From cabo@tzi.org Thu Nov 1 00:36: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 2100921F8519 for ; Thu, 1 Nov 2012 00:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.684 X-Spam-Level: X-Spam-Status: No, score=-106.684 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 SnwptPID0mIl for ; Thu, 1 Nov 2012 00:36:39 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 52CC121F8514 for ; Thu, 1 Nov 2012 00:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qA17aVhn028294; Thu, 1 Nov 2012 08:36:31 +0100 (CET) Received: from [192.168.217.105] (p54893DF3.dip.t-dialin.net [84.137.61.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C80DFEA8; Thu, 1 Nov 2012 08:36:30 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FFE16053@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 1 Nov 2012 08:36:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0AD30956-7482-4900-9784-FEF7896B5677@tzi.org> References: <255B9BB34FB7D647A506DC292726F6E114FFE16053@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1499) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] JSON pointer: disallow leading 0s in array indicies 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, 01 Nov 2012 07:36:40 -0000 On Nov 1, 2012, at 07:24, "Manger, James H" = wrote: > The JSON pointer spec allows /007 as a valid pointer to the 8th item = in a JSON array, in addition to /7, and /07 etc. I think we should = change this to disallow leading zeros. Absolutely -- also for the same reasons leading zeros are not allowed in = JSON itself. Important: Make it a MUST reject, or people will postel*) them in again. Gr=FC=DFe, Carsten *) Yes, this is a verb now, referring to the undesirable effect of Jon = Postel's timeless robustness principle. It works like this: People try to be robust and allow leading zeros on = reception. Other people find out that this is common and for some = reason start relying on that in their senders. Suddenly, not supporting = leading zeroes becomes an interop problem. Done: the protocol has = changed itself. From chris@w3.org Thu Nov 1 04:01: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 187B121F84CF for ; Thu, 1 Nov 2012 04:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 QACTFYqbp+hg for ; Thu, 1 Nov 2012 04:01:45 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 64B3221F84C7 for ; Thu, 1 Nov 2012 04:01:45 -0700 (PDT) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtpa (Exim 4.69) (envelope-from ) id 1TTsWr-0008PO-MZ; Thu, 01 Nov 2012 07:01:41 -0400 Date: Thu, 1 Nov 2012 12:01:00 +0100 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Organization: W3C X-Priority: 3 (Normal) Message-ID: <1969645725.20121101120100@w3.org> To: apps-discuss@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------2711F196B7C4A0A" Cc: eb2m-mrt@asahi-net.or.jp, chris@w3.org Subject: [apps-discuss] FW: New Version Notification for draft-lilley-xml-mediatypes-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Chris Lilley List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 11:01:46 -0000 ------------2711F196B7C4A0A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello apps-discuss, draft-lilley-xml-mediatypes-00.txt is a restart of a proposed replacement for RFC3023. The previous attempt foundered because the approach taken required deprecation of text/xml, and the implementor community was not happy with that as there is much legacy content using that type that still has to be supported. The present draft takes advantage of recent changes in HTTP-bis which removes the default charset, and so treats text/xml the same as application/xml. This approach is also what most implementations already do, in practice. The present draft also introduces some clarifications on fragment identifiers for xml, and updates some references. It has been suggested that this document would be a good fit for the apps area WG, and the editors would like to request review and adoption by the WG (or an alternative suggestion of where/how to handle this document). This would be a standards-track document. -- Chris Lilley Technical Director, Interaction Domain W3C Graphics Activity Lead, Fonts Activity Lead Co-Chair, W3C Hypertext CG Member, CSS, WebFonts, SVG Working Groups ------------2711F196B7C4A0A Content-Type: message/rfc822; name="1.msg" Content-Disposition: attachment; filename="1.msg" X-From-Line: internet-drafts@ietf.org Return-Path: Received: from imap.staffmail.ed.ac.uk [129.215.17.36] by calexico.inf.ed.ac.uk with IMAP (fetchmail-6.3.17) for (single-drop); Mon, 15 Oct 2012 12:50:36 +0100 (BST) Received: from murder (lmtp1.ucs.ed.ac.uk [129.215.149.64]) by mailbe9.staffmail.ed.ac.uk (Cyrus v2.3.15) with LMTPA; Mon, 15 Oct 2012 12:49:45 +0100 X-Sieve: CMU Sieve 2.3 Received: from lmtp1.ucs.ed.ac.uk (localhost [127.0.0.1]) by lmtp1.ucs.ed.ac.uk (Cyrus v2.2.12) with LMTPA; Mon, 15 Oct 2012 12:49:45 +0100 Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by lmtp1.ucs.ed.ac.uk (8.13.8/8.13.7) with ESMTP id q9FBniwN024964 for ; Mon, 15 Oct 2012 12:49:44 +0100 (BST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q9FBnh5n024615 for ; Mon, 15 Oct 2012 12:49:43 +0100 (BST) Received: from dalziel.ucs.ed.ac.uk (dalziel.ucs.ed.ac.uk [129.215.13.80]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q9FBnhMm032515 for ; Mon, 15 Oct 2012 12:49:43 +0100 Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by dalziel.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q9FBnbHW010490 for ; Mon, 15 Oct 2012 12:49:42 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7F221F8589; Mon, 15 Oct 2012 04:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 6d3CwGLKNqgG; Mon, 15 Oct 2012 04:49:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8230F21F86CE; Mon, 15 Oct 2012 04:49:36 -0700 (PDT) From: internet-drafts@ietf.org To: ht@inf.ed.ac.uk Cc: alexey.melnikov@isode.com, chris@w3.org, eb2m-mrt@asahi-net.or.jp Subject: New Version Notification for draft-lilley-xml-mediatypes-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121015114936.21755.88774.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 04:49:36 -0700 X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: hits=0 tests= version=2.64+local X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.52 on 129.215.149.64 X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 X-Scanned-By: MIMEDefang 2.60 on 129.215.13.80 X-Bogosity: No, tests=bogofilter, spamicity=0.500000, version=1.2.2 Lines: 46 Xref: calexico.inf.ed.ac.uk pers-2012-10:427 MIME-Version: 1.0 A new version of I-D, draft-lilley-xml-mediatypes-00.txt has been successfully submitted by Henry S. Thompson and posted to the IETF repository. Filename: draft-lilley-xml-mediatypes Revision: 00 Title: XML Media Types Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 35 URL: http://www.ietf.org/internet-drafts/draft-lilley-xml-mediatypes-00.txt Status: http://datatracker.ietf.org/doc/draft-lilley-xml-mediatypes Htmlized: http://tools.ietf.org/html/draft-lilley-xml-mediatypes-00 Abstract: This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. Major differences from [RFC3023] are alignment of charset handling for text/xml and text/xml-external-parsed-entity with application/ xml, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, mention of the XPointer Registry, and updating of many references. The IETF Secretariat ------------2711F196B7C4A0A-- From bradfitz@google.com Wed Oct 31 17:02: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 8849721F88A3 for ; Wed, 31 Oct 2012 17:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.118 X-Spam-Level: X-Spam-Status: No, score=-99.118 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_PROFIT1=3.858, 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 GbqOCDC7DjMx for ; Wed, 31 Oct 2012 17:02:32 -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 39D5C21F849A for ; Wed, 31 Oct 2012 17:02:32 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2185133obq.31 for ; Wed, 31 Oct 2012 17:02:31 -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=ZK5Vwc1PIL5/3ySTfBAkuzNoo1a/YaAzWvMEbYNHUSA=; b=LXNFY9nTySR4dtVY/QWtqo2LAccZjnhEOWJk1wGlA3fNi324U04ZimDh+RGcnaAkx8 vUxiUJPR+DHGfqSOdncSJshPSc8W2/4Gpk02/3praHxl7MF1gOsgnCNu6ltuvXBvTFNQ P1HHCcIzgS2GjtdaZ5UuQjDF+2HBUA1ySgCxVhFOLNI4eumZJgGPa2wGwSqM1Xri5PmC xwGDnCOUwKsnsJqzxGuYKCkaNSMU/SmDPhvHuOFKBG7z/u/tBIRe9DMUia9UHKlbYQuT M3x/64UtSAihac2XnUODdpFWrNZhP90yCBHmEZPrv1GCkMvhYglYstnCDcSdjzF0WbQh SkXw== 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=ZK5Vwc1PIL5/3ySTfBAkuzNoo1a/YaAzWvMEbYNHUSA=; b=lE5sW/b0yKXCh4/ZQ3NK9nW2MW8o4HNiYaObeTdmzu2yzT9X6uaR6BvRLu+bPOmA1L njLbdj3n6TfKnLDOU1hmC3hlNpXWWiPcOV1LAdXPXF0YJ/BA+oZFAJD+l4Qjp1pn+JlJ XQLByRdP2xINMagPbD6CGZ73zb5FPTiOnPJt3zJ5GgH3vJZhGhRkVBNQLOsT6iQCBWlq d7pcLSXPhTJG/N0vQ+/wJdN0wZ1LipEaIFxOoPJjuvdax0wDoSrAq75mfNtRmeYl4Ekm g3EZKyxufNzys6slkQG1vCylVmt99w2K5/wc3Xp66zYj0K7XXL74DNZzKFcMv/pMAqfl mUmg== MIME-Version: 1.0 Received: by 10.60.172.138 with SMTP id bc10mr14845101oec.33.1351728151675; Wed, 31 Oct 2012 17:02:31 -0700 (PDT) Received: by 10.60.31.41 with HTTP; Wed, 31 Oct 2012 17:02:31 -0700 (PDT) In-Reply-To: <00c401cdb7c0$55fe5eb0$01fb1c10$@packetizer.com> References: <00c401cdb7c0$55fe5eb0$01fb1c10$@packetizer.com> Date: Thu, 1 Nov 2012 01:02:31 +0100 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=bcaec54d41a850423004cd63bcd3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlIzQoa1KUIC8J7ufYqYrTHQ2fqMtDqTK9CrURY9GRMvs440sPRL/GrYBw9gksnzNvfZP3WKUzitw2QWovXUFeA9wtOu+G8RNpS5NzhcvjflesQ4GI2SysFHoxXo+D/t8+sfMzdXL9/Bb3NlKuT4mS/BSbtNzyt2rPyZrgfY69QopbNo/RwPkc2GpaExtvtxAF/C4um X-Mailman-Approved-At: Thu, 01 Nov 2012 08:01:53 -0700 Cc: public-fedsocweb@w3.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger compromises 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, 01 Nov 2012 00:07:28 -0000 --bcaec54d41a850423004cd63bcd3 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 1, 2012 at 12:34 AM, Paul E. Jones wrote: > Brad, > > > To everybody who recently saw me rant about WebFinger in person > > recently, hello again. > > Oh, I wish I was there... ;-) > I'm happy to [video] chat any time. > > -- can we please stop changing things? -- JSON, XRD, great, whatever. > > But let's just pick one. If JSON is now the hotness, let's pick *only* > > JSON. Specs that say "X is required but you can maybe do Y if you want > > to" just reek of political compromise to gain a certain party's favor. > > Look at OpenID 2.0. (I remember being sad about those political moves > > too, but I had lost the energy to fight) > > The current language actually isn't political compromise, but more my > desire to not break backward-compatibility any more than we have to. > Current spec recognizes, for example, that Google's WF server serves up > XML. If I change it to CSV tomorrow, will the spec recognize that? Seriously, don't regard at all what Google does today. It can change on a moment's notice if this thing every shows promise of stabilizing. The only reason it doesn't support JSON today is that I got bored of this process. > Clients expecting XML will still work. How?? The spec says only JSON is required? > So long as any WF server wants to support both, those clients will work. > I might advocate for our webfinger implementation to only return XML-as-requested 25% of the time. That would be more hilarious than the 0% as required by the spec. Going forward, XML is optional and JSON is mandatory. I wanted to mandate > both, but lost that argument. (Still, supporting both is simple. My > server does both and will honor the Accept header. It's trivial to do.) > > At some point, I will publish my server code. It's just a simple Perl > script, but shows how trivial it is to implement a WF server. It does both > XML and JSON and I do wish we would continue with both. > Do not even talk about implementations. Implementations are always easy. I made that mistake in the past, trying to convince people how easy things are by showing code. What is harder is winning mindshare, and overly large, schizophrenic specs don't instill confidence in would-be supporters. Further, I accept the preference for JSON and only putting the requirement > there. But the fact is that any web resource can return ANY format. This > is a basic part of HTTP and the reason the Accept header exists. So why don't you document the image/gif response type in the spec? (Because it would be noise.) Just as I can file my own RFC entitled "Recommendations for serving image/gif response payloads in Content-Type-negotiated WebFinger queries", so can the XRD community. The WebFinger spec is only required to document the requirements, not ponies. > So we should design the service such that we can support whatever the next > hot format is. > I do not object to you clarifying that "WebFinger MAY return alternate response types, if requested by the client with an HTTP Accept header blah blah blah in the absence of an such a header, the default is JSON etc etc" > > So, my position is: > 1) Let's not just kill XML because we decided we do not like it this week > (killing all hope for backward-compatibility) > Let's kill it because it's not required. I neither like nor dislike it. I also neither like nor dislike JSON. I just think it's stupid for a spec to not decide. I'm entering this mailing list again because it has no deciders. Everybody just keeps saying "yes, sure, we'll add that to" (as far as I can tell). > 2) Let's have a web service that could serve XML or JSON or next-hot-thing > (i.e., future-proof it) > Don't disagree. > 3) Let's use HTTP the way it is supposed to be used and allow the "Accept" > header to work via /.well-known/host-meta. > Don't disagree. > 4) Since host-meta.json is already defined (and I would have argued > against it, but it's there), let's fully embrace it. > That's fine. I'm not against supporting that. > -- My recommendation: just remove all mention of XRD from the latest > > WebFinger spec. Yes, this is counter to my "please stop changing > > things" bullet earlier. But WebFinger has a better chance of success if > > it's a simple spec. And you're not breaking compatibility with anybody > > because *nobody uses WebFinger*. > > I'd prefer not to for the above-stated reasons. Note that only JSON is > required. > > > -- 1 round trip, 2 round trips. Don't really care. 2 round trips keeps > > the spec simpler and the 1st will be highly cacheable (Expires: weeks), > > so it's 1 round trip in practice, but I won't fight (too much) > > *optional* parameters in the 1st request to possibly skip the 2nd > > request. It worries me, though. I'd rather see that optimization added > > in a subsequent version of the spec, so all 1.0 implementations have > > then shown that they're capable of performing the base algorithm. I > > worry that too many servers will implement the optimization and then > > lazy clients will become pervasive which only do one round trip, thus > > making the "optional" optimization now de facto required for servers. > > So I'd really rather drop that from the spec too. Let's add it only > > later, once it's shown to be needed. As is, clients could even fire off > > two HTTP requests in parallel to reduce latency, one for host-meta and > > one optimistically for the presumed host-meta location in cases of big > > hosts that rarely change, or expired cached host-meta documents. > > We support both. RFC 6415 defined the base for 2 round trips. The > current WF spec adds that extension to allow for one round trip. > Please acknowledge my argument, even if you don't agree with it. Do you understand my description of how I fear it will become a de-facto requirement? > And both are trivially implemented, so simple it can be done via > [snip] Again, I don't care about implementations. > I will continue to fight for Google's WebFinger support, but I'm not the > > only one losing patience. > > You're right there, which is why I'm serving the role of editor. I thank you for that, because it's a largely thankless job. I'm coming across as aggressive, but I really want this to work, and I view everybody on these mailing lists as friends. I just think we all need a reality check. > I'm personally pretty happy with the way things are currently defined. > Aside from the vast number of comments regarding privacy, I'm not hearing > a lot in the way of technical issues. I'd like to move forward. > As would I. > > Everybody please hurry up, simplify, then hurry up. I'll help however I > > can. I'm not sure whether this was helpful. > > It's doesn't get much simpler than this: > > curl https://packetizer.com/.well-known/host-meta.json? > resource=acct:paulej@packetizer.com Again, implementation. Everybody on this mailing list can write a static webserver. Now we need to just move on to agreeing on some useful link relations for > WF. > I will stay out of your way there. I just want a simple base to build upon. --bcaec54d41a850423004cd63bcd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Nov 1, 2012 at 12:34 AM, Paul E. Jones <paulej@packetizer.com> wrote:
Brad,

> To everybody who recently saw me rant about WebFinger in person
> recently, hello again.

Oh, I wish I was there... ;-)

I&#= 39;m happy to [video] chat any time.
=C2=A0
> -- can we please stop changing things? =C2=A0-- JSON= , XRD, great, whatever.
> But let's just pick one. =C2=A0If JSON is now the hotness, let'= ;s pick *only*
> JSON. =C2=A0Specs that say "X is required but you can maybe do Y = if you want
> to" just reek of political compromise to gain a certain party'= ;s favor.
> Look at OpenID 2.0. =C2=A0(I remember being sad about those political = moves
> too, but I had lost the energy to fight)

The current language actually isn't political compromise, but mor= e my desire to not break backward-compatibility any more than we have to. = =C2=A0Current spec recognizes, for example, that Google's WF server ser= ves up XML.

If I change it to CSV tomorrow, will the spec recognize= that?

Seriously, don't regard at all what Goo= gle does today. =C2=A0It can change on a moment's notice if this thing = every shows promise of stabilizing. =C2=A0The only reason it doesn't su= pport JSON today is that I got bored of this process.
=C2=A0
=C2=A0Clients expecting XM= L will still work.

How?? The spec says only= JSON is required?
=C2=A0
=C2=A0So long as any WF se= rver wants to support both, those clients will work.
<= br>
I might advocate for our webfinger implementation to only return XML-as-req= uested 25% of the time. =C2=A0That would be more hilarious than the 0% as r= equired by the spec.

Going forward, XML is optional and JSON is mandatory. =C2=A0I wanted to man= date both, but lost that argument. =C2=A0(Still, supporting both is simple.= =C2=A0My server does both and will honor the Accept header. =C2=A0It's= trivial to do.)

At some point, I will publish my server code. =C2=A0It's just a simple = Perl script, but shows how trivial it is to implement a WF server. =C2=A0It= does both XML and JSON and I do wish we would continue with both.

Do not even talk about implementations. =C2=A0Implement= ations are always easy. =C2=A0I made that mistake in the past, trying to co= nvince people how easy things are by showing code.

What is harder is winning mindshare, and overly large, schizophrenic specs= don't instill confidence in would-be supporters.

Further, I accept the prefere= nce for JSON and only putting the requirement there. =C2=A0But the fact is = that any web resource can return ANY format. =C2=A0This is a basic part of = HTTP and the reason the Accept header exists.

So why don't you document the image/gif response ty= pe in the spec? =C2=A0(Because it would be noise.)

Just as I can file my own RFC entitled "Recommendations for serving i= mage/gif response payloads in Content-Type-negotiated WebFinger queries&quo= t;, so can the XRD community.

The WebFinger spec is only required to document the req= uirements, not ponies.

=C2=A0
So we should design the service such that we can support whatever the next = hot format is.

I do not object to you c= larifying that "WebFinger MAY return alternate response types, if requ= ested by the client with an HTTP Accept header blah blah blah in the absenc= e of an such a header, the default is JSON etc etc"
=C2=A0

So, my position is:
1) Let's not just kill XML because we decided we do not like it this we= ek (killing all hope for backward-compatibility)

<= /div>
Let's kill it because it's not required. =C2=A0I neither = like nor dislike it. =C2=A0I also neither like nor dislike JSON. =C2=A0I ju= st think it's stupid for a spec to not decide.

I'm entering this mailing list again because it has= no deciders. =C2=A0Everybody just keeps saying "yes, sure, we'll = add that to" (as far as I can tell).
=C2=A0
2) Let's have a web service that could serve XML or JSON or next-hot-th= ing (i.e., future-proof it)

Don't d= isagree.
=C2=A0
3) Let's use HTTP the way it is supposed to be used and allow the "= ;Accept" header to work via /.well-known/host-meta.

Don't disagree.
=C2=A0
4) Since host-meta.json is already defined (and I would have argued against= it, but it's there), let's fully embrace it.
=
That's fine. =C2=A0I'm not against supporting that.<= /div>

> -- My recommendation: just remove all mention of XRD= from the latest
> WebFinger spec. =C2=A0Yes, this is counter to my "please stop cha= nging
> things" bullet earlier. =C2=A0But WebFinger has a better chance o= f success if
> it's a simple spec. =C2=A0And you're not breaking compatibilit= y with anybody
> because *nobody uses WebFinger*.

I'd prefer not to for the above-stated reasons. =C2=A0Note that o= nly JSON is required.

> -- 1 round trip, 2 round trips. Don't really care. 2 round trips k= eeps
> the spec simpler and the 1st will be highly cacheable (Expires: weeks)= ,
> so it's 1 round trip in practice, but I won't fight (too much)=
> *optional* parameters in the 1st request to possibly skip the 2nd
> request. =C2=A0It worries me, though. =C2=A0I'd rather see that op= timization added
> in a subsequent version of the spec, so all 1.0 implementations have > then shown that they're capable of performing the base algorithm. = =C2=A0I
> worry that too many servers will implement the optimization and then > lazy clients will become pervasive which only do one round trip, thus<= br> > making the "optional" optimization now de facto required for= servers.
> So I'd really rather drop that from the spec too. =C2=A0Let's = add it only
> later, once it's shown to be needed. =C2=A0As is, clients could ev= en fire off
> two HTTP requests in parallel to reduce latency, one for host-meta and=
> one optimistically for the presumed host-meta location in cases of big=
> hosts that rarely change, or expired cached host-meta documents.

We support both. =C2=A0RFC 6415 defined the base for 2 round trips. = =C2=A0The current WF spec adds that extension to allow for one round trip.<= br>

Please acknowledge my argument, even if= you don't agree with it. =C2=A0Do you understand my description of how= I fear it will become a de-facto requirement?
=C2=A0
And both are trivially impl= emented, so simple it can be done via
[snip]

Again, I don't care about implementations.=C2=A0
<= br>
> I will continue to fight for Google's WebFinger = support, but I'm not the
> only one losing patience.

You're right there, which is why I'm serving the role of edit= or.

I thank you for that, because it's = a largely thankless job. =C2=A0I'm coming across as aggressive, but I r= eally want this to work, and I view everybody on these mailing lists as fri= ends. =C2=A0I just think we all need a reality check.
=C2=A0
=C2=A0I'm personally p= retty happy with the way things are currently defined. =C2=A0Aside from the= vast number of comments regarding privacy, I'm not hearing a lot in th= e way of technical issues. =C2=A0I'd like to move forward.

As would I.
=C2=A0
> Everybody please hurry up, simplify, then hurry up. = =C2=A0I'll help however I
> can. =C2=A0I'm not sure whether this was helpful.

It's doesn't get much simpler than this:

=C2=A0 =C2=A0curl https://packetizer.com/.well-known/host-meta.json?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 resource=3Dacct:paulej@packetizer.com

= =C2=A0Again, implementation. =C2=A0Everybody on this mailing list can write= a static webserver.

Now we need to just move on to agr= eeing on some useful link relations for WF.

I will stay out of your way there. =C2=A0I just want a simple base to = build upon.

--bcaec54d41a850423004cd63bcd3-- From bradfitz@google.com Thu Nov 1 05:58: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 5477A21F8206 for ; Thu, 1 Nov 2012 05:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.947 X-Spam-Level: X-Spam-Status: No, score=-101.947 tagged_above=-999 required=5 tests=[AWL=1.029, 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 2jHYkdDcZcwG for ; Thu, 1 Nov 2012 05:58:41 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC4F221F8FD1 for ; Thu, 1 Nov 2012 05:58:28 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so2706439oag.31 for ; Thu, 01 Nov 2012 05:58:28 -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=ooyFJe/heTDD2vBcArXQoQ5E7kMtu5qqsQq2inMXZJw=; b=nM1oF1PyTyQ0qWp4JjdtdTiLLWRRjQba6U5aFtflkZiOShLrVSsLUJy7G4ywP+haDb yELrvD3Q10X4pHbOLEieAzVrls1OTVEaJtmeoE+1fqMF7yNPISIDXCnTxmhdAnYVmFKU xoCmQJ+Qtc8HMuIDEVJbx0XaLWkJRVp5VH1D1S+xGZJJK3P1geBICisRwurBdjGieuar VuQgvwqu19CiSlneHKXJmydTMI1KVPWVfyOtRSlLalCpGRS6AY0zJGzv4Ev1DTCk0Iep IKhR6/D+VOQm+zNr5+fqOR/R21Ekd8fruZ7t39Hr/w7JGlqBGYf4YHJ6sQF4xlT9sL6q J2qA== 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=ooyFJe/heTDD2vBcArXQoQ5E7kMtu5qqsQq2inMXZJw=; b=A/kjUAzvQt416ziAEin+kIscOX+H+MZrz3Y5f4u+ETqv8tGxSJKMDSOdBP6eNezK5f kKx8HGJaHpAkSzis9SWOcLFF+NUs9UKu0VPcU40711OQ6laMosFCzSk3M6XpR9oHZxCO eBoG8UaYNt5hpZInItC2PVCeW6wRHOgioM4Pep/wDoZzEZd4f8w7y9DUQnAjM48LHVKW hUTq8GjukUH64Aew3FB1SsqMqlpjvuusUiNoLK33tx6FPkAo6H2hD0kY1jQwyWcQgxbh ZkuwpNsZ+aTPVUCUqdf0dnDSYjJ7tc0mqd2TowXmacBnCQVsBnHKZVAHGf2HPRLa2fBB HFqA== MIME-Version: 1.0 Received: by 10.60.169.20 with SMTP id aa20mr35076266oec.105.1351774708510; Thu, 01 Nov 2012 05:58:28 -0700 (PDT) Received: by 10.60.31.41 with HTTP; Thu, 1 Nov 2012 05:58:28 -0700 (PDT) In-Reply-To: References: <00c401cdb7c0$55fe5eb0$01fb1c10$@packetizer.com> <00e201cdb7e7$a5a67390$f0f35ab0$@packetizer.com> Date: Thu, 1 Nov 2012 13:58:28 +0100 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=bcaec54d49a651317404cd6e93e2 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnooqnIdr4trrtajMM/RD3plkmCEDp9bzduPIIFU3zO+6EYODZkdh3GwPg0f+bexOy+o5SiJZEzoNJwQNojc32sgqhoz/QepLvqm3WddnvJ8leSd/9s1L0PaTREMjIrk8om7RMY6YzRSmW/QT4G9GDgfyAxgl/okBTrvj31EvTQI6D6N4M7xk5ITFgwCkzzf3Oesn/6 X-Mailman-Approved-At: Thu, 01 Nov 2012 08:02:05 -0700 Cc: public-fedsocweb@w3.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger compromises 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, 01 Nov 2012 12:58:42 -0000 --bcaec54d49a651317404cd6e93e2 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 1, 2012 at 6:34 AM, Dick Hardt wrote: > > On Oct 31, 2012, at 9:16 PM, "Paul E. Jones" > wrote: > > Brad,**** > > Comments in green: > > > that is fairly random! > First green, then red. I think he's pointing out that this spec is a bikeshed and he can also pick colors. --bcaec54d49a651317404cd6e93e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Nov 1, 2012 at 6:34 AM, Dick Hardt <dick.hardt@gmail.com>= wrote:

On Oct 31, 2012, at 9:16= PM, "Paul E. Jones" <paulej@packetizer.com> wrote:

Brad,
=C2=A0
Comments in= =C2=A0green:=C2=A0

that is fairly random!

First green, then red. =C2=A0I t= hink he's pointing out that this spec is a bikeshed and he can also pic= k colors.
--bcaec54d49a651317404cd6e93e2-- From bradfitz@google.com Thu Nov 1 07:43: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 B040A21F8AC9 for ; Thu, 1 Nov 2012 07:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=0.686, 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 C9BbNr6rUCB5 for ; Thu, 1 Nov 2012 07:43:47 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D42321F8AAF for ; Thu, 1 Nov 2012 07:43:47 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so2831619oag.31 for ; Thu, 01 Nov 2012 07:43:47 -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=dSjP5ATvBD979Ks8+i15YKAAOVgx+vkhmp5Ws/SkY5o=; b=Jomr6Jf86qCPYJYndDomxpo7Z9NX9M1z1/bhK/+Lx50fYYVAthkSib0DcIC+3KrPvY QX/GtM2Rtl2rDzSeLPVMEgz9Dq5v1jsNI98elPU1+Tu3LzhnNB+P655gSHdqsp6Hrt3e IxarvsEfsbrUn74CmZzq8OPq3Pt7hD+TsP1xgzzJ+MGjEdoafwwUTJ1+h5Vsr5txo+cC ecvJUe33kmlx6JJlwIXESOuwL9+yhwuhlnO52Anclf6E9rEZ9LHNHVkuilgvS3PqXxrv izXH6mLMksyaT+QxJoFgzlfNCOmAuLGZOvKjzIw2Y0O69AdkHQ8g1JP5qlas0VSuhfC4 jpiQ== 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=dSjP5ATvBD979Ks8+i15YKAAOVgx+vkhmp5Ws/SkY5o=; b=HK4p1KlRhgQtuyThWdpN3xlBYEBK41kIl+kZaj5AFAldDy6X1R5UW3CrNVn3NHuVAD 12FzX/R5kepK/OIhVN8aWyUrrXjX9j7EVlDYtr0jUTxRnB/AXCZPQe/S+/UkBufd9hWO IagLlagZvDADL1NVc5qYKaqA7SrouEyf8DnsSg4E/Y9zLy7777dybJsEqlw/7BCCeW9m 5z+H9nniwXgc+gkoa+WonPaCTjtGpSTJ99SOqZwNaVwI1QbOmp9C+Q/NIu7t+z45vVeJ CRyX1fw2WyNjfO1rxGhfpsCI9S/Ek3hVEWA7iH6CZaoNp7A+1La3esufMOf+UN/i8hak KSyA== MIME-Version: 1.0 Received: by 10.60.169.20 with SMTP id aa20mr35369969oec.105.1351781027076; Thu, 01 Nov 2012 07:43:47 -0700 (PDT) Received: by 10.60.31.41 with HTTP; Thu, 1 Nov 2012 07:43:47 -0700 (PDT) In-Reply-To: <011a01cdb7fb$bca72f80$35f58e80$@packetizer.com> References: <011a01cdb7fb$bca72f80$35f58e80$@packetizer.com> Date: Thu, 1 Nov 2012 15:43:47 +0100 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=bcaec54d49a6eedb6904cd700bfa X-System-Of-Record: true X-Gm-Message-State: ALoCoQnKPXS3Ju3X04mTLe1ZoJZeb/xx4DikOwyZErTJgsRp4lgDhh57pCDLjdpIn9Wzi/EVugezPXBPH2K0LBgXT/bYHp2lzGF7rXfBQRLBnEHPCCrUCS6Hf86DOiEjY5DWMwo6JyqCbuIzM7Y1vfzLiKLYU0l+X0jriGi6MrhL9WL3mc2SZtuFtEMTwk48U++TGFh1DyUF X-Mailman-Approved-At: Thu, 01 Nov 2012 08:02:20 -0700 Cc: public-fedsocweb@w3.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] An alteration to the WebFinger Spec 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, 01 Nov 2012 14:43:48 -0000 --bcaec54d49a6eedb6904cd700bfa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Nov 1, 2012 at 7:40 AM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > Here=E2=80=99s a proposal that some might find acceptable and others will= probably > love. It=E2=80=99s just a proposal, so no bazookas, please, from those w= ho will > find it troubling ;-)**** > > ** ** > > > http://hive.packetizer.com/users/paulej/internet-drafts/draft-ietf-appsaw= g-webfinger-03-ALT.txt > Much nicer! > **** > > ** What I did with this text is the following: > > ** > > **=C2=B7 **Included all of the current -03 text (not yet publishe= d, > but text folks proposed on the list)**** > > **=C2=B7 **Removed every reference to XML and XRD**** > > **=C2=B7 **Stated that the default format for > /.well-known/host-meta.json is JRD**** > > **=C2=B7 **Stated that the default format for /.well-known/host-m= eta > is implementation-dependent, so clients MUST use the Accept header to > explicitly request the desired representation when using that resource > (this is key to backward/forward compatibility and proper use of HTTP and > Accept)**** > > **=C2=B7 **Removed the =E2=80=9Caccount link relation=E2=80=9D se= ction**** > > **=C2=B7 **Removed the interop considerations section, since some= feel > there is no need and I think requiring use of =E2=80=9CAccept=E2=80=9D on= host-meta will > address any interop concerns**** > > **=C2=B7 **Removed the XML appendix that gave some people heartbu= rn**** > > ** ** > > This shaved off 6 pages of text, I think will still give us > backward-compatibility for those who have asked for it, but more clearly > positions JSON / JRD as the only format developers need to worry with.***= * > > ** ** > > Tell me what you think. > Some notes I took while reading: * Delete the whole section "4.2. Simplifying the Login Process". As much a= s I loves me some OpenID, it's out of place in this document. * WebFinger, being JSON-only, should only document /.well-known/host-meta.json as part of the client's discovery process, not /.well-known/host-meta. Status.net and whoever else can continue to serve webfinger for compatibility at /.well-known/host-meta if they'd like to support all of RFC 6415. But WebFinger doesn't need to include docs on supporting all of RFC 6415. It should be possible to write a server which is WebServer compliant without being 6415 compliant. * Section 5.2: ditch the rel=3D, resource=3D parameters from host-meta.json= . It's a HOST meta, not a RESOURCE meta. It's being morphed into an all-encompassing endpoint. If you really want this, DO NOT REUSE host-meta and just use /.well-known/webfinger-query. But I am not proposing that. I'm just saying that would be more sane than tacking random crap onto host-meta. * Section 6. MUST support CORS, but MAY exclude the header. What? SHOULD probably. * Section 8.1: "When a query is issued host-meta" ... "pointing to the location of the hosted WebFinger service URL" host-meta is its own thing. You ar= e assuming that host-meta means WebFinger. I might have more minor feedback later, but the above is most of it. --bcaec54d49a6eedb6904cd700bfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Nov 1, 2012 at 7:40 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Much nicer!
=C2=A0

=C2= =A0What I did with this text is the following:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Included all of the curre= nt -03 text (not yet published, but text folks proposed on the list)=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Removed every reference to XML and= XRD

= =C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Stated tha= t the default format for /.well-known/host-meta.json is JRD

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Stated that the default format for= /.well-known/host-meta is implementation-dependent, so clients MUST use th= e Accept header to explicitly request the desired representation when using= that resource (this is key to backward/forward compatibility and proper us= e of HTTP and Accept)

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Removed the =E2=80=9Caccount link = relation=E2=80=9D section

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Removed the interop considerations section, since some feel there is= no need and I think requiring use of =E2=80=9CAccept=E2=80=9D on host-meta= will address any interop concerns

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Removed the XML appendix that gave= some people heartburn

=C2=A0

This shaved off 6 pages of t= ext, I think will still give us backward-compatibility for those who have a= sked for it, but more clearly positions JSON / JRD as the only format devel= opers need to worry with.

=C2=A0

Tell = me what you think.


Some notes I t= ook while reading:

* Delete the whole section= "4.2. Simplifying the Login Process". =C2=A0As much as
=C2=A0 I loves me some OpenID, it's out of place in this document.=

* WebFinger, being JSON-only, should only documen= t /.well-known/host-meta.json
=C2=A0 as part of the client's = discovery process, not /.well-known/host-meta.
=C2=A0 Status.net and whoever else can continue to serve webfinger for= compatibility
=C2=A0 at /.well-known/host-meta if they'd lik= e to support all of RFC 6415. =C2=A0But
=C2=A0 WebFinger doesn= 9;t need to include docs on supporting all of RFC 6415. =C2=A0It
=C2=A0 should be possible to write a server which is WebServer complia= nt without
=C2=A0 being 6415 compliant.

= * Section 5.2: ditch the rel=3D, resource=3D parameters from host-meta.json= .
=C2=A0 It's a HOST meta, not a RESOURCE meta. =C2=A0It's being morp= hed into an
=C2=A0 all-encompassing endpoint. =C2=A0If you really= want this, DO NOT REUSE host-meta
=C2=A0 and just use /.well-kno= wn/webfinger-query. =C2=A0But I am not proposing that.
=C2=A0 I'm just saying that would be more sane than tacking random= crap onto
=C2=A0 host-meta.

* Section 6= . MUST support CORS, but MAY exclude the header. What? SHOULD probably.

* Section 8.1: "When a query is issued host-meta" = ... "pointing to the location=C2=A0
=C2=A0 of the hosted Web= Finger service URL" =C2=A0host-meta is its own thing. =C2=A0You are
=C2=A0 assuming that host-meta means WebFinger.


I might have more minor feedback l= ater, but the above is most of it.
--bcaec54d49a6eedb6904cd700bfa-- From bradfitz@google.com Thu Nov 1 07:53: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 5856621F8668 for ; Thu, 1 Nov 2012 07:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.628 X-Spam-Level: X-Spam-Status: No, score=-101.628 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666, 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 ZKpLNM9WMG+O for ; Thu, 1 Nov 2012 07:53:11 -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 0572021F8667 for ; Thu, 1 Nov 2012 07:53:10 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2832173obq.31 for ; Thu, 01 Nov 2012 07:53:10 -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 :content-type:x-system-of-record; bh=dDSwBehTks70r+4kxi3E516nIPye0lsTUsA8ydYGux8=; b=T5NE4/fxCCrOtjuIoFS7FfitJs77HgU6oUV62ldLlv3AL0WZPuOheQM3+PDO9cZOFs 7eb2c+gMGNuQpnEqeNejNEDvXkazF/npW4XaogKzXd5gZwlIXPbSqKF6489ZCdwD6CpE EL+6/tc7qvnD4ihkBgNAzeJroXeNGTsDV1ErpPegezKOXg8A5nT5REHhJzK33UXedZAM RJBBE3AC7SFV96g8Njreft4QzhMawmfk6+PQLrk9En+zFkvA9zv7yJiEMIXGkNMju+x+ Qp1VqfogeKw0oWnvfvz7e5hcmLaC9tJo6d+9Kr1GOeGDmxG8ZUjmesDF31vGijn2Civ6 mcoQ== 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 :content-type:x-system-of-record:x-gm-message-state; bh=dDSwBehTks70r+4kxi3E516nIPye0lsTUsA8ydYGux8=; b=lJekfe0/Zzi6AIkcEcTMAn+sK6WxsDyjd8mXfaDetEJQ6cYyku/d8e5AnAFGVmG/1G lJwnyujXSm9NnmHPjf6kpqK4xtHf1K0yB60t99PGnjETt5uvAE3A/py8f6AWxky4d4M5 47CI5GgXGefjeXu7SEdIEghx+ehNmaeAvgd+n2K2ruYSipcBjEQ0NQNqtgSiAR4n/FMW GbjDgmgbSs2TJbY5e2VSZoBaj98+oq0EAQmv2ZlRJaDQrln6ycQBLoQ+1IC7gHrS8+vq TqftPhIX9MP0wTBfPdPwmZblQDjOz1Bk9goOQKXld3wEWNWy2ulq1zZQGRckNkNpTBR3 gyRQ== MIME-Version: 1.0 Received: by 10.60.31.101 with SMTP id z5mr35707172oeh.110.1351781590586; Thu, 01 Nov 2012 07:53:10 -0700 (PDT) Received: by 10.60.31.41 with HTTP; Thu, 1 Nov 2012 07:53:10 -0700 (PDT) In-Reply-To: References: <00c401cdb7c0$55fe5eb0$01fb1c10$@packetizer.com> <00e201cdb7e7$a5a67390$f0f35ab0$@packetizer.com> <013001cdb7fd$860de980$9229bc80$@packetizer.com> Date: Thu, 1 Nov 2012 15:53:10 +0100 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com, apps-discuss@ietf.org, public-fedsocweb@w3.org Content-Type: multipart/alternative; boundary=e89a8fb1f19685557904cd702d60 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnz+k3mNDWEJDrrP3D4GCjOk/D2Lx0sTIn5ZOV8cLqYI6coqCPSLypNYOlwll6NsuyCiE6pcc3oOPonUykC2P17jgbLfZtRSO6fnR7Z/IKkCRhv25OE+M0VUZu0LEeNMsX2ASKCvk8cbyCUKIPiKnnbS3gJddl8ut5f+QsUPsH0OtCRqeERypx/eAVDZE2+s+4o8bxH X-Mailman-Approved-At: Thu, 01 Nov 2012 08:02:35 -0700 Subject: Re: [apps-discuss] WebFinger compromises 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, 01 Nov 2012 14:53:12 -0000 --e89a8fb1f19685557904cd702d60 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Blaine entirely, but I'll add some commentary: On Thu, Nov 1, 2012 at 12:47 PM, Blaine Cook wrote: > This is great. It seems like there's largely consensus on ditching XML > (what do we need to do to convince you, Evan? My take is that the install= ed > base is easily converted as code is updated). Paul's new draft is vastly > simpler for it. The only thing I can imagine to simplify things further > (and possibly help the backwards compatibility question) would be to drop > the requirement for Accept headers altogether, and just use host-meta.jso= n. > > Since others (Brad, Dick) are advocating for the resource-less approach, > I'll reiterate my support for that approach. Failing that, we should have > only one approach. > Totally agreed, > The big problems as it stands: > > 1. Too much complexity in the spec. A casual reader, implementing > webfinger for the first time, will be confused. > 2. Too many conditionals required in fully-functional clients. A webfinge= r > client should ideally be implementable in just a few lines of code (i.e., > HTTP request, parse JSON, go). > An explicit example, mentioned elsewhere, is I don't think we should mention two host-meta endpoints in the webfinger spec. Pick one. Since we're saying only JSON is required and host-meta.json is already defined, let's just pick that one. Do not mention bare host-meta anywhere. If a server wants to implement all of RFC 6415 independently, that's fine. But WebFinger should use only a subset of 6415: just host-meta.json (a static document, without query parameters). > 3. Hosting is more complicated with "resource=3D". Ideally, server setup = for > a redirecting server could be: > > $ mkdir /var/www/.well-known > $ cd /var/www/.well-known; curl -O > http://myprovider.com/help/host-meta-template.json > > and done. At this point, I'd really like for Mike Jones or someone else > who was advocating for the resource parameter to reiterate why it's > necessary? > > Honestly, I don't care either way (resource or no), but would prefer *one= * > option to reduce overall complexity. I know it's not *much* complexity to > us, since we're all very familiar with the issues, but the reality is tha= t > every extra feature reduces our chances of adoption significantly. > Yes, it should go. host-meta isn't a search interface. Its sole eponymous feature is providing metadata about the host. Yes, that means two round-trips for the cold cache case. But it'll be just one or two-in-parallel in practice. - Brad > > On 1 November 2012 06:52, Paul E. Jones wrote: > >> Dick,**** >> >> ** ** >> >> Comments in this color:**** >> >> ** ** >> >> ** ** >> >> *From:* webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] *= On >> Behalf Of *Dick Hardt >> *Sent:* Thursday, November 01, 2012 1:35 AM >> *To:* webfinger@googlegroups.com >> *Cc:* public-fedsocweb@w3.org; apps-discuss@ietf.org >> *Subject:* Re: WebFinger compromises**** >> >> ** ** >> >> ** ** >> >> On Oct 31, 2012, at 9:16 PM, "Paul E. Jones" >> wrote:**** >> >> >> >> **** >> >> Brad,**** >> >> **** >> >> Comments in green: **** >> >> ** ** >> >> that is fairly random!**** >> >> >> >> **** >> >> PEJ: Yeah, so how do we get to that thing we can build on? Current >> requirements =E2=80=A6 bare bone =E2=80=A6 are:**** >> >> =C2=B7 Servers must support JSON, may support XRD (or TLV or wha= tever) >> **** >> >> ** ** >> >> Only one.**** >> >> ** ** >> >> PEJ: Only one is required. I=E2=80=99m not pushing for requiring another= , but we >> should be forward-looking and plan for the possibility that another form= at >> might be preferred one day, especially since two already exist today. W= e >> go forward with JRD, but always ask for it by name via Accept and specif= y >> the Content-Type clearly.**** >> >> >> >> **** >> >> =C2=B7 Servers must make /.well-known/host-meta and >> /.well-known/host-meta.json resources accessible**** >> >> ** ** >> >> Only one.**** >> >> ** ** >> >> PEJ: This is historical (last year) and I=E2=80=99d prefer one, too. If= nobody >> is using host-meta.json, then perhaps we get rid of it now? But, can we >> agree to write code properly and use the Accept header and Content-Type?= * >> *** >> >> >> >> **** >> >> =C2=B7 Servers must support the =E2=80=9Cresource=E2=80=9D param= eter**** >> >> ** ** >> >> Discuss.**** >> >> ** ** >> >> PEJ: Discuss what, exactly? This allows a single request/response, whic= h >> some argue makes or breaks WF.**** >> >> >> >> **** >> >> More than one has expressed a desire to be able to cache >> /.well-known/host-meta to speed processing of resource-specific queries.= * >> *** >> >> ** ** >> >> Early optimization in my opinion.**** >> >> ** ** >> >> PEJ: This has all been defined for years now. This optimization is some >> of the oldest stuff defined.**** >> >> >> >> **** >> >> **** >> >> Personally, I think we have the solution in hand. If I change one thing, >> there is somebody who will not be happy. **** >> >> ** ** >> >> Trying to please everyone leads to a mediocre standard. Have we not >> learned anything from Apple? Not having a keypad on a phone was going to >> make some people unhappy. Worked out well at the end of the day.**** >> >> ** ** >> >> PEJ: Yeah, but the problem is that I=E2=80=99m not the CEO who can just = dictate >> what gets done. Standards don=E2=80=99t work that way :-) >> >> **** >> >> As compromises go, I think we=E2=80=99ve done pretty well. I say that, = because I >> know one can build both a client and server implementation quite easily = and >> only one format they need to consider.**** >> >> ** ** >> >> Not true. The server needs to know both.**** >> >> ** ** >> >> PEJ: Server does not need to support anything other than JRD. That=E2= =80=99s >> stated more than once.**** >> >> ** ** >> >> Paul**** >> >> ** ** >> > > --e89a8fb1f19685557904cd702d60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= div>I agree with Blaine entirely, but I'll add some commentary:

On Thu, Nov 1, 2012 at 12:47 PM, Blaine Cook <romeda@gmail.com= > wrote:
This is great. It= seems like there's largely consensus on ditching XML (what do we need = to do to convince you, Evan? My take is that the installed base is easily c= onverted as code is updated). Paul's new draft is vastly simpler for it= . The only thing I can imagine to simplify things further (and possibly hel= p the backwards compatibility question) would be to drop the requirement fo= r Accept headers altogether, and just use host-meta.json.

Since others (Brad, Dick) are advocating for the resource-le= ss approach, I'll reiterate my support for that approach. Failing that,= we should have only one approach.

Totally agreed,
=C2=A0
T= he big problems as it stands:

1. Too much complexity in the spec. A casual reader, im= plementing webfinger for the first time, will be confused.
2. Too= many conditionals required in fully-functional clients. A webfinger client= should ideally be implementable in just a few lines of code (i.e., HTTP re= quest, parse JSON, go).

An explicit example, mentioned elsewhere, = is I don't think we should=C2=A0mention two host-meta endpoints in the = webfinger spec. =C2=A0Pick one. =C2=A0Since we're saying only JSON is r= equired and host-meta.json is already defined, let's just pick that one= . =C2=A0Do not mention bare host-meta anywhere.

If a server wants to implement all of RFC 6415 independ= ently, that's fine. =C2=A0But WebFinger should use only a subset of 641= 5: =C2=A0just host-meta.json (a static document, without query parameters).=
=C2=A0
3. Hosting is more complicated with "resource=3D". Ideally, = server setup for a redirecting server could be:

$ = mkdir /var/www/.well-known
$ cd /var/www/.well-known; curl -O http://myprovider.com/help/host-meta-template.json

and done. At this point, I'd really like for Mike J= ones or someone else who was advocating for the resource parameter to reite= rate why it's necessary?

Honestly, I don't= care either way (resource or no), but would prefer *one* option to reduce = overall complexity. I know it's not *much* complexity to us, since we&#= 39;re all very familiar with the issues, but the reality is that every extr= a feature reduces our chances of adoption significantly.

Yes, it should go.

host-meta isn't a search interface. =C2=A0Its sole eponymous feature = is providing metadata about the host.

Yes, that me= ans two round-trips for the cold cache case. =C2=A0But it'll be just on= e or two-in-parallel in practice.

- Brad
=C2=A0

On 1 November 2012 06:52, Paul E. = Jones <paulej@packetizer.com> wrote:

Dick,<= u>

=C2=A0

Comments in = this color:

=C2=A0

=C2=A0

From:= webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf = Of Dick Hardt
Sent: Thursday, November 01, 2012 1:35 AM
To: webfinger@googlegroups.= com
Cc: public-fedsocweb@w3.org; apps-discuss@ietf.org
Subject: Re: WebFinger compromises

=C2=A0

=C2=A0

On Oct 31, 2012= , at 9:16 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:<= /u>



Brad,

=C2=A0

Comments= in=C2=A0green:=C2=A0

=C2=A0

=

that is fairly random!



PEJ: Yeah, so h= ow do we get to that thing we can build on?=C2=A0 Current requirements =E2= =80=A6 bare bone =E2=80=A6 are:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Servers must = support JSON, may support XRD (or TLV or whatever)

=C2=A0

Only one.

<= p class=3D"MsoNormal">=C2=A0

PEJ: Only one is required. I=E2=80=99m not pushi= ng for requiring another, but we should be forward-looking and plan for the= possibility that another format might be preferred one day, especially sin= ce two already exist today.=C2=A0 We go forward with JRD, but always ask fo= r it by name via Accept and specify the Content-Type clearly.=



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= span>=C2=A0Servers must make /.wel= l-known/host-meta and /.well-known/host-meta.json resources accessible

=C2=A0

Only one.

=C2=A0

PEJ: This is historical (= last year) and I=E2=80=99d prefer one, too.=C2=A0 If nobody is using host-m= eta.json, then perhaps we get rid of it now?=C2=A0 But, can we agree to wri= te code properly and use the Accept header and Content-Type?<= /span>



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0Servers must sup= port the =E2=80=9Cresource=E2=80=9D parameter

=C2=A0

Discuss.

=C2=A0

PEJ: Discuss what, exactl= y?=C2=A0 This allows a single request/response, which some argue makes or b= reaks WF.



More than one has = expressed a desire to be able to cache /.well-known/host-meta to speed proc= essing of resource-specific queries.

=C2=A0

Early optimization in my opinion.=

=C2=A0

PEJ: This has all b= een defined for years now.=C2=A0 This optimization is some of the oldest st= uff defined.



=C2=A0<= /u>

Personally, I = think we have the solution in hand. If I change one thing, there is somebod= y who will not be happy.=C2=A0

=C2=A0

Trying to please everyone leads to a med= iocre standard. Have we not learned anything from Apple? Not having a keypa= d on a phone was going to make some people unhappy. Worked out well at the = end of the day.

=C2=A0=

PEJ:= Yeah, but the problem is that I=E2=80=99m not the CEO who can just dictate= what gets done.=C2=A0 Standards don=E2=80=99t work that way :-)

As compromises go, I think we=E2=80=99ve done prett= y well.=C2=A0 I say that, because I know one can build both a client and se= rver implementation quite easily and only one format they need to consider.=

=C2=A0

Not true. The server needs to know both.=

=C2=A0

PEJ: Server does not need= to support anything other than JRD.=C2=A0 That=E2=80=99s stated more than = once.

=C2=A0

Paul

=C2=A0



--e89a8fb1f19685557904cd702d60-- From dick.hardt@gmail.com Wed Oct 31 22:35: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 3727621F8527 for ; Wed, 31 Oct 2012 22:35:09 -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=[AWL=-0.000, 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 sNZH4T6rqrTv for ; Wed, 31 Oct 2012 22:35:08 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAC321F84EF for ; Wed, 31 Oct 2012 22:35:08 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so1483994pad.31 for ; Wed, 31 Oct 2012 22:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=VI4CE4+3rDSPKPZXDCHWU6J8F1Gmv60dZaNcqR01TEs=; b=Sngy7VDpTB+ohE3YiPoevf+EcOaUHwdPAUkYBhm3o8gqTQym1S4k/UevwNZxV/ACff 9nG9ogDukD+CcOOgkmzigQz3vwGnvKnU7NkLlYb31gsPQdPJW5vF6OXyAfY/Yme9D/nc KubE79VVXOgkUBInny9xhxJF7Wbop+PMQp8+hA8eIRioxXgcfYdZM1F6opOB3o8+cE0J BNJ6cmGq22/Ez7o8r9nsJQDrWVW0Gvl94UzBET/y60YNcUAKQ/+pOgF6IEMD69MRGWIe aD8u/zDwQjb0ZgJX8m7qb9Ya6A2MgPtiqAdIttC4mWK5XV/JOQTufmQGyCWoYZQKGIg4 moXQ== Received: by 10.66.90.36 with SMTP id bt4mr108248120pab.54.1351748104062; Wed, 31 Oct 2012 22:35:04 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id ru4sm3467356pbc.25.2012.10.31.22.34.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 22:35:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DC055B66-3C3C-4913-B4BB-7D91765829BA" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <00e201cdb7e7$a5a67390$f0f35ab0$@packetizer.com> Date: Wed, 31 Oct 2012 22:34:51 -0700 Message-Id: References: <00c401cdb7c0$55fe5eb0$01fb1c10$@packetizer.com> <00e201cdb7e7$a5a67390$f0f35ab0$@packetizer.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Thu, 01 Nov 2012 08:02:47 -0700 Cc: public-fedsocweb@w3.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger compromises 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, 01 Nov 2012 05:35:10 -0000 --Apple-Mail=_DC055B66-3C3C-4913-B4BB-7D91765829BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 31, 2012, at 9:16 PM, "Paul E. Jones" = wrote: > Brad, > =20 > Comments in green:=20 that is fairly random! > PEJ: Yeah, so how do we get to that thing we can build on? Current = requirements =85 bare bone =85 are: > =B7 Servers must support JSON, may support XRD (or TLV or = whatever) Only one. > =B7 Servers must make /.well-known/host-meta and = /.well-known/host-meta.json resources accessible Only one. > =B7 Servers must support the =93resource=94 parameter Discuss. > This means the vanilla client on the Internet will query only for = JSON. Client developers have mostly said they want the simplest = possible solution, which means most will send requests with the = =93resource=94 parameter.=20 As a resource developer, I want a simple solution as well. > More than one has expressed a desire to be able to cache = /.well-known/host-meta to speed processing of resource-specific queries. Early optimization in my opinion. > =20 > Personally, I think we have the solution in hand. If I change one = thing, there is somebody who will not be happy.=20 Trying to please everyone leads to a mediocre standard. Have we not = learned anything from Apple? Not having a keypad on a phone was going to = make some people unhappy. Worked out well at the end of the day. > As compromises go, I think we=92ve done pretty well. I say that, = because I know one can build both a client and server implementation = quite easily and only one format they need to consider. Not true. The server needs to know both. -- Dick --Apple-Mail=_DC055B66-3C3C-4913-B4BB-7D91765829BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Oct 31, 2012, = at 9:16 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:

 
Comments in green
PEJ: = Yeah, so how do we get to that thing we can build on?  Current = requirements =85 bare bone =85 are:
 Servers must support JSON, may support XRD (or TLV or = whatever)

= Only one.

 Servers must make /.well-known/host-meta and = /.well-known/host-meta.json resources = accessible

Only one.

 Servers must support the =93resource=94 = parameter

=
Discuss.

This means the vanilla = client on the Internet will query only for JSON.  Client developers = have mostly said they want the simplest possible solution, which means = most will send requests with the = =93resource=94 parameter.  =

As = a resource developer, I want a simple solution as = well.

More than one has = expressed a desire to be able to cache /.well-known/host-meta to speed = processing of resource-specific = queries.

<= div>Early optimization in my opinion.

 
Personally, I think we have the solution in = hand. If I change one thing, there is somebody who will not be = happy. 

Trying to please everyone leads to a mediocre standard. Have we = not learned anything from Apple? Not having a keypad on a phone was = going to make some people unhappy. Worked out well at the end of the = day.

As compromises go, I = think we=92ve done pretty well.  I say that, because I know one can = build both a client and server implementation quite easily and only one = format they need to = consider.

=
Not true. The server needs to know = both.

-- = Dick


= --Apple-Mail=_DC055B66-3C3C-4913-B4BB-7D91765829BA-- From joe.gregorio@gmail.com Wed Oct 31 09:20: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 5D5DC21F870F for ; Wed, 31 Oct 2012 09:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 s-8WM-1FTz05 for ; Wed, 31 Oct 2012 09:20:40 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4183021F8668 for ; Wed, 31 Oct 2012 09:20:39 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so1758786oag.31 for ; Wed, 31 Oct 2012 09:20:36 -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=yx6myq4dzd5ng5QWHB1KXeBRwV9bE+OVv5DqpJDjAKY=; b=oK6NUn38XUS/ureOe3/XwQjIGCax20fiy7magPksuc53DuMGTLuB+V8oETFDIN9b8u 4lG7iR3aMfzLDWiQ4gRb59pOoTPuVSCRZ6/oZ6h0ZsQXVBlcjsefNR1SqBX8X8P8SYGE alnO+6VZuP3wrctnriWEio7e6ZmF5rtDViufPzgO5r+aUGiC5oRM1DViVExuzQQ7khQ9 P/VMydqAVB7RWTu3I2IbOgHfezRmY5AGmu8GS0DTG04qEPvLKLjE1VRgwgXo5mtqDdrI YlndV20Cu4q/+zQAHU6/ozZ5U2plx9kdnZTKn+WITJfYD8MTi/65TZJWjJS4jABQLGJA 4D+w== MIME-Version: 1.0 Received: by 10.182.31.13 with SMTP id w13mr31209470obh.29.1351700436211; Wed, 31 Oct 2012 09:20:36 -0700 (PDT) Sender: joe.gregorio@gmail.com Received: by 10.76.84.101 with HTTP; Wed, 31 Oct 2012 09:20:36 -0700 (PDT) In-Reply-To: <50914952.7090100@stpeter.im> References: <22D799A3-D79C-47C4-B9B3-3FFD5146B35D@gmail.com> <50914952.7090100@stpeter.im> Date: Wed, 31 Oct 2012 12:20:36 -0400 X-Google-Sender-Auth: 5p4w-pogE42YRsLimjGsSMIECL0 Message-ID: From: Joe Gregorio To: webfinger@googlegroups.com Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 01 Nov 2012 08:03:02 -0700 Cc: public-fedsocweb@w3.org, "apps-discuss@ietf.org" , Dick Hardt Subject: Re: [apps-discuss] WebFinger compromises 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, 31 Oct 2012 16:35:20 -0000 On Wed, Oct 31, 2012 at 11:52 AM, Peter Saint-Andre wrote: > [ +cc apps-discuss@ietf.org given that the spec is now an > Internet-Draft... ] > > On 10/31/12 9:48 AM, Dick Hardt wrote: >> +1 on everything. >> >> A simple, easy to understand spec that solves the major use cases >> released soon is far superior to kitchen sink spec that solves all use >> cases that is released in a year. >> >> JSON only (if that is not obvious, you need to write some code this decade) >> >> 1 round trip vs 2 round. Pick one that is simple to implement. Let's not >> get caught up in optimization. Brad's comments below seem sane (as usual) Agreed, +1 to everything he said. -joe >> >> -- Dick >> >> >> On Oct 31, 2012, at 12:45 AM, Brad Fitzpatrick > > wrote: >> >>> To everybody who recently saw me rant about WebFinger in person >>> recently, hello again. >>> >>> To everybody else, a brief summary: >>> >>> -- I was an early WebFinger evangelist. I remember discussing it at >>> conferences for years before it sorta became a thing. I think I even >>> named it? >>> >>> -- I added Google's WebFinger support >>> (https://groups.google.com/group/webfinger/msg/e8df6402708841ea) >>> >>> -- I think it's critically important for the Internet to preserve >>> user@host.com hierarchical identifiers before >>> email gets too passe and we're stuck with single-namespaced walled >>> gardens. It's on us to make email-looking identifiers more useful to >>> compete with all the latest proprietary silo hotness, before the >>> people of the internet no longer recognize them. >>> >>> (trying to establish that I'm a friend here) >>> >>> That said, >>> >>> -- this is the slowest moving community ever (I accept part of the >>> blame here) >>> >>> -- can we please stop changing things? >>> >>> -- JSON, XRD, great, whatever. But let's just pick one. If JSON is >>> now the hotness, let's pick *only* JSON. Specs that say "X is >>> required but you can maybe do Y if you want to" just reek of political >>> compromise to gain a certain party's favor. Look at OpenID 2.0. (I >>> remember being sad about those political moves too, but I had lost the >>> energy to fight) >>> >>> -- My recommendation: just remove all mention of XRD from the latest >>> WebFinger spec. Yes, this is counter to my "please stop changing >>> things" bullet earlier. But WebFinger has a better chance of success >>> if it's a simple spec. And you're not breaking compatibility with >>> anybody because *nobody uses WebFinger*. >>> >>> -- 1 round trip, 2 round trips. Don't really care. 2 round trips keeps >>> the spec simpler and the 1st will be highly cacheable (Expires: >>> weeks), so it's 1 round trip in practice, but I won't fight (too much) >>> *optional* parameters in the 1st request to possibly skip the 2nd >>> request. It worries me, though. I'd rather see that optimization >>> added in a subsequent version of the spec, so all 1.0 implementations >>> have then shown that they're capable of performing the base algorithm. >>> I worry that too many servers will implement the optimization and >>> then lazy clients will become pervasive which only do one round trip, >>> thus making the "optional" optimization now de facto required for >>> servers. So I'd really rather drop that from the spec too. Let's add >>> it only later, once it's shown to be needed. As is, clients could >>> even fire off two HTTP requests in parallel to reduce latency, one for >>> host-meta and one optimistically for the presumed host-meta location >>> in cases of big hosts that rarely change, or expired cached host-meta >>> documents. >>> >>> I will continue to fight for Google's WebFinger support, but I'm not >>> the only one losing patience. >>> >>> Everybody please hurry up, simplify, then hurry up. I'll help however >>> I can. I'm not sure whether this was helpful. >>> >>> - Brad >>> >>> (If any of the above is offensive to my employer, I'm speaking as myself.) >>> >> > > > -- > Peter Saint-Andre > https://stpeter.im/ > > -- Joe Gregorio http://bitworking.org From barryleiba.mailing.lists@gmail.com Thu Nov 1 08:05: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 9A62921F8B8F for ; Thu, 1 Nov 2012 08:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.131 X-Spam-Level: X-Spam-Status: No, score=-103.131 tagged_above=-999 required=5 tests=[AWL=-0.154, 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 TXTogq6UI4AW for ; Thu, 1 Nov 2012 08:05:50 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2654C21F899D for ; Thu, 1 Nov 2012 08:05:49 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2078115lam.31 for ; Thu, 01 Nov 2012 08:05:48 -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=aO84BbO0zMo/5StFppsFLBquaPWHeqLD1Wssht3/Tvc=; b=jOhvkjSP1vTphwXmOSBS5Y1pi6ASegKBIcFzPcqDG66IZ3Si0sEmr09zYCCsB7V06N 2Hm8lSiFPnZcBqQmZXm0BN52DG70IlfpCJIBg5ZzFalINHTgUHh1JpQZbVcdIgc8h8j9 AF/LQp9RDeQPWP0bYiMTMcCTDLv6Lcp9jHeQmWpdg6d9XsLfivjW9Ghb00z1yqr/iprH SmGYhLPgYDEoK1ErW/80RzHrlFk1XIvum26ce+vs9qEd4yEEc0/gwixZP/0kl7fmLWx/ J1mgzijoiyGPmNBSbyiEu7jaaHO5cE7wPOPiFbq1Yc6GMDNEV6KWmv2xf3MuaFNpZiJk 1FNQ== MIME-Version: 1.0 Received: by 10.152.162.97 with SMTP id xz1mr37279639lab.38.1351782348600; Thu, 01 Nov 2012 08:05:48 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.99.131 with HTTP; Thu, 1 Nov 2012 08:05:48 -0700 (PDT) Date: Thu, 1 Nov 2012 11:05:48 -0400 X-Google-Sender-Auth: P6FSJpEcA52AJKblLKhXO2Ix164 Message-ID: From: Barry Leiba To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] The Nominating Committee needs your help 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, 01 Nov 2012 15:05:54 -0000 The following is an important message from the NomCom chair; please give the NomCom input for their consideration, as described below. --------------------------------------------------- The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 11. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org From Michael.Jones@microsoft.com Thu Nov 1 08:06: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 3CA8821F8DE1 for ; Thu, 1 Nov 2012 08:06:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsIBkFbd6Dtf for ; Thu, 1 Nov 2012 08:06:28 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id DF97F21F8DDF for ; Thu, 1 Nov 2012 08:06:27 -0700 (PDT) Received: from BL2FFO11FD006.protection.gbl (10.173.161.200) by BL2FFO11HUB009.protection.gbl (10.173.161.111) with Microsoft SMTP Server (TLS) id 15.0.545.8; Thu, 1 Nov 2012 15:06:25 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD006.mail.protection.outlook.com (10.173.161.2) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Thu, 1 Nov 2012 15:06:24 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Thu, 1 Nov 2012 15:06:15 +0000 From: Mike Jones To: "Paul E. Jones" , "apps-discuss@ietf.org" , "webfinger@googlegroups.com" Thread-Topic: [apps-discuss] An alteration to the WebFinger Spec Thread-Index: Ac23+u3YVAhN5wz+SoC7W4GHhl67bgAR3zEA Date: Thu, 1 Nov 2012 15:06:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366885CA3@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <011a01cdb7fb$bca72f80$35f58e80$@packetizer.com> In-Reply-To: <011a01cdb7fb$bca72f80$35f58e80$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366885CA3TK5EX14MBXC285r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(76104002)(54356001)(74502001)(47446002)(51856001)(33656001)(54316001)(49866001)(15202345001)(5343635001)(5343655001)(16406001)(44976002)(47736001)(53806001)(46102001)(47976001)(4396001)(512954001)(31966008)(50986001)(74662001)(76482001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0652EA5565 Subject: Re: [apps-discuss] An alteration to the WebFinger Spec 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, 01 Nov 2012 15:06:31 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366885CA3TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1! From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Paul E. Jones Sent: Wednesday, October 31, 2012 11:40 PM To: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: [apps-discuss] An alteration to the WebFinger Spec Folks, Here's a proposal that some might find acceptable and others will probably = love. It's just a proposal, so no bazookas, please, from those who will fi= nd it troubling ;-) http://hive.packetizer.com/users/paulej/internet-drafts/draft-ietf-appsawg-= webfinger-03-ALT.txt What I did with this text is the following: * Included all of the current -03 text (not yet published, but text = folks proposed on the list) * Removed every reference to XML and XRD * Stated that the default format for /.well-known/host-meta.json is = JRD * Stated that the default format for /.well-known/host-meta is imple= mentation-dependent, so clients MUST use the Accept header to explicitly re= quest the desired representation when using that resource (this is key to b= ackward/forward compatibility and proper use of HTTP and Accept) * Removed the "account link relation" section * Removed the interop considerations section, since some feel there = is no need and I think requiring use of "Accept" on host-meta will address = any interop concerns * Removed the XML appendix that gave some people heartburn This shaved off 6 pages of text, I think will still give us backward-compat= ibility for those who have asked for it, but more clearly positions JSON / = JRD as the only format developers need to worry with. Tell me what you think. Paul --_000_4E1F6AAD24975D4BA5B168042967394366885CA3TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1!

 

From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Wednesday, October 31, 2012 11:40 PM
To: apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: [apps-discuss] An alteration to the WebFinger Spec

 

Folks,

 

Here’s a proposal that some might find accepta= ble and others will probably love.  It’s just a proposal, so no = bazookas, please, from those who will find it troubling ;-)

 

http://hive.packeti= zer.com/users/paulej/internet-drafts/draft-ietf-appsawg-webfinger-03-ALT.tx= t

 

What I did with this text is the following:

·        Included all of the current -03 text (not ye= t published, but text folks proposed on the list)

·        Removed every reference to XML and XRD<= /o:p>

·        Stated that the default format for /.well-kn= own/host-meta.json is JRD

·        Stated that the default format for /.well-kn= own/host-meta is implementation-dependent, so clients MUST use the Accept h= eader to explicitly request the desired representation when using that reso= urce (this is key to backward/forward compatibility and proper use of HTTP and Accept)

·        Removed the “account link relationR= 21; section

·        Removed the interop considerations section, = since some feel there is no need and I think requiring use of “Accept= ” on host-meta will address any interop concerns

·        Removed the XML appendix that gave some peop= le heartburn

 

This shaved off 6 pages of text, I think will still = give us backward-compatibility for those who have asked for it, but more cl= early positions JSON / JRD as the only format developers need to worry with= .

 

Tell me what you think.

 

Paul

 

--_000_4E1F6AAD24975D4BA5B168042967394366885CA3TK5EX14MBXC285r_-- From ietfc@btconnect.com Thu Nov 1 08:25: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 03AD821F8E06 for ; Thu, 1 Nov 2012 08:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 qmDlYM0jsEbX for ; Thu, 1 Nov 2012 08:25:27 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id F057E21F8D90 for ; Thu, 1 Nov 2012 08:25:26 -0700 (PDT) Received: from mail6-co9-R.bigfish.com (10.236.132.241) by CO9EHSOBE036.bigfish.com (10.236.130.99) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Nov 2012 15:25:15 +0000 Received: from mail6-co9 (localhost [127.0.0.1]) by mail6-co9-R.bigfish.com (Postfix) with ESMTP id 1FEB04C014C; Thu, 1 Nov 2012 15:25:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT001.eurprd07.prod.outlook.com; RD:error; EFVD:FOP X-SpamScore: -27 X-BigFish: PS-27(zz9371I103dK542M1432I1418Izz1de0h1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h5a9h668h839hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h304l1155h) Received: from mail6-co9 (localhost.localdomain [127.0.0.1]) by mail6-co9 (MessageSwitch) id 1351783512420481_18953; Thu, 1 Nov 2012 15:25:12 +0000 (UTC) Received: from CO9EHSMHS017.bigfish.com (unknown [10.236.132.226]) by mail6-co9.bigfish.com (Postfix) with ESMTP id 5D4ADA0044; Thu, 1 Nov 2012 15:25:12 +0000 (UTC) Received: from AM2PRD0710HT001.eurprd07.prod.outlook.com (157.56.249.213) by CO9EHSMHS017.bigfish.com (10.236.130.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 1 Nov 2012 15:11:09 +0000 Received: from SN2PRD0710HT005.namprd07.prod.outlook.com (157.56.234.149) by pod51017.outlook.com (10.255.165.36) with Microsoft SMTP Server (TLS) id 14.16.233.3; Thu, 1 Nov 2012 15:11:08 +0000 Message-ID: <002201cdb843$09105f80$4001a8c0@gateway.2wire.net> From: t.petch To: Peter Saint-Andre , References: <508E9713.3030301@stpeter.im> Date: Thu, 1 Nov 2012 15:10:13 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.234.149] X-OriginatorOrg: btconnect.com Cc: 'Graham Klyne' Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 01 Nov 2012 15:25:28 -0000 ----- Original Message ----- From: "Peter Saint-Andre" To: Cc: "'Graham Klyne'" Sent: Monday, October 29, 2012 2:47 PM > > I see two open issues with draft-ietf-appsawg-acct-uri (which I think > we can resolve on the mailing list, thus saving precious meeting time > for topics that require realtime discussion): > > 1. In version -01, I think that I was too aggressive about trying to > simplify the ABNF, to wit: > > acctURI = "acct" ":" userinfo "@" host > > The userinfo rule allows the colon character ':', but I don't think > that's what we want here. Instead, I think we want: > > acctURI = "acct" ":" userpart "@" host > userpart = 1*( unreserved / pct-encoded / sub-delims ) > > If you disagree with that definition, please reply to this message. This definition bears a passing resemblance to that of an e-mail address, which makes me wonder whether or not the syntax should be aligned with that of e-mail with a reference thereto. I understand the change you have just made, but cannot see a rationale for it. It is not that I disagree with the definition but that I disagree with the reason for it, not knowing what that is. Tom Petch > 2. I would like to verify that the updated text about dereferencing > 'acct' URIs is sensible. That is (last paragraph of > draft-ietf-appsawg-acct-uri-01, section 3): > > Because an 'acct' URI enables identification only and not > interaction, it cannot be deferenced directly. Any protocol that > might use the 'acct' URI scheme, such as the WebFinger protocol > [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol > [I-D.jones-simple-web-discovery], is responsible for specifying how > an 'acct' URI is dereferenced in the context of that protocol. For > example, an 'acct' URI might be passed as a parameter in an HTTP > request and the service might retrieve the relevant information > associated with the account identified by that URI and then provide > that information to the requesting entity in an HTTP response. > > Thanks! > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > From evan@status.net Thu Nov 1 08:27: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 A088B21F8E15 for ; Thu, 1 Nov 2012 08:27:26 -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=[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 wu0AXhpfxDvS for ; Thu, 1 Nov 2012 08:27:25 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2A321F8E14 for ; Thu, 1 Nov 2012 08:27:25 -0700 (PDT) Received: from [192.168.69.113] (modemcable107.194-202-24.mc.videotron.ca [24.202.194.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 656D58D7362 for ; Thu, 1 Nov 2012 15:38:49 +0000 (UTC) Message-ID: <509294DB.8070208@status.net> Date: Thu, 01 Nov 2012 11:27:23 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: IETF Apps Discuss References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <50917B1E.1040508@status.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020008020603080402060104" Subject: [apps-discuss] Private fields in Webfinger output (was Re: webfinger privacy question/suggestion) 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, 01 Nov 2012 15:27:26 -0000 This is a multi-part message in MIME format. --------------020008020603080402060104 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12-10-31 05:38 PM, James M Snell wrote: > > > > The critical points here are A) a user should never be surprised about > what data a particular service provider is offering up about them and > B) a user should never be surprised about which services are offering > up data about them. I think we're on the same page. An example from Twitter (note: twitter.com doesn't yet support Webfinger). My account there has these scalar fields: * nickname - identifier, public * full name - public * location - self-reported, more like 'hometown'; *not* current lat/lon, public * bio - short self-description, public * homepage - public * email address - for alerts, private * telephone number - for SMS, private All the "public" fields are visible to unauthenticated users on my profile page; I can't selectively share them. The only way to hide them is to delete them entirely. "Private" fields are visible only to me and Twitter; I can't share them at all, with anyone, even if I want to. Given this app profile, I'd say that: * full name, location, bio, and homepage should be included in Webfinger output * there is no need for the user to grant additional permissions, opt-in or opt-out, to the service to include public data in the Webfinger output * email address and telephone number should not be included in Webfinger output * functional endpoints like OAuth request-token endpoint should be included * derived data like last login IP, exact-ish location (derived from IP), workplace (derived from email address), should not be included Is that about what you're thinking? I think there's a subtle spectrum of opinions on the public profile fields. * The service should never share any of the public profile fields. * The service should only share the public profile fields if the user opts in. * The service should only share the public profile fields if the user has not opted out. * The service should only share the public profile fields if it knows there's a client that's going to use it. * The service should share all public profile fields, in hopes that someone will find it useful. I'm probably on the end where if it's on the public profile page, it should be in the Webfinger output. I would disagree with the concept that, since Webfinger output is marginally easier to parse than the HTML of the profile page, it's dangerous to have the same data in JRD as in the HTML. For the private fields, I think there are some more interesting examples from LinkedIn or Facebook where users can selectively share some personal data like email address and phone numbers with other users, but it'd probably be good for us to worry about that later. -Evan --------------020008020603080402060104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 12-10-31 05:38 PM, James M Snell wrote:



The critical points here are A) a user should never be surprised about what data a particular service provider is offering up about them and B) a user should never be surprised about which services are offering up data about them.

I think we're on the same page. An example from Twitter (note: twitter.com doesn't yet support Webfinger). My account there has these scalar fields:
  • nickname - identifier, public
  • full name - public
  • location - self-reported, more like 'hometown'; not current lat/lon, public
  • bio - short self-description, public
  • homepage - public
  • email address - for alerts, private
  • telephone number - for SMS, private
All the "public" fields are visible to unauthenticated users on my profile page; I can't selectively share them. The only way to hide them is to delete them entirely.

"Private" fields are visible only to me and Twitter; I can't share them at all, with anyone, even if I want to.

Given this app profile, I'd say that:
  • full name, location, bio, and homepage should be included in Webfinger output
  • there is no need for the user to grant additional permissions, opt-in or opt-out, to the service to include public data in the Webfinger output
  • email address and telephone number should not be included in Webfinger output
  • functional endpoints like OAuth request-token endpoint should be included
  • derived data like last login IP, exact-ish location (derived from IP), workplace (derived from email address), should not be included
Is that about what you're thinking?

I think there's a subtle spectrum of opinions on the public profile fields.
  • The service should never share any of the public profile fields.
  • The service should only share the public profile fields if the user opts in.
  • The service should only share the public profile fields if the user has not opted out.
  • The service should only share the public profile fields if it knows there's a client that's going to use it.
  • The service should share all public profile fields, in hopes that someone will find it useful.
I'm probably on the end where if it's on the public profile page, it should be in the Webfinger output. I would disagree with the concept that, since Webfinger output is marginally easier to parse than the HTML of the profile page, it's dangerous to have the same data in JRD as in the HTML.

For the private fields, I think there are some more interesting examples from LinkedIn or Facebook where users can selectively share some personal data like email address and phone numbers with other users, but it'd probably be good for us to worry about that later.

-Evan
--------------020008020603080402060104-- From evan@status.net Thu Nov 1 08:55: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 973AD21F8F18 for ; Thu, 1 Nov 2012 08:55:22 -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=[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 xIbPRiGxDsr1 for ; Thu, 1 Nov 2012 08:55:21 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id E32B621F8A68 for ; Thu, 1 Nov 2012 08:55:20 -0700 (PDT) Received: from [192.168.69.113] (modemcable107.194-202-24.mc.videotron.ca [24.202.194.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 42C748D73A2 for ; Thu, 1 Nov 2012 16:06:41 +0000 (UTC) Message-ID: <50929B62.9060008@status.net> Date: Thu, 01 Nov 2012 11:55:14 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: IETF Apps Discuss References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <50917B1E.1040508@status.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050201030705020205080806" Subject: [apps-discuss] Using obfuscated resource identifiers for Webfinger (was Re: webfinger privacy question/suggestion) 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, 01 Nov 2012 15:55:22 -0000 This is a multi-part message in MIME format. --------------050201030705020205080806 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12-10-31 05:38 PM, James M Snell wrote: > > > > > Very straightforward really... Org A wishes to access information > about Org B's users without all the parties in between knowing what's > being requested. For example... IBM has their SmartCloud for Social > Business service.. which is essentially a multi-tenant hosted version > of our Connections product. We have third party ISV's that integrate > with that product and provide extended services to our customers. This > is just an example, but what I want is to be able to provide secure > Webfinger services so that those ISV's can access non-public > information about specific users. It's the same basic WF protocol but > with an added layer of security that the privacy and confidentiality > of potentially sensitive business relationships. > Let me see if I've got this. Let's say that a client wants to get Webfinger information about jasnell@company.example . They make an unauthenticated request like: GET /.well-known/host-meta.json?resource=acct:jasnell@company.example Host: company.example which generates a result like: HTTP/1.1 200 OK Content-Type: application/json { "subject": "acct:jasnell@company.example", "links": [ "rel": "http://webfinger.net/rel/profile-page", "href": "http://company.example/profiles/3008" ] } A malicious third-party attacker, observing this exchange, would know that an account "jasnell@company.example" exists and is valid, since the response came back with status code 200. They could then: 1. Make additional future requests to Webfinger about this account. 2. Try using the account ID as an email address (or XMPP address) and send it spam. Is that a fair characterization of the problem? There's also the information in the Webfinger results themselves. Presumably the attacker could get this public information again (the request wasn't authenticated, remember), but here they got it "silently", and didn't have to make their own request. That's a wee bit more advantage. It sounds like the ways we can mitigate the danger are: * Use HTTPS for the request. This would prevent (more or less?) third-party observers from seeing any of this request information. * Use an obfuscated identifier without authentication. This would prevent the attacker from re-using the identifier for email or XMPP, but they could still replay the request later. * Use an obfuscated identifier with authentication, and the identifier is tied to the requester. This would prevent both re-use for SMTP and replay over Webfinger. Is that about what you're asking for? Personally, I think specifying a way to use obscured identifiers is more trouble than just using HTTPS. But I acknowledge that there are some serious difficulties with using HTTPS (cost of certificates, use on virtual hosting or multi-homed systems). -Evan --------------050201030705020205080806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12-10-31 05:38 PM, James M Snell wrote:




Very straightforward really... Org A wishes to access information about Org B's users without all the parties in between knowing what's being requested. For example... IBM has their SmartCloud for Social Business service.. which is essentially a multi-tenant hosted version of our Connections product. We have third party ISV's that integrate with that product and provide extended services to our customers. This is just an example, but what I want is to be able to provide secure Webfinger services so that those ISV's can access non-public information about specific users. It's the same basic WF protocol but with an added layer of security that the privacy and confidentiality of potentially sensitive business relationships. 

Let me see if I've got this. Let's say that a client wants to get Webfinger information about jasnell@company.example . They make an unauthenticated request like:
    GET /.well-known/host-meta.json?resource=acct:jasnell@company.example
    Host: company.example
which generates a result like:
    HTTP/1.1 200 OK
    Content-Type: application/json

    {
	"subject": "acct:jasnell@company.example",
        "links": [
		"rel": "http://webfinger.net/rel/profile-page",
		"href": "http://company.example/profiles/3008"
        ]
    }
A malicious third-party attacker, observing this exchange, would know that an account "jasnell@company.example" exists and is valid, since the response came back with status code 200.

They could then:
  1. Make additional future requests to Webfinger about this account.
  2. Try using the account ID as an email address (or XMPP address) and send it spam.
Is that a fair characterization of the problem?

There's also the information in the Webfinger results themselves. Presumably the attacker could get this public information again (the request wasn't authenticated, remember), but here they got it "silently", and didn't have to make their own request. That's a wee bit more advantage.

It sounds like the ways we can mitigate the danger are:
  • Use HTTPS for the request. This would prevent (more or less?) third-party observers from seeing any of this request information.
  • Use an obfuscated identifier without authentication. This would prevent the attacker from re-using the identifier for email or XMPP, but they could still replay the request later.
  • Use an obfuscated identifier with authentication, and the identifier is tied to the requester. This would prevent both re-use for SMTP and replay over Webfinger.
Is that about what you're asking for?

Personally, I think specifying a way to use obscured identifiers is more trouble than just using HTTPS. But I acknowledge that there are some serious difficulties with using HTTPS (cost of certificates, use on virtual hosting or multi-homed systems).

-Evan

--------------050201030705020205080806-- From sm@resistor.net Thu Nov 1 09:11: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 C6BD021F8DAE for ; Thu, 1 Nov 2012 09:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 wvLsZvJbKZGg for ; Thu, 1 Nov 2012 09:11:25 -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 A229021F8DAD for ; Thu, 1 Nov 2012 09:11:25 -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 qA1GBKbj021858; Thu, 1 Nov 2012 09:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351786284; bh=iFoxqc4B91DxPkzM1HUEwblPjhv2AFXHmd9+0jOxw34=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZKzmjYAnY6TlvYoWm906nMrc6uYZXmUCn8ZCQ4u99J1MuBeI0/IAl4HbeyCSNw2er oYVfzMllAbHR8rYGycagOOGJPV4bjwlOWMIEI5fCvV3m3MNXBhojdg4tMZwOkgbsYa +mAA/Awlgc512AW5ZJe9RFTrE9vrFf9mZyJ5taYs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351786284; i=@resistor.net; bh=iFoxqc4B91DxPkzM1HUEwblPjhv2AFXHmd9+0jOxw34=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YqapQXnoNKOYpz9CE8w4mRXcXd3rb5OGL2O3GPAsNT8WFoha/LVhLdX3h5oD+I7Jy 5eMWi6beL2r2WhxjFBJjh5UoVUDKhfKyHqYMJIG1EGU8rIkhIS0V7y/P6lZOgJTQtF e7cqbUYY0vxW1n831K3kapCIp0UOfYIzZhd/xbxQ= Message-Id: <6.2.5.6.2.20121101080412.0b4a3890@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 Nov 2012 09:07:35 -0700 To: "Paul E. Jones" From: SM In-Reply-To: <000f01cdb79b$d4edf1b0$7ec9d510$@packetizer.com> References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net> <000f01cdb79b$d4edf1b0$7ec9d510$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] webfinger privacy question/suggestion 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, 01 Nov 2012 16:11:26 -0000 Hi Paul, At 12:13 31-10-2012, Paul E. Jones wrote: >No, but it is an open standards process where anyone can contribute text. >I've contributed text and I've tried to address the issues raised w.r.t. >privacy. If it is not sufficient, then I need to be told what to put in >there. Ok. >I think we should address post making info available and accessing it. How >is this: > > If one does not wish to share certain information with the world, > do not allow that information to be freely accessible through > WebFinger and do not use any service supporting WebFinger. > >That said, I do think it's going a bit far. Following this logic, we= should >go back and revise the DNS specs, too, to say "if one does not want the >world to know what one is accessing, do not use DNS." It's the same issue, >really. I agree that it would be going a bit too far to=20 add that text to the draft. I don't think that it is the same issue for= DNS. >This can certainly be said of Google advertising, for example. It can be >said of any web user habits, your email exchanges with me, blog posts, >comments on web sites, etc. WebFinger is just one more service like so= many >others. The only thing that is perhaps strikingly different is that with >WebFinger, one is publishing information about themselves in a concentrated >place. So, rather than visiting my home page to get some contact info, one >can query it via WebFinger in a nice automated way. This can be abused, of >course, but so can posting profile information in one's Facebook account. This is a general comment. It's not because the=20 world is stupid that I have to be stupid. The=20 point of having security or privacy=20 considerations is to "think about it". Quoting a=20 sentence from Phillip Hallam-Baker [1]: "Webfinger as currently designed is not going=20 to make the situation any worse, but it isn't going to make it better either." People can be realistic and argue that privacy is=20 not worth the bother as it is not going to make=20 any difference. I doubt that Google or Facebook=20 are going to use that argument in their responses=20 to the European Union. Quoting the Managing Director of Facebook: "The recent audit by the Irish DPC recognized that Facebook=92s current privacy practices go far beyond the existing legal requirements, which proves how seriously we take the issue." "=91Privacy=81 by=81 design=92 is an important principle which is= recognized in the Commission=92s proposal. It is also one of the core principles of Facebook's privacy programme:" It is convenient to have a protocol, e.g.=20 WebFinger, aggregate data and provide the=20 information in a nice automated way. As=20 mentioned above, there is a risk for abuse. I=20 doubt that the risk can be eliminated. Whether=20 the risk can be mitigated is still debatable. I=20 referred to "correlation" in=20 draft-iab-privacy-considerations-04 and asked=20 whether it was an issue [3]. If the answer of=20 the three authors of draft-ietf-appsawg-webfinger-02 is, for example: We tried to address the issue. If the text is=20 not adequate we need to be told what to add I can understand that. if the answer is: We are writing a technical specification and=20 not a treatise about social networks I can understand that too. If the answer is: "WebFinger is just one more service like so many others." I don't find it a convincing argument. Even=20 though it may not be the intent the argument=20 comes out as "we don't want to be bothered with=20 that or we do not want to do the work". Regards, -sm 1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07701.html 2.=20 http://www.europarl.europa.eu/document/activities/cont/201210/20121008ATT531= 82/20121008ATT53182EN.pdf 3. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07697.html= =20 From evan@status.net Thu Nov 1 09:19: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 59AF221F8E72 for ; Thu, 1 Nov 2012 09:19:03 -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=[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 dpk8vB2Cj84n for ; Thu, 1 Nov 2012 09:19:02 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id B25FA21F8E6F for ; Thu, 1 Nov 2012 09:19:02 -0700 (PDT) Received: from [192.168.69.113] (modemcable107.194-202-24.mc.videotron.ca [24.202.194.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 428638D728B for ; Thu, 1 Nov 2012 16:30:27 +0000 (UTC) Message-ID: <5092A0F4.6000702@status.net> Date: Thu, 01 Nov 2012 12:19:00 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: IETF Apps Discuss References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <50917B1E.1040508@status.net> <50929B62.9060008@status.net> In-Reply-To: <50929B62.9060008@status.net> Content-Type: multipart/alternative; boundary="------------040507070008080707060304" Subject: Re: [apps-discuss] Using obfuscated resource identifiers for Webfinger (was Re: webfinger privacy question/suggestion) 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, 01 Nov 2012 16:19:03 -0000 This is a multi-part message in MIME format. --------------040507070008080707060304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12-11-01 11:55 AM, Evan Prodromou wrote: > On 12-10-31 05:38 PM, James M Snell wrote: >> >> >> >> >> Very straightforward really... Org A wishes to access information >> about Org B's users without all the parties in between knowing what's >> being requested. For example... IBM has their SmartCloud for Social >> Business service.. which is essentially a multi-tenant hosted version >> of our Connections product. We have third party ISV's that integrate >> with that product and provide extended services to our customers. >> This is just an example, but what I want is to be able to provide >> secure Webfinger services so that those ISV's can access non-public >> information about specific users. It's the same basic WF protocol but >> with an added layer of security that the privacy and confidentiality >> of potentially sensitive business relationships. >> > [...] > A malicious third-party attacker, observing this exchange, would know > that an account "jasnell@company.example" exists and is valid, since > the response came back with status code 200. Actually, re-reading your description, it sounds like I might have mischaracterized the problem you're trying solve. You want it "so that those ISV's can access non-public information about specific users." I think that you could do this pretty well just using one of several HTTP authentication mechanisms (OAuth, Basic, Digest, client certs, ...). ISVs provision credentials out-of-band and then use those credentials in the Webfinger request to get more information. -Evan --------------040507070008080707060304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12-11-01 11:55 AM, Evan Prodromou wrote:
On 12-10-31 05:38 PM, James M Snell wrote:




Very straightforward really... Org A wishes to access information about Org B's users without all the parties in between knowing what's being requested. For example... IBM has their SmartCloud for Social Business service.. which is essentially a multi-tenant hosted version of our Connections product. We have third party ISV's that integrate with that product and provide extended services to our customers. This is just an example, but what I want is to be able to provide secure Webfinger services so that those ISV's can access non-public information about specific users. It's the same basic WF protocol but with an added layer of security that the privacy and confidentiality of potentially sensitive business relationships. 

[...]
A malicious third-party attacker, observing this exchange, would know that an account "jasnell@company.example" exists and is valid, since the response came back with status code 200.
Actually, re-reading your description, it sounds like I might have mischaracterized the problem you're trying solve. You want it "so that those ISV's can access non-public information about specific users."

I think that you could do this pretty well just using one of several HTTP authentication mechanisms (OAuth, Basic, Digest, client certs, ...). ISVs provision credentials out-of-band and then use those credentials in the Webfinger request to get more information.

-Evan

--------------040507070008080707060304-- From paulej@packetizer.com Thu Nov 1 09:19: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 279B121F8E9F for ; Thu, 1 Nov 2012 09:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.427, 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 GNSD0WDM9TGt for ; Thu, 1 Nov 2012 09:19:27 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 09CBB21F8E89 for ; Thu, 1 Nov 2012 09:19: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 qA1GJOaD013709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Nov 2012 12:19:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351786765; bh=/Iporj8d05a3fleVn17MMaNJITBrPm9KNMtzcadm/t8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Npuc/y/Gh8MF0JX9ICQGofs6qeEjpzk47WUDW4dDuTkZkT2UXP7q3vhJSibRmKMRN y5cuV9JMA8azIEef5mb/8p8UxgYL6xbuQvBCy5gYdanpsy8bEedN4J7P0+gynq86Ly KuTOZ25oqe2Aj1sDZ6Y9xkzmSmSvTdRANpJqst5Q= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" , References: <011a01cdb7fb$bca72f80$35f58e80$@packetizer.com> In-Reply-To: Date: Thu, 1 Nov 2012 12:19:31 -0400 Message-ID: <021b01cdb84c$acfd2930$06f77b90$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_021C_01CDB82B.25EB8930" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGOvx3J4VkqAJM7GNut5joo4XlPbAH+kVB6mEMdPvA= Content-Language: en-us Cc: public-fedsocweb@w3.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] An alteration to the WebFinger Spec 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, 01 Nov 2012 16:19:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_021C_01CDB82B.25EB8930 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Comments below: =20 =20 * Delete the whole section "4.2. Simplifying the Login Process". As = much as I loves me some OpenID, it's out of place in this document. =20 PEJ: OK. It is only an example, so it can be removed. Is there a = different example you would like to see, or are the other two = sufficient?=20 =20 * WebFinger, being JSON-only, should only document = /.well-known/host-meta.json as part of the client's discovery process, not /.well-known/host-meta. Status.net and whoever else can continue to serve webfinger for = compatibility at /.well-known/host-meta if they'd like to support all of RFC 6415. = But WebFinger doesn't need to include docs on supporting all of RFC 6415. = It should be possible to write a server which is WebServer compliant = without being 6415 compliant. =20 PEJ: Given we are not deprecating RFC 6415, that seems like a reasonable = compromise. A server could still support both, but anything that is = officially =E2=80=9CWebFinger=E2=80=9D will use only the .json resource. = I=E2=80=99ll remove host-meta and post an updated =E2=80=9Calt=E2=80=9D = spec shortly. =20 * Section 5.2: ditch the rel=3D, resource=3D parameters from = host-meta.json. It's a HOST meta, not a RESOURCE meta. It's being morphed into an all-encompassing endpoint. If you really want this, DO NOT REUSE = host-meta and just use /.well-known/webfinger-query. But I am not proposing = that. I'm just saying that would be more sane than tacking random crap onto host-meta. =20 PEJ: I think this one might be more challenging. There is a camp that = likes the RFC 6415-way of doing things with a host-meta document and = then an LRDD resource. Then there is the other camp who says =E2=80=9CI = want the simplest possible client and want to issue exactly one query, = period.=E2=80=9D The =E2=80=9Crel=E2=80=9D parameter allows server-side = filtering in the event the response might be voluminous; this reduces = client-side processing work. I let the camps battle this one, but I can = see good arguments on both sides. =20 * Section 6. MUST support CORS, but MAY exclude the header. What? SHOULD = probably. =20 PEJ: WebFinger servers that serve the public (Internet) MUST use CORS; = enterprise WebFinger servers are not required to do so. That was the = consensus of the group thus far and there are several who have demanded = CORS support. =20 * Section 8.1: "When a query is issued host-meta" ... "pointing to the = location=20 of the hosted WebFinger service URL" host-meta is its own thing. You = are assuming that host-meta means WebFinger. =20 PEJ: I=E2=80=99m not following what you=E2=80=99re saying. The text = says =E2=80=9CWhen a query is issued to /.well-known/host-meta.json, the = target domain=E2=80=99s web server MUST return a 301, 302, or 307 = =E2=80=A6 pointing to=E2=80=A6=E2=80=9D. I=E2=80=99m making no = assumptions, just specifying how resources must be redirected to enable = a service provider to provide the services on behalf the domain. =20 =20 I might have more minor feedback later, but the above is most of it. =20 PEJ: Hold that for -ALT-R1 :-) =20 Paul =20 ------=_NextPart_000_021C_01CDB82B.25EB8930 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Comments below:

 

 

* Delete the = whole section "4.2. Simplifying the Login Process".  As = much as

  I = loves me some OpenID, it's out of place in this = document.

 

PEJ: OK.=C2=A0 It is only an example, so it can be removed. Is = there a different example you would like to see, or are the other two = sufficient?

 

* WebFinger, = being JSON-only, should only document = /.well-known/host-meta.json

  as = part of the client's discovery process, not = /.well-known/host-meta.

  = Status.net and whoever else can continue to serve webfinger for = compatibility

  at = /.well-known/host-meta if they'd like to support all of RFC 6415. =  But

  = WebFinger doesn't need to include docs on supporting all of RFC 6415. =  It

  = should be possible to write a server which is WebServer compliant = without

  being = 6415 compliant.

 

PEJ: Given we are not deprecating RFC 6415, that seems like a = reasonable compromise.=C2=A0 A server could still support both, but = anything that is officially =E2=80=9CWebFinger=E2=80=9D will use only = the .json resource.=C2=A0 I=E2=80=99ll remove host-meta and post an = updated =E2=80=9Calt=E2=80=9D spec = shortly.

 

* Section = 5.2: ditch the rel=3D, resource=3D parameters from = host-meta.json.

  It's = a HOST meta, not a RESOURCE meta.  It's being morphed into = an

  = all-encompassing endpoint.  If you really want this, DO NOT REUSE = host-meta

  and = just use /.well-known/webfinger-query.  But I am not proposing = that.

  I'm = just saying that would be more sane than tacking random crap = onto

  = host-meta.

 

PEJ: I think this one might be more challenging.=C2=A0 There is a = camp that likes the RFC 6415-way of doing things with a host-meta = document and then an LRDD resource.=C2=A0 Then there is the other camp = who says =E2=80=9CI want the simplest possible client and want to issue = exactly one query, period.=E2=80=9D=C2=A0 The =E2=80=9Crel=E2=80=9D = parameter allows server-side filtering in the event the response might = be voluminous; this reduces client-side processing work.=C2=A0 I let the = camps battle this one, but I can see good arguments on both = sides.

 

* Section 6. = MUST support CORS, but MAY exclude the header. What? SHOULD = probably.

 

PEJ: WebFinger servers that serve the public (Internet) MUST use = CORS; enterprise WebFinger servers are not required to do so.=C2=A0 That = was the consensus of the group thus far and there are several who have = demanded CORS support.

 

* Section = 8.1: "When a query is issued host-meta" ... "pointing to = the location 

  of = the hosted WebFinger service URL"  host-meta is its own thing. =  You are

  = assuming that host-meta means = WebFinger.

 

PEJ: I=E2=80=99m not following what you=E2=80=99re saying.=C2=A0 = The text says =E2=80=9CWhen a query is issued to = /.well-known/host-meta.json, the target domain=E2=80=99s web server MUST = return a 301, 302, or 307 =E2=80=A6 pointing to=E2=80=A6=E2=80=9D.=C2=A0 = I=E2=80=99m making no assumptions, just specifying how resources must be = redirected to enable a service provider to provide the services on = behalf the domain.=C2=A0

 

I might have = more minor feedback later, but the above is most of = it.

 

PEJ: Hold that for -ALT-R1 :-)

 

Paul

 

------=_NextPart_000_021C_01CDB82B.25EB8930-- From paulej@packetizer.com Thu Nov 1 09:39: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 9B00721F8CB3 for ; Thu, 1 Nov 2012 09:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.412, 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 m0sznYeU8kSy for ; Thu, 1 Nov 2012 09:39:20 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 76EB521F8D5A for ; Thu, 1 Nov 2012 09:39:20 -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 qA1GdJgh014630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Nov 2012 12:39:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351787959; bh=3KW0Mw0DAYKxed9bxNgLHxe25Dd1avvJH3sUCQOMyhA=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=l14UHWOQKoB+rcyYFI3P6S4ML+1snyBXwb6ct8EIT6yxlYysoBgxpRzRHggP2GIVx UPUe6lQ4yvMcTatm1UFy835ZH4vQKEb82vHIgADRuDTrfSqHfpFm9J1G9ikW8zlmKF pcKKRQeDTe4505qMY8Tf1ctyLEaio4vm2v2PdoU8= From: "Paul E. Jones" To: , , Date: Thu, 1 Nov 2012 12:39:26 -0400 Message-ID: <023f01cdb84f$74f394e0$5edabea0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0240_01CDB82D.EDE1F4E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac24TocJ+SHO9WVFRLSAwu/wovX+LA== Content-Language: en-us Subject: [apps-discuss] WebFinger Draft - Alternate -01 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, 01 Nov 2012 16:39:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0240_01CDB82D.EDE1F4E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, Trying to accommodate all requests for simplification, I now have this draft up for consideration: http://hive.packetizer.com/users/paulej/internet-drafts/draft-ietf-appsawg-w ebfinger-03-ALT-R1.txt This removes the /.well-known/host-meta resource and focuses only on /.well-known/host-meta.json. I also removed the OpenID example (former section 4.2). There still seems to be some debate on the merit of the "resource" and "rel" parameters. Some people want to have a simple client that can make a single request and get a single response, while others want to query to get host-meta information (not resource-specific info) and also want to be able to cache that reply. So, they are still in this draft. Now, down to 19 pages with examples, boilerplate material, references, etc. Comments welcome. Paul ------=_NextPart_000_0240_01CDB82D.EDE1F4E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Trying to = accommodate all requests for simplification, I now have this draft up = for consideration:

http://hive.packetizer.com/users/paule= j/internet-drafts/draft-ietf-appsawg-webfinger-03-ALT-R1.txt

 

This removes the /.well-known/host-meta resource and = focuses only on /.well-known/host-meta.json.  I also removed the = OpenID example (former section 4.2).

 

There still = seems to be some debate on the merit of the “resource” and = “rel” parameters.  Some people want to have a simple = client that can make a single request and get a single response,  = while others want to query to get host-meta information (not = resource-specific info) and also want to be able to cache that = reply.  So, they are still in this draft.

 

Now, down to = 19 pages with examples, boilerplate material, references, = etc.

 

Comments welcome.

 

Paul

 

------=_NextPart_000_0240_01CDB82D.EDE1F4E0-- From joe.gregorio@gmail.com Thu Nov 1 10:40: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 E081D21F8EFE for ; Thu, 1 Nov 2012 10:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.057, 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 IbTeGsDzGYAG for ; Thu, 1 Nov 2012 10:40:37 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7D721F8E53 for ; Thu, 1 Nov 2012 10:40:37 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so1243517eaa.31 for ; Thu, 01 Nov 2012 10:40:36 -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 :content-transfer-encoding; bh=QYr5gNMtbHxJa83GAKfXlN+V7hIYZ6YDSdCzu0Mg0y8=; b=ufNEg09KWeAyRlMCYaI+KjTDP3oampZ/cIARUCFnsjlcIiBhGvC1xKZDWrTLDjH6+x GDcDkte1s5wmiWUpyXiUBitmVKjMc5m/F9XbJlxU+Z6i07j6f/R+/RVwN0b6m3/1tVA6 vXr/ls+tEybZZBqoYJ6i5mQFIsDCbfYwMaiySw7p1l5EYQGsEtKRPgW5vXSPVow45DNK kcOikLJjSYXdRsc4/tX372z91JDnfXZkWb7E8LpxkNSvvXO2xca8QQJxMpLVK5tZeM2V dUIkhPpXRRgAMN/uktOGDEU+DqcJwCqOVOF9OSDDb4rXpF/0N5FuRHRqx2Jnc56VG5dN H8LQ== MIME-Version: 1.0 Received: by 10.14.194.2 with SMTP id l2mr100067964een.12.1351791636430; Thu, 01 Nov 2012 10:40:36 -0700 (PDT) Sender: joe.gregorio@gmail.com Received: by 10.223.75.199 with HTTP; Thu, 1 Nov 2012 10:40:36 -0700 (PDT) In-Reply-To: <1351737592.16591.YahooMailNeo@web31807.mail.mud.yahoo.com> References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <005f01cdb7b0$010fc430$032f4c90$@packetizer.com> <1351737592.16591.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Thu, 1 Nov 2012 13:40:36 -0400 X-Google-Sender-Auth: Aw3VaGoi_hjQU-8nJF5QhvJ3llo Message-ID: From: Joe Gregorio To: William Mills Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] webfinger privacy question/suggestion 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, 01 Nov 2012 17:40:39 -0000 On Wed, Oct 31, 2012 at 10:39 PM, William Mills wrot= e: > While I agree with the privacy language and drive toward being completely > aware of this I think it's unrealistic to put too much verbiage in on wha= t > would be a company terms of service or privacy policy. +1, a protocol should not come with a terms of service. > > ________________________________ > From: James M Snell > To: Paul E. Jones > Cc: IETF Apps Discuss > Sent: Wednesday, October 31, 2012 2:56 PM > > Subject: Re: [apps-discuss] webfinger privacy question/suggestion > > > On Wed, Oct 31, 2012 at 2:38 PM, Paul E. Jones > wrote: > > James, > > HTTPS is recommended and shown throughout the document. We do not say TL= S, > as HTTPS implies that. > > > From the security considerations, I see... > > "Of particular importance is the recommended use of HTTPS to ensure that > information is not modified during transit. Clients should verify that th= e > certificate used on an HTTPS connection is valid." > > Why not make this a "SHOULD use HTTPS" (note the capitalized SHOULD) and > provide a normative reference to TLS? Why not make use of TLS the default= ? > Showing it in examples without a strong normative recommendation or > requirement is a good way to have it ignored or supported as an > afterthought. > > > > In the security section at the end of =93Service providers and users=85= =94 how > about this? > > Further, WebFinger servers MUST NOT be used to provide any personal > information to any party unless authorized by the person whose informatio= n > is being shared. > > > > Perhaps something along the lines of... > > "Further, WebFinger servers MUST NOT be used to provide any personal > information to any party unless explicitly or implicitly authorized by th= e > person whose information is being shared. Implicit authorization can be > determined by the users voluntary utilization of a service as defined by > that service's relevant terms of use or published privacy policy." > > Would have to fiddle with the wording there but basically... if a user is > voluntarily providing their information to a service that makes it know i= n > advance what information is going to be provided via WebFinger (e.g. with= in > a Terms of Service or Privacy Policy document) then we're good. Again, to > reiterate the point I made in another note, a user should never be surpri= sed > what information is being shared and by whom. > > > As a final paragraph in that section, how about this? > > Finally, a WebFinger server has no means of ensuring that information > provided by a user is accurate. Likewise, neither the server nor the cli= ent > can be absolutely guaranteed that information has not been manipulated > either at the server or along the communication path between the client a= nd > server. Use of HTTPS helps to address some concerns with manipulation of > information along the communication path, but it clearly cannot address > issues where the server provided incorrect information, either due to bei= ng > provided false information or due to malicious behavior on the part of th= e > server administrator. As with any information service available on the > Internet, users should wary of information received from untrusted source= s. > > > > That works. > > - James > > > Paul > > From: James M Snell [mailto:jasnell@gmail.com] > Sent: Wednesday, October 31, 2012 12:32 PM > To: Paul E. Jones > Cc: IETF Apps Discuss; Hannes Tschofenig; SM > > Subject: Re: [apps-discuss] webfinger privacy question/suggestion > > Ordinarily I would provide a suggestion of alternative text but I've been > tied up on a few other matters. That said, a few notes... > The basic protocol itself is fine.. the way that the current resource > parameter is defined, I could in theory use a uri scheme that allows me t= o > hash the identifier without requiring changes to the basic protocol itsel= f. > That itself is not so much of a problem. > What is a problem, however, is that you've mentioned a few times that TLS > could provide the necessary privacy control but there does not appear to = be > any mention at all of TLS within the specification document. It really > should be called out as a specific recommendation in the text. > I also note that while you do cover some of the privacy issues in the > security considerations, one point could stand to be made clearer: WebFin= ger > should only be used to expose information the subject has explicitly opte= d > in to be shared. Or put another way, WebFinger MUST NOT be used to provid= e > information to any party the subject has not explicitly authorized. This = is > loosely implied by the current text but, unless I missed it, you never ju= st > come out and say it. > A couple other points that come to mind when re-reading the security > considerations... > 1. There is nothing said about the validity and authenticity of the data > returned. There does not have to be an exhaustive discussion on this matt= er, > of course, but currently the protocol makes no guarantees and provides no > mechanisms for assuring that the information returned for a given user is > authentic, authoritative or valid in any way. It should at least be noted > that such mechanisms are out of the scope of the WebFinger protocol. > 2. A cryptographic hashed identifier could help prevent correlation style > breaches in privacy if the hash is generated based on a shared secret key > tied to the requesters authenticated identity. That is, if a WebFinger > server requires authentication to request data, the requester can generat= e > an hmac, for instance, using a shared secret key and specify that within = the > URI request. Used in combination with TLS, for example, this would provid= e a > reasonable assurance of privacy between the requester and the service > provider, keeping prying eyes in the middle from knowing whose informatio= n > is being requested. Again, it is possible to do with currently without an= y > changes to the WF protocol as defined so no normative changes would be > necessary, but it might be worthwhile to draw out as an informative examp= le. > - James > On Oct 30, 2012 5:48 PM, "Paul E. Jones" wrote: > That's not an entirely true statement. See: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#section-11 > > Question is whether that is sufficient. Thus far, I've not received any > additional text. > > Paul > >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of SM >> Sent: Tuesday, October 30, 2012 1:19 PM >> To: Hannes Tschofenig >> Cc: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] webfinger privacy question/suggestion >> >> At 03:16 30-10-2012, Hannes Tschofenig wrote: >> >Have a look at: http://tools.ietf.org/html/draft-iab-privacy- >> considerations-04 >> >> Hmm, that draft was mentioned several months ago [1]. >> >> >I have raised these privacy issues already last year. My comments got >> ignored. >> >> The following question was asked around 11 months ago [2]: >> >> "What are you planning to do to ensure the draft properly addresses >> security, privacy, and netiquette issues?" >> >> The current plan seems to be: do nothing. >> >> Regards, >> -sm >> >> 1. http://www.ietf.org/mail-archive/web/apps- >> discuss/current/msg04747.html >> 2. http://www.ietf.org/mail-archive/web/apps- >> discuss/current/msg03804.html >> >> _______________________________________________ >> 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 Joe Gregorio http://bitworking.org From laurentwalter.goix@telecomitalia.it Fri Nov 2 05:02: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 0F9AE21F99D4 for ; Fri, 2 Nov 2012 05:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.312 X-Spam-Level: X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[AWL=1.406, 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 1G4y9DUF2hNp for ; Fri, 2 Nov 2012 05:02:34 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id EE74F21F99BF for ; Fri, 2 Nov 2012 05:02:33 -0700 (PDT) Content-Type: multipart/mixed; boundary="_4db24748-84d5-4b2b-895e-121d10bc533a_" 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.279.5; Fri, 2 Nov 2012 13:02:30 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Fri, 2 Nov 2012 13:02:30 +0100 From: Goix Laurent Walter To: "apps-discuss@ietf.org" Date: Fri, 2 Nov 2012 13:02:28 +0100 Thread-Topic: High-level considerations about "webfinger" Thread-Index: Ac248e42GvCeed0CRAm/3rU9gysZbA== Message-ID: 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 Subject: [apps-discuss] High-level considerations about "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, 02 Nov 2012 12:02:38 -0000 --_4db24748-84d5-4b2b-895e-121d10bc533a_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A50F6C4DGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A50F6C4DGRFMBX704BA02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I tried to catch up with the hot discussion of the last days and would try = to hold on for the time of an email trying to summarize the current situati= on and take a breath... At this stage we are having very distinct camps in the list for what they h= ave in mind behind the "webfinger" keyword: xml vs json, 1 or 2 roundtrips,= privacy ecc. It seems to me that Paul has been doing an outstanding work t= rying to compromise (I would have lost patience...) but such compromises do= not seem to satisfy anyone: actually, compromises are moving more and more= towards the original SWD idea at the end. Maybe we could ask ourselves the following questions: - With the "xrd" idea in mind (please, jrd-enthusiasts, try to put= that hat on as well), what is actually missing beyond rfc6415 for "webfing= er"? now the 'acct' URI is a separate draft (an initial motivation). Rel/re= source parameters for xrd supporters do not seem essential in my understand= ing neither. So (although I am a supports of that camp) I have trouble seei= ng what truly need to be added. I can understand Evan's position for keepin= g the entire xrd-based community (ostatus, diaspora, etc) but isn't rfc6415= -compliance for those existing implementations already fair enough? If a ne= w "webfinger" is jrd, 1-roundtrip only at the end it's just another rfc num= ber to be referenced instead/in addition and as such has the same value...(= not mentioning the implementation work needed) - Rfc6415-compliance & backward compatibility: this seems also con= tentious as whether backward-compatibility is needed or not. however the cu= rrent "compromises" are odd in maintaining backward-compability. What is ex= actly interesting for "webfinger" from that rfc? From the latest alternativ= e it seems only the "host-meta.json" endpoint name & the jrd. Or else? How = these can be referenced at best without needing the whole thing? - Host-meta+lrdd vs new endpoint: Should we propose an alternative= endpoint name (there were many proposals, including one of mine a while ag= o) so that we simply "distinguish" the existing host-meta+lrdd way from a n= ew "webfinger" way/endpoint all-in-1-roundtrip. This is what swd is proposi= ng. Eventually one could at the end use the same backend implementation to = return queries coming all the way from host-meta+lrdd than others using ano= ther well-known (and direct) endpoint. This would also be much easier to su= pport any query parameter (resource, rel, etc) as some are arguing against = overriding host-meta with parameters. In that case the new "webfinger" woul= d be actually more like SWD (with JRD support) - In alternative, what about the provocative idea from Evan to "re= place" rfc6415? Are they other usages of rfc6415 than the "webfinger" one t= hroughout the community? If yes, then it may be more difficult to replace u= nless agreed with whom is using it. Otherwise, as it seems most people do n= ot like it, why keep it as-is and not upgrade directly to whatever is now u= seful? A standard that is not used is useless and has no point in being sup= erseded by a parallel spec not actually obsoleting it... If JRD and the wel= l-known endpoints are useful in other context, then why not splitting them = from the actual protocol procedures of current rfc6415 and have clean specs= that can be generically referenced without buying the full thing or writin= g complex text to select some parts of it and contest others: 1 for JRD and= 1 for the endpoints/link registrations. Then a protocol-oriented spec like= webfinger can easily decide what to take and replace current rfc6415, or d= ecide to live separately/parallel. Personally I have more interest and feeling for the 2-roundtrip xrd solutio= n from rfc6415 still. But if I have to choose between an odd/partial/unstab= le/unclear/buggy reference to it and a new json way for satisfying another = use case I have to put limits in compromising and at this point prefer a pa= rallel/independent approach. Of course I'd like possibly to reuse the file = format (jrd) as it seems suitable for all. At least this way rfc6415 can st= ill live independently (being updated or not if we want to make it "cleaner= ") and "webfinger" can hopefully be finalized quickly in the json + 1 round= trip direction... Once these macro topics are clarified then we can better discuss the detail= s about securing wf, supporting privacy, distinct delivery for auth/non-aut= h requests etc...But can we first discuss at high level what we want to ach= ieve in terms of process? Cheers walter 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 ? necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE53A50F6C4DGRFMBX704BA02_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I tried to catch up with the ho= t discussion of the last days and would try to hold on for the time of an e= mail trying to summarize the current situation and take a breath…

 

At this stage we are having ver= y distinct camps in the list for what they have in mind behind the “w= ebfinger” keyword: xml vs json, 1 or 2 roundtrips, privacy ecc. It se= ems to me that Paul has been doing an outstanding work trying to compromise (I would have lost patience…) but such com= promises do not seem to satisfy anyone: actually, compromises are moving mo= re and more towards the original SWD idea at the end.

 

Maybe we could ask ourselves th= e following questions:

-  = ;        With the “xrdR= 21; idea in mind (please, jrd-enthusiasts, try to put that hat on as well),= what is actually missing beyond rfc6415 for “webfinger”? now t= he ‘acct’ URI is a separate draft (an initial motivation). Rel/resource parameters for xrd supporters do not seem essential in my und= erstanding neither. So (although I am a supports of that camp) I have troub= le seeing what truly need to be added. I can understand Evan’s positi= on for keeping the entire xrd-based community (ostatus, diaspora, etc) but isn’t rfc6415-compliance for those exis= ting implementations already fair enough? If a new “webfinger” = is jrd, 1-roundtrip only at the end it’s just another rfc number to b= e referenced instead/in addition and as such has the same value…(not mentioning the implementation work needed)

 =

-  = ;        Rfc6415-compliance &= ; backward compatibility: this seems also contentious as whether backward-c= ompatibility is needed or not. however the current “compromises”= ; are odd in maintaining backward-compability. What is exactly interesting for “webfinger” from that rfc? From the= latest alternative it seems only the “host-meta.json” endpoint= name & the jrd. Or else? How these can be referenced at best without n= eeding the whole thing?

 =

-  = ;        Host-meta+lrdd vs n= ew endpoint: Should we propose an alternative endpoint name (there were man= y proposals, including one of mine a while ago) so that we simply “di= stinguish” the existing host-meta+lrdd way from a new “webfinger” way/endpoint all-in-1-roundtrip. This is wha= t swd is proposing. Eventually one could at the end use the same backend im= plementation to return queries coming all the way from host-meta+lrdd t= han others using another well-known (and direct) endpoint. This would also be much easier to support any query parameter (r= esource, rel, etc) as some are arguing against overriding host-meta with pa= rameters. In that case the new “webfinger” would be actually mo= re like SWD (with JRD support)

 =

-  = ;        In alternative, what ab= out the provocative idea from Evan to “replace” rfc6415? Are th= ey other usages of rfc6415 than the “webfinger” one throughout = the community? If yes, then it may be more difficult to replace unless agreed with whom is using it. Otherwise, as it seems most people do= not like it, why keep it as-is and not upgrade directly to whatever is now= useful? A standard that is not used is useless and has no point in being s= uperseded by a parallel spec not actually obsoleting it... If JRD and the well-known endpoints are useful i= n other context, then why not splitting them from the actual protocol proce= dures of current rfc6415 and have clean specs that can be generically refer= enced without buying the full thing or writing complex text to select some parts of it and contest others: 1 f= or JRD and 1 for the endpoints/link registrations. Then a protocol-oriented= spec like webfinger can easily decide what to take and replace current rfc= 6415, or decide to live separately/parallel.

 =

 =

Personally I have more interest= and feeling for the 2-roundtrip xrd solution from rfc6415 still. But if I = have to choose between an odd/partial/unstable/unclear/buggy reference to i= t and a new json way for satisfying another use case I have to put limits in compromising and at this point pr= efer a parallel/independent approach. Of course I’d like possibly to = reuse the file format (jrd) as it seems suitable for all. At least this way= rfc6415 can still live independently (being updated or not if we want to make it “cleaner”) and = 220;webfinger” can hopefully be finalized quickly in the json + 1= roundtrip direction…

 

Once these macro topics are cla= rified then we can better discuss the details about securing wf, supporting= privacy, distinct delivery for auth/non-auth requests etc…But can we= first discuss at high level what we want to achieve in terms of process?

 

Cheers

walter

= 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 è necessario.

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A50F6C4DGRFMBX704BA02_-- --_4db24748-84d5-4b2b-895e-121d10bc533a_ 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= --_4db24748-84d5-4b2b-895e-121d10bc533a_-- From evan@status.net Fri Nov 2 08:04: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 9395B11E809A for ; Fri, 2 Nov 2012 08:04:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lr7dIE5lc7lP for ; Fri, 2 Nov 2012 08:04:48 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0ED11E8099 for ; Fri, 2 Nov 2012 08:04:48 -0700 (PDT) Received: from [192.168.0.112] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 9FAF28D58C2 for ; Fri, 2 Nov 2012 15:16:04 +0000 (UTC) Message-ID: <5093E105.2090302@status.net> Date: Fri, 02 Nov 2012 11:04:37 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030503000000050307020206" Subject: Re: [apps-discuss] High-level considerations about "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, 02 Nov 2012 15:04:52 -0000 This is a multi-part message in MIME format. --------------030503000000050307020206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit The conversation has really moved on! I suggest you read Paul Jones's latest email to get caught up. -Evan On 12-11-02 08:02 AM, Goix Laurent Walter wrote: > > Dear all, > > I tried to catch up with the hot discussion of the last days and would > try to hold on for the time of an email trying to summarize the > current situation and take a breath... > > At this stage we are having very distinct camps in the list for what > they have in mind behind the "webfinger" keyword: xml vs json, 1 or 2 > roundtrips, privacy ecc. It seems to me that Paul has been doing an > outstanding work trying to compromise (I would have lost patience...) > but such compromises do not seem to satisfy anyone: actually, > compromises are moving more and more towards the original SWD idea at > the end. > > Maybe we could ask ourselves the following questions: > > -With the "xrd" idea in mind (please, jrd-enthusiasts, try to put that > hat on as well), what is actually missing beyond rfc6415 for > "webfinger"? now the 'acct' URI is a separate draft (an initial > motivation). Rel/resource parameters for xrd supporters do not seem > essential in my understanding neither. So (although I am a supports of > that camp) I have trouble seeing what truly need to be added. I can > understand Evan's position for keeping the entire xrd-based community > (ostatus, diaspora, etc) but isn't rfc6415-compliance for those > existing implementations already fair enough? If a new "webfinger" is > jrd, 1-roundtrip only at the end it's just another rfc number to be > referenced instead/in addition and as such has the same value...(not > mentioning the implementation work needed) > > -Rfc6415-compliance & backward compatibility: this seems also > contentious as whether backward-compatibility is needed or not. > however the current "compromises" are odd in maintaining > backward-compability. What is exactly interesting for "webfinger" from > that rfc? From the latest alternative it seems only the > "host-meta.json" endpoint name & the jrd. Or else? How these can be > referenced at best without needing the whole thing? > > -Host-meta+lrdd vs new endpoint: Should we propose an alternative > endpoint name (there were many proposals, including one of mine a > while ago) so that we simply "distinguish" the existing host-meta+lrdd > way from a new "webfinger" way/endpoint all-in-1-roundtrip. This is > what swd is proposing. Eventually one could at the end use the same > backend implementation to return queries coming all the way from > host-meta+lrdd than others using another well-known (and direct) > endpoint. This would also be much easier to support any query > parameter (resource, rel, etc) as some are arguing against overriding > host-meta with parameters. In that case the new "webfinger" would be > actually more like SWD (with JRD support) > > -In alternative, what about the provocative idea from Evan to > "replace" rfc6415? Are they other usages of rfc6415 than the > "webfinger" one throughout the community? If yes, then it may be more > difficult to replace unless agreed with whom is using it. Otherwise, > as it seems most people do not like it, why keep it as-is and not > upgrade directly to whatever is now useful? A standard that is not > used is useless and has no point in being superseded by a parallel > spec not actually obsoleting it... If JRD and the well-known endpoints > are useful in other context, then why not splitting them from the > actual protocol procedures of current rfc6415 and have clean specs > that can be generically referenced without buying the full thing or > writing complex text to select some parts of it and contest others: 1 > for JRD and 1 for the endpoints/link registrations. Then a > protocol-oriented spec like webfinger can easily decide what to take > and replace current rfc6415, or decide to live separately/parallel. > > Personally I have more interest and feeling for the 2-roundtrip xrd > solution from rfc6415 still. But if I have to choose between an > odd/partial/unstable/unclear/buggy reference to it and a new json way > for satisfying another use case I have to put limits in compromising > and at this point prefer a parallel/independent approach. Of course > I'd like possibly to reuse the file format (jrd) as it seems suitable > for all. At least this way rfc6415 can still live independently (being > updated or not if we want to make it "cleaner") and "webfinger" can > hopefully be finalized quickly in the json + 1 roundtrip direction... > > Once these macro topics are clarified then we can better discuss the > details about securing wf, supporting privacy, distinct delivery for > auth/non-auth requests etc...But can we first discuss at high level > what we want to achieve in terms of process? > > Cheers > > walter > > 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./ > > *rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se > non è necessario.* > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------030503000000050307020206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
The conversation has really moved on! I suggest you read Paul Jones's latest email to get caught up.

-Evan

On 12-11-02 08:02 AM, Goix Laurent Walter wrote:

Dear all,

 

I tried to catch up with the hot discussion of the last days and would try to hold on for the time of an email trying to summarize the current situation and take a breath…

 

At this stage we are having very distinct camps in the list for what they have in mind behind the “webfinger” keyword: xml vs json, 1 or 2 roundtrips, privacy ecc. It seems to me that Paul has been doing an outstanding work trying to compromise (I would have lost patience…) but such compromises do not seem to satisfy anyone: actually, compromises are moving more and more towards the original SWD idea at the end.

 

Maybe we could ask ourselves the following questions:

-          With the “xrd” idea in mind (please, jrd-enthusiasts, try to put that hat on as well), what is actually missing beyond rfc6415 for “webfinger”? now the ‘acct’ URI is a separate draft (an initial motivation). Rel/resource parameters for xrd supporters do not seem essential in my understanding neither. So (although I am a supports of that camp) I have trouble seeing what truly need to be added. I can understand Evan’s position for keeping the entire xrd-based community (ostatus, diaspora, etc) but isn’t rfc6415-compliance for those existing implementations already fair enough? If a new “webfinger” is jrd, 1-roundtrip only at the end it’s just another rfc number to be referenced instead/in addition and as such has the same value…(not mentioning the implementation work needed)

 

-          Rfc6415-compliance & backward compatibility: this seems also contentious as whether backward-compatibility is needed or not. however the current “compromises” are odd in maintaining backward-compability. What is exactly interesting for “webfinger” from that rfc? From the latest alternative it seems only the “host-meta.json” endpoint name & the jrd. Or else? How these can be referenced at best without needing the whole thing?

 

-          Host-meta+lrdd vs new endpoint: Should we propose an alternative endpoint name (there were many proposals, including one of mine a while ago) so that we simply “distinguish” the existing host-meta+lrdd way from a new “webfinger” way/endpoint all-in-1-roundtrip. This is what swd is proposing. Eventually one could at the end use the same backend implementation to return queries coming all the way from host-meta+lrdd than others using another well-known (and direct) endpoint. This would also be much easier to support any query parameter (resource, rel, etc) as some are arguing against overriding host-meta with parameters. In that case the new “webfinger” would be actually more like SWD (with JRD support)

 

-          In alternative, what about the provocative idea from Evan to “replace” rfc6415? Are they other usages of rfc6415 than the “webfinger” one throughout the community? If yes, then it may be more difficult to replace unless agreed with whom is using it. Otherwise, as it seems most people do not like it, why keep it as-is and not upgrade directly to whatever is now useful? A standard that is not used is useless and has no point in being superseded by a parallel spec not actually obsoleting it... If JRD and the well-known endpoints are useful in other context, then why not splitting them from the actual protocol procedures of current rfc6415 and have clean specs that can be generically referenced without buying the full thing or writing complex text to select some parts of it and contest others: 1 for JRD and 1 for the endpoints/link registrations. Then a protocol-oriented spec like webfinger can easily decide what to take and replace current rfc6415, or decide to live separately/parallel.

 

 

Personally I have more interest and feeling for the 2-roundtrip xrd solution from rfc6415 still. But if I have to choose between an odd/partial/unstable/unclear/buggy reference to it and a new json way for satisfying another use case I have to put limits in compromising and at this point prefer a parallel/independent approach. Of course I’d like possibly to reuse the file format (jrd) as it seems suitable for all. At least this way rfc6415 can still live independently (being updated or not if we want to make it “cleaner”) and “webfinger” can hopefully be finalized quickly in the json + 1 roundtrip direction…

 

Once these macro topics are clarified then we can better discuss the details about securing wf, supporting privacy, distinct delivery for auth/non-auth requests etc…But can we first discuss at high level what we want to achieve in terms of process?

 

Cheers

walter

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.

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è necessario. 


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

--------------030503000000050307020206-- From laurentwalter.goix@telecomitalia.it Fri Nov 2 08:29: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 128FE11E8097 for ; Fri, 2 Nov 2012 08:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.781 X-Spam-Level: X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[AWL=0.937, 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 Xcn1vr8iHXSn for ; Fri, 2 Nov 2012 08:29:41 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id EF58221F8AAF for ; Fri, 2 Nov 2012 08:29:40 -0700 (PDT) Content-Type: multipart/mixed; boundary="_a97ba711-ece0-4f49-ab3e-ce444c13e88e_" Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 2 Nov 2012 16:29:38 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Fri, 2 Nov 2012 16:29:38 +0100 From: Goix Laurent Walter To: Evan Prodromou , "apps-discuss@ietf.org" Date: Fri, 2 Nov 2012 16:29:37 +0100 Thread-Topic: [apps-discuss] High-level considerations about "webfinger" Thread-Index: Ac25C29FsVz5dXz9TbSlCcZYIXVvrgAAIojg Message-ID: References: <5093E105.2090302@status.net> In-Reply-To: <5093E105.2090302@status.net> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Subject: [apps-discuss] R: High-level considerations about "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, 02 Nov 2012 15:29:47 -0000 --_a97ba711-ece0-4f49-ab3e-ce444c13e88e_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A50F6CF9GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A50F6CF9GRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi evan, I do have read the latest alt-r1 draft. But I do believe these are still ap= plicable questions: - I could still see pros/cons in the list for rel/resource paramet= ers in host-meta.json - The question of creating a new endpoint has been raised and stil= l pending imo (also wrt previous bullet) - Relationship with rfc6415 is still not clear as some parts are c= learly referenced (mostly procedures) whilst others mention a clear distanc= e with it (eg xrd vs jrd). As a developer I could not know very well whethe= r I need to implement rfc6415 and how much of it...at this point one may co= nsider how much the draft gains in actually referencing those sections if i= t is to mandate the contrary... o In section 3 it reads "the protocol builds on rfc6415", which is very u= nclear to which extent o Section 5 talks about backward-compatibility but basically says it "may= not be". This is mainly to reuse jrd and "host-meta.json" so it may be mor= e appropriate to call them out explicitly without any generic sentence (sti= ll if this is the feeling of the group) o Section 5.1 references section 4.2 of rfc6415 but actually introduces s= ome variants, so why not write a clean standalone text with no reference to= rfc6415? o Section 5.2 references an "example" of rfc6415 section 1.1.1, but the v= alue of that reference is not clear. Better probably to reference webfinger= 's own examples. - the very latest draft is still al "ALT" at this stage... I'm playing the devil's advocate here but do think that the various camps i= ntend very diverse usages of webfinger that maybe do not benefit of one sol= ution. It is a pity those use cases are not reflected in the simplistic exa= mples: I personally liked the openid one as I think opened connect would be= 1 candidate, but I've heard about autoconfiguration (see oauth use case) a= nd federated social networks (the whole original point of it). All of them = are used in very different contexts (trusted/untrusted, intra-/inter-domain= ) and will probably distinguish themselves from the actual link rels they w= ill use/expose... walter Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Pe= r conto di Evan Prodromou Inviato: venerd=EC 2 novembre 2012 16.05 A: apps-discuss@ietf.org Oggetto: Re: [apps-discuss] High-level considerations about "webfinger" The conversation has really moved on! I suggest you read Paul Jones's lates= t email to get caught up. -Evan On 12-11-02 08:02 AM, Goix Laurent Walter wrote: Dear all, I tried to catch up with the hot discussion of the last days and would try = to hold on for the time of an email trying to summarize the current situati= on and take a breath... At this stage we are having very distinct camps in the list for what they h= ave in mind behind the "webfinger" keyword: xml vs json, 1 or 2 roundtrips,= privacy ecc. It seems to me that Paul has been doing an outstanding work t= rying to compromise (I would have lost patience...) but such compromises do= not seem to satisfy anyone: actually, compromises are moving more and more= towards the original SWD idea at the end. Maybe we could ask ourselves the following questions: - With the "xrd" idea in mind (please, jrd-enthusiasts, try to put= that hat on as well), what is actually missing beyond rfc6415 for "webfing= er"? now the 'acct' URI is a separate draft (an initial motivation). Rel/re= source parameters for xrd supporters do not seem essential in my understand= ing neither. So (although I am a supports of that camp) I have trouble seei= ng what truly need to be added. I can understand Evan's position for keepin= g the entire xrd-based community (ostatus, diaspora, etc) but isn't rfc6415= -compliance for those existing implementations already fair enough? If a ne= w "webfinger" is jrd, 1-roundtrip only at the end it's just another rfc num= ber to be referenced instead/in addition and as such has the same value...(= not mentioning the implementation work needed) - Rfc6415-compliance & backward compatibility: this seems also con= tentious as whether backward-compatibility is needed or not. however the cu= rrent "compromises" are odd in maintaining backward-compability. What is ex= actly interesting for "webfinger" from that rfc? From the latest alternativ= e it seems only the "host-meta.json" endpoint name & the jrd. Or else? How = these can be referenced at best without needing the whole thing? - Host-meta+lrdd vs new endpoint: Should we propose an alternative= endpoint name (there were many proposals, including one of mine a while ag= o) so that we simply "distinguish" the existing host-meta+lrdd way from a n= ew "webfinger" way/endpoint all-in-1-roundtrip. This is what swd is proposi= ng. Eventually one could at the end use the same backend implementation to = return queries coming all the way from host-meta+lrdd than others using ano= ther well-known (and direct) endpoint. This would also be much easier to su= pport any query parameter (resource, rel, etc) as some are arguing against = overriding host-meta with parameters. In that case the new "webfinger" woul= d be actually more like SWD (with JRD support) - In alternative, what about the provocative idea from Evan to "re= place" rfc6415? Are they other usages of rfc6415 than the "webfinger" one t= hroughout the community? If yes, then it may be more difficult to replace u= nless agreed with whom is using it. Otherwise, as it seems most people do n= ot like it, why keep it as-is and not upgrade directly to whatever is now u= seful? A standard that is not used is useless and has no point in being sup= erseded by a parallel spec not actually obsoleting it... If JRD and the wel= l-known endpoints are useful in other context, then why not splitting them = from the actual protocol procedures of current rfc6415 and have clean specs= that can be generically referenced without buying the full thing or writin= g complex text to select some parts of it and contest others: 1 for JRD and= 1 for the endpoints/link registrations. Then a protocol-oriented spec like= webfinger can easily decide what to take and replace current rfc6415, or d= ecide to live separately/parallel. Personally I have more interest and feeling for the 2-roundtrip xrd solutio= n from rfc6415 still. But if I have to choose between an odd/partial/unstab= le/unclear/buggy reference to it and a new json way for satisfying another = use case I have to put limits in compromising and at this point prefer a pa= rallel/independent approach. Of course I'd like possibly to reuse the file = format (jrd) as it seems suitable for all. At least this way rfc6415 can st= ill live independently (being updated or not if we want to make it "cleaner= ") and "webfinger" can hopefully be finalized quickly in the json + 1 round= trip direction... Once these macro topics are clarified then we can better discuss the detail= s about securing wf, supporting privacy, distinct delivery for auth/non-aut= h requests etc...But can we first discuss at high level what we want to ach= ieve in terms of process? Cheers walter 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. _______________________________________________ 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_A09A9E0A4B9C654E8672D1DC003633AE53A50F6CF9GRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi evan= ,

&n= bsp;

I do ha= ve read the latest alt-r1 draft. But I do believe these are still applicabl= e questions:

= -          I could still see pros/cons in the list for rel/resource parameters in hos= t-meta.json

= -          The question of creating a new endpoint has been raised and still pending = imo (also wrt previous bullet)

= -          Relationship with rfc6415 is still not clear as some parts are clearly ref= erenced (mostly procedures) whilst others mention a clear distance with it = (eg xrd vs jrd). As a developer I could not know very well whether I need to implement rfc6415 and how much of it&= #8230;at this point one may consider how much the draft gains in actually r= eferencing those sections if it is to mandate the contrary…

o   In section 3 it reads “the protocol builds on rfc6415”, which = is very unclear to which extent

o   Section 5 talks about backward-compatibility but basically says it “= may not be”. This is mainly to reuse jrd and “host-meta.json= 221; so it may be more appropriate to call them out explicitly without any generic sentence (still if this is the feeling of the group)

o   Section 5.1 references section 4.2 of rfc6415 but actually introduces some= variants, so why not write a clean standalone text with no reference to rf= c6415?

o   Section 5.2 references an “example” of rfc6415 section 1.1.1, = but the value of that reference is not clear. Better probably to reference = webfinger’s own examples.

= -          the very latest draft is still al “ALT” at this stage…

&n= bsp;

I’= ;m playing the devil’s advocate here but do think that the various ca= mps intend very diverse usages of webfinger that maybe do not benefit of on= e solution. It is a pity those use cases are not reflected in the simplistic examples: I personally liked the openid one as I think o= pened connect would be 1 candidate, but I’ve heard about autoconfigur= ation (see oauth use case) and federated social networks (the whole origina= l point of it). All of them are used in very different contexts (trusted/untrusted, intra-/inter-domain) and will = probably distinguish themselves from the actual link rels they will use/exp= ose…

&n= bsp;

walter<= o:p>

 

Da: = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di Evan Prodromou<= br> Inviato: venerd=EC 2 novembre 2012 16.05
A: apps-discuss@ietf.org
Oggetto: Re: [apps-discuss] High-level considerations about "we= bfinger"

 

The conversation has really moved on! I suggest you = read Paul Jones's latest email to get caught up.

-Evan

On 12-11-02 08:02 AM, Goix Laurent Walter wrote:

Dear all,

 

I tried to catch up with the ho= t discussion of the last days and would try to hold on for the time of an e= mail trying to summarize the current situation and take a breath…

 

At this stage we are having ver= y distinct camps in the list for what they have in mind behind the “w= ebfinger” keyword: xml vs json, 1 or 2 roundtrips, privacy ecc. It se= ems to me that Paul has been doing an outstanding work trying to compromise (I would have lost patience…) but such com= promises do not seem to satisfy anyone: actually, compromises are moving mo= re and more towards the original SWD idea at the end.

 

Maybe we could ask ourselves th= e following questions:

-     &= nbsp;    With the “xrd” ide= a in mind (please, jrd-enthusiasts, try to put that hat on as well), what i= s actually missing beyond rfc6415 for “webfinger”? now the R= 16;acct’ URI is a separate draft (an initial motivation). Rel/resourc= e parameters for xrd supporters do not seem essential in my understanding ne= ither. So (although I am a supports of that camp) I have trouble seeing wha= t truly need to be added. I can understand Evan’s position for keepin= g the entire xrd-based community (ostatus, diaspora, etc) but isn’t rfc6415-compliance for those existing imple= mentations already fair enough? If a new “webfinger” is jrd, 1-= roundtrip only at the end it’s just another rfc number to be referenc= ed instead/in addition and as such has the same value…(not mentioning the implementation work needed)

 =

-     &= nbsp;    Rfc6415-compliance & backw= ard compatibility: this seems also contentious as whether backward-compatib= ility is needed or not. however the current “compromises” are o= dd in maintaining backward-compability. What is exactly interesting for “webfinger” from that rfc? From the latest alt= ernative it seems only the “host-meta.json” endpoint name &= the jrd. Or else? How these can be referenced at best without needing the = whole thing?

 =

-     &= nbsp;    Host-meta+lrdd vs new endp= oint: Should we propose an alternative endpoint name (there were many propo= sals, including one of mine a while ago) so that we simply “distingui= sh” the existing host-meta+lrdd way from a new “webfinger” way/endpoint all-in-1-roundtrip. This is what swd = is proposing. Eventually one could at the end use the same backend implemen= tation to return queries coming all the way from host-meta+lrdd than ot= hers using another well-known (and direct) endpoint. This would also be much easier to support any query parameter (resource, r= el, etc) as some are arguing against overriding host-meta with parameters. = In that case the new “webfinger” would be actually more like SW= D (with JRD support)

 =

-     &= nbsp;    In alternative, what about the= provocative idea from Evan to “replace” rfc6415? Are they othe= r usages of rfc6415 than the “webfinger” one throughout the com= munity? If yes, then it may be more difficult to replace unless agreed with whom is using it. Otherwise, as it seems most people do not li= ke it, why keep it as-is and not upgrade directly to whatever is now useful= ? A standard that is not used is useless and has no point in being supersed= ed by a parallel spec not actually obsoleting it... If JRD and the well-known endpoints are useful in other c= ontext, then why not splitting them from the actual protocol procedures of = current rfc6415 and have clean specs that can be generically referenced wit= hout buying the full thing or writing complex text to select some parts of it and contest others: 1 for JRD and = 1 for the endpoints/link registrations. Then a protocol-oriented spec like = webfinger can easily decide what to take and replace current rfc6415, or de= cide to live separately/parallel.

 =

 =

Personally I have more interest= and feeling for the 2-roundtrip xrd solution from rfc6415 still. But if I = have to choose between an odd/partial/unstable/unclear/buggy reference to i= t and a new json way for satisfying another use case I have to put limits in compromising and at this point pr= efer a parallel/independent approach. Of course I’d like possibly to = reuse the file format (jrd) as it seems suitable for all. At least this way= rfc6415 can still live independently (being updated or not if we want to make it “cleaner”) and = 220;webfinger” can hopefully be finalized quickly in the json + 1= roundtrip direction…

 

Once these macro topics are cla= rified then we can better discuss the details about securing wf, supporting= privacy, distinct delivery for auth/non-auth requests etc…But can we= first discuss at high level what we want to achieve in terms of process?

 

Cheers

walter

Questo messaggio e i suoi allegati sono indirizzati esclusi= vamente alle persone 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. 




_______________________________________________
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_A09A9E0A4B9C654E8672D1DC003633AE53A50F6CF9GRFMBX704BA02_-- --_a97ba711-ece0-4f49-ab3e-ce444c13e88e_ 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= --_a97ba711-ece0-4f49-ab3e-ce444c13e88e_-- From paulej@packetizer.com Fri Nov 2 23:50: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 ABEE921F9C0F for ; Fri, 2 Nov 2012 23:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=-0.311, 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 Ir6VXeTaJ4iC for ; Fri, 2 Nov 2012 23:50:41 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCDD21F849A for ; Fri, 2 Nov 2012 23:50: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 qA36ocFs024514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 3 Nov 2012 02:50:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351925440; bh=ddG6HXEDa4LMv38VB3d/e2g8xL90a6CL6ktcsbHooKg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=f8juLTJVhmXG7HGfLVZPARcRznwqRbHpQt+a95ZQuq+BoKlv85BjAJyxszud6I2iK nnyj/yvq50+6OnTYSyXumhNGK6H+YgVdR3nDOI0keyNlcjXY53zGyagHqXZZFXEsSY QMMk8I7Uxt+FVXcNjhHhmBOaWHzPbQ3w8Firoh7U= From: "Paul E. Jones" To: "'Goix Laurent Walter'" , "'Evan Prodromou'" , References: <5093E105.2090302@status.net> In-Reply-To: Date: Sat, 3 Nov 2012 02:50:48 -0400 Message-ID: <054501cdb98f$8f77fe00$ae67fa00$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0546_01CDB96E.0869B960" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIeWfuWjoUIv93mY+PWpHVBG3B76gJ00KovAaFt2qeXFaQ84A== Content-Language: en-us Cc: webfinger@googlegroups.com Subject: Re: [apps-discuss] R: High-level considerations about "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, 03 Nov 2012 06:50:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0546_01CDB96E.0869B960 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0547_01CDB96E.0869B960" ------=_NextPart_001_0547_01CDB96E.0869B960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Walter, et al, =20 (Apologizes for the length, but I think we have an important directional decision to make=85) =20 I think down below you summarized the situation pretty well. While generalizing, what I think we have are two different camps. There are = those who have a preference for RFC 6415 as it=92s defined today. There are a = list of people who said they like the host-meta approach with host-specific = and then separate resource-specific information and the use of templates (notably the one for LRDD). Then there is the group who does not. They just want to issue a single query and get back a single response. The latter group do not like templates and do not want to make two requests. Oh, and they do not care one way or the other about preserving backward-compatibility with RFC 6415. (Now, my statements about the two camps is a generalization, a I said at the outset, and there are = opinions that cross boundaries, but this is the cleanest division I can see for = the purposes of discussion.) =20 What I=92ve tried to do is define a solution that would allow for a = single request/response, but would maintain a high-degree of interoperability between this new document and 6415. As I was making changes to the = draft and trying to take input, I was trying to think through how I could = produce a solution to meet the requirements without a host-meta server modified = in any way, except for the addition of =93resource=94 and JRD support. = Ignoring the editorial improvements that could be made, I think the current = ALT-R1 draft does that. =20 You are entirely correct that this spec is looking more like SWD. There = are some very important distinctions, though. For one, SWD returns a single link to a single request. It makes discovering lots of information = about somebody a pain, IMO. It=92s primary purpose was to support OpenID = Connect and it works fine for that, but if I want to ask a sever to =93tell me everything you know about Paul Jones=94, it cannot. RFC 6415 can, and I = like that. The difference is really a matter of the document returned. = Also, there is application-level kind of redirect in SWD (or was) that really should be an HTTP-level (3xx). I don=92t like that about SWD, either. =20 Back to the two camps: neither is happy with the present solution (the = -02 draft). People who like the single request approach like this ALT = drafts better because XML is gone, there is a single resource to go query, and, = of course, there is a single request/response. People who are in the 6415 = camp do are not happy with the -02 draft because we turn =93host metadata=94 = into =93resource=94 information: we merge the concepts. They also do not = like the ALT drafts for the same reason. However, even the 6415 camp does seem = to have an appreciation for a resource-centric approach that can use a = single query. They just don=92t like the =93hack=94 (my term=85 that=92s the = one negative word I don=92t think I=92ve had thrown in my face ;-) ). =20 I believe you are right to point out that the one thing people seem to = be generally OK with is JRD. I think it=92s a simple format, nice to work = with, useful, and not overly complicated. Given that there are virtually no comments on the format, I gather people share the same sentiment. =20 Now, having had conversations with a number of people both on the list = and off, I believe we need to decide which direction to take and I think = there are two choices: 1) We discard the current WebFinger draft and continue with RFC = 6415 as-is 2) We re-write the spec in the spirit of the ALT versions, = completely breaking away from RFC 6415 by a. Removing all references to and dependencies on RFC 6415 b. Defining JRD within the WebFinger spec, specifying such things = as =93the order of link relations is significant=94 or other rules we want = to apply to the document c. Defining a new resource for this server at = /.well-known/webfinger (or swd ?) d. Using no templates whatsoever e. Using the =93resource=94 parameter as the current ALT draft has = them (the concept of =93host metadata=94 does not exist with this draft; = I=92m not sure what the server should do if the resource parameter is absent, though) f. (I would say use the =93rel=94 parameter, too, but some have = really expressed dissatisfaction with that. While I think it=92s wonderful in = order to reduce the number of link relations returned, some just saw no value = in that=85 even on narrow-band network connections.) =20 If I understand the two camps, I think those are the two options before = us. I=92m sure there may be other things to do for option 2, but you get the = gist of where that is headed. =20 More importantly, I am left with the impression that if we do go with = option 2, we will get support from both camps. Some of those who are in the = 6415 camp just have an objective of not breaking what is there now and some = just don=92t want the =93hack=94 that is the current WF spec. But, I believe = most are all for a clean specification that defines a useful service and that utilizes JRD to provide a set of link relations about a resource; a = useful =93web discovery protocol=94. =20 I just want a solution and would not be upset with either solution. = What I do not like, though, is having two or three solutions for discovery. At present, we have RFC 6415, current WF draft, SWD, and draft-daboo-agreggated-service-discovery. That=92s a few too many ;-) =20 I do have a high opinion of XRD/JRD, so I would like to see either or = both of those retained in any solution the group produces. =20 Given that SWD exists, I take it that there is at least enough support = to do something other than RFC 6415. I do not fully understand the reasons, = except perhaps =93we want one round trip=94. I don=92t know. Perhaps someone = can educate me on the =93why=94. But, it does exist, so there is a reason and it = means we might end up with two solutions. =20 So, can we avoid that? I=92d be ok with putting aside the WF spec in = favor a merger between SWD/WF. I don=92t want to call this a =93compromise=94, = but rather a clean solution that borrows from both: single round trip (like SWD), a richer response with a set of links (JRD), adheres to and follows HTTP procedures (e.g., no =93SWD_service_redirect=94 type construct; use = 3xx), has no templates in the JRD, allows any URI type (including =93acct:=94) as the =93subject=94 of the query, and is rooted at the host at some agreed = location like /.well-known/swd. =20 I believe if we do this, we have the greatest chance of getting the = largest number of people on board. Perhaps Mike or someone serve as editing, = but I=92d be happy to help co-author. I=92ll also write an implementation = as I did for RFC 6415; it should be simple to do. =20 In any case, I do think there is a serious risk of failure if we = continue down the current WF path, either because we end up with multiple = competing solutions or because we alienate one of the two camps. So we either = stick with 6415 and stop spending time on this, or create something along the lines of (2) where we can get nearly everyone on board. =20 Paul =20 From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Goix Laurent Walter Sent: Friday, November 02, 2012 11:30 AM To: Evan Prodromou; apps-discuss@ietf.org Subject: [apps-discuss] R: High-level considerations about "webfinger" =20 Hi evan, =20 I do have read the latest alt-r1 draft. But I do believe these are still applicable questions: - I could still see pros/cons in the list for rel/resource parameters in host-meta.json - The question of creating a new endpoint has been raised and = still pending imo (also wrt previous bullet) - Relationship with rfc6415 is still not clear as some parts = are clearly referenced (mostly procedures) whilst others mention a clear distance with it (eg xrd vs jrd). As a developer I could not know very = well whether I need to implement rfc6415 and how much of it=85at this point = one may consider how much the draft gains in actually referencing those sections = if it is to mandate the contrary=85 o In section 3 it reads =93the protocol builds on rfc6415=94, which is = very unclear to which extent o Section 5 talks about backward-compatibility but basically says it = =93may not be=94. This is mainly to reuse jrd and =93host-meta.json=94 so it = may be more appropriate to call them out explicitly without any generic sentence = (still if this is the feeling of the group) o Section 5.1 references section 4.2 of rfc6415 but actually = introduces some variants, so why not write a clean standalone text with no = reference to rfc6415? o Section 5.2 references an =93example=94 of rfc6415 section 1.1.1, = but the value of that reference is not clear. Better probably to reference webfinger=92s own examples. - the very latest draft is still al =93ALT=94 at this stage=85 =20 I=92m playing the devil=92s advocate here but do think that the various = camps intend very diverse usages of webfinger that maybe do not benefit of one solution. It is a pity those use cases are not reflected in the = simplistic examples: I personally liked the openid one as I think opened connect = would be 1 candidate, but I=92ve heard about autoconfiguration (see oauth use = case) and federated social networks (the whole original point of it). All of = them are used in very different contexts (trusted/untrusted, = intra-/inter-domain) and will probably distinguish themselves from the actual link rels they = will use/expose=85 =20 walter =20 Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = Per conto di Evan Prodromou Inviato: venerd=EC 2 novembre 2012 16.05 A: apps-discuss@ietf.org Oggetto: Re: [apps-discuss] High-level considerations about "webfinger" =20 The conversation has really moved on! I suggest you read Paul Jones's = latest email to get caught up. -Evan On 12-11-02 08:02 AM, Goix Laurent Walter wrote: Dear all, =20 I tried to catch up with the hot discussion of the last days and would = try to hold on for the time of an email trying to summarize the current situation and take a breath=85 =20 At this stage we are having very distinct camps in the list for what = they have in mind behind the =93webfinger=94 keyword: xml vs json, 1 or 2 = roundtrips, privacy ecc. It seems to me that Paul has been doing an outstanding work trying to compromise (I would have lost patience=85) but such = compromises do not seem to satisfy anyone: actually, compromises are moving more and = more towards the original SWD idea at the end. =20 Maybe we could ask ourselves the following questions: - With the =93xrd=94 idea in mind (please, jrd-enthusiasts, try = to put that hat on as well), what is actually missing beyond rfc6415 for =93webfinger=94? now the =91acct=92 URI is a separate draft (an initial = motivation). Rel/resource parameters for xrd supporters do not seem essential in my understanding neither. So (although I am a supports of that camp) I have trouble seeing what truly need to be added. I can understand Evan=92s = position for keeping the entire xrd-based community (ostatus, diaspora, etc) but isn=92t rfc6415-compliance for those existing implementations already = fair enough? If a new =93webfinger=94 is jrd, 1-roundtrip only at the end = it=92s just another rfc number to be referenced instead/in addition and as such has = the same value=85(not mentioning the implementation work needed) =20 - Rfc6415-compliance & backward compatibility: this seems also contentious as whether backward-compatibility is needed or not. however = the current =93compromises=94 are odd in maintaining backward-compability. = What is exactly interesting for =93webfinger=94 from that rfc? From the latest alternative it seems only the =93host-meta.json=94 endpoint name & the = jrd. Or else? How these can be referenced at best without needing the whole = thing?=20 =20 - Host-meta+lrdd vs new endpoint: Should we propose an = alternative endpoint name (there were many proposals, including one of mine a while = ago) so that we simply =93distinguish=94 the existing host-meta+lrdd way from = a new =93webfinger=94 way/endpoint all-in-1-roundtrip. This is what swd is = proposing. Eventually one could at the end use the same backend implementation to return queries coming all the way from host-meta+lrdd than others using another well-known (and direct) endpoint. This would also be much easier = to support any query parameter (resource, rel, etc) as some are arguing = against overriding host-meta with parameters. In that case the new = =93webfinger=94 would be actually more like SWD (with JRD support) =20 - In alternative, what about the provocative idea from Evan to =93replace=94 rfc6415? Are they other usages of rfc6415 than the = =93webfinger=94 one throughout the community? If yes, then it may be more difficult to = replace unless agreed with whom is using it. Otherwise, as it seems most people = do not like it, why keep it as-is and not upgrade directly to whatever is = now useful? A standard that is not used is useless and has no point in being superseded by a parallel spec not actually obsoleting it... If JRD and = the well-known endpoints are useful in other context, then why not splitting them from the actual protocol procedures of current rfc6415 and have = clean specs that can be generically referenced without buying the full thing = or writing complex text to select some parts of it and contest others: 1 = for JRD and 1 for the endpoints/link registrations. Then a protocol-oriented spec like webfinger can easily decide what to take and replace current rfc6415, or decide to live separately/parallel. =20 =20 Personally I have more interest and feeling for the 2-roundtrip xrd = solution from rfc6415 still. But if I have to choose between an odd/partial/unstable/unclear/buggy reference to it and a new json way = for satisfying another use case I have to put limits in compromising and at = this point prefer a parallel/independent approach. Of course I=92d like = possibly to reuse the file format (jrd) as it seems suitable for all. At least this = way rfc6415 can still live independently (being updated or not if we want to make it =93cleaner=94) and =93webfinger=94 can hopefully be finalized = quickly in the json + 1 roundtrip direction=85 =20 Once these macro topics are clarified then we can better discuss the = details about securing wf, supporting privacy, distinct delivery for = auth/non-auth requests etc=85But can we first discuss at high level what we want to = achieve in terms of process? =20 Cheers walter 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 _______________________________________________ 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_0547_01CDB96E.0869B960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Walter, et = al,

 

(Apologizes for the = length, but I think we have an important directional decision to = make…)

 

I think down below you = summarized the situation pretty well.=A0 While generalizing, what I = think we have are two different camps. =A0There are those who have a = preference for RFC 6415 as it’s defined today.=A0 There are a list = of people who said they like the host-meta approach with host-specific = and then separate resource-specific information and the use of templates = (notably the one for LRDD).=A0 Then there is the group who does not.=A0 = They just want to issue a single query and get back a single = response.=A0 The latter group do not like templates and do not want to = make two requests.=A0 Oh, and they do not care one way or the other = about preserving backward-compatibility with RFC 6415.=A0 (Now, my = statements about the two camps is a generalization, a I said at the = outset, and there are opinions that cross boundaries, but this is the = cleanest division I can see for the purposes of = discussion.)

 

What I’ve tried to = do is define a solution that would allow for a single request/response, = but would maintain a high-degree of interoperability between this new = document and 6415.=A0 As I was making changes to the draft and trying to = take input, I was trying to think through how I could produce a solution = to meet the requirements without a host-meta server modified in any way, = except for the addition of “resource” and JRD support.=A0 = Ignoring the editorial improvements that could be made, I think the = current ALT-R1 draft does that.

 

You are entirely correct = that this spec is looking more like SWD.=A0 There are some very = important distinctions, though.=A0 For one, SWD returns a single link to = a single request.=A0 It makes discovering lots of information about = somebody a pain, IMO.=A0 It’s primary purpose was to support = OpenID Connect and it works fine for that, but if I want to ask a sever = to “tell me everything you know about Paul Jones”, it = cannot.=A0 RFC 6415 can, and I like that.=A0 The difference is really a = matter of the document returned.=A0 Also, there is application-level = kind of redirect in SWD (or was) that really should be an HTTP-level = (3xx).=A0 I don’t like that about SWD, = either.

 

Back to the two camps: = neither is happy with the present solution (the -02 draft).=A0 People = who like the single request approach like this ALT drafts better because = XML is gone, there is a single resource to go query, and, of course, = there is a single request/response.=A0 People who are in the 6415 camp = do are not happy with the -02 draft because we turn “host = metadata” into “resource” information: we merge the = concepts.=A0 They also do not like the ALT drafts for the same = reason.=A0 However, even the 6415 camp does seem to have an appreciation = for a resource-centric approach that can use a single query.=A0 They = just don’t like the “hack” (my term… = that’s the one negative word I don’t think I’ve had = thrown in my face ;-) ).

 

I believe you are right = to point out that the one thing people seem to be generally OK with is = JRD.=A0 I think it’s a simple format, nice to work with, useful, = and not overly complicated.=A0 Given that there are virtually no = comments on the format, I gather people share the same = sentiment.

 

Now, having had = conversations with a number of people both on the list and off, I = believe we need to decide which direction to take and I think there are = two choices:

1)      = We discard = the current WebFinger draft and continue with RFC 6415 = as-is

2)      = We re-write = the spec in the spirit of the ALT versions, completely breaking away = from RFC 6415 by

a.       = Removing = all references to and dependencies on RFC 6415

b.      = Defining = JRD within the WebFinger spec, specifying such things as “the = order of link relations is significant” or other rules we want to = apply to the document

c.       = Defining a = new resource for this server at /.well-known/webfinger (or swd = ?)

d.      = Using no = templates whatsoever

e.      = Using the = “resource” parameter as the current ALT draft has them (the = concept of “host metadata” does not exist with this draft; = I’m not sure what the server should do if the resource parameter = is absent, though)

f.        = (I would = say use the “rel” parameter, too, but some have really = expressed dissatisfaction with that.=A0 While I think it’s = wonderful in order to reduce the number of link relations returned, some = just saw no value in that… even on narrow-band network = connections.)

 

If I understand the two = camps, I think those are the two options before us.=A0 I’m sure = there may be other things to do for option 2, but you get the gist of = where that is headed.

 

More importantly, I am = left with the impression that if we do go with option 2, we will get = support from both camps.=A0 Some of those who are in the 6415 camp just = have an objective of not breaking what is there now and some just = don’t want the “hack” that is the current WF spec.=A0 = But, I believe most are all for a clean specification that defines a = useful service and that utilizes JRD to provide a set of link relations = about a resource; a useful “web discovery = protocol”.

 

I just want a solution = and would not be upset with either solution.=A0 What I do not like, = though, is having two or three solutions for discovery.=A0 At present, = we have RFC 6415, current WF draft, SWD, and=A0 = draft-daboo-agreggated-service-discovery.=A0 That’s a few too many = ;-)

 

I do have a high opinion = of XRD/JRD, so I would like to see either or both of those retained in = any solution the group produces.

 

Given that SWD exists, I = take it that there is at least enough support to do something other than = RFC 6415. I do not fully understand the reasons, except perhaps = “we want one round trip”. I don’t know.=A0 Perhaps = someone can educate me on the “why”.=A0 But, it does exist, = so there is a reason and it means we might end up with two = solutions.

 

So, can we avoid = that?=A0 I’d be ok with putting aside the WF spec in favor a = merger between SWD/WF.=A0 I don’t want to call this a = “compromise”, but rather a clean solution that borrows from = both: single round trip (like SWD), a richer response with a set of = links (JRD), adheres to and follows HTTP procedures (e.g., no = “SWD_service_redirect” type construct; use 3xx), has no = templates in the JRD, allows any URI type (including = “acct:”) as the “subject” of the query, and is = rooted at the host at some agreed location like = /.well-known/swd.

 

I believe if we do this, = we have the greatest chance of getting the largest number of people on = board.=A0 Perhaps Mike or someone serve as editing, but I’d be = happy to help co-author.=A0 I’ll also write an implementation as I = did for RFC 6415; it should be simple to do.

 

In any case, I do think = there is a serious risk of failure if we continue down the current WF = path, either because we end up with multiple competing solutions or = because we alienate one of the two camps.=A0 So we either stick with = 6415 and stop spending time on this, or create something along the lines = of (2) where we can get nearly everyone on = board.

 

Paul

 

From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Goix Laurent = Walter
Sent: Friday, November 02, 2012 11:30 AM
To: = Evan Prodromou; apps-discuss@ietf.org
Subject: [apps-discuss] = R: High-level considerations about = "webfinger"

 

Hi evan,

 

I do have read the = latest alt-r1 draft. But I do believe these are still applicable = questions:

-          = I could = still see pros/cons in the list for rel/resource parameters in = host-meta.json

-          = The = question of creating a new endpoint has been raised and still pending = imo (also wrt previous bullet)

-          = Relationship with rfc6415 is still not clear as = some parts are clearly referenced (mostly procedures) whilst others = mention a clear distance with it (eg xrd vs jrd). As a developer I could = not know very well whether I need to implement rfc6415 and how much of = it…at this point one may consider how much the draft gains in = actually referencing those sections if it is to mandate the = contrary…

o   = In section = 3 it reads “the protocol builds on rfc6415”, which is very = unclear to which extent

o   = Section 5 = talks about backward-compatibility but basically says it “may not = be”. This is mainly to reuse jrd and “host-meta.json” = so it may be more appropriate to call them out explicitly without any = generic sentence (still if this is the feeling of the = group)

o   = Section 5.1 = references section 4.2 of rfc6415 but actually introduces some variants, = so why not write a clean standalone text with no reference to = rfc6415?

o   = Section 5.2 = references an “example” of rfc6415 section 1.1.1, but the = value of that reference is not clear. Better probably to reference = webfinger’s own examples.

-          = the very = latest draft is still al “ALT” at this = stage…

 

I’m playing the = devil’s advocate here but do think that the various camps intend = very diverse usages of webfinger that maybe do not benefit of one = solution. It is a pity those use cases are not reflected in the = simplistic examples: I personally liked the openid one as I think opened = connect would be 1 candidate, but I’ve heard about = autoconfiguration (see oauth use case) and federated social networks = (the whole original point of it). All of them are used in very different = contexts (trusted/untrusted, intra-/inter-domain) and will probably = distinguish themselves from the actual link rels they will = use/expose…

 

walter

 

Da: apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-bounces= @ietf.org] Per conto di Evan Prodromou
Inviato: = venerd=EC 2 novembre 2012 16.05
A: apps-discuss@ietf.org
Ogg= etto: Re: [apps-discuss] High-level considerations about = "webfinger"

 

The conversation has really moved on! = I suggest you read Paul Jones's latest email to get caught = up.

-Evan

On 12-11-02 08:02 AM, Goix Laurent Walter = wrote:

Dear all,

 

I tried to catch up with the hot discussion of the = last days and would try to hold on for the time of an email trying to = summarize the current situation and take a breath…

 

At this stage we = are having very distinct camps in the list for what they have in mind = behind the “webfinger” keyword: xml vs json, 1 or 2 = roundtrips, privacy ecc. It seems to me that Paul has been doing an = outstanding work trying to compromise (I would have lost = patience…) but such compromises do not seem to satisfy anyone: = actually, compromises are moving more and more towards the original SWD = idea at the end.

 

Maybe we could ask ourselves the following = questions:

-          = With the “xrd” idea in mind = (please, jrd-enthusiasts, try to put that hat on as well), what is = actually missing beyond rfc6415 for “webfinger”? now the = ‘acct’ URI is a separate draft (an initial motivation). = Rel/resource parameters for xrd supporters do not seem essential in my = understanding neither. So (although I am a supports of that camp) I have = trouble seeing what truly need to be added. I can understand = Evan’s position for keeping the entire xrd-based community = (ostatus, diaspora, etc) but isn’t rfc6415-compliance for those = existing implementations already fair enough? If a new = “webfinger” is jrd, 1-roundtrip only at the end it’s = just another rfc number to be referenced instead/in addition and as such = has the same value…(not mentioning the implementation work = needed)

 

-          = Rfc6415-compliance & backward = compatibility: this seems also contentious as whether = backward-compatibility is needed or not. however the current = “compromises” are odd in maintaining backward-compability. = What is exactly interesting for “webfinger” from that rfc? = >From the latest alternative it seems only the = “host-meta.json” endpoint name & the jrd. Or else? How = these can be referenced at best without needing the whole thing?

 

-          = Host-meta+lrdd vs new endpoint: Should we = propose an alternative endpoint name (there were many proposals, = including one of mine a while ago) so that we simply = “distinguish” the existing host-meta+lrdd way from a new = “webfinger” way/endpoint all-in-1-roundtrip. This is what = swd is proposing. Eventually one could at the end use the same backend = implementation to return queries coming all the way from host-meta+lrdd = than others using another well-known (and direct) endpoint. This would = also be much easier to support any query parameter (resource, rel, etc) = as some are arguing against overriding host-meta with parameters. In = that case the new “webfinger” would be actually more like = SWD (with JRD support)

 

-          = In alternative, what about the = provocative idea from Evan to “replace” rfc6415? Are they = other usages of rfc6415 than the “webfinger” one throughout = the community? If yes, then it may be more difficult to replace unless = agreed with whom is using it. Otherwise, as it seems most people do not = like it, why keep it as-is and not upgrade directly to whatever is now = useful? A standard that is not used is useless and has no point in being = superseded by a parallel spec not actually obsoleting it... If JRD and = the well-known endpoints are useful in other context, then why not = splitting them from the actual protocol procedures of current rfc6415 = and have clean specs that can be generically referenced without buying = the full thing or writing complex text to select some parts of it and = contest others: 1 for JRD and 1 for the endpoints/link registrations. = Then a protocol-oriented spec like webfinger can easily decide what to = take and replace current rfc6415, or decide to live = separately/parallel.

 

 

Personally I have more interest and feeling for the = 2-roundtrip xrd solution from rfc6415 still. But if I have to choose = between an odd/partial/unstable/unclear/buggy reference to it and a new = json way for satisfying another use case I have to put limits in = compromising and at this point prefer a parallel/independent approach. = Of course I’d like possibly to reuse the file format (jrd) as it = seems suitable for all. At least this way rfc6415 can still live = independently (being updated or not if we want to make it = “cleaner”) and “webfinger” can hopefully be = finalized quickly in the json + 1 roundtrip direction…

 

Once these macro = topics are clarified then we can better discuss the details about = securing wf, supporting privacy, distinct delivery for auth/non-auth = requests etc…But can we first discuss at high level what we want = to achieve in terms of process?

 

Cheers

walter

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. <= /span>

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. = <= /span>

3D"rispettaRispetta l'ambiente. Non stampare questa mail se non =E8 = necessario. = 



_______________________________________________
apps-discuss mailing =
list
apps-discuss@ietf.org
https://www.i=
etf.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. <= /span>

This e-mail = and any attachments is&nbs= p;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_0547_01CDB96E.0869B960-- ------=_NextPart_000_0546_01CDB96E.0869B960 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_0546_01CDB96E.0869B960-- From Michael.Jones@microsoft.com Sat Nov 3 00:48: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 858FD21F9C98 for ; Sat, 3 Nov 2012 00:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 k4H1aNEzLvW2 for ; Sat, 3 Nov 2012 00:48:43 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.32]) by ietfa.amsl.com (Postfix) with ESMTP id 18C0E21F9C91 for ; Sat, 3 Nov 2012 00:48:42 -0700 (PDT) Received: from BL2FFO11FD007.protection.gbl (10.173.161.204) by BL2FFO11HUB015.protection.gbl (10.173.160.107) with Microsoft SMTP Server (TLS) id 15.0.545.8; Sat, 3 Nov 2012 07:47:32 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD007.mail.protection.outlook.com (10.173.161.3) with Microsoft SMTP Server (TLS) id 15.0.556.9 via Frontend Transport; Sat, 3 Nov 2012 07:47:32 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Sat, 3 Nov 2012 07:47:31 +0000 From: Mike Jones To: "Paul E. Jones" , 'Goix Laurent Walter' , 'Evan Prodromou' , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] R: High-level considerations about "webfinger" Thread-Index: AQHNuQ79ETpznvAr2U+AKZ+enUsurZfXrP4AgAAP2J4= Date: Sat, 3 Nov 2012 07:47:30 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943668879DD@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <5093E105.2090302@status.net> , <054501cdb98f$8f77fe00$ae67fa00$@packetizer.com> In-Reply-To: <054501cdb98f$8f77fe00$ae67fa00$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/related; boundary="_004_4E1F6AAD24975D4BA5B1680429673943668879DDTK5EX14MBXC285r_"; type="multipart/alternative" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377424002)(53794001)(377454001)(24454001)(479174001)(47736001)(512944001)(76482001)(47446002)(51856001)(31966008)(46102001)(53806001)(5343655001)(47976001)(4396001)(33656001)(50986001)(16406001)(74502001)(74662001)(54316001)(44976002)(54356001)(49866001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0654257CF5 Cc: "webfinger@googlegroups.com" Subject: Re: [apps-discuss] R: High-level considerations about "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, 03 Nov 2012 07:48:45 -0000 --_004_4E1F6AAD24975D4BA5B1680429673943668879DDTK5EX14MBXC285r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943668879DDTK5EX14MBXC285r_" --_000_4E1F6AAD24975D4BA5B1680429673943668879DDTK5EX14MBXC285r_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Good analysis. +1 to creating something along the lines of (2). -- Mike ________________________________ From: Paul E. Jones Sent: 11/3/2012 7:50 AM To: 'Goix Laurent Walter'; 'Evan Prodromou'; apps-discuss@ietf.org Cc: webfinger@googlegroups.com; Mike Jones Subject: RE: [apps-discuss] R: High-level considerations about "webfinger" Walter, et al, (Apologizes for the length, but I think we have an important directional de= cision to make=85) I think down below you summarized the situation pretty well. While general= izing, what I think we have are two different camps. There are those who h= ave a preference for RFC 6415 as it=92s defined today. There are a list of= people who said they like the host-meta approach with host-specific and th= en separate resource-specific information and the use of templates (notably= the one for LRDD). Then there is the group who does not. They just want = to issue a single query and get back a single response. The latter group d= o not like templates and do not want to make two requests. Oh, and they do= not care one way or the other about preserving backward-compatibility with= RFC 6415. (Now, my statements about the two camps is a generalization, a = I said at the outset, and there are opinions that cross boundaries, but thi= s is the cleanest division I can see for the purposes of discussion.) What I=92ve tried to do is define a solution that would allow for a single = request/response, but would maintain a high-degree of interoperability betw= een this new document and 6415. As I was making changes to the draft and t= rying to take input, I was trying to think through how I could produce a so= lution to meet the requirements without a host-meta server modified in any = way, except for the addition of =93resource=94 and JRD support. Ignoring t= he editorial improvements that could be made, I think the current ALT-R1 dr= aft does that. You are entirely correct that this spec is looking more like SWD. There ar= e some very important distinctions, though. For one, SWD returns a single = link to a single request. It makes discovering lots of information about s= omebody a pain, IMO. It=92s primary purpose was to support OpenID Connect = and it works fine for that, but if I want to ask a sever to =93tell me ever= ything you know about Paul Jones=94, it cannot. RFC 6415 can, and I like t= hat. The difference is really a matter of the document returned. Also, th= ere is application-level kind of redirect in SWD (or was) that really shoul= d be an HTTP-level (3xx). I don=92t like that about SWD, either. Back to the two camps: neither is happy with the present solution (the -02 = draft). People who like the single request approach like this ALT drafts b= etter because XML is gone, there is a single resource to go query, and, of = course, there is a single request/response. People who are in the 6415 cam= p do are not happy with the -02 draft because we turn =93host metadata=94 i= nto =93resource=94 information: we merge the concepts. They also do not li= ke the ALT drafts for the same reason. However, even the 6415 camp does se= em to have an appreciation for a resource-centric approach that can use a s= ingle query. They just don=92t like the =93hack=94 (my term=85 that=92s th= e one negative word I don=92t think I=92ve had thrown in my face ;-) ). I believe you are right to point out that the one thing people seem to be g= enerally OK with is JRD. I think it=92s a simple format, nice to work with= , useful, and not overly complicated. Given that there are virtually no co= mments on the format, I gather people share the same sentiment. Now, having had conversations with a number of people both on the list and = off, I believe we need to decide which direction to take and I think there = are two choices: 1) We discard the current WebFinger draft and continue with RFC 6415 a= s-is 2) We re-write the spec in the spirit of the ALT versions, completely = breaking away from RFC 6415 by a. Removing all references to and dependencies on RFC 6415 b. Defining JRD within the WebFinger spec, specifying such things as = =93the order of link relations is significant=94 or other rules we want to = apply to the document c. Defining a new resource for this server at /.well-known/webfinger = (or swd ?) d. Using no templates whatsoever e. Using the =93resource=94 parameter as the current ALT draft has the= m (the concept of =93host metadata=94 does not exist with this draft; I=92m= not sure what the server should do if the resource parameter is absent, th= ough) f. (I would say use the =93rel=94 parameter, too, but some have real= ly expressed dissatisfaction with that. While I think it=92s wonderful in = order to reduce the number of link relations returned, some just saw no val= ue in that=85 even on narrow-band network connections.) If I understand the two camps, I think those are the two options before us.= I=92m sure there may be other things to do for option 2, but you get the = gist of where that is headed. More importantly, I am left with the impression that if we do go with optio= n 2, we will get support from both camps. Some of those who are in the 641= 5 camp just have an objective of not breaking what is there now and some ju= st don=92t want the =93hack=94 that is the current WF spec. But, I believe= most are all for a clean specification that defines a useful service and t= hat utilizes JRD to provide a set of link relations about a resource; a use= ful =93web discovery protocol=94. I just want a solution and would not be upset with either solution. What I= do not like, though, is having two or three solutions for discovery. At p= resent, we have RFC 6415, current WF draft, SWD, and draft-daboo-agreggate= d-service-discovery. That=92s a few too many ;-) I do have a high opinion of XRD/JRD, so I would like to see either or both = of those retained in any solution the group produces. Given that SWD exists, I take it that there is at least enough support to d= o something other than RFC 6415. I do not fully understand the reasons, exc= ept perhaps =93we want one round trip=94. I don=92t know. Perhaps someone = can educate me on the =93why=94. But, it does exist, so there is a reason = and it means we might end up with two solutions. So, can we avoid that? I=92d be ok with putting aside the WF spec in favor= a merger between SWD/WF. I don=92t want to call this a =93compromise=94, = but rather a clean solution that borrows from both: single round trip (like= SWD), a richer response with a set of links (JRD), adheres to and follows = HTTP procedures (e.g., no =93SWD_service_redirect=94 type construct; use 3x= x), has no templates in the JRD, allows any URI type (including =93acct:=94= ) as the =93subject=94 of the query, and is rooted at the host at some agre= ed location like /.well-known/swd. I believe if we do this, we have the greatest chance of getting the largest= number of people on board. Perhaps Mike or someone serve as editing, but = I=92d be happy to help co-author. I=92ll also write an implementation as I= did for RFC 6415; it should be simple to do. In any case, I do think there is a serious risk of failure if we continue d= own the current WF path, either because we end up with multiple competing s= olutions or because we alienate one of the two camps. So we either stick w= ith 6415 and stop spending time on this, or create something along the line= s of (2) where we can get nearly everyone on board. Paul From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Goix Laurent Walter Sent: Friday, November 02, 2012 11:30 AM To: Evan Prodromou; apps-discuss@ietf.org Subject: [apps-discuss] R: High-level considerations about "webfinger" Hi evan, I do have read the latest alt-r1 draft. But I do believe these are still ap= plicable questions: - I could still see pros/cons in the list for rel/resource paramet= ers in host-meta.json - The question of creating a new endpoint has been raised and stil= l pending imo (also wrt previous bullet) - Relationship with rfc6415 is still not clear as some parts are c= learly referenced (mostly procedures) whilst others mention a clear distanc= e with it (eg xrd vs jrd). As a developer I could not know very well whethe= r I need to implement rfc6415 and how much of it=85at this point one may co= nsider how much the draft gains in actually referencing those sections if i= t is to mandate the contrary=85 o In section 3 it reads =93the protocol builds on rfc6415=94, which is ve= ry unclear to which extent o Section 5 talks about backward-compatibility but basically says it =93m= ay not be=94. This is mainly to reuse jrd and =93host-meta.json=94 so it ma= y be more appropriate to call them out explicitly without any generic sente= nce (still if this is the feeling of the group) o Section 5.1 references section 4.2 of rfc6415 but actually introduces s= ome variants, so why not write a clean standalone text with no reference to= rfc6415? o Section 5.2 references an =93example=94 of rfc6415 section 1.1.1, but t= he value of that reference is not clear. Better probably to reference webfi= nger=92s own examples. - the very latest draft is still al =93ALT=94 at this stage=85 I=92m playing the devil=92s advocate here but do think that the various cam= ps intend very diverse usages of webfinger that maybe do not benefit of one= solution. It is a pity those use cases are not reflected in the simplistic= examples: I personally liked the openid one as I think opened connect woul= d be 1 candidate, but I=92ve heard about autoconfiguration (see oauth use c= ase) and federated social networks (the whole original point of it). All of= them are used in very different contexts (trusted/untrusted, intra-/inter-= domain) and will probably distinguish themselves from the actual link rels = they will use/expose=85 walter Da: apps-discuss-bounces@ietf.org [ma= ilto:apps-discuss-bounces@ietf.org] Per conto di Evan Prodromou Inviato: venerd=EC 2 novembre 2012 16.05 A: apps-discuss@ietf.org Oggetto: Re: [apps-discuss] High-level considerations about "webfinger" The conversation has really moved on! I suggest you read Paul Jones's lates= t email to get caught up. -Evan On 12-11-02 08:02 AM, Goix Laurent Walter wrote: Dear all, I tried to catch up with the hot discussion of the last days and would try = to hold on for the time of an email trying to summarize the current situati= on and take a breath=85 At this stage we are having very distinct camps in the list for what they h= ave in mind behind the =93webfinger=94 keyword: xml vs json, 1 or 2 roundtr= ips, privacy ecc. It seems to me that Paul has been doing an outstanding wo= rk trying to compromise (I would have lost patience=85) but such compromise= s do not seem to satisfy anyone: actually, compromises are moving more and = more towards the original SWD idea at the end. Maybe we could ask ourselves the following questions: - With the =93xrd=94 idea in mind (please, jrd-enthusiasts, try to= put that hat on as well), what is actually missing beyond rfc6415 for =93w= ebfinger=94? now the =91acct=92 URI is a separate draft (an initial motivat= ion). Rel/resource parameters for xrd supporters do not seem essential in m= y understanding neither. So (although I am a supports of that camp) I have = trouble seeing what truly need to be added. I can understand Evan=92s posit= ion for keeping the entire xrd-based community (ostatus, diaspora, etc) but= isn=92t rfc6415-compliance for those existing implementations already fair= enough? If a new =93webfinger=94 is jrd, 1-roundtrip only at the end it=92= s just another rfc number to be referenced instead/in addition and as such = has the same value=85(not mentioning the implementation work needed) - Rfc6415-compliance & backward compatibility: this seems also con= tentious as whether backward-compatibility is needed or not. however the cu= rrent =93compromises=94 are odd in maintaining backward-compability. What i= s exactly interesting for =93webfinger=94 from that rfc? From the latest al= ternative it seems only the =93host-meta.json=94 endpoint name & the jrd. O= r else? How these can be referenced at best without needing the whole thing= ? - Host-meta+lrdd vs new endpoint: Should we propose an alternative= endpoint name (there were many proposals, including one of mine a while ag= o) so that we simply =93distinguish=94 the existing host-meta+lrdd way from= a new =93webfinger=94 way/endpoint all-in-1-roundtrip. This is what swd is= proposing. Eventually one could at the end use the same backend implementa= tion to return queries coming all the way from host-meta+lrdd than others u= sing another well-known (and direct) endpoint. This would also be much easi= er to support any query parameter (resource, rel, etc) as some are arguing = against overriding host-meta with parameters. In that case the new =93webfi= nger=94 would be actually more like SWD (with JRD support) - In alternative, what about the provocative idea from Evan to =93= replace=94 rfc6415? Are they other usages of rfc6415 than the =93webfinger= =94 one throughout the community? If yes, then it may be more difficult to = replace unless agreed with whom is using it. Otherwise, as it seems most pe= ople do not like it, why keep it as-is and not upgrade directly to whatever= is now useful? A standard that is not used is useless and has no point in = being superseded by a parallel spec not actually obsoleting it... If JRD an= d the well-known endpoints are useful in other context, then why not splitt= ing them from the actual protocol procedures of current rfc6415 and have cl= ean specs that can be generically referenced without buying the full thing = or writing complex text to select some parts of it and contest others: 1 fo= r JRD and 1 for the endpoints/link registrations. Then a protocol-oriented = spec like webfinger can easily decide what to take and replace current rfc6= 415, or decide to live separately/parallel. Personally I have more interest and feeling for the 2-roundtrip xrd solutio= n from rfc6415 still. But if I have to choose between an odd/partial/unstab= le/unclear/buggy reference to it and a new json way for satisfying another = use case I have to put limits in compromising and at this point prefer a pa= rallel/independent approach. Of course I=92d like possibly to reuse the fil= e format (jrd) as it seems suitable for all. At least this way rfc6415 can = still live independently (being updated or not if we want to make it =93cle= aner=94) and =93webfinger=94 can hopefully be finalized quickly in the json= + 1 roundtrip direction=85 Once these macro topics are clarified then we can better discuss the detail= s about securing wf, supporting privacy, distinct delivery for auth/non-aut= h requests etc=85But can we first discuss at high level what we want to ach= ieve in terms of process? Cheers walter 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. [rispetta l'ambiente]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 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. [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non = =E8 necessario. --_000_4E1F6AAD24975D4BA5B1680429673943668879DDTK5EX14MBXC285r_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Good analysis= . +1 to creating something along the lines of (2).

-- Mike

From: Paul E= . Jones
Sent: 11/3/2= 012 7:50 AM
To: 'Goix = Laurent Walter'; 'Evan Prodromou'; apps-discuss@ietf.org
Cc: webfin= ger@googlegroups.com; Mike Jones
Subject: RE: [a= pps-discuss] R:  High-level considerations about "webfinger"=

Walter, et al,<= /p>

 

(Apologizes for the le= ngth, but I think we have an important directional decision to make=85)

 

I think down below you= summarized the situation pretty well.  While generalizing, what I thi= nk we have are two different camps.  There are those who have a prefer= ence for RFC 6415 as it=92s defined today.  There are a list of people who said they like the host-meta approach with host-s= pecific and then separate resource-specific information and the use of temp= lates (notably the one for LRDD).  Then there is the group who does no= t.  They just want to issue a single query and get back a single response.  The latter group do not like t= emplates and do not want to make two requests.  Oh, and they do not ca= re one way or the other about preserving backward-compatibility with RFC 64= 15.  (Now, my statements about the two camps is a generalization, a I said at the outset, and there are opinions that c= ross boundaries, but this is the cleanest division I can see for the purpos= es of discussion.)

 

What I=92ve tried to d= o is define a solution that would allow for a single request/response, but = would maintain a high-degree of interoperability between this new document = and 6415.  As I was making changes to the draft and trying to take input, I was trying to think through how I co= uld produce a solution to meet the requirements without a host-meta server = modified in any way, except for the addition of =93resource=94 and JRD supp= ort.  Ignoring the editorial improvements that could be made, I think the current ALT-R1 draft does that.

 

You are entirely corre= ct that this spec is looking more like SWD.  There are some very impor= tant distinctions, though.  For one, SWD returns a single link to a si= ngle request.  It makes discovering lots of information about somebody a pain, IMO.  It=92s primary purpose was to support Op= enID Connect and it works fine for that, but if I want to ask a sever to = =93tell me everything you know about Paul Jones=94, it cannot.  RFC 64= 15 can, and I like that.  The difference is really a matter of the document returned.  Also, there is application-level = kind of redirect in SWD (or was) that really should be an HTTP-level (3xx).=   I don=92t like that about SWD, either.

 

Back to the two camps:= neither is happy with the present solution (the -02 draft).  People w= ho like the single request approach like this ALT drafts better because XML= is gone, there is a single resource to go query, and, of course, there is a single request/response.  People wh= o are in the 6415 camp do are not happy with the -02 draft because we turn = =93host metadata=94 into =93resource=94 information: we merge the concepts.=   They also do not like the ALT drafts for the same reason.  However, even the 6415 camp does seem to have an apprec= iation for a resource-centric approach that can use a single query.  T= hey just don=92t like the =93hack=94 (my term=85 that=92s the one negative = word I don=92t think I=92ve had thrown in my face ;-) ).

 

I believe you are righ= t to point out that the one thing people seem to be generally OK with is JR= D.  I think it=92s a simple format, nice to work with, useful, and not= overly complicated.  Given that there are virtually no comments on the format, I gather people share the same sentim= ent.

 

Now, having had conver= sations with a number of people both on the list and off, I believe we need= to decide which direction to take and I think there are two choices:

1)      We discard the current W= ebFinger draft and continue with RFC 6415 as-is

2)      We re-write the spec in = the spirit of the ALT versions, completely breaking away from RFC 6415 by

a.       Removing all references = to and dependencies on RFC 6415

b.      Defining JRD within the = WebFinger spec, specifying such things as =93the order of link relations is= significant=94 or other rules we want to apply to the document

c.       Defining a new resource = for this server at /.well-known/webfinger (or swd ?)

d.      Using no templates whats= oever

e.      Using the =93resource=94= parameter as the current ALT draft has them (the concept of =93host metada= ta=94 does not exist with this draft; I=92m not sure what the server should= do if the resource parameter is absent, though)

f.        (I would say use the =93= rel=94 parameter, too, but some have really expressed dissatisfaction with = that.  While I think it=92s wonderful in order to reduce the number of= link relations returned, some just saw no value in that=85 even on narrow-band network connections.)

 

If I understand the tw= o camps, I think those are the two options before us.  I=92m sure ther= e may be other things to do for option 2, but you get the gist of where tha= t is headed.

 

More importantly, I am= left with the impression that if we do go with option 2, we will get suppo= rt from both camps.  Some of those who are in the 6415 camp just have = an objective of not breaking what is there now and some just don=92t want the =93hack=94 that is the current WF spec.=   But, I believe most are all for a clean specification that defines a= useful service and that utilizes JRD to provide a set of link relations ab= out a resource; a useful =93web discovery protocol=94.

 

I just want a solution= and would not be upset with either solution.  What I do not like, tho= ugh, is having two or three solutions for discovery.  At present, we h= ave RFC 6415, current WF draft, SWD, and  draft-daboo-agreggated-servi= ce-discovery.  That=92s a few too many ;-)

 

I do have a high opini= on of XRD/JRD, so I would like to see either or both of those retained in a= ny solution the group produces.

 

Given that SWD exists,= I take it that there is at least enough support to do something other than= RFC 6415. I do not fully understand the reasons, except perhaps =93we want= one round trip=94. I don=92t know.  Perhaps someone can educate me on the =93why=94.  But, it does exist, so ther= e is a reason and it means we might end up with two solutions.

 

So, can we avoid that?=   I=92d be ok with putting aside the WF spec in favor a merger between= SWD/WF.  I don=92t want to call this a =93compromise=94, but rather a= clean solution that borrows from both: single round trip (like SWD), a richer response with a set of links (JRD), adheres to and fo= llows HTTP procedures (e.g., no =93SWD_service_redirect=94 type construct; = use 3xx), has no templates in the JRD, allows any URI type (including =93ac= ct:=94) as the =93subject=94 of the query, and is rooted at the host at some agreed location like /.well-known/swd.

 

I believe if we do thi= s, we have the greatest chance of getting the largest number of people on b= oard.  Perhaps Mike or someone serve as editing, but I=92d be happy to= help co-author.  I=92ll also write an implementation as I did for RFC 6415; it should be simple to do.

 

In any case, I do thin= k there is a serious risk of failure if we continue down the current WF pat= h, either because we end up with multiple competing solutions or because we= alienate one of the two camps.  So we either stick with 6415 and stop spending time on this, or create someth= ing along the lines of (2) where we can get nearly everyone on board.

 

Paul

 

From: apps-discuss-bounces@ietf.org [mailto:apps-di= scuss-bounces@ietf.org] On Behalf Of Goix Laurent Walter
Sent: Friday, November 02, 2012 11:30 AM
To: Evan Prodromou; apps-discuss@ietf.org
Subject: [apps-discuss] R: High-level considerations about "web= finger"

 

Hi evan,

 

I do have read the lat= est alt-r1 draft. But I do believe these are still applicable questions:

-          I could still see pros/c= ons in the list for rel/resource parameters in host-meta.json

-          The question of creating= a new endpoint has been raised and still pending imo (also wrt previous bu= llet)

-          Relationship with rfc641= 5 is still not clear as some parts are clearly referenced (mostly procedure= s) whilst others mention a clear distance with it (eg xrd vs jrd). As a dev= eloper I could not know very well whether I need to implement rfc6415 and how much of it=85at this point one= may consider how much the draft gains in actually referencing those sectio= ns if it is to mandate the contrary=85

o &= nbsp; In section 3 it reads = =93the protocol builds on rfc6415=94, which is very unclear to which extent=

o &= nbsp; Section 5 talks about ba= ckward-compatibility but basically says it =93may not be=94. This is mainly= to reuse jrd and =93host-meta.json=94 so it may be more appropriate to cal= l them out explicitly without any generic sentence (still if this is the feeling of the group)

o &= nbsp; Section 5.1 references s= ection 4.2 of rfc6415 but actually introduces some variants, so why not wri= te a clean standalone text with no reference to rfc6415?

o &= nbsp; Section 5.2 references a= n =93example=94 of rfc6415 section 1.1.1, but the value of that reference i= s not clear. Better probably to reference webfinger=92s own examples.

-          the very latest draft is= still al =93ALT=94 at this stage=85

 

I=92m playing the devi= l=92s advocate here but do think that the various camps intend very diverse= usages of webfinger that maybe do not benefit of one solution. It is a pit= y those use cases are not reflected in the simplistic examples: I personally liked the openid one as I think opened c= onnect would be 1 candidate, but I=92ve heard about autoconfiguration (see = oauth use case) and federated social networks (the whole original point of = it). All of them are used in very different contexts (trusted/untrusted, intra-/inter-domain) and will proba= bly distinguish themselves from the actual link rels they will use/expose= =85

 

walter

 

 

The conversation has really moved = on! I suggest you read Paul Jones's latest email to get caught up.

-Evan

On 12-11-02 08:02 AM, Goix Laurent Walter wrote:

Dear all,

 

I tried to catch up with the hot discussion of the l= ast days and would try to hold on for the time of an email trying to summar= ize the current situation and take a breath=85

 

At this stage we are having very distinct camps in t= he list for what they have in mind behind the =93webfinger=94 keyword: xml = vs json, 1 or 2 roundtrips, privacy ecc. It seems to me that Paul has been = doing an outstanding work trying to compromise (I would have lost patience=85) but such compromises do not seem to satisf= y anyone: actually, compromises are moving more and more towards the origin= al SWD idea at the end.

 

Maybe we could ask ourselves the following questions= :

-=           With the =93xrd=94 idea in mind (please, jrd-enthusias= ts, try to put that hat on as well), what is actually missing beyond rfc641= 5 for =93webfinger=94? now the =91acct=92 URI is a separate draft (an initi= al motivation). Rel/resource parameters for xrd supporters do not seem essential in my understanding neither. So (alth= ough I am a supports of that camp) I have trouble seeing what truly need to= be added. I can understand Evan=92s position for keeping the entire xrd-ba= sed community (ostatus, diaspora, etc) but isn=92t rfc6415-compliance for those existing implementations alr= eady fair enough? If a new =93webfinger=94 is jrd, 1-roundtrip only at the = end it=92s just another rfc number to be referenced instead/in addition and= as such has the same value=85(not mentioning the implementation work needed)

 

-=           Rfc6415-compliance & backward compatibility: this = seems also contentious as whether backward-compatibility is needed or not. = however the current =93compromises=94 are odd in maintaining backward-compa= bility. What is exactly interesting for =93webfinger=94 from that rfc? From the latest alternative it seems only t= he =93host-meta.json=94 endpoint name & the jrd. Or else? How these can= be referenced at best without needing the whole thing?

 

-=           Host-meta+lrdd vs new endpoint: Should we propose = an alternative endpoint name (there were many proposals, including one of m= ine a while ago) so that we simply =93distinguish=94 the existing host-meta= +lrdd way from a new =93webfinger=94 way/endpoint all-in-1-roundtrip. This is what swd is proposing. Eventually one could at= the end use the same backend implementation to return queries coming all t= he way from host-meta+lrdd than others using another well-known (and di= rect) endpoint. This would also be much easier to support any query parameter (resource, rel, etc) as some are arg= uing against overriding host-meta with parameters. In that case the new =93= webfinger=94 would be actually more like SWD (with JRD support)

 

-=           In alternative, what about the provocative idea from E= van to =93replace=94 rfc6415? Are they other usages of rfc6415 than the =93= webfinger=94 one throughout the community? If yes, then it may be more diff= icult to replace unless agreed with whom is using it. Otherwise, as it seems most people do not like it, why keep i= t as-is and not upgrade directly to whatever is now useful? A standard that= is not used is useless and has no point in being superseded by a parallel = spec not actually obsoleting it... If JRD and the well-known endpoints are useful in other context, then why = not splitting them from the actual protocol procedures of current rfc6415 a= nd have clean specs that can be generically referenced without buying the f= ull thing or writing complex text to select some parts of it and contest others: 1 for JRD and 1 for the end= points/link registrations. Then a protocol-oriented spec like webfinger can= easily decide what to take and replace current rfc6415, or decide to live = separately/parallel.

 

 

Personally I have more interest and feeling for the = 2-roundtrip xrd solution from rfc6415 still. But if I have to choose betwee= n an odd/partial/unstable/unclear/buggy reference to it and a new json way = for satisfying another use case I have to put limits in compromising and at this point prefer a parallel/ind= ependent approach. Of course I=92d like possibly to reuse the file format (= jrd) as it seems suitable for all. At least this way rfc6415 can still live= independently (being updated or not if we want to make it =93cleaner=94) and =93webfinger=94 can hopefully be = finalized quickly in the json + 1 roundtrip direction=85

 

Once these macro topics are clarified then we can be= tter discuss the details about securing wf, supporting privacy, distinct de= livery for auth/non-auth requests etc=85But can we first discuss at high le= vel what we want to achieve in terms of process?

 

Cheers

walter

Questo messaggio e i suoi allegati sono indirizzati esclus= ivamente alle persone 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 an= d 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. 



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

 

Questo messaggio e i suoi allegati sono indirizzati esclus= ivamente alle persone 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_4E1F6AAD24975D4BA5B1680429673943668879DDTK5EX14MBXC285r_-- --_004_4E1F6AAD24975D4BA5B1680429673943668879DDTK5EX14MBXC285r_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=677; creation-date="Sat, 03 Nov 2012 06:50:52 GMT"; modification-date="Sat, 03 Nov 2012 06:50:52 GMT" Content-ID: Content-Transfer-Encoding: base64 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= --_004_4E1F6AAD24975D4BA5B1680429673943668879DDTK5EX14MBXC285r_-- From bradfitz@google.com Sat Nov 3 04:48: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 31B9C21F9C68 for ; Sat, 3 Nov 2012 04:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.578, 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 n9d1meHASjS3 for ; Sat, 3 Nov 2012 04:48:52 -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 6478921F9C65 for ; Sat, 3 Nov 2012 04:48:52 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so4698951obq.31 for ; Sat, 03 Nov 2012 04:48:51 -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=JPyq6YRa3GWOJaBjQn9AAJ1ZL9QAR8aSuOAQPPh1PRI=; b=YrZ/ysXSA8vf5ESEBoZIFNIDJLWv5TcXfBP6uZ2qP0G1+UBmKbaC60BVsu2vMQbY9d oWAyKiRIsIa4qe+WZT1dTzYvn79+WFwwZE2hYgdMHgYUr60XH3h71RXftSCsWz6kyPIp EnaKoV12WhPDs1c7aCLKEqK6ZwXfM2O/6k+hwHNvP5MogSgUrQMrkgj7/nJhgQ1w11Zg CpyJ2gDyB2yq3r482RVRrpYv3lKh9xjgEofLzeLqflbBgv4FZUOFiF0lEuFWDDxXnNfC kk8Ib4HCT4LIV0jwqDUlnfitdN0ig5QaBorUNtAF1vk/rMh2/3CQzbuLnRBp/ZCemwuQ MlTg== 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=JPyq6YRa3GWOJaBjQn9AAJ1ZL9QAR8aSuOAQPPh1PRI=; b=Kf9MlzHHXZADvKbZce3ZVDQUWSLaUnh/NU9V3yNQwp0KHPCBu6zEP6G+rI4/VxeRAa JgxRBJQKqx20Cl5GeUphmP1luL3a/5tgt7F840vxUHDE6J507XjA7VgGFsqeqbwpdfYF dJnIPutGidG+g1NI9ZegsnCI1RCkm8owUiq2BIXP7lxJHMobTP7+RVFO8PimZQyb5cfM zttcGi1Hkeipvm+XoWog7cqC+iUNsmUjhjQgn3ZjuKDgE3MT/yEfkeAdydcGsVZrCxGk cVy05Vb5rcVfqzkz4MQPv5dx91I1krRTWpOtnuxFALb2S9cIc9Y11lHWI2Dg01FcNBE+ WsDA== MIME-Version: 1.0 Received: by 10.60.169.234 with SMTP id ah10mr3661663oec.12.1351943331789; Sat, 03 Nov 2012 04:48:51 -0700 (PDT) Received: by 10.60.31.41 with HTTP; Sat, 3 Nov 2012 04:48:51 -0700 (PDT) In-Reply-To: <20121103103608.19cc37d1@bogo> References: <5093E105.2090302@status.net> <054501cdb98f$8f77fe00$ae67fa00$@packetizer.com> <20121103103608.19cc37d1@bogo> Date: Sat, 3 Nov 2012 12:48:51 +0100 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com, Paul Jones Content-Type: multipart/alternative; boundary=bcaec54d4d8e0c3ab504cd95d653 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlvdE4O00Ogym8qADdqCoFPvxEsyBHiIRVGkp1gsq6EehVsRHAKmzh3W14/1q6ltMuveAf5ys4D/2XsLJNaSmYdeNEVXK0NXbmz0D6BsRv4tu0+WvGIsy4tKoNoMRZHz7JaYnQf1FoYMfVO7BNI7Ee+xufdiL7MoBKsigL80E97HYRqlJRap/NrDUAeXbzUn6k/CU3j X-Mailman-Approved-At: Sat, 03 Nov 2012 08:06:38 -0700 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] High-level considerations about "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, 03 Nov 2012 11:48:53 -0000 --bcaec54d4d8e0c3ab504cd95d653 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not against a single round-trip, but I am against abusing host-meta with query params. I have no problems with JRD as a response format. I'm in support of dropping webfinger's dependency on RFC 6415, using /.well-known/webfinger instead (and thus not abusing host-meta), and keeping with one round trip. If you want to query a host, use /.well-known/host-meta{,.json}. If you want to query a user@host, use /.well-known/webfinger?rel=3D...&resource=3D.... Both are one round-trip, CORS, etc. (Background: years ago I was advocating two round-trips, one for host discovery and then one for making the webfinger query, because I was worried about global load balancing and large organization politics of who owns what parts of the HTTP namespace, but I'm much less worried about that these days. It's not a problem for small orgs and individuals, and it's not a problem for Google, so I'm fine accepting that it's not actually a problem worth worrying about.) So count me in for +1 on single round-trip and /.well-known/webfinger and even dropping templates. Christian makes a good point that host-meta upgrades well to discovering the /.well-known/webfinger endpoint for legacy clients. - Brad On Sat, Nov 3, 2012 at 10:36 AM, Christian Weiske wrote= : > Hello Paul, > > > > c. Defining a new resource for this server > > at /.well-known/webfinger (or swd ?) > > I was for long in the RFC 6415 camp, and I still am. Reusing existing > standards makes much sense in my eyes. > > Given that people like the one request approach (I do see its > benefits, too), and that adding a resource parameter to host-meta is a > dirty hack, I'd rather go with a new resource - /.well-known/webfinger. > > This separates it cleanly, allows the one request solution without > hacks, and is even backward compatible with existing clients if the > lrdd link is changed to /.well-known/webfinger?resource=3D{uri}. > Not that it is that important, but it's nice to have. > > > -- > Regards/Mit freundlichen Gr=C3=BC=C3=9Fen > Christian Weiske > > -=3D=E2=89=A1 Geeking around in the name of science since 1982 =E2=89=A1= =3D- > --bcaec54d4d8e0c3ab504cd95d653 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= div>I'm not against a single round-trip, but I am against abusing host-= meta with query params.

I have no problems wit= h JRD as a response format.

I'm in support of dropping webfinger's dependency on= RFC 6415, using /.well-known/webfinger instead (and thus not abusing host-= meta), and keeping with one round trip.

If you want to q= uery a host, use /.well-known/host-meta{,.json}.
If you want to query a user@host, use /.well-known/webfinger?rel=3D...= &resource=3D....

Both are one round-trip, CORS= , etc.

(Background: years ago I was advocating two= round-trips, one for host discovery and then one for making the webfinger = query, because I was worried about global load balancing and large organiza= tion politics of who owns what parts of the HTTP namespace, but I'm muc= h less worried about that these days. =C2=A0It's not a problem for smal= l orgs and individuals, and it's not a problem for Google, so I'm f= ine accepting that it's not actually a problem worth worrying about.)

So count me in for +1 on single round-trip and /.well-k= nown/webfinger and even dropping templates.

Christ= ian makes a good point that host-meta upgrades well to discovering the /.we= ll-known/webfinger endpoint for legacy clients.

- Brad


On Sat, Nov 3, 2012 at 10:36 AM, Christian Weiske <= span dir=3D"ltr"><cweiske@cweiske.de> wrote:
Hello Paul,


> c. =C2=A0 =C2=A0 =C2=A0 Defining a new resource for this server
> at /.well-known/webfinger (or swd ?)

I was for long in the RFC 6415 camp, and I still am. Reusing existing=
standards makes much sense in my eyes.

Given that people like the one request approach (I do see its
benefits, too), and that adding a resource parameter to host-meta is a
dirty hack, I'd rather go with a new resource - /.well-known/webfinger.=

This separates it cleanly, allows the one request solution without
hacks, and is even backward compatible with existing clients if the
lrdd link is changed to /.well-known/webfinger?resource=3D{uri}.
Not that it is that important, but it's nice to have.


--
Regards/Mit freundlichen Gr=C3=BC=C3=9Fen
Christian Weiske

-=3D=E2=89=A1 Geeking around in the name of science since 1982 =E2=89=A1=3D= -

--bcaec54d4d8e0c3ab504cd95d653-- From cweiske@cweiske.de Sat Nov 3 02:36: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 B26D821F9C60 for ; Sat, 3 Nov 2012 02:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 3E4JV1HlaB3n for ; Sat, 3 Nov 2012 02:36:11 -0700 (PDT) Received: from mail.cweiske.de (mail.cweiske.de [IPv6:2a01:488:66:1000:53a9:7c6:0:1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E66A21F9C5B for ; Sat, 3 Nov 2012 02:36:11 -0700 (PDT) Received: by mail.cweiske.de (Postfix, from userid 65534) id 91A2810448002; Sat, 3 Nov 2012 10:36:09 +0100 (CET) Received: from bogo (p54BD7CAF.dip.t-dialin.net [84.189.124.175]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.cweiske.de (Postfix) with ESMTPSA id 4A68F10438003; Sat, 3 Nov 2012 10:36:09 +0100 (CET) Date: Sat, 3 Nov 2012 10:36:08 +0100 From: Christian Weiske To: webfinger@googlegroups.com, Message-ID: <20121103103608.19cc37d1@bogo> In-Reply-To: <054501cdb98f$8f77fe00$ae67fa00$@packetizer.com> References: <5093E105.2090302@status.net> <054501cdb98f$8f77fe00$ae67fa00$@packetizer.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/DpT/oosrZuogoV0Ou1rLXqg"; protocol="application/pgp-signature" X-Mailman-Approved-At: Sat, 03 Nov 2012 08:06:51 -0700 Subject: Re: [apps-discuss] High-level considerations about "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, 03 Nov 2012 09:36:11 -0000 --Sig_/DpT/oosrZuogoV0Ou1rLXqg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Paul, > c. Defining a new resource for this server > at /.well-known/webfinger (or swd ?) I was for long in the RFC 6415 camp, and I still am. Reusing existing standards makes much sense in my eyes. Given that people like the one request approach (I do see its benefits, too), and that adding a resource parameter to host-meta is a dirty hack, I'd rather go with a new resource - /.well-known/webfinger. This separates it cleanly, allows the one request solution without hacks, and is even backward compatible with existing clients if the lrdd link is changed to /.well-known/webfinger?resource=3D{uri}. Not that it is that important, but it's nice to have. --=20 Regards/Mit freundlichen Gr=C3=BC=C3=9Fen Christian Weiske -=3D=E2=89=A1 Geeking around in the name of science since 1982 =E2=89=A1=3D- --Sig_/DpT/oosrZuogoV0Ou1rLXqg Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlCU5YgACgkQFMhaCCTq+COfLwCg0tPwz4feZx5JqLKmerUlZp2o kzEAoJbncLkPJOOrq35mgq7IIgMrne5D =SJCM -----END PGP SIGNATURE----- --Sig_/DpT/oosrZuogoV0Ou1rLXqg-- From laurentwalter.goix@telecomitalia.it Sat Nov 3 08:22: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 8FCAD21F9BE1 for ; Sat, 3 Nov 2012 08:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.015 X-Spam-Level: X-Spam-Status: No, score=-1.015 tagged_above=-999 required=5 tests=[AWL=0.703, 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 LjEI91F3EFFS for ; Sat, 3 Nov 2012 08:22:12 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id D9B1821F99CC for ; Sat, 3 Nov 2012 08:22:10 -0700 (PDT) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Sat, 3 Nov 2012 16:22:03 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Sat, 3 Nov 2012 16:22:03 +0100 From: Goix Laurent Walter To: "Paul E. Jones" Date: Sat, 3 Nov 2012 16:21:55 +0100 Thread-Topic: [apps-discuss] R: High-level considerations about "webfinger" Thread-Index: Ac251vlAhlcH1m6pQomLKyjQTVRwyQ== Message-ID: <5BE71165-CE5F-4B5C-ACE9-63CA659B4987@telecomitalia.it> References: <5093E105.2090302@status.net> <054501cdb98f$8f77fe00$ae67fa00$@packetizer.com> In-Reply-To: <054501cdb98f$8f77fe00$ae67fa00$@packetizer.com> Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: multipart/alternative; boundary="_000_5BE71165CE5F4B5CACE963CA659B4987telecomitaliait_" MIME-Version: 1.0 Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] R: High-level considerations about "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, 03 Nov 2012 15:22:14 -0000 --_000_5BE71165CE5F4B5CACE963CA659B4987telecomitaliait_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFBhdWwhIEl0IHJlbWluZHMgbWUgb2YgYW4gZWFybHkgZGlzY3Vzc2lvbiB3ZSBoYWQg b24gdGhpcyBhYm91dCBkb2N1bWVudC1vcmllbnRlZCB2cyBBUEkgYXBwcm9hY2guIE9wdGlvbiAy LCBwcm9iYWJseSB0aGUgYmVzdCB3YXkgZm9yd2FyZCwgaXMgYSBzb3J0IG9mIEFQSS4uLndlIGNh biBkZWZpbmUgcGFyYW1ldGVycyBldGMuDQpJZiB0aGUgZ3JvdXAgc3RpY2tzIHdpdGggSnJkIGFu ZCB0aGUgb3RoZXIgY29uc2lkZXJhdGlvbnMgeW91IG1hZGUgb24gaHR0cCByZWRpcmVjdHMgZXRj IEkgZG8gZ3Vlc3MgdGhpcyBpcyBhIGNsZWFuIEFQSSAob25lIGNvdWxkIGV2ZW4gdGhpbmsgb2Yg UE9TVC9QVVQvREVMRVRFIGZvciB0aGlzIDopICkuIEFuZCBpdCBsZWF2ZXMgNjQxNSB1bmNoYW5n ZWQgYW5kIHdvcmtpbmcuIFNvbWUgY291bGQgc2F5IHVzZWxlc3MgaWYgd2Yvc3dkIG1lcmdlciBp cyBjcmVhdGVkLCBidXQgYWN0dWFsbHkgdGhpcyB3YXkgd2UgYnVpbGQgc29tZXRoaW5nIHBhcmFs bGVsL2luZGVwZW5kZW50IGluZGVlZCwgc28gNjQxNSBoYXMgc3RpbGwgaXRzIGRpZ25pdHkgYW5k IGlzIG5vdCBicm9rZW4gaW50byBnb29kIGFuZCBiYWQgcGFydHMuLi4NCg0KUGVyc29uYWxseSwg Zm9yIG15IG93biB2aWV3IG9mIGZlZGVyYXRlZCBzb2NpYWwgbmV0d29ya3MgYW5kIG15IE9NQSBo YXQgb24sICBJIGRvIHdvdWxkIHNwb25zb3IgYW4gNjQxNS1iYXNlZCBzb2x1dGlvbiBhY3Jvc3Mg c29jaWFsIG5ldHdvcmsgcHJvdmlkZXJzIGZvciBwZWVyaW5nIGFuZCBjcm9zcy1kaXNjb3Zlcnku DQpCdXQgSSBkbyBzZWUgdmFsdWUgaW4gYSBuZXcganNvbi1iYXNlZCBBUEkvZW5kcG9pbnQgZm9y IG90aGVyIHVzZSBjYXNlcyBhbmQgYW0gd2lsbGluZyB0byBoZWxwLiBOb3RlIHRoYXQgdGhpcyBj b3VsZCBhY3R1YWxseSBiZSB2aWV3IGFzIHN0YW5kYXJkaXppbmcgdGhlICdMcmRkJyBlbmRwb2lu dCA6KSAoYWx0aG91Z2gganNvbi1vbmx5KSBzbyBJIHN0aWxsIHNlZSBpdCBzb21laG93IGNvbXBh dGlibGUgd2l0aCB0aGUgZXhpc3RpbmcgNjQxNSBmcmFtZXdvcmsuLi5pZiB3ZSBuYW1lIHRoZSBl bmRwb2ludCAud2VsbC1rbm93bi9scmRkIHdlIGV2ZW4gYXZvaWQgdGhlIHdmL3N3ZCBuYW1lIGJh dHRsZSA7KQ0KDQpNb3Zpbmcgb24gdG93YXJkcyBvcHRpb24gMiwgSSBkbyBoYXZlIHN0aWxsIHRo ZSBmb2xsb3dpbmcgY29uY2VybnM6DQotIHdvdWxkIHRoZSB3aG9sZSBhY3Rpdml0eSBhbnl3YXkg YmVuZWZpdCBmcm9tIHNsaWdodGx5IHVwZGF0aW5nIDY0MTUgaW4gcGFyYWxsZWwgb2YgdGhlIHdm IGFjdGl2aXR5IGVnIHRvIGNhbGwganJkIG91dCBvZiBhIHNpbXBsZSBhcHBlbmRpeCBmb3IgYSBj bGVhbmVyIHJlZmVyZW5jZSAocG90ZW50aWFsbHkgYWxzbyBieSBvdGhlciBzcGVjcyBpbiB0aGUg ZnV0dXJlKSwgYW5kIG1heWJlIHdpdGggb3RoZXIgdGhpbmdzIGFzIHdlbGwgc3VjaCBhcyBjb3Jz IG9yIGVsc2U/IFdoYXQgaXMgdGhlIHZpZXcgb2YgdGhlIGF1dGhvcnMgb2YgNjQxNT8NCg0KLSBJ IHN0aWxsIHNlZSB0aGF0IHRoZSBtb3N0IHJlbGV2YW50IHVzZSBjYXNlcyBkaXNjdXNzZWQgb3Zl ciB0aGUgbGFzdCBtb250aHMgYXJlIGFjdHVhbGx5IG1pc3NpbmcgZnJvbSB0aGUgdGV4dC4gRnNu LCBvcGVuaWQgY29ubmVjdCwgYXV0byBjb25maWd1cmF0aW9uICYgJ2NvbnRhY3QgZW5yaWNobWVu dCcgYXJlIDQgbWFpbiB1c2UgY2FzZXMgd2l0aCB2ZXJ5IGRpZmZlcmVudCBuZWVkcyB0aGF0IHdv dWxkIGRlc2VydmUgYmVpbmcgbWVudGlvbmVkIGV4cGxpY2l0bHkuDQoNCkFzIGEgc2lkZSBjb21t ZW50LCBJIG1heSBiZSB0b28gb3B0aW1pc3RpYy9xdWljayBidXQgSSdkIGFsc28gbGlrZSB0byB3 b3JrIHdpdGggd2hvZXZlciBpcyBpbnRlcmVzdGVkIGF0IGFuYWx5emluZyBsaW5rIHJlbHMgcmVs ZXZhbnQgZm9yIHRoZSBmc24gdXNlIGNhc2UgaW4gcGFydGljdWxhciBhbmQgcG9zc2libHkgaGF2 ZSBzb21lIG9mIHRoZW0gcmVnaXN0ZXJlZCBpZiBtaXNzaW5nIHRvIHBhdmUgdGhlIHdheSBmb3Ig aW50ZXJvcGVyYWJpbGl0eS4NCg0KV2FsdGVyDQoNCkxlIDMgbm92LiAyMDEyIMOgIDA3OjUwLCAi UGF1bCBFLiBKb25lcyIgPHBhdWxlakBwYWNrZXRpemVyLmNvbTxtYWlsdG86cGF1bGVqQHBhY2tl dGl6ZXIuY29tPj4gYSDDqWNyaXQgOg0KDQpXYWx0ZXIsIGV0IGFsLA0KDQooQXBvbG9naXplcyBm b3IgdGhlIGxlbmd0aCwgYnV0IEkgdGhpbmsgd2UgaGF2ZSBhbiBpbXBvcnRhbnQgZGlyZWN0aW9u YWwgZGVjaXNpb24gdG8gbWFrZeKApikNCg0KSSB0aGluayBkb3duIGJlbG93IHlvdSBzdW1tYXJp emVkIHRoZSBzaXR1YXRpb24gcHJldHR5IHdlbGwuICBXaGlsZSBnZW5lcmFsaXppbmcsIHdoYXQg SSB0aGluayB3ZSBoYXZlIGFyZSB0d28gZGlmZmVyZW50IGNhbXBzLiAgVGhlcmUgYXJlIHRob3Nl IHdobyBoYXZlIGEgcHJlZmVyZW5jZSBmb3IgUkZDIDY0MTUgYXMgaXTigJlzIGRlZmluZWQgdG9k YXkuICBUaGVyZSBhcmUgYSBsaXN0IG9mIHBlb3BsZSB3aG8gc2FpZCB0aGV5IGxpa2UgdGhlIGhv c3QtbWV0YSBhcHByb2FjaCB3aXRoIGhvc3Qtc3BlY2lmaWMgYW5kIHRoZW4gc2VwYXJhdGUgcmVz b3VyY2Utc3BlY2lmaWMgaW5mb3JtYXRpb24gYW5kIHRoZSB1c2Ugb2YgdGVtcGxhdGVzIChub3Rh Ymx5IHRoZSBvbmUgZm9yIExSREQpLiAgVGhlbiB0aGVyZSBpcyB0aGUgZ3JvdXAgd2hvIGRvZXMg bm90LiAgVGhleSBqdXN0IHdhbnQgdG8gaXNzdWUgYSBzaW5nbGUgcXVlcnkgYW5kIGdldCBiYWNr IGEgc2luZ2xlIHJlc3BvbnNlLiAgVGhlIGxhdHRlciBncm91cCBkbyBub3QgbGlrZSB0ZW1wbGF0 ZXMgYW5kIGRvIG5vdCB3YW50IHRvIG1ha2UgdHdvIHJlcXVlc3RzLiAgT2gsIGFuZCB0aGV5IGRv IG5vdCBjYXJlIG9uZSB3YXkgb3IgdGhlIG90aGVyIGFib3V0IHByZXNlcnZpbmcgYmFja3dhcmQt Y29tcGF0aWJpbGl0eSB3aXRoIFJGQyA2NDE1LiAgKE5vdywgbXkgc3RhdGVtZW50cyBhYm91dCB0 aGUgdHdvIGNhbXBzIGlzIGEgZ2VuZXJhbGl6YXRpb24sIGEgSSBzYWlkIGF0IHRoZSBvdXRzZXQs IGFuZCB0aGVyZSBhcmUgb3BpbmlvbnMgdGhhdCBjcm9zcyBib3VuZGFyaWVzLCBidXQgdGhpcyBp cyB0aGUgY2xlYW5lc3QgZGl2aXNpb24gSSBjYW4gc2VlIGZvciB0aGUgcHVycG9zZXMgb2YgZGlz Y3Vzc2lvbi4pDQoNCldoYXQgSeKAmXZlIHRyaWVkIHRvIGRvIGlzIGRlZmluZSBhIHNvbHV0aW9u IHRoYXQgd291bGQgYWxsb3cgZm9yIGEgc2luZ2xlIHJlcXVlc3QvcmVzcG9uc2UsIGJ1dCB3b3Vs ZCBtYWludGFpbiBhIGhpZ2gtZGVncmVlIG9mIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiB0aGlz IG5ldyBkb2N1bWVudCBhbmQgNjQxNS4gIEFzIEkgd2FzIG1ha2luZyBjaGFuZ2VzIHRvIHRoZSBk cmFmdCBhbmQgdHJ5aW5nIHRvIHRha2UgaW5wdXQsIEkgd2FzIHRyeWluZyB0byB0aGluayB0aHJv dWdoIGhvdyBJIGNvdWxkIHByb2R1Y2UgYSBzb2x1dGlvbiB0byBtZWV0IHRoZSByZXF1aXJlbWVu dHMgd2l0aG91dCBhIGhvc3QtbWV0YSBzZXJ2ZXIgbW9kaWZpZWQgaW4gYW55IHdheSwgZXhjZXB0 IGZvciB0aGUgYWRkaXRpb24gb2Yg4oCccmVzb3VyY2XigJ0gYW5kIEpSRCBzdXBwb3J0LiAgSWdu b3JpbmcgdGhlIGVkaXRvcmlhbCBpbXByb3ZlbWVudHMgdGhhdCBjb3VsZCBiZSBtYWRlLCBJIHRo aW5rIHRoZSBjdXJyZW50IEFMVC1SMSBkcmFmdCBkb2VzIHRoYXQuDQoNCllvdSBhcmUgZW50aXJl bHkgY29ycmVjdCB0aGF0IHRoaXMgc3BlYyBpcyBsb29raW5nIG1vcmUgbGlrZSBTV0QuICBUaGVy ZSBhcmUgc29tZSB2ZXJ5IGltcG9ydGFudCBkaXN0aW5jdGlvbnMsIHRob3VnaC4gIEZvciBvbmUs IFNXRCByZXR1cm5zIGEgc2luZ2xlIGxpbmsgdG8gYSBzaW5nbGUgcmVxdWVzdC4gIEl0IG1ha2Vz IGRpc2NvdmVyaW5nIGxvdHMgb2YgaW5mb3JtYXRpb24gYWJvdXQgc29tZWJvZHkgYSBwYWluLCBJ TU8uICBJdOKAmXMgcHJpbWFyeSBwdXJwb3NlIHdhcyB0byBzdXBwb3J0IE9wZW5JRCBDb25uZWN0 IGFuZCBpdCB3b3JrcyBmaW5lIGZvciB0aGF0LCBidXQgaWYgSSB3YW50IHRvIGFzayBhIHNldmVy IHRvIOKAnHRlbGwgbWUgZXZlcnl0aGluZyB5b3Uga25vdyBhYm91dCBQYXVsIEpvbmVz4oCdLCBp dCBjYW5ub3QuICBSRkMgNjQxNSBjYW4sIGFuZCBJIGxpa2UgdGhhdC4gIFRoZSBkaWZmZXJlbmNl IGlzIHJlYWxseSBhIG1hdHRlciBvZiB0aGUgZG9jdW1lbnQgcmV0dXJuZWQuICBBbHNvLCB0aGVy ZSBpcyBhcHBsaWNhdGlvbi1sZXZlbCBraW5kIG9mIHJlZGlyZWN0IGluIFNXRCAob3Igd2FzKSB0 aGF0IHJlYWxseSBzaG91bGQgYmUgYW4gSFRUUC1sZXZlbCAoM3h4KS4gIEkgZG9u4oCZdCBsaWtl IHRoYXQgYWJvdXQgU1dELCBlaXRoZXIuDQoNCkJhY2sgdG8gdGhlIHR3byBjYW1wczogbmVpdGhl ciBpcyBoYXBweSB3aXRoIHRoZSBwcmVzZW50IHNvbHV0aW9uICh0aGUgLTAyIGRyYWZ0KS4gIFBl b3BsZSB3aG8gbGlrZSB0aGUgc2luZ2xlIHJlcXVlc3QgYXBwcm9hY2ggbGlrZSB0aGlzIEFMVCBk cmFmdHMgYmV0dGVyIGJlY2F1c2UgWE1MIGlzIGdvbmUsIHRoZXJlIGlzIGEgc2luZ2xlIHJlc291 cmNlIHRvIGdvIHF1ZXJ5LCBhbmQsIG9mIGNvdXJzZSwgdGhlcmUgaXMgYSBzaW5nbGUgcmVxdWVz dC9yZXNwb25zZS4gIFBlb3BsZSB3aG8gYXJlIGluIHRoZSA2NDE1IGNhbXAgZG8gYXJlIG5vdCBo YXBweSB3aXRoIHRoZSAtMDIgZHJhZnQgYmVjYXVzZSB3ZSB0dXJuIOKAnGhvc3QgbWV0YWRhdGHi gJ0gaW50byDigJxyZXNvdXJjZeKAnSBpbmZvcm1hdGlvbjogd2UgbWVyZ2UgdGhlIGNvbmNlcHRz LiAgVGhleSBhbHNvIGRvIG5vdCBsaWtlIHRoZSBBTFQgZHJhZnRzIGZvciB0aGUgc2FtZSByZWFz b24uICBIb3dldmVyLCBldmVuIHRoZSA2NDE1IGNhbXAgZG9lcyBzZWVtIHRvIGhhdmUgYW4gYXBw cmVjaWF0aW9uIGZvciBhIHJlc291cmNlLWNlbnRyaWMgYXBwcm9hY2ggdGhhdCBjYW4gdXNlIGEg c2luZ2xlIHF1ZXJ5LiAgVGhleSBqdXN0IGRvbuKAmXQgbGlrZSB0aGUg4oCcaGFja+KAnSAobXkg dGVybeKApiB0aGF04oCZcyB0aGUgb25lIG5lZ2F0aXZlIHdvcmQgSSBkb27igJl0IHRoaW5rIEni gJl2ZSBoYWQgdGhyb3duIGluIG15IGZhY2UgOy0pICkuDQoNCkkgYmVsaWV2ZSB5b3UgYXJlIHJp Z2h0IHRvIHBvaW50IG91dCB0aGF0IHRoZSBvbmUgdGhpbmcgcGVvcGxlIHNlZW0gdG8gYmUgZ2Vu ZXJhbGx5IE9LIHdpdGggaXMgSlJELiAgSSB0aGluayBpdOKAmXMgYSBzaW1wbGUgZm9ybWF0LCBu aWNlIHRvIHdvcmsgd2l0aCwgdXNlZnVsLCBhbmQgbm90IG92ZXJseSBjb21wbGljYXRlZC4gIEdp dmVuIHRoYXQgdGhlcmUgYXJlIHZpcnR1YWxseSBubyBjb21tZW50cyBvbiB0aGUgZm9ybWF0LCBJ IGdhdGhlciBwZW9wbGUgc2hhcmUgdGhlIHNhbWUgc2VudGltZW50Lg0KDQpOb3csIGhhdmluZyBo YWQgY29udmVyc2F0aW9ucyB3aXRoIGEgbnVtYmVyIG9mIHBlb3BsZSBib3RoIG9uIHRoZSBsaXN0 IGFuZCBvZmYsIEkgYmVsaWV2ZSB3ZSBuZWVkIHRvIGRlY2lkZSB3aGljaCBkaXJlY3Rpb24gdG8g dGFrZSBhbmQgSSB0aGluayB0aGVyZSBhcmUgdHdvIGNob2ljZXM6DQoNCjEpICAgICAgV2UgZGlz Y2FyZCB0aGUgY3VycmVudCBXZWJGaW5nZXIgZHJhZnQgYW5kIGNvbnRpbnVlIHdpdGggUkZDIDY0 MTUgYXMtaXMNCg0KMikgICAgICBXZSByZS13cml0ZSB0aGUgc3BlYyBpbiB0aGUgc3Bpcml0IG9m IHRoZSBBTFQgdmVyc2lvbnMsIGNvbXBsZXRlbHkgYnJlYWtpbmcgYXdheSBmcm9tIFJGQyA2NDE1 IGJ5DQoNCmEuICAgICAgIFJlbW92aW5nIGFsbCByZWZlcmVuY2VzIHRvIGFuZCBkZXBlbmRlbmNp ZXMgb24gUkZDIDY0MTUNCg0KYi4gICAgICBEZWZpbmluZyBKUkQgd2l0aGluIHRoZSBXZWJGaW5n ZXIgc3BlYywgc3BlY2lmeWluZyBzdWNoIHRoaW5ncyBhcyDigJx0aGUgb3JkZXIgb2YgbGluayBy ZWxhdGlvbnMgaXMgc2lnbmlmaWNhbnTigJ0gb3Igb3RoZXIgcnVsZXMgd2Ugd2FudCB0byBhcHBs eSB0byB0aGUgZG9jdW1lbnQNCg0KYy4gICAgICAgRGVmaW5pbmcgYSBuZXcgcmVzb3VyY2UgZm9y IHRoaXMgc2VydmVyIGF0IC8ud2VsbC1rbm93bi93ZWJmaW5nZXIgKG9yIHN3ZCA/KQ0KDQpkLiAg ICAgIFVzaW5nIG5vIHRlbXBsYXRlcyB3aGF0c29ldmVyDQoNCmUuICAgICAgVXNpbmcgdGhlIOKA nHJlc291cmNl4oCdIHBhcmFtZXRlciBhcyB0aGUgY3VycmVudCBBTFQgZHJhZnQgaGFzIHRoZW0g KHRoZSBjb25jZXB0IG9mIOKAnGhvc3QgbWV0YWRhdGHigJ0gZG9lcyBub3QgZXhpc3Qgd2l0aCB0 aGlzIGRyYWZ0OyBJ4oCZbSBub3Qgc3VyZSB3aGF0IHRoZSBzZXJ2ZXIgc2hvdWxkIGRvIGlmIHRo ZSByZXNvdXJjZSBwYXJhbWV0ZXIgaXMgYWJzZW50LCB0aG91Z2gpDQoNCmYuICAgICAgICAoSSB3 b3VsZCBzYXkgdXNlIHRoZSDigJxyZWzigJ0gcGFyYW1ldGVyLCB0b28sIGJ1dCBzb21lIGhhdmUg cmVhbGx5IGV4cHJlc3NlZCBkaXNzYXRpc2ZhY3Rpb24gd2l0aCB0aGF0LiAgV2hpbGUgSSB0aGlu ayBpdOKAmXMgd29uZGVyZnVsIGluIG9yZGVyIHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mIGxpbmsg cmVsYXRpb25zIHJldHVybmVkLCBzb21lIGp1c3Qgc2F3IG5vIHZhbHVlIGluIHRoYXTigKYgZXZl biBvbiBuYXJyb3ctYmFuZCBuZXR3b3JrIGNvbm5lY3Rpb25zLikNCg0KSWYgSSB1bmRlcnN0YW5k IHRoZSB0d28gY2FtcHMsIEkgdGhpbmsgdGhvc2UgYXJlIHRoZSB0d28gb3B0aW9ucyBiZWZvcmUg dXMuICBJ4oCZbSBzdXJlIHRoZXJlIG1heSBiZSBvdGhlciB0aGluZ3MgdG8gZG8gZm9yIG9wdGlv biAyLCBidXQgeW91IGdldCB0aGUgZ2lzdCBvZiB3aGVyZSB0aGF0IGlzIGhlYWRlZC4NCg0KTW9y ZSBpbXBvcnRhbnRseSwgSSBhbSBsZWZ0IHdpdGggdGhlIGltcHJlc3Npb24gdGhhdCBpZiB3ZSBk byBnbyB3aXRoIG9wdGlvbiAyLCB3ZSB3aWxsIGdldCBzdXBwb3J0IGZyb20gYm90aCBjYW1wcy4g IFNvbWUgb2YgdGhvc2Ugd2hvIGFyZSBpbiB0aGUgNjQxNSBjYW1wIGp1c3QgaGF2ZSBhbiBvYmpl Y3RpdmUgb2Ygbm90IGJyZWFraW5nIHdoYXQgaXMgdGhlcmUgbm93IGFuZCBzb21lIGp1c3QgZG9u 4oCZdCB3YW50IHRoZSDigJxoYWNr4oCdIHRoYXQgaXMgdGhlIGN1cnJlbnQgV0Ygc3BlYy4gIEJ1 dCwgSSBiZWxpZXZlIG1vc3QgYXJlIGFsbCBmb3IgYSBjbGVhbiBzcGVjaWZpY2F0aW9uIHRoYXQg ZGVmaW5lcyBhIHVzZWZ1bCBzZXJ2aWNlIGFuZCB0aGF0IHV0aWxpemVzIEpSRCB0byBwcm92aWRl IGEgc2V0IG9mIGxpbmsgcmVsYXRpb25zIGFib3V0IGEgcmVzb3VyY2U7IGEgdXNlZnVsIOKAnHdl YiBkaXNjb3ZlcnkgcHJvdG9jb2zigJ0uDQoNCkkganVzdCB3YW50IGEgc29sdXRpb24gYW5kIHdv dWxkIG5vdCBiZSB1cHNldCB3aXRoIGVpdGhlciBzb2x1dGlvbi4gIFdoYXQgSSBkbyBub3QgbGlr ZSwgdGhvdWdoLCBpcyBoYXZpbmcgdHdvIG9yIHRocmVlIHNvbHV0aW9ucyBmb3IgZGlzY292ZXJ5 LiAgQXQgcHJlc2VudCwgd2UgaGF2ZSBSRkMgNjQxNSwgY3VycmVudCBXRiBkcmFmdCwgU1dELCBh bmQgIGRyYWZ0LWRhYm9vLWFncmVnZ2F0ZWQtc2VydmljZS1kaXNjb3ZlcnkuICBUaGF04oCZcyBh IGZldyB0b28gbWFueSA7LSkNCg0KSSBkbyBoYXZlIGEgaGlnaCBvcGluaW9uIG9mIFhSRC9KUkQs IHNvIEkgd291bGQgbGlrZSB0byBzZWUgZWl0aGVyIG9yIGJvdGggb2YgdGhvc2UgcmV0YWluZWQg aW4gYW55IHNvbHV0aW9uIHRoZSBncm91cCBwcm9kdWNlcy4NCg0KR2l2ZW4gdGhhdCBTV0QgZXhp c3RzLCBJIHRha2UgaXQgdGhhdCB0aGVyZSBpcyBhdCBsZWFzdCBlbm91Z2ggc3VwcG9ydCB0byBk byBzb21ldGhpbmcgb3RoZXIgdGhhbiBSRkMgNjQxNS4gSSBkbyBub3QgZnVsbHkgdW5kZXJzdGFu ZCB0aGUgcmVhc29ucywgZXhjZXB0IHBlcmhhcHMg4oCcd2Ugd2FudCBvbmUgcm91bmQgdHJpcOKA nS4gSSBkb27igJl0IGtub3cuICBQZXJoYXBzIHNvbWVvbmUgY2FuIGVkdWNhdGUgbWUgb24gdGhl IOKAnHdoeeKAnS4gIEJ1dCwgaXQgZG9lcyBleGlzdCwgc28gdGhlcmUgaXMgYSByZWFzb24gYW5k IGl0IG1lYW5zIHdlIG1pZ2h0IGVuZCB1cCB3aXRoIHR3byBzb2x1dGlvbnMuDQoNClNvLCBjYW4g d2UgYXZvaWQgdGhhdD8gIEnigJlkIGJlIG9rIHdpdGggcHV0dGluZyBhc2lkZSB0aGUgV0Ygc3Bl YyBpbiBmYXZvciBhIG1lcmdlciBiZXR3ZWVuIFNXRC9XRi4gIEkgZG9u4oCZdCB3YW50IHRvIGNh bGwgdGhpcyBhIOKAnGNvbXByb21pc2XigJ0sIGJ1dCByYXRoZXIgYSBjbGVhbiBzb2x1dGlvbiB0 aGF0IGJvcnJvd3MgZnJvbSBib3RoOiBzaW5nbGUgcm91bmQgdHJpcCAobGlrZSBTV0QpLCBhIHJp Y2hlciByZXNwb25zZSB3aXRoIGEgc2V0IG9mIGxpbmtzIChKUkQpLCBhZGhlcmVzIHRvIGFuZCBm b2xsb3dzIEhUVFAgcHJvY2VkdXJlcyAoZS5nLiwgbm8g4oCcU1dEX3NlcnZpY2VfcmVkaXJlY3Ti gJ0gdHlwZSBjb25zdHJ1Y3Q7IHVzZSAzeHgpLCBoYXMgbm8gdGVtcGxhdGVzIGluIHRoZSBKUkQs IGFsbG93cyBhbnkgVVJJIHR5cGUgKGluY2x1ZGluZyDigJxhY2N0OuKAnSkgYXMgdGhlIOKAnHN1 YmplY3TigJ0gb2YgdGhlIHF1ZXJ5LCBhbmQgaXMgcm9vdGVkIGF0IHRoZSBob3N0IGF0IHNvbWUg YWdyZWVkIGxvY2F0aW9uIGxpa2UgLy53ZWxsLWtub3duL3N3ZC4NCg0KSSBiZWxpZXZlIGlmIHdl IGRvIHRoaXMsIHdlIGhhdmUgdGhlIGdyZWF0ZXN0IGNoYW5jZSBvZiBnZXR0aW5nIHRoZSBsYXJn ZXN0IG51bWJlciBvZiBwZW9wbGUgb24gYm9hcmQuICBQZXJoYXBzIE1pa2Ugb3Igc29tZW9uZSBz ZXJ2ZSBhcyBlZGl0aW5nLCBidXQgSeKAmWQgYmUgaGFwcHkgdG8gaGVscCBjby1hdXRob3IuICBJ 4oCZbGwgYWxzbyB3cml0ZSBhbiBpbXBsZW1lbnRhdGlvbiBhcyBJIGRpZCBmb3IgUkZDIDY0MTU7 IGl0IHNob3VsZCBiZSBzaW1wbGUgdG8gZG8uDQoNCkluIGFueSBjYXNlLCBJIGRvIHRoaW5rIHRo ZXJlIGlzIGEgc2VyaW91cyByaXNrIG9mIGZhaWx1cmUgaWYgd2UgY29udGludWUgZG93biB0aGUg Y3VycmVudCBXRiBwYXRoLCBlaXRoZXIgYmVjYXVzZSB3ZSBlbmQgdXAgd2l0aCBtdWx0aXBsZSBj b21wZXRpbmcgc29sdXRpb25zIG9yIGJlY2F1c2Ugd2UgYWxpZW5hdGUgb25lIG9mIHRoZSB0d28g Y2FtcHMuICBTbyB3ZSBlaXRoZXIgc3RpY2sgd2l0aCA2NDE1IGFuZCBzdG9wIHNwZW5kaW5nIHRp bWUgb24gdGhpcywgb3IgY3JlYXRlIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YgKDIpIHdo ZXJlIHdlIGNhbiBnZXQgbmVhcmx5IGV2ZXJ5b25lIG9uIGJvYXJkLg0KDQpQYXVsDQoNCkZyb206 IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNl c0BpZXRmLm9yZz4gW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEdvaXggTGF1cmVudCBXYWx0ZXINClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMDIsIDIw MTIgMTE6MzAgQU0NClRvOiBFdmFuIFByb2Ryb21vdTsgYXBwcy1kaXNjdXNzQGlldGYub3JnPG1h aWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbYXBwcy1kaXNjdXNzXSBSOiBI aWdoLWxldmVsIGNvbnNpZGVyYXRpb25zIGFib3V0ICJ3ZWJmaW5nZXIiDQoNCkhpIGV2YW4sDQoN CkkgZG8gaGF2ZSByZWFkIHRoZSBsYXRlc3QgYWx0LXIxIGRyYWZ0LiBCdXQgSSBkbyBiZWxpZXZl IHRoZXNlIGFyZSBzdGlsbCBhcHBsaWNhYmxlIHF1ZXN0aW9uczoNCg0KLSAgICAgICAgICBJIGNv dWxkIHN0aWxsIHNlZSBwcm9zL2NvbnMgaW4gdGhlIGxpc3QgZm9yIHJlbC9yZXNvdXJjZSBwYXJh bWV0ZXJzIGluIGhvc3QtbWV0YS5qc29uDQoNCi0gICAgICAgICAgVGhlIHF1ZXN0aW9uIG9mIGNy ZWF0aW5nIGEgbmV3IGVuZHBvaW50IGhhcyBiZWVuIHJhaXNlZCBhbmQgc3RpbGwgcGVuZGluZyBp bW8gKGFsc28gd3J0IHByZXZpb3VzIGJ1bGxldCkNCg0KLSAgICAgICAgICBSZWxhdGlvbnNoaXAg d2l0aCByZmM2NDE1IGlzIHN0aWxsIG5vdCBjbGVhciBhcyBzb21lIHBhcnRzIGFyZSBjbGVhcmx5 IHJlZmVyZW5jZWQgKG1vc3RseSBwcm9jZWR1cmVzKSB3aGlsc3Qgb3RoZXJzIG1lbnRpb24gYSBj bGVhciBkaXN0YW5jZSB3aXRoIGl0IChlZyB4cmQgdnMganJkKS4gQXMgYSBkZXZlbG9wZXIgSSBj b3VsZCBub3Qga25vdyB2ZXJ5IHdlbGwgd2hldGhlciBJIG5lZWQgdG8gaW1wbGVtZW50IHJmYzY0 MTUgYW5kIGhvdyBtdWNoIG9mIGl04oCmYXQgdGhpcyBwb2ludCBvbmUgbWF5IGNvbnNpZGVyIGhv dyBtdWNoIHRoZSBkcmFmdCBnYWlucyBpbiBhY3R1YWxseSByZWZlcmVuY2luZyB0aG9zZSBzZWN0 aW9ucyBpZiBpdCBpcyB0byBtYW5kYXRlIHRoZSBjb250cmFyeeKApg0KDQpvICAgSW4gc2VjdGlv biAzIGl0IHJlYWRzIOKAnHRoZSBwcm90b2NvbCBidWlsZHMgb24gcmZjNjQxNeKAnSwgd2hpY2gg aXMgdmVyeSB1bmNsZWFyIHRvIHdoaWNoIGV4dGVudA0KDQpvICAgU2VjdGlvbiA1IHRhbGtzIGFi b3V0IGJhY2t3YXJkLWNvbXBhdGliaWxpdHkgYnV0IGJhc2ljYWxseSBzYXlzIGl0IOKAnG1heSBu b3QgYmXigJ0uIFRoaXMgaXMgbWFpbmx5IHRvIHJldXNlIGpyZCBhbmQg4oCcaG9zdC1tZXRhLmpz b27igJ0gc28gaXQgbWF5IGJlIG1vcmUgYXBwcm9wcmlhdGUgdG8gY2FsbCB0aGVtIG91dCBleHBs aWNpdGx5IHdpdGhvdXQgYW55IGdlbmVyaWMgc2VudGVuY2UgKHN0aWxsIGlmIHRoaXMgaXMgdGhl IGZlZWxpbmcgb2YgdGhlIGdyb3VwKQ0KDQpvICAgU2VjdGlvbiA1LjEgcmVmZXJlbmNlcyBzZWN0 aW9uIDQuMiBvZiByZmM2NDE1IGJ1dCBhY3R1YWxseSBpbnRyb2R1Y2VzIHNvbWUgdmFyaWFudHMs IHNvIHdoeSBub3Qgd3JpdGUgYSBjbGVhbiBzdGFuZGFsb25lIHRleHQgd2l0aCBubyByZWZlcmVu Y2UgdG8gcmZjNjQxNT8NCg0KbyAgIFNlY3Rpb24gNS4yIHJlZmVyZW5jZXMgYW4g4oCcZXhhbXBs ZeKAnSBvZiByZmM2NDE1IHNlY3Rpb24gMS4xLjEsIGJ1dCB0aGUgdmFsdWUgb2YgdGhhdCByZWZl cmVuY2UgaXMgbm90IGNsZWFyLiBCZXR0ZXIgcHJvYmFibHkgdG8gcmVmZXJlbmNlIHdlYmZpbmdl cuKAmXMgb3duIGV4YW1wbGVzLg0KDQotICAgICAgICAgIHRoZSB2ZXJ5IGxhdGVzdCBkcmFmdCBp cyBzdGlsbCBhbCDigJxBTFTigJ0gYXQgdGhpcyBzdGFnZeKApg0KDQpJ4oCZbSBwbGF5aW5nIHRo ZSBkZXZpbOKAmXMgYWR2b2NhdGUgaGVyZSBidXQgZG8gdGhpbmsgdGhhdCB0aGUgdmFyaW91cyBj YW1wcyBpbnRlbmQgdmVyeSBkaXZlcnNlIHVzYWdlcyBvZiB3ZWJmaW5nZXIgdGhhdCBtYXliZSBk byBub3QgYmVuZWZpdCBvZiBvbmUgc29sdXRpb24uIEl0IGlzIGEgcGl0eSB0aG9zZSB1c2UgY2Fz ZXMgYXJlIG5vdCByZWZsZWN0ZWQgaW4gdGhlIHNpbXBsaXN0aWMgZXhhbXBsZXM6IEkgcGVyc29u YWxseSBsaWtlZCB0aGUgb3BlbmlkIG9uZSBhcyBJIHRoaW5rIG9wZW5lZCBjb25uZWN0IHdvdWxk IGJlIDEgY2FuZGlkYXRlLCBidXQgSeKAmXZlIGhlYXJkIGFib3V0IGF1dG9jb25maWd1cmF0aW9u IChzZWUgb2F1dGggdXNlIGNhc2UpIGFuZCBmZWRlcmF0ZWQgc29jaWFsIG5ldHdvcmtzICh0aGUg d2hvbGUgb3JpZ2luYWwgcG9pbnQgb2YgaXQpLiBBbGwgb2YgdGhlbSBhcmUgdXNlZCBpbiB2ZXJ5 IGRpZmZlcmVudCBjb250ZXh0cyAodHJ1c3RlZC91bnRydXN0ZWQsIGludHJhLS9pbnRlci1kb21h aW4pIGFuZCB3aWxsIHByb2JhYmx5IGRpc3Rpbmd1aXNoIHRoZW1zZWx2ZXMgZnJvbSB0aGUgYWN0 dWFsIGxpbmsgcmVscyB0aGV5IHdpbGwgdXNlL2V4cG9zZeKApg0KDQp3YWx0ZXINCg0KRGE6IGFw cHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0Bp ZXRmLm9yZz4gW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gUGVyIGNvbnRv IGRpIEV2YW4gUHJvZHJvbW91DQpJbnZpYXRvOiB2ZW5lcmTDrCAyIG5vdmVtYnJlIDIwMTIgMTYu MDUNCkE6IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3Jn Pg0KT2dnZXR0bzogUmU6IFthcHBzLWRpc2N1c3NdIEhpZ2gtbGV2ZWwgY29uc2lkZXJhdGlvbnMg YWJvdXQgIndlYmZpbmdlciINCg0KVGhlIGNvbnZlcnNhdGlvbiBoYXMgcmVhbGx5IG1vdmVkIG9u ISBJIHN1Z2dlc3QgeW91IHJlYWQgUGF1bCBKb25lcydzIGxhdGVzdCBlbWFpbCB0byBnZXQgY2F1 Z2h0IHVwLg0KDQotRXZhbg0KDQpPbiAxMi0xMS0wMiAwODowMiBBTSwgR29peCBMYXVyZW50IFdh bHRlciB3cm90ZToNCkRlYXIgYWxsLA0KDQpJIHRyaWVkIHRvIGNhdGNoIHVwIHdpdGggdGhlIGhv dCBkaXNjdXNzaW9uIG9mIHRoZSBsYXN0IGRheXMgYW5kIHdvdWxkIHRyeSB0byBob2xkIG9uIGZv ciB0aGUgdGltZSBvZiBhbiBlbWFpbCB0cnlpbmcgdG8gc3VtbWFyaXplIHRoZSBjdXJyZW50IHNp dHVhdGlvbiBhbmQgdGFrZSBhIGJyZWF0aOKApg0KDQpBdCB0aGlzIHN0YWdlIHdlIGFyZSBoYXZp bmcgdmVyeSBkaXN0aW5jdCBjYW1wcyBpbiB0aGUgbGlzdCBmb3Igd2hhdCB0aGV5IGhhdmUgaW4g bWluZCBiZWhpbmQgdGhlIOKAnHdlYmZpbmdlcuKAnSBrZXl3b3JkOiB4bWwgdnMganNvbiwgMSBv ciAyIHJvdW5kdHJpcHMsIHByaXZhY3kgZWNjLiBJdCBzZWVtcyB0byBtZSB0aGF0IFBhdWwgaGFz IGJlZW4gZG9pbmcgYW4gb3V0c3RhbmRpbmcgd29yayB0cnlpbmcgdG8gY29tcHJvbWlzZSAoSSB3 b3VsZCBoYXZlIGxvc3QgcGF0aWVuY2XigKYpIGJ1dCBzdWNoIGNvbXByb21pc2VzIGRvIG5vdCBz ZWVtIHRvIHNhdGlzZnkgYW55b25lOiBhY3R1YWxseSwgY29tcHJvbWlzZXMgYXJlIG1vdmluZyBt b3JlIGFuZCBtb3JlIHRvd2FyZHMgdGhlIG9yaWdpbmFsIFNXRCBpZGVhIGF0IHRoZSBlbmQuDQoN Ck1heWJlIHdlIGNvdWxkIGFzayBvdXJzZWx2ZXMgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6DQoN Ci0gICAgICAgICAgV2l0aCB0aGUg4oCceHJk4oCdIGlkZWEgaW4gbWluZCAocGxlYXNlLCBqcmQt ZW50aHVzaWFzdHMsIHRyeSB0byBwdXQgdGhhdCBoYXQgb24gYXMgd2VsbCksIHdoYXQgaXMgYWN0 dWFsbHkgbWlzc2luZyBiZXlvbmQgcmZjNjQxNSBmb3Ig4oCcd2ViZmluZ2Vy4oCdPyBub3cgdGhl IOKAmGFjY3TigJkgVVJJIGlzIGEgc2VwYXJhdGUgZHJhZnQgKGFuIGluaXRpYWwgbW90aXZhdGlv bikuIFJlbC9yZXNvdXJjZSBwYXJhbWV0ZXJzIGZvciB4cmQgc3VwcG9ydGVycyBkbyBub3Qgc2Vl bSBlc3NlbnRpYWwgaW4gbXkgdW5kZXJzdGFuZGluZyBuZWl0aGVyLiBTbyAoYWx0aG91Z2ggSSBh bSBhIHN1cHBvcnRzIG9mIHRoYXQgY2FtcCkgSSBoYXZlIHRyb3VibGUgc2VlaW5nIHdoYXQgdHJ1 bHkgbmVlZCB0byBiZSBhZGRlZC4gSSBjYW4gdW5kZXJzdGFuZCBFdmFu4oCZcyBwb3NpdGlvbiBm b3Iga2VlcGluZyB0aGUgZW50aXJlIHhyZC1iYXNlZCBjb21tdW5pdHkgKG9zdGF0dXMsIGRpYXNw b3JhLCBldGMpIGJ1dCBpc27igJl0IHJmYzY0MTUtY29tcGxpYW5jZSBmb3IgdGhvc2UgZXhpc3Rp bmcgaW1wbGVtZW50YXRpb25zIGFscmVhZHkgZmFpciBlbm91Z2g/IElmIGEgbmV3IOKAnHdlYmZp bmdlcuKAnSBpcyBqcmQsIDEtcm91bmR0cmlwIG9ubHkgYXQgdGhlIGVuZCBpdOKAmXMganVzdCBh bm90aGVyIHJmYyBudW1iZXIgdG8gYmUgcmVmZXJlbmNlZCBpbnN0ZWFkL2luIGFkZGl0aW9uIGFu ZCBhcyBzdWNoIGhhcyB0aGUgc2FtZSB2YWx1ZeKApihub3QgbWVudGlvbmluZyB0aGUgaW1wbGVt ZW50YXRpb24gd29yayBuZWVkZWQpDQoNCg0KDQotICAgICAgICAgIFJmYzY0MTUtY29tcGxpYW5j ZSAmIGJhY2t3YXJkIGNvbXBhdGliaWxpdHk6IHRoaXMgc2VlbXMgYWxzbyBjb250ZW50aW91cyBh cyB3aGV0aGVyIGJhY2t3YXJkLWNvbXBhdGliaWxpdHkgaXMgbmVlZGVkIG9yIG5vdC4gaG93ZXZl ciB0aGUgY3VycmVudCDigJxjb21wcm9taXNlc+KAnSBhcmUgb2RkIGluIG1haW50YWluaW5nIGJh Y2t3YXJkLWNvbXBhYmlsaXR5LiBXaGF0IGlzIGV4YWN0bHkgaW50ZXJlc3RpbmcgZm9yIOKAnHdl YmZpbmdlcuKAnSBmcm9tIHRoYXQgcmZjPyBGcm9tIHRoZSBsYXRlc3QgYWx0ZXJuYXRpdmUgaXQg c2VlbXMgb25seSB0aGUg4oCcaG9zdC1tZXRhLmpzb27igJ0gZW5kcG9pbnQgbmFtZSAmIHRoZSBq cmQuIE9yIGVsc2U/IEhvdyB0aGVzZSBjYW4gYmUgcmVmZXJlbmNlZCBhdCBiZXN0IHdpdGhvdXQg bmVlZGluZyB0aGUgd2hvbGUgdGhpbmc/DQoNCg0KDQotICAgICAgICAgIEhvc3QtbWV0YStscmRk IHZzIG5ldyBlbmRwb2ludDogU2hvdWxkIHdlIHByb3Bvc2UgYW4gYWx0ZXJuYXRpdmUgZW5kcG9p bnQgbmFtZSAodGhlcmUgd2VyZSBtYW55IHByb3Bvc2FscywgaW5jbHVkaW5nIG9uZSBvZiBtaW5l IGEgd2hpbGUgYWdvKSBzbyB0aGF0IHdlIHNpbXBseSDigJxkaXN0aW5ndWlzaOKAnSB0aGUgZXhp c3RpbmcgaG9zdC1tZXRhK2xyZGQgd2F5IGZyb20gYSBuZXcg4oCcd2ViZmluZ2Vy4oCdIHdheS9l bmRwb2ludCBhbGwtaW4tMS1yb3VuZHRyaXAuIFRoaXMgaXMgd2hhdCBzd2QgaXMgcHJvcG9zaW5n LiBFdmVudHVhbGx5IG9uZSBjb3VsZCBhdCB0aGUgZW5kIHVzZSB0aGUgc2FtZSBiYWNrZW5kIGlt cGxlbWVudGF0aW9uIHRvIHJldHVybiBxdWVyaWVzIGNvbWluZyBhbGwgdGhlIHdheSBmcm9tIGhv c3QtbWV0YStscmRkIHRoYW4gb3RoZXJzIHVzaW5nIGFub3RoZXIgd2VsbC1rbm93biAoYW5kIGRp cmVjdCkgZW5kcG9pbnQuIFRoaXMgd291bGQgYWxzbyBiZSBtdWNoIGVhc2llciB0byBzdXBwb3J0 IGFueSBxdWVyeSBwYXJhbWV0ZXIgKHJlc291cmNlLCByZWwsIGV0YykgYXMgc29tZSBhcmUgYXJn dWluZyBhZ2FpbnN0IG92ZXJyaWRpbmcgaG9zdC1tZXRhIHdpdGggcGFyYW1ldGVycy4gSW4gdGhh dCBjYXNlIHRoZSBuZXcg4oCcd2ViZmluZ2Vy4oCdIHdvdWxkIGJlIGFjdHVhbGx5IG1vcmUgbGlr ZSBTV0QgKHdpdGggSlJEIHN1cHBvcnQpDQoNCg0KDQotICAgICAgICAgIEluIGFsdGVybmF0aXZl LCB3aGF0IGFib3V0IHRoZSBwcm92b2NhdGl2ZSBpZGVhIGZyb20gRXZhbiB0byDigJxyZXBsYWNl 4oCdIHJmYzY0MTU/IEFyZSB0aGV5IG90aGVyIHVzYWdlcyBvZiByZmM2NDE1IHRoYW4gdGhlIOKA nHdlYmZpbmdlcuKAnSBvbmUgdGhyb3VnaG91dCB0aGUgY29tbXVuaXR5PyBJZiB5ZXMsIHRoZW4g aXQgbWF5IGJlIG1vcmUgZGlmZmljdWx0IHRvIHJlcGxhY2UgdW5sZXNzIGFncmVlZCB3aXRoIHdo b20gaXMgdXNpbmcgaXQuIE90aGVyd2lzZSwgYXMgaXQgc2VlbXMgbW9zdCBwZW9wbGUgZG8gbm90 IGxpa2UgaXQsIHdoeSBrZWVwIGl0IGFzLWlzIGFuZCBub3QgdXBncmFkZSBkaXJlY3RseSB0byB3 aGF0ZXZlciBpcyBub3cgdXNlZnVsPyBBIHN0YW5kYXJkIHRoYXQgaXMgbm90IHVzZWQgaXMgdXNl bGVzcyBhbmQgaGFzIG5vIHBvaW50IGluIGJlaW5nIHN1cGVyc2VkZWQgYnkgYSBwYXJhbGxlbCBz cGVjIG5vdCBhY3R1YWxseSBvYnNvbGV0aW5nIGl0Li4uIElmIEpSRCBhbmQgdGhlIHdlbGwta25v d24gZW5kcG9pbnRzIGFyZSB1c2VmdWwgaW4gb3RoZXIgY29udGV4dCwgdGhlbiB3aHkgbm90IHNw bGl0dGluZyB0aGVtIGZyb20gdGhlIGFjdHVhbCBwcm90b2NvbCBwcm9jZWR1cmVzIG9mIGN1cnJl bnQgcmZjNjQxNSBhbmQgaGF2ZSBjbGVhbiBzcGVjcyB0aGF0IGNhbiBiZSBnZW5lcmljYWxseSBy ZWZlcmVuY2VkIHdpdGhvdXQgYnV5aW5nIHRoZSBmdWxsIHRoaW5nIG9yIHdyaXRpbmcgY29tcGxl eCB0ZXh0IHRvIHNlbGVjdCBzb21lIHBhcnRzIG9mIGl0IGFuZCBjb250ZXN0IG90aGVyczogMSBm b3IgSlJEIGFuZCAxIGZvciB0aGUgZW5kcG9pbnRzL2xpbmsgcmVnaXN0cmF0aW9ucy4gVGhlbiBh IHByb3RvY29sLW9yaWVudGVkIHNwZWMgbGlrZSB3ZWJmaW5nZXIgY2FuIGVhc2lseSBkZWNpZGUg d2hhdCB0byB0YWtlIGFuZCByZXBsYWNlIGN1cnJlbnQgcmZjNjQxNSwgb3IgZGVjaWRlIHRvIGxp dmUgc2VwYXJhdGVseS9wYXJhbGxlbC4NCg0KDQoNCg0KUGVyc29uYWxseSBJIGhhdmUgbW9yZSBp bnRlcmVzdCBhbmQgZmVlbGluZyBmb3IgdGhlIDItcm91bmR0cmlwIHhyZCBzb2x1dGlvbiBmcm9t IHJmYzY0MTUgc3RpbGwuIEJ1dCBpZiBJIGhhdmUgdG8gY2hvb3NlIGJldHdlZW4gYW4gb2RkL3Bh cnRpYWwvdW5zdGFibGUvdW5jbGVhci9idWdneSByZWZlcmVuY2UgdG8gaXQgYW5kIGEgbmV3IGpz b24gd2F5IGZvciBzYXRpc2Z5aW5nIGFub3RoZXIgdXNlIGNhc2UgSSBoYXZlIHRvIHB1dCBsaW1p dHMgaW4gY29tcHJvbWlzaW5nIGFuZCBhdCB0aGlzIHBvaW50IHByZWZlciBhIHBhcmFsbGVsL2lu ZGVwZW5kZW50IGFwcHJvYWNoLiBPZiBjb3Vyc2UgSeKAmWQgbGlrZSBwb3NzaWJseSB0byByZXVz ZSB0aGUgZmlsZSBmb3JtYXQgKGpyZCkgYXMgaXQgc2VlbXMgc3VpdGFibGUgZm9yIGFsbC4gQXQg bGVhc3QgdGhpcyB3YXkgcmZjNjQxNSBjYW4gc3RpbGwgbGl2ZSBpbmRlcGVuZGVudGx5IChiZWlu ZyB1cGRhdGVkIG9yIG5vdCBpZiB3ZSB3YW50IHRvIG1ha2UgaXQg4oCcY2xlYW5lcuKAnSkgYW5k IOKAnHdlYmZpbmdlcuKAnSBjYW4gaG9wZWZ1bGx5IGJlIGZpbmFsaXplZCBxdWlja2x5IGluIHRo ZSBqc29uICsgMSByb3VuZHRyaXAgZGlyZWN0aW9u4oCmDQoNCk9uY2UgdGhlc2UgbWFjcm8gdG9w aWNzIGFyZSBjbGFyaWZpZWQgdGhlbiB3ZSBjYW4gYmV0dGVyIGRpc2N1c3MgdGhlIGRldGFpbHMg YWJvdXQgc2VjdXJpbmcgd2YsIHN1cHBvcnRpbmcgcHJpdmFjeSwgZGlzdGluY3QgZGVsaXZlcnkg Zm9yIGF1dGgvbm9uLWF1dGggcmVxdWVzdHMgZXRj4oCmQnV0IGNhbiB3ZSBmaXJzdCBkaXNjdXNz IGF0IGhpZ2ggbGV2ZWwgd2hhdCB3ZSB3YW50IHRvIGFjaGlldmUgaW4gdGVybXMgb2YgcHJvY2Vz cz8NCg0KQ2hlZXJzDQp3YWx0ZXINClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkg c29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExh IGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFs bGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2 aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJy b3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmlj YXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwg R3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlh bCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhl IGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1 c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRh Y2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0K PGltYWdlMDAxLmdpZj5SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1h aWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCg0K YXBwcy1kaXNjdXNzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQoNClF1ZXN0 byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFt ZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNp YXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5m b3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmlj ZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVn YXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJv dnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1p bmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0 aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5k ZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KPGltYWdlMDAxLmdpZj5SaXNwZXR0YSBsJ2Ft YmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uDQoN Cg0K --_000_5BE71165CE5F4B5CACE963CA659B4987telecomitaliait_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+VGhhbmtz IFBhdWwhIEl0IHJlbWluZHMgbWUgb2YgYW4gZWFybHkgZGlzY3Vzc2lvbiB3ZSBoYWQgb24gdGhp cyBhYm91dCBkb2N1bWVudC1vcmllbnRlZCB2cyBBUEkgYXBwcm9hY2guIE9wdGlvbiAyLCBwcm9i YWJseSB0aGUgYmVzdCB3YXkgZm9yd2FyZCwgaXMgYSBzb3J0IG9mIEFQSS4uLndlIGNhbiBkZWZp bmUgcGFyYW1ldGVycyBldGMuPC9kaXY+PGRpdj5JZiB0aGUgZ3JvdXAgc3RpY2tzIHdpdGggSnJk IGFuZCB0aGUgb3RoZXIgY29uc2lkZXJhdGlvbnMgeW91IG1hZGUgb24gaHR0cCByZWRpcmVjdHMg ZXRjIEkgZG8gZ3Vlc3MgdGhpcyBpcyBhIGNsZWFuIEFQSSAob25lIGNvdWxkIGV2ZW4gdGhpbmsg b2YgUE9TVC9QVVQvREVMRVRFIGZvciB0aGlzIDopICkuIEFuZCBpdCBsZWF2ZXMgNjQxNSB1bmNo YW5nZWQgYW5kIHdvcmtpbmcuIFNvbWUgY291bGQgc2F5IHVzZWxlc3MgaWYgd2Yvc3dkIG1lcmdl ciBpcyBjcmVhdGVkLCBidXQgYWN0dWFsbHkgdGhpcyB3YXkgd2UgYnVpbGQgc29tZXRoaW5nIHBh cmFsbGVsL2luZGVwZW5kZW50IGluZGVlZCwgc28gNjQxNSBoYXMgc3RpbGwgaXRzIGRpZ25pdHkg YW5kIGlzIG5vdCBicm9rZW4gaW50byBnb29kIGFuZCBiYWQgcGFydHMuLi48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PlBlcnNvbmFsbHksIGZvciBteSBvd24gdmlldyBvZiBmZWRlcmF0ZWQgc29j aWFsIG5ldHdvcmtzIGFuZCBteSBPTUEgaGF0IG9uLCAmbmJzcDtJIGRvIHdvdWxkIHNwb25zb3Ig YW4gNjQxNS1iYXNlZCBzb2x1dGlvbiBhY3Jvc3Mgc29jaWFsIG5ldHdvcmsgcHJvdmlkZXJzIGZv ciBwZWVyaW5nIGFuZCBjcm9zcy1kaXNjb3ZlcnkuPC9kaXY+PGRpdj5CdXQgSSBkbyBzZWUgdmFs dWUgaW4gYSBuZXcganNvbi1iYXNlZCBBUEkvZW5kcG9pbnQgZm9yIG90aGVyIHVzZSBjYXNlcyBh bmQgYW0gd2lsbGluZyB0byBoZWxwLiBOb3RlIHRoYXQgdGhpcyBjb3VsZCBhY3R1YWxseSBiZSB2 aWV3IGFzIHN0YW5kYXJkaXppbmcgdGhlICdMcmRkJyBlbmRwb2ludCA6KSAoYWx0aG91Z2gganNv bi1vbmx5KSBzbyBJIHN0aWxsIHNlZSBpdCBzb21laG93IGNvbXBhdGlibGUgd2l0aCB0aGUgZXhp c3RpbmcgNjQxNSBmcmFtZXdvcmsuLi5pZiB3ZSBuYW1lIHRoZSBlbmRwb2ludCAud2VsbC1rbm93 bi9scmRkIHdlIGV2ZW4gYXZvaWQgdGhlIHdmL3N3ZCBuYW1lIGJhdHRsZSA7KTwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+TW92aW5nIG9uIHRvd2FyZHMgb3B0aW9uIDIsIEkgZG8gaGF2ZSBzdGls bCB0aGUgZm9sbG93aW5nIGNvbmNlcm5zOjwvZGl2PjxkaXY+LSB3b3VsZCB0aGUgd2hvbGUgYWN0 aXZpdHkgYW55d2F5IGJlbmVmaXQgZnJvbSBzbGlnaHRseSB1cGRhdGluZyA2NDE1IGluIHBhcmFs bGVsIG9mIHRoZSB3ZiBhY3Rpdml0eSBlZyB0byBjYWxsIGpyZCBvdXQgb2YgYSBzaW1wbGUgYXBw ZW5kaXggZm9yIGEgY2xlYW5lciByZWZlcmVuY2UgKHBvdGVudGlhbGx5IGFsc28gYnkgb3RoZXIg c3BlY3MgaW4gdGhlIGZ1dHVyZSksIGFuZCBtYXliZSB3aXRoIG90aGVyIHRoaW5ncyBhcyB3ZWxs IHN1Y2ggYXMgY29ycyBvciBlbHNlPyBXaGF0IGlzIHRoZSB2aWV3IG9mIHRoZSBhdXRob3JzIG9m IDY0MTU/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4tIEkgc3RpbGwgc2VlIHRoYXQgdGhlIG1v c3QgcmVsZXZhbnQgdXNlIGNhc2VzIGRpc2N1c3NlZCBvdmVyIHRoZSBsYXN0IG1vbnRocyBhcmUg YWN0dWFsbHkgbWlzc2luZyBmcm9tIHRoZSB0ZXh0LiBGc24sIG9wZW5pZCBjb25uZWN0LCBhdXRv IGNvbmZpZ3VyYXRpb24gJmFtcDsgJ2NvbnRhY3QgZW5yaWNobWVudCcgYXJlIDQgbWFpbiB1c2Ug Y2FzZXMgd2l0aCB2ZXJ5IGRpZmZlcmVudCBuZWVkcyB0aGF0IHdvdWxkIGRlc2VydmUgYmVpbmcg bWVudGlvbmVkIGV4cGxpY2l0bHkuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5BcyBhIHNpZGUg Y29tbWVudCwgSSBtYXkgYmUgdG9vIG9wdGltaXN0aWMvcXVpY2sgYnV0IEknZCBhbHNvIGxpa2Ug dG8gd29yayB3aXRoIHdob2V2ZXIgaXMgaW50ZXJlc3RlZCBhdCBhbmFseXppbmcgbGluayByZWxz IHJlbGV2YW50IGZvciB0aGUgZnNuIHVzZSBjYXNlIGluIHBhcnRpY3VsYXIgYW5kIHBvc3NpYmx5 IGhhdmUgc29tZSBvZiB0aGVtIHJlZ2lzdGVyZWQgaWYgbWlzc2luZyB0byBwYXZlIHRoZSB3YXkg Zm9yIGludGVyb3BlcmFiaWxpdHkuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5XYWx0ZXI8YnI+ PGJyPkxlIDMgbm92LiAyMDEyIMOgIDA3OjUwLCAiUGF1bCBFLiBKb25lcyIgJmx0OzxhIGhyZWY9 Im1haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20iPnBhdWxlakBwYWNrZXRpemVyLmNvbTwvYT4m Z3Q7IGEgw6ljcml0Jm5ic3A7Ojxicj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGRpdj4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PVdpbmRvd3MtMTI1MiI+PG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5bGU+ dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNk ZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBl IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxzdHls ZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsN CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIjsNCglwYW5vc2UtMToy IDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0Fj ZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdy YXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt YXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28t c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6 Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29u b3JtYWw7fQ0KcC5QcmVmb3JtYXR0YXRvSFRNTCwgbGkuUHJlZm9ybWF0dGF0b0hUTUwsIGRpdi5Q cmVmb3JtYXR0YXRvSFRNTA0KCXttc28tc3R5bGUtbmFtZToiUHJlZm9ybWF0dGF0byBIVE1MIjsN Cgltc28tc3R5bGUtbGluazoiUHJlZm9ybWF0dGF0byBIVE1MIENhcmF0dGVyZSI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uUHJl Zm9ybWF0dGF0b0hUTUxDYXJhdHRlcmUNCgl7bXNvLXN0eWxlLW5hbWU6IlByZWZvcm1hdHRhdG8g SFRNTCBDYXJhdHRlcmUiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiUHJlZm9ybWF0dGF0byBIVE1MIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpi bGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46NzAu ODVwdCA1Ni43cHQgNTYuN3B0IDU2LjdwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjIwNzY4ODQxNzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTE2MDc5NTA5ODAgLTIwNjY5OTUzNjggNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcg Njc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDE7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFi LXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6OTEzOTcz Njk0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNzA4 ODUxNTggNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1s ZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZl bDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE4NzIxODYwMzg7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEwOTIzNzYxNjggLTM3 ODE4OTI2IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1 Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3Rh cnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwy OmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC10 YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDI6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsOQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj48cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2FsdGVyLCBldCBh bCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+KEFwb2xvZ2l6ZXMgZm9yIHRoZSBs ZW5ndGgsIGJ1dCBJIHRoaW5rIHdlIGhhdmUgYW4gaW1wb3J0YW50IGRpcmVjdGlvbmFsIGRlY2lz aW9uIHRvIG1ha2XigKYpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgdGhpbmsg ZG93biBiZWxvdyB5b3Ugc3VtbWFyaXplZCB0aGUgc2l0dWF0aW9uIHByZXR0eSB3ZWxsLiZuYnNw OyBXaGlsZSBnZW5lcmFsaXppbmcsIHdoYXQgSSB0aGluayB3ZSBoYXZlIGFyZSB0d28gZGlmZmVy ZW50IGNhbXBzLiAmbmJzcDtUaGVyZSBhcmUgdGhvc2Ugd2hvIGhhdmUgYSBwcmVmZXJlbmNlIGZv ciBSRkMgNjQxNSBhcyBpdOKAmXMgZGVmaW5lZCB0b2RheS4mbmJzcDsgVGhlcmUgYXJlIGEgbGlz dCBvZiBwZW9wbGUgd2hvIHNhaWQgdGhleSBsaWtlIHRoZSBob3N0LW1ldGEgYXBwcm9hY2ggd2l0 aCBob3N0LXNwZWNpZmljIGFuZCB0aGVuIHNlcGFyYXRlIHJlc291cmNlLXNwZWNpZmljIGluZm9y bWF0aW9uIGFuZCB0aGUgdXNlIG9mIHRlbXBsYXRlcyAobm90YWJseSB0aGUgb25lIGZvciBMUkRE KS4mbmJzcDsgVGhlbiB0aGVyZSBpcyB0aGUgZ3JvdXAgd2hvIGRvZXMgbm90LiZuYnNwOyBUaGV5 IGp1c3Qgd2FudCB0byBpc3N1ZSBhIHNpbmdsZSBxdWVyeSBhbmQgZ2V0IGJhY2sgYSBzaW5nbGUg cmVzcG9uc2UuJm5ic3A7IFRoZSBsYXR0ZXIgZ3JvdXAgZG8gbm90IGxpa2UgdGVtcGxhdGVzIGFu ZCBkbyBub3Qgd2FudCB0byBtYWtlIHR3byByZXF1ZXN0cy4mbmJzcDsgT2gsIGFuZCB0aGV5IGRv IG5vdCBjYXJlIG9uZSB3YXkgb3IgdGhlIG90aGVyIGFib3V0IHByZXNlcnZpbmcgYmFja3dhcmQt Y29tcGF0aWJpbGl0eSB3aXRoIFJGQyA2NDE1LiZuYnNwOyAoTm93LCBteSBzdGF0ZW1lbnRzIGFi b3V0IHRoZSB0d28gY2FtcHMgaXMgYSBnZW5lcmFsaXphdGlvbiwgYSBJIHNhaWQgYXQgdGhlIG91 dHNldCwgYW5kIHRoZXJlIGFyZSBvcGluaW9ucyB0aGF0IGNyb3NzIGJvdW5kYXJpZXMsIGJ1dCB0 aGlzIGlzIHRoZSBjbGVhbmVzdCBkaXZpc2lvbiBJIGNhbiBzZWUgZm9yIHRoZSBwdXJwb3NlcyBv ZiBkaXNjdXNzaW9uLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2hhdCBJ4oCZ dmUgdHJpZWQgdG8gZG8gaXMgZGVmaW5lIGEgc29sdXRpb24gdGhhdCB3b3VsZCBhbGxvdyBmb3Ig YSBzaW5nbGUgcmVxdWVzdC9yZXNwb25zZSwgYnV0IHdvdWxkIG1haW50YWluIGEgaGlnaC1kZWdy ZWUgb2YgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIHRoaXMgbmV3IGRvY3VtZW50IGFuZCA2NDE1 LiZuYnNwOyBBcyBJIHdhcyBtYWtpbmcgY2hhbmdlcyB0byB0aGUgZHJhZnQgYW5kIHRyeWluZyB0 byB0YWtlIGlucHV0LCBJIHdhcyB0cnlpbmcgdG8gdGhpbmsgdGhyb3VnaCBob3cgSSBjb3VsZCBw cm9kdWNlIGEgc29sdXRpb24gdG8gbWVldCB0aGUgcmVxdWlyZW1lbnRzIHdpdGhvdXQgYSBob3N0 LW1ldGEgc2VydmVyIG1vZGlmaWVkIGluIGFueSB3YXksIGV4Y2VwdCBmb3IgdGhlIGFkZGl0aW9u IG9mIOKAnHJlc291cmNl4oCdIGFuZCBKUkQgc3VwcG9ydC4mbmJzcDsgSWdub3JpbmcgdGhlIGVk aXRvcmlhbCBpbXByb3ZlbWVudHMgdGhhdCBjb3VsZCBiZSBtYWRlLCBJIHRoaW5rIHRoZSBjdXJy ZW50IEFMVC1SMSBkcmFmdCBkb2VzIHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPllvdSBhcmUgZW50aXJlbHkgY29ycmVjdCB0aGF0IHRoaXMgc3BlYyBpcyBsb29raW5nIG1v cmUgbGlrZSBTV0QuJm5ic3A7IFRoZXJlIGFyZSBzb21lIHZlcnkgaW1wb3J0YW50IGRpc3RpbmN0 aW9ucywgdGhvdWdoLiZuYnNwOyBGb3Igb25lLCBTV0QgcmV0dXJucyBhIHNpbmdsZSBsaW5rIHRv IGEgc2luZ2xlIHJlcXVlc3QuJm5ic3A7IEl0IG1ha2VzIGRpc2NvdmVyaW5nIGxvdHMgb2YgaW5m b3JtYXRpb24gYWJvdXQgc29tZWJvZHkgYSBwYWluLCBJTU8uJm5ic3A7IEl04oCZcyBwcmltYXJ5 IHB1cnBvc2Ugd2FzIHRvIHN1cHBvcnQgT3BlbklEIENvbm5lY3QgYW5kIGl0IHdvcmtzIGZpbmUg Zm9yIHRoYXQsIGJ1dCBpZiBJIHdhbnQgdG8gYXNrIGEgc2V2ZXIgdG8g4oCcdGVsbCBtZSBldmVy eXRoaW5nIHlvdSBrbm93IGFib3V0IFBhdWwgSm9uZXPigJ0sIGl0IGNhbm5vdC4mbmJzcDsgUkZD IDY0MTUgY2FuLCBhbmQgSSBsaWtlIHRoYXQuJm5ic3A7IFRoZSBkaWZmZXJlbmNlIGlzIHJlYWxs eSBhIG1hdHRlciBvZiB0aGUgZG9jdW1lbnQgcmV0dXJuZWQuJm5ic3A7IEFsc28sIHRoZXJlIGlz IGFwcGxpY2F0aW9uLWxldmVsIGtpbmQgb2YgcmVkaXJlY3QgaW4gU1dEIChvciB3YXMpIHRoYXQg cmVhbGx5IHNob3VsZCBiZSBhbiBIVFRQLWxldmVsICgzeHgpLiZuYnNwOyBJIGRvbuKAmXQgbGlr ZSB0aGF0IGFib3V0IFNXRCwgZWl0aGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5CYWNrIHRvIHRoZSB0d28gY2FtcHM6IG5laXRoZXIgaXMgaGFwcHkgd2l0aCB0aGUgcHJlc2Vu dCBzb2x1dGlvbiAodGhlIC0wMiBkcmFmdCkuJm5ic3A7IFBlb3BsZSB3aG8gbGlrZSB0aGUgc2lu Z2xlIHJlcXVlc3QgYXBwcm9hY2ggbGlrZSB0aGlzIEFMVCBkcmFmdHMgYmV0dGVyIGJlY2F1c2Ug WE1MIGlzIGdvbmUsIHRoZXJlIGlzIGEgc2luZ2xlIHJlc291cmNlIHRvIGdvIHF1ZXJ5LCBhbmQs IG9mIGNvdXJzZSwgdGhlcmUgaXMgYSBzaW5nbGUgcmVxdWVzdC9yZXNwb25zZS4mbmJzcDsgUGVv cGxlIHdobyBhcmUgaW4gdGhlIDY0MTUgY2FtcCBkbyBhcmUgbm90IGhhcHB5IHdpdGggdGhlIC0w MiBkcmFmdCBiZWNhdXNlIHdlIHR1cm4g4oCcaG9zdCBtZXRhZGF0YeKAnSBpbnRvIOKAnHJlc291 cmNl4oCdIGluZm9ybWF0aW9uOiB3ZSBtZXJnZSB0aGUgY29uY2VwdHMuJm5ic3A7IFRoZXkgYWxz byBkbyBub3QgbGlrZSB0aGUgQUxUIGRyYWZ0cyBmb3IgdGhlIHNhbWUgcmVhc29uLiZuYnNwOyBI b3dldmVyLCBldmVuIHRoZSA2NDE1IGNhbXAgZG9lcyBzZWVtIHRvIGhhdmUgYW4gYXBwcmVjaWF0 aW9uIGZvciBhIHJlc291cmNlLWNlbnRyaWMgYXBwcm9hY2ggdGhhdCBjYW4gdXNlIGEgc2luZ2xl IHF1ZXJ5LiZuYnNwOyBUaGV5IGp1c3QgZG9u4oCZdCBsaWtlIHRoZSDigJxoYWNr4oCdIChteSB0 ZXJt4oCmIHRoYXTigJlzIHRoZSBvbmUgbmVnYXRpdmUgd29yZCBJIGRvbuKAmXQgdGhpbmsgSeKA mXZlIGhhZCB0aHJvd24gaW4gbXkgZmFjZSA7LSkgKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+SSBiZWxpZXZlIHlvdSBhcmUgcmlnaHQgdG8gcG9pbnQgb3V0IHRoYXQgdGhlIG9u ZSB0aGluZyBwZW9wbGUgc2VlbSB0byBiZSBnZW5lcmFsbHkgT0sgd2l0aCBpcyBKUkQuJm5ic3A7 IEkgdGhpbmsgaXTigJlzIGEgc2ltcGxlIGZvcm1hdCwgbmljZSB0byB3b3JrIHdpdGgsIHVzZWZ1 bCwgYW5kIG5vdCBvdmVybHkgY29tcGxpY2F0ZWQuJm5ic3A7IEdpdmVuIHRoYXQgdGhlcmUgYXJl IHZpcnR1YWxseSBubyBjb21tZW50cyBvbiB0aGUgZm9ybWF0LCBJIGdhdGhlciBwZW9wbGUgc2hh cmUgdGhlIHNhbWUgc2VudGltZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5O b3csIGhhdmluZyBoYWQgY29udmVyc2F0aW9ucyB3aXRoIGEgbnVtYmVyIG9mIHBlb3BsZSBib3Ro IG9uIHRoZSBsaXN0IGFuZCBvZmYsIEkgYmVsaWV2ZSB3ZSBuZWVkIHRvIGRlY2lkZSB3aGljaCBk aXJlY3Rpb24gdG8gdGFrZSBhbmQgSSB0aGluayB0aGVyZSBhcmUgdHdvIGNob2ljZXM6PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm81Ij48IS0tW2lmICFzdXBwb3J0TGlz dHNdLS0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjEpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCEtLVtlbmRpZl0tLT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2UgZGlzY2FyZCB0aGUg Y3VycmVudCBXZWJGaW5nZXIgZHJhZnQgYW5kIGNvbnRpbnVlIHdpdGggUkZDIDY0MTUgYXMtaXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzUiPjwhLS1baWYgIXN1cHBv cnRMaXN0c10tLT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Mik8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XZSByZS13cml0 ZSB0aGUgc3BlYyBpbiB0aGUgc3Bpcml0IG9mIHRoZSBBTFQgdmVyc2lvbnMsIGNvbXBsZXRlbHkg YnJlYWtpbmcgYXdheSBmcm9tIFJGQyA2NDE1IGJ5PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMiBsZm81Ij48IS0tW2lmICFzdXBwb3J0TGlzdHNd LS0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCEtLVtlbmRpZl0tLT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVtb3ZpbmcgYWxs IHJlZmVyZW5jZXMgdG8gYW5kIGRlcGVuZGVuY2llcyBvbiBSRkMgNjQxNTxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEu MGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDIgbGZvNSI+PCEtLVtpZiAh c3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj5iLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRlZmlu aW5nIEpSRCB3aXRoaW4gdGhlIFdlYkZpbmdlciBzcGVjLCBzcGVjaWZ5aW5nIHN1Y2ggdGhpbmdz IGFzIOKAnHRoZSBvcmRlciBvZiBsaW5rIHJlbGF0aW9ucyBpcyBzaWduaWZpY2FudOKAnSBvciBv dGhlciBydWxlcyB3ZSB3YW50IHRvIGFwcGx5IHRvIHRoZSBkb2N1bWVudDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEu MGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDIgbGZvNSI+PCEtLVtpZiAh c3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj5jLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkRlZmluaW5nIGEgbmV3IHJlc291cmNlIGZvciB0aGlzIHNlcnZlciBhdCAvLndlbGwta25vd24v d2ViZmluZ2VyIChvciBzd2QgPyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzUiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ZC48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0t PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Vc2luZyBubyB0ZW1wbGF0ZXMgd2hhdHNvZXZl cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDIg bGZvNSI+PCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5lLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPlVzaW5nIHRoZSDigJxyZXNvdXJjZeKAnSBwYXJhbWV0ZXIgYXMgdGhlIGN1cnJl bnQgQUxUIGRyYWZ0IGhhcyB0aGVtICh0aGUgY29uY2VwdCBvZiDigJxob3N0IG1ldGFkYXRh4oCd IGRvZXMgbm90IGV4aXN0IHdpdGggdGhpcyBkcmFmdDsgSeKAmW0gbm90IHN1cmUgd2hhdCB0aGUg c2VydmVyIHNob3VsZCBkbyBpZiB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIGlzIGFic2VudCwgdGhv dWdoKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZl bDIgbGZvNSI+PCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5mLjxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPihJIHdvdWxkIHNheSB1c2UgdGhlIOKAnHJlbOKAnSBw YXJhbWV0ZXIsIHRvbywgYnV0IHNvbWUgaGF2ZSByZWFsbHkgZXhwcmVzc2VkIGRpc3NhdGlzZmFj dGlvbiB3aXRoIHRoYXQuJm5ic3A7IFdoaWxlIEkgdGhpbmsgaXTigJlzIHdvbmRlcmZ1bCBpbiBv cmRlciB0byByZWR1Y2UgdGhlIG51bWJlciBvZiBsaW5rIHJlbGF0aW9ucyByZXR1cm5lZCwgc29t ZSBqdXN0IHNhdyBubyB2YWx1ZSBpbiB0aGF04oCmIGV2ZW4gb24gbmFycm93LWJhbmQgbmV0d29y ayBjb25uZWN0aW9ucy4pPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklmIEkgdW5k ZXJzdGFuZCB0aGUgdHdvIGNhbXBzLCBJIHRoaW5rIHRob3NlIGFyZSB0aGUgdHdvIG9wdGlvbnMg YmVmb3JlIHVzLiZuYnNwOyBJ4oCZbSBzdXJlIHRoZXJlIG1heSBiZSBvdGhlciB0aGluZ3MgdG8g ZG8gZm9yIG9wdGlvbiAyLCBidXQgeW91IGdldCB0aGUgZ2lzdCBvZiB3aGVyZSB0aGF0IGlzIGhl YWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TW9yZSBpbXBvcnRhbnRseSwg SSBhbSBsZWZ0IHdpdGggdGhlIGltcHJlc3Npb24gdGhhdCBpZiB3ZSBkbyBnbyB3aXRoIG9wdGlv biAyLCB3ZSB3aWxsIGdldCBzdXBwb3J0IGZyb20gYm90aCBjYW1wcy4mbmJzcDsgU29tZSBvZiB0 aG9zZSB3aG8gYXJlIGluIHRoZSA2NDE1IGNhbXAganVzdCBoYXZlIGFuIG9iamVjdGl2ZSBvZiBu b3QgYnJlYWtpbmcgd2hhdCBpcyB0aGVyZSBub3cgYW5kIHNvbWUganVzdCBkb27igJl0IHdhbnQg dGhlIOKAnGhhY2vigJ0gdGhhdCBpcyB0aGUgY3VycmVudCBXRiBzcGVjLiZuYnNwOyBCdXQsIEkg YmVsaWV2ZSBtb3N0IGFyZSBhbGwgZm9yIGEgY2xlYW4gc3BlY2lmaWNhdGlvbiB0aGF0IGRlZmlu ZXMgYSB1c2VmdWwgc2VydmljZSBhbmQgdGhhdCB1dGlsaXplcyBKUkQgdG8gcHJvdmlkZSBhIHNl dCBvZiBsaW5rIHJlbGF0aW9ucyBhYm91dCBhIHJlc291cmNlOyBhIHVzZWZ1bCDigJx3ZWIgZGlz Y292ZXJ5IHByb3RvY29s4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGp1 c3Qgd2FudCBhIHNvbHV0aW9uIGFuZCB3b3VsZCBub3QgYmUgdXBzZXQgd2l0aCBlaXRoZXIgc29s dXRpb24uJm5ic3A7IFdoYXQgSSBkbyBub3QgbGlrZSwgdGhvdWdoLCBpcyBoYXZpbmcgdHdvIG9y IHRocmVlIHNvbHV0aW9ucyBmb3IgZGlzY292ZXJ5LiZuYnNwOyBBdCBwcmVzZW50LCB3ZSBoYXZl IFJGQyA2NDE1LCBjdXJyZW50IFdGIGRyYWZ0LCBTV0QsIGFuZCZuYnNwOyBkcmFmdC1kYWJvby1h Z3JlZ2dhdGVkLXNlcnZpY2UtZGlzY292ZXJ5LiZuYnNwOyBUaGF04oCZcyBhIGZldyB0b28gbWFu eSA7LSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBkbyBoYXZlIGEgaGlnaCBv cGluaW9uIG9mIFhSRC9KUkQsIHNvIEkgd291bGQgbGlrZSB0byBzZWUgZWl0aGVyIG9yIGJvdGgg b2YgdGhvc2UgcmV0YWluZWQgaW4gYW55IHNvbHV0aW9uIHRoZSBncm91cCBwcm9kdWNlcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+R2l2ZW4gdGhhdCBTV0QgZXhpc3RzLCBJIHRh a2UgaXQgdGhhdCB0aGVyZSBpcyBhdCBsZWFzdCBlbm91Z2ggc3VwcG9ydCB0byBkbyBzb21ldGhp bmcgb3RoZXIgdGhhbiBSRkMgNjQxNS4gSSBkbyBub3QgZnVsbHkgdW5kZXJzdGFuZCB0aGUgcmVh c29ucywgZXhjZXB0IHBlcmhhcHMg4oCcd2Ugd2FudCBvbmUgcm91bmQgdHJpcOKAnS4gSSBkb27i gJl0IGtub3cuJm5ic3A7IFBlcmhhcHMgc29tZW9uZSBjYW4gZWR1Y2F0ZSBtZSBvbiB0aGUg4oCc d2h54oCdLiZuYnNwOyBCdXQsIGl0IGRvZXMgZXhpc3QsIHNvIHRoZXJlIGlzIGEgcmVhc29uIGFu ZCBpdCBtZWFucyB3ZSBtaWdodCBlbmQgdXAgd2l0aCB0d28gc29sdXRpb25zLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TbywgY2FuIHdlIGF2b2lkIHRoYXQ/Jm5ic3A7IEnigJlk IGJlIG9rIHdpdGggcHV0dGluZyBhc2lkZSB0aGUgV0Ygc3BlYyBpbiBmYXZvciBhIG1lcmdlciBi ZXR3ZWVuIFNXRC9XRi4mbmJzcDsgSSBkb27igJl0IHdhbnQgdG8gY2FsbCB0aGlzIGEg4oCcY29t cHJvbWlzZeKAnSwgYnV0IHJhdGhlciBhIGNsZWFuIHNvbHV0aW9uIHRoYXQgYm9ycm93cyBmcm9t IGJvdGg6IHNpbmdsZSByb3VuZCB0cmlwIChsaWtlIFNXRCksIGEgcmljaGVyIHJlc3BvbnNlIHdp dGggYSBzZXQgb2YgbGlua3MgKEpSRCksIGFkaGVyZXMgdG8gYW5kIGZvbGxvd3MgSFRUUCBwcm9j ZWR1cmVzIChlLmcuLCBubyDigJxTV0Rfc2VydmljZV9yZWRpcmVjdOKAnSB0eXBlIGNvbnN0cnVj dDsgdXNlIDN4eCksIGhhcyBubyB0ZW1wbGF0ZXMgaW4gdGhlIEpSRCwgYWxsb3dzIGFueSBVUkkg dHlwZSAoaW5jbHVkaW5nIOKAnGFjY3Q64oCdKSBhcyB0aGUg4oCcc3ViamVjdOKAnSBvZiB0aGUg cXVlcnksIGFuZCBpcyByb290ZWQgYXQgdGhlIGhvc3QgYXQgc29tZSBhZ3JlZWQgbG9jYXRpb24g bGlrZSAvLndlbGwta25vd24vc3dkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5J IGJlbGlldmUgaWYgd2UgZG8gdGhpcywgd2UgaGF2ZSB0aGUgZ3JlYXRlc3QgY2hhbmNlIG9mIGdl dHRpbmcgdGhlIGxhcmdlc3QgbnVtYmVyIG9mIHBlb3BsZSBvbiBib2FyZC4mbmJzcDsgUGVyaGFw cyBNaWtlIG9yIHNvbWVvbmUgc2VydmUgYXMgZWRpdGluZywgYnV0IEnigJlkIGJlIGhhcHB5IHRv IGhlbHAgY28tYXV0aG9yLiZuYnNwOyBJ4oCZbGwgYWxzbyB3cml0ZSBhbiBpbXBsZW1lbnRhdGlv biBhcyBJIGRpZCBmb3IgUkZDIDY0MTU7IGl0IHNob3VsZCBiZSBzaW1wbGUgdG8gZG8uPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkluIGFueSBjYXNlLCBJIGRvIHRoaW5rIHRoZXJl IGlzIGEgc2VyaW91cyByaXNrIG9mIGZhaWx1cmUgaWYgd2UgY29udGludWUgZG93biB0aGUgY3Vy cmVudCBXRiBwYXRoLCBlaXRoZXIgYmVjYXVzZSB3ZSBlbmQgdXAgd2l0aCBtdWx0aXBsZSBjb21w ZXRpbmcgc29sdXRpb25zIG9yIGJlY2F1c2Ugd2UgYWxpZW5hdGUgb25lIG9mIHRoZSB0d28gY2Ft cHMuJm5ic3A7IFNvIHdlIGVpdGhlciBzdGljayB3aXRoIDY0MTUgYW5kIHN0b3Agc3BlbmRpbmcg dGltZSBvbiB0aGlzLCBvciBjcmVhdGUgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiAoMikg d2hlcmUgd2UgY2FuIGdldCBuZWFybHkgZXZlcnlvbmUgb24gYm9hcmQuPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPlBhdWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPjxkaXY+PGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gPGEgaHJlZj0ibWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2Vz QGlldGYub3JnIj5hcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1h aWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmFwcHMtZGlzY3Vzcy1i b3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mIDwvYj5Hb2l4IExhdXJlbnQgV2Fs dGVyPGJyPjxiPlNlbnQ6PC9iPiBGcmlkYXksIE5vdmVtYmVyIDAyLCAyMDEyIDExOjMwIEFNPGJy PjxiPlRvOjwvYj4gRXZhbiBQcm9kcm9tb3U7IDxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NA aWV0Zi5vcmciPmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFth cHBzLWRpc2N1c3NdIFI6IEhpZ2gtbGV2ZWwgY29uc2lkZXJhdGlvbnMgYWJvdXQgIndlYmZpbmdl ciI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkhpIGV2YW4sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkg ZG8gaGF2ZSByZWFkIHRoZSBsYXRlc3QgYWx0LXIxIGRyYWZ0LiBCdXQgSSBkbyBiZWxpZXZlIHRo ZXNlIGFyZSBzdGlsbCBhcHBsaWNhYmxlIHF1ZXN0aW9uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgY291bGQg c3RpbGwgc2VlIHByb3MvY29ucyBpbiB0aGUgbGlzdCBmb3IgcmVsL3Jlc291cmNlIHBhcmFtZXRl cnMgaW4gaG9zdC1tZXRhLmpzb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwx IGxmbzIiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5k aWZdLS0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSBxdWVzdGlvbiBvZiBjcmVhdGlu ZyBhIG5ldyBlbmRwb2ludCBoYXMgYmVlbiByYWlzZWQgYW5kIHN0aWxsIHBlbmRpbmcgaW1vIChh bHNvIHdydCBwcmV2aW91cyBidWxsZXQpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxl dmVsMSBsZm8yIj48IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0t W2VuZGlmXS0tPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SZWxhdGlvbnNoaXAgd2l0aCBy ZmM2NDE1IGlzIHN0aWxsIG5vdCBjbGVhciBhcyBzb21lIHBhcnRzIGFyZSBjbGVhcmx5IHJlZmVy ZW5jZWQgKG1vc3RseSBwcm9jZWR1cmVzKSB3aGlsc3Qgb3RoZXJzIG1lbnRpb24gYSBjbGVhciBk aXN0YW5jZSB3aXRoIGl0IChlZyB4cmQgdnMganJkKS4gQXMgYSBkZXZlbG9wZXIgSSBjb3VsZCBu b3Qga25vdyB2ZXJ5IHdlbGwgd2hldGhlciBJIG5lZWQgdG8gaW1wbGVtZW50IHJmYzY0MTUgYW5k IGhvdyBtdWNoIG9mIGl04oCmYXQgdGhpcyBwb2ludCBvbmUgbWF5IGNvbnNpZGVyIGhvdyBtdWNo IHRoZSBkcmFmdCBnYWlucyBpbiBhY3R1YWxseSByZWZlcmVuY2luZyB0aG9zZSBzZWN0aW9ucyBp ZiBpdCBpcyB0byBtYW5kYXRlIHRoZSBjb250cmFyeeKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDIgbGZvMiI+PCEtLVtpZiAhc3VwcG9ydExp c3RzXS0tPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsgPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+SW4gc2VjdGlvbiAzIGl0IHJlYWRzIOKAnHRoZSBwcm90b2NvbCBidWlsZHMgb24gcmZjNjQx NeKAnSwgd2hpY2ggaXMgdmVyeSB1bmNsZWFyIHRvIHdoaWNoIGV4dGVudDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEu MGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDIgbGZvMiI+PCEtLVtpZiAh c3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+U2VjdGlvbiA1IHRhbGtzIGFib3V0IGJhY2t3YXJkLWNvbXBhdGliaWxpdHkg YnV0IGJhc2ljYWxseSBzYXlzIGl0IOKAnG1heSBub3QgYmXigJ0uIFRoaXMgaXMgbWFpbmx5IHRv IHJldXNlIGpyZCBhbmQg4oCcaG9zdC1tZXRhLmpzb27igJ0gc28gaXQgbWF5IGJlIG1vcmUgYXBw cm9wcmlhdGUgdG8gY2FsbCB0aGVtIG91dCBleHBsaWNpdGx5IHdpdGhvdXQgYW55IGdlbmVyaWMg c2VudGVuY2UgKHN0aWxsIGlmIHRoaXMgaXMgdGhlIGZlZWxpbmcgb2YgdGhlIGdyb3VwKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDIgbGZvMiI+ PCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj5vPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+U2VjdGlvbiA1LjEgcmVmZXJlbmNlcyBzZWN0aW9uIDQuMiBv ZiByZmM2NDE1IGJ1dCBhY3R1YWxseSBpbnRyb2R1Y2VzIHNvbWUgdmFyaWFudHMsIHNvIHdoeSBu b3Qgd3JpdGUgYSBjbGVhbiBzdGFuZGFsb25lIHRleHQgd2l0aCBubyByZWZlcmVuY2UgdG8gcmZj NjQxNT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2 ZWwyIGxmbzIiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+bzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZd LS0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gNS4yIHJlZmVyZW5jZXMgYW4g 4oCcZXhhbXBsZeKAnSBvZiByZmM2NDE1IHNlY3Rpb24gMS4xLjEsIGJ1dCB0aGUgdmFsdWUgb2Yg dGhhdCByZWZlcmVuY2UgaXMgbm90IGNsZWFyLiBCZXR0ZXIgcHJvYmFibHkgdG8gcmVmZXJlbmNl IHdlYmZpbmdlcuKAmXMgb3duIGV4YW1wbGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MiBsZXZlbDEgbGZvMiI+PCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCEtLVtlbmRpZl0tLT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+dGhlIHZlcnkgbGF0ZXN0 IGRyYWZ0IGlzIHN0aWxsIGFsIOKAnEFMVOKAnSBhdCB0aGlzIHN0YWdl4oCmPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPknigJltIHBsYXlpbmcgdGhlIGRldmls4oCZcyBhZHZvY2F0 ZSBoZXJlIGJ1dCBkbyB0aGluayB0aGF0IHRoZSB2YXJpb3VzIGNhbXBzIGludGVuZCB2ZXJ5IGRp dmVyc2UgdXNhZ2VzIG9mIHdlYmZpbmdlciB0aGF0IG1heWJlIGRvIG5vdCBiZW5lZml0IG9mIG9u ZSBzb2x1dGlvbi4gSXQgaXMgYSBwaXR5IHRob3NlIHVzZSBjYXNlcyBhcmUgbm90IHJlZmxlY3Rl ZCBpbiB0aGUgc2ltcGxpc3RpYyBleGFtcGxlczogSSBwZXJzb25hbGx5IGxpa2VkIHRoZSBvcGVu aWQgb25lIGFzIEkgdGhpbmsgb3BlbmVkIGNvbm5lY3Qgd291bGQgYmUgMSBjYW5kaWRhdGUsIGJ1 dCBJ4oCZdmUgaGVhcmQgYWJvdXQgYXV0b2NvbmZpZ3VyYXRpb24gKHNlZSBvYXV0aCB1c2UgY2Fz ZSkgYW5kIGZlZGVyYXRlZCBzb2NpYWwgbmV0d29ya3MgKHRoZSB3aG9sZSBvcmlnaW5hbCBwb2lu dCBvZiBpdCkuIEFsbCBvZiB0aGVtIGFyZSB1c2VkIGluIHZlcnkgZGlmZmVyZW50IGNvbnRleHRz ICh0cnVzdGVkL3VudHJ1c3RlZCwgaW50cmEtL2ludGVyLWRvbWFpbikgYW5kIHdpbGwgcHJvYmFi bHkgZGlzdGluZ3Vpc2ggdGhlbXNlbHZlcyBmcm9tIHRoZSBhY3R1YWwgbGluayByZWxzIHRoZXkg d2lsbCB1c2UvZXhwb3Nl4oCmPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPndhbHRl cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD48ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPjxkaXY+PGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkRhOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iSVQi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IDxhIGhyZWY9Im1haWx0 bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyI+YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmci Pm1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPlBlciBjb250byBk aSA8L2I+RXZhbiBQcm9kcm9tb3U8YnI+PGI+SW52aWF0bzo8L2I+IHZlbmVyZMOsIDIgbm92ZW1i cmUgMjAxMiAxNi4wNTxicj48Yj5BOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmFwcHMtZGlzY3Vzc0Bp ZXRmLm9yZyI+YXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPjxicj48Yj5PZ2dldHRvOjwvYj4gUmU6 IFthcHBzLWRpc2N1c3NdIEhpZ2gtbGV2ZWwgY29uc2lkZXJhdGlvbnMgYWJvdXQgIndlYmZpbmdl ciI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5UaGUgY29udmVyc2F0aW9uIGhhcyByZWFsbHkg bW92ZWQgb24hIEkgc3VnZ2VzdCB5b3UgcmVhZCBQYXVsIEpvbmVzJ3MgbGF0ZXN0IGVtYWlsIHRv IGdldCBjYXVnaHQgdXAuPGJyPjxicj4tRXZhbjxicj48YnI+T24gMTItMTEtMDIgMDg6MDIgQU0s IEdvaXggTGF1cmVudCBXYWx0ZXIgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5EZWFyIGFsbCw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRyaWVkIHRvIGNhdGNoIHVw IHdpdGggdGhlIGhvdCBkaXNjdXNzaW9uIG9mIHRoZSBsYXN0IGRheXMgYW5kIHdvdWxkIHRyeSB0 byBob2xkIG9uIGZvciB0aGUgdGltZSBvZiBhbiBlbWFpbCB0cnlpbmcgdG8gc3VtbWFyaXplIHRo ZSBjdXJyZW50IHNpdHVhdGlvbiBhbmQgdGFrZSBhIGJyZWF0aOKApjxzcGFuIGxhbmc9IkZSIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHNwYW4gbGFu Zz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCB0aGlz IHN0YWdlIHdlIGFyZSBoYXZpbmcgdmVyeSBkaXN0aW5jdCBjYW1wcyBpbiB0aGUgbGlzdCBmb3Ig d2hhdCB0aGV5IGhhdmUgaW4gbWluZCBiZWhpbmQgdGhlIOKAnHdlYmZpbmdlcuKAnSBrZXl3b3Jk OiB4bWwgdnMganNvbiwgMSBvciAyIHJvdW5kdHJpcHMsIHByaXZhY3kgZWNjLiBJdCBzZWVtcyB0 byBtZSB0aGF0IFBhdWwgaGFzIGJlZW4gZG9pbmcgYW4gb3V0c3RhbmRpbmcgd29yayB0cnlpbmcg dG8gY29tcHJvbWlzZSAoSSB3b3VsZCBoYXZlIGxvc3QgcGF0aWVuY2XigKYpIGJ1dCBzdWNoIGNv bXByb21pc2VzIGRvIG5vdCBzZWVtIHRvIHNhdGlzZnkgYW55b25lOiBhY3R1YWxseSwgY29tcHJv bWlzZXMgYXJlIG1vdmluZyBtb3JlIGFuZCBtb3JlIHRvd2FyZHMgdGhlIG9yaWdpbmFsIFNXRCBp ZGVhIGF0IHRoZSBlbmQuPHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1heWJlIHdlIGNvdWxkIGFzayBvdXJzZWx2ZXMgdGhl IGZvbGxvd2luZyBxdWVzdGlvbnM6PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvNCI+PCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIGxh bmc9IkZSIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEt LVtlbmRpZl0tLT5XaXRoIHRoZSDigJx4cmTigJ0gaWRlYSBpbiBtaW5kIChwbGVhc2UsIGpyZC1l bnRodXNpYXN0cywgdHJ5IHRvIHB1dCB0aGF0IGhhdCBvbiBhcyB3ZWxsKSwgd2hhdCBpcyBhY3R1 YWxseSBtaXNzaW5nIGJleW9uZCByZmM2NDE1IGZvciDigJx3ZWJmaW5nZXLigJ0/IG5vdyB0aGUg 4oCYYWNjdOKAmSBVUkkgaXMgYSBzZXBhcmF0ZSBkcmFmdCAoYW4gaW5pdGlhbCBtb3RpdmF0aW9u KS4gUmVsL3Jlc291cmNlIHBhcmFtZXRlcnMgZm9yIHhyZCBzdXBwb3J0ZXJzIGRvIG5vdCBzZWVt IGVzc2VudGlhbCBpbiBteSB1bmRlcnN0YW5kaW5nIG5laXRoZXIuIFNvIChhbHRob3VnaCBJIGFt IGEgc3VwcG9ydHMgb2YgdGhhdCBjYW1wKSBJIGhhdmUgdHJvdWJsZSBzZWVpbmcgd2hhdCB0cnVs eSBuZWVkIHRvIGJlIGFkZGVkLiBJIGNhbiB1bmRlcnN0YW5kIEV2YW7igJlzIHBvc2l0aW9uIGZv ciBrZWVwaW5nIHRoZSBlbnRpcmUgeHJkLWJhc2VkIGNvbW11bml0eSAob3N0YXR1cywgZGlhc3Bv cmEsIGV0YykgYnV0IGlzbuKAmXQgcmZjNjQxNS1jb21wbGlhbmNlIGZvciB0aG9zZSBleGlzdGlu ZyBpbXBsZW1lbnRhdGlvbnMgYWxyZWFkeSBmYWlyIGVub3VnaD8gSWYgYSBuZXcg4oCcd2ViZmlu Z2Vy4oCdIGlzIGpyZCwgMS1yb3VuZHRyaXAgb25seSBhdCB0aGUgZW5kIGl04oCZcyBqdXN0IGFu b3RoZXIgcmZjIG51bWJlciB0byBiZSByZWZlcmVuY2VkIGluc3RlYWQvaW4gYWRkaXRpb24gYW5k IGFzIHN1Y2ggaGFzIHRoZSBzYW1lIHZhbHVl4oCmKG5vdCBtZW50aW9uaW5nIHRoZSBpbXBsZW1l bnRhdGlvbiB3b3JrIG5lZWRlZCk8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj4mbmJzcDs8c3BhbiBsYW5nPSJGUiI+PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm80Ij48IS0tW2lmICFzdXBwb3J0TGlz dHNdLS0+PHNwYW4gbGFuZz0iRlIiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPlJmYzY0MTUtY29tcGxpYW5jZSAmYW1wOyBiYWNrd2Fy ZCBjb21wYXRpYmlsaXR5OiB0aGlzIHNlZW1zIGFsc28gY29udGVudGlvdXMgYXMgd2hldGhlciBi YWNrd2FyZC1jb21wYXRpYmlsaXR5IGlzIG5lZWRlZCBvciBub3QuIGhvd2V2ZXIgdGhlIGN1cnJl bnQg4oCcY29tcHJvbWlzZXPigJ0gYXJlIG9kZCBpbiBtYWludGFpbmluZyBiYWNrd2FyZC1jb21w YWJpbGl0eS4gV2hhdCBpcyBleGFjdGx5IGludGVyZXN0aW5nIGZvciDigJx3ZWJmaW5nZXLigJ0g ZnJvbSB0aGF0IHJmYz8gRnJvbSB0aGUgbGF0ZXN0IGFsdGVybmF0aXZlIGl0IHNlZW1zIG9ubHkg dGhlIOKAnGhvc3QtbWV0YS5qc29u4oCdIGVuZHBvaW50IG5hbWUgJmFtcDsgdGhlIGpyZC4gT3Ig ZWxzZT8gSG93IHRoZXNlIGNhbiBiZSByZWZlcmVuY2VkIGF0IGJlc3Qgd2l0aG91dCBuZWVkaW5n IHRoZSB3aG9sZSB0aGluZz8gPHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+Jm5ic3A7PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvNCI+PCEtLVtpZiAhc3VwcG9ydExpc3Rz XS0tPjxzcGFuIGxhbmc9IkZSIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCEtLVtlbmRpZl0tLT5Ib3N0LW1ldGErbHJkZCB2cyBuZXcgZW5kcG9pbnQ6IFNo b3VsZCB3ZSBwcm9wb3NlIGFuIGFsdGVybmF0aXZlIGVuZHBvaW50IG5hbWUgKHRoZXJlIHdlcmUg bWFueSBwcm9wb3NhbHMsIGluY2x1ZGluZyBvbmUgb2YgbWluZSBhIHdoaWxlIGFnbykgc28gdGhh dCB3ZSBzaW1wbHkg4oCcZGlzdGluZ3Vpc2jigJ0gdGhlIGV4aXN0aW5nIGhvc3QtbWV0YStscmRk IHdheSBmcm9tIGEgbmV3IOKAnHdlYmZpbmdlcuKAnSB3YXkvZW5kcG9pbnQgYWxsLWluLTEtcm91 bmR0cmlwLiBUaGlzIGlzIHdoYXQgc3dkIGlzIHByb3Bvc2luZy4gRXZlbnR1YWxseSBvbmUgY291 bGQgYXQgdGhlIGVuZCB1c2UgdGhlIHNhbWUgYmFja2VuZCBpbXBsZW1lbnRhdGlvbiB0byByZXR1 cm4gcXVlcmllcyBjb21pbmcgYWxsIHRoZSB3YXkgZnJvbSBob3N0LW1ldGErbHJkZCB0aGFuIG90 aGVycyB1c2luZyBhbm90aGVyIHdlbGwta25vd24gKGFuZCBkaXJlY3QpIGVuZHBvaW50LiBUaGlz IHdvdWxkIGFsc28gYmUgbXVjaCBlYXNpZXIgdG8gc3VwcG9ydCBhbnkgcXVlcnkgcGFyYW1ldGVy IChyZXNvdXJjZSwgcmVsLCBldGMpIGFzIHNvbWUgYXJlIGFyZ3VpbmcgYWdhaW5zdCBvdmVycmlk aW5nIGhvc3QtbWV0YSB3aXRoIHBhcmFtZXRlcnMuIEluIHRoYXQgY2FzZSB0aGUgbmV3IOKAnHdl YmZpbmdlcuKAnSB3b3VsZCBiZSBhY3R1YWxseSBtb3JlIGxpa2UgU1dEICh3aXRoIEpSRCBzdXBw b3J0KTxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiPiZuYnNwOzxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzQiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBsYW5n PSJGUiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1b ZW5kaWZdLS0+SW4gYWx0ZXJuYXRpdmUsIHdoYXQgYWJvdXQgdGhlIHByb3ZvY2F0aXZlIGlkZWEg ZnJvbSBFdmFuIHRvIOKAnHJlcGxhY2XigJ0gcmZjNjQxNT8gQXJlIHRoZXkgb3RoZXIgdXNhZ2Vz IG9mIHJmYzY0MTUgdGhhbiB0aGUg4oCcd2ViZmluZ2Vy4oCdIG9uZSB0aHJvdWdob3V0IHRoZSBj b21tdW5pdHk/IElmIHllcywgdGhlbiBpdCBtYXkgYmUgbW9yZSBkaWZmaWN1bHQgdG8gcmVwbGFj ZSB1bmxlc3MgYWdyZWVkIHdpdGggd2hvbSBpcyB1c2luZyBpdC4gT3RoZXJ3aXNlLCBhcyBpdCBz ZWVtcyBtb3N0IHBlb3BsZSBkbyBub3QgbGlrZSBpdCwgd2h5IGtlZXAgaXQgYXMtaXMgYW5kIG5v dCB1cGdyYWRlIGRpcmVjdGx5IHRvIHdoYXRldmVyIGlzIG5vdyB1c2VmdWw/IEEgc3RhbmRhcmQg dGhhdCBpcyBub3QgdXNlZCBpcyB1c2VsZXNzIGFuZCBoYXMgbm8gcG9pbnQgaW4gYmVpbmcgc3Vw ZXJzZWRlZCBieSBhIHBhcmFsbGVsIHNwZWMgbm90IGFjdHVhbGx5IG9ic29sZXRpbmcgaXQuLi4g SWYgSlJEIGFuZCB0aGUgd2VsbC1rbm93biBlbmRwb2ludHMgYXJlIHVzZWZ1bCBpbiBvdGhlciBj b250ZXh0LCB0aGVuIHdoeSBub3Qgc3BsaXR0aW5nIHRoZW0gZnJvbSB0aGUgYWN0dWFsIHByb3Rv Y29sIHByb2NlZHVyZXMgb2YgY3VycmVudCByZmM2NDE1IGFuZCBoYXZlIGNsZWFuIHNwZWNzIHRo YXQgY2FuIGJlIGdlbmVyaWNhbGx5IHJlZmVyZW5jZWQgd2l0aG91dCBidXlpbmcgdGhlIGZ1bGwg dGhpbmcgb3Igd3JpdGluZyBjb21wbGV4IHRleHQgdG8gc2VsZWN0IHNvbWUgcGFydHMgb2YgaXQg YW5kIGNvbnRlc3Qgb3RoZXJzOiAxIGZvciBKUkQgYW5kIDEgZm9yIHRoZSBlbmRwb2ludHMvbGlu ayByZWdpc3RyYXRpb25zLiBUaGVuIGEgcHJvdG9jb2wtb3JpZW50ZWQgc3BlYyBsaWtlIHdlYmZp bmdlciBjYW4gZWFzaWx5IGRlY2lkZSB3aGF0IHRvIHRha2UgYW5kIHJlcGxhY2UgY3VycmVudCBy ZmM2NDE1LCBvciBkZWNpZGUgdG8gbGl2ZSBzZXBhcmF0ZWx5L3BhcmFsbGVsLjxzcGFuIGxhbmc9 IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPiZu YnNwOzxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiPiZuYnNwOzxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyc29uYWxseSBJIGhhdmUgbW9yZSBpbnRlcmVzdCBhbmQg ZmVlbGluZyBmb3IgdGhlIDItcm91bmR0cmlwIHhyZCBzb2x1dGlvbiBmcm9tIHJmYzY0MTUgc3Rp bGwuIEJ1dCBpZiBJIGhhdmUgdG8gY2hvb3NlIGJldHdlZW4gYW4gb2RkL3BhcnRpYWwvdW5zdGFi bGUvdW5jbGVhci9idWdneSByZWZlcmVuY2UgdG8gaXQgYW5kIGEgbmV3IGpzb24gd2F5IGZvciBz YXRpc2Z5aW5nIGFub3RoZXIgdXNlIGNhc2UgSSBoYXZlIHRvIHB1dCBsaW1pdHMgaW4gY29tcHJv bWlzaW5nIGFuZCBhdCB0aGlzIHBvaW50IHByZWZlciBhIHBhcmFsbGVsL2luZGVwZW5kZW50IGFw cHJvYWNoLiBPZiBjb3Vyc2UgSeKAmWQgbGlrZSBwb3NzaWJseSB0byByZXVzZSB0aGUgZmlsZSBm b3JtYXQgKGpyZCkgYXMgaXQgc2VlbXMgc3VpdGFibGUgZm9yIGFsbC4gQXQgbGVhc3QgdGhpcyB3 YXkgcmZjNjQxNSBjYW4gc3RpbGwgbGl2ZSBpbmRlcGVuZGVudGx5IChiZWluZyB1cGRhdGVkIG9y IG5vdCBpZiB3ZSB3YW50IHRvIG1ha2UgaXQg4oCcY2xlYW5lcuKAnSkgYW5kIOKAnHdlYmZpbmdl cuKAnSBjYW4gaG9wZWZ1bGx5IGJlIGZpbmFsaXplZCBxdWlja2x5IGluIHRoZSBqc29uICsgMSBy b3VuZHRyaXAgZGlyZWN0aW9u4oCmPHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uY2UgdGhlc2UgbWFjcm8gdG9waWNzIGFy ZSBjbGFyaWZpZWQgdGhlbiB3ZSBjYW4gYmV0dGVyIGRpc2N1c3MgdGhlIGRldGFpbHMgYWJvdXQg c2VjdXJpbmcgd2YsIHN1cHBvcnRpbmcgcHJpdmFjeSwgZGlzdGluY3QgZGVsaXZlcnkgZm9yIGF1 dGgvbm9uLWF1dGggcmVxdWVzdHMgZXRj4oCmQnV0IGNhbiB3ZSBmaXJzdCBkaXNjdXNzIGF0IGhp Z2ggbGV2ZWwgd2hhdCB3ZSB3YW50IHRvIGFjaGlldmUgaW4gdGVybXMgb2YgcHJvY2Vzcz88c3Bh biBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05v cm1hbCI+Q2hlZXJzPHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz0iTXNvTm9ybWFsIj53YWx0ZXI8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9w Pjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi IHdpZHRoPSI2MDAiIHN0eWxlPSJ3aWR0aDo2LjI1aW4iPjx0Ym9keT48dHI+PHRkIHdpZHRoPSI1 ODUiIHN0eWxlPSJ3aWR0aDo0MzguNzVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0 Ij48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxz cGFuIGNsYXNzPSJtc29ub3JtYWwwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UXVlc3Rv IG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1l bnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lh c2kgYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZv cm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNl dnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdh dGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92 dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuIDwvc3Bhbj48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBzdHls ZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBjbGFzcz0ibXNvbm9ybWFsMCI+PGk+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGlzIGUtbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlz c2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1 bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUg c2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy48L3NwYW4+PC9pPjwvc3Bhbj48c3BhbiBj bGFzcz0ibXNvbm9ybWFsMCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnki PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbHQ7aW1hZ2UwMDEuZ2lmJmd0O1Jpc3Bl dHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNz YXJpby48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gPG86cD48L286cD48 L3NwYW4+PC9wPjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cHJlPjxzcGFuIGxh bmc9IkZSIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz0iRlIiPmFwcHMtZGlzY3VzcyBt YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIGxhbmc9IkZSIj48 YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnIj5hcHBzLWRpc2N1c3NAaWV0Zi5v cmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPSJGUiI+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPjwvYmxvY2txdW90ZT48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj ZWxscGFkZGluZz0iMCIgd2lkdGg9IjYwMCIgc3R5bGU9IndpZHRoOjYuMjVpbiI+PHRib2R5Pjx0 cj48dGQgd2lkdGg9IjU4NSIgc3R5bGU9IndpZHRoOjQzOC43NXB0O3BhZGRpbmc6Ljc1cHQgLjc1 cHQgLjc1cHQgLjc1cHQiPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxp Z246anVzdGlmeSI+PHNwYW4gY2xhc3M9Im1zb25vcm1hbDAiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5RdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenph dGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBj b3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEg ZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9y YSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0 ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0 ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4gPC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxwIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIGNsYXNzPSJtc29ub3Jt YWwwIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoaXMgZS1t YWlsIGFuZCBhbnkgYXR0YWNobWVudHM8L3NwYW4+PC9pPjwvc3Bhbj48c3BhbiBjbGFzcz0ibXNv bm9ybWFsMCI+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDtpcyZuYnNwOzwvc3Bhbj48L2k+PC9zcGFuPjxzcGFuIGNsYXNzPSJtc29ub3JtYWwwIj48aT48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmNvbmZpZGVudGlhbCBhbmQg bWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJl c3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkg YW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50 cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLjwvc3Bhbj48 L2k+PC9zcGFuPjxzcGFuIGNsYXNzPSJtc29ub3JtYWwwIj48c3BhbiBsYW5nPSJFTi1HQiI+IDwv c3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtYWxpZ246anVzdGlmeSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZsdDtpbWFn ZTAwMS5naWYmZ3Q7UmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWls IHNlIG5vbiDDqCBuZWNlc3NhcmlvLjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6d2lu ZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2Pjwv YmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --_000_5BE71165CE5F4B5CACE963CA659B4987telecomitaliait_-- From laurentwalter.goix@telecomitalia.it Sat Nov 3 08:25: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 EEF8221F9C6A for ; Sat, 3 Nov 2012 08:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 IGUzHpz+yGf9 for ; Sat, 3 Nov 2012 08:25:25 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 22EE621F9C38 for ; Sat, 3 Nov 2012 08:25:25 -0700 (PDT) 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.279.5; Sat, 3 Nov 2012 16:25:24 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Sat, 3 Nov 2012 16:25:23 +0100 From: Goix Laurent Walter To: Christian Weiske Date: Sat, 3 Nov 2012 16:25:22 +0100 Thread-Topic: [apps-discuss] High-level considerations about "webfinger" Thread-Index: Ac2513GNDZo+CiyqSl26iMEFZcjI8g== Message-ID: <2EFB5756-EDC5-4B01-A646-9A1C3010D9FB@telecomitalia.it> References: <5093E105.2090302@status.net> <054501cdb98f$8f77fe00$ae67fa00$@packetizer.com> <20121103103608.19cc37d1@bogo> In-Reply-To: <20121103103608.19cc37d1@bogo> Accept-Language: en-US Content-Language: fr-FR 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: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] High-level considerations about "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, 03 Nov 2012 15:25:26 -0000 SSB3YXMgd3JpdGluZyBteSBhbnN3ZXIgd2hlbiB5b3Ugc2VudCB5b3Vycy4uLmNsZWFybHkgd2Ug Z290IGFsaWduZWQgb24gdGhlIHNlYW1sZXNzIGludGVncmF0aW9uIG9mIHRoZSBscmRkIGxpbmsg OikNCg0KTGUgMyBub3YuIDIwMTIgw6AgMTY6MDYsICJDaHJpc3RpYW4gV2Vpc2tlIiA8Y3dlaXNr ZUBjd2Vpc2tlLmRlPiBhIMOpY3JpdCA6DQoNCj4gSGVsbG8gUGF1bCwNCj4NCj4NCj4+IGMuICAg ICAgIERlZmluaW5nIGEgbmV3IHJlc291cmNlIGZvciB0aGlzIHNlcnZlcg0KPj4gYXQgLy53ZWxs LWtub3duL3dlYmZpbmdlciAob3Igc3dkID8pDQo+DQo+IEkgd2FzIGZvciBsb25nIGluIHRoZSBS RkMgNjQxNSBjYW1wLCBhbmQgSSBzdGlsbCBhbS4gUmV1c2luZyBleGlzdGluZw0KPiBzdGFuZGFy ZHMgbWFrZXMgbXVjaCBzZW5zZSBpbiBteSBleWVzLg0KPg0KPiBHaXZlbiB0aGF0IHBlb3BsZSBs aWtlIHRoZSBvbmUgcmVxdWVzdCBhcHByb2FjaCAoSSBkbyBzZWUgaXRzDQo+IGJlbmVmaXRzLCB0 b28pLCBhbmQgdGhhdCBhZGRpbmcgYSByZXNvdXJjZSBwYXJhbWV0ZXIgdG8gaG9zdC1tZXRhIGlz IGENCj4gZGlydHkgaGFjaywgSSdkIHJhdGhlciBnbyB3aXRoIGEgbmV3IHJlc291cmNlIC0gLy53 ZWxsLWtub3duL3dlYmZpbmdlci4NCj4NCj4gVGhpcyBzZXBhcmF0ZXMgaXQgY2xlYW5seSwgYWxs b3dzIHRoZSBvbmUgcmVxdWVzdCBzb2x1dGlvbiB3aXRob3V0DQo+IGhhY2tzLCBhbmQgaXMgZXZl biBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgY2xpZW50cyBpZiB0aGUNCj4gbHJk ZCBsaW5rIGlzIGNoYW5nZWQgdG8gLy53ZWxsLWtub3duL3dlYmZpbmdlcj9yZXNvdXJjZT17dXJp fS4NCj4gTm90IHRoYXQgaXQgaXMgdGhhdCBpbXBvcnRhbnQsIGJ1dCBpdCdzIG5pY2UgdG8gaGF2 ZS4NCj4NCj4NCj4gLS0NCj4gUmVnYXJkcy9NaXQgZnJldW5kbGljaGVuIEdyw7zDn2VuDQo+IENo cmlzdGlhbiBXZWlza2UNCj4NCj4gLT3iiaEgR2Vla2luZyBhcm91bmQgaW4gdGhlIG5hbWUgb2Yg c2NpZW5jZSBzaW5jZSAxOTgyIOKJoT0tDQo+IDxzaWduYXR1cmUuYXNjPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBhcHBzLWRpc2N1c3MgbWFp bGluZyBsaXN0DQo+IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBz dW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25l IGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUg ZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJp Z29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1 bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1l ZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEg ZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBp cyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50 ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywg cHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1h aWwsIFRoYW5rcy4NCg0K From romeda@gmail.com Sat Nov 3 11:48: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 4951A21F9CC5 for ; Sat, 3 Nov 2012 11:48:45 -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=-0.001, BAYES_00=-2.599, 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 7HdEHIZmjYUr for ; Sat, 3 Nov 2012 11:48:44 -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 86C9F21F8D5A for ; Sat, 3 Nov 2012 11:48:44 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so3091537pbb.31 for ; Sat, 03 Nov 2012 11:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Ndej0aU7c4+JDgXel/u7IhQZtY1NqrvurcsvVNFgd7o=; b=U6ef+1FpjO5iGx/h9E+C62cfSwXDA0V7QUSxh5v29QLxoGZbgGEaN2aFK50kRHKJ2H WHoTl1Hrrc6CsccFpbFSWczW6njjUN95X94AMfnu77RBLYK4EyguPB/bqa7r3YrFs3W6 1FKqU8OLftZywgltmvC31UAZ1p2bqEew1w3irz6rv0C8N7YZ48vRsmSfGHN4DBXU2s+I rqJB2KWU9td5OcHSVF+oClNDCE3ht00ho2gtRu3TZxZJUX6kSQaXtc1/O91nc8cIBb3V tISW2Uep4KPrg8sMEyh++yKntN6Pe2gpGmKK2Niw5sUwuLV+WJgY/kmOhCjJbIJU77Kr tr7g== Received: by 10.68.217.67 with SMTP id ow3mr17388228pbc.26.1351968524198; Sat, 03 Nov 2012 11:48:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.67.2.101 with HTTP; Sat, 3 Nov 2012 11:48:23 -0700 (PDT) In-Reply-To: <2EFB5756-EDC5-4B01-A646-9A1C3010D9FB@telecomitalia.it> References: <5093E105.2090302@status.net> <054501cdb98f$8f77fe00$ae67fa00$@packetizer.com> <20121103103608.19cc37d1@bogo> <2EFB5756-EDC5-4B01-A646-9A1C3010D9FB@telecomitalia.it> From: Blaine Cook Date: Sat, 3 Nov 2012 18:48:23 +0000 Message-ID: To: "apps-discuss@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ff246e1a1e20b04cd9bb39a Subject: Re: [apps-discuss] High-level considerations about "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, 03 Nov 2012 18:48:45 -0000 --e89a8ff246e1a1e20b04cd9bb39a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to all this. Hooray! A few thoughts on unifying the thinking based on the excellent contributions so far: =E2=80=93 Use host-meta as a fallback for when /.well-known/webfinger isn't= present. =E2=80=93 A big +1 to only using HTTP redirects. =E2=80=93 Drop the template requirement for rel=3D'webfinger' links; the se= mantics are described by webfinger itself, so only the URL is required (i.e., deprecate LRDD in that respect). The only other comment I have at the moment is that I still really oppose the allowance of 301 (Permanent) redirects in webfinger. I can't imagine a scenario where that makes sense, and I can imagine all sorts of scenarios where it could be actively harmful. b. On 3 November 2012 15:25, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it > wrote: > I was writing my answer when you sent yours...clearly we got aligned on > the seamless integration of the lrdd link :) > > Le 3 nov. 2012 =C3=A0 16:06, "Christian Weiske" > > a =C3=A9crit : > > > Hello Paul, > > > > > >> c. Defining a new resource for this server > >> at /.well-known/webfinger (or swd ?) > > > > I was for long in the RFC 6415 camp, and I still am. Reusing existing > > standards makes much sense in my eyes. > > > > Given that people like the one request approach (I do see its > > benefits, too), and that adding a resource parameter to host-meta is a > > dirty hack, I'd rather go with a new resource - /.well-known/webfinger. > > > > This separates it cleanly, allows the one request solution without > > hacks, and is even backward compatible with existing clients if the > > lrdd link is changed to /.well-known/webfinger?resource=3D{uri}. > > Not that it is that important, but it's nice to have. > > > > > > -- > > Regards/Mit freundlichen Gr=C3=BC=C3=9Fen > > Christian Weiske > > > > -=3D=E2=89=A1 Geeking around in the name of science since 1982 =E2=89= =A1=3D- > > > > _______________________________________________ > > 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 privilege= d > 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. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --e89a8ff246e1a1e20b04cd9bb39a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to all this. Hooray!

A few thoughts on unifying the t= hinking based on the excellent contributions so far:

=E2=80=93 Use host-meta as a fallback for when /.well-known/webfinger is= n't present.
=E2=80=93 A big +1 to only using HTTP redirects.
=E2=80=93 D= rop the template requirement for rel=3D'webfinger' links; the seman= tics are described by webfinger itself, so only the URL is required (i.e., = deprecate LRDD in that respect).

The only other comment I have at the moment is that I s= till really oppose the allowance of 301 (Permanent) redirects in webfinger.= I can't imagine a scenario where that makes sense, and I can imagine a= ll sorts of scenarios where it could be actively harmful.

b.

On 3 November 2012 15:25, Goix Laurent Walter = <laurentwa= lter.goix@telecomitalia.it> wrote:
I was writing my answer when you sent yours.= ..clearly we got aligned on the seamless integration of the lrdd link :)
Le 3 nov. 2012 =C3=A0 16:06, "Christian Weiske" <cweiske@cweiske.de> a =C3=A9crit :

> Hello Paul,
>
>
>> c. =C2=A0 =C2=A0 =C2=A0 Defining a new resource for this server >> at /.well-known/webfinger (or swd ?)
>
> I was for long in the RFC 6415 camp, and I still am. Reusing existing<= br> > standards makes much sense in my eyes.
>
> Given that people like the one request approach (I do see its
> benefits, too), and that adding a resource parameter to host-meta is a=
> dirty hack, I'd rather go with a new resource - /.well-known/webfi= nger.
>
> This separates it cleanly, allows the one request solution without
> hacks, and is even backward compatible with existing clients if the > lrdd link is changed to /.well-known/webfinger?resource=3D{uri}.
> Not that it is that important, but it's nice to have.
>
>
> --
> Regards/Mit freundlichen Gr=C3=BC=C3=9Fen
> Christian Weiske
>
> -=3D=E2=89=A1 Geeking around in the name of science since 1982 =E2=89= =A1=3D-
> <signature.asc>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.or= g
> 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.

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

--e89a8ff246e1a1e20b04cd9bb39a-- From paulej@packetizer.com Sat Nov 3 16:37: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 2E27D21F9CA1 for ; Sat, 3 Nov 2012 16:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.982 X-Spam-Level: X-Spam-Status: No, score=-0.982 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_40=-0.185, 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 D5mK+2wRbeR7 for ; Sat, 3 Nov 2012 16:37:31 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A48A521F9C8A for ; Sat, 3 Nov 2012 16:37:25 -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 qA3NbMRg006966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 3 Nov 2012 19:37:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351985843; bh=DrL83cjj42FpQJ5vP7wh368a1Qb9psJEYT2RTT31V8A=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Wh9HFEbXHlp6YD3tYFFlgycL2OPA4Lf6oGO1IrBRZqopOiVmO+qxRb8yKE6qMCFTq SP9Me28adDVdO7nCZ6v4/X76lQVZAAu620XmjWIGWI5rS3MbUGv0TxKMRdNxD49DGT Uir+BrayR+jzi27qfZ3cJ+uHshzPjp7ctHqv/Pkw= From: "Paul E. Jones" To: "'Goix Laurent Walter'" References: <5093E105.2090302@status.net> <054501cdb98f$8f77fe00$ae67fa00$@packetizer.com> <5BE71165-CE5F-4B5C-ACE9-63CA659B4987@telecomitalia.it> In-Reply-To: <5BE71165-CE5F-4B5C-ACE9-63CA659B4987@telecomitalia.it> Date: Sat, 3 Nov 2012 19:37:33 -0400 Message-ID: <05fe01cdba1c$339cd820$9ad68860$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05FF_01CDB9FA.AC8DA920" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIeWfuWjoUIv93mY+PWpHVBG3B76gJ00KovAaFt2qcB+atHoAFBXZKZlvzhqUA= Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] R: High-level considerations about "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, 03 Nov 2012 23:37:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05FF_01CDB9FA.AC8DA920 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Walter, =20 We could update RFC 6415, but we should keep that as a separate = activity. That said, is there truly a benefit? No opposition, but = I=E2=80=99m not sure if there is a lot of value in doing so. =20 The relevance of the examples was a question with the current WebFinger = draft, too. It would be useful to have real-world examples, I agree. = That said, they should be simple ones so as to not loose effect. =20 Paul =20 From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]=20 Sent: Saturday, November 03, 2012 11:22 AM To: Paul E. Jones Cc: Evan Prodromou; apps-discuss@ietf.org; webfinger@googlegroups.com; = Mike Jones Subject: Re: [apps-discuss] R: High-level considerations about = "webfinger" =20 Thanks Paul! It reminds me of an early discussion we had on this about = document-oriented vs API approach. Option 2, probably the best way = forward, is a sort of API...we can define parameters etc. If the group sticks with Jrd and the other considerations you made on = http redirects etc I do guess this is a clean API (one could even think = of POST/PUT/DELETE for this :) ). And it leaves 6415 unchanged and = working. Some could say useless if wf/swd merger is created, but = actually this way we build something parallel/independent indeed, so = 6415 has still its dignity and is not broken into good and bad parts... =20 Personally, for my own view of federated social networks and my OMA hat = on, I do would sponsor an 6415-based solution across social network = providers for peering and cross-discovery. But I do see value in a new json-based API/endpoint for other use cases = and am willing to help. Note that this could actually be view as = standardizing the 'Lrdd' endpoint :) (although json-only) so I still see = it somehow compatible with the existing 6415 framework...if we name the = endpoint .well-known/lrdd we even avoid the wf/swd name battle ;) =20 Moving on towards option 2, I do have still the following concerns: - would the whole activity anyway benefit from slightly updating 6415 in = parallel of the wf activity eg to call jrd out of a simple appendix for = a cleaner reference (potentially also by other specs in the future), and = maybe with other things as well such as cors or else? What is the view = of the authors of 6415? =20 - I still see that the most relevant use cases discussed over the last = months are actually missing from the text. Fsn, openid connect, auto = configuration & 'contact enrichment' are 4 main use cases with very = different needs that would deserve being mentioned explicitly. =20 As a side comment, I may be too optimistic/quick but I'd also like to = work with whoever is interested at analyzing link rels relevant for the = fsn use case in particular and possibly have some of them registered if = missing to pave the way for interoperability. =20 Walter Le 3 nov. 2012 =C3=A0 07:50, "Paul E. Jones" a = =C3=A9crit : Walter, et al, =20 (Apologizes for the length, but I think we have an important directional = decision to make=E2=80=A6) =20 I think down below you summarized the situation pretty well. While = generalizing, what I think we have are two different camps. There are = those who have a preference for RFC 6415 as it=E2=80=99s defined today. = There are a list of people who said they like the host-meta approach = with host-specific and then separate resource-specific information and = the use of templates (notably the one for LRDD). Then there is the = group who does not. They just want to issue a single query and get back = a single response. The latter group do not like templates and do not = want to make two requests. Oh, and they do not care one way or the = other about preserving backward-compatibility with RFC 6415. (Now, my = statements about the two camps is a generalization, a I said at the = outset, and there are opinions that cross boundaries, but this is the = cleanest division I can see for the purposes of discussion.) =20 What I=E2=80=99ve tried to do is define a solution that would allow for = a single request/response, but would maintain a high-degree of = interoperability between this new document and 6415. As I was making = changes to the draft and trying to take input, I was trying to think = through how I could produce a solution to meet the requirements without = a host-meta server modified in any way, except for the addition of = =E2=80=9Cresource=E2=80=9D and JRD support. Ignoring the editorial = improvements that could be made, I think the current ALT-R1 draft does = that. =20 You are entirely correct that this spec is looking more like SWD. There = are some very important distinctions, though. For one, SWD returns a = single link to a single request. It makes discovering lots of = information about somebody a pain, IMO. It=E2=80=99s primary purpose = was to support OpenID Connect and it works fine for that, but if I want = to ask a sever to =E2=80=9Ctell me everything you know about Paul = Jones=E2=80=9D, it cannot. RFC 6415 can, and I like that. The = difference is really a matter of the document returned. Also, there is = application-level kind of redirect in SWD (or was) that really should be = an HTTP-level (3xx). I don=E2=80=99t like that about SWD, either. =20 Back to the two camps: neither is happy with the present solution (the = -02 draft). People who like the single request approach like this ALT = drafts better because XML is gone, there is a single resource to go = query, and, of course, there is a single request/response. People who = are in the 6415 camp do are not happy with the -02 draft because we turn = =E2=80=9Chost metadata=E2=80=9D into =E2=80=9Cresource=E2=80=9D = information: we merge the concepts. They also do not like the ALT = drafts for the same reason. However, even the 6415 camp does seem to = have an appreciation for a resource-centric approach that can use a = single query. They just don=E2=80=99t like the =E2=80=9Chack=E2=80=9D = (my term=E2=80=A6 that=E2=80=99s the one negative word I don=E2=80=99t = think I=E2=80=99ve had thrown in my face ;-) ). =20 I believe you are right to point out that the one thing people seem to = be generally OK with is JRD. I think it=E2=80=99s a simple format, nice = to work with, useful, and not overly complicated. Given that there are = virtually no comments on the format, I gather people share the same = sentiment. =20 Now, having had conversations with a number of people both on the list = and off, I believe we need to decide which direction to take and I think = there are two choices: 1) We discard the current WebFinger draft and continue with RFC = 6415 as-is 2) We re-write the spec in the spirit of the ALT versions, = completely breaking away from RFC 6415 by a. Removing all references to and dependencies on RFC 6415 b. Defining JRD within the WebFinger spec, specifying such things = as =E2=80=9Cthe order of link relations is significant=E2=80=9D or other = rules we want to apply to the document c. Defining a new resource for this server at = /.well-known/webfinger (or swd ?) d. Using no templates whatsoever e. Using the =E2=80=9Cresource=E2=80=9D parameter as the current = ALT draft has them (the concept of =E2=80=9Chost metadata=E2=80=9D does = not exist with this draft; I=E2=80=99m not sure what the server should = do if the resource parameter is absent, though) f. (I would say use the =E2=80=9Crel=E2=80=9D parameter, too, but = some have really expressed dissatisfaction with that. While I think = it=E2=80=99s wonderful in order to reduce the number of link relations = returned, some just saw no value in that=E2=80=A6 even on narrow-band = network connections.) =20 If I understand the two camps, I think those are the two options before = us. I=E2=80=99m sure there may be other things to do for option 2, but = you get the gist of where that is headed. =20 More importantly, I am left with the impression that if we do go with = option 2, we will get support from both camps. Some of those who are in = the 6415 camp just have an objective of not breaking what is there now = and some just don=E2=80=99t want the =E2=80=9Chack=E2=80=9D that is the = current WF spec. But, I believe most are all for a clean specification = that defines a useful service and that utilizes JRD to provide a set of = link relations about a resource; a useful =E2=80=9Cweb discovery = protocol=E2=80=9D. =20 I just want a solution and would not be upset with either solution. = What I do not like, though, is having two or three solutions for = discovery. At present, we have RFC 6415, current WF draft, SWD, and = draft-daboo-agreggated-service-discovery. That=E2=80=99s a few too many = ;-) =20 I do have a high opinion of XRD/JRD, so I would like to see either or = both of those retained in any solution the group produces. =20 Given that SWD exists, I take it that there is at least enough support = to do something other than RFC 6415. I do not fully understand the = reasons, except perhaps =E2=80=9Cwe want one round trip=E2=80=9D. I = don=E2=80=99t know. Perhaps someone can educate me on the = =E2=80=9Cwhy=E2=80=9D. But, it does exist, so there is a reason and it = means we might end up with two solutions. =20 So, can we avoid that? I=E2=80=99d be ok with putting aside the WF spec = in favor a merger between SWD/WF. I don=E2=80=99t want to call this a = =E2=80=9Ccompromise=E2=80=9D, but rather a clean solution that borrows = from both: single round trip (like SWD), a richer response with a set of = links (JRD), adheres to and follows HTTP procedures (e.g., no = =E2=80=9CSWD_service_redirect=E2=80=9D type construct; use 3xx), has no = templates in the JRD, allows any URI type (including = =E2=80=9Cacct:=E2=80=9D) as the =E2=80=9Csubject=E2=80=9D of the query, = and is rooted at the host at some agreed location like /.well-known/swd. =20 I believe if we do this, we have the greatest chance of getting the = largest number of people on board. Perhaps Mike or someone serve as = editing, but I=E2=80=99d be happy to help co-author. I=E2=80=99ll also = write an implementation as I did for RFC 6415; it should be simple to = do. =20 In any case, I do think there is a serious risk of failure if we = continue down the current WF path, either because we end up with = multiple competing solutions or because we alienate one of the two = camps. So we either stick with 6415 and stop spending time on this, or = create something along the lines of (2) where we can get nearly everyone = on board. =20 Paul =20 From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Goix Laurent Walter Sent: Friday, November 02, 2012 11:30 AM To: Evan Prodromou; apps-discuss@ietf.org Subject: [apps-discuss] R: High-level considerations about "webfinger" =20 Hi evan, =20 I do have read the latest alt-r1 draft. But I do believe these are still = applicable questions: - I could still see pros/cons in the list for rel/resource = parameters in host-meta.json - The question of creating a new endpoint has been raised and = still pending imo (also wrt previous bullet) - Relationship with rfc6415 is still not clear as some parts = are clearly referenced (mostly procedures) whilst others mention a clear = distance with it (eg xrd vs jrd). As a developer I could not know very = well whether I need to implement rfc6415 and how much of it=E2=80=A6at = this point one may consider how much the draft gains in actually = referencing those sections if it is to mandate the contrary=E2=80=A6 o In section 3 it reads =E2=80=9Cthe protocol builds on = rfc6415=E2=80=9D, which is very unclear to which extent o Section 5 talks about backward-compatibility but basically says it = =E2=80=9Cmay not be=E2=80=9D. This is mainly to reuse jrd and = =E2=80=9Chost-meta.json=E2=80=9D so it may be more appropriate to call = them out explicitly without any generic sentence (still if this is the = feeling of the group) o Section 5.1 references section 4.2 of rfc6415 but actually = introduces some variants, so why not write a clean standalone text with = no reference to rfc6415? o Section 5.2 references an =E2=80=9Cexample=E2=80=9D of rfc6415 = section 1.1.1, but the value of that reference is not clear. Better = probably to reference webfinger=E2=80=99s own examples. - the very latest draft is still al =E2=80=9CALT=E2=80=9D at = this stage=E2=80=A6 =20 I=E2=80=99m playing the devil=E2=80=99s advocate here but do think that = the various camps intend very diverse usages of webfinger that maybe do = not benefit of one solution. It is a pity those use cases are not = reflected in the simplistic examples: I personally liked the openid one = as I think opened connect would be 1 candidate, but I=E2=80=99ve heard = about autoconfiguration (see oauth use case) and federated social = networks (the whole original point of it). All of them are used in very = different contexts (trusted/untrusted, intra-/inter-domain) and will = probably distinguish themselves from the actual link rels they will = use/expose=E2=80=A6 =20 walter =20 Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = Per conto di Evan Prodromou Inviato: venerd=C3=AC 2 novembre 2012 16.05 A: apps-discuss@ietf.org Oggetto: Re: [apps-discuss] High-level considerations about "webfinger" =20 The conversation has really moved on! I suggest you read Paul Jones's = latest email to get caught up. -Evan On 12-11-02 08:02 AM, Goix Laurent Walter wrote: Dear all, =20 I tried to catch up with the hot discussion of the last days and would = try to hold on for the time of an email trying to summarize the current = situation and take a breath=E2=80=A6 =20 At this stage we are having very distinct camps in the list for what = they have in mind behind the =E2=80=9Cwebfinger=E2=80=9D keyword: xml vs = json, 1 or 2 roundtrips, privacy ecc. It seems to me that Paul has been = doing an outstanding work trying to compromise (I would have lost = patience=E2=80=A6) but such compromises do not seem to satisfy anyone: = actually, compromises are moving more and more towards the original SWD = idea at the end. =20 Maybe we could ask ourselves the following questions: - With the =E2=80=9Cxrd=E2=80=9D idea in mind (please, = jrd-enthusiasts, try to put that hat on as well), what is actually = missing beyond rfc6415 for =E2=80=9Cwebfinger=E2=80=9D? now the = =E2=80=98acct=E2=80=99 URI is a separate draft (an initial motivation). = Rel/resource parameters for xrd supporters do not seem essential in my = understanding neither. So (although I am a supports of that camp) I have = trouble seeing what truly need to be added. I can understand = Evan=E2=80=99s position for keeping the entire xrd-based community = (ostatus, diaspora, etc) but isn=E2=80=99t rfc6415-compliance for those = existing implementations already fair enough? If a new = =E2=80=9Cwebfinger=E2=80=9D is jrd, 1-roundtrip only at the end = it=E2=80=99s just another rfc number to be referenced instead/in = addition and as such has the same value=E2=80=A6(not mentioning the = implementation work needed) =20 - Rfc6415-compliance & backward compatibility: this seems also = contentious as whether backward-compatibility is needed or not. however = the current =E2=80=9Ccompromises=E2=80=9D are odd in maintaining = backward-compability. What is exactly interesting for = =E2=80=9Cwebfinger=E2=80=9D from that rfc? From the latest alternative = it seems only the =E2=80=9Chost-meta.json=E2=80=9D endpoint name & the = jrd. Or else? How these can be referenced at best without needing the = whole thing?=20 =20 - Host-meta+lrdd vs new endpoint: Should we propose an = alternative endpoint name (there were many proposals, including one of = mine a while ago) so that we simply =E2=80=9Cdistinguish=E2=80=9D the = existing host-meta+lrdd way from a new =E2=80=9Cwebfinger=E2=80=9D = way/endpoint all-in-1-roundtrip. This is what swd is proposing. = Eventually one could at the end use the same backend implementation to = return queries coming all the way from host-meta+lrdd than others using = another well-known (and direct) endpoint. This would also be much easier = to support any query parameter (resource, rel, etc) as some are arguing = against overriding host-meta with parameters. In that case the new = =E2=80=9Cwebfinger=E2=80=9D would be actually more like SWD (with JRD = support) =20 - In alternative, what about the provocative idea from Evan to = =E2=80=9Creplace=E2=80=9D rfc6415? Are they other usages of rfc6415 than = the =E2=80=9Cwebfinger=E2=80=9D one throughout the community? If yes, = then it may be more difficult to replace unless agreed with whom is = using it. Otherwise, as it seems most people do not like it, why keep it = as-is and not upgrade directly to whatever is now useful? A standard = that is not used is useless and has no point in being superseded by a = parallel spec not actually obsoleting it... If JRD and the well-known = endpoints are useful in other context, then why not splitting them from = the actual protocol procedures of current rfc6415 and have clean specs = that can be generically referenced without buying the full thing or = writing complex text to select some parts of it and contest others: 1 = for JRD and 1 for the endpoints/link registrations. Then a = protocol-oriented spec like webfinger can easily decide what to take and = replace current rfc6415, or decide to live separately/parallel. =20 =20 Personally I have more interest and feeling for the 2-roundtrip xrd = solution from rfc6415 still. But if I have to choose between an = odd/partial/unstable/unclear/buggy reference to it and a new json way = for satisfying another use case I have to put limits in compromising and = at this point prefer a parallel/independent approach. Of course = I=E2=80=99d like possibly to reuse the file format (jrd) as it seems = suitable for all. At least this way rfc6415 can still live independently = (being updated or not if we want to make it =E2=80=9Ccleaner=E2=80=9D) = and =E2=80=9Cwebfinger=E2=80=9D can hopefully be finalized quickly in = the json + 1 roundtrip direction=E2=80=A6 =20 Once these macro topics are clarified then we can better discuss the = details about securing wf, supporting privacy, distinct delivery for = auth/non-auth requests etc=E2=80=A6But can we first discuss at high = level what we want to achieve in terms of process? =20 Cheers walter 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 _______________________________________________ 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_05FF_01CDB9FA.AC8DA920 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Walter,

 

We could update RFC = 6415, but we should keep that as a separate activity. That said, is = there truly a benefit?=C2=A0 No opposition, but I=E2=80=99m not sure if = there is a lot of value in doing so.

 

The relevance of the = examples was a question with the current WebFinger draft, too.=C2=A0 It = would be useful to have real-world examples, I agree.=C2=A0 That said, = they should be simple ones so as to not loose = effect.

 

Paul

 

From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] =
Sent: Saturday, November 03, 2012 11:22 AM
To: Paul = E. Jones
Cc: Evan Prodromou; apps-discuss@ietf.org; = webfinger@googlegroups.com; Mike Jones
Subject: Re: = [apps-discuss] R: High-level considerations about = "webfinger"

 

Thanks = Paul! It reminds me of an early discussion we had on this about = document-oriented vs API approach. Option 2, probably the best way = forward, is a sort of API...we can define parameters = etc.

If the group sticks = with Jrd and the other considerations you made on http redirects etc I = do guess this is a clean API (one could even think of POST/PUT/DELETE = for this :) ). And it leaves 6415 unchanged and working. Some could say = useless if wf/swd merger is created, but actually this way we build = something parallel/independent indeed, so 6415 has still its dignity and = is not broken into good and bad parts...

 

Personally, for my own view of federated social = networks and my OMA hat on,  I do would sponsor an 6415-based = solution across social network providers for peering and = cross-discovery.

But I do = see value in a new json-based API/endpoint for other use cases and am = willing to help. Note that this could actually be view as standardizing = the 'Lrdd' endpoint :) (although json-only) so I still see it somehow = compatible with the existing 6415 framework...if we name the endpoint = .well-known/lrdd we even avoid the wf/swd name battle = ;)

 

Moving on towards option 2, I do have still the = following concerns:

- = would the whole activity anyway benefit from slightly updating 6415 in = parallel of the wf activity eg to call jrd out of a simple appendix for = a cleaner reference (potentially also by other specs in the future), and = maybe with other things as well such as cors or else? What is the view = of the authors of 6415?

 

- = I still see that the most relevant use cases discussed over the last = months are actually missing from the text. Fsn, openid connect, auto = configuration & 'contact enrichment' are 4 main use cases with very = different needs that would deserve being mentioned = explicitly.

 

As a side comment, I may be too optimistic/quick but = I'd also like to work with whoever is interested at analyzing link rels = relevant for the fsn use case in particular and possibly have some of = them registered if missing to pave the way for = interoperability.

 

Walter

Le 3 nov. 2012 =C3=A0 = 07:50, "Paul E. Jones" <paulej@packetizer.com> a = =C3=A9crit :

Walter, et = al,

 

(Apologizes for the = length, but I think we have an important directional decision to = make=E2=80=A6)

 

I think down below you = summarized the situation pretty well.  While generalizing, what I = think we have are two different camps.  There are those who have a = preference for RFC 6415 as it=E2=80=99s defined today.  There are a = list of people who said they like the host-meta approach with = host-specific and then separate resource-specific information and the = use of templates (notably the one for LRDD).  Then there is the = group who does not.  They just want to issue a single query and get = back a single response.  The latter group do not like templates and = do not want to make two requests.  Oh, and they do not care one way = or the other about preserving backward-compatibility with RFC = 6415.  (Now, my statements about the two camps is a generalization, = a I said at the outset, and there are opinions that cross boundaries, = but this is the cleanest division I can see for the purposes of = discussion.)

 

What I=E2=80=99ve tried = to do is define a solution that would allow for a single = request/response, but would maintain a high-degree of interoperability = between this new document and 6415.  As I was making changes to the = draft and trying to take input, I was trying to think through how I = could produce a solution to meet the requirements without a host-meta = server modified in any way, except for the addition of = =E2=80=9Cresource=E2=80=9D and JRD support.  Ignoring the editorial = improvements that could be made, I think the current ALT-R1 draft does = that.

 

You are entirely correct = that this spec is looking more like SWD.  There are some very = important distinctions, though.  For one, SWD returns a single link = to a single request.  It makes discovering lots of information = about somebody a pain, IMO.  It=E2=80=99s primary purpose was to = support OpenID Connect and it works fine for that, but if I want to ask = a sever to =E2=80=9Ctell me everything you know about Paul = Jones=E2=80=9D, it cannot.  RFC 6415 can, and I like that.  = The difference is really a matter of the document returned.  Also, = there is application-level kind of redirect in SWD (or was) that really = should be an HTTP-level (3xx).  I don=E2=80=99t like that about = SWD, either.

 

Back to the two camps: = neither is happy with the present solution (the -02 draft).  People = who like the single request approach like this ALT drafts better because = XML is gone, there is a single resource to go query, and, of course, = there is a single request/response.  People who are in the 6415 = camp do are not happy with the -02 draft because we turn =E2=80=9Chost = metadata=E2=80=9D into =E2=80=9Cresource=E2=80=9D information: we merge = the concepts.  They also do not like the ALT drafts for the same = reason.  However, even the 6415 camp does seem to have an = appreciation for a resource-centric approach that can use a single = query.  They just don=E2=80=99t like the =E2=80=9Chack=E2=80=9D (my = term=E2=80=A6 that=E2=80=99s the one negative word I don=E2=80=99t think = I=E2=80=99ve had thrown in my face ;-) ).

 

I believe you are right = to point out that the one thing people seem to be generally OK with is = JRD.  I think it=E2=80=99s a simple format, nice to work with, = useful, and not overly complicated.  Given that there are virtually = no comments on the format, I gather people share the same = sentiment.

 

Now, having had = conversations with a number of people both on the list and off, I = believe we need to decide which direction to take and I think there are = two choices:

1)      = We discard the = current WebFinger draft and continue with RFC 6415 = as-is

2)      = We re-write the = spec in the spirit of the ALT versions, completely breaking away from = RFC 6415 by

a.       = Removing all = references to and dependencies on RFC 6415

b.      = Defining JRD = within the WebFinger spec, specifying such things as =E2=80=9Cthe order = of link relations is significant=E2=80=9D or other rules we want to = apply to the document

c.       = Defining a new = resource for this server at /.well-known/webfinger (or swd = ?)

d.      = Using no templates = whatsoever

e.      = Using the = =E2=80=9Cresource=E2=80=9D parameter as the current ALT draft has them = (the concept of =E2=80=9Chost metadata=E2=80=9D does not exist with this = draft; I=E2=80=99m not sure what the server should do if the resource = parameter is absent, though)

f.        = (I would say use = the =E2=80=9Crel=E2=80=9D parameter, too, but some have really expressed = dissatisfaction with that.  While I think it=E2=80=99s wonderful in = order to reduce the number of link relations returned, some just saw no = value in that=E2=80=A6 even on narrow-band network = connections.)

 

If I understand the two = camps, I think those are the two options before us.  I=E2=80=99m = sure there may be other things to do for option 2, but you get the gist = of where that is headed.

 

More importantly, I am = left with the impression that if we do go with option 2, we will get = support from both camps.  Some of those who are in the 6415 camp = just have an objective of not breaking what is there now and some just = don=E2=80=99t want the =E2=80=9Chack=E2=80=9D that is the current WF = spec.  But, I believe most are all for a clean specification that = defines a useful service and that utilizes JRD to provide a set of link = relations about a resource; a useful =E2=80=9Cweb discovery = protocol=E2=80=9D.

 

I just want a solution = and would not be upset with either solution.  What I do not like, = though, is having two or three solutions for discovery.  At = present, we have RFC 6415, current WF draft, SWD, and  = draft-daboo-agreggated-service-discovery.  That=E2=80=99s a few too = many ;-)

 

I do have a high opinion = of XRD/JRD, so I would like to see either or both of those retained in = any solution the group produces.

 

Given that SWD exists, I = take it that there is at least enough support to do something other than = RFC 6415. I do not fully understand the reasons, except perhaps = =E2=80=9Cwe want one round trip=E2=80=9D. I don=E2=80=99t know.  = Perhaps someone can educate me on the =E2=80=9Cwhy=E2=80=9D.  But, = it does exist, so there is a reason and it means we might end up with = two solutions.

 

So, can we avoid = that?  I=E2=80=99d be ok with putting aside the WF spec in favor a = merger between SWD/WF.  I don=E2=80=99t want to call this a = =E2=80=9Ccompromise=E2=80=9D, but rather a clean solution that borrows = from both: single round trip (like SWD), a richer response with a set of = links (JRD), adheres to and follows HTTP procedures (e.g., no = =E2=80=9CSWD_service_redirect=E2=80=9D type construct; use 3xx), has no = templates in the JRD, allows any URI type (including = =E2=80=9Cacct:=E2=80=9D) as the =E2=80=9Csubject=E2=80=9D of the query, = and is rooted at the host at some agreed location like = /.well-known/swd.

 

I believe if we do this, = we have the greatest chance of getting the largest number of people on = board.  Perhaps Mike or someone serve as editing, but I=E2=80=99d = be happy to help co-author.  I=E2=80=99ll also write an = implementation as I did for RFC 6415; it should be simple to = do.

 

In any case, I do think = there is a serious risk of failure if we continue down the current WF = path, either because we end up with multiple competing solutions or = because we alienate one of the two camps.  So we either stick with = 6415 and stop spending time on this, or create something along the lines = of (2) where we can get nearly everyone on = board.

 

Paul

 

From: apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-bounces= @ietf.org] On Behalf Of Goix Laurent Walter
Sent: = Friday, November 02, 2012 11:30 AM
To: Evan Prodromou; apps-discuss@ietf.org
Sub= ject: [apps-discuss] R: High-level considerations about = "webfinger"

 

Hi evan,

 

I do have read the = latest alt-r1 draft. But I do believe these are still applicable = questions:

-          = I could still see = pros/cons in the list for rel/resource parameters in = host-meta.json

-          = The question of = creating a new endpoint has been raised and still pending imo (also wrt = previous bullet)

-          = Relationship with = rfc6415 is still not clear as some parts are clearly referenced (mostly = procedures) whilst others mention a clear distance with it (eg xrd vs = jrd). As a developer I could not know very well whether I need to = implement rfc6415 and how much of it=E2=80=A6at this point one may = consider how much the draft gains in actually referencing those sections = if it is to mandate the contrary=E2=80=A6

o   In section 3 it reads =E2=80=9Cthe protocol = builds on rfc6415=E2=80=9D, which is very unclear to which = extent

o   Section 5 talks about backward-compatibility but = basically says it =E2=80=9Cmay not be=E2=80=9D. This is mainly to reuse = jrd and =E2=80=9Chost-meta.json=E2=80=9D so it may be more appropriate = to call them out explicitly without any generic sentence (still if this = is the feeling of the group)

o   Section 5.1 references section 4.2 of rfc6415 = but actually introduces some variants, so why not write a clean = standalone text with no reference to rfc6415?

o   Section 5.2 references an = =E2=80=9Cexample=E2=80=9D of rfc6415 section 1.1.1, but the value of = that reference is not clear. Better probably to reference = webfinger=E2=80=99s own examples.

-          = the very latest = draft is still al =E2=80=9CALT=E2=80=9D at this = stage=E2=80=A6

 

I=E2=80=99m playing the = devil=E2=80=99s advocate here but do think that the various camps intend = very diverse usages of webfinger that maybe do not benefit of one = solution. It is a pity those use cases are not reflected in the = simplistic examples: I personally liked the openid one as I think opened = connect would be 1 candidate, but I=E2=80=99ve heard about = autoconfiguration (see oauth use case) and federated social networks = (the whole original point of it). All of them are used in very different = contexts (trusted/untrusted, intra-/inter-domain) and will probably = distinguish themselves from the actual link rels they will = use/expose=E2=80=A6

 

walter

 

Da: apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-bounces= @ietf.org] Per conto di Evan Prodromou
Inviato: = venerd=C3=AC 2 novembre 2012 16.05
A: apps-discuss@ietf.org
Ogg= etto: Re: [apps-discuss] High-level considerations about = "webfinger"

 

The conversation has really moved on! = I suggest you read Paul Jones's latest email to get caught = up.

-Evan

On 12-11-02 08:02 AM, Goix Laurent Walter = wrote:

Dear all,

 

I tried to catch up with the hot discussion of the = last days and would try to hold on for the time of an email trying to = summarize the current situation and take a = breath=E2=80=A6

 

At this = stage we are having very distinct camps in the list for what they have = in mind behind the =E2=80=9Cwebfinger=E2=80=9D keyword: xml vs json, 1 = or 2 roundtrips, privacy ecc. It seems to me that Paul has been doing an = outstanding work trying to compromise (I would have lost = patience=E2=80=A6) but such compromises do not seem to satisfy anyone: = actually, compromises are moving more and more towards the original SWD = idea at the end.

 

Maybe we = could ask ourselves the following questions:

-          = With the =E2=80=9Cxrd=E2=80=9D idea in mind = (please, jrd-enthusiasts, try to put that hat on as well), what is = actually missing beyond rfc6415 for =E2=80=9Cwebfinger=E2=80=9D? now the = =E2=80=98acct=E2=80=99 URI is a separate draft (an initial motivation). = Rel/resource parameters for xrd supporters do not seem essential in my = understanding neither. So (although I am a supports of that camp) I have = trouble seeing what truly need to be added. I can understand = Evan=E2=80=99s position for keeping the entire xrd-based community = (ostatus, diaspora, etc) but isn=E2=80=99t rfc6415-compliance for those = existing implementations already fair enough? If a new = =E2=80=9Cwebfinger=E2=80=9D is jrd, 1-roundtrip only at the end = it=E2=80=99s just another rfc number to be referenced instead/in = addition and as such has the same value=E2=80=A6(not mentioning the = implementation work needed)

 

-          = Rfc6415-compliance & backward compatibility: = this seems also contentious as whether backward-compatibility is needed = or not. however the current =E2=80=9Ccompromises=E2=80=9D are odd in = maintaining backward-compability. What is exactly interesting for = =E2=80=9Cwebfinger=E2=80=9D from that rfc? From the latest alternative = it seems only the =E2=80=9Chost-meta.json=E2=80=9D endpoint name & = the jrd. Or else? How these can be referenced at best without needing = the whole thing?

 

-          = Host-meta+lrdd vs new endpoint: Should we = propose an alternative endpoint name (there were many proposals, = including one of mine a while ago) so that we simply = =E2=80=9Cdistinguish=E2=80=9D the existing host-meta+lrdd way from a new = =E2=80=9Cwebfinger=E2=80=9D way/endpoint all-in-1-roundtrip. This is = what swd is proposing. Eventually one could at the end use the same = backend implementation to return queries coming all the way from = host-meta+lrdd than others using another well-known (and direct) = endpoint. This would also be much easier to support any query parameter = (resource, rel, etc) as some are arguing against overriding host-meta = with parameters. In that case the new =E2=80=9Cwebfinger=E2=80=9D would = be actually more like SWD (with JRD support)

 

-          = In alternative, what about the provocative idea = from Evan to =E2=80=9Creplace=E2=80=9D rfc6415? Are they other usages of = rfc6415 than the =E2=80=9Cwebfinger=E2=80=9D one throughout the = community? If yes, then it may be more difficult to replace unless = agreed with whom is using it. Otherwise, as it seems most people do not = like it, why keep it as-is and not upgrade directly to whatever is now = useful? A standard that is not used is useless and has no point in being = superseded by a parallel spec not actually obsoleting it... If JRD and = the well-known endpoints are useful in other context, then why not = splitting them from the actual protocol procedures of current rfc6415 = and have clean specs that can be generically referenced without buying = the full thing or writing complex text to select some parts of it and = contest others: 1 for JRD and 1 for the endpoints/link registrations. = Then a protocol-oriented spec like webfinger can easily decide what to = take and replace current rfc6415, or decide to live = separately/parallel.

 

 

Personally I have more interest and feeling for the = 2-roundtrip xrd solution from rfc6415 still. But if I have to choose = between an odd/partial/unstable/unclear/buggy reference to it and a new = json way for satisfying another use case I have to put limits in = compromising and at this point prefer a parallel/independent approach. = Of course I=E2=80=99d like possibly to reuse the file format (jrd) as it = seems suitable for all. At least this way rfc6415 can still live = independently (being updated or not if we want to make it = =E2=80=9Ccleaner=E2=80=9D) and =E2=80=9Cwebfinger=E2=80=9D can hopefully = be finalized quickly in the json + 1 roundtrip = direction=E2=80=A6

 

Once these = macro topics are clarified then we can better discuss the details about = securing wf, supporting privacy, distinct delivery for auth/non-auth = requests etc=E2=80=A6But can we first discuss at high level what we want = to achieve in terms of process?

 

Cheers

walter

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. = 




_______________________________________________
apps-discuss mailing =
list
apps-discuss@ietf.org
https://www.i=
etf.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_05FF_01CDB9FA.AC8DA920-- From paulej@packetizer.com Sat Nov 3 17:31: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 A063221F9BE1 for ; Sat, 3 Nov 2012 17:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, J_CHICKENPOX_35=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 OLxiQNz-s4Dk for ; Sat, 3 Nov 2012 17:31:55 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9721F9B09 for ; Sat, 3 Nov 2012 17:31:55 -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 qA40VrqO009288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 3 Nov 2012 20:31:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351989114; bh=XX6TNQWCOFwjKzq4r5XoDaYs04TlVY7/506dUBMNFPo=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=caEP+rT2xSiMTDL0VGMXwxWR1nRT2ZuMG7j9FBYjLuSpwD2x7iqHMpCFvPBRpO4ON 9vHQyrNaG7agnSywyK/fnbFoFAHKj5El+00SorDTIZpQHzq7tcr35SfCvCdP3mfgO1 MLhD7DHY5ZsG30mk4gcopHLfVSVq3kbxChoKuTVM= From: "Paul E. Jones" To: , Date: Sat, 3 Nov 2012 20:32:05 -0400 Message-ID: <061d01cdba23$d174d910$745e8b30$@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: Ac26IhwCTU8qR2opQk+7Q4GxD5VYcg== Content-Language: en-us Subject: [apps-discuss] The /.well-known/webfinger resource 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, 04 Nov 2012 00:31:56 -0000 Folks, So far, reaction has been positive in favor of option (2). As noted, this would mean that WebFinger is, more-or-less, the equivalent of the LRDD resource as defined in RFC 6415, except that the default representation will be application/json rather than application/xrd+xml. Before we start working on the new text, I do want to understand if folks agree to the following usage & results. $ curl -v 'https://packetizer.com/.well-known/webfinger' -- returns 404, as there is no specified resource -- Should there be a different response code? If so, what? $ curl -v 'https://packetizer.com/.well-known/webfinger? resource=acct:paulej@packetizer.com' -- returns a JRD for the specified resource -- Example: { "subject" : "acct:paulej@packetizer.com", "links" : [ { "rel" : "http://webfinger.net/rel/avatar", "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg" }, { "rel" : "http://schemas.google.com/g/2010#updates-from", "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml" }, { "rel" : "vcard", "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" } ] } $ curl -v 'https://packetizer.com/.well-known/webfinger? resource=acct:paulej@packetizer.com& rel=vcard' -- returns a JRD for the specified resource, filtered to include only the space-separated list of link relations in the "rel" parameter -- Example: { "subject" : "acct:paulej@packetizer.com", "links" : [ { "rel" : "vcard", "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" } ] } In all cases, the "resource" parameter might be any URI for which that WebFinger server might be able to provide an answer. It might be an "acct:" URI, "mailto:" URI, "http:" URI, etc. I think that was generally agreed before, though we had the dialog about how to deal with the "tel:" URI and other such URIs that do not have domain names associated with them. Paul From wmills@yahoo-inc.com Sat Nov 3 21:48: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 8A3F421F86B4 for ; Sat, 3 Nov 2012 21:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.392 X-Spam-Level: X-Spam-Status: No, score=-16.392 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 N7TlmJW59gTf for ; Sat, 3 Nov 2012 21:48:21 -0700 (PDT) Received: from nm5.bullet.mail.ne1.yahoo.com (nm5.bullet.mail.ne1.yahoo.com [98.138.90.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5781821F860D for ; Sat, 3 Nov 2012 21:48:20 -0700 (PDT) Received: from [98.138.90.50] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 04 Nov 2012 04:48:17 -0000 Received: from [98.138.89.249] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 04 Nov 2012 04:48:17 -0000 Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 04 Nov 2012 04:48:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 553474.78121.bm@omp1041.mail.ne1.yahoo.com Received: (qmail 45527 invoked by uid 60001); 4 Nov 2012 04:48:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1352004497; bh=zYmhKJmuoNCXtyGo9J9isEMPywOF2gy5kOIdz6k2qTE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=IFi9VQ1sEYFAdv6ezJ2SrKW2R1qNSw/uPZy6DNU7ruY1YqbAU/s+JJOwHdnUCY7b6l//w33xeXdTwkwaMrkdt0H7ZCx06gNBrZWBSJJ8vreD4BjYdKgx4fw0L4oUHhk40hoSyB5RyqU3ux5DO5Khk6T5rsHp12NVbaMVr6MKpEk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=CCYTqlV73/qoHFF5LuI3zxn0PgU0S/Rs9+zzpEGbTr/OU8F7YHYRo4k2kfTTjUHmJdK6WSsxUCwivz2ggKfTSNlacT134CibM9XiQkKMpIUYafFMC4P/X0eVfb4p/QJaZy3hNz3w1hYL8KejGMYkdbrvBupt1J8rwGdPgU+OESQ=; X-YMail-OSG: 369DAq4VM1m6ASIDuNbzt.So2MfbUea9WwZzlM6mkUKa9mj hFBvf.UPm2wVrUct3ydtlOwHiQC_0e_e7wiMmW4zCFukmomp18NAeADb8UsQ w5uj5IkJ_FV11Kt3vvozy3I6_wenqDlnpglYC6pe_._FjMcbrXaAbrx2wpVJ uHtVatjjLY8tFM.4T2DYDAJMx5ZaDbOzdva4gTdGWyu8zrvfiDXQXniqFeyj 2yinRRd72r4.fXhlzzHInw0qxLNdp6F26MjbeK2R.vtpVbFvl3xuA3ti.lPy bhHKSEI6j03XlWmjW9.vO1ieliZ6ratr96yTxdfdH6WYNiNXca1NGGr3VMQj mTWBQ8BnG.NpKAv1M2eV.A6dBc4KcpLMajoTW1ReCe825iUT.IjHR3PQwF2v VtKEKnDDqgeWliv_jx05jFGNK8m4x_RqxWvNQv7aZ_HQfiJ7Wdq_yLgnYqno 9w4_OT4tm7EcYyDbKExUr0lGMYJBDBpcwo5BLyTmdcsYXcXwxveQyKoH_PoT QqmXW8143IMcLsr4rZ8nR0iYdLQGWK3TOfmXDxewNgp6zFkEQ2ufGYgNdsSn CaVNL5X5LY.Iw_fDCedIJJKeHcL45ThjAy6fTgG9g9PHjuhy.3A-- Received: from [99.31.212.42] by web31813.mail.mud.yahoo.com via HTTP; Sat, 03 Nov 2012 21:48:16 PDT X-Rocket-MIMEInfo: 001.001, SSdtIGdvbm5hIGFzayBzb21ldGhpbmcgSSBzaG91bGQgcHJvYmFibHkga25vdywgd2h5IGlzIHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIgcmVxdWlyZWQ_wqAgSXMgdGhlcmUgbm8gdXNlIGNhc2UgZm9yIGdlbmVyaWMgZGlzY292ZXJ5IGhlcmUgaW4gdGhlIGN1cnJlbnQgU0Ygc3R5bGU_wqAgSSBmaW5kIHRoaXMgc3VycHJpc2luZy4KCgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBQYXVsIEUuIEpvbmVzIDxwYXVsZWpAcGFja2V0aXplci5jb20.Cj5UbzogYXBwcy1kaXNjdXMBMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.123.460 References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> Message-ID: <1352004496.14504.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Sat, 3 Nov 2012 21:48:16 -0700 (PDT) From: William Mills To: "Paul E. Jones" , "apps-discuss@ietf.org" , "webfinger@googlegroups.com" In-Reply-To: <061d01cdba23$d174d910$745e8b30$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-1877898535-1352004496=:14504" Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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: Sun, 04 Nov 2012 04:48:22 -0000 --767760015-1877898535-1352004496=:14504 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'm gonna ask something I should probably know, why is the resource paramet= er required?=A0 Is there no use case for generic discovery here in the curr= ent SF style?=A0 I find this surprising.=0A=0A=0A=0A=0A=0A>________________= ________________=0A> From: Paul E. Jones =0A>To: app= s-discuss@ietf.org; webfinger@googlegroups.com =0A>Sent: Saturday, November= 3, 2012 5:32 PM=0A>Subject: [apps-discuss] The /.well-known/webfinger reso= urce=0A> =0A>Folks,=0A>=0A>So far, reaction has been positive in favor of o= ption (2).=A0 As noted, this=0A>would mean that WebFinger is, more-or-less,= the equivalent of the LRDD=0A>resource as defined in RFC 6415, except that= the default representation will=0A>be application/json rather than applica= tion/xrd+xml.=0A>=0A>Before we start working on the new text, I do want to = understand if folks=0A>agree to the following usage & results.=0A>=0A>=0A>$= curl -v 'https://packetizer.com/.well-known/webfinger'=0A>-- returns 404, = as there is no specified resource=0A>-- Should there be a different respons= e code? If so, what?=0A>=0A>=0A>$ curl -v 'https://packetizer.com/.well-kno= wn/webfinger?=0A>=A0 =A0 =A0 =A0 =A0 resource=3Dacct:paulej@packetizer.com= '=0A>-- returns a JRD for the specified resource=0A>-- Example:=0A>{=0A>=A0= "subject" : "acct:paulej@packetizer.com",=0A>=A0 "links" :=0A>=A0 [=0A>=A0= =A0 {=0A>=A0 =A0 =A0 "rel" : "http://webfinger.net/rel/avatar",=0A>=A0 =A0= =A0 "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg"= =0A>=A0 =A0 },=0A>=A0 =A0 {=0A>=A0 =A0 =A0 "rel" : "http://schemas.google.c= om/g/2010#updates-from",=0A>=A0 =A0 =A0 "href" : "http://www.packetizer.com= /people/paulej/blog/blog.xml"=0A>=A0 =A0 },=0A>=A0 =A0 {=0A>=A0 =A0 =A0 "re= l" : "vcard",=0A>=A0 =A0 =A0 "href" : "http://www.packetizer.com/people/pau= lej/paulej.vcf"=0A>=A0 =A0 }=0A>=A0 ]=0A>}=0A>=0A>=0A>$ curl -v 'https://pa= cketizer.com/.well-known/webfinger?=0A>=A0 =A0 =A0 =A0 =A0 resource=3Dacct= :paulej@packetizer.com&=0A>=A0 =A0 =A0 =A0 =A0 rel=3Dvcard'=0A>-- returns = a JRD for the specified resource, filtered to include only=0A>=A0 the spac= e-separated list of link relations in the "rel" parameter=0A>-- Example:=0A= >{=0A>=A0 "subject" : "acct:paulej@packetizer.com",=0A>=A0 "links" :=0A>=A0= [=0A>=A0 =A0 {=0A>=A0 =A0 =A0 "rel" : "vcard",=0A>=A0 =A0 =A0 "href" : "ht= tp://www.packetizer.com/people/paulej/paulej.vcf"=0A>=A0 =A0 }=0A>=A0 ]=0A>= }=0A>=0A>In all cases, the "resource" parameter might be any URI for which = that=0A>WebFinger server might be able to provide an answer.=A0 It might be= an "acct:"=0A>URI, "mailto:" URI, "http:" URI, etc.=A0 I think that was ge= nerally agreed=0A>before, though we had the dialog about how to deal with t= he "tel:" URI and=0A>other such URIs that do not have domain names associat= ed with them.=0A>=0A>Paul=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> --767760015-1877898535-1352004496=:14504 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I'm gonna= ask something I should probably know, why is the resource parameter requir= ed?  Is there no use case for generic discovery here in the current SF= style?  I find this surprising.

<= br>
= From: Paul E. Jones <pa= ulej@packetizer.com>
To: apps-discuss@ietf.org; webfinger@googlegroups.com
Sent: Saturday, November 3, 2012 5= :32 PM
Subject: [apps-= discuss] The /.well-known/webfinger resource

Folks,<= br>
So far, reaction has been positive in favor of option (2).  As = noted, this
would mean that WebFinger is, more-or-less, the equivalent o= f the LRDD
resource as defined in RFC 6415, except that the default repr= esentation will
be application/json rather than application/xrd+xml.
=
Before we start working on the new text, I do want to understand if fol= ks
agree to the following usage & results.


$ curl -v '= https://packetizer.com/.well-known/webfinger'
-- returns 404, as the= re is no specified resource
-- Should there be a different response code= ? If so, what?


$ curl -v 'ht= tps://packetizer.com/.well-known/webfinger?
      &nb= sp;   resource=3Dacct:paulej@packetizer.com'
-- returns= a JRD for the specified resource
-- Example:
{
  "subject" := "acct:paulej@packetizer.com",
  "links" :
  [    {
      "rel" : "http://webfinger.net/rel/avatar",=
      "href" : "http://www.packetizer.com/p= eople/paulej/images/paulej.jpg"
    },
    {<= br>      "rel" : "http://schemas.google.com/g/2010#updates-from",
&= nbsp;     "href" : "http://www.packetizer.com/people/pau= lej/blog/blog.xml"
    },
    {
  &nb= sp;   "rel" : "vcard",
      "href" : "http://= www.packetizer.com/people/paulej/paulej.vcf"
    }
&nbs= p; ]
}


$ curl -v 'https://packetizer.com/.well-known/webfinge= r?
          resource=3Dacct:paulej= @packetizer.com&
          rel=3Dvcard= '
-- returns a JRD for the specified resource, filtered to include only<= br>  the space-separated list of link relations in the "rel" parameter
-- Exampl= e:
{
  "subject" : "acct:paulej@packetizer.com",
&= nbsp; "links" :
  [
    {
      "rel= " : "vcard",
      "href" : "http://www.packetizer.= com/people/paulej/paulej.vcf"
    }
  ]
}
In all cases, the "resource" parameter might be any URI for which thatWebFinger server might be able to provide an answer.  It might be an = "acct:"
URI, "mailto:" URI, "http:" URI, etc.  I think that was gen= erally agreed
before, though we had the dialog about how to deal with th= e "tel:" URI and
other such URIs that do not have domain names associate= d with them.

Paul


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


=
--767760015-1877898535-1352004496=:14504-- From superuser@gmail.com Sat Nov 3 22:24: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 8C84B21F9481 for ; Sat, 3 Nov 2012 22:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.216, 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 cvMU-gVxiF0d for ; Sat, 3 Nov 2012 22:24: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 CF34921F8514 for ; Sat, 3 Nov 2012 22:24:31 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so3698212lbo.31 for ; Sat, 03 Nov 2012 22:24:30 -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=YuFHjBRc/SQKGfL5yNztxetS/KkzV+CE413fAzeEzlU=; b=f6XHQlFMOg+9p/FWQAQc8+JqqLG9YVtuSYG+7GDThAhtAsyEe/z3FR4+HI0EEO/EoX iTqfCG74iGNSHGk/FhhRfShgbJLk0C8Tx5krWWgmNCnxTypGKsj4pG7yyGWzEkRRc5cV ZHYgG01Fjgg/Xz8vyF0YwW4ETNdFxP7iux2+rOfGYEQeFoxThyjsjqL3Qb4SP6Xorai8 NSPGZw/wN9uKEUD7N+/OzsAk/v6TrKqvNjSK5wtmWrlMosu7RqXWX2Az3wOv4TBXKGPS xyToYFHs5eZX52FPkM+PFu/jOBsgSc3wgXGuVOPjQN5H+fKdAbsOPEukkUMpN3Zbs2Vo L1BQ== MIME-Version: 1.0 Received: by 10.112.17.40 with SMTP id l8mr2513044lbd.58.1352006670506; Sat, 03 Nov 2012 22:24:30 -0700 (PDT) Received: by 10.112.83.232 with HTTP; Sat, 3 Nov 2012 22:24:30 -0700 (PDT) Date: Sat, 3 Nov 2012 22:24:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d0401fb65545a0b04cda495b1 Subject: [apps-discuss] Presentations for Monday 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, 04 Nov 2012 05:24:32 -0000 --f46d0401fb65545a0b04cda495b1 Content-Type: text/plain; charset=ISO-8859-1 Anybody who has an agenda slot for Monday and wishes to use slides but has not yet submitted a slide deck, please do so ASAP. We will likely not accept new slide decks for use during Monday's meeting after Sunday night. Thanks, and see you all Monday morning, bright and early. -MSK, co-chair --f46d0401fb65545a0b04cda495b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anybody who has an agenda slot for Monday and wishes to use slides but has = not yet submitted a slide deck, please do so ASAP.=A0 We will likely not ac= cept new slide decks for use during Monday's meeting after Sunday night= .

Thanks, and see you all Monday morning, bright and early.

-MSK, = co-chair
--f46d0401fb65545a0b04cda495b1-- From masinter@adobe.com Sun Nov 4 00:38: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 3DD0D21F854F for ; Sun, 4 Nov 2012 00:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[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 8mQ12bkCA8Dg for ; Sun, 4 Nov 2012 00:38:46 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 990D921F854A for ; Sun, 4 Nov 2012 00:38:45 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUJYbhMQ4FqvNjwq1oxx5BSoV+hYDUBMH@postini.com; Sun, 04 Nov 2012 00:38:45 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qA47chHP022412 for ; Sun, 4 Nov 2012 00:38:43 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id qA47cgXL013840 for ; Sun, 4 Nov 2012 00:38:43 -0700 (PDT) Received: from SJ1SWM219.corp.adobe.com (10.5.77.61) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 4 Nov 2012 00:38:42 -0700 Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by SJ1SWM219.corp.adobe.com ([fe80::d55c:7209:7a34:fcf7%11]) with mapi; Sun, 4 Nov 2012 00:38:41 -0700 From: Larry Masinter To: IETF Apps Discuss Date: Sun, 4 Nov 2012 00:38:39 -0700 Thread-Topic: Topics on Apps & Web specs (from W3C / WHATWG ) Thread-Index: Ac26XrZYHgv8xYqFSEuVMYNM3T5x1A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C68CB012D9182D408CED7B884F441D4D1E36DA4673nambxv01acorp_" MIME-Version: 1.0 Subject: [apps-discuss] Topics on Apps & Web specs (from W3C / WHATWG ) 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, 04 Nov 2012 07:38:47 -0000 --_000_C68CB012D9182D408CED7B884F441D4D1E36DA4673nambxv01acorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since I didn't ask for an agenda slot on Monday, I'll suggest these as an i= nformal topics for anyone interested, perhaps a bar bof during the week. Bu= t If I could get a few minutes to announce these at apps area WG, that woul= d be great: * I've proposed using the IRI working group time slot to discuss updatin= g STD 66 / RFC 3896 URI spec, combining it with the IRIs and http://url.spe= c.whatwg.org 's algorithmic specification of URL processing. I didn't ask f= or agenda time before, but the topic came out of developments the last few = days at the W3C TPAC meeting. There are a couple of other "willful violatio= ns" in HTML based on current implementations not matching current specifica= tions, and I'd like to talk about those with anyone interested. * I'd like to talk about the HTML5 features of registerProtocolHandler, = registerContentHandler (where a web site can dynamically add itself as an = implementation of a new URI scheme and of a new MIME type, respectively) an= d its impact on the use of IANA registries. This is more speculative, but I= think fits into the previous "death of protocols" discussion in the IAB. --_000_C68CB012D9182D408CED7B884F441D4D1E36DA4673nambxv01acorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since I d= idn’t ask for an agenda slot on Monday, I’ll suggest these as a= n informal topics for anyone interested, perhaps a bar bof during the week.= But If I could get a few minutes to announce these at apps area WG, that w= ould be great:

 =

  • I’ve proposed using the= IRI working group time slot to discuss updating STD 66 / RFC 3896 URI spec= , combining it with the IRIs and htt= p://url.spec.whatwg.org ‘s algorithmic specification of URL proce= ssing. I didn’t ask for agenda time before, but the topic came out of= developments the last few days at the W3C TPAC meeting. There are a couple= of other “willful violations” in HTML based on current impleme= ntations not matching current specifications, and I’d like to talk ab= out those with anyone interested.

 

  • I= 217;d like to talk about the HTML5 features of registerProtocolHandler, reg= isterContentHandler  (where a web site can dynamically add itself as a= n implementation of a new URI scheme and of a new MIME type, respectively) = and its impact on the use of IANA registries. This is more speculative, but= I think fits into the previous “death of protocols” discussion= in the IAB.
= --_000_C68CB012D9182D408CED7B884F441D4D1E36DA4673nambxv01acorp_-- From melvincarvalho@gmail.com Sun Nov 4 05:45: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 85D1D21F8634 for ; Sun, 4 Nov 2012 05:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 Z+G7viqb806r for ; Sun, 4 Nov 2012 05:45:16 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5638221F862D for ; Sun, 4 Nov 2012 05:45:16 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so7729299iec.31 for ; Sun, 04 Nov 2012 05:45:13 -0800 (PST) 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=+WIw7GxhOwMldEEW/fy9Nbd0hE23dVNl46dRSnueOdo=; b=GkBRVLqCl4Ag9ojbmCCgVff0plXVbQOwwNIdyvIdpleKPDsvnh5WW9TnJBxlfe97JG gTDGwYvorayHEvQHzB1H3HgBLfS5UeyZnYHCr/2B4iIZE8gdQ/b/tGqB0aw9e0nAV/ss SLyTWt3zw/k9mclK1m4zFUsPMbd9RX/W7NGXBQ50DEKfbkeP8TsKFn9EQxkIedO+8UXj QLQdxeEwVeSKJJXc0kl7nVq/EZ7XndCF3oL24VNA96hVHq41aZQozS/pZ96AdkUNo35j nWS2x09lFcEMi4enUObbzucwyDWV6/yhVtyEY9gxBEBhYOoFmROIJc9Ip3hYJlRnrKno 64KQ== MIME-Version: 1.0 Received: by 10.43.134.65 with SMTP id ib1mr5999198icc.12.1352036713338; Sun, 04 Nov 2012 05:45:13 -0800 (PST) Received: by 10.42.247.129 with HTTP; Sun, 4 Nov 2012 05:45:13 -0800 (PST) In-Reply-To: <061d01cdba23$d174d910$745e8b30$@packetizer.com> References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> Date: Sun, 4 Nov 2012 14:45:13 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=20cf307f35180596ad04cdab94ad Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 04 Nov 2012 13:45:17 -0000 --20cf307f35180596ad04cdab94ad Content-Type: text/plain; charset=ISO-8859-1 On 4 November 2012 01:32, Paul E. Jones wrote: > Folks, > > So far, reaction has been positive in favor of option (2). As noted, this > would mean that WebFinger is, more-or-less, the equivalent of the LRDD > resource as defined in RFC 6415, except that the default representation > will > be application/json rather than application/xrd+xml. > > Before we start working on the new text, I do want to understand if folks > agree to the following usage & results. > > > $ curl -v 'https://packetizer.com/.well-known/webfinger' > -- returns 404, as there is no specified resource > -- Should there be a different response code? If so, what? > > > $ curl -v 'https://packetizer.com/.well-known/webfinger? > resource=acct:paulej@packetizer.com' > -- returns a JRD for the specified resource > -- Example: > { > "subject" : "acct:paulej@packetizer.com", > "links" : > [ > { > "rel" : "http://webfinger.net/rel/avatar", > "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg" > }, > { > "rel" : "http://schemas.google.com/g/2010#updates-from", > "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml" > }, > { > "rel" : "vcard", > "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" > } > ] > } > > > $ curl -v 'https://packetizer.com/.well-known/webfinger? > resource=acct:paulej@packetizer.com& > rel=vcard' > -- returns a JRD for the specified resource, filtered to include only > the space-separated list of link relations in the "rel" parameter > -- Example: > { > "subject" : "acct:paulej@packetizer.com", > "links" : > [ > { > "rel" : "vcard", > "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" > } > ] > } > > In all cases, the "resource" parameter might be any URI for which that > WebFinger server might be able to provide an answer. It might be an > "acct:" > URI, "mailto:" URI, "http:" URI, etc. I think that was generally agreed > before, though we had the dialog about how to deal with the "tel:" URI and > other such URIs that do not have domain names associated with them. > Should the email address appear somewhere in the data? Consider an analogy with RDBMS. 1. SELECT * from users where email = 'mailto:user@host' Would normally return the email too. In the slightly more complex version webfinger users it's something more like: 2a. SELECT * from users where primary_key = 'acct:user@host' or 2b SELECT resource from users where primary_key = 'acct:user@host' In a traditional data lookup you might expect to see an email come back, in the result set, as that's the foreign key from which the whole dance starts :) > > Paul > > > --20cf307f35180596ad04cdab94ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 4 November 2012 01:32, Paul E. Jones = <paulej@packetizer.com> wrote:
Folks,

So far, reaction has been positive in favor of option (2). =A0As noted, thi= s
would mean that WebFinger is, more-or-less, the equivalent of the LRDD
resource as defined in RFC 6415, except that the default representation wil= l
be application/json rather than application/xrd+xml.

Before we start working on the new text, I do want to understand if folks agree to the following usage & results.


$ curl -v 'https://packetizer.com/.well-known/webfinger'
-- returns 404, as there is no specified resource
-- Should there be a different response code? If so, what?


$ curl -v 'https://packetizer.com/.well-known/webfinger?
=A0 =A0 =A0 =A0 =A0 =A0resource=3Dacct:paulej@packetizer.com'
-- returns a JRD for the specified resource
-- Example:
{
=A0 "subject" : "acct:paulej@packetizer.com",
=A0 "links" :
=A0 [
=A0 =A0 {
=A0 =A0 =A0 "rel" : "http://webfinger.net/rel/avatar",
=A0 =A0 =A0 "href" : "http://www.packetizer.com= /people/paulej/images/paulej.jpg"
=A0 =A0 },
=A0 =A0 {
=A0 =A0 =A0 "rel" : "http://schemas.google.com/g/2010#updat= es-from",
=A0 =A0 =A0 "href" : "http://www.packetizer.com/peo= ple/paulej/blog/blog.xml"
=A0 =A0 },
=A0 =A0 {
=A0 =A0 =A0 "rel" : "vcard",
=A0 =A0 =A0 "href" : "http://www.packetizer.com/people= /paulej/paulej.vcf"
=A0 =A0 }
=A0 ]
}


$ curl -v 'https://packetizer.com/.well-known/webfinger?
=A0 =A0 =A0 =A0 =A0 =A0resource=3Dacct:paulej@packetizer.com&
=A0 =A0 =A0 =A0 =A0 =A0rel=3Dvcard'
-- returns a JRD for the specified resource, filtered to include only
=A0 =A0the space-separated list of link relations in the "rel" pa= rameter
-- Example:
{
=A0 "subject" : "acct:paulej@packetizer.com",
=A0 "links" :
=A0 [
=A0 =A0 {
=A0 =A0 =A0 "rel" : "vcard",
=A0 =A0 =A0 "href" : "http://www.packetizer.com/people= /paulej/paulej.vcf"
=A0 =A0 }
=A0 ]
}

In all cases, the "resource" parameter might be any URI for which= that
WebFinger server might be able to provide an answer. =A0It might be an &quo= t;acct:"
URI, "mailto:" URI, "http:" URI, etc. =A0I think that w= as generally agreed
before, though we had the dialog about how to deal with the "tel:"= ; URI and
other such URIs that do not have domain names associated with them.

Should the email address appear somewhere in the data?
Consider an analogy with RDBMS.

1. SELECT * from users where em= ail =3D 'mailto:user@host'

Would normally return the email too.

In the slightly more comple= x version webfinger users it's something more like:

2a. SELECT *= from users where primary_key =3D 'acct:user@host'

or
2b SELECT resource from users where primary_key =3D 'acct:user@host'= ;

In a traditional data lookup you might expect to see an email come= back, in the result set, as that's the foreign key from which the whol= e dance starts :)
=A0

Paul



--20cf307f35180596ad04cdab94ad-- From paulej@packetizer.com Sun Nov 4 08:04: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 2E7DB21F862D for ; Sun, 4 Nov 2012 08:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 OuW001kp5gag for ; Sun, 4 Nov 2012 08:03:57 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id AA31321F8590 for ; Sun, 4 Nov 2012 08:03:56 -0800 (PST) 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 qA4G3sZO020055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 4 Nov 2012 11:03:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1352045035; bh=KxAkYgkQURXOKHIhQZdE7obSiCKedzHt1w5dGxaFH/Y=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=ih3ZFGlwHcYjxHnR0kmyzkPgikwYkRPDWQnpXw8Ra56h0Sv8Jrk/DE42PtIUTBBgg 5lEiOJAhyJp4HenwM2QOwfmRdFida0rdDpNo/LdzAg5R4jgiJk9QBOMyre88eeJG75 sP2+26Bacg6XiGx6lqTZconr+POIpSnAJGNdnQGU= From: "Paul E. Jones" To: "'William Mills'" , , References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <1352004496.14504.YahooMailNeo@web31813.mail.mud.yahoo.com> In-Reply-To: <1352004496.14504.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Sun, 4 Nov 2012 11:04:07 -0500 Message-ID: <06cf01cdbaa6$05ad8dd0$1108a970$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06D0_01CDBA7C.1CD9F6D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHG5aGrJlMX7sxuIe9fbUyX8E9W5wGAMjwxl9t7EjA= Content-Language: en-us Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 04 Nov 2012 16:04:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06D0_01CDBA7C.1CD9F6D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit William, The purpose of the "resource" parameter is to allow the client to ask the server what it wants to know about. If the client wants to know about acct:paulej@packetizer.com, for example, it uses that as the value of the resource parameter. RFC 6415 has the notion of issuing a request to the host-meta resource without parameters. The response is an XRD document that contains host-meta information and "template" types that allow the client then then further query for resource-specific information, replacing the "{uri}" part in the template URI with that of the URI for which the client is seeking information. Paul From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Sunday, November 04, 2012 12:48 AM To: Paul E. Jones; apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Re: [apps-discuss] The /.well-known/webfinger resource I'm gonna ask something I should probably know, why is the resource parameter required? Is there no use case for generic discovery here in the current SF style? I find this surprising. _____ From: Paul E. Jones To: apps-discuss@ietf.org; webfinger@googlegroups.com Sent: Saturday, November 3, 2012 5:32 PM Subject: [apps-discuss] The /.well-known/webfinger resource Folks, So far, reaction has been positive in favor of option (2). As noted, this would mean that WebFinger is, more-or-less, the equivalent of the LRDD resource as defined in RFC 6415, except that the default representation will be application/json rather than application/xrd+xml. Before we start working on the new text, I do want to understand if folks agree to the following usage & results. $ curl -v 'https://packetizer.com/.well-known/webfinger' -- returns 404, as there is no specified resource -- Should there be a different response code? If so, what? $ curl -v 'https://packetizer.com/.well-known/webfinger? resource=acct:paulej@packetizer.com' -- returns a JRD for the specified resource -- Example: { "subject" : "acct:paulej@packetizer.com", "links" : [ { "rel" : "http://webfinger.net/rel/avatar", "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg" }, { "rel" : "http://schemas.google.com/g/2010#updates-from", "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml" }, { "rel" : "vcard", "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" } ] } $ curl -v 'https://packetizer.com/.well-known/webfinger? resource=acct:paulej@packetizer.com& rel=vcard' -- returns a JRD for the specified resource, filtered to include only the space-separated list of link relations in the "rel" parameter -- Example: { "subject" : "acct:paulej@packetizer.com", "links" : [ { "rel" : "vcard", "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" } ] } In all cases, the "resource" parameter might be any URI for which that WebFinger server might be able to provide an answer. It might be an "acct:" URI, "mailto:" URI, "http:" URI, etc. I think that was generally agreed before, though we had the dialog about how to deal with the "tel:" URI and other such URIs that do not have domain names associated with them. Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_06D0_01CDBA7C.1CD9F6D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

William,

 

The purpose of the “resource” parameter is to allow the = client to ask the server what it wants to know about.  If the = client wants to know about acct:paulej@packetizer.com, for example, it = uses that as the value of the resource = parameter.

 

RFC 6415 has the notion of issuing a request to the host-meta = resource without parameters.  The response is an XRD document that = contains host-meta information and “template” types that = allow the client then then further query for resource-specific = information, replacing the “{uri}” part in the template URI = with that of the URI for which the client is seeking = information.

 

Paul

 

 

From:= = William Mills [mailto:wmills@yahoo-inc.com]
Sent: Sunday, = November 04, 2012 12:48 AM
To: Paul E. Jones; = apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: = [apps-discuss] The /.well-known/webfinger = resource

 

I'm = gonna ask something I should probably know, why is the resource = parameter required?  Is there no use case for generic discovery = here in the current SF style?  I find this = surprising.

 

 

<= hr size=3D1 width=3D"100%" align=3Dcenter>

F= rom: = Paul E. Jones <paulej@packetizer.com>
To: apps-discuss@ietf.org; webfinger@googlegroups.com=
Sent: Saturday, November 3, 2012 5:32 PM
Subject: = [apps-discuss] The /.well-known/webfinger resource


Folks,

So far, reaction has been = positive in favor of option (2).  As noted, this
would mean that = WebFinger is, more-or-less, the equivalent of the LRDD
resource as = defined in RFC 6415, except that the default representation will
be = application/json rather than application/xrd+xml.

Before we start = working on the new text, I do want to understand if folks
agree to = the following usage & results.


$ curl -v 'https://packetizer.com/.well-known/webfinger'
--= returns 404, as there is no specified resource
-- Should there be a = different response code? If so, what?


$ curl -v 'https://packetizer.com/.well-known/webfinger?
&n= bsp;         resource=3Dacct:paulej@packetizer.com'
-- = returns a JRD for the specified resource
-- Example:
{
  = "subject" : "acct:paulej@packetizer.com",  "links" :
  [
    {
  =     "rel" : "http://webfinger.net/rel/avatar",
  =     "href" : "http://www.packetizer.com/people/paulej/images/paulej.j= pg"
    },
    {
    =   "rel" : "http://schemas.google.com/g/2010#updates-from"= ,
      "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml"
    },
    {
      = "rel" : "vcard",
      = "href" : "http://www.packetizer.com/people/paulej/paulej.vcf&= quot;
    }
  ]
}


$ curl -v 'https://packetizer.com/.well-known/webfinger?
&n= bsp;         resource=3Dacct:paulej@packetizer.com&
&= nbsp;         rel=3Dvcard'
-- returns a JRD for = the specified resource, filtered to include only
  the = space-separated list of link relations in the "rel" = parameter
-- Example:
{
  "subject" : = "acct:paulej@packetizer.com",  "links" :
  [
    {
  =     "rel" : "vcard",
    =   "href" : "http://www.packetizer.com/people/paulej/paulej.vcf&= quot;
    }
  ]
}

In all cases, the = "resource" parameter might be any URI for which = that
WebFinger server might be able to provide an answer.  It = might be an "acct:"
URI, "mailto:" URI, = "http:" URI, etc.  I think that was generally = agreed
before, though we had the dialog about how to deal with the = "tel:" URI and
other such URIs that do not have domain = names associated with = them.

Paul


____________________________________________= ___
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= br>

<= /div> ------=_NextPart_000_06D0_01CDBA7C.1CD9F6D0-- From bradfitz@google.com Sun Nov 4 01:55: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 1715921F8652 for ; Sun, 4 Nov 2012 01:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.194 X-Spam-Level: X-Spam-Status: No, score=-102.194 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 mTSQRRvVDPze for ; Sun, 4 Nov 2012 01:55:34 -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 3E69A21F8643 for ; Sun, 4 Nov 2012 01:55:34 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so5185767obq.31 for ; Sun, 04 Nov 2012 01:55:33 -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=fM/jC/vHuGAxNsP/O9AzsEDkEAZUO6jrH6f5vvtUFdE=; b=FU4AFerQ0a24O8cpZR8kcRQIIIwNGnWXdZkAnTSWRjPtyhmpYYjNnAGedviTFSfA2c E08VCX29BIi8oNO5hQ+FcaqQFD7dcEY1jzNXMgGb1hIISkg9fa1m3dD7SQG6PE0LAn01 BXuoM9qi3kcZl1ssaKI4/sRH0qb3z2V+MTx27xfJmet0zuYFZnxgx6cT/NmectZGU/Fu a0T2ZMHnDGyczHZoGnjesMhJJpItBQQyeTLwFLAzV0CPe6HES4atLFyF3LfshluTF/OH GrdjOBr1GDfq7/L7mBMYmfT7wOOokjuinMlnNeneuvATdsNmjDu4eRdUAGQM5UySgEKz 6QWw== 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=fM/jC/vHuGAxNsP/O9AzsEDkEAZUO6jrH6f5vvtUFdE=; b=aG+ygUgzwsGCr7ruCFOIWr4d7XfxcA3bqa6AMAwtrpRMb2pZ+dhxe2LvH/vtxtW53k gbavH5ucG5vfXPsfDqGa/Cb3421utboydFgF1MI3jfuqZnFQAZ6TN18FmebvBOTmhOO/ +Q50r8Cc9yt2E+Iimhu0TYtZBNMEAJ6TaoCYue7mhuFTF4LjTxHQAdKVsibbgiZJFEYE d/GwczntpZNpva0WBdQ+aM6tjUOVSty87B+JLYECcvvzmInPNdw9coIjF2R6AXudMqo7 nyY1jyzBaj0VT8LN6gfFaMDjaVjWrL8n0NgJmKzy4yvviW2nHroj4J5AZzbP6ZZ01Eor ND5g== MIME-Version: 1.0 Received: by 10.60.20.41 with SMTP id k9mr5411627oee.39.1352019333724; Sun, 04 Nov 2012 01:55:33 -0700 (PDT) Received: by 10.60.31.41 with HTTP; Sun, 4 Nov 2012 01:55:33 -0700 (PDT) In-Reply-To: <061d01cdba23$d174d910$745e8b30$@packetizer.com> References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> Date: Sun, 4 Nov 2012 09:55:33 +0100 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8fb207101db9bd04cda78852 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlJOvmqQLIApsWgR0lJiAKfQ/YyH2aZ9o2c8O1I84usQ0V/cfj2J/SThSrL0DVbOqZQqRbh0nzLBApfWoIkRRljTzyBSZXPBHYxF2h0t6TSWC3ttrbDnG2nqqbbeAE+IXTHhtBJDCE1l/VSZEdpqjarW3ffj7+52Ez9389bLRCw2dgyqj6EuW/rX/GOEEgyCNfTh12c X-Mailman-Approved-At: Sun, 04 Nov 2012 08:04:48 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 04 Nov 2012 08:55:35 -0000 --e89a8fb207101db9bd04cda78852 Content-Type: text/plain; charset=UTF-8 Yes, I support this simplified spec. On Sun, Nov 4, 2012 at 1:32 AM, Paul E. Jones wrote: > Folks, > > So far, reaction has been positive in favor of option (2). As noted, this > would mean that WebFinger is, more-or-less, the equivalent of the LRDD > resource as defined in RFC 6415, except that the default representation > will > be application/json rather than application/xrd+xml. > > Before we start working on the new text, I do want to understand if folks > agree to the following usage & results. > > > $ curl -v 'https://packetizer.com/.well-known/webfinger' > -- returns 404, as there is no specified resource > -- Should there be a different response code? If so, what? > I'm not sure there's a need to specify the exact error code here. I think I'd probably return a 400 Bad Request with text "Missing 'resource' query parameter" but if others returned a 404 or even a 500, I wouldn't be offended. Just document that it must contain a resource parameter. Not worth specifying rare parts that people will ignore anyway. > $ curl -v 'https://packetizer.com/.well-known/webfinger? > resource=acct:paulej@packetizer.com' > -- returns a JRD for the specified resource > -- Example: > { > "subject" : "acct:paulej@packetizer.com", > "links" : > [ > { > "rel" : "http://webfinger.net/rel/avatar", > "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg" > }, > { > "rel" : "http://schemas.google.com/g/2010#updates-from", > "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml" > }, > { > "rel" : "vcard", > "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" > } > ] > } > > > $ curl -v 'https://packetizer.com/.well-known/webfinger? > resource=acct:paulej@packetizer.com& > rel=vcard' > -- returns a JRD for the specified resource, filtered to include only > the space-separated list of link relations in the "rel" parameter > Why space-separated? I can live with that, but it seems like the more natural thing to do would be to use multiple rel parameters: webfinger?resource=bob&rel=vcard&rel=blog&rel=openid.server Also, I don't recall, but I assume it's only a SHOULD that the server filter the returned list for the requested rels? If a server instead only looked at the "resource" parameter and always returned all link relations on every request, I think that'd be nice to still be a compliant server. That might also satisfy the increasingly-small-but-still-existent camp who want webfinger to work with "static" webservers: a URI rewrite rule like mod_rewrite can regexp out the "resource=([^&]+?) from the query and map it to a file on disk. In all cases, the "resource" parameter might be any URI for which that > WebFinger server might be able to provide an answer. It might be an > "acct:" > URI, "mailto:" URI, "http:" URI, etc. I think that was generally agreed > before, though we had the dialog about how to deal with the "tel:" URI and > other such URIs that do not have domain names associated with them. > Don't disallow tel: for sure. (I can certainly think of a phone number of mine I'd love to see work with webfinger...) But don't go out of your way specifying how to it should or shouldn't work. - Brad --e89a8fb207101db9bd04cda78852 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= div>Yes, I support this simplified spec.

On Sun, Nov 4,= 2012 at 1:32 AM, Paul E. Jones <paulej@packetizer.com> = wrote:
Folks,

So far, reaction has been positive in favor of option (2). =C2=A0As noted, = this
would mean that WebFinger is, more-or-less, the equivalent of the LRDD
resource as defined in RFC 6415, except that the default representation wil= l
be application/json rather than application/xrd+xml.

Before we start working on the new text, I do want to understand if folks agree to the following usage & results.


$ curl -v 'https://packetizer.com/.well-known/webfinger'
-- returns 404, as there is no specified resource
-- Should there be a different response code? If so, what?
=

I'm not sure there's a need to specify the exac= t error code here. =C2=A0I think I'd probably return a 400 Bad Request = with text "Missing 'resource' query parameter" but if oth= ers returned a 404 or even a 500, I wouldn't be offended. =C2=A0Just do= cument that it must contain a resource parameter. =C2=A0Not worth specifyin= g rare parts that people will ignore anyway.
=C2=A0
$ curl -v 'https://pack= etizer.com/.well-known/webfinger?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0resource=3Dacct:paulej@packetizer.com'
-- returns a JRD for the specified resource
-- Example:
{
=C2=A0 "subject" : "acct:paulej@packetizer.com",
=C2=A0 "links" :
=C2=A0 [
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "rel" : "http://webfinger.net/rel/avatar",<= br> =C2=A0 =C2=A0 =C2=A0 "href" : "http://www.packe= tizer.com/people/paulej/images/paulej.jpg"
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "rel" : "http://schemas.google.com/g/2= 010#updates-from",
=C2=A0 =C2=A0 =C2=A0 "href" : "http://www.packetize= r.com/people/paulej/blog/blog.xml"
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "rel" : "vcard",
=C2=A0 =C2=A0 =C2=A0 "href" : "http://www.packetizer.c= om/people/paulej/paulej.vcf"
=C2=A0 =C2=A0 }
=C2=A0 ]
}


$ curl -v 'https://packetizer.com/.well-known/webfinger?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0resource=3Dacct:paulej@packetizer.com&
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rel=3Dvcard'
-- returns a JRD for the specified resource, filtered to include only
=C2=A0 =C2=A0the space-separated list of link relations in the "rel&qu= ot; parameter

Why space-separated? =C2= =A0I can live with that, but it seems like the more natural thing to do wou= ld be to use multiple rel parameters:

webfinger?resource=3Dbob&rel=3Dvcard&rel=3Dblog= &rel=3Dopenid.server

Also, I don't recall,= but I assume it's only a SHOULD that the server filter the returned li= st for the requested rels?

If a server instead only looked at the "resource&q= uot; parameter and always returned all link relations on every request, I t= hink that'd be nice to still be a compliant server. =C2=A0That might al= so satisfy the increasingly-small-but-still-existent camp who want webfinge= r to work with "static" webservers: a URI rewrite rule like mod_r= ewrite can regexp out the "resource=3D([^&]+?) from the query and = map it to a file on disk.

In all cases, the "resou= rce" parameter might be any URI for which that
WebFinger server might be able to provide an answer. =C2=A0It might be an &= quot;acct:"
URI, "mailto:" URI, "http:" URI, etc. =C2=A0I think tha= t was generally agreed
before, though we had the dialog about how to deal with the "tel:"= ; URI and
other such URIs that do not have domain names associated with them.

Don't disallow tel: for sure. =C2=A0(I can= certainly think of a phone number of mine I'd love to see work with we= bfinger...) =C2=A0But don't go out of your way specifying how to it sho= uld or shouldn't work.

- Brad

--e89a8fb207101db9bd04cda78852-- From cweiske@cweiske.de Sun Nov 4 01:42: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 002AA21F86A7 for ; Sun, 4 Nov 2012 01:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, J_CHICKENPOX_35=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 d2s15GsDfiQV for ; Sun, 4 Nov 2012 01:42:29 -0800 (PST) Received: from mail.cweiske.de (mail.cweiske.de [IPv6:2a01:488:66:1000:53a9:7c6:0:1]) by ietfa.amsl.com (Postfix) with ESMTP id DBACB21F86A3 for ; Sun, 4 Nov 2012 01:42:28 -0800 (PST) Received: by mail.cweiske.de (Postfix, from userid 65534) id 063A110438004; Sun, 4 Nov 2012 10:42:27 +0100 (CET) Received: from bogo (p54BD788A.dip.t-dialin.net [84.189.120.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.cweiske.de (Postfix) with ESMTPSA id 75F7610438003; Sun, 4 Nov 2012 10:42:26 +0100 (CET) Date: Sun, 4 Nov 2012 10:42:28 +0100 From: Christian Weiske To: webfinger@googlegroups.com Message-ID: <20121104104228.5a49c685@bogo> In-Reply-To: References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/eTloq_ECNctHSjqTKDtUnVN"; protocol="application/pgp-signature" X-Mailman-Approved-At: Sun, 04 Nov 2012 08:05:02 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 04 Nov 2012 09:42:30 -0000 --Sig_/eTloq_ECNctHSjqTKDtUnVN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Brad, > > Before we start working on the new text, I do want to understand if > > folks agree to the following usage & results. > > $ curl -v 'https://packetizer.com/.well-known/webfinger' > > -- returns 404, as there is no specified resource > > -- Should there be a different response code? If so, what? > I'm not sure there's a need to specify the exact error code here. I > think I'd probably return a 400 Bad Request with text "Missing > 'resource' query parameter" That'd be the correct solution. The resource parameter is required, and failing to provide it is a user error. In contrast to a 404, it says "we support webfinger, but you didn't give us all we need to answer the request". A 404 says "we don't support webfinger". > > $ curl -v 'https://packetizer.com/.well-known/webfinger? > > resource=3Dacct:paulej@packetizer.com' > > -- returns a JRD for the specified resource Yep. > > $ curl -v 'https://packetizer.com/.well-known/webfinger? > > resource=3Dacct:paulej@packetizer.com& > > rel=3Dvcard' > > -- returns a JRD for the specified resource, filtered to include > > only the space-separated list of link relations in the "rel" > > parameter > Why space-separated? I can live with that, but it seems like the more > natural thing to do would be to use multiple rel parameters: Space separation would introduce problems with rel URLs that have spaces in them. You'd need to take care of double encoding the rel URL, while single-encoding the " " that separate the rels. > webfinger?resource=3Dbob&rel=3Dvcard&rel=3Dblog&rel=3Dopenid.server Because of the double-encoding issue, I support the multiple rel parameter approach. > Also, I don't recall, but I assume it's only a SHOULD that the server > filter the returned list for the requested rels. I second that, too - because it would be impossible to serve the files statically. > In all cases, the "resource" parameter might be any URI for which that > > WebFinger server might be able to provide an answer. > Don't disallow tel: for sure. (I can certainly think of a phone > number of mine I'd love to see work with webfinger...) But don't go > out of your way specifying how to it should or shouldn't work. Yes, there should be no restriction on what URIs are allowed. If I want to host a book information system that provides webfinger for ISBN numbers, the spec should not try to hinder that. --=20 Regards/Mit freundlichen Gr=C3=BC=C3=9Fen Christian Weiske -=3D=E2=89=A1 Geeking around in the name of science since 1982 =E2=89=A1=3D- --Sig_/eTloq_ECNctHSjqTKDtUnVN Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlCWOIQACgkQFMhaCCTq+CNC1wCdG4sRtXZl0Q2vVAMJ9dRNUpyd 1I4AoM50ZfVH6s/aXci4BN+gVCiNnPLW =bgrw -----END PGP SIGNATURE----- --Sig_/eTloq_ECNctHSjqTKDtUnVN-- From romeda@gmail.com Sun Nov 4 08:26: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 9FC5121F8739 for ; Sun, 4 Nov 2012 08:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 dTdyGi3yBUhS for ; Sun, 4 Nov 2012 08:26:19 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 862C721F8734 for ; Sun, 4 Nov 2012 08:26:19 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so3387937pad.31 for ; Sun, 04 Nov 2012 08:26:19 -0800 (PST) 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=UqA+/PxsgZqcqqfjZXcME5UUQ9tECRrVjYhNFejiTm8=; b=1APZ8u4E1wLZMqmPQqnaYSG9ItOaHX06Ui7wXY5vqHo+4o+NV/QKrd6V+iDP03q+yj mHtA+Ay4F1aH4VaDkBrq7AGdfSoi44b4EevEqTovXJNIgy7wgWFDu2IQ3gyfrU/Odibq Crpf99HHPnE0Vi9GoxMGIaSIrSuRGs79Vz/v2XT8uSE8LsYFLkc4Wc2AH3shbOsf92yD aPth/z4XXblbjSkWACmkxFzSsfU/HRukSCiOb+FeCXMBtK4zbK+i5oafqYXJYgfMdDuJ 04uR3lqogfsCYPVGtfqwFYsUWX0cGNyiu4qAaJOLF9A0AFf1xXhKQMcU1Ok5yadZC3ba tyQg== Received: by 10.68.217.67 with SMTP id ow3mr23425985pbc.26.1352046379330; Sun, 04 Nov 2012 08:26:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.67.2.101 with HTTP; Sun, 4 Nov 2012 08:25:59 -0800 (PST) In-Reply-To: <06cf01cdbaa6$05ad8dd0$1108a970$@packetizer.com> References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <1352004496.14504.YahooMailNeo@web31813.mail.mud.yahoo.com> <06cf01cdbaa6$05ad8dd0$1108a970$@packetizer.com> From: Blaine Cook Date: Sun, 4 Nov 2012 16:25:59 +0000 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8ff246e128ed9004cdadd4c6 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 04 Nov 2012 16:26:20 -0000 --e89a8ff246e128ed9004cdadd4c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In practice, the scheme will be irrelevant. Requests for " acct:bob@example.com", or "mailto:bob@example.com", and "bob@example.com" will be treated the same. I suspect that owing to Postel's Law, Google et. al. will just strip out the scheme (as with SMTP). Likewise, if "tel:" URIs are supported by webfinger hosts, then webfinger providers will work very hard to translate "things that look like phone numbers" into "normalised representations of phone numbers", since there is so much inconsistency in input formats of telephone numbers. I don't think this has any bearing on the spec, but perhaps worthwhile noting. b. On 4 November 2012 16:04, Paul E. Jones wrote: > William,**** > > ** ** > > The purpose of the =E2=80=9Cresource=E2=80=9D parameter is to allow the c= lient to ask the > server what it wants to know about. If the client wants to know about > acct:paulej@packetizer.com, for example, it uses that as the value of the > resource parameter.**** > > ** ** > > RFC 6415 has the notion of issuing a request to the host-meta resource > without parameters. The response is an XRD document that contains > host-meta information and =E2=80=9Ctemplate=E2=80=9D types that allow the= client then then > further query for resource-specific information, replacing the =E2=80=9C{= uri}=E2=80=9D part > in the template URI with that of the URI for which the client is seeking > information.**** > > ** ** > > Paul**** > > ** ** > > ** ** > > *From:* William Mills [mailto:wmills@yahoo-inc.com] > *Sent:* Sunday, November 04, 2012 12:48 AM > *To:* Paul E. Jones; apps-discuss@ietf.org; webfinger@googlegroups.com > *Subject:* Re: [apps-discuss] The /.well-known/webfinger resource**** > > ** ** > > I'm gonna ask something I should probably know, why is the resource > parameter required? Is there no use case for generic discovery here in t= he > current SF style? I find this surprising.**** > > ** ** > > ** ** > ------------------------------ > > *From:* Paul E. Jones > *To:* apps-discuss@ietf.org; webfinger@googlegroups.com > *Sent:* Saturday, November 3, 2012 5:32 PM > *Subject:* [apps-discuss] The /.well-known/webfinger resource**** > > > Folks, > > So far, reaction has been positive in favor of option (2). As noted, thi= s > would mean that WebFinger is, more-or-less, the equivalent of the LRDD > resource as defined in RFC 6415, except that the default representation > will > be application/json rather than application/xrd+xml. > > Before we start working on the new text, I do want to understand if folks > agree to the following usage & results. > > > $ curl -v 'https://packetizer.com/.well-known/webfinger' > -- returns 404, as there is no specified resource > -- Should there be a different response code? If so, what? > > > $ curl -v 'https://packetizer.com/.well-known/webfinger? > resource=3Dacct:paulej@packetizer.com' > -- returns a JRD for the specified resource > -- Example: > { > "subject" : "acct:paulej@packetizer.com", > "links" : > [ > { > "rel" : "http://webfinger.net/rel/avatar", > "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg= " > }, > { > "rel" : "http://schemas.google.com/g/2010#updates-from", > "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml" > }, > { > "rel" : "vcard", > "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" > } > ] > } > > > $ curl -v 'https://packetizer.com/.well-known/webfinger? > resource=3Dacct:paulej@packetizer.com& > rel=3Dvcard' > -- returns a JRD for the specified resource, filtered to include only > the space-separated list of link relations in the "rel" parameter > -- Example: > { > "subject" : "acct:paulej@packetizer.com", > "links" : > [ > { > "rel" : "vcard", > "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" > } > ] > } > > In all cases, the "resource" parameter might be any URI for which that > WebFinger server might be able to provide an answer. It might be an > "acct:" > URI, "mailto:" URI, "http:" URI, etc. I think that was generally agreed > before, though we had the dialog about how to deal with the "tel:" URI an= d > other such URIs that do not have domain names associated with them. > > Paul > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > **** > > --e89a8ff246e128ed9004cdadd4c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In practice, the scheme will be irrelevant. Requests for "acct:bob@example.com", or "mail= to:bob@example.com", and "= bob@example.com" will be treate= d the same. I suspect that owing to Postel's Law, Google et. al. will j= ust strip out the scheme (as with SMTP).

Likewise, if "tel:" URIs are supported by webfinge= r hosts, then webfinger providers will work very hard to translate "th= ings that look like phone numbers" into "normalised representatio= ns of phone numbers", since there is so much inconsistency in input fo= rmats of telephone numbers.

I don't think this has any bearing on the spec, but= perhaps worthwhile noting.

b.


On 4 November 2012 16:04, P= aul E. Jones <paulej@packetizer.com> wrote:

William,

=C2=A0

The purpose of the = =E2=80=9Cresource=E2=80=9D parameter is to allow the client to ask the serv= er what it wants to know about.=C2=A0 If the client wants to know about acct:paulej@= packetizer.com, for example, it uses that as the value of the resource = parameter.

=C2=A0

RFC 6415 has the no= tion of issuing a request to the host-meta resource without parameters.=C2= =A0 The response is an XRD document that contains host-meta information and= =E2=80=9Ctemplate=E2=80=9D types that allow the client then then further q= uery for resource-specific information, replacing the =E2=80=9C{uri}=E2=80= =9D part in the template URI with that of the URI for which the client is s= eeking information.

=C2=A0

Paul<= /span>

=C2=A0

=C2=A0

From:= William Mills [mailto:wmills@yahoo-inc.com]
Sent: Sunday, November 04, 2012 12:48 AM
To: Paul E. Jones= ; apps-discuss@i= etf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] The /.well-known/webfinger resource

=C2=A0

I'm gonna ask something I should probably know, why is the resource pa= rameter required?=C2=A0 Is there no use case for generic discovery here in = the current SF style?=C2=A0 I find this surprising.

=C2=A0

=C2=A0

=

From: Paul E. Jones <paulej@packetizer.com>
To: apps-= discuss@ietf.org; webfinger@googlegroups.com
Sent: Saturday, Novem= ber 3, 2012 5:32 PM
Subject: [apps-discuss] The /.well-known/webfinger resource


Folks,

So far, = reaction has been positive in favor of option (2).=C2=A0 As noted, this
would mean that WebFinger is, more-or-less, the equivalent of the LRDD
r= esource as defined in RFC 6415, except that the default representation will=
be application/json rather than application/xrd+xml.

Before we s= tart working on the new text, I do want to understand if folks
agree to the following usage & results.


$ curl -v 'ht= tps://packetizer.com/.well-known/webfinger'
-- returns 404, as t= here is no specified resource
-- Should there be a different response code? If so, what?


$ cur= l -v 'https://packetizer.com/.well-known/webfinger?
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 resource=3Dacct:paulej@packetizer.com'
-- returns a JRD for the specified resource
-- Example:
{
=C2=A0 &= quot;subject" : "acct:paulej@packetizer.com",
=C2=A0 "links"= ; :
=C2=A0 [
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "rel" : "http://webfinger.net/rel= /avatar",
=C2=A0 =C2=A0 =C2=A0 "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg" =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "rel"= : "http://schemas.google.com/g/2010#updates-from",
=C2= =A0 =C2=A0 =C2=A0 "href" : "http://www.packetizer.c= om/people/paulej/blog/blog.xml"
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "rel"= : "vcard",
=C2=A0 =C2=A0 =C2=A0 "href" : "http://www.packetizer.com/people/paulej/paulej.vcf"
=C2=A0 =C2=A0 }
=C2=A0 ]
}


$ curl -v 'https://packetiz= er.com/.well-known/webfinger?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 res= ource=3Dacct:pau= lej@packetizer.com&
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rel=3Dvcard'
-- returns a JRD for= the specified resource, filtered to include only
=C2=A0 the space-separ= ated list of link relations in the "rel" parameter
-- Example:=
{
=C2=A0 "subject" : "acct:paulej@packetizer.com",
=C2=A0 "links" :
=C2=A0 [
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 = =C2=A0 "rel" : "vcard",
=C2=A0 =C2=A0 =C2=A0 "h= ref" : "http://www.packetizer.com/people/paulej/paulej.vcf<= /a>"
=C2=A0 =C2=A0 }
=C2=A0 ]
}

In all cases, the "resource&qu= ot; parameter might be any URI for which that
WebFinger server might be = able to provide an answer.=C2=A0 It might be an "acct:"
URI, &= quot;mailto:" URI, "http:" URI, etc.=C2=A0 I think that was = generally agreed
before, though we had the dialog about how to deal with the "tel:"= ; URI and
other such URIs that do not have domain names associated with = them.

Paul


______________________________________________= _
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailma= n/listinfo/apps-discuss


--e89a8ff246e128ed9004cdadd4c6-- From paulej@packetizer.com Sun Nov 4 08:45: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 7371C21F8643 for ; Sun, 4 Nov 2012 08:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 62-dwqGU4Wv1 for ; Sun, 4 Nov 2012 08:45:29 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4950A21F8615 for ; Sun, 4 Nov 2012 08:45:29 -0800 (PST) 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 qA4GjQXK021959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 4 Nov 2012 11:45:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1352047527; bh=CQHIJqO7Z+muw90/0c3+aoB4kpLlzEPWl3QL5yPdIlI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=g1+QqaitxJP1/Y5YTHiBc1BI23P85ikOylgjbeD3zvGCupXHWEpQs9yRdyHVMFEcB vUD9Tt3K5M4FSLjBShCR+saMMyC35fswzI1x2LP2d1cg4nvR49DPx89cLbpCqtJF4T K747Rqza5xS9gZNk8L2yPva3tVdr1GRokAdDGKPA= From: "Paul E. Jones" To: "'Melvin Carvalho'" , References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> In-Reply-To: Date: Sun, 4 Nov 2012 11:45:40 -0500 Message-ID: <070f01cdbaab$d327d770$79778650$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0710_01CDBA81.EA51CF70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHG5aGrJlMX7sxuIe9fbUyX8E9W5wJ+6+f4l9OKb/A= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 04 Nov 2012 16:45:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0710_01CDBA81.EA51CF70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, Bit off topic, but as a matter or practice, I never use "*" in an SQL statement. If you ask for fields explicitly, you get what you want every time. If you use "*", it works today, but then if somebody modifies the underlying table and introduces a new field or moves a column, then the impact on the application can be quite unpredictable. To your question, though, the thing being queried does come back as the "subject" in the JRD document. Paul From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Melvin Carvalho Sent: Sunday, November 04, 2012 8:45 AM To: webfinger@googlegroups.com Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The /.well-known/webfinger resource On 4 November 2012 01:32, Paul E. Jones wrote: Folks, So far, reaction has been positive in favor of option (2). As noted, this would mean that WebFinger is, more-or-less, the equivalent of the LRDD resource as defined in RFC 6415, except that the default representation will be application/json rather than application/xrd+xml. Before we start working on the new text, I do want to understand if folks agree to the following usage & results. $ curl -v 'https://packetizer.com/.well-known/webfinger' -- returns 404, as there is no specified resource -- Should there be a different response code? If so, what? $ curl -v 'https://packetizer.com/.well-known/webfinger? resource=acct:paulej@packetizer.com ' -- returns a JRD for the specified resource -- Example: { "subject" : "acct:paulej@packetizer.com ", "links" : [ { "rel" : "http://webfinger.net/rel/avatar", "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg" }, { "rel" : "http://schemas.google.com/g/2010#updates-from", "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml" }, { "rel" : "vcard", "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" } ] } $ curl -v 'https://packetizer.com/.well-known/webfinger? resource=acct:paulej@packetizer.com & rel=vcard' -- returns a JRD for the specified resource, filtered to include only the space-separated list of link relations in the "rel" parameter -- Example: { "subject" : "acct:paulej@packetizer.com ", "links" : [ { "rel" : "vcard", "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" } ] } In all cases, the "resource" parameter might be any URI for which that WebFinger server might be able to provide an answer. It might be an "acct:" URI, "mailto:" URI, "http:" URI, etc. I think that was generally agreed before, though we had the dialog about how to deal with the "tel:" URI and other such URIs that do not have domain names associated with them. Should the email address appear somewhere in the data? Consider an analogy with RDBMS. 1. SELECT * from users where email = 'mailto:user@host' Would normally return the email too. In the slightly more complex version webfinger users it's something more like: 2a. SELECT * from users where primary_key = 'acct:user@host' or 2b SELECT resource from users where primary_key = 'acct:user@host' In a traditional data lookup you might expect to see an email come back, in the result set, as that's the foreign key from which the whole dance starts :) Paul ------=_NextPart_000_0710_01CDBA81.EA51CF70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

Bit off topic, but as a matter or practice, I never use = “*” in an SQL statement.  If you ask for fields = explicitly, you get what you want every time.  If you use = “*”, it works today, but then if somebody modifies the = underlying table and introduces a new field or moves a column, then the = impact on the application can be quite = unpredictable.

 

To your question, though, the thing being queried does come back as = the “subject” in the JRD document.

 

Paul

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Melvin Carvalho
Sent: Sunday, November 04, = 2012 8:45 AM
To: webfinger@googlegroups.com
Cc: = apps-discuss@ietf.org
Subject: Re: [apps-discuss] The = /.well-known/webfinger resource

 

 

On 4 November 2012 01:32, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

So far, reaction has been positive in = favor of option (2).  As noted, this
would mean that WebFinger = is, more-or-less, the equivalent of the LRDD
resource as defined in = RFC 6415, except that the default representation will
be = application/json rather than application/xrd+xml.

Before we start = working on the new text, I do want to understand if folks
agree to = the following usage & results.


$ curl -v 'https://packetizer.com/.well-known/webfinger'
--= returns 404, as there is no specified resource
-- Should there be a = different response code? If so, what?


$ curl -v 'https://packetizer.com/.well-known/webfinger?
&n= bsp;          resource=3Dacct:paulej@packetizer.com'
-- returns a JRD for the specified resource
-- = Example:
{
  "subject" : "acct:paulej@packetizer.com",
  "links" :
  [
    = {
      "rel" : "http://webfinger.net/rel/avatar",
  =     "href" : "http://www.packetizer.com/people/paulej/images/paulej.j= pg"
    },
    {
    =   "rel" : "http://schemas.google.com/g/2010#updates-from"= ,
      "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml"
    },
    {
      = "rel" : "vcard",
      = "href" : "http://www.packetizer.com/people/paulej/paulej.vcf&= quot;
    }
  ]
}


$ curl -v 'https://packetizer.com/.well-known/webfinger?
&n= bsp;          resource=3Dacct:paulej@packetizer.com&
           rel=3Dvcard'
-- = returns a JRD for the specified resource, filtered to include = only
   the space-separated list of link relations in the = "rel" parameter
-- Example:
{
  = "subject" : "acct:paulej@packetizer.com",
  "links" :
  [
    = {
      "rel" : "vcard",
  =     "href" : "http://www.packetizer.com/people/paulej/paulej.vcf&= quot;
    }
  ]
}

In all cases, the = "resource" parameter might be any URI for which = that
WebFinger server might be able to provide an answer.  It = might be an "acct:"
URI, "mailto:" URI, = "http:" URI, etc.  I think that was generally = agreed
before, though we had the dialog about how to deal with the = "tel:" URI and
other such URIs that do not have domain = names associated with them.


Should the email address appear somewhere in the = data?

Consider an analogy with RDBMS.

1. SELECT * from = users where email =3D 'mailto:user@host'

Would normally return = the email too.

In the slightly more complex version webfinger = users it's something more like:

2a. SELECT * from users where = primary_key =3D 'acct:user@host'

or

2b SELECT resource = from users where primary_key =3D 'acct:user@host'

In a = traditional data lookup you might expect to see an email come back, in = the result set, as that's the foreign key from which the whole dance = starts :)
 


Paul

 

------=_NextPart_000_0710_01CDBA81.EA51CF70-- From wmills@yahoo-inc.com Sun Nov 4 08:47: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 6F93A21F875C for ; Sun, 4 Nov 2012 08:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.493 X-Spam-Level: X-Spam-Status: No, score=-16.493 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 7ZGVvQtmz480 for ; Sun, 4 Nov 2012 08:47:32 -0800 (PST) Received: from nm4-vm0.bullet.mail.sp2.yahoo.com (nm4-vm0.bullet.mail.sp2.yahoo.com [98.139.91.190]) by ietfa.amsl.com (Postfix) with ESMTP id 580CB21F86DD for ; Sun, 4 Nov 2012 08:47:32 -0800 (PST) Received: from [98.139.91.64] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 04 Nov 2012 16:47:29 -0000 Received: from [98.139.91.37] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 04 Nov 2012 16:47:29 -0000 Received: from [127.0.0.1] by omp1037.mail.sp2.yahoo.com with NNFMP; 04 Nov 2012 16:47:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 584627.18960.bm@omp1037.mail.sp2.yahoo.com Received: (qmail 62839 invoked by uid 60001); 4 Nov 2012 16:47:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1352047649; bh=duowUpI7N6GfLpGcvjIcD2iFuLBSed5KhsnpxzRNfn4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Rqb4Cv4MKbbMtXPoy2qfAr3ai27FgTI5krwRFxFgYy1lADHdI2HII0KzzP+NGMEJDZM9irWdz5p9VQaYE0h4ELX48PIv/2rkqz9LS0tAMBYQOxAJEBiq3QJxMi61fgSuTQPOdtK510N8egoT7WZFDEasS1FbvhXmGAN55tnwgSI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=LQXFURVj6C/jFXmflDdbOBgUGiqfHODxXSSIiGOw4xZ0QR5lCVA3IBxxObTivnnBT3QVJxfYk79EBKu5pBNx1Y2eQEIqMj07rEXIoX3G/syhyFJyDo/QDG9h9eZdBiMcy9N8mVM6t5Hr1tIxT6+KGCeyZ9prot86dnfkfRr9/dQ=; X-YMail-OSG: xSjEUwwVM1kZxR4bamSIu1y07J9NvQ20Kk21mAeZxdQPq4H x3jQnNSNCwYTBofqHTFWUlM41huYHC2IwhaYBABMadw0m83frUMkA2Quz67m g0OSnmy1P8soLMPM40tlyTr0OwNqDMW2TDD_zq3zY9DR4KwgZIhW_..xOoDi lb85pc52CG39tdSHjmTBoAjxUGkxPymB1HV4yb8bQvX1P2q7NOCYq8RyYHVT _9psaEklf_qf43B21NxnQ7h8_6LvNcqsORN8yVcgPFAmDfwR7H5p9f4gkJun L26lm8BrrbneHLV0G.eF4_ma9gq.3mEhY88VQvziaf.KwOEWkA4dJGrMfPm. O21.5DhPm3Lfd5N1tPb6u6JV1JYFxCl7qNZdNaMbBOsZdTGS.caMNfxTDvlB Py7Hohpn1wsnBGgx0bmSV0pnt_KKRpgeXdFubhkBo1kSfRncZ7xBUbJpFIE9 dPX_9N1OgacLpnrljRs7DfLpswaIjkAFQ5I.Zr5wdin4LjK.LnZNAQWIse20 hteefGoKTfVtrFc2yGz85oBvJOjRgfTwCN7ek98bqCpwlquuDFiDt9n13lNw 0KlqYzv9EL9b7QrGTKtYVjaIBoCrg.k3PaVqZcZi3qQ9gN8G9 Received: from [99.31.212.42] by web31813.mail.mud.yahoo.com via HTTP; Sun, 04 Nov 2012 08:47:28 PST X-Rocket-MIMEInfo: 001.001, SXQgbWlnaHQgaGF2ZSB0ZW1wbGF0ZXMsIG9yIGl0IG1pZ2h0IGhhdmUgc3RyYWlnaHQgbGluayByZWxhdGlvbnMuwqAgQW4gZXhhbXBsZSBvZiBzb21ldGhpZ24gZ2VuZXJhbGx5IGludGVyZXN0aW5nIHRvIGtub3cgYWJvdXQgYSBzaXRlIG1pZ2h0IGJlIHRoZSBzZWN1cml0eSBjb250YWN0IGFkZHJlc3MsIG9yIGN1c290bWVyIGNhcmUsIGV0Yy7CoCAKCkhvdyBkbyBJIHF1ZXJ5IGZvciBnZW5lcmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzaXRlIGl0c2VsZj_CoCBEbyB3ZSB0aGVuIGhhdmUgdG8gZGVmaW4BMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.123.460 References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <1352004496.14504.YahooMailNeo@web31813.mail.mud.yahoo.com> <06cf01cdbaa6$05ad8dd0$1108a970$@packetizer.com> Message-ID: <1352047648.61656.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Sun, 4 Nov 2012 08:47:28 -0800 (PST) From: William Mills To: "Paul E. Jones" , "apps-discuss@ietf.org" , "webfinger@googlegroups.com" In-Reply-To: <06cf01cdbaa6$05ad8dd0$1108a970$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-539431346-1352047648=:61656" Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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: Sun, 04 Nov 2012 16:47:33 -0000 --767760015-539431346-1352047648=:61656 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It might have templates, or it might have straight link relations.=C2=A0 An= example of somethign generally interesting to know about a site might be t= he security contact address, or cusotmer care, etc.=C2=A0 =0A=0AHow do I qu= ery for general information about the site itself?=C2=A0 Do we then have to= define a new relation for this?=C2=A0 If so then this draft should do that= .=0A=0A=0A=0A=0A=0A>________________________________=0A> From: Paul E. Jone= s =0A>To: 'William Mills' ; ap= ps-discuss@ietf.org; webfinger@googlegroups.com =0A>Sent: Sunday, November = 4, 2012 8:04 AM=0A>Subject: RE: [apps-discuss] The /.well-known/webfinger r= esource=0A> =0A>=0A>William,=0A>=C2=A0=0A>The purpose of the =E2=80=9Cresou= rce=E2=80=9D parameter is to allow the client to ask the server what it wan= ts to know about.=C2=A0 If the client wants to know about acct:paulej@packe= tizer.com, for example, it uses that as the value of the resource parameter= .=0A>=C2=A0=0A>RFC 6415 has the notion of issuing a request to the host-met= a resource without parameters.=C2=A0 The response is an XRD document that c= ontains host-meta information and =E2=80=9Ctemplate=E2=80=9D types that all= ow the client then then further query for resource-specific information, re= placing the =E2=80=9C{uri}=E2=80=9D part in the template URI with that of t= he URI for which the client is seeking information.=0A>=C2=A0=0A>Paul=0A>= =C2=A0=0A>=C2=A0=0A>From:William Mills [mailto:wmills@yahoo-inc.com] =0A>Se= nt: Sunday, November 04, 2012 12:48 AM=0A>To: Paul E. Jones; apps-discuss@i= etf.org; webfinger@googlegroups.com=0A>Subject: Re: [apps-discuss] The /.we= ll-known/webfinger resource=0A>=C2=A0=0A>I'm gonna ask something I should p= robably know, why is the resource parameter required?=C2=A0 Is there no use= case for generic discovery here in the current SF style?=C2=A0 I find this= surprising.=0A>=C2=A0=0A>=C2=A0=0A>>=0A>>________________________________= =0A>>=0A>>From:Paul E. Jones =0A>>To: apps-discuss@i= etf.org; webfinger@googlegroups.com =0A>>Sent: Saturday, November 3, 2012 5= :32 PM=0A>>Subject: [apps-discuss] The /.well-known/webfinger resource=0A>>= =0A>>Folks,=0A>>=0A>>So far, reaction has been positive in favor of option = (2).=C2=A0 As noted, this=0A>>would mean that WebFinger is, more-or-less, t= he equivalent of the LRDD=0A>>resource as defined in RFC 6415, except that = the default representation will=0A>>be application/json rather than applica= tion/xrd+xml.=0A>>=0A>>Before we start working on the new text, I do want t= o understand if folks=0A>>agree to the following usage & results.=0A>>=0A>>= =0A>>$ curl -v 'https://packetizer.com/.well-known/webfinger'=0A>>-- return= s 404, as there is no specified resource=0A>>-- Should there be a different= response code? If so, what?=0A>>=0A>>=0A>>$ curl -v 'https://packetizer.co= m/.well-known/webfinger?=0A>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 resource=3D= acct:paulej@packetizer.com'=0A>>-- returns a JRD for the specified resource= =0A>>-- Example:=0A>>{=0A>>=C2=A0 "subject" : "acct:paulej@packetizer.com",= =0A>>=C2=A0 "links" :=0A>>=C2=A0 [=0A>>=C2=A0 =C2=A0 {=0A>>=C2=A0 =C2=A0 = =C2=A0 "rel" : "http://webfinger.net/rel/avatar",=0A>>=C2=A0 =C2=A0 =C2=A0 = "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg"=0A>>= =C2=A0 =C2=A0 },=0A>>=C2=A0 =C2=A0 {=0A>>=C2=A0 =C2=A0 =C2=A0 "rel" : "http= ://schemas.google.com/g/2010#updates-from",=0A>>=C2=A0 =C2=A0 =C2=A0 "href"= : "http://www.packetizer.com/people/paulej/blog/blog.xml"=0A>>=C2=A0 =C2= =A0 },=0A>>=C2=A0 =C2=A0 {=0A>>=C2=A0 =C2=A0 =C2=A0 "rel" : "vcard",=0A>>= =C2=A0 =C2=A0 =C2=A0 "href" : "http://www.packetizer.com/people/paulej/paul= ej.vcf"=0A>>=C2=A0 =C2=A0 }=0A>>=C2=A0 ]=0A>>}=0A>>=0A>>=0A>>$ curl -v 'htt= ps://packetizer.com/.well-known/webfinger?=0A>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 resource=3Dacct:paulej@packetizer.com&=0A>>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 rel=3Dvcard'=0A>>-- returns a JRD for the specified resource, fi= ltered to include only=0A>>=C2=A0 the space-separated list of link relation= s in the "rel" parameter=0A>>-- Example:=0A>>{=0A>>=C2=A0 "subject" : "acct= :paulej@packetizer.com",=0A>>=C2=A0 "links" :=0A>>=C2=A0 [=0A>>=C2=A0 =C2= =A0 {=0A>>=C2=A0 =C2=A0 =C2=A0 "rel" : "vcard",=0A>>=C2=A0 =C2=A0 =C2=A0 "h= ref" : "http://www.packetizer.com/people/paulej/paulej.vcf"=0A>>=C2=A0 =C2= =A0 }=0A>>=C2=A0 ]=0A>>}=0A>>=0A>>In all cases, the "resource" parameter mi= ght be any URI for which that=0A>>WebFinger server might be able to provide= an answer.=C2=A0 It might be an "acct:"=0A>>URI, "mailto:" URI, "http:" UR= I, etc.=C2=A0 I think that was generally agreed=0A>>before, though we had t= he dialog about how to deal with the "tel:" URI and=0A>>other such URIs tha= t do not have domain names associated with them.=0A>>=0A>>Paul=0A>>=0A>>=0A= >>_______________________________________________=0A>>apps-discuss mailing = list=0A>>apps-discuss@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/ap= ps-discuss=0A>>=0A>>=0A>=0A> --767760015-539431346-1352047648=:61656 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It might = have templates, or it might have straight link relations.  An example = of somethign generally interesting to know about a site might be the securi= ty contact address, or cusotmer care, etc. 

How do I query for= general information about the site itself?  Do we then have to define= a new relation for this?  If so then this draft should do that.


From:= Paul E. Jones <paulej@packetizer.com>
To: 'William Mills' <wmills@yahoo-inc.com>; ap= ps-discuss@ietf.org; webfinger@googlegroups.com
Sent: Sunday, November 4, 2012 8:04 AM
Subject: RE: [apps-discuss] The= /.well-known/webfinger resource

William,
 
The purpose of the =E2=80=9Cresource=E2=80=9D parameter is t= o allow the client to ask the server what it wants to know about.  If = the client wants to know about acct:paulej@packetizer.com, for example, it = uses that as the value of the resource parameter.
 
<= div class=3D"yiv1176452204MsoNormal">RFC 6415 has= the notion of issuing a request to the host-meta resource without paramete= rs.  The response is an XRD document that contains host-meta informati= on and =E2=80=9Ctemplate=E2=80=9D types that allow the client then then fur= ther query for resource-specific information, replacing the =E2=80=9C{uri}= =E2=80=9D part in the template URI with that of the URI for which the clien= t is seeking information.
 
Paul
 
 
= From: William Mills [mailto:wmills@yahoo-inc.com] =
Sent: Sunday, November 04, 2012 12:48 AM
To: Paul E. J= ones; apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: = Re: [apps-discuss] The /.well-known/webfinger resource
 
I'm = gonna ask something I should probably know, why is the resource parameter r= equired?  Is there no use case for generic discovery here in the curre= nt SF style?  I find this surprising.
 
 
<= /div>
<= span style=3D"font-size:10.0pt;font-family:"Arial", "sans-se= rif";color:black;">From: Paul E. J= ones <paulej@packetizer.com>
To: apps-discuss@= ietf.org; webfinger= @googlegroups.com
Sent: Saturday, November 3, 2012 5:32 PMSubject: [apps-discuss] The /.well-known/webfinger resource

Folks,

= So far, reaction has been positive in favor of option (2).  As noted, = this
would mean that WebFinger is, more-or-less, the equivalent of the L= RDD
resource as defined in RFC 6415, except that the default representat= ion will
be application/json rather than application/xrd+xml.

Bef= ore we start working on the new text, I do want to understand if folks
a= gree to the following usage & results.


$ curl -v 'https://packetizer.com/.well-known/webfinger'
-- returns 4= 04, as there is no specified resource
-- Should there be a different res= ponse code? If so, what?


$ curl -v 'https://packetizer.c= om/.well-known/webfinger?
          resourc= e=3Dacct:paulej@packetizer.com'
-- returns a JRD for the specified resource
-- Example:
{
&n= bsp; "subject" : "acct:paulej@pac= ketizer.com",
  "links" :
  [
    {
&nb= sp;     "rel" : "http://webfinger.net/rel/avatar",
&nb= sp;     "href" : "http://www.packet= izer.com/people/paulej/images/paulej.jpg"
    },
 =   {
      "rel" : "http://schemas.google.com/g/2010#= updates-from",
      "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml"
  &n= bsp; },
    {
      "rel" : "vcard",
&nbs= p;     "href" : "http://www.packetizer.com= /people/paulej/paulej.vcf"
    }
  ]
}

<= br>$ curl -v 'https://packetizer.com/.well-known/webfinger= ?
          resource=3Dacct:paulej@packetizer.com&
&n= bsp;         rel=3Dvcard'
-- returns a JRD for the s= pecified resource, filtered to include only
  the space-separated l= ist of link relations in the "rel" parameter
-- Example:
{
  = "subject" : "acct:paulej@packetiz= er.com",
  "links" :
  [
    {
  &= nbsp;   "rel" : "vcard",
      "href" : "http://www.packetizer.com/people/paulej/paulej.vcf"
&nbs= p;   }
  ]
}

In all cases, the "resource" parameter = might be any URI for which that
WebFinger server might be able to provid= e an answer.  It might be an "acct:"
URI, "mailto:" URI, "http:" UR= I, etc.  I think that was generally agreed
before, though we had the = dialog about how to deal with the "tel:" URI and
other such URIs that do= not have domain names associated with them.

Paul


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


--767760015-539431346-1352047648=:61656-- From paulej@packetizer.com Sun Nov 4 08:57: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 46A5221F875C for ; Sun, 4 Nov 2012 08:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 nVOo5POlZM2k for ; Sun, 4 Nov 2012 08:57:15 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 63A2221F84D3 for ; Sun, 4 Nov 2012 08:57:15 -0800 (PST) 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 qA4GvDkj022489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 4 Nov 2012 11:57:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1352048234; bh=BpH2y0CQjD5q2M30EwrsOyXACXoMi8tMrj1OWZlHTys=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=d82Y/QsohQKJTRvoS51yylGabrwfeVABvs2rz3y0j/nC3J0QJtfdeEh8bv2JBFaDE J2oG2s0iSqcaQUVCS3+9krbPdCrSYU04ltmDzGiNcZSSI/fGi3KeRvYyTIaofkHEd3 G8/rzbPAvxezXb/odRea3VKOXvCYZjHLK1DsWbKI= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" , References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> In-Reply-To: Date: Sun, 4 Nov 2012 11:57:26 -0500 Message-ID: <072201cdbaad$78513970$68f3ac50$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0723_01CDBA83.8F7D7B60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHG5aGrJlMX7sxuIe9fbUyX8E9W5wDmbyD/l+BZhJA= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 04 Nov 2012 16:57:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0723_01CDBA83.8F7D7B60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Brad, =20 Comments below: =20 =20 $ curl -v 'https://packetizer.com/.well-known/webfinger' -- returns 404, as there is no specified resource -- Should there be a different response code? If so, what? =20 I'm not sure there's a need to specify the exact error code here. I = think I'd probably return a 400 Bad Request with text "Missing = 'resource' query parameter" but if others returned a 404 or even a 500, = I wouldn't be offended. Just document that it must contain a resource = parameter. Not worth specifying rare parts that people will ignore = anyway. =20 PEJ: OK. We can settle on something later. 400 might be a good = response, since the missing resource parameter would be a bad request. =20 =20 $ curl -v 'https://packetizer.com/.well-known/webfinger? resource=3Dacct:paulej@packetizer.com = & rel=3Dvcard' -- returns a JRD for the specified resource, filtered to include only the space-separated list of link relations in the "rel" parameter =20 Why space-separated? I can live with that, but it seems like the more = natural thing to do would be to use multiple rel parameters: =20 webfinger?resource=3Dbob&rel=3Dvcard&rel=3Dblog&rel=3Dopenid.server =20 PEJ: The reason for space-separating was to be consistent with HTML. = That=E2=80=99s exactly how you=E2=80=99ll find multiple link relation = values appearing in an HTML document. An issue with using the same = parameter multiple times in the URL is that I suspect many (or most) = protocol libraries would either take the first one or the last one it = sees and discard the others. =20 Also, I don't recall, but I assume it's only a SHOULD that the server = filter the returned list for the requested rels? =20 If a server instead only looked at the "resource" parameter and always = returned all link relations on every request, I think that'd be nice to = still be a compliant server. That might also satisfy the = increasingly-small-but-still-existent camp who want webfinger to work = with "static" webservers: a URI rewrite rule like mod_rewrite can regexp = out the "resource=3D([^&]+?) from the query and map it to a file on = disk. =20 PEJ: Oh, definitely think it should be either SHOULD or MAY. That does = make it optional, but it=E2=80=99s one of those things that only has = benefit when the returned document is enormous or when a client is = seeking very specific piece of information.=20 =20 In all cases, the "resource" parameter might be any URI for which that WebFinger server might be able to provide an answer. It might be an = "acct:" URI, "mailto:" URI, "http:" URI, etc. I think that was generally agreed before, though we had the dialog about how to deal with the "tel:" URI = and other such URIs that do not have domain names associated with them. =20 Don't disallow tel: for sure. (I can certainly think of a phone number = of mine I'd love to see work with webfinger...) But don't go out of = your way specifying how to it should or shouldn't work. =20 PEJ: WebFinger would accept any URI, but not every WF server would know = what to do with every URI. The =E2=80=9Cright=E2=80=9D thing to do with = a =E2=80=9Ctel=E2=80=9D URI is query DNS and convert that into an = =E2=80=9Cacct:=E2=80=9D URI or something else. That said, if one wants = to have a client that has a =E2=80=9Cdefault domain=E2=80=9D against = which it makes queries using =E2=80=9Ctel=E2=80=9D URIs, that should be = legal. =20 Paul =20 ------=_NextPart_000_0723_01CDBA83.8F7D7B60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Brad,

 

Comments below:

 

 

$ curl -v = 'https://packetizer.com/.well-known/webfinger'
--= returns 404, as there is no specified resource
-- Should there be a = different response code? If so, = what?

 

I'm not sure = there's a need to specify the exact error code here.  I think I'd = probably return a 400 Bad Request with text "Missing 'resource' = query parameter" but if others returned a 404 or even a 500, I = wouldn't be offended.  Just document that it must contain a = resource parameter.  Not worth specifying rare parts that people = will ignore anyway.

 

PEJ: OK.=C2=A0 We can settle on something later.=C2=A0 400 might be = a good response, since the missing resource parameter would be a bad = request.

 

 

$ curl -v = 'https://packetizer.com/.well-known/webfinger?
&n= bsp;          resource=3Dacct:paulej@packetizer.com&
           rel=3Dvcard'
-- = returns a JRD for the specified resource, filtered to include = only
   the space-separated list of link relations in the = "rel" parameter

In all = cases, the "resource" parameter might be any URI for which = that
WebFinger server might be able to provide an answer.  It = might be an "acct:"
URI, "mailto:" URI, = "http:" URI, etc.  I think that was generally = agreed
before, though we had the dialog about how to deal with the = "tel:" URI and
other such URIs that do not have domain = names associated with them.

------=_NextPart_000_0723_01CDBA83.8F7D7B60-- From paulej@packetizer.com Sun Nov 4 09:18: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 28E4421F878E for ; Sun, 4 Nov 2012 09:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_20=-0.74, J_CHICKENPOX_35=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 kRAoAmOVT55e for ; Sun, 4 Nov 2012 09:18:00 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7425F21F8712 for ; Sun, 4 Nov 2012 09:18:00 -0800 (PST) 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 qA4HHv0k023363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 4 Nov 2012 12:17:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1352049477; bh=dRIbJHCe06PvU1GIDFBjBFGT87HgbbO50gy/Kb6SLzY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=NnD0mzGr8GOyM3o0Z5k1rJOGs7+j4lC8sLQvoUXS30RevzdgPUs6fN6aKdvJj5EzP M+Bw6rdUL1QvciURyqPnAwPr8nR6A3BoGPZPjE3SMqKXIQS6P42Ojkr0yZt2CxKoeu F/sNGeQ+Y6/R5E/r+sBuqM2a6o8ofEg6WBn9dvx4= From: "Paul E. Jones" To: "'Christian Weiske'" , References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <20121104104228.5a49c685@bogo> In-Reply-To: <20121104104228.5a49c685@bogo> Date: Sun, 4 Nov 2012 12:18:10 -0500 Message-ID: <074701cdbab0$5d9f3de0$18ddb9a0$@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: AQHG5aGrJlMX7sxuIe9fbUyX8E9W5wDmbyD/ASr8nL2X1wiKsA== Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 04 Nov 2012 17:18:01 -0000 Christian, > > > Before we start working on the new text, I do want to understand = if > > > folks agree to the following usage & results. > > > $ curl -v 'https://packetizer.com/.well-known/webfinger' > > > -- returns 404, as there is no specified resource > > > -- Should there be a different response code? If so, what? > > I'm not sure there's a need to specify the exact error code here. I > > think I'd probably return a 400 Bad Request with text "Missing > > 'resource' query parameter" >=20 > That'd be the correct solution. The resource parameter is required, = and > failing to provide it is a user error. >=20 > In contrast to a 404, it says "we support webfinger, but you didn't = give > us all we need to answer the request". A 404 says "we don't support > webfinger". Agreed. I think 400 is best for when the param is missing, 404 if the = thing queries is unknown. =20 > > > $ curl -v 'https://packetizer.com/.well-known/webfinger? > > > resource=3Dacct:paulej@packetizer.com' > > > -- returns a JRD for the specified resource > Yep. >=20 > > > $ curl -v 'https://packetizer.com/.well-known/webfinger? > > > resource=3Dacct:paulej@packetizer.com& > > > rel=3Dvcard' > > > -- returns a JRD for the specified resource, filtered to include > > > only the space-separated list of link relations in the "rel" > > > parameter > > Why space-separated? I can live with that, but it seems like the = more > > natural thing to do would be to use multiple rel parameters: >=20 > Space separation would introduce problems with rel URLs that have = spaces > in them. You'd need to take care of double encoding the rel URL, while > single-encoding the " " that separate the rels. In addition to HTML following this convention, it is specified this way = in the Web Linking document (RFC 5988), too. I think it is best that we = follow the same format as existing specs. Link relation types are = always space-separated. I'd suggest we just define link relation types = such that they do not have spaces. =20 > > webfinger?resource=3Dbob&rel=3Dvcard&rel=3Dblog&rel=3Dopenid.server > Because of the double-encoding issue, I support the multiple rel > parameter approach. I know this will not work in some libraries, though. What some = libraries do is create a map of tag/value pairs. If "rel" is seen a = second time, it is either ignored or the old value is replaced. I honestly cannot recall ever having seen a web API that used the same = URI parameter more than once. We should be careful about this one. On the other hand, a space-separated list is easy to manage. Paul From paulej@packetizer.com Sun Nov 4 09:26: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 8F85221F8712 for ; Sun, 4 Nov 2012 09:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 7ZlhIBBbIGSW for ; Sun, 4 Nov 2012 09:26:56 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE6B21F8724 for ; Sun, 4 Nov 2012 09:26:52 -0800 (PST) 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 qA4HQoD9023823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 4 Nov 2012 12:26:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1352050011; bh=R05cd4amwEGc+Vd5PmKA3k8AJ6/Amm2+8/jGzaT6RuA=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=OaRhpJwnJQ6xzoNljFs43vv+MYQucJOEvgTXtsJVpsJTCqQd2Muh6Xso6k84PMMKI 8zbvTs0IXo5BWKEbTOndW+YUdVThcMuxR3ot51l5UNUu9H7MRrvdFeN4tJfQeY3JXU 16iMoluKy3K0tpe0fWfVAaJV/LPJB/MM5G9Ob6a4= From: "Paul E. Jones" To: "'William Mills'" , , References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <1352004496.14504.YahooMailNeo@web31813.mail.mud.yahoo.com> <06cf01cdbaa6$05ad8dd0$1108a970$@packetizer.com> <1352047648.61656.YahooMailNeo@web31813.mail.mud.yahoo.com> In-Reply-To: <1352047648.61656.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Sun, 4 Nov 2012 12:27:03 -0500 Message-ID: <074901cdbab1$9b991110$d2cb3330$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_074A_01CDBA87.B2C57A10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHG5aGrJlMX7sxuIe9fbUyX8E9W5wGAMjwxAhI1/H8BEFNDTJfCf/mg Content-Language: en-us Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 04 Nov 2012 17:26:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_074A_01CDBA87.B2C57A10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable William, =20 That was a question I asked in one of my email messages. So, I = understand the question, but don=E2=80=99t have an answer. =20 I think the answer might be =E2=80=9Cuse host-meta=E2=80=9D. Another = answer might be that we define a URI that is for that purpose. For = example, =E2=80=9Cacct:support@example.com=E2=80=9D or = =E2=80=9Cacct:webmaster@example.com=E2=80=9D. =20 The risk of suggesting that we have a response about the site if no URI = parameter is there is that we have a solution for that in the -02 draft = :-) But, there was push back in hacking up the host-meta resource to = provide both resource-specific information and resource information. If = we use the new webfinger resource to serve both, we=E2=80=99re in the = same boat. =20 Perhaps the answer is that you query webfinger if looking for = resource-specific info and host-meta if looking for host information? =20 These all work: $ curl 'https://packetizer.com/.well-known/host-meta' -- returns host-meta information (and templates if one wants to follow = RFC 6415 procedures) $ curl 'https://packetizer.com/.well-known/webfinger? resource=3Dacct:paulej@packetizer.com' -- returns resource-specific information =20 The host-meta file can be a text file that can definitely be static. =20 Paul =20 From: William Mills [mailto:wmills@yahoo-inc.com]=20 Sent: Sunday, November 04, 2012 11:47 AM To: Paul E. Jones; apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Re: [apps-discuss] The /.well-known/webfinger resource =20 It might have templates, or it might have straight link relations. An = example of somethign generally interesting to know about a site might be = the security contact address, or cusotmer care, etc. =20 How do I query for general information about the site itself? Do we = then have to define a new relation for this? If so then this draft = should do that. =20 =20 _____ =20 From: Paul E. Jones To: 'William Mills' ; apps-discuss@ietf.org; = webfinger@googlegroups.com=20 Sent: Sunday, November 4, 2012 8:04 AM Subject: RE: [apps-discuss] The /.well-known/webfinger resource =20 William, =20 The purpose of the =E2=80=9Cresource=E2=80=9D parameter is to allow the = client to ask the server what it wants to know about. If the client = wants to know about acct:paulej@packetizer.com, for example, it uses = that as the value of the resource parameter. =20 RFC 6415 has the notion of issuing a request to the host-meta resource = without parameters. The response is an XRD document that contains = host-meta information and =E2=80=9Ctemplate=E2=80=9D types that allow = the client then then further query for resource-specific information, = replacing the =E2=80=9C{uri}=E2=80=9D part in the template URI with that = of the URI for which the client is seeking information. =20 Paul =20 =20 From: William Mills [mailto:wmills@yahoo-inc.com]=20 Sent: Sunday, November 04, 2012 12:48 AM To: Paul E. Jones; apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Re: [apps-discuss] The /.well-known/webfinger resource =20 I'm gonna ask something I should probably know, why is the resource = parameter required? Is there no use case for generic discovery here in = the current SF style? I find this surprising. =20 =20 _____ =20 From: Paul E. Jones To: apps-discuss@ietf.org; webfinger@googlegroups.com=20 Sent: Saturday, November 3, 2012 5:32 PM Subject: [apps-discuss] The /.well-known/webfinger resource Folks, So far, reaction has been positive in favor of option (2). As noted, = this would mean that WebFinger is, more-or-less, the equivalent of the LRDD resource as defined in RFC 6415, except that the default representation = will be application/json rather than application/xrd+xml. Before we start working on the new text, I do want to understand if = folks agree to the following usage & results. $ curl -v 'https://packetizer.com/.well-known/webfinger' = =20 -- returns 404, as there is no specified resource -- Should there be a different response code? If so, what? $ curl -v 'https://packetizer.com/.well-known/webfinger? resource=3Dacct:paulej@packetizer.com' -- returns a JRD for the specified resource -- Example: { "subject" : "acct:paulej@packetizer.com", "links" : [ { "rel" : "http://webfinger.net/rel/avatar", "href" : = "http://www.packetizer.com/people/paulej/images/paulej.jpg" }, { "rel" : "http://schemas.google.com/g/2010#updates-from", "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml" }, { "rel" : "vcard", "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" } ] } $ curl -v 'https://packetizer.com/.well-known/webfinger? resource=3Dacct:paulej@packetizer.com& rel=3Dvcard' -- returns a JRD for the specified resource, filtered to include only the space-separated list of link relations in the "rel" parameter -- Example: { "subject" : "acct:paulej@packetizer.com", "links" : [ { "rel" : "vcard", "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" } ] } In all cases, the "resource" parameter might be any URI for which that WebFinger server might be able to provide an answer. It might be an = "acct:" URI, "mailto:" URI, "http:" URI, etc. I think that was generally agreed before, though we had the dialog about how to deal with the "tel:" URI = and other such URIs that do not have domain names associated with them. Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss =20 ------=_NextPart_000_074A_01CDBA87.B2C57A10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

William,

 

That was a question I asked in one of my email messages.=C2=A0 So, I = understand the question, but don=E2=80=99t have an = answer.

 

I think the answer might be =E2=80=9Cuse host-meta=E2=80=9D.=C2=A0 = Another answer might be that we define a URI that is for that purpose. = For example, =E2=80=9Cacct:support@example.com=E2=80=9D or = =E2=80=9Cacct:webmaster@example.com=E2=80=9D.

 

The risk of suggesting that we have a response about the site if no = URI parameter is there is that we have a solution for that in the -02 = draft :-)=C2=A0 But, there was push back in hacking up the host-meta = resource to provide both resource-specific information and resource = information.=C2=A0 If we use the new webfinger resource to serve both, = we=E2=80=99re in the same boat.

 

Perhaps the answer is that you query webfinger if looking for = resource-specific info and host-meta if looking for host = information?

 

These all work:

$ = curl = 'https://packetizer.com/.well-known/host-meta'

-- returns host-meta information (and templates if = one wants to follow RFC 6415 procedures)

$ curl = 'https://packetizer.com/.well-known/webfinger?

=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0resource=3Dacct:paulej@packetizer.com= '

-- = returns resource-specific information

 

The host-meta file can be a text file that can definitely be = static.

 

Paul

 

From:= = William Mills [mailto:wmills@yahoo-inc.com]
Sent: Sunday, = November 04, 2012 11:47 AM
To: Paul E. Jones; = apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: = [apps-discuss] The /.well-known/webfinger = resource

 

It = might have templates, or it might have straight link relations.  An = example of somethign generally interesting to know about a site might be = the security contact address, or cusotmer care, etc. 

How = do I query for general information about the site itself?  Do we = then have to define a new relation for this?  If so then this draft = should do that.

 

 

 

William,

 

The purpose of the =E2=80=9Cresource=E2=80=9D parameter is to allow = the client to ask the server what it wants to know about.  If the = client wants to know about acct:paulej@packetizer.com, for example, it = uses that as the value of the resource parameter.

 

RFC 6415 has the notion of issuing a request to the host-meta = resource without parameters.  The response is an XRD document that = contains host-meta information and =E2=80=9Ctemplate=E2=80=9D types that = allow the client then then further query for resource-specific = information, replacing the =E2=80=9C{uri}=E2=80=9D part in the template = URI with that of the URI for which the client is seeking = information.

 

Paul

 

 

= From:= William Mills [mailto:wmills@yahoo-inc.com] =
Sent: Sunday, November 04, 2012 12:48 AM
To: Paul = E. Jones; apps-discuss@ietf.org; webfinger@googlegroups.com=
Subject: Re: [apps-discuss] The /.well-known/webfinger = resource

 

I'm = gonna ask something I should probably know, why is the resource = parameter required?  Is there no use case for generic discovery = here in the current SF style?  I find this surprising.

 

 

<= hr size=3D1 width=3D"100%" align=3Dcenter>

F= rom: = Paul E. Jones <paulej@packetizer.com>
To: apps-discuss@ietf.org; webfinger@googlegroups.com
Sent: = Saturday, November 3, 2012 5:32 PM
Subject: [apps-discuss] The = /.well-known/webfinger resource


Folks,

So far, reaction has been = positive in favor of option (2).  As noted, this
would mean that = WebFinger is, more-or-less, the equivalent of the LRDD
resource as = defined in RFC 6415, except that the default representation will
be = application/json rather than application/xrd+xml.

Before we start = working on the new text, I do want to understand if folks
agree to = the following usage & results.


$ curl -v 'https://packetizer.com/.well-known/webfinger'
--= returns 404, as there is no specified resource
-- Should there be a = different response code? If so, what?


$ curl -v 'https://packetizer.com/.well-known/webfinger?
&n= bsp;         resource=3Dacct:paulej@packetizer.com'
-- returns a JRD for the = specified resource
-- Example:
{
  "subject" : = "acct:paulej@packetizer.com",
  = "links" :
  [
    {
    =   "rel" : "http://webfinger.net/rel/avatar",
  =     "href" : "http://www.packetizer.com/people/paulej/images/paulej.j= pg"
    },
    {
    =   "rel" : "http://schemas.google.com/g/2010#updates-from"= ,
      "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml"
    },
    {
      = "rel" : "vcard",
      = "href" : "http://www.packetizer.com/people/paulej/paulej.vcf&= quot;
    }
  ]
}


$ curl -v 'https://packetizer.com/.well-known/webfinger?
&n= bsp;         resource=3Dacct:paulej@packetizer.com&
      =     rel=3Dvcard'
-- returns a JRD for the specified = resource, filtered to include only
  the space-separated list of = link relations in the "rel" parameter
-- = Example:
{
  "subject" : "acct:paulej@packetizer.com",
  = "links" :
  [
    {
    =   "rel" : "vcard",
      = "href" : "http://www.packetizer.com/people/paulej/paulej.vcf&= quot;
    }
  ]
}

In all cases, the = "resource" parameter might be any URI for which = that
WebFinger server might be able to provide an answer.  It = might be an "acct:"
URI, "mailto:" URI, = "http:" URI, etc.  I think that was generally = agreed
before, though we had the dialog about how to deal with the = "tel:" URI and
other such URIs that do not have domain = names associated with = them.

Paul


____________________________________________= ___
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 

------=_NextPart_000_074A_01CDBA87.B2C57A10-- From wmills@yahoo-inc.com Sun Nov 4 10:14: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 69F2121F85DA for ; Sun, 4 Nov 2012 10:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.565 X-Spam-Level: X-Spam-Status: No, score=-16.565 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 14IqOzgmx6o5 for ; Sun, 4 Nov 2012 10:14:46 -0800 (PST) Received: from nm29-vm0.bullet.mail.sp2.yahoo.com (nm29-vm0.bullet.mail.sp2.yahoo.com [98.139.91.236]) by ietfa.amsl.com (Postfix) with ESMTP id B679421F8476 for ; Sun, 4 Nov 2012 10:14:44 -0800 (PST) Received: from [72.30.22.93] by nm29.bullet.mail.sp2.yahoo.com with NNFMP; 04 Nov 2012 18:14:32 -0000 Received: from [98.139.91.32] by tm15.bullet.mail.sp2.yahoo.com with NNFMP; 04 Nov 2012 18:14:32 -0000 Received: from [127.0.0.1] by omp1032.mail.sp2.yahoo.com with NNFMP; 04 Nov 2012 18:14:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 854068.4953.bm@omp1032.mail.sp2.yahoo.com Received: (qmail 84173 invoked by uid 60001); 4 Nov 2012 18:14:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1352052872; bh=+EzynqkCHk3gJJJEZbFSrII7lgjbEBulyzWo1+UzYGM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=PyM3ZNlhN8eop16BBMHB1KoRDlXMgTTYODHJyTVEOOAEhQAIjyOsGmbSwOLbL1Ws/eMPu0OdNRXSB5xPdeLsDHjbJt0vkbLwTu/slUCvxlHlht4e+loqz4XBo1TntGlJYALiynDNRg2F27Ywl/WkG+NGRlxFZmDkzXTU4ayIcbE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=WZFG1BDy7S/tY1krrBJvecJhu/lWVEJHW5H8Q0GToWtO7jqdwyQeX1ss3Egaxqm/C6xIZOznYf+nSgKd9rWgn5S8haZkreino2eTkokBIGeLJ+KyYBCTvEUganOdjDg7mPHQVudCDkyGzUdbSwKj+fl9lBp2voybzOLokA8eQPQ=; X-YMail-OSG: kVNcvjUVM1mfevtSAbsgGJIK9qCu_1xlHMqo1j40ZGRjYhU ScehDfvy26Ie21eYTjhjOJnA0ovUibzL_irdC7ETWddmUM52nJAY762MgbFE mIstVnZjtZQxZmZnmfiiTHVKEH2EofbCggbadoiuNzh.U6G86bu8HYhVvZuH hifSAwaWUK16UwGSx4gJpqhA_vOWjx0saoOzmTlun6_zkfclDDLJukCxZV2P IdWWZ.nuivscqrXfUMkkn4Uydb4o_fUzXrKRouA5jd50D0QCnbJEeClOikPE rl8vBQyYoQvJWfAabinBT4vyZCEXNObpby4DuEY_589fZh3tBhPkAS54G226 io8apiOu8mTwK6M8z7AYSKLpA2OSQ1O9j0Ykt7t2Te1S4R9Ti5u1IKoz2iyv nIC0s4H2BQ.wZxvkvgQ1H.w.GC5ZgZyz_qTWGwYGlyXnTUMmGEX9usceuEKJ C9LzOtVBqO1UPzrmMYyLjf4UrLkTsKCavVlxRznszhuxrGub4R_T4TorfCeN j4DjfEeCJ0RGx8CuJZZp.1BoBNkA.qENQDvLjRT14wpYEq2Dg_matvv1J7d3 GvNdHFn8oc1KG7pYulPqb1E_KftzT0oxOLUIhKUB2H.gki0KJ Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Sun, 04 Nov 2012 10:14:31 PST X-Rocket-MIMEInfo: 001.001, QUghwqAgT0ssIHRoaXMgaXMgZXhhY3RseSB0aGUgYW5zd2VyLCBob3N0LW1ldGEgaXMgZm9yIGdlbmVyYWxseSBhZHZlcnRpc2VkIGluZm9ybWF0aW9uLCB3ZWJmaW5nZXIgcmVxdWlyZXMgYSByZXNvdXJjZS7CoCBXb3J0aCBhIG1lbnRpb24gaW4gdGhlIHNwZWM_CgoKCgoKPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogUGF1bCBFLiBKb25lcyA8cGF1bGVqQHBhY2tldGl6ZXIuY29tPgo.VG86ICdXaWxsaWFtIE1pbGxzJyA8d21pbGxzQHlhaG9vLWluYy5jb20.OyBhcHBzLWRpc2MBMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.123.460 References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <1352004496.14504.YahooMailNeo@web31813.mail.mud.yahoo.com> <06cf01cdbaa6$05ad8dd0$1108a970$@packetizer.com> <1352047648.61656.YahooMailNeo@web31813.mail.mud.yahoo.com> <074901cdbab1$9b991110$d2cb3330$@packetizer.com> Message-ID: <1352052871.46114.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Sun, 4 Nov 2012 10:14:31 -0800 (PST) From: William Mills To: "Paul E. Jones" , "apps-discuss@ietf.org" , "webfinger@googlegroups.com" In-Reply-To: <074901cdbab1$9b991110$d2cb3330$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-1173786015-1352052871=:46114" Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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: Sun, 04 Nov 2012 18:14:47 -0000 --764183289-1173786015-1352052871=:46114 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable AH!=C2=A0 OK, this is exactly the answer, host-meta is for generally advert= ised information, webfinger requires a resource.=C2=A0 Worth a mention in t= he spec?=0A=0A=0A=0A=0A=0A>________________________________=0A> From: Paul = E. Jones =0A>To: 'William Mills' ; apps-discuss@ietf.org; webfinger@googlegroups.com =0A>Sent: Sunday, No= vember 4, 2012 9:27 AM=0A>Subject: RE: [apps-discuss] The /.well-known/webf= inger resource=0A> =0A>=0A>William,=0A>=C2=A0=0A>That was a question I aske= d in one of my email messages.=C2=A0 So, I understand the question, but don= =E2=80=99t have an answer.=0A>=C2=A0=0A>I think the answer might be =E2=80= =9Cuse host-meta=E2=80=9D.=C2=A0 Another answer might be that we define a U= RI that is for that purpose. For example, =E2=80=9Cacct:support@example.com= =E2=80=9D or =E2=80=9Cacct:webmaster@example.com=E2=80=9D.=0A>=C2=A0=0A>The= risk of suggesting that we have a response about the site if no URI parame= ter is there is that we have a solution for that in the -02 draft :-)=C2=A0= But, there was push back in hacking up the host-meta resource to provide b= oth resource-specific information and resource information.=C2=A0 If we use= the new webfinger resource to serve both, we=E2=80=99re in the same boat.= =0A>=C2=A0=0A>Perhaps the answer is that you query webfinger if looking for= resource-specific info and host-meta if looking for host information?=0A>= =C2=A0=0A>These all work:=0A>$ curl 'https://packetizer.com/.well-known/hos= t-meta'=0A>-- returns host-meta information (and templates if one wants to = follow RFC 6415 procedures)=0A>$ curl 'https://packetizer.com/.well-known/w= ebfinger?=0A>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0resource=3Dacct:pau= lej@packetizer.com'=0A>-- returns resource-specific information=0A>=C2=A0= =0A>The host-meta file can be a text file that can definitely be static.=0A= >=C2=A0=0A>Paul=0A>=C2=A0=0A>From:William Mills [mailto:wmills@yahoo-inc.co= m] =0A>Sent: Sunday, November 04, 2012 11:47 AM=0A>To: Paul E. Jones; apps-= discuss@ietf.org; webfinger@googlegroups.com=0A>Subject: Re: [apps-discuss]= The /.well-known/webfinger resource=0A>=C2=A0=0A>It might have templates, = or it might have straight link relations.=C2=A0 An example of somethign gen= erally interesting to know about a site might be the security contact addre= ss, or cusotmer care, etc.=C2=A0 =0A>=0A>How do I query for general informa= tion about the site itself?=C2=A0 Do we then have to define a new relation = for this?=C2=A0 If so then this draft should do that.=0A>=C2=A0=0A>=C2=A0= =0A>>=0A>>________________________________=0A>>=0A>>From:Paul E. Jones =0A>>To: 'William Mills' ; apps-di= scuss@ietf.org; webfinger@googlegroups.com =0A>>Sent: Sunday, November 4, 2= 012 8:04 AM=0A>>Subject: RE: [apps-discuss] The /.well-known/webfinger reso= urce=0A>>=C2=A0=0A>>William,=0A>>=C2=A0=0A>>The purpose of the =E2=80=9Cres= ource=E2=80=9D parameter is to allow the client to ask the server what it w= ants to know about.=C2=A0 If the client wants to know about acct:paulej@pac= ketizer.com, for example, it uses that as the value of the resource paramet= er.=0A>>=C2=A0=0A>>RFC 6415 has the notion of issuing a request to the host= -meta resource without parameters.=C2=A0 The response is an XRD document th= at contains host-meta information and =E2=80=9Ctemplate=E2=80=9D types that= allow the client then then further query for resource-specific information= , replacing the =E2=80=9C{uri}=E2=80=9D part in the template URI with that = of the URI for which the client is seeking information.=0A>>=C2=A0=0A>>Paul= =0A>>=C2=A0=0A>>=C2=A0=0A>>From:William Mills [mailto:wmills@yahoo-inc.com]= =0A>>Sent: Sunday, November 04, 2012 12:48 AM=0A>>To: Paul E. Jones; apps-= discuss@ietf.org; webfinger@googlegroups.com=0A>>Subject: Re: [apps-discuss= ] The /.well-known/webfinger resource=0A>>=C2=A0=0A>>I'm gonna ask somethin= g I should probably know, why is the resource parameter required?=C2=A0 Is = there no use case for generic discovery here in the current SF style?=C2=A0= I find this surprising.=0A>>=C2=A0=0A>>=C2=A0=0A>>>=0A>>>_________________= _______________=0A>>>=0A>>>From:Paul E. Jones =0A>>>= To: apps-discuss@ietf.org; webfinger@googlegroups.com =0A>>>Sent: Saturday,= November 3, 2012 5:32 PM=0A>>>Subject: [apps-discuss] The /.well-known/web= finger resource=0A>>>=0A>>>Folks,=0A>>>=0A>>>So far, reaction has been posi= tive in favor of option (2).=C2=A0 As noted, this=0A>>>would mean that WebF= inger is, more-or-less, the equivalent of the LRDD=0A>>>resource as defined= in RFC 6415, except that the default representation will=0A>>>be applicati= on/json rather than application/xrd+xml.=0A>>>=0A>>>Before we start working= on the new text, I do want to understand if folks=0A>>>agree to the follow= ing usage & results.=0A>>>=0A>>>=0A>>>$ curl -v 'https://packetizer.com/.we= ll-known/webfinger'=0A>>>-- returns 404, as there is no specified resource= =0A>>>-- Should there be a different response code? If so, what?=0A>>>=0A>>= >=0A>>>$ curl -v 'https://packetizer.com/.well-known/webfinger?=0A>>>=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 resource=3Dacct:paulej@packetizer.com'=0A>>>--= returns a JRD for the specified resource=0A>>>-- Example:=0A>>>{=0A>>>=C2= =A0 "subject" : "acct:paulej@packetizer.com",=0A>>>=C2=A0 "links" :=0A>>>= =C2=A0 [=0A>>>=C2=A0 =C2=A0 {=0A>>>=C2=A0 =C2=A0 =C2=A0 "rel" : "http://web= finger.net/rel/avatar",=0A>>>=C2=A0 =C2=A0 =C2=A0 "href" : "http://www.pack= etizer.com/people/paulej/images/paulej.jpg"=0A>>>=C2=A0 =C2=A0 },=0A>>>=C2= =A0 =C2=A0 {=0A>>>=C2=A0 =C2=A0 =C2=A0 "rel" : "http://schemas.google.com/g= /2010#updates-from",=0A>>>=C2=A0 =C2=A0 =C2=A0 "href" : "http://www.packeti= zer.com/people/paulej/blog/blog.xml"=0A>>>=C2=A0 =C2=A0 },=0A>>>=C2=A0 =C2= =A0 {=0A>>>=C2=A0 =C2=A0 =C2=A0 "rel" : "vcard",=0A>>>=C2=A0 =C2=A0 =C2=A0 = "href" : "http://www.packetizer.com/people/paulej/paulej.vcf"=0A>>>=C2=A0 = =C2=A0 }=0A>>>=C2=A0 ]=0A>>>}=0A>>>=0A>>>=0A>>>$ curl -v 'https://packetize= r.com/.well-known/webfinger?=0A>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 resour= ce=3Dacct:paulej@packetizer.com&=0A>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 re= l=3Dvcard'=0A>>>-- returns a JRD for the specified resource, filtered to in= clude only=0A>>>=C2=A0 the space-separated list of link relations in the "r= el" parameter=0A>>>-- Example:=0A>>>{=0A>>>=C2=A0 "subject" : "acct:paulej@= packetizer.com",=0A>>>=C2=A0 "links" :=0A>>>=C2=A0 [=0A>>>=C2=A0 =C2=A0 {= =0A>>>=C2=A0 =C2=A0 =C2=A0 "rel" : "vcard",=0A>>>=C2=A0 =C2=A0 =C2=A0 "href= " : "http://www.packetizer.com/people/paulej/paulej.vcf"=0A>>>=C2=A0 =C2=A0= }=0A>>>=C2=A0 ]=0A>>>}=0A>>>=0A>>>In all cases, the "resource" parameter m= ight be any URI for which that=0A>>>WebFinger server might be able to provi= de an answer.=C2=A0 It might be an "acct:"=0A>>>URI, "mailto:" URI, "http:"= URI, etc.=C2=A0 I think that was generally agreed=0A>>>before, though we h= ad the dialog about how to deal with the "tel:" URI and=0A>>>other such URI= s that do not have domain names associated with them.=0A>>>=0A>>>Paul=0A>>>= =0A>>>=0A>>>_______________________________________________=0A>>>apps-discu= ss mailing list=0A>>>apps-discuss@ietf.org=0A>>>https://www.ietf.org/mailma= n/listinfo/apps-discuss=0A>>=C2=A0=0A>=0A> --764183289-1173786015-1352052871=:46114 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
AH! = OK, this is exactly the answer, host-meta is for generally advertised info= rmation, webfinger requires a resource.  Worth a mention in the spec?<= br>


From: Paul E. Jones <paulej@packetizer.com>
To: 'William Mills' <wmills@yah= oo-inc.com>; apps-discuss@ietf.org; webfinger@googlegroups.com
<= span style=3D"font-weight: bold;">Sent: Sunday, November 4, 2012 9:2= 7 AM
Subject: RE: [app= s-discuss] The /.well-known/webfinger resource

= William,
 
That was a question I asked in one of my email mes= sages.  So, I understand the question, but don=E2=80=99t have an answe= r.
 
I think the answer might be =E2=80=9Cuse host-meta=E2=80=9D.  Another answer might be that we def= ine a URI that is for that purpose. For example, =E2=80=9Cacct:support@exam= ple.com=E2=80=9D or =E2=80=9Cacct:webmaster@example.com=E2=80=9D.
&nbs= p;
The risk of suggesting that we have a response about the site if no = URI parameter is there is that we have a solution for that in the -02 draft= :-)  But, there was push back in hacking up the host-meta resource to= provide both resource-specific information and resource information. = If we use the new webfinger resource to serve both, we=E2=80=99re in the s= ame boat.
 
Perhaps the answer is that you query we= bfinger if looking for resource-specific info and host-meta if looking for = host information?
 
These all work:
$ curl 'https://packetizer.com/.well-know= n/host-meta'
-- returns host-meta information (and templates if one wants to follow = RFC 6415 procedures)
$ curl 'https://packetizer.com/.well-known/webfinger?
      &= nbsp; resource=3Dacct:paulej@packetizer.com'
-- returns resource-specific information<= /span>
 
The host-meta file can = be a text file that can definitely be static.
 
Paul
&nb= sp;
From: William Mills [mailto:wmills@yahoo-= inc.com]
Sent: Sunday, November 04, 2012 11:47 AM
To: = Paul E. Jones; apps-discuss@ietf.org; webfinger@googlegroups.com
Subj= ect: Re: [apps-discuss] The /.well-known/webfinger resource
 
It might= have templates, or it might have straight link relations.  An example= of somethign generally interesting to know about a site might be the secur= ity contact address, or cusotmer care, etc. 

How do I query fo= r general information about the site itself?  Do we then have to defin= e a new relation for this?  If so then this draft should do that.<= /div>
 
 
From: Paul E. Jones <paulej@pac= ketizer.com>
To: 'William Mills' <wmills@yahoo-inc.com>; apps-discuss@ietf.org; webfinger@googlegroups.com
Sent: Sunday,= November 4, 2012 8:04 AM
Subject: RE: [apps-discuss] The /.well-= known/webfinger resource
 
<= div>
William,=
 
The purpose of the =E2=80= =9Cresource=E2=80=9D parameter is to allow the client to ask the server wha= t it wants to know about.  If the client wants to know about acct:paul= ej@packetizer.com, for example, it uses that as the value of the resource parameter.
 
RFC 6415 has= the notion of issuing a request to the host-meta resource without paramete= rs.  The response is an XRD document that contains host-meta informati= on and =E2=80=9Ctemplate=E2=80=9D types that allow the client then then fur= ther query for resource-specific information, replacing the =E2=80=9C{uri}= =E2=80=9D part in the template URI with that of the URI for which the clien= t is seeking information.
<= /div>
 
= Paul
 
 
From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Sunday, November 04,= 2012 12:48 AM
To: Paul E. Jones; apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-= discuss] The /.well-known/webfinger resource=
 
<= div>
= I'm gonna ask something I should probably know, why is the resource = parameter required?  Is there no use case for generic discovery here i= n the current SF style?  I find this surprising.
 
&nbs= p;
From:= Paul E. Jones <paulej@packetizer.com>
= To: apps-discuss@ietf.org= ; webfinger@googlegrou= ps.com
Sent: Saturday, November 3, 2012 5:32 PM
Subjec= t: [apps-discuss] The /.well-known/webfinger resource

Folks,

So far, rea= ction has been positive in favor of option (2).  As noted, this
wou= ld mean that WebFinger is, more-or-less, the equivalent of the LRDD
reso= urce as defined in RFC 6415, except that the default representation willbe application/json rather than application/xrd+xml.

Before we start working on the new= text, I do want to understand if folks
agree to the following usage &am= p; results.


$ curl -v 'https://packetizer.co= m/.well-known/webfinger'
-- returns 404, as there is no specified re= source
-- Should there be a different response code? If so, what?

$ curl -v 'https://packetizer.com/.well-known/webfing= er?
          resource=3Dacct:paulej@packetizer.com'
-- returns a JRD= for the specified resource
-- Example:
{
  "subject" : "acct= :paulej@packetizer.com",
 = ; "links" :
  [
    {
      "rel" : = "http://webfinger.net/rel/avatar",
      "href" := "http://www.packetizer.com/people/paulej/ima= ges/paulej.jpg"
    },
    {
   =   "rel" : "http://schemas.google.com/g/2010#updates= -from",
      "href" : "htt= p://www.packetizer.com/people/paulej/blog/blog.xml"
    },=
    {
      "rel" : "vcard",
  &nbs= p;   "href" : "http://www.packetizer.com/people/paulej/paulej.vcf= "
    }
  ]
}


$ curl -v 'https://packetizer.com/.well-known/webfinger?
    &n= bsp;     resource=3Dacct:paulej@packetizer.com&
          rel= =3Dvcard'
-- returns a JRD for the specified resource, filtered to inclu= de only
  the space-separated list of link relations in the "rel" p= arameter
-- Example:
{
  "subject" : "acct:paulej@packetizer.com",
  "links" :
=   [
    {
      "rel" : "vcard",
      "href" = : "http://www.packetizer.com/people/paulej/paulej.vc= f"
    }
  ]
}

In all cases, the "resour= ce" parameter might be any URI for which that
WebFinger server might be = able to provide an answer.  It might be an "acct:"
URI, "mailto:" U= RI, "http:" URI, etc.  I think that was generally agreed
before, th= ough we had the dialog about how to deal with the "tel:" URI and
other s= uch URIs that do not have domain names associated with them.

Paul

_______________________________________________
apps-discuss ma= iling list
apps-discuss@ietf.o= rg
https://www.ie= tf.org/mailman/listinfo/apps-discuss
 
<= /div>

= --764183289-1173786015-1352052871=:46114-- From cweiske@cweiske.de Sun Nov 4 10:08: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 D952E21F84CE for ; Sun, 4 Nov 2012 10:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[AWL=-1.857, BAYES_20=-0.74, J_CHICKENPOX_51=0.6, MANGLED_OFF=2.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 W8gNEYRZV14R for ; Sun, 4 Nov 2012 10:08:30 -0800 (PST) Received: from mail.cweiske.de (mail.cweiske.de [IPv6:2a01:488:66:1000:53a9:7c6:0:1]) by ietfa.amsl.com (Postfix) with ESMTP id 051D221F84CD for ; Sun, 4 Nov 2012 10:08:29 -0800 (PST) Received: by mail.cweiske.de (Postfix, from userid 65534) id 573C910438004; Sun, 4 Nov 2012 19:08:26 +0100 (CET) Received: from bogo (p54BD788A.dip.t-dialin.net [84.189.120.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.cweiske.de (Postfix) with ESMTPSA id 0659210438003; Sun, 4 Nov 2012 19:08:25 +0100 (CET) Date: Sun, 4 Nov 2012 19:08:26 +0100 From: Christian Weiske To: webfinger@googlegroups.com Message-ID: <20121104190826.4f1c1509@bogo> In-Reply-To: <074701cdbab0$5d9f3de0$18ddb9a0$@packetizer.com> References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <20121104104228.5a49c685@bogo> <074701cdbab0$5d9f3de0$18ddb9a0$@packetizer.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/v.0V+2qA4CiqNwj7s75Uak4"; protocol="application/pgp-signature" X-Mailman-Approved-At: Sun, 04 Nov 2012 12:27:33 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 04 Nov 2012 18:08:31 -0000 --Sig_/v.0V+2qA4CiqNwj7s75Uak4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Paul, > > > > -- returns a JRD for the specified resource, filtered to include > > > > only the space-separated list of link relations in the "rel" > > > > parameter > > > Why space-separated? I can live with that, but it seems like the > > > more natural thing to do would be to use multiple rel parameters: > >=20 > > Space separation would introduce problems with rel URLs that have > > spaces in them. You'd need to take care of double encoding the rel > > URL, while single-encoding the " " that separate the rels. >=20 > In addition to HTML following this convention, it is specified this > way in the Web Linking document (RFC 5988), too. I think it is best > that we follow the same format as existing specs. Link relation > types are always space-separated. I'd suggest we just define link > relation types such that they do not have spaces. But URIs are allowed as link relation types. URIs may have spaces. &rel=3Dhttp://www.packetizer.com/rel/blog%20with%20space You can't define them away. > > > webfinger?resource=3Dbob&rel=3Dvcard&rel=3Dblog&rel=3Dopenid.server > > Because of the double-encoding issue, I support the multiple rel > > parameter approach. > I know this will not work in some libraries, though. What some > libraries do is create a map of tag/value pairs. If "rel" is seen a > second time, it is either ignored or the old value is replaced. PHP uses [] to "add" to the parameter, e.g. > &f[]=3Da&f[]=3Db&f[]=3Dc so you get a GET array of > f =3D array(a, b, c) --=20 Regards/Mit freundlichen Gr=C3=BC=C3=9Fen Christian Weiske -=3D=E2=89=A1 Geeking around in the name of science since 1982 =E2=89=A1=3D- --Sig_/v.0V+2qA4CiqNwj7s75Uak4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlCWrxoACgkQFMhaCCTq+CPGxACgxfQ6SXN3kZv1Udu5naR1xIZA rHQAn0SfYxSKlXvzp55Qqd79+r6p1aNH =KZXb -----END PGP SIGNATURE----- --Sig_/v.0V+2qA4CiqNwj7s75Uak4-- From evan@status.net Sun Nov 4 13:29: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 96AAB21F84C2 for ; Sun, 4 Nov 2012 13:29:21 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoatFz6Tu59W for ; Sun, 4 Nov 2012 13:29:21 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 11DBF21F84B2 for ; Sun, 4 Nov 2012 13:29:20 -0800 (PST) Received: from [192.168.69.113] (modemcable107.194-202-24.mc.videotron.ca [24.202.194.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 10A948D541B; Sun, 4 Nov 2012 21:40:50 +0000 (UTC) Message-ID: <5096DE2B.9070500@status.net> Date: Sun, 04 Nov 2012 16:29:15 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Christian Weiske References: <5093E105.2090302@status.net> <054501cdb98f$8f77fe00$ae67fa00$@packetizer.com> <20121103103608.19cc37d1@bogo> In-Reply-To: <20121103103608.19cc37d1@bogo> Content-Type: multipart/alternative; boundary="------------070004080304020500060805" Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] High-level considerations about "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: Sun, 04 Nov 2012 21:29:21 -0000 This is a multi-part message in MIME format. --------------070004080304020500060805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1,000,000. I think this is a great way to do it. -Evan On 12-11-03 05:36 AM, Christian Weiske wrote: > Hello Paul, > > >> c. Defining a new resource for this server >> at /.well-known/webfinger (or swd ?) > I was for long in the RFC 6415 camp, and I still am. Reusing existing > standards makes much sense in my eyes. > > Given that people like the one request approach (I do see its > benefits, too), and that adding a resource parameter to host-meta is a > dirty hack, I'd rather go with a new resource - /.well-known/webfinger. > > This separates it cleanly, allows the one request solution without > hacks, and is even backward compatible with existing clients if the > lrdd link is changed to /.well-known/webfinger?resource={uri}. > Not that it is that important, but it's nice to have. > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------070004080304020500060805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
+1,000,000.

I think this is a great way to do it.

-Evan

On 12-11-03 05:36 AM, Christian Weiske wrote:
Hello Paul,



c.       Defining a new resource for this server
at /.well-known/webfinger (or swd ?)

I was for long in the RFC 6415 camp, and I still am. Reusing existing
standards makes much sense in my eyes.

Given that people like the one request approach (I do see its
benefits, too), and that adding a resource parameter to host-meta is a
dirty hack, I'd rather go with a new resource - /.well-known/webfinger.

This separates it cleanly, allows the one request solution without
hacks, and is even backward compatible with existing clients if the
lrdd link is changed to /.well-known/webfinger?resource={uri}.
Not that it is that important, but it's nice to have.





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

--------------070004080304020500060805-- From fluffy@cisco.com Sun Nov 4 15:48: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 AB30821F84FF for ; Sun, 4 Nov 2012 15:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 NdVE2UQMiyOi for ; Sun, 4 Nov 2012 15:48:20 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B1E1E21F84F3 for ; Sun, 4 Nov 2012 15:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=117; q=dns/txt; s=iport; t=1352072900; x=1353282500; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=siGOl8ehXOYZG2pGaU2XXRtJD0RJc4PgM+K8aa8CDz8=; b=dvxb+w7OP33XCoenOZU4MNoyxFFRral7nkYRGi7M+t9JL4Muwuc2gnIc EpeG8YoemZfzoTTRMAUbuOk4nfubXHVS9HRgq4xqtc2DVZM4AOss4SPJ/ e0hxAE3ZzRm1hGGtxj9pvJROWdCfyWBU4GWYPIB740CutV9rCh5z1O8/P c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8JAC3+llCtJV2b/2dsb2JhbABDwioEBIEJgQiCIAEEEgEnPxIBKhRCJwQODRqHaJlQnwmRXGEDpFSBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,712,1344211200"; d="scan'208";a="138686224" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 04 Nov 2012 23:48:12 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA4NmBHq020796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Nov 2012 23:48:11 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 17:48:11 -0600 From: "Cullen Jennings (fluffy)" To: "" Thread-Topic: draft-newton-json-content-rules Thread-Index: AQHNuubYEdmdY7zs006RafAgMU/pfA== Date: Sun, 4 Nov 2012 23:48:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.211] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004 x-tm-as-result: No--22.561100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: [apps-discuss] draft-newton-json-content-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, 04 Nov 2012 23:48:21 -0000 I think something like this would be useful for the folks writing specs tha= t use JSON. I like it.=20 Cullen From paulej@packetizer.com Sun Nov 4 18:47: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 6214621F8903 for ; Sun, 4 Nov 2012 18:47:20 -0800 (PST) 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=[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 5E07bTHa-PI8 for ; Sun, 4 Nov 2012 18:47:19 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 955AB21F88EC for ; Sun, 4 Nov 2012 18:47:19 -0800 (PST) Received: from [130.129.68.150] (dhcp-4496.meeting.ietf.org [130.129.68.150]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qA52l3r2019432 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 4 Nov 2012 21:47:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1352083638; bh=MeJqGql8O4uWUFJBiUsa4b3903T8r+3aJ8es2YoVITc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=cucuMlwie4pEwiltfdX2HLwpp05B0qQgr+FAOOoVfJkfQpxGqoRbrkG6qSJcQnOyd bkZnTwQdQ+MLUz62TouTserz6kRfwNuBbO+2D5vshChAQdT6GwI0mBFRralmqDS3gx RprHxfz0Z1IxpftR5/GIxRxaosEvick+VSVWEvoM= Message-ID: <509728A6.3070800@packetizer.com> Date: Sun, 04 Nov 2012 21:47:02 -0500 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: William Mills References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <1352004496.14504.YahooMailNeo@web31813.mail.mud.yahoo.com> <06cf01cdbaa6$05ad8dd0$1108a970$@packetizer.com> <1352047648.61656.YahooMailNeo@web31813.mail.mud.yahoo.com> <074901cdbab1$9b991110$d2cb3330$@packetizer.com> <1352052871.46114.YahooMailNeo@web31811.mail.mud.yahoo.com> In-Reply-To: <1352052871.46114.YahooMailNeo@web31811.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------020407030306000203010807" Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 05 Nov 2012 02:47:20 -0000 This is a multi-part message in MIME format. --------------020407030306000203010807 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/4/2012 1:14 PM, William Mills wrote: > AH! OK, this is exactly the answer, host-meta is for generally > advertised information, webfinger requires a resource. Worth a > mention in the spec? Possibly... so long as that mention does not cause a divide among the interested parties :-) If we draft a new spec around those points I listed in the previous email (the option (2) list), then we could consider inserting that. This will be a clean break from RFC 6415, whereas the current WF spec is heavily dependent on RFC 6415. We'll discuss this in the meeting tomorrow and see what the group thinks. Paul --------------020407030306000203010807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 11/4/2012 1:14 PM, William Mills wrote:
AH!  OK, this is exactly the answer, host-meta is for generally advertised information, webfinger requires a resource.  Worth a mention in the spec?

Possibly... so long as that mention does not cause a divide among the interested parties :-)

If we draft a new spec around those points I listed in the previous email (the option (2) list), then we could consider inserting that.  This will be a clean break from RFC 6415, whereas the current WF spec is heavily dependent on RFC 6415.

We'll discuss this in the meeting tomorrow and see what the group thinks.

Paul

--------------020407030306000203010807-- From wmills@yahoo-inc.com Sun Nov 4 19:36: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 E199E21F8997 for ; Sun, 4 Nov 2012 19:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.919 X-Spam-Level: X-Spam-Status: No, score=-16.919 tagged_above=-999 required=5 tests=[AWL=0.678, 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 4WXV1Vf9uTLK for ; Sun, 4 Nov 2012 19:36:23 -0800 (PST) Received: from nm18.bullet.mail.sp2.yahoo.com (nm18.bullet.mail.sp2.yahoo.com [98.139.91.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0E221F8996 for ; Sun, 4 Nov 2012 19:36:20 -0800 (PST) Received: from [98.139.91.65] by nm18.bullet.mail.sp2.yahoo.com with NNFMP; 05 Nov 2012 03:36:17 -0000 Received: from [98.139.91.37] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 05 Nov 2012 03:36:17 -0000 Received: from [127.0.0.1] by omp1037.mail.sp2.yahoo.com with NNFMP; 05 Nov 2012 03:36:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 676211.55886.bm@omp1037.mail.sp2.yahoo.com Received: (qmail 17050 invoked by uid 60001); 5 Nov 2012 03:36:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1352086577; bh=Ct13CZi+TlvxftXgcFpt0s2V9B8UZSES2CiIfZQw6Jw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=guyrJKLnH29skJquKipUDfSc+SbJ5HlR+Ek8iPiPv878ccCh38acyzlKf+W96JoH1d/HEpXvbPVgTNxKSdKo2Gxt+3UbxLBV8KnY8isA+Rtrz95C3w7psDjoIGDsv+zZWcqcbj0qLn66ac2Dcsdb0UZk5GeT9PICH1X+6jYb2X0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Im/D2zJ/J1Sob/tX/fhsz5nifePnKfEilJIU7frpaXGvgaKzpEAtjVmfjVN7EFsU78HGW1Mn1+GuM2NlVKz4RSEhDxc2XHSa3XuMR+PycZwCly5TFaEy4RFoi0zJIqhLVgQG4ApOYYZ45BWq0e9WXbrOSgIBKVUYek/GbwMqXbE=; X-YMail-OSG: mMG8kF8VM1n48nbKLV.jTK23BG6V2oYF0B9xtnWQI6aQsuQ LiPyM2M8xmFaX_RgUsktiCw8QvUqPjnyABFb2vxAOQcGRPyHlrsGuLPqy_CH jQtM85Agp188qLsWoQw30zyLx02U2chBBq2Fs8v2KfNwY4m.LwXc1q1tJ6wB WQrg2n01s9hBkg1rPI4jg9Topsr6sF0VNITPxqOux54cq3cuUnl2eotiJOgl mgy.dM.cyLeNx_JE5b351SawU1w97R8s7Kh_gLZQQpGp4DOQ73xVqOr5tjGN eWLq.jQAw55wacOn8ruJGGB8a0X7t5yyDssewzu5uivn_n5CbeQ248TMHrOy 8vBrYyT1CoTqZj1.H5ZfvWa8WYYmK.PwG4fI5SH_oO9KDaeLmNh6B8Z7U9Xj pw49CQpNzHR.jgcN5_MfGxleeJNeA_1r7KkeUnC_oKaEG1Ab5R3S3h4jO1qj N8jja3RN5Rsv_oq19KsqrFA-- Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Sun, 04 Nov 2012 19:36:16 PST X-Rocket-MIMEInfo: 001.001, SSdkIHN1Z2dlc3Qgd2hlcmUgdGhlIHJlc291cmNlIHBhcmFtZXRlciBpcyBkZWZpbmVkIGFzIHJlcXVpcmVkIHRoYXQgd2UgYWRkICJOb3RlIHRoYXQgaG9zdC1tZXRhIGNvdmVycyB0aGUgZ2VuZXJpYyBjYXNlIHdoZXJlIGEgc2l0ZSB3aXNoZWQgdG8gYWR2ZXJ0aXNlIGEgZ2VuZXJhbCBwcm9maWxlIG9mIHNlcnZpY2VzIHdoZW4gYSBzcGVjaWZpYyByZXNvdXJjZSBpcyBub3QgcmVxdWVzdGVkLiIKCkFub3RoZXIgcXVlc3Rpb24sIGFyZSB0aGUgcmVzb3VyY2VzIGxpc3RlZCBpbiB0aGUgcmVzb3VyY2UgcGEBMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.123.460 References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <1352004496.14504.YahooMailNeo@web31813.mail.mud.yahoo.com> <06cf01cdbaa6$05ad8dd0$1108a970$@packetizer.com> <1352047648.61656.YahooMailNeo@web31813.mail.mud.yahoo.com> <074901cdbab1$9b991110$d2cb3330$@packetizer.com> <1352052871.46114.YahooMailNeo@web31811.mail.mud.yahoo.com> <509728A6.3070800@packetizer.com> Message-ID: <1352086576.91289.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Sun, 4 Nov 2012 19:36:16 -0800 (PST) From: William Mills To: "Paul E. Jones" In-Reply-To: <509728A6.3070800@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-626654086-1352086576=:91289" Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 05 Nov 2012 03:36:24 -0000 --764183289-626654086-1352086576=:91289 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'd suggest where the resource parameter is defined as required that we add= "Note that host-meta covers the generic case where a site wished to advert= ise a general profile of services when a specific resource is not requested= ."=0A=0AAnother question, are the resources listed in the resource paramete= r link relation names?=A0 can we support, or do we want to support somethin= g like "oauth-*" so I don't have to list the 3 (or 2) specific OAuth relate= d link names?=0A=0A=0A=0A>________________________________=0A> From: Paul E= . Jones =0A>To: William Mills = =0A>Cc: "apps-discuss@ietf.org" ; "webfinger@google= groups.com" =0A>Sent: Sunday, November 4, 2012= 6:47 PM=0A>Subject: Re: [apps-discuss] The /.well-known/webfinger resource= =0A> =0A>=0A>On 11/4/2012 1:14 PM, William Mills wrote:=0A>=0A>AH!=A0 OK, t= his is exactly the answer, host-meta is for generally advertised informatio= n, webfinger requires a resource.=A0 Worth a mention in the spec?=0A>>=0A>P= ossibly... so long as that mention does not cause a divide among=0A the = interested parties :-)=0A>=0A>If we draft a new spec around those points I = listed in the previous=0A email (the option (2) list), then we could con= sider inserting that.=A0=0A This will be a clean break from RFC 6415, wh= ereas the current WF=0A spec is heavily dependent on RFC 6415.=0A>=0A>We= 'll discuss this in the meeting tomorrow and see what the group=0A think= s.=0A>=0A>Paul=0A>=0A>=0A>=0A> --764183289-626654086-1352086576=:91289 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I'd sugge= st where the resource parameter is defined as required that we add "Note th= at host-meta covers the generic case where a site wished to advertise a gen= eral profile of services when a specific resource is not requested."
Another question, are the resources listed in the resource parameter link = relation names?  can we support, or do we want to support something li= ke "oauth-*" so I don't have to list the 3 (or 2) specific OAuth related li= nk names?

From: Paul E.= Jones <paulej@packetizer.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: "apps-discuss@ietf.org" <app= s-discuss@ietf.org>; "webfinger@googlegroups.com" <webfinger@googlegr= oups.com>
Sent: Su= nday, November 4, 2012 6:47 PM
Su= bject: Re: [apps-discuss] The /.well-known/webfinger resource

=0A =0A =0A =0A
= =0A
On 11/4/2012 1:14 PM, Wil= liam Mills=0A wrote:
=0A
=0A
= =0A
AH! =0A = OK, this is exactly the answer, host-meta is for generally=0A = advertised information, webfinger requires a resource.  Worth a=0A = mention in the spec?
=0A
=0A
=0A
= =0A Possibly... so long as that mention does not cause a divide among=0A= the interested parties :-)
=0A
=0A If we draft a new spec = around those points I listed in the previous=0A email (the option (2) li= st), then we could consider inserting that. =0A This will be a clea= n break from RFC 6415, whereas the current WF=0A spec is heavily depende= nt on RFC 6415.
=0A
=0A We'll discuss this in the meeting tomo= rrow and see what the group=0A thinks.
=0A
=0A Paul
=0A =
=0A
=0A=0A


=
--764183289-626654086-1352086576=:91289-- From paulej@packetizer.com Sun Nov 4 20:42: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 8C2FB21F88FE for ; Sun, 4 Nov 2012 20:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 f1N9mOSx1GZq for ; Sun, 4 Nov 2012 20:42:42 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 56F9D21F8583 for ; Sun, 4 Nov 2012 20:42:42 -0800 (PST) Received: from [130.129.68.150] (dhcp-4496.meeting.ietf.org [130.129.68.150]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qA54geDa024286 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 4 Nov 2012 23:42:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1352090560; bh=jziRwFyy1R79PkkyuZ+pGNqHAmx9MVochTbXrc1EC2A=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=njeP2RUyeauleuRfI0LwFq92sxhEkCkAlAEj64u1pLuQpDV5dukbaN3IgK/Xpmnje StgwvGxAkVeyt9hPhvGWUcH6NZicuZajzExxp1FJFtqel3MBSPEQ14brXEX3nyHeOm B6YWWfM8iMvvppQE8HiNIn3AGgKUlMQ6KuhMle2c= Message-ID: <509743BF.3010404@packetizer.com> Date: Sun, 04 Nov 2012 23:42:39 -0500 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Brad Fitzpatrick References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <072201cdbaad$78513970$68f3ac50$@packetizer.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030601080509010707070904" Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 05 Nov 2012 04:42:43 -0000 This is a multi-part message in MIME format. --------------030601080509010707070904 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Brad, On 11/4/2012 5:06 PM, Brad Fitzpatrick wrote: > On Sun, Nov 4, 2012 at 5:57 PM, Paul E. Jones > wrote: > > > $ curl -v 'https://packetizer.com/.well-known/webfinger? > resource=acct:paulej@packetizer.com > & > rel=vcard' > -- returns a JRD for the specified resource, filtered to > include only > the space-separated list of link relations in the "rel" > parameter > > Why space-separated? I can live with that, but it seems like the > more natural thing to do would be to use multiple rel parameters: > > webfinger?resource=bob&rel=vcard&rel=blog&rel=openid.server > > PEJ: The reason for space-separating was to be consistent with > HTML. That’s exactly how you’ll find multiple link relation > values appearing in an HTML document. An issue with using the > same parameter multiple times in the URL is that I suspect many > (or most) protocol libraries would either take the first one or > the last one it sees and discard the others. > > > But URLs aren't HTML (or JSON, or XML), and as Christian said: URLs > can contain %20. > That's true, but they are URLs are specifically selected to serve as "link relation" types. The "Web Linking" spec, as I noted separately, also defined these as a space-separated list. See the ABNF in RFC 5988. I'm just attempting to maintain consistency. So, the Link header in HTTP and Link in HTML is a space separated list. Why not the URI parameter? > Let's consider your real fear, that HTTP libraries suck at multiple > parameters, first for a server and then for a client: > > For a server: > a) Servers are generally written by more competent people. So they > probably know how to use their language's HTTP library properly. All > languages and frameworks I've ever seen let you do it. > b) Support for rel is only a SHOULD. Even if a server ignores it, > they're still compliant. > c) The common case will be clients requesting 0 (all) or 1 rel anyway. My "fear" might be entirely unfounded, but... a) Sometimes that's true ;-) (I do agree libraries SHOULD support multiple parameters of the same name.) b) Definitely. c) If the server only grabs the first or the last, then the results are totally wrong. Thus, the server must either do it right or not do it at all. > > For a client: > a) The common case will be clients requesting 0 (all) or 1 rel anyway. > b) If they want to filter on 2 or more, they can read some docs. > Alternatively, they can request no filter and get all the rel/value > pairs and do their own filtering, wasting a bit of bandwidth. > > I'm really not worried. > > Space separated seems like a hack. I think I'm going to regret using that word ;-) I guess I brought it on myself. But, really, this one was not intended to be a hack, but just to follow existing style. However, if folks prefer a list of rel parameters rather than a space-separated list of rels in a single rel parameter, I don't really care. > But I have a good card to play now: If we go with space-separated rel > parameters, I'll endeavor to introduce rel URLs containing spaces, > just to confuse clients. I can see it now: "Appendix A: recommended > algorithm for string splitting on whitespace, re-joining fragments > which don't begin with 'http' with their preceeding fragment." If there wasn't a lot of history with this space-separated list... ;-) > Or maybe some spec already says rel URLs can't contain " ", %20, or +? > If so, we'd want to reinforce that in the webfinger spec. If not, > I'd especially want to avoid space separation. I could not find anything in the Web Linking spec that forbid spaces, but I might have missed it. It does speak about quote marks. URIs would have to be escaped, just in case they contain certain characters. But, one escape is better than two, for sure. I would just like to think we would not select URIs that would contain spaces... but I'll never get that, I suppose. > But I'm happy we're down to discussing something as boring as this. I > absolutely love the recent change of direction to a radically > simplified spec. :) And just so you're happy: $ curl 'https://packetizer.com/.well-known/webfinger?resource=paulej@packetizer.com&rel=vcard&rel=http://microformats.org/profile/hcard&rel=vcard' I changed my code to use multiple 'rel' parameters (and was to lazy to escape what I put on the command-line, but properly-escaped URLs should work). Paul --------------030601080509010707070904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Brad,

On 11/4/2012 5:06 PM, Brad Fitzpatrick wrote:
On Sun, Nov 4, 2012 at 5:57 PM, Paul E. Jones <paulej@packetizer.com> wrote:


$ curl -v 'https://packetizer.com/.well-known/webfinger?
           resource=acct:paulej@packetizer.com&
           rel=vcard'
-- returns a JRD for the specified resource, filtered to include only
   the space-separated list of link relations in the "rel" parameter

 

Why space-separated?  I can live with that, but it seems like the more natural thing to do would be to use multiple rel parameters:

 

webfinger?resource=bob&rel=vcard&rel=blog&rel=openid.server

 

PEJ: The reason for space-separating was to be consistent with HTML.  That’s exactly how you’ll find multiple link relation values appearing in an HTML document.  An issue with using the same parameter multiple times in the URL is that I suspect many (or most) protocol libraries would either take the first one or the last one it sees and discard the others.


But URLs aren't HTML (or JSON, or XML), and as Christian said: URLs can contain %20.


That's true, but they are URLs are specifically selected to serve as "link relation" types.  The "Web Linking" spec, as I noted separately, also defined these as a space-separated list.  See the ABNF in RFC 5988.  I'm just attempting to maintain consistency.  So, the Link header in HTTP and Link in HTML is a space separated list.  Why not the URI parameter?

Let's consider your real fear, that HTTP libraries suck at multiple parameters, first for a server and then for a client:

For a server:
a) Servers are generally written by more competent people.  So they probably know how to use their language's HTTP library properly.  All languages and frameworks I've ever seen let you do it.
b) Support for rel is only a SHOULD.  Even if a server ignores it, they're still compliant.
c) The common case will be clients requesting 0 (all) or 1 rel anyway.

My "fear" might be entirely unfounded, but...
a) Sometimes that's true ;-)  (I do agree libraries SHOULD support multiple parameters of the same name.)
b)  Definitely.
c) If the server only grabs the first or the last, then the results are totally wrong.  Thus, the server must either do it right or not do it at all.


For a client:
a) The common case will be clients requesting 0 (all) or 1 rel anyway.
b) If they want to filter on 2 or more, they can read some docs.  Alternatively, they can request no filter and get all the rel/value pairs and do their own filtering, wasting a bit of bandwidth.

I'm really not worried.

Space separated seems like a hack.

I think I'm going to regret using that word ;-)  I guess I brought it on myself.

But, really, this one was not intended to be a hack, but just to follow existing style.  However, if folks prefer a list of rel parameters rather than a space-separated list of rels in a single rel parameter, I don't really care.

But I have a good card to play now:  If we go with space-separated rel parameters, I'll endeavor to introduce rel URLs containing spaces, just to confuse clients.  I can see it now: "Appendix A: recommended algorithm for string splitting on whitespace, re-joining fragments which don't begin with 'http' with their preceeding fragment."

If there wasn't a lot of history with this space-separated list... ;-)

Or maybe some spec already says rel URLs can't contain " ", %20, or +?  If so, we'd want to reinforce that in the webfinger spec.  If not, I'd especially want to avoid space separation.

I could not find anything in the Web Linking spec that forbid spaces, but I might have missed it.  It does speak about quote marks.  URIs would have to be escaped, just in case they contain certain characters.  But, one escape is better than two, for sure.  I would just like to think we would not select URIs that would contain spaces... but I'll never get that, I suppose.

But I'm happy we're down to discussing something as boring as this.  I absolutely love the recent change of direction to a radically simplified spec.

:)

And just so you're happy:
$ curl 'https://packetizer.com/.well-known/webfinger?resource=paulej@packetizer.com&rel=vcard&rel=http://microformats.org/profile/hcard&rel=vcard'

I changed my code to use multiple 'rel' parameters (and was to lazy to escape what I put on the command-line, but properly-escaped URLs should work).

Paul




--------------030601080509010707070904-- From paulej@packetizer.com Sun Nov 4 21:05: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 BA2E621F88D4 for ; Sun, 4 Nov 2012 21:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 V+bn-1u6kYJ5 for ; Sun, 4 Nov 2012 21:05:09 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C3C7D21F88C1 for ; Sun, 4 Nov 2012 21:05:08 -0800 (PST) Received: from [130.129.68.150] (dhcp-4496.meeting.ietf.org [130.129.68.150]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qA5557nt025297 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Nov 2012 00:05:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1352091907; bh=WeWrBEcW7w8DncJfO8FblMvVTA1ttiIAFCG60y144gQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=II3pRP2BNykL5Mso9v5+W6ZE8jXXxlogv/rXsAmR3Qbkbq68sjM9QQoqZ4eborcQV 6A/h+4XeEdx6lMtQMPprVHBMiX7Xh7nwh7XfZmLNjGbHzVOg//6RTadv0r8S+Q25od HPcSx38QAa591uEO9Kh5WpGXO1RJORaadljuWIsY= Message-ID: <50974903.1090901@packetizer.com> Date: Mon, 05 Nov 2012 00:05:07 -0500 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: William Mills References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <1352004496.14504.YahooMailNeo@web31813.mail.mud.yahoo.com> <06cf01cdbaa6$05ad8dd0$1108a970$@packetizer.com> <1352047648.61656.YahooMailNeo@web31813.mail.mud.yahoo.com> <074901cdbab1$9b991110$d2cb3330$@packetizer.com> <1352052871.46114.YahooMailNeo@web31811.mail.mud.yahoo.com> <509728A6.3070800@packetizer.com> <1352086576.91289.YahooMailNeo@web31811.mail.mud.yahoo.com> In-Reply-To: <1352086576.91289.YahooMailNeo@web31811.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------030306040903010408060606" Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 05 Nov 2012 05:05:09 -0000 This is a multi-part message in MIME format. --------------030306040903010408060606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Remind me (or whomever the editor will be) once we have a new draft. I don't recommend using wildcards (or more complex regular expressions) in the link relations. This stars to get complicated for the client. Paul On 11/4/2012 10:36 PM, William Mills wrote: > I'd suggest where the resource parameter is defined as required that > we add "Note that host-meta covers the generic case where a site > wished to advertise a general profile of services when a specific > resource is not requested." > > Another question, are the resources listed in the resource parameter > link relation names? can we support, or do we want to support > something like "oauth-*" so I don't have to list the 3 (or 2) specific > OAuth related link names? > > ------------------------------------------------------------------------ > *From:* Paul E. Jones > *To:* William Mills > *Cc:* "apps-discuss@ietf.org" ; > "webfinger@googlegroups.com" > *Sent:* Sunday, November 4, 2012 6:47 PM > *Subject:* Re: [apps-discuss] The /.well-known/webfinger resource > > On 11/4/2012 1:14 PM, William Mills wrote: >> AH! OK, this is exactly the answer, host-meta is for generally >> advertised information, webfinger requires a resource. Worth a >> mention in the spec? > > Possibly... so long as that mention does not cause a divide among > the interested parties :-) > > If we draft a new spec around those points I listed in the > previous email (the option (2) list), then we could consider > inserting that. This will be a clean break from RFC 6415, whereas > the current WF spec is heavily dependent on RFC 6415. > > We'll discuss this in the meeting tomorrow and see what the group > thinks. > > Paul > > > --------------030306040903010408060606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Remind me (or whomever the editor will be) once we have a new draft.

I don't recommend using wildcards (or more complex regular expressions) in the link relations.  This stars to get complicated for the client.

Paul

On 11/4/2012 10:36 PM, William Mills wrote:
I'd suggest where the resource parameter is defined as required that we add "Note that host-meta covers the generic case where a site wished to advertise a general profile of services when a specific resource is not requested."

Another question, are the resources listed in the resource parameter link relation names?  can we support, or do we want to support something like "oauth-*" so I don't have to list the 3 (or 2) specific OAuth related link names?

From: Paul E. Jones <paulej@packetizer.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>; "webfinger@googlegroups.com" <webfinger@googlegroups.com>
Sent: Sunday, November 4, 2012 6:47 PM
Subject: Re: [apps-discuss] The /.well-known/webfinger resource

On 11/4/2012 1:14 PM, William Mills wrote:
AH!  OK, this is exactly the answer, host-meta is for generally advertised information, webfinger requires a resource.  Worth a mention in the spec?

Possibly... so long as that mention does not cause a divide among the interested parties :-)

If we draft a new spec around those points I listed in the previous email (the option (2) list), then we could consider inserting that.  This will be a clean break from RFC 6415, whereas the current WF spec is heavily dependent on RFC 6415.

We'll discuss this in the meeting tomorrow and see what the group thinks.

Paul




--------------030306040903010408060606-- From internet-drafts@ietf.org Sun Nov 4 21:07: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 1066921F8A89; Sun, 4 Nov 2012 21:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 NEAU7k4I4Hg8; Sun, 4 Nov 2012 21:07:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C0821F8A66; Sun, 4 Nov 2012 21:07:53 -0800 (PST) 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.35 Message-ID: <20121105050753.25600.95561.idtracker@ietfa.amsl.com> Date: Sun, 04 Nov 2012 21:07:53 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-jones-simple-web-discovery-04.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, 05 Nov 2012 05:07:54 -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 : Simple Web Discovery (SWD) Author(s) : Michael B. Jones Yaron Y. Goland Filename : draft-jones-simple-web-discovery-04.txt Pages : 8 Date : 2012-11-04 Abstract: Simple Web Discovery (SWD) defines an HTTPS GET based mechanism to discover the location of a given type of service for a given principal starting only with a domain name. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jones-simple-web-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-jones-simple-web-discovery-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-jones-simple-web-discovery-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paulej@packetizer.com Sun Nov 4 21:25: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 B554121F8A68 for ; Sun, 4 Nov 2012 21:25:26 -0800 (PST) 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 Il+6yGRNo1vI for ; Sun, 4 Nov 2012 21:25:26 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFF221F8A65 for ; Sun, 4 Nov 2012 21:25:25 -0800 (PST) Received: from [130.129.68.150] (dhcp-4496.meeting.ietf.org [130.129.68.150]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qA55PN0t026166 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Nov 2012 00:25:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1352093123; bh=Dmn4GEeVcLNpRpfuRPBQi72sdaERgfcfT/FydNxnLns=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=kPNixkIgcDxxAQV5hqLiHByHD4GxJE9rFmYjclXhpMjJbIkiLFFIgMtX+e16GFCNx r0/mngEMui8UgHYvdzQhsLORtKZUW3y6qgwK91Z8RFpRmX1UORXnLV5x0GCnV192mw j7Hji5qGRWPiTlvE8e3Y8HBUR/B1sGwXXHCwxHYw= Message-ID: <50974DC3.3010209@packetizer.com> Date: Mon, 05 Nov 2012 00:25:23 -0500 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Christian Weiske References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <20121104104228.5a49c685@bogo> <074701cdbab0$5d9f3de0$18ddb9a0$@packetizer.com> <20121104190826.4f1c1509@bogo> In-Reply-To: <20121104190826.4f1c1509@bogo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 05 Nov 2012 05:25:26 -0000 Christian, But, you can define them away. These are link relation values we select. They're not arbitrary URIs that users select or whatever. I don't think I've ever seen a link relation URI defined to have a space in it. Even so, I'll not argue the point. But, it is important to understand that link relations are definitely selected names. Paul > But URIs are allowed as link relation types. URIs may have spaces. > > &rel=http://www.packetizer.com/rel/blog%20with%20space > > You can't define them away. > > From jasnell@gmail.com Sun Nov 4 21:37: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 7A15221F89C9 for ; Sun, 4 Nov 2012 21:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 q3Pj-Yoqe3al for ; Sun, 4 Nov 2012 21:37:09 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9760121F8967 for ; Sun, 4 Nov 2012 21:37:09 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so4563954iak.31 for ; Sun, 04 Nov 2012 21:37:09 -0800 (PST) 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=JeKoUr0DLmb3KMM2lxTw4PlYbNDrJQhIhQIREliwXCs=; b=lzlZHyRpwQueni/DwwJNWNBzrWpukhaRe4hD8gwyQDGfkKaxJUt7bwiuqjEKY86B0p y+niVUDstB95+a6s8rLiMSV7Am0Y4zHA9pmqQJMEAfLD7NB8RTuodIG+zFvAjwV0TKC+ Cz8w+CW0+gWpDCSAisaWNxyouuhQsEQWFtUE88FdhyXlIfR87FMs6d3cGCupX8eJdtnX adFt6LEeA3mOAFHZMcqS9f93dB5YL1UUXTIxY4JKH57rdCicBnmQDyZH0DjKmhbm0ALQ hrMW9/JE+rDjPQKNAJ/pdgQ3rELdNsa8Cm0uOOyDjH8zWtblMcyPOkEBpsEf9CWpstrg vWQQ== MIME-Version: 1.0 Received: by 10.50.160.165 with SMTP id xl5mr8099057igb.54.1352093829280; Sun, 04 Nov 2012 21:37:09 -0800 (PST) Received: by 10.64.46.225 with HTTP; Sun, 4 Nov 2012 21:37:09 -0800 (PST) Received: by 10.64.46.225 with HTTP; Sun, 4 Nov 2012 21:37:09 -0800 (PST) In-Reply-To: <50974DC3.3010209@packetizer.com> References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <20121104104228.5a49c685@bogo> <074701cdbab0$5d9f3de0$18ddb9a0$@packetizer.com> <20121104190826.4f1c1509@bogo> <50974DC3.3010209@packetizer.com> Date: Sun, 4 Nov 2012 21:37:09 -0800 Message-ID: From: James M Snell To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae9340efd65b45504cdb8e0d5 Cc: Christian Weiske , IETF Apps Discuss , webfinger@googlegroups.com Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 05 Nov 2012 05:37:10 -0000 --14dae9340efd65b45504cdb8e0d5 Content-Type: text/plain; charset=UTF-8 Not to mention the fact that a space delimited list of uris containing literal %20 sequences could be double escaped to bypass any ambiguity... e.g. uri=http://.../foo%2520bar%20http://.../bar%2520foo This would be the ideal encoding to avoid unintended decoding by overly helpful HTTP stacks, anyway. Most ideal, however, is don't use silly uris that contain spaces as rel values. - James On Nov 4, 2012 9:25 PM, "Paul E. Jones" wrote: > > Christian, > > But, you can define them away. These are link relation values we select. > They're not arbitrary URIs that users select or whatever. I don't think > I've ever seen a link relation URI defined to have a space in it. > > Even so, I'll not argue the point. But, it is important to understand > that link relations are definitely selected names. > > Paul > > But URIs are allowed as link relation types. URIs may have spaces. >> >> &rel=http://www.packetizer.**com/rel/blog%20with%20space >> >> You can't define them away. >> >> >> > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --14dae9340efd65b45504cdb8e0d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Not to mention the fact that a space delimited list of uris = containing literal %20 sequences could be double escaped to bypass any ambi= guity... e.g. uri=3Dhttp://.../foo%2520bar%20http://.../bar%2520foo

This would be the ideal encoding to avoid unintended decodin= g by overly helpful HTTP stacks, anyway. Most ideal, however, is don't = use silly uris that contain spaces as rel values.

- James

On Nov 4, 2012 9:25 PM, "Paul E. Jones"= ; <paulej@packetizer.com>= ; wrote:

Christian,

But, you can define them away. =C2=A0These are link relation values we sele= ct. =C2=A0They're not arbitrary URIs that users select or whatever. =C2= =A0I don't think I've ever seen a link relation URI defined to have= a space in it.

Even so, I'll not argue the point. =C2=A0But, it is important to unders= tand that link relations are definitely selected names.

Paul

But URIs are allowed as link relation types. URIs may have spaces.

&rel=3Dhttp://www.packetizer.com/rel/blog%20with%20space

You can't define them away.



_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--14dae9340efd65b45504cdb8e0d5-- From laurentwalter.goix@telecomitalia.it Mon Nov 5 00:19: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 026E521F89BD for ; Mon, 5 Nov 2012 00:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 8TPIpQHaNB4Q for ; Mon, 5 Nov 2012 00:19:19 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id A0BB621F8996 for ; Mon, 5 Nov 2012 00:19:16 -0800 (PST) Content-Type: multipart/mixed; boundary="_7436d553-8b49-4b04-a068-159c351d14e8_" Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Mon, 5 Nov 2012 09:19:10 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Mon, 5 Nov 2012 09:19:10 +0100 From: Goix Laurent Walter To: James M Snell Date: Mon, 5 Nov 2012 09:19:02 +0100 Thread-Topic: [apps-discuss] The /.well-known/webfinger resource Thread-Index: Ac27LjssXanQzGaMQ7qOY033rwrPxQ== Message-ID: <012857E3-021C-4682-B5E5-C24D18697A88@telecomitalia.it> References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <20121104104228.5a49c685@bogo> <074701cdbab0$5d9f3de0$18ddb9a0$@packetizer.com> <20121104190826.4f1c1509@bogo> <50974DC3.3010209@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: Christian Weiske , IETF Apps Discuss , "webfinger@googlegroups.com" Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 05 Nov 2012 08:19:20 -0000 --_7436d553-8b49-4b04-a068-159c351d14e8_ Content-Type: multipart/alternative; boundary="_000_012857E3021C4682B5E5C24D18697A88telecomitaliait_" --_000_012857E3021C4682B5E5C24D18697A88telecomitaliait_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5kZWVkIGFzIHJlbCB2YWx1ZXMgYXJlIHdlbGwta25vd24gKGV2ZW4gd2hlbiBVcmlzKSBhbmQg ZXZlbnR1YWxseSBhaW0gYXQgYmVjb21pbmcgc2ltcGxlIHJlZ2lzdGVyZWQgdG9rZW5zIEkgd291 bGRuJ3Qgd29ycnkgbXVjaCBhYm91dCB3aGl0ZSBzcGFjZXMgdGhlcmUuIEknbSBhbHNvIG11Y2gg bW9yZSB3b3JyaWVkIGFib3V0IGludGVyb3BlcmFiaWxpdHkgd2l0aCBIVE1MIGZvcm1zLCBodHRw IHN0YWNrcyBhbmQgc2VydmVyIGltcGxlbWVudGF0aW9ucyAodGhhdCdzIDMgdmFyaWFibGVzIGFs cmVhZHkpIGluIGhhbmRsaW5nIG11bHRpcGxlIGZpZWxkcyAodXN1YWxseSBhIHBhaW4pLCBzbyAr MSBmb3IgYSBzaW5nbGUgc3BhY2Utc2VwYXJhdGVkIGxpc3QuDQoNCkxlIDUgbm92LiAyMDEyIMOg IDA2OjM3LCAiSmFtZXMgTSBTbmVsbCIgPGphc25lbGxAZ21haWwuY29tPG1haWx0bzpqYXNuZWxs QGdtYWlsLmNvbT4+IGEgw6ljcml0IDoNCg0KDQpOb3QgdG8gbWVudGlvbiB0aGUgZmFjdCB0aGF0 IGEgc3BhY2UgZGVsaW1pdGVkIGxpc3Qgb2YgdXJpcyBjb250YWluaW5nIGxpdGVyYWwgJTIwIHNl cXVlbmNlcyBjb3VsZCBiZSBkb3VibGUgZXNjYXBlZCB0byBieXBhc3MgYW55IGFtYmlndWl0eS4u LiBlLmcuIHVyaT1odHRwOi8vLi4uL2ZvbyUyNTIwYmFyJTIwaHR0cDovLy4uLi9iYXIlMjUyMGZv bw0KDQpUaGlzIHdvdWxkIGJlIHRoZSBpZGVhbCBlbmNvZGluZyB0byBhdm9pZCB1bmludGVuZGVk IGRlY29kaW5nIGJ5IG92ZXJseSBoZWxwZnVsIEhUVFAgc3RhY2tzLCBhbnl3YXkuIE1vc3QgaWRl YWwsIGhvd2V2ZXIsIGlzIGRvbid0IHVzZSBzaWxseSB1cmlzIHRoYXQgY29udGFpbiBzcGFjZXMg YXMgcmVsIHZhbHVlcy4NCg0KLSBKYW1lcw0KDQpPbiBOb3YgNCwgMjAxMiA5OjI1IFBNLCAiUGF1 bCBFLiBKb25lcyIgPHBhdWxlakBwYWNrZXRpemVyLmNvbTxtYWlsdG86cGF1bGVqQHBhY2tldGl6 ZXIuY29tPj4gd3JvdGU6DQoNCkNocmlzdGlhbiwNCg0KQnV0LCB5b3UgY2FuIGRlZmluZSB0aGVt IGF3YXkuICBUaGVzZSBhcmUgbGluayByZWxhdGlvbiB2YWx1ZXMgd2Ugc2VsZWN0LiAgVGhleSdy ZSBub3QgYXJiaXRyYXJ5IFVSSXMgdGhhdCB1c2VycyBzZWxlY3Qgb3Igd2hhdGV2ZXIuICBJIGRv bid0IHRoaW5rIEkndmUgZXZlciBzZWVuIGEgbGluayByZWxhdGlvbiBVUkkgZGVmaW5lZCB0byBo YXZlIGEgc3BhY2UgaW4gaXQuDQoNCkV2ZW4gc28sIEknbGwgbm90IGFyZ3VlIHRoZSBwb2ludC4g IEJ1dCwgaXQgaXMgaW1wb3J0YW50IHRvIHVuZGVyc3RhbmQgdGhhdCBsaW5rIHJlbGF0aW9ucyBh cmUgZGVmaW5pdGVseSBzZWxlY3RlZCBuYW1lcy4NCg0KUGF1bA0KDQpCdXQgVVJJcyBhcmUgYWxs b3dlZCBhcyBsaW5rIHJlbGF0aW9uIHR5cGVzLiBVUklzIG1heSBoYXZlIHNwYWNlcy4NCg0KJnJl bD1odHRwOi8vd3d3LnBhY2tldGl6ZXIuY29tL3JlbC9ibG9nJTIwd2l0aCUyMHNwYWNlDQoNCllv dSBjYW4ndCBkZWZpbmUgdGhlbSBhd2F5Lg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCmFwcHMt ZGlzY3Vzc0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQphcHBzLWRpc2N1c3MgbWFpbGluZyBs aXN0DQphcHBzLWRpc2N1c3NAaWV0Zi5vcmc8bWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQpRdWVz dG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZh bWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxz aWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGlu Zm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJp Y2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJl Z2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHBy b3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2Vt aW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1 dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2Vu ZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0KW2NpZDowMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwM0BUSS5EaXNjbGFpbWVyXVJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFt cGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4NCg0K --_000_012857E3021C4682B5E5C24D18697A88telecomitaliait_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkluZGVlZCBhcyByZWwgdmFsdWVzIGFyZSB3ZWxsLWtub3duIChldmVuIHdoZW4gVXJpcykg YW5kIGV2ZW50dWFsbHkgYWltIGF0IGJlY29taW5nIHNpbXBsZSByZWdpc3RlcmVkIHRva2VucyBJ IHdvdWxkbid0IHdvcnJ5IG11Y2ggYWJvdXQgd2hpdGUgc3BhY2VzIHRoZXJlLiBJJ20gYWxzbyBt dWNoIG1vcmUgd29ycmllZCBhYm91dCBpbnRlcm9wZXJhYmlsaXR5IHdpdGggSFRNTCBmb3Jtcywg aHR0cCBzdGFja3MgYW5kIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMNCiAodGhhdCdzIDMgdmFyaWFi bGVzIGFscmVhZHkpIGluIGhhbmRsaW5nIG11bHRpcGxlIGZpZWxkcyAodXN1YWxseSBhIHBhaW4p LCBzbyAmIzQzOzEgZm9yIGEgc2luZ2xlIHNwYWNlLXNlcGFyYXRlZCBsaXN0Ljxicj4NCjxicj4N CkxlIDUgbm92LiAyMDEyIMOgIDA2OjM3LCAmcXVvdDtKYW1lcyBNIFNuZWxsJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86amFzbmVsbEBnbWFpbC5jb20iPmphc25lbGxAZ21haWwuY29tPC9hPiZn dDsgYSDDqWNyaXQmbmJzcDs6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4NCjxkaXY+DQo8cCBkaXI9Imx0ciI+Tm90IHRvIG1lbnRpb24gdGhlIGZhY3QgdGhhdCBh IHNwYWNlIGRlbGltaXRlZCBsaXN0IG9mIHVyaXMgY29udGFpbmluZyBsaXRlcmFsICUyMCBzZXF1 ZW5jZXMgY291bGQgYmUgZG91YmxlIGVzY2FwZWQgdG8gYnlwYXNzIGFueSBhbWJpZ3VpdHkuLi4g ZS5nLiB1cmk9PGEgaHJlZj0iaHR0cDovLy4uLi9mb28lMjUyMGJhciUyMGh0dHA6Ly8uLi4vYmFy JTI1MjBmb28iPmh0dHA6Ly8uLi4vZm9vJTI1MjBiYXIlMjBodHRwOi8vLi4uL2JhciUyNTIwZm9v PC9hPjwvcD4NCjxwIGRpcj0ibHRyIj5UaGlzIHdvdWxkIGJlIHRoZSBpZGVhbCBlbmNvZGluZyB0 byBhdm9pZCB1bmludGVuZGVkIGRlY29kaW5nIGJ5IG92ZXJseSBoZWxwZnVsIEhUVFAgc3RhY2tz LCBhbnl3YXkuIE1vc3QgaWRlYWwsIGhvd2V2ZXIsIGlzIGRvbid0IHVzZSBzaWxseSB1cmlzIHRo YXQgY29udGFpbiBzcGFjZXMgYXMgcmVsIHZhbHVlcy48L3A+DQo8cCBkaXI9Imx0ciI+LSBKYW1l czwvcD4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBOb3YgNCwgMjAxMiA5OjI1IFBNLCAm cXVvdDtQYXVsIEUuIEpvbmVzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cGF1bGVqQHBhY2tl dGl6ZXIuY29tIj5wYXVsZWpAcGFja2V0aXplci5jb208L2E+Jmd0OyB3cm90ZTo8YnIgdHlwZT0i YXR0cmlidXRpb24iPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFl eCI+DQo8YnI+DQpDaHJpc3RpYW4sPGJyPg0KPGJyPg0KQnV0LCB5b3UgY2FuIGRlZmluZSB0aGVt IGF3YXkuICZuYnNwO1RoZXNlIGFyZSBsaW5rIHJlbGF0aW9uIHZhbHVlcyB3ZSBzZWxlY3QuICZu YnNwO1RoZXkncmUgbm90IGFyYml0cmFyeSBVUklzIHRoYXQgdXNlcnMgc2VsZWN0IG9yIHdoYXRl dmVyLiAmbmJzcDtJIGRvbid0IHRoaW5rIEkndmUgZXZlciBzZWVuIGEgbGluayByZWxhdGlvbiBV UkkgZGVmaW5lZCB0byBoYXZlIGEgc3BhY2UgaW4gaXQuPGJyPg0KPGJyPg0KRXZlbiBzbywgSSds bCBub3QgYXJndWUgdGhlIHBvaW50LiAmbmJzcDtCdXQsIGl0IGlzIGltcG9ydGFudCB0byB1bmRl cnN0YW5kIHRoYXQgbGluayByZWxhdGlvbnMgYXJlIGRlZmluaXRlbHkgc2VsZWN0ZWQgbmFtZXMu PGJyPg0KPGJyPg0KUGF1bDxicj4NCjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3Bh ZGRpbmctbGVmdDoxZXgiPg0KQnV0IFVSSXMgYXJlIGFsbG93ZWQgYXMgbGluayByZWxhdGlvbiB0 eXBlcy4gVVJJcyBtYXkgaGF2ZSBzcGFjZXMuPGJyPg0KPGJyPg0KJmFtcDtyZWw9PGEgaHJlZj0i aHR0cDovL3d3dy5wYWNrZXRpemVyLmNvbS9yZWwvYmxvZyUyMHdpdGglMjBzcGFjZSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly93d3cucGFja2V0aXplci48dT48L3U+Y29tL3JlbC9ibG9nJTIwd2l0 aCUyMHNwYWNlPC9hPjxicj4NCjxicj4NCllvdSBjYW4ndCBkZWZpbmUgdGhlbSBhd2F5Ljxicj4N Cjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzx1PjwvdT5fX19fX19fX19fX19fX19fXzxicj4NCmFwcHMtZGlzY3VzcyBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+YXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88dT48L3U+bGlzdGluZm8vYXBwcy1kaXNj dXNzPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4+YXBwcy1kaXNj dXNzIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86YXBwcy1k aXNjdXNzQGlldGYub3JnIj5hcHBzLWRpc2N1c3NAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxz cGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1k aXNjdXNzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vz czwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8c3R5bGUgdHlwZT0idGV4 dC9jc3MiPg0KPCEtLQ0Kc3Bhbi5HcmFtRSB7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0t ZTp5ZXM7fQ0KLS0+DQo8L3N0eWxlPg0KPHRhYmxlIHN0eWxlPSJ3aWR0aDo2MDBweDsiPg0KPHRi b2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJ3aWR0aDo1ODVweDsgZm9udC1mYW1pbHk6IFZlcmRhbmEs IEFyaWFsOyBmb250LXNpemU6MTJweDsgY29sb3I6IzAwMDsgdGV4dC1hbGlnbjoganVzdGlmeSIg d2lkdGg9IjM5NSI+DQo8ZGl2IGFsaWduPSJqdXN0aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5OyBsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYSI+UXVlc3RvIG1lc3NhZ2dp byBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUg cGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kNCiBhbHRy YSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9u aSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1 ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBk YXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUg YWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCjwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8cCBh bGlnbj0ianVzdGlmeSI+PHNwYW4gY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246 anVzdGlmeTsgbGluZS1oZWlnaHQ6bm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVO LUdCIj5UaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzPC9zcGFuPjwvaT48aT48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToNCiAgNy41cHQ7bXNvLWJpZGktZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj4mbmJz cDs8c3BhbiBjbGFzcz0iR3JhbUUiPmlzPC9zcGFuPiZuYnNwOzwvc3Bhbj48L2k+PGk+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6DQogIDcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRh bmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPmNvbmZpZGVudGlhbA0KIGFuZCBtYXkgY29udGFp biBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9u bHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVs c2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZp c2UgdGhlIHNlbmRlcg0KIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy48L3NwYW4+PC9pPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPg0KPC9zcGFuPjwv c3Bhbj48L3A+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0Ow0KICBmb250LWZhbWls eTpWZXJkYW5hIj48aW1nIHNyYz0iY2lkOjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz QFRJLkRpc2NsYWltZXIiIGFsdD0icmlzcGV0dGEgbCdhbWJpZW50ZSIgd2lkdGg9IjI2IiBoZWln aHQ9IjQwIj5SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ug bm9uIMOoIG5lY2Vzc2FyaW8uPC9zcGFuPjwvYj4NCjxwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_012857E3021C4682B5E5C24D18697A88telecomitaliait_-- --_7436d553-8b49-4b04-a068-159c351d14e8_ 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= --_7436d553-8b49-4b04-a068-159c351d14e8_-- From laurentwalter.goix@telecomitalia.it Mon Nov 5 02:58: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 0FB5F21F844A for ; Mon, 5 Nov 2012 02:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.197 X-Spam-Level: X-Spam-Status: No, score=-1.197 tagged_above=-999 required=5 tests=[AWL=0.521, 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 fsVrsqXHFMG8 for ; Mon, 5 Nov 2012 02:58:14 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id EAEFC21F844B for ; Mon, 5 Nov 2012 02:58:12 -0800 (PST) Content-Type: multipart/mixed; boundary="_728d5ac0-6582-4523-b4cc-3dfdfd6fdd7f_" Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Mon, 5 Nov 2012 11:58:03 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Mon, 5 Nov 2012 11:57:59 +0100 From: Goix Laurent Walter To: "Paul E. Jones" Date: Mon, 5 Nov 2012 11:57:58 +0100 Thread-Topic: [apps-discuss] R: High-level considerations about "webfinger" Thread-Index: AQIeWfuWjoUIv93mY+PWpHVBG3B76gJ00KovAaFt2qcB+atHoAFBXZKZlvzhqUCAAmfgwA== Message-ID: References: <5093E105.2090302@status.net> <054501cdb98f$8f77fe00$ae67fa00$@packetizer.com> <5BE71165-CE5F-4B5C-ACE9-63CA659B4987@telecomitalia.it> <05fe01cdba1c$339cd820$9ad68860$@packetizer.com> In-Reply-To: <05fe01cdba1c$339cd820$9ad68860$@packetizer.com> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" Subject: [apps-discuss] R: R: High-level considerations about "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: Mon, 05 Nov 2012 10:58:17 -0000 --_728d5ac0-6582-4523-b4cc-3dfdfd6fdd7f_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A50F6FC2GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A50F6FC2GRFMBX704BA02_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gUGF1bCwNCkNvbW1lbnRzIGFzIFt3YWx0ZXJdDQoNCkRhOiBQYXVsIEUuIEpvbmVzIFtt YWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tXQ0KSW52aWF0bzogZG9tZW5pY2EgNCBub3ZlbWJy ZSAyMDEyIDAuMzgNCkE6IEdvaXggTGF1cmVudCBXYWx0ZXINCkNjOiAnRXZhbiBQcm9kcm9tb3Un OyBhcHBzLWRpc2N1c3NAaWV0Zi5vcmc7IHdlYmZpbmdlckBnb29nbGVncm91cHMuY29tOyAnTWlr ZSBKb25lcycNCk9nZ2V0dG86IFJFOiBbYXBwcy1kaXNjdXNzXSBSOiBIaWdoLWxldmVsIGNvbnNp ZGVyYXRpb25zIGFib3V0ICJ3ZWJmaW5nZXIiDQoNCldhbHRlciwNCg0KV2UgY291bGQgdXBkYXRl IFJGQyA2NDE1LCBidXQgd2Ugc2hvdWxkIGtlZXAgdGhhdCBhcyBhIHNlcGFyYXRlIGFjdGl2aXR5 LiBUaGF0IHNhaWQsIGlzIHRoZXJlIHRydWx5IGEgYmVuZWZpdD8gIE5vIG9wcG9zaXRpb24sIGJ1 dCBJ4oCZbSBub3Qgc3VyZSBpZiB0aGVyZSBpcyBhIGxvdCBvZiB2YWx1ZSBpbiBkb2luZyBzby4N Cg0KW3dhbHRlcl0gaXQgaXMgdHJ1bHkgbWFpbmx5IGFpbWVkIGF0IOKAnGVsZXZhdGluZ+KAnSBK UkQgdG8gYSBzdGFuZGFsb25lIHNwZWMgdG8gYmUgbW9yZSBlYXNpbHkgcmVmZXJlbmNlYWJsZSB0 aGFuIGJlaW5nIG5lc3RlZCBhcyBhIHNpbXBsZSBhcHBlbmRpeCBpbiBhbm90aGVyIGluZGVwZW5k ZW50IHNwZWMuIFBsdXMgcG90ZW50aWFsIG1pbm9yIHVwZGF0ZXMgaWYgbmVlZGVkLiBCdXQgbm8g YmlnIGlzc3VlLg0KDQpUaGUgcmVsZXZhbmNlIG9mIHRoZSBleGFtcGxlcyB3YXMgYSBxdWVzdGlv biB3aXRoIHRoZSBjdXJyZW50IFdlYkZpbmdlciBkcmFmdCwgdG9vLiAgSXQgd291bGQgYmUgdXNl ZnVsIHRvIGhhdmUgcmVhbC13b3JsZCBleGFtcGxlcywgSSBhZ3JlZS4gIFRoYXQgc2FpZCwgdGhl eSBzaG91bGQgYmUgc2ltcGxlIG9uZXMgc28gYXMgdG8gbm90IGxvb3NlIGVmZmVjdC4NCg0KW3dh bHRlcl0gYWdyZWVkLiBJIGNhbiB0cnkgdG8gcHJvdmlkZSBvbmUgZm9yIGZlZGVyYXRlZCBzb2Np YWwgbmV0d29ya3MgZm9yIHRoZSBuZXh0IHJldmlzaW9uIGlmIHlvdS9ncm91cCB3aXNoLg0KDQpQ YXVsDQoNCkZyb206IEdvaXggTGF1cmVudCBXYWx0ZXIgW21haWx0bzpsYXVyZW50d2FsdGVyLmdv aXhAdGVsZWNvbWl0YWxpYS5pdF0NClNlbnQ6IFNhdHVyZGF5LCBOb3ZlbWJlciAwMywgMjAxMiAx MToyMiBBTQ0KVG86IFBhdWwgRS4gSm9uZXMNCkNjOiBFdmFuIFByb2Ryb21vdTsgYXBwcy1kaXNj dXNzQGlldGYub3JnOyB3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbTsgTWlrZSBKb25lcw0KU3Vi amVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFI6IEhpZ2gtbGV2ZWwgY29uc2lkZXJhdGlvbnMgYWJv dXQgIndlYmZpbmdlciINCg0KVGhhbmtzIFBhdWwhIEl0IHJlbWluZHMgbWUgb2YgYW4gZWFybHkg ZGlzY3Vzc2lvbiB3ZSBoYWQgb24gdGhpcyBhYm91dCBkb2N1bWVudC1vcmllbnRlZCB2cyBBUEkg YXBwcm9hY2guIE9wdGlvbiAyLCBwcm9iYWJseSB0aGUgYmVzdCB3YXkgZm9yd2FyZCwgaXMgYSBz b3J0IG9mIEFQSS4uLndlIGNhbiBkZWZpbmUgcGFyYW1ldGVycyBldGMuDQpJZiB0aGUgZ3JvdXAg c3RpY2tzIHdpdGggSnJkIGFuZCB0aGUgb3RoZXIgY29uc2lkZXJhdGlvbnMgeW91IG1hZGUgb24g aHR0cCByZWRpcmVjdHMgZXRjIEkgZG8gZ3Vlc3MgdGhpcyBpcyBhIGNsZWFuIEFQSSAob25lIGNv dWxkIGV2ZW4gdGhpbmsgb2YgUE9TVC9QVVQvREVMRVRFIGZvciB0aGlzIDopICkuIEFuZCBpdCBs ZWF2ZXMgNjQxNSB1bmNoYW5nZWQgYW5kIHdvcmtpbmcuIFNvbWUgY291bGQgc2F5IHVzZWxlc3Mg aWYgd2Yvc3dkIG1lcmdlciBpcyBjcmVhdGVkLCBidXQgYWN0dWFsbHkgdGhpcyB3YXkgd2UgYnVp bGQgc29tZXRoaW5nIHBhcmFsbGVsL2luZGVwZW5kZW50IGluZGVlZCwgc28gNjQxNSBoYXMgc3Rp bGwgaXRzIGRpZ25pdHkgYW5kIGlzIG5vdCBicm9rZW4gaW50byBnb29kIGFuZCBiYWQgcGFydHMu Li4NCg0KUGVyc29uYWxseSwgZm9yIG15IG93biB2aWV3IG9mIGZlZGVyYXRlZCBzb2NpYWwgbmV0 d29ya3MgYW5kIG15IE9NQSBoYXQgb24sICBJIGRvIHdvdWxkIHNwb25zb3IgYW4gNjQxNS1iYXNl ZCBzb2x1dGlvbiBhY3Jvc3Mgc29jaWFsIG5ldHdvcmsgcHJvdmlkZXJzIGZvciBwZWVyaW5nIGFu ZCBjcm9zcy1kaXNjb3ZlcnkuDQpCdXQgSSBkbyBzZWUgdmFsdWUgaW4gYSBuZXcganNvbi1iYXNl ZCBBUEkvZW5kcG9pbnQgZm9yIG90aGVyIHVzZSBjYXNlcyBhbmQgYW0gd2lsbGluZyB0byBoZWxw LiBOb3RlIHRoYXQgdGhpcyBjb3VsZCBhY3R1YWxseSBiZSB2aWV3IGFzIHN0YW5kYXJkaXppbmcg dGhlICdMcmRkJyBlbmRwb2ludCA6KSAoYWx0aG91Z2gganNvbi1vbmx5KSBzbyBJIHN0aWxsIHNl ZSBpdCBzb21laG93IGNvbXBhdGlibGUgd2l0aCB0aGUgZXhpc3RpbmcgNjQxNSBmcmFtZXdvcmsu Li5pZiB3ZSBuYW1lIHRoZSBlbmRwb2ludCAud2VsbC1rbm93bi9scmRkIHdlIGV2ZW4gYXZvaWQg dGhlIHdmL3N3ZCBuYW1lIGJhdHRsZSA7KQ0KDQpNb3Zpbmcgb24gdG93YXJkcyBvcHRpb24gMiwg SSBkbyBoYXZlIHN0aWxsIHRoZSBmb2xsb3dpbmcgY29uY2VybnM6DQotIHdvdWxkIHRoZSB3aG9s ZSBhY3Rpdml0eSBhbnl3YXkgYmVuZWZpdCBmcm9tIHNsaWdodGx5IHVwZGF0aW5nIDY0MTUgaW4g cGFyYWxsZWwgb2YgdGhlIHdmIGFjdGl2aXR5IGVnIHRvIGNhbGwganJkIG91dCBvZiBhIHNpbXBs ZSBhcHBlbmRpeCBmb3IgYSBjbGVhbmVyIHJlZmVyZW5jZSAocG90ZW50aWFsbHkgYWxzbyBieSBv dGhlciBzcGVjcyBpbiB0aGUgZnV0dXJlKSwgYW5kIG1heWJlIHdpdGggb3RoZXIgdGhpbmdzIGFz IHdlbGwgc3VjaCBhcyBjb3JzIG9yIGVsc2U/IFdoYXQgaXMgdGhlIHZpZXcgb2YgdGhlIGF1dGhv cnMgb2YgNjQxNT8NCg0KLSBJIHN0aWxsIHNlZSB0aGF0IHRoZSBtb3N0IHJlbGV2YW50IHVzZSBj YXNlcyBkaXNjdXNzZWQgb3ZlciB0aGUgbGFzdCBtb250aHMgYXJlIGFjdHVhbGx5IG1pc3Npbmcg ZnJvbSB0aGUgdGV4dC4gRnNuLCBvcGVuaWQgY29ubmVjdCwgYXV0byBjb25maWd1cmF0aW9uICYg J2NvbnRhY3QgZW5yaWNobWVudCcgYXJlIDQgbWFpbiB1c2UgY2FzZXMgd2l0aCB2ZXJ5IGRpZmZl cmVudCBuZWVkcyB0aGF0IHdvdWxkIGRlc2VydmUgYmVpbmcgbWVudGlvbmVkIGV4cGxpY2l0bHku DQoNCkFzIGEgc2lkZSBjb21tZW50LCBJIG1heSBiZSB0b28gb3B0aW1pc3RpYy9xdWljayBidXQg SSdkIGFsc28gbGlrZSB0byB3b3JrIHdpdGggd2hvZXZlciBpcyBpbnRlcmVzdGVkIGF0IGFuYWx5 emluZyBsaW5rIHJlbHMgcmVsZXZhbnQgZm9yIHRoZSBmc24gdXNlIGNhc2UgaW4gcGFydGljdWxh ciBhbmQgcG9zc2libHkgaGF2ZSBzb21lIG9mIHRoZW0gcmVnaXN0ZXJlZCBpZiBtaXNzaW5nIHRv IHBhdmUgdGhlIHdheSBmb3IgaW50ZXJvcGVyYWJpbGl0eS4NCg0KV2FsdGVyDQoNCkxlIDMgbm92 LiAyMDEyIMOgIDA3OjUwLCAiUGF1bCBFLiBKb25lcyIgPHBhdWxlakBwYWNrZXRpemVyLmNvbTxt YWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tPj4gYSDDqWNyaXQgOg0KV2FsdGVyLCBldCBhbCwN Cg0KKEFwb2xvZ2l6ZXMgZm9yIHRoZSBsZW5ndGgsIGJ1dCBJIHRoaW5rIHdlIGhhdmUgYW4gaW1w b3J0YW50IGRpcmVjdGlvbmFsIGRlY2lzaW9uIHRvIG1ha2XigKYpDQoNCkkgdGhpbmsgZG93biBi ZWxvdyB5b3Ugc3VtbWFyaXplZCB0aGUgc2l0dWF0aW9uIHByZXR0eSB3ZWxsLiAgV2hpbGUgZ2Vu ZXJhbGl6aW5nLCB3aGF0IEkgdGhpbmsgd2UgaGF2ZSBhcmUgdHdvIGRpZmZlcmVudCBjYW1wcy4g IFRoZXJlIGFyZSB0aG9zZSB3aG8gaGF2ZSBhIHByZWZlcmVuY2UgZm9yIFJGQyA2NDE1IGFzIGl0 4oCZcyBkZWZpbmVkIHRvZGF5LiAgVGhlcmUgYXJlIGEgbGlzdCBvZiBwZW9wbGUgd2hvIHNhaWQg dGhleSBsaWtlIHRoZSBob3N0LW1ldGEgYXBwcm9hY2ggd2l0aCBob3N0LXNwZWNpZmljIGFuZCB0 aGVuIHNlcGFyYXRlIHJlc291cmNlLXNwZWNpZmljIGluZm9ybWF0aW9uIGFuZCB0aGUgdXNlIG9m IHRlbXBsYXRlcyAobm90YWJseSB0aGUgb25lIGZvciBMUkREKS4gIFRoZW4gdGhlcmUgaXMgdGhl IGdyb3VwIHdobyBkb2VzIG5vdC4gIFRoZXkganVzdCB3YW50IHRvIGlzc3VlIGEgc2luZ2xlIHF1 ZXJ5IGFuZCBnZXQgYmFjayBhIHNpbmdsZSByZXNwb25zZS4gIFRoZSBsYXR0ZXIgZ3JvdXAgZG8g bm90IGxpa2UgdGVtcGxhdGVzIGFuZCBkbyBub3Qgd2FudCB0byBtYWtlIHR3byByZXF1ZXN0cy4g IE9oLCBhbmQgdGhleSBkbyBub3QgY2FyZSBvbmUgd2F5IG9yIHRoZSBvdGhlciBhYm91dCBwcmVz ZXJ2aW5nIGJhY2t3YXJkLWNvbXBhdGliaWxpdHkgd2l0aCBSRkMgNjQxNS4gIChOb3csIG15IHN0 YXRlbWVudHMgYWJvdXQgdGhlIHR3byBjYW1wcyBpcyBhIGdlbmVyYWxpemF0aW9uLCBhIEkgc2Fp ZCBhdCB0aGUgb3V0c2V0LCBhbmQgdGhlcmUgYXJlIG9waW5pb25zIHRoYXQgY3Jvc3MgYm91bmRh cmllcywgYnV0IHRoaXMgaXMgdGhlIGNsZWFuZXN0IGRpdmlzaW9uIEkgY2FuIHNlZSBmb3IgdGhl IHB1cnBvc2VzIG9mIGRpc2N1c3Npb24uKQ0KDQpXaGF0IEnigJl2ZSB0cmllZCB0byBkbyBpcyBk ZWZpbmUgYSBzb2x1dGlvbiB0aGF0IHdvdWxkIGFsbG93IGZvciBhIHNpbmdsZSByZXF1ZXN0L3Jl c3BvbnNlLCBidXQgd291bGQgbWFpbnRhaW4gYSBoaWdoLWRlZ3JlZSBvZiBpbnRlcm9wZXJhYmls aXR5IGJldHdlZW4gdGhpcyBuZXcgZG9jdW1lbnQgYW5kIDY0MTUuICBBcyBJIHdhcyBtYWtpbmcg Y2hhbmdlcyB0byB0aGUgZHJhZnQgYW5kIHRyeWluZyB0byB0YWtlIGlucHV0LCBJIHdhcyB0cnlp bmcgdG8gdGhpbmsgdGhyb3VnaCBob3cgSSBjb3VsZCBwcm9kdWNlIGEgc29sdXRpb24gdG8gbWVl dCB0aGUgcmVxdWlyZW1lbnRzIHdpdGhvdXQgYSBob3N0LW1ldGEgc2VydmVyIG1vZGlmaWVkIGlu IGFueSB3YXksIGV4Y2VwdCBmb3IgdGhlIGFkZGl0aW9uIG9mIOKAnHJlc291cmNl4oCdIGFuZCBK UkQgc3VwcG9ydC4gIElnbm9yaW5nIHRoZSBlZGl0b3JpYWwgaW1wcm92ZW1lbnRzIHRoYXQgY291 bGQgYmUgbWFkZSwgSSB0aGluayB0aGUgY3VycmVudCBBTFQtUjEgZHJhZnQgZG9lcyB0aGF0Lg0K DQpZb3UgYXJlIGVudGlyZWx5IGNvcnJlY3QgdGhhdCB0aGlzIHNwZWMgaXMgbG9va2luZyBtb3Jl IGxpa2UgU1dELiAgVGhlcmUgYXJlIHNvbWUgdmVyeSBpbXBvcnRhbnQgZGlzdGluY3Rpb25zLCB0 aG91Z2guICBGb3Igb25lLCBTV0QgcmV0dXJucyBhIHNpbmdsZSBsaW5rIHRvIGEgc2luZ2xlIHJl cXVlc3QuICBJdCBtYWtlcyBkaXNjb3ZlcmluZyBsb3RzIG9mIGluZm9ybWF0aW9uIGFib3V0IHNv bWVib2R5IGEgcGFpbiwgSU1PLiAgSXTigJlzIHByaW1hcnkgcHVycG9zZSB3YXMgdG8gc3VwcG9y dCBPcGVuSUQgQ29ubmVjdCBhbmQgaXQgd29ya3MgZmluZSBmb3IgdGhhdCwgYnV0IGlmIEkgd2Fu dCB0byBhc2sgYSBzZXZlciB0byDigJx0ZWxsIG1lIGV2ZXJ5dGhpbmcgeW91IGtub3cgYWJvdXQg UGF1bCBKb25lc+KAnSwgaXQgY2Fubm90LiAgUkZDIDY0MTUgY2FuLCBhbmQgSSBsaWtlIHRoYXQu ICBUaGUgZGlmZmVyZW5jZSBpcyByZWFsbHkgYSBtYXR0ZXIgb2YgdGhlIGRvY3VtZW50IHJldHVy bmVkLiAgQWxzbywgdGhlcmUgaXMgYXBwbGljYXRpb24tbGV2ZWwga2luZCBvZiByZWRpcmVjdCBp biBTV0QgKG9yIHdhcykgdGhhdCByZWFsbHkgc2hvdWxkIGJlIGFuIEhUVFAtbGV2ZWwgKDN4eCku ICBJIGRvbuKAmXQgbGlrZSB0aGF0IGFib3V0IFNXRCwgZWl0aGVyLg0KDQpCYWNrIHRvIHRoZSB0 d28gY2FtcHM6IG5laXRoZXIgaXMgaGFwcHkgd2l0aCB0aGUgcHJlc2VudCBzb2x1dGlvbiAodGhl IC0wMiBkcmFmdCkuICBQZW9wbGUgd2hvIGxpa2UgdGhlIHNpbmdsZSByZXF1ZXN0IGFwcHJvYWNo IGxpa2UgdGhpcyBBTFQgZHJhZnRzIGJldHRlciBiZWNhdXNlIFhNTCBpcyBnb25lLCB0aGVyZSBp cyBhIHNpbmdsZSByZXNvdXJjZSB0byBnbyBxdWVyeSwgYW5kLCBvZiBjb3Vyc2UsIHRoZXJlIGlz IGEgc2luZ2xlIHJlcXVlc3QvcmVzcG9uc2UuICBQZW9wbGUgd2hvIGFyZSBpbiB0aGUgNjQxNSBj YW1wIGRvIGFyZSBub3QgaGFwcHkgd2l0aCB0aGUgLTAyIGRyYWZ0IGJlY2F1c2Ugd2UgdHVybiDi gJxob3N0IG1ldGFkYXRh4oCdIGludG8g4oCccmVzb3VyY2XigJ0gaW5mb3JtYXRpb246IHdlIG1l cmdlIHRoZSBjb25jZXB0cy4gIFRoZXkgYWxzbyBkbyBub3QgbGlrZSB0aGUgQUxUIGRyYWZ0cyBm b3IgdGhlIHNhbWUgcmVhc29uLiAgSG93ZXZlciwgZXZlbiB0aGUgNjQxNSBjYW1wIGRvZXMgc2Vl bSB0byBoYXZlIGFuIGFwcHJlY2lhdGlvbiBmb3IgYSByZXNvdXJjZS1jZW50cmljIGFwcHJvYWNo IHRoYXQgY2FuIHVzZSBhIHNpbmdsZSBxdWVyeS4gIFRoZXkganVzdCBkb27igJl0IGxpa2UgdGhl IOKAnGhhY2vigJ0gKG15IHRlcm3igKYgdGhhdOKAmXMgdGhlIG9uZSBuZWdhdGl2ZSB3b3JkIEkg ZG9u4oCZdCB0aGluayBJ4oCZdmUgaGFkIHRocm93biBpbiBteSBmYWNlIDstKSApLg0KDQpJIGJl bGlldmUgeW91IGFyZSByaWdodCB0byBwb2ludCBvdXQgdGhhdCB0aGUgb25lIHRoaW5nIHBlb3Bs ZSBzZWVtIHRvIGJlIGdlbmVyYWxseSBPSyB3aXRoIGlzIEpSRC4gIEkgdGhpbmsgaXTigJlzIGEg c2ltcGxlIGZvcm1hdCwgbmljZSB0byB3b3JrIHdpdGgsIHVzZWZ1bCwgYW5kIG5vdCBvdmVybHkg Y29tcGxpY2F0ZWQuICBHaXZlbiB0aGF0IHRoZXJlIGFyZSB2aXJ0dWFsbHkgbm8gY29tbWVudHMg b24gdGhlIGZvcm1hdCwgSSBnYXRoZXIgcGVvcGxlIHNoYXJlIHRoZSBzYW1lIHNlbnRpbWVudC4N Cg0KTm93LCBoYXZpbmcgaGFkIGNvbnZlcnNhdGlvbnMgd2l0aCBhIG51bWJlciBvZiBwZW9wbGUg Ym90aCBvbiB0aGUgbGlzdCBhbmQgb2ZmLCBJIGJlbGlldmUgd2UgbmVlZCB0byBkZWNpZGUgd2hp Y2ggZGlyZWN0aW9uIHRvIHRha2UgYW5kIEkgdGhpbmsgdGhlcmUgYXJlIHR3byBjaG9pY2VzOg0K DQoxKSAgICAgIFdlIGRpc2NhcmQgdGhlIGN1cnJlbnQgV2ViRmluZ2VyIGRyYWZ0IGFuZCBjb250 aW51ZSB3aXRoIFJGQyA2NDE1IGFzLWlzDQoNCjIpICAgICAgV2UgcmUtd3JpdGUgdGhlIHNwZWMg aW4gdGhlIHNwaXJpdCBvZiB0aGUgQUxUIHZlcnNpb25zLCBjb21wbGV0ZWx5IGJyZWFraW5nIGF3 YXkgZnJvbSBSRkMgNjQxNSBieQ0KDQphLiAgICAgICBSZW1vdmluZyBhbGwgcmVmZXJlbmNlcyB0 byBhbmQgZGVwZW5kZW5jaWVzIG9uIFJGQyA2NDE1DQoNCmIuICAgICAgRGVmaW5pbmcgSlJEIHdp dGhpbiB0aGUgV2ViRmluZ2VyIHNwZWMsIHNwZWNpZnlpbmcgc3VjaCB0aGluZ3MgYXMg4oCcdGhl IG9yZGVyIG9mIGxpbmsgcmVsYXRpb25zIGlzIHNpZ25pZmljYW504oCdIG9yIG90aGVyIHJ1bGVz IHdlIHdhbnQgdG8gYXBwbHkgdG8gdGhlIGRvY3VtZW50DQoNCmMuICAgICAgIERlZmluaW5nIGEg bmV3IHJlc291cmNlIGZvciB0aGlzIHNlcnZlciBhdCAvLndlbGwta25vd24vd2ViZmluZ2VyIChv ciBzd2QgPykNCg0KZC4gICAgICBVc2luZyBubyB0ZW1wbGF0ZXMgd2hhdHNvZXZlcg0KDQplLiAg ICAgIFVzaW5nIHRoZSDigJxyZXNvdXJjZeKAnSBwYXJhbWV0ZXIgYXMgdGhlIGN1cnJlbnQgQUxU IGRyYWZ0IGhhcyB0aGVtICh0aGUgY29uY2VwdCBvZiDigJxob3N0IG1ldGFkYXRh4oCdIGRvZXMg bm90IGV4aXN0IHdpdGggdGhpcyBkcmFmdDsgSeKAmW0gbm90IHN1cmUgd2hhdCB0aGUgc2VydmVy IHNob3VsZCBkbyBpZiB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIGlzIGFic2VudCwgdGhvdWdoKQ0K DQpmLiAgICAgICAgKEkgd291bGQgc2F5IHVzZSB0aGUg4oCccmVs4oCdIHBhcmFtZXRlciwgdG9v LCBidXQgc29tZSBoYXZlIHJlYWxseSBleHByZXNzZWQgZGlzc2F0aXNmYWN0aW9uIHdpdGggdGhh dC4gIFdoaWxlIEkgdGhpbmsgaXTigJlzIHdvbmRlcmZ1bCBpbiBvcmRlciB0byByZWR1Y2UgdGhl IG51bWJlciBvZiBsaW5rIHJlbGF0aW9ucyByZXR1cm5lZCwgc29tZSBqdXN0IHNhdyBubyB2YWx1 ZSBpbiB0aGF04oCmIGV2ZW4gb24gbmFycm93LWJhbmQgbmV0d29yayBjb25uZWN0aW9ucy4pDQoN CklmIEkgdW5kZXJzdGFuZCB0aGUgdHdvIGNhbXBzLCBJIHRoaW5rIHRob3NlIGFyZSB0aGUgdHdv IG9wdGlvbnMgYmVmb3JlIHVzLiAgSeKAmW0gc3VyZSB0aGVyZSBtYXkgYmUgb3RoZXIgdGhpbmdz IHRvIGRvIGZvciBvcHRpb24gMiwgYnV0IHlvdSBnZXQgdGhlIGdpc3Qgb2Ygd2hlcmUgdGhhdCBp cyBoZWFkZWQuDQoNCk1vcmUgaW1wb3J0YW50bHksIEkgYW0gbGVmdCB3aXRoIHRoZSBpbXByZXNz aW9uIHRoYXQgaWYgd2UgZG8gZ28gd2l0aCBvcHRpb24gMiwgd2Ugd2lsbCBnZXQgc3VwcG9ydCBm cm9tIGJvdGggY2FtcHMuICBTb21lIG9mIHRob3NlIHdobyBhcmUgaW4gdGhlIDY0MTUgY2FtcCBq dXN0IGhhdmUgYW4gb2JqZWN0aXZlIG9mIG5vdCBicmVha2luZyB3aGF0IGlzIHRoZXJlIG5vdyBh bmQgc29tZSBqdXN0IGRvbuKAmXQgd2FudCB0aGUg4oCcaGFja+KAnSB0aGF0IGlzIHRoZSBjdXJy ZW50IFdGIHNwZWMuICBCdXQsIEkgYmVsaWV2ZSBtb3N0IGFyZSBhbGwgZm9yIGEgY2xlYW4gc3Bl Y2lmaWNhdGlvbiB0aGF0IGRlZmluZXMgYSB1c2VmdWwgc2VydmljZSBhbmQgdGhhdCB1dGlsaXpl cyBKUkQgdG8gcHJvdmlkZSBhIHNldCBvZiBsaW5rIHJlbGF0aW9ucyBhYm91dCBhIHJlc291cmNl OyBhIHVzZWZ1bCDigJx3ZWIgZGlzY292ZXJ5IHByb3RvY29s4oCdLg0KDQpJIGp1c3Qgd2FudCBh IHNvbHV0aW9uIGFuZCB3b3VsZCBub3QgYmUgdXBzZXQgd2l0aCBlaXRoZXIgc29sdXRpb24uICBX aGF0IEkgZG8gbm90IGxpa2UsIHRob3VnaCwgaXMgaGF2aW5nIHR3byBvciB0aHJlZSBzb2x1dGlv bnMgZm9yIGRpc2NvdmVyeS4gIEF0IHByZXNlbnQsIHdlIGhhdmUgUkZDIDY0MTUsIGN1cnJlbnQg V0YgZHJhZnQsIFNXRCwgYW5kICBkcmFmdC1kYWJvby1hZ3JlZ2dhdGVkLXNlcnZpY2UtZGlzY292 ZXJ5LiAgVGhhdOKAmXMgYSBmZXcgdG9vIG1hbnkgOy0pDQoNCkkgZG8gaGF2ZSBhIGhpZ2ggb3Bp bmlvbiBvZiBYUkQvSlJELCBzbyBJIHdvdWxkIGxpa2UgdG8gc2VlIGVpdGhlciBvciBib3RoIG9m IHRob3NlIHJldGFpbmVkIGluIGFueSBzb2x1dGlvbiB0aGUgZ3JvdXAgcHJvZHVjZXMuDQoNCkdp dmVuIHRoYXQgU1dEIGV4aXN0cywgSSB0YWtlIGl0IHRoYXQgdGhlcmUgaXMgYXQgbGVhc3QgZW5v dWdoIHN1cHBvcnQgdG8gZG8gc29tZXRoaW5nIG90aGVyIHRoYW4gUkZDIDY0MTUuIEkgZG8gbm90 IGZ1bGx5IHVuZGVyc3RhbmQgdGhlIHJlYXNvbnMsIGV4Y2VwdCBwZXJoYXBzIOKAnHdlIHdhbnQg b25lIHJvdW5kIHRyaXDigJ0uIEkgZG9u4oCZdCBrbm93LiAgUGVyaGFwcyBzb21lb25lIGNhbiBl ZHVjYXRlIG1lIG9uIHRoZSDigJx3aHnigJ0uICBCdXQsIGl0IGRvZXMgZXhpc3QsIHNvIHRoZXJl IGlzIGEgcmVhc29uIGFuZCBpdCBtZWFucyB3ZSBtaWdodCBlbmQgdXAgd2l0aCB0d28gc29sdXRp b25zLg0KDQpTbywgY2FuIHdlIGF2b2lkIHRoYXQ/ICBJ4oCZZCBiZSBvayB3aXRoIHB1dHRpbmcg YXNpZGUgdGhlIFdGIHNwZWMgaW4gZmF2b3IgYSBtZXJnZXIgYmV0d2VlbiBTV0QvV0YuICBJIGRv buKAmXQgd2FudCB0byBjYWxsIHRoaXMgYSDigJxjb21wcm9taXNl4oCdLCBidXQgcmF0aGVyIGEg Y2xlYW4gc29sdXRpb24gdGhhdCBib3Jyb3dzIGZyb20gYm90aDogc2luZ2xlIHJvdW5kIHRyaXAg KGxpa2UgU1dEKSwgYSByaWNoZXIgcmVzcG9uc2Ugd2l0aCBhIHNldCBvZiBsaW5rcyAoSlJEKSwg YWRoZXJlcyB0byBhbmQgZm9sbG93cyBIVFRQIHByb2NlZHVyZXMgKGUuZy4sIG5vIOKAnFNXRF9z ZXJ2aWNlX3JlZGlyZWN04oCdIHR5cGUgY29uc3RydWN0OyB1c2UgM3h4KSwgaGFzIG5vIHRlbXBs YXRlcyBpbiB0aGUgSlJELCBhbGxvd3MgYW55IFVSSSB0eXBlIChpbmNsdWRpbmcg4oCcYWNjdDri gJ0pIGFzIHRoZSDigJxzdWJqZWN04oCdIG9mIHRoZSBxdWVyeSwgYW5kIGlzIHJvb3RlZCBhdCB0 aGUgaG9zdCBhdCBzb21lIGFncmVlZCBsb2NhdGlvbiBsaWtlIC8ud2VsbC1rbm93bi9zd2QuDQoN CkkgYmVsaWV2ZSBpZiB3ZSBkbyB0aGlzLCB3ZSBoYXZlIHRoZSBncmVhdGVzdCBjaGFuY2Ugb2Yg Z2V0dGluZyB0aGUgbGFyZ2VzdCBudW1iZXIgb2YgcGVvcGxlIG9uIGJvYXJkLiAgUGVyaGFwcyBN aWtlIG9yIHNvbWVvbmUgc2VydmUgYXMgZWRpdGluZywgYnV0IEnigJlkIGJlIGhhcHB5IHRvIGhl bHAgY28tYXV0aG9yLiAgSeKAmWxsIGFsc28gd3JpdGUgYW4gaW1wbGVtZW50YXRpb24gYXMgSSBk aWQgZm9yIFJGQyA2NDE1OyBpdCBzaG91bGQgYmUgc2ltcGxlIHRvIGRvLg0KDQpJbiBhbnkgY2Fz ZSwgSSBkbyB0aGluayB0aGVyZSBpcyBhIHNlcmlvdXMgcmlzayBvZiBmYWlsdXJlIGlmIHdlIGNv bnRpbnVlIGRvd24gdGhlIGN1cnJlbnQgV0YgcGF0aCwgZWl0aGVyIGJlY2F1c2Ugd2UgZW5kIHVw IHdpdGggbXVsdGlwbGUgY29tcGV0aW5nIHNvbHV0aW9ucyBvciBiZWNhdXNlIHdlIGFsaWVuYXRl IG9uZSBvZiB0aGUgdHdvIGNhbXBzLiAgU28gd2UgZWl0aGVyIHN0aWNrIHdpdGggNjQxNSBhbmQg c3RvcCBzcGVuZGluZyB0aW1lIG9uIHRoaXMsIG9yIGNyZWF0ZSBzb21ldGhpbmcgYWxvbmcgdGhl IGxpbmVzIG9mICgyKSB3aGVyZSB3ZSBjYW4gZ2V0IG5lYXJseSBldmVyeW9uZSBvbiBib2FyZC4N Cg0KUGF1bA0KDQpGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YXBw cy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHb2l4IExhdXJlbnQgV2FsdGVyDQpTZW50OiBGcmlkYXks IE5vdmVtYmVyIDAyLCAyMDEyIDExOjMwIEFNDQpUbzogRXZhbiBQcm9kcm9tb3U7IGFwcHMtZGlz Y3Vzc0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnPg0KU3ViamVjdDogW2Fw cHMtZGlzY3Vzc10gUjogSGlnaC1sZXZlbCBjb25zaWRlcmF0aW9ucyBhYm91dCAid2ViZmluZ2Vy Ig0KDQpIaSBldmFuLA0KDQpJIGRvIGhhdmUgcmVhZCB0aGUgbGF0ZXN0IGFsdC1yMSBkcmFmdC4g QnV0IEkgZG8gYmVsaWV2ZSB0aGVzZSBhcmUgc3RpbGwgYXBwbGljYWJsZSBxdWVzdGlvbnM6DQoN Ci0gICAgICAgICAgSSBjb3VsZCBzdGlsbCBzZWUgcHJvcy9jb25zIGluIHRoZSBsaXN0IGZvciBy ZWwvcmVzb3VyY2UgcGFyYW1ldGVycyBpbiBob3N0LW1ldGEuanNvbg0KDQotICAgICAgICAgIFRo ZSBxdWVzdGlvbiBvZiBjcmVhdGluZyBhIG5ldyBlbmRwb2ludCBoYXMgYmVlbiByYWlzZWQgYW5k IHN0aWxsIHBlbmRpbmcgaW1vIChhbHNvIHdydCBwcmV2aW91cyBidWxsZXQpDQoNCi0gICAgICAg ICAgUmVsYXRpb25zaGlwIHdpdGggcmZjNjQxNSBpcyBzdGlsbCBub3QgY2xlYXIgYXMgc29tZSBw YXJ0cyBhcmUgY2xlYXJseSByZWZlcmVuY2VkIChtb3N0bHkgcHJvY2VkdXJlcykgd2hpbHN0IG90 aGVycyBtZW50aW9uIGEgY2xlYXIgZGlzdGFuY2Ugd2l0aCBpdCAoZWcgeHJkIHZzIGpyZCkuIEFz IGEgZGV2ZWxvcGVyIEkgY291bGQgbm90IGtub3cgdmVyeSB3ZWxsIHdoZXRoZXIgSSBuZWVkIHRv IGltcGxlbWVudCByZmM2NDE1IGFuZCBob3cgbXVjaCBvZiBpdOKApmF0IHRoaXMgcG9pbnQgb25l IG1heSBjb25zaWRlciBob3cgbXVjaCB0aGUgZHJhZnQgZ2FpbnMgaW4gYWN0dWFsbHkgcmVmZXJl bmNpbmcgdGhvc2Ugc2VjdGlvbnMgaWYgaXQgaXMgdG8gbWFuZGF0ZSB0aGUgY29udHJhcnnigKYN Cg0KbyAgIEluIHNlY3Rpb24gMyBpdCByZWFkcyDigJx0aGUgcHJvdG9jb2wgYnVpbGRzIG9uIHJm YzY0MTXigJ0sIHdoaWNoIGlzIHZlcnkgdW5jbGVhciB0byB3aGljaCBleHRlbnQNCg0KbyAgIFNl Y3Rpb24gNSB0YWxrcyBhYm91dCBiYWNrd2FyZC1jb21wYXRpYmlsaXR5IGJ1dCBiYXNpY2FsbHkg c2F5cyBpdCDigJxtYXkgbm90IGJl4oCdLiBUaGlzIGlzIG1haW5seSB0byByZXVzZSBqcmQgYW5k IOKAnGhvc3QtbWV0YS5qc29u4oCdIHNvIGl0IG1heSBiZSBtb3JlIGFwcHJvcHJpYXRlIHRvIGNh bGwgdGhlbSBvdXQgZXhwbGljaXRseSB3aXRob3V0IGFueSBnZW5lcmljIHNlbnRlbmNlIChzdGls bCBpZiB0aGlzIGlzIHRoZSBmZWVsaW5nIG9mIHRoZSBncm91cCkNCg0KbyAgIFNlY3Rpb24gNS4x IHJlZmVyZW5jZXMgc2VjdGlvbiA0LjIgb2YgcmZjNjQxNSBidXQgYWN0dWFsbHkgaW50cm9kdWNl cyBzb21lIHZhcmlhbnRzLCBzbyB3aHkgbm90IHdyaXRlIGEgY2xlYW4gc3RhbmRhbG9uZSB0ZXh0 IHdpdGggbm8gcmVmZXJlbmNlIHRvIHJmYzY0MTU/DQoNCm8gICBTZWN0aW9uIDUuMiByZWZlcmVu Y2VzIGFuIOKAnGV4YW1wbGXigJ0gb2YgcmZjNjQxNSBzZWN0aW9uIDEuMS4xLCBidXQgdGhlIHZh bHVlIG9mIHRoYXQgcmVmZXJlbmNlIGlzIG5vdCBjbGVhci4gQmV0dGVyIHByb2JhYmx5IHRvIHJl ZmVyZW5jZSB3ZWJmaW5nZXLigJlzIG93biBleGFtcGxlcy4NCg0KLSAgICAgICAgICB0aGUgdmVy eSBsYXRlc3QgZHJhZnQgaXMgc3RpbGwgYWwg4oCcQUxU4oCdIGF0IHRoaXMgc3RhZ2XigKYNCg0K SeKAmW0gcGxheWluZyB0aGUgZGV2aWzigJlzIGFkdm9jYXRlIGhlcmUgYnV0IGRvIHRoaW5rIHRo YXQgdGhlIHZhcmlvdXMgY2FtcHMgaW50ZW5kIHZlcnkgZGl2ZXJzZSB1c2FnZXMgb2Ygd2ViZmlu Z2VyIHRoYXQgbWF5YmUgZG8gbm90IGJlbmVmaXQgb2Ygb25lIHNvbHV0aW9uLiBJdCBpcyBhIHBp dHkgdGhvc2UgdXNlIGNhc2VzIGFyZSBub3QgcmVmbGVjdGVkIGluIHRoZSBzaW1wbGlzdGljIGV4 YW1wbGVzOiBJIHBlcnNvbmFsbHkgbGlrZWQgdGhlIG9wZW5pZCBvbmUgYXMgSSB0aGluayBvcGVu ZWQgY29ubmVjdCB3b3VsZCBiZSAxIGNhbmRpZGF0ZSwgYnV0IEnigJl2ZSBoZWFyZCBhYm91dCBh dXRvY29uZmlndXJhdGlvbiAoc2VlIG9hdXRoIHVzZSBjYXNlKSBhbmQgZmVkZXJhdGVkIHNvY2lh bCBuZXR3b3JrcyAodGhlIHdob2xlIG9yaWdpbmFsIHBvaW50IG9mIGl0KS4gQWxsIG9mIHRoZW0g YXJlIHVzZWQgaW4gdmVyeSBkaWZmZXJlbnQgY29udGV4dHMgKHRydXN0ZWQvdW50cnVzdGVkLCBp bnRyYS0vaW50ZXItZG9tYWluKSBhbmQgd2lsbCBwcm9iYWJseSBkaXN0aW5ndWlzaCB0aGVtc2Vs dmVzIGZyb20gdGhlIGFjdHVhbCBsaW5rIHJlbHMgdGhleSB3aWxsIHVzZS9leHBvc2XigKYNCg0K d2FsdGVyDQoNCkRhOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YXBwcy1k aXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0 Zi5vcmddIFBlciBjb250byBkaSBFdmFuIFByb2Ryb21vdQ0KSW52aWF0bzogdmVuZXJkw6wgMiBu b3ZlbWJyZSAyMDEyIDE2LjA1DQpBOiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmc8bWFpbHRvOmFwcHMt ZGlzY3Vzc0BpZXRmLm9yZz4NCk9nZ2V0dG86IFJlOiBbYXBwcy1kaXNjdXNzXSBIaWdoLWxldmVs IGNvbnNpZGVyYXRpb25zIGFib3V0ICJ3ZWJmaW5nZXIiDQoNClRoZSBjb252ZXJzYXRpb24gaGFz IHJlYWxseSBtb3ZlZCBvbiEgSSBzdWdnZXN0IHlvdSByZWFkIFBhdWwgSm9uZXMncyBsYXRlc3Qg ZW1haWwgdG8gZ2V0IGNhdWdodCB1cC4NCg0KLUV2YW4NCg0KT24gMTItMTEtMDIgMDg6MDIgQU0s IEdvaXggTGF1cmVudCBXYWx0ZXIgd3JvdGU6DQpEZWFyIGFsbCwNCg0KSSB0cmllZCB0byBjYXRj aCB1cCB3aXRoIHRoZSBob3QgZGlzY3Vzc2lvbiBvZiB0aGUgbGFzdCBkYXlzIGFuZCB3b3VsZCB0 cnkgdG8gaG9sZCBvbiBmb3IgdGhlIHRpbWUgb2YgYW4gZW1haWwgdHJ5aW5nIHRvIHN1bW1hcml6 ZSB0aGUgY3VycmVudCBzaXR1YXRpb24gYW5kIHRha2UgYSBicmVhdGjigKYNCg0KQXQgdGhpcyBz dGFnZSB3ZSBhcmUgaGF2aW5nIHZlcnkgZGlzdGluY3QgY2FtcHMgaW4gdGhlIGxpc3QgZm9yIHdo YXQgdGhleSBoYXZlIGluIG1pbmQgYmVoaW5kIHRoZSDigJx3ZWJmaW5nZXLigJ0ga2V5d29yZDog eG1sIHZzIGpzb24sIDEgb3IgMiByb3VuZHRyaXBzLCBwcml2YWN5IGVjYy4gSXQgc2VlbXMgdG8g bWUgdGhhdCBQYXVsIGhhcyBiZWVuIGRvaW5nIGFuIG91dHN0YW5kaW5nIHdvcmsgdHJ5aW5nIHRv IGNvbXByb21pc2UgKEkgd291bGQgaGF2ZSBsb3N0IHBhdGllbmNl4oCmKSBidXQgc3VjaCBjb21w cm9taXNlcyBkbyBub3Qgc2VlbSB0byBzYXRpc2Z5IGFueW9uZTogYWN0dWFsbHksIGNvbXByb21p c2VzIGFyZSBtb3ZpbmcgbW9yZSBhbmQgbW9yZSB0b3dhcmRzIHRoZSBvcmlnaW5hbCBTV0QgaWRl YSBhdCB0aGUgZW5kLg0KDQpNYXliZSB3ZSBjb3VsZCBhc2sgb3Vyc2VsdmVzIHRoZSBmb2xsb3dp bmcgcXVlc3Rpb25zOg0KDQotICAgICAgICAgIFdpdGggdGhlIOKAnHhyZOKAnSBpZGVhIGluIG1p bmQgKHBsZWFzZSwganJkLWVudGh1c2lhc3RzLCB0cnkgdG8gcHV0IHRoYXQgaGF0IG9uIGFzIHdl bGwpLCB3aGF0IGlzIGFjdHVhbGx5IG1pc3NpbmcgYmV5b25kIHJmYzY0MTUgZm9yIOKAnHdlYmZp bmdlcuKAnT8gbm93IHRoZSDigJhhY2N04oCZIFVSSSBpcyBhIHNlcGFyYXRlIGRyYWZ0IChhbiBp bml0aWFsIG1vdGl2YXRpb24pLiBSZWwvcmVzb3VyY2UgcGFyYW1ldGVycyBmb3IgeHJkIHN1cHBv cnRlcnMgZG8gbm90IHNlZW0gZXNzZW50aWFsIGluIG15IHVuZGVyc3RhbmRpbmcgbmVpdGhlci4g U28gKGFsdGhvdWdoIEkgYW0gYSBzdXBwb3J0cyBvZiB0aGF0IGNhbXApIEkgaGF2ZSB0cm91Ymxl IHNlZWluZyB3aGF0IHRydWx5IG5lZWQgdG8gYmUgYWRkZWQuIEkgY2FuIHVuZGVyc3RhbmQgRXZh buKAmXMgcG9zaXRpb24gZm9yIGtlZXBpbmcgdGhlIGVudGlyZSB4cmQtYmFzZWQgY29tbXVuaXR5 IChvc3RhdHVzLCBkaWFzcG9yYSwgZXRjKSBidXQgaXNu4oCZdCByZmM2NDE1LWNvbXBsaWFuY2Ug Zm9yIHRob3NlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBhbHJlYWR5IGZhaXIgZW5vdWdoPyBJ ZiBhIG5ldyDigJx3ZWJmaW5nZXLigJ0gaXMganJkLCAxLXJvdW5kdHJpcCBvbmx5IGF0IHRoZSBl bmQgaXTigJlzIGp1c3QgYW5vdGhlciByZmMgbnVtYmVyIHRvIGJlIHJlZmVyZW5jZWQgaW5zdGVh ZC9pbiBhZGRpdGlvbiBhbmQgYXMgc3VjaCBoYXMgdGhlIHNhbWUgdmFsdWXigKYobm90IG1lbnRp b25pbmcgdGhlIGltcGxlbWVudGF0aW9uIHdvcmsgbmVlZGVkKQ0KDQoNCg0KLSAgICAgICAgICBS ZmM2NDE1LWNvbXBsaWFuY2UgJiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5OiB0aGlzIHNlZW1zIGFs c28gY29udGVudGlvdXMgYXMgd2hldGhlciBiYWNrd2FyZC1jb21wYXRpYmlsaXR5IGlzIG5lZWRl ZCBvciBub3QuIGhvd2V2ZXIgdGhlIGN1cnJlbnQg4oCcY29tcHJvbWlzZXPigJ0gYXJlIG9kZCBp biBtYWludGFpbmluZyBiYWNrd2FyZC1jb21wYWJpbGl0eS4gV2hhdCBpcyBleGFjdGx5IGludGVy ZXN0aW5nIGZvciDigJx3ZWJmaW5nZXLigJ0gZnJvbSB0aGF0IHJmYz8gRnJvbSB0aGUgbGF0ZXN0 IGFsdGVybmF0aXZlIGl0IHNlZW1zIG9ubHkgdGhlIOKAnGhvc3QtbWV0YS5qc29u4oCdIGVuZHBv aW50IG5hbWUgJiB0aGUganJkLiBPciBlbHNlPyBIb3cgdGhlc2UgY2FuIGJlIHJlZmVyZW5jZWQg YXQgYmVzdCB3aXRob3V0IG5lZWRpbmcgdGhlIHdob2xlIHRoaW5nPw0KDQoNCg0KLSAgICAgICAg ICBIb3N0LW1ldGErbHJkZCB2cyBuZXcgZW5kcG9pbnQ6IFNob3VsZCB3ZSBwcm9wb3NlIGFuIGFs dGVybmF0aXZlIGVuZHBvaW50IG5hbWUgKHRoZXJlIHdlcmUgbWFueSBwcm9wb3NhbHMsIGluY2x1 ZGluZyBvbmUgb2YgbWluZSBhIHdoaWxlIGFnbykgc28gdGhhdCB3ZSBzaW1wbHkg4oCcZGlzdGlu Z3Vpc2jigJ0gdGhlIGV4aXN0aW5nIGhvc3QtbWV0YStscmRkIHdheSBmcm9tIGEgbmV3IOKAnHdl YmZpbmdlcuKAnSB3YXkvZW5kcG9pbnQgYWxsLWluLTEtcm91bmR0cmlwLiBUaGlzIGlzIHdoYXQg c3dkIGlzIHByb3Bvc2luZy4gRXZlbnR1YWxseSBvbmUgY291bGQgYXQgdGhlIGVuZCB1c2UgdGhl IHNhbWUgYmFja2VuZCBpbXBsZW1lbnRhdGlvbiB0byByZXR1cm4gcXVlcmllcyBjb21pbmcgYWxs IHRoZSB3YXkgZnJvbSBob3N0LW1ldGErbHJkZCB0aGFuIG90aGVycyB1c2luZyBhbm90aGVyIHdl bGwta25vd24gKGFuZCBkaXJlY3QpIGVuZHBvaW50LiBUaGlzIHdvdWxkIGFsc28gYmUgbXVjaCBl YXNpZXIgdG8gc3VwcG9ydCBhbnkgcXVlcnkgcGFyYW1ldGVyIChyZXNvdXJjZSwgcmVsLCBldGMp IGFzIHNvbWUgYXJlIGFyZ3VpbmcgYWdhaW5zdCBvdmVycmlkaW5nIGhvc3QtbWV0YSB3aXRoIHBh cmFtZXRlcnMuIEluIHRoYXQgY2FzZSB0aGUgbmV3IOKAnHdlYmZpbmdlcuKAnSB3b3VsZCBiZSBh Y3R1YWxseSBtb3JlIGxpa2UgU1dEICh3aXRoIEpSRCBzdXBwb3J0KQ0KDQoNCg0KLSAgICAgICAg ICBJbiBhbHRlcm5hdGl2ZSwgd2hhdCBhYm91dCB0aGUgcHJvdm9jYXRpdmUgaWRlYSBmcm9tIEV2 YW4gdG8g4oCccmVwbGFjZeKAnSByZmM2NDE1PyBBcmUgdGhleSBvdGhlciB1c2FnZXMgb2YgcmZj NjQxNSB0aGFuIHRoZSDigJx3ZWJmaW5nZXLigJ0gb25lIHRocm91Z2hvdXQgdGhlIGNvbW11bml0 eT8gSWYgeWVzLCB0aGVuIGl0IG1heSBiZSBtb3JlIGRpZmZpY3VsdCB0byByZXBsYWNlIHVubGVz cyBhZ3JlZWQgd2l0aCB3aG9tIGlzIHVzaW5nIGl0LiBPdGhlcndpc2UsIGFzIGl0IHNlZW1zIG1v c3QgcGVvcGxlIGRvIG5vdCBsaWtlIGl0LCB3aHkga2VlcCBpdCBhcy1pcyBhbmQgbm90IHVwZ3Jh ZGUgZGlyZWN0bHkgdG8gd2hhdGV2ZXIgaXMgbm93IHVzZWZ1bD8gQSBzdGFuZGFyZCB0aGF0IGlz IG5vdCB1c2VkIGlzIHVzZWxlc3MgYW5kIGhhcyBubyBwb2ludCBpbiBiZWluZyBzdXBlcnNlZGVk IGJ5IGEgcGFyYWxsZWwgc3BlYyBub3QgYWN0dWFsbHkgb2Jzb2xldGluZyBpdC4uLiBJZiBKUkQg YW5kIHRoZSB3ZWxsLWtub3duIGVuZHBvaW50cyBhcmUgdXNlZnVsIGluIG90aGVyIGNvbnRleHQs IHRoZW4gd2h5IG5vdCBzcGxpdHRpbmcgdGhlbSBmcm9tIHRoZSBhY3R1YWwgcHJvdG9jb2wgcHJv Y2VkdXJlcyBvZiBjdXJyZW50IHJmYzY0MTUgYW5kIGhhdmUgY2xlYW4gc3BlY3MgdGhhdCBjYW4g YmUgZ2VuZXJpY2FsbHkgcmVmZXJlbmNlZCB3aXRob3V0IGJ1eWluZyB0aGUgZnVsbCB0aGluZyBv ciB3cml0aW5nIGNvbXBsZXggdGV4dCB0byBzZWxlY3Qgc29tZSBwYXJ0cyBvZiBpdCBhbmQgY29u dGVzdCBvdGhlcnM6IDEgZm9yIEpSRCBhbmQgMSBmb3IgdGhlIGVuZHBvaW50cy9saW5rIHJlZ2lz dHJhdGlvbnMuIFRoZW4gYSBwcm90b2NvbC1vcmllbnRlZCBzcGVjIGxpa2Ugd2ViZmluZ2VyIGNh biBlYXNpbHkgZGVjaWRlIHdoYXQgdG8gdGFrZSBhbmQgcmVwbGFjZSBjdXJyZW50IHJmYzY0MTUs IG9yIGRlY2lkZSB0byBsaXZlIHNlcGFyYXRlbHkvcGFyYWxsZWwuDQoNCg0KDQoNClBlcnNvbmFs bHkgSSBoYXZlIG1vcmUgaW50ZXJlc3QgYW5kIGZlZWxpbmcgZm9yIHRoZSAyLXJvdW5kdHJpcCB4 cmQgc29sdXRpb24gZnJvbSByZmM2NDE1IHN0aWxsLiBCdXQgaWYgSSBoYXZlIHRvIGNob29zZSBi ZXR3ZWVuIGFuIG9kZC9wYXJ0aWFsL3Vuc3RhYmxlL3VuY2xlYXIvYnVnZ3kgcmVmZXJlbmNlIHRv IGl0IGFuZCBhIG5ldyBqc29uIHdheSBmb3Igc2F0aXNmeWluZyBhbm90aGVyIHVzZSBjYXNlIEkg aGF2ZSB0byBwdXQgbGltaXRzIGluIGNvbXByb21pc2luZyBhbmQgYXQgdGhpcyBwb2ludCBwcmVm ZXIgYSBwYXJhbGxlbC9pbmRlcGVuZGVudCBhcHByb2FjaC4gT2YgY291cnNlIEnigJlkIGxpa2Ug cG9zc2libHkgdG8gcmV1c2UgdGhlIGZpbGUgZm9ybWF0IChqcmQpIGFzIGl0IHNlZW1zIHN1aXRh YmxlIGZvciBhbGwuIEF0IGxlYXN0IHRoaXMgd2F5IHJmYzY0MTUgY2FuIHN0aWxsIGxpdmUgaW5k ZXBlbmRlbnRseSAoYmVpbmcgdXBkYXRlZCBvciBub3QgaWYgd2Ugd2FudCB0byBtYWtlIGl0IOKA nGNsZWFuZXLigJ0pIGFuZCDigJx3ZWJmaW5nZXLigJ0gY2FuIGhvcGVmdWxseSBiZSBmaW5hbGl6 ZWQgcXVpY2tseSBpbiB0aGUganNvbiArIDEgcm91bmR0cmlwIGRpcmVjdGlvbuKApg0KDQpPbmNl IHRoZXNlIG1hY3JvIHRvcGljcyBhcmUgY2xhcmlmaWVkIHRoZW4gd2UgY2FuIGJldHRlciBkaXNj dXNzIHRoZSBkZXRhaWxzIGFib3V0IHNlY3VyaW5nIHdmLCBzdXBwb3J0aW5nIHByaXZhY3ksIGRp c3RpbmN0IGRlbGl2ZXJ5IGZvciBhdXRoL25vbi1hdXRoIHJlcXVlc3RzIGV0Y+KApkJ1dCBjYW4g d2UgZmlyc3QgZGlzY3VzcyBhdCBoaWdoIGxldmVsIHdoYXQgd2Ugd2FudCB0byBhY2hpZXZlIGlu IHRlcm1zIG9mIHByb2Nlc3M/DQoNCkNoZWVycw0Kd2FsdGVyDQpRdWVzdG8gbWVzc2FnZ2lvIGUg aSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJz b25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlv bmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25v IHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBk b2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBp bW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBz dWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g aW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWlu ZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBl LW1haWwsIFRoYW5rcy4NCjxpbWFnZTAwMS5naWY+UmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0 YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3NhcmlvLg0KDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQphcHBzLWRpc2N1c3Mg bWFpbGluZyBsaXN0DQoNCmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNz QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMt ZGlzY3Vzcw0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJp enphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25l LCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2Vu emEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVh bG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBj b3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBt aXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0K VGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBj b250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUo cykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJv ZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5k IGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCjxpbWFnZTAwMS5n aWY+UmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDD qCBuZWNlc3NhcmlvLg0KDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29u byBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRp ZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEg Y29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0 YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3Jl IHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXpp b25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3Jh emllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBh bmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFk ZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2Ug YnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2ht ZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQpb Y2lkOjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzQFRJLkRpc2NsYWltZXJdUmlzcGV0 dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3Nh cmlvLg0KDQo= --_000_A09A9E0A4B9C654E8672D1DC003633AE53A50F6FC2GRFMBX704BA02_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYg OSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi U2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCiAvKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xv cjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJQcmVmb3JtYXR0YXRvIEhUTUwgQ2FyYXR0ZXJlIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRlc3RvIGZ1bWV0dG8gQ2FyYXR0ZXJlIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRv bTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5QcmVmb3JtYXR0YXRvSFRNTENhcmF0dGVyZQ0KCXttc28tc3R5 bGUtbmFtZToiUHJlZm9ybWF0dGF0byBIVE1MIENhcmF0dGVyZSI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcmVmb3JtYXR0YXRvIEhUTUwiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uVGVzdG9mdW1ldHRvQ2FyYXR0ZXJl DQoJe21zby1zdHlsZS1uYW1lOiJUZXN0byBmdW1ldHRvIENhcmF0dGVyZSI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXN0byBmdW1ldHRvIjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5IVE1MUHJlZm9y bWF0dGVkLCBsaS5IVE1MUHJlZm9ybWF0dGVkLCBkaXYuSFRNTFByZWZvcm1hdHRlZA0KCXttc28t c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29s YXM7DQoJY29sb3I6YmxhY2s7fQ0KcC5CYWxsb29uVGV4dCwgbGkuQmFsbG9vblRleHQsIGRpdi5C YWxsb29uVGV4dA0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IjsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5TdGlsZU1lc3NhZ2dpb0RpUG9zdGFFbGV0 dHJvbmljYTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb25vcm1hbDAN Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsO30NCnNwYW4uU3RpbGVNZXNzYWdnaW9EaVBvc3Rh RWxldHRyb25pY2EyOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5TdGlsZU1lc3Nh Z2dpb0RpUG9zdGFFbGV0dHJvbmljYTMwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LlN0aWxlTWVzc2FnZ2lvRGlQb3N0YUVsZXR0cm9uaWNhMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uU3RpbGVNZXNzYWdnaW9EaVBvc3RhRWxldHRyb25pY2EzMg0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCAyLjBjbSAyLjBjbSAyLjBjbTt9DQpk aXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQogLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K IEBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIwNzY4ODQxNzsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2MDc5NTA5ODAgLTIwNjY5OTUzNjggNjc4OTUy OTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkg Njc4OTUzMDE7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1z dG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJ e21zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6OTEzOTczNjk0Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNzA4ODUxNTggNjc2OTg3 MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIl MVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE4NzIxODYwMzg7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEwOTIzNzYxNjggLTM3ODE4OTI2 IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3 ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2 ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsNA0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3Rv cDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCm9sDQoJe21hcmdp bi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPg0KPC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+SGVsbG8gUGF1bCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q29tbWVudHMgYXMgW3dhbHRlcl08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iSVQiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjp3aW5kb3d0ZXh0Ij5EYTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiZxdW90O1Nl Z29lIFVJJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IFBh dWwgRS4gSm9uZXMgW21haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb21dDQo8YnI+DQo8Yj5JbnZp YXRvOjwvYj4gZG9tZW5pY2EgNCBub3ZlbWJyZSAyMDEyIDAuMzg8YnI+DQo8Yj5BOjwvYj4gR29p eCBMYXVyZW50IFdhbHRlcjxicj4NCjxiPkNjOjwvYj4gJ0V2YW4gUHJvZHJvbW91JzsgYXBwcy1k aXNjdXNzQGlldGYub3JnOyB3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbTsgJ01pa2UgSm9uZXMn PGJyPg0KPGI+T2dnZXR0bzo8L2I+IFJFOiBbYXBwcy1kaXNjdXNzXSBSOiBIaWdoLWxldmVsIGNv bnNpZGVyYXRpb25zIGFib3V0ICZxdW90O3dlYmZpbmdlciZxdW90OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+V2FsdGVyLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XZSBjb3VsZCB1cGRhdGUgUkZDIDY0MTUsIGJ1 dCB3ZSBzaG91bGQga2VlcCB0aGF0IGFzIGEgc2VwYXJhdGUgYWN0aXZpdHkuIFRoYXQgc2FpZCwg aXMgdGhlcmUgdHJ1bHkgYSBiZW5lZml0PyZuYnNwOyBObyBvcHBvc2l0aW9uLCBidXQgSeKAmW0g bm90IHN1cmUgaWYgdGhlcmUgaXMgYSBsb3Qgb2YgdmFsdWUgaW4gZG9pbmcgc28uPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlt3YWx0ZXJdIGl0 IGlzIHRydWx5IG1haW5seSBhaW1lZCBhdCDigJxlbGV2YXRpbmfigJ0gSlJEIHRvIGEgc3RhbmRh bG9uZSBzcGVjIHRvIGJlIG1vcmUgZWFzaWx5IHJlZmVyZW5jZWFibGUgdGhhbiBiZWluZyBuZXN0 ZWQgYXMgYSBzaW1wbGUgYXBwZW5kaXggaW4gYW5vdGhlciBpbmRlcGVuZGVudCBzcGVjLiBQbHVz IHBvdGVudGlhbCBtaW5vcg0KIHVwZGF0ZXMgaWYgbmVlZGVkLiBCdXQgbm8gYmlnIGlzc3VlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5UaGUgcmVsZXZhbmNlIG9mIHRoZSBleGFtcGxlcyB3YXMgYSBxdWVzdGlvbiB3aXRoIHRo ZSBjdXJyZW50IFdlYkZpbmdlciBkcmFmdCwgdG9vLiZuYnNwOyBJdCB3b3VsZCBiZSB1c2VmdWwg dG8gaGF2ZSByZWFsLXdvcmxkIGV4YW1wbGVzLCBJIGFncmVlLiZuYnNwOyBUaGF0IHNhaWQsIHRo ZXkgc2hvdWxkIGJlIHNpbXBsZSBvbmVzIHNvIGFzIHRvIG5vdCBsb29zZQ0KIGVmZmVjdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+W3dhbHRlcl0gYWdyZWVkLiBJIGNhbiB0cnkgdG8gcHJvdmlkZSBvbmUgZm9yIGZlZGVyYXRl ZCBzb2NpYWwgbmV0d29ya3MgZm9yIHRoZSBuZXh0IHJldmlzaW9uIGlmIHlvdS9ncm91cCB3aXNo LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5QYXVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4 dCI+IEdvaXggTGF1cmVudCBXYWx0ZXIgW21haWx0bzpsYXVyZW50d2FsdGVyLmdvaXhAdGVsZWNv bWl0YWxpYS5pdF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTm92ZW1iZXIgMDMsIDIw MTIgMTE6MjIgQU08YnI+DQo8Yj5Ubzo8L2I+IFBhdWwgRS4gSm9uZXM8YnI+DQo8Yj5DYzo8L2I+ IEV2YW4gUHJvZHJvbW91OyBhcHBzLWRpc2N1c3NAaWV0Zi5vcmc7IHdlYmZpbmdlckBnb29nbGVn cm91cHMuY29tOyBNaWtlIEpvbmVzPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbYXBwcy1kaXNj dXNzXSBSOiBIaWdoLWxldmVsIGNvbnNpZGVyYXRpb25zIGFib3V0ICZxdW90O3dlYmZpbmdlciZx dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MgUGF1 bCEgSXQgcmVtaW5kcyBtZSBvZiBhbiBlYXJseSBkaXNjdXNzaW9uIHdlIGhhZCBvbiB0aGlzIGFi b3V0IGRvY3VtZW50LW9yaWVudGVkIHZzIEFQSSBhcHByb2FjaC4gT3B0aW9uIDIsIHByb2JhYmx5 IHRoZSBiZXN0IHdheSBmb3J3YXJkLCBpcyBhIHNvcnQgb2YgQVBJLi4ud2UgY2FuIGRlZmluZSBw YXJhbWV0ZXJzIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgdGhlIGdyb3VwIHN0aWNrcyB3 aXRoIEpyZCBhbmQgdGhlIG90aGVyIGNvbnNpZGVyYXRpb25zIHlvdSBtYWRlIG9uIGh0dHAgcmVk aXJlY3RzIGV0YyBJIGRvIGd1ZXNzIHRoaXMgaXMgYSBjbGVhbiBBUEkgKG9uZSBjb3VsZCBldmVu IHRoaW5rIG9mIFBPU1QvUFVUL0RFTEVURSBmb3IgdGhpcyA6KSApLiBBbmQgaXQgbGVhdmVzIDY0 MTUgdW5jaGFuZ2VkIGFuZCB3b3JraW5nLg0KIFNvbWUgY291bGQgc2F5IHVzZWxlc3MgaWYgd2Yv c3dkIG1lcmdlciBpcyBjcmVhdGVkLCBidXQgYWN0dWFsbHkgdGhpcyB3YXkgd2UgYnVpbGQgc29t ZXRoaW5nIHBhcmFsbGVsL2luZGVwZW5kZW50IGluZGVlZCwgc28gNjQxNSBoYXMgc3RpbGwgaXRz IGRpZ25pdHkgYW5kIGlzIG5vdCBicm9rZW4gaW50byBnb29kIGFuZCBiYWQgcGFydHMuLi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBlcnNvbmFsbHks IGZvciBteSBvd24gdmlldyBvZiBmZWRlcmF0ZWQgc29jaWFsIG5ldHdvcmtzIGFuZCBteSBPTUEg aGF0IG9uLCAmbmJzcDtJIGRvIHdvdWxkIHNwb25zb3IgYW4gNjQxNS1iYXNlZCBzb2x1dGlvbiBh Y3Jvc3Mgc29jaWFsIG5ldHdvcmsgcHJvdmlkZXJzIGZvciBwZWVyaW5nIGFuZCBjcm9zcy1kaXNj b3ZlcnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJ1dCBJIGRvIHNlZSB2YWx1ZSBpbiBhIG5ldyBq c29uLWJhc2VkIEFQSS9lbmRwb2ludCBmb3Igb3RoZXIgdXNlIGNhc2VzIGFuZCBhbSB3aWxsaW5n IHRvIGhlbHAuIE5vdGUgdGhhdCB0aGlzIGNvdWxkIGFjdHVhbGx5IGJlIHZpZXcgYXMgc3RhbmRh cmRpemluZyB0aGUgJ0xyZGQnIGVuZHBvaW50IDopIChhbHRob3VnaCBqc29uLW9ubHkpIHNvIEkg c3RpbGwgc2VlIGl0IHNvbWVob3cNCiBjb21wYXRpYmxlIHdpdGggdGhlIGV4aXN0aW5nIDY0MTUg ZnJhbWV3b3JrLi4uaWYgd2UgbmFtZSB0aGUgZW5kcG9pbnQgLndlbGwta25vd24vbHJkZCB3ZSBl dmVuIGF2b2lkIHRoZSB3Zi9zd2QgbmFtZSBiYXR0bGUgOyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk1vdmluZyBvbiB0b3dhcmRzIG9wdGlvbiAyLCBJ IGRvIGhhdmUgc3RpbGwgdGhlIGZvbGxvd2luZyBjb25jZXJuczo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+LSB3b3VsZCB0aGUgd2hvbGUgYWN0aXZpdHkgYW55d2F5IGJlbmVmaXQgZnJvbSBzbGlnaHRs eSB1cGRhdGluZyA2NDE1IGluIHBhcmFsbGVsIG9mIHRoZSB3ZiBhY3Rpdml0eSBlZyB0byBjYWxs IGpyZCBvdXQgb2YgYSBzaW1wbGUgYXBwZW5kaXggZm9yIGEgY2xlYW5lciByZWZlcmVuY2UgKHBv dGVudGlhbGx5IGFsc28gYnkgb3RoZXIgc3BlY3MgaW4gdGhlIGZ1dHVyZSksIGFuZA0KIG1heWJl IHdpdGggb3RoZXIgdGhpbmdzIGFzIHdlbGwgc3VjaCBhcyBjb3JzIG9yIGVsc2U/IFdoYXQgaXMg dGhlIHZpZXcgb2YgdGhlIGF1dGhvcnMgb2YgNjQxNT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gSSBzdGlsbCBzZWUgdGhhdCB0aGUgbW9zdCByZWxl dmFudCB1c2UgY2FzZXMgZGlzY3Vzc2VkIG92ZXIgdGhlIGxhc3QgbW9udGhzIGFyZSBhY3R1YWxs eSBtaXNzaW5nIGZyb20gdGhlIHRleHQuIEZzbiwgb3BlbmlkIGNvbm5lY3QsIGF1dG8gY29uZmln dXJhdGlvbiAmYW1wOyAnY29udGFjdCBlbnJpY2htZW50JyBhcmUgNCBtYWluIHVzZSBjYXNlcyB3 aXRoIHZlcnkgZGlmZmVyZW50DQogbmVlZHMgdGhhdCB3b3VsZCBkZXNlcnZlIGJlaW5nIG1lbnRp b25lZCBleHBsaWNpdGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+QXMgYSBzaWRlIGNvbW1lbnQsIEkgbWF5IGJlIHRvbyBvcHRpbWlzdGljL3F1aWNr IGJ1dCBJJ2QgYWxzbyBsaWtlIHRvIHdvcmsgd2l0aCB3aG9ldmVyIGlzIGludGVyZXN0ZWQgYXQg YW5hbHl6aW5nIGxpbmsgcmVscyByZWxldmFudCBmb3IgdGhlIGZzbiB1c2UgY2FzZSBpbiBwYXJ0 aWN1bGFyIGFuZCBwb3NzaWJseSBoYXZlIHNvbWUgb2YgdGhlbSByZWdpc3RlcmVkIGlmIG1pc3Np bmcNCiB0byBwYXZlIHRoZSB3YXkgZm9yIGludGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPldhbHRlcjxicj4NCjxicj4NCkxlIDMgbm92LiAyMDEyIMOgIDA3OjUwLCAmcXVvdDtQ YXVsIEUuIEpvbmVzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cGF1bGVqQHBhY2tldGl6ZXIu Y29tIj5wYXVsZWpAcGFja2V0aXplci5jb208L2E+Jmd0OyBhIMOpY3JpdCZuYnNwOzo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2FsdGVyLCBldCBhbCw8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPihB cG9sb2dpemVzIGZvciB0aGUgbGVuZ3RoLCBidXQgSSB0aGluayB3ZSBoYXZlIGFuIGltcG9ydGFu dCBkaXJlY3Rpb25hbCBkZWNpc2lvbiB0byBtYWtl4oCmKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSB0aGluayBkb3duIGJlbG93IHlv dSBzdW1tYXJpemVkIHRoZSBzaXR1YXRpb24gcHJldHR5IHdlbGwuJm5ic3A7IFdoaWxlIGdlbmVy YWxpemluZywgd2hhdCBJIHRoaW5rIHdlIGhhdmUgYXJlIHR3byBkaWZmZXJlbnQgY2FtcHMuICZu YnNwO1RoZXJlIGFyZSB0aG9zZSB3aG8gaGF2ZSBhIHByZWZlcmVuY2UgZm9yIFJGQyA2NDE1IGFz IGl04oCZcyBkZWZpbmVkDQogdG9kYXkuJm5ic3A7IFRoZXJlIGFyZSBhIGxpc3Qgb2YgcGVvcGxl IHdobyBzYWlkIHRoZXkgbGlrZSB0aGUgaG9zdC1tZXRhIGFwcHJvYWNoIHdpdGggaG9zdC1zcGVj aWZpYyBhbmQgdGhlbiBzZXBhcmF0ZSByZXNvdXJjZS1zcGVjaWZpYyBpbmZvcm1hdGlvbiBhbmQg dGhlIHVzZSBvZiB0ZW1wbGF0ZXMgKG5vdGFibHkgdGhlIG9uZSBmb3IgTFJERCkuJm5ic3A7IFRo ZW4gdGhlcmUgaXMgdGhlIGdyb3VwIHdobyBkb2VzIG5vdC4mbmJzcDsgVGhleSBqdXN0IHdhbnQg dG8gaXNzdWUNCiBhIHNpbmdsZSBxdWVyeSBhbmQgZ2V0IGJhY2sgYSBzaW5nbGUgcmVzcG9uc2Uu Jm5ic3A7IFRoZSBsYXR0ZXIgZ3JvdXAgZG8gbm90IGxpa2UgdGVtcGxhdGVzIGFuZCBkbyBub3Qg d2FudCB0byBtYWtlIHR3byByZXF1ZXN0cy4mbmJzcDsgT2gsIGFuZCB0aGV5IGRvIG5vdCBjYXJl IG9uZSB3YXkgb3IgdGhlIG90aGVyIGFib3V0IHByZXNlcnZpbmcgYmFja3dhcmQtY29tcGF0aWJp bGl0eSB3aXRoIFJGQyA2NDE1LiZuYnNwOyAoTm93LCBteSBzdGF0ZW1lbnRzIGFib3V0IHRoZQ0K IHR3byBjYW1wcyBpcyBhIGdlbmVyYWxpemF0aW9uLCBhIEkgc2FpZCBhdCB0aGUgb3V0c2V0LCBh bmQgdGhlcmUgYXJlIG9waW5pb25zIHRoYXQgY3Jvc3MgYm91bmRhcmllcywgYnV0IHRoaXMgaXMg dGhlIGNsZWFuZXN0IGRpdmlzaW9uIEkgY2FuIHNlZSBmb3IgdGhlIHB1cnBvc2VzIG9mIGRpc2N1 c3Npb24uKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+V2hhdCBJ4oCZdmUgdHJpZWQgdG8gZG8gaXMgZGVmaW5lIGEgc29sdXRpb24gdGhh dCB3b3VsZCBhbGxvdyBmb3IgYSBzaW5nbGUgcmVxdWVzdC9yZXNwb25zZSwgYnV0IHdvdWxkIG1h aW50YWluIGEgaGlnaC1kZWdyZWUgb2YgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIHRoaXMgbmV3 IGRvY3VtZW50IGFuZCA2NDE1LiZuYnNwOyBBcyBJIHdhcyBtYWtpbmcNCiBjaGFuZ2VzIHRvIHRo ZSBkcmFmdCBhbmQgdHJ5aW5nIHRvIHRha2UgaW5wdXQsIEkgd2FzIHRyeWluZyB0byB0aGluayB0 aHJvdWdoIGhvdyBJIGNvdWxkIHByb2R1Y2UgYSBzb2x1dGlvbiB0byBtZWV0IHRoZSByZXF1aXJl bWVudHMgd2l0aG91dCBhIGhvc3QtbWV0YSBzZXJ2ZXIgbW9kaWZpZWQgaW4gYW55IHdheSwgZXhj ZXB0IGZvciB0aGUgYWRkaXRpb24gb2Yg4oCccmVzb3VyY2XigJ0gYW5kIEpSRCBzdXBwb3J0LiZu YnNwOyBJZ25vcmluZyB0aGUgZWRpdG9yaWFsDQogaW1wcm92ZW1lbnRzIHRoYXQgY291bGQgYmUg bWFkZSwgSSB0aGluayB0aGUgY3VycmVudCBBTFQtUjEgZHJhZnQgZG9lcyB0aGF0Ljwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WW91IGFy ZSBlbnRpcmVseSBjb3JyZWN0IHRoYXQgdGhpcyBzcGVjIGlzIGxvb2tpbmcgbW9yZSBsaWtlIFNX RC4mbmJzcDsgVGhlcmUgYXJlIHNvbWUgdmVyeSBpbXBvcnRhbnQgZGlzdGluY3Rpb25zLCB0aG91 Z2guJm5ic3A7IEZvciBvbmUsIFNXRCByZXR1cm5zIGEgc2luZ2xlIGxpbmsgdG8gYSBzaW5nbGUg cmVxdWVzdC4mbmJzcDsgSXQgbWFrZXMgZGlzY292ZXJpbmcNCiBsb3RzIG9mIGluZm9ybWF0aW9u IGFib3V0IHNvbWVib2R5IGEgcGFpbiwgSU1PLiZuYnNwOyBJdOKAmXMgcHJpbWFyeSBwdXJwb3Nl IHdhcyB0byBzdXBwb3J0IE9wZW5JRCBDb25uZWN0IGFuZCBpdCB3b3JrcyBmaW5lIGZvciB0aGF0 LCBidXQgaWYgSSB3YW50IHRvIGFzayBhIHNldmVyIHRvIOKAnHRlbGwgbWUgZXZlcnl0aGluZyB5 b3Uga25vdyBhYm91dCBQYXVsIEpvbmVz4oCdLCBpdCBjYW5ub3QuJm5ic3A7IFJGQyA2NDE1IGNh biwgYW5kIEkgbGlrZSB0aGF0LiZuYnNwOyBUaGUNCiBkaWZmZXJlbmNlIGlzIHJlYWxseSBhIG1h dHRlciBvZiB0aGUgZG9jdW1lbnQgcmV0dXJuZWQuJm5ic3A7IEFsc28sIHRoZXJlIGlzIGFwcGxp Y2F0aW9uLWxldmVsIGtpbmQgb2YgcmVkaXJlY3QgaW4gU1dEIChvciB3YXMpIHRoYXQgcmVhbGx5 IHNob3VsZCBiZSBhbiBIVFRQLWxldmVsICgzeHgpLiZuYnNwOyBJIGRvbuKAmXQgbGlrZSB0aGF0 IGFib3V0IFNXRCwgZWl0aGVyLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+QmFjayB0byB0aGUgdHdvIGNhbXBzOiBuZWl0aGVyIGlzIGhh cHB5IHdpdGggdGhlIHByZXNlbnQgc29sdXRpb24gKHRoZSAtMDIgZHJhZnQpLiZuYnNwOyBQZW9w bGUgd2hvIGxpa2UgdGhlIHNpbmdsZSByZXF1ZXN0IGFwcHJvYWNoIGxpa2UgdGhpcyBBTFQgZHJh ZnRzIGJldHRlciBiZWNhdXNlIFhNTCBpcyBnb25lLCB0aGVyZSBpcyBhIHNpbmdsZQ0KIHJlc291 cmNlIHRvIGdvIHF1ZXJ5LCBhbmQsIG9mIGNvdXJzZSwgdGhlcmUgaXMgYSBzaW5nbGUgcmVxdWVz dC9yZXNwb25zZS4mbmJzcDsgUGVvcGxlIHdobyBhcmUgaW4gdGhlIDY0MTUgY2FtcCBkbyBhcmUg bm90IGhhcHB5IHdpdGggdGhlIC0wMiBkcmFmdCBiZWNhdXNlIHdlIHR1cm4g4oCcaG9zdCBtZXRh ZGF0YeKAnSBpbnRvIOKAnHJlc291cmNl4oCdIGluZm9ybWF0aW9uOiB3ZSBtZXJnZSB0aGUgY29u Y2VwdHMuJm5ic3A7IFRoZXkgYWxzbyBkbyBub3QgbGlrZSB0aGUgQUxUDQogZHJhZnRzIGZvciB0 aGUgc2FtZSByZWFzb24uJm5ic3A7IEhvd2V2ZXIsIGV2ZW4gdGhlIDY0MTUgY2FtcCBkb2VzIHNl ZW0gdG8gaGF2ZSBhbiBhcHByZWNpYXRpb24gZm9yIGEgcmVzb3VyY2UtY2VudHJpYyBhcHByb2Fj aCB0aGF0IGNhbiB1c2UgYSBzaW5nbGUgcXVlcnkuJm5ic3A7IFRoZXkganVzdCBkb27igJl0IGxp a2UgdGhlIOKAnGhhY2vigJ0gKG15IHRlcm3igKYgdGhhdOKAmXMgdGhlIG9uZSBuZWdhdGl2ZSB3 b3JkIEkgZG9u4oCZdCB0aGluayBJ4oCZdmUgaGFkIHRocm93biBpbg0KIG15IGZhY2UgOy0pICku PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5JIGJlbGlldmUgeW91IGFyZSByaWdodCB0byBwb2ludCBvdXQgdGhhdCB0aGUgb25lIHRoaW5n IHBlb3BsZSBzZWVtIHRvIGJlIGdlbmVyYWxseSBPSyB3aXRoIGlzIEpSRC4mbmJzcDsgSSB0aGlu ayBpdOKAmXMgYSBzaW1wbGUgZm9ybWF0LCBuaWNlIHRvIHdvcmsgd2l0aCwgdXNlZnVsLCBhbmQg bm90IG92ZXJseSBjb21wbGljYXRlZC4mbmJzcDsgR2l2ZW4gdGhhdA0KIHRoZXJlIGFyZSB2aXJ0 dWFsbHkgbm8gY29tbWVudHMgb24gdGhlIGZvcm1hdCwgSSBnYXRoZXIgcGVvcGxlIHNoYXJlIHRo ZSBzYW1lIHNlbnRpbWVudC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPk5vdywgaGF2aW5nIGhhZCBjb252ZXJzYXRpb25zIHdpdGggYSBu dW1iZXIgb2YgcGVvcGxlIGJvdGggb24gdGhlIGxpc3QgYW5kIG9mZiwgSSBiZWxpZXZlIHdlIG5l ZWQgdG8gZGVjaWRlIHdoaWNoIGRpcmVjdGlvbiB0byB0YWtlIGFuZCBJIHRoaW5rIHRoZXJlIGFy ZSB0d28gY2hvaWNlczo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g bGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEpPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldlIGRpc2NhcmQgdGhlIGN1cnJlbnQgV2Vi RmluZ2VyIGRyYWZ0IGFuZCBjb250aW51ZSB3aXRoIFJGQyA2NDE1IGFzLWlzPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm bzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5XZSByZS13cml0ZSB0aGUgc3BlYyBpbiB0aGUgc3Bpcml0IG9mIHRoZSBBTFQgdmVyc2lv bnMsIGNvbXBsZXRlbHkgYnJlYWtpbmcgYXdheSBmcm9tIFJGQyA2NDE1IGJ5PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0Ow0K bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFu Zz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJlbW92aW5nIGFsbCByZWZlcmVuY2Vz IHRvIGFuZCBkZXBlbmRlbmNpZXMgb24gUkZDIDY0MTU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7DQptc28tbGlzdDpsMSBs ZXZlbDIgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+RGVmaW5pbmcgSlJEIHdpdGhpbiB0aGUgV2ViRmluZ2VyIHNwZWMsIHNw ZWNpZnlpbmcgc3VjaCB0aGluZ3MgYXMg4oCcdGhlIG9yZGVyIG9mIGxpbmsgcmVsYXRpb25zIGlz IHNpZ25pZmljYW504oCdIG9yIG90aGVyIHJ1bGVzIHdlIHdhbnQgdG8gYXBwbHkgdG8gdGhlIGRv Y3VtZW50PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0 LWluZGVudDotMTguMHB0Ow0KbXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzIiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PmMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRlZmlu aW5nIGEgbmV3IHJlc291cmNlIGZvciB0aGlzIHNlcnZlciBhdCAvLndlbGwta25vd24vd2ViZmlu Z2VyIChvciBzd2QgPyk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIu MHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7DQptc28tbGlzdDpsMSBsZXZlbDIgbGZvMiI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+ZC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VXNp bmcgbm8gdGVtcGxhdGVzIHdoYXRzb2V2ZXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7DQptc28tbGlzdDpsMSBsZXZlbDIg bGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+ZS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+VXNpbmcgdGhlIOKAnHJlc291cmNl4oCdIHBhcmFtZXRlciBhcyB0aGUgY3VycmVu dCBBTFQgZHJhZnQgaGFzIHRoZW0gKHRoZSBjb25jZXB0IG9mIOKAnGhvc3QgbWV0YWRhdGHigJ0g ZG9lcyBub3QgZXhpc3Qgd2l0aCB0aGlzIGRyYWZ0OyBJ4oCZbSBub3Qgc3VyZSB3aGF0IHRoZSBz ZXJ2ZXIgc2hvdWxkIGRvIGlmIHRoZSByZXNvdXJjZSBwYXJhbWV0ZXINCiBpcyBhYnNlbnQsIHRo b3VnaCk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQt aW5kZW50Oi0xOC4wcHQ7DQptc28tbGlzdDpsMSBsZXZlbDIgbGZvMiI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ Zi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ KEkgd291bGQgc2F5IHVzZSB0aGUg4oCccmVs4oCdIHBhcmFtZXRlciwgdG9vLCBidXQgc29tZSBo YXZlIHJlYWxseSBleHByZXNzZWQgZGlzc2F0aXNmYWN0aW9uIHdpdGggdGhhdC4mbmJzcDsgV2hp bGUgSSB0aGluayBpdOKAmXMgd29uZGVyZnVsIGluIG9yZGVyIHRvIHJlZHVjZSB0aGUgbnVtYmVy IG9mIGxpbmsgcmVsYXRpb25zIHJldHVybmVkLA0KIHNvbWUganVzdCBzYXcgbm8gdmFsdWUgaW4g dGhhdOKApiBldmVuIG9uIG5hcnJvdy1iYW5kIG5ldHdvcmsgY29ubmVjdGlvbnMuKTwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SWYgSSB1 bmRlcnN0YW5kIHRoZSB0d28gY2FtcHMsIEkgdGhpbmsgdGhvc2UgYXJlIHRoZSB0d28gb3B0aW9u cyBiZWZvcmUgdXMuJm5ic3A7IEnigJltIHN1cmUgdGhlcmUgbWF5IGJlIG90aGVyIHRoaW5ncyB0 byBkbyBmb3Igb3B0aW9uIDIsIGJ1dCB5b3UgZ2V0IHRoZSBnaXN0IG9mIHdoZXJlIHRoYXQgaXMg aGVhZGVkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+TW9yZSBpbXBvcnRhbnRseSwgSSBhbSBsZWZ0IHdpdGggdGhlIGltcHJlc3Npb24g dGhhdCBpZiB3ZSBkbyBnbyB3aXRoIG9wdGlvbiAyLCB3ZSB3aWxsIGdldCBzdXBwb3J0IGZyb20g Ym90aCBjYW1wcy4mbmJzcDsgU29tZSBvZiB0aG9zZSB3aG8gYXJlIGluIHRoZSA2NDE1IGNhbXAg anVzdCBoYXZlIGFuIG9iamVjdGl2ZSBvZiBub3QgYnJlYWtpbmcNCiB3aGF0IGlzIHRoZXJlIG5v dyBhbmQgc29tZSBqdXN0IGRvbuKAmXQgd2FudCB0aGUg4oCcaGFja+KAnSB0aGF0IGlzIHRoZSBj dXJyZW50IFdGIHNwZWMuJm5ic3A7IEJ1dCwgSSBiZWxpZXZlIG1vc3QgYXJlIGFsbCBmb3IgYSBj bGVhbiBzcGVjaWZpY2F0aW9uIHRoYXQgZGVmaW5lcyBhIHVzZWZ1bCBzZXJ2aWNlIGFuZCB0aGF0 IHV0aWxpemVzIEpSRCB0byBwcm92aWRlIGEgc2V0IG9mIGxpbmsgcmVsYXRpb25zIGFib3V0IGEg cmVzb3VyY2U7IGEgdXNlZnVsIOKAnHdlYg0KIGRpc2NvdmVyeSBwcm90b2NvbOKAnS48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkganVz dCB3YW50IGEgc29sdXRpb24gYW5kIHdvdWxkIG5vdCBiZSB1cHNldCB3aXRoIGVpdGhlciBzb2x1 dGlvbi4mbmJzcDsgV2hhdCBJIGRvIG5vdCBsaWtlLCB0aG91Z2gsIGlzIGhhdmluZyB0d28gb3Ig dGhyZWUgc29sdXRpb25zIGZvciBkaXNjb3ZlcnkuJm5ic3A7IEF0IHByZXNlbnQsIHdlIGhhdmUg UkZDIDY0MTUsIGN1cnJlbnQgV0YgZHJhZnQsIFNXRCwNCiBhbmQmbmJzcDsgZHJhZnQtZGFib28t YWdyZWdnYXRlZC1zZXJ2aWNlLWRpc2NvdmVyeS4mbmJzcDsgVGhhdOKAmXMgYSBmZXcgdG9vIG1h bnkgOy0pPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5JIGRvIGhhdmUgYSBoaWdoIG9waW5pb24gb2YgWFJEL0pSRCwgc28gSSB3b3VsZCBs aWtlIHRvIHNlZSBlaXRoZXIgb3IgYm90aCBvZiB0aG9zZSByZXRhaW5lZCBpbiBhbnkgc29sdXRp b24gdGhlIGdyb3VwIHByb2R1Y2VzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+R2l2ZW4gdGhhdCBTV0QgZXhpc3RzLCBJIHRha2UgaXQg dGhhdCB0aGVyZSBpcyBhdCBsZWFzdCBlbm91Z2ggc3VwcG9ydCB0byBkbyBzb21ldGhpbmcgb3Ro ZXIgdGhhbiBSRkMgNjQxNS4gSSBkbyBub3QgZnVsbHkgdW5kZXJzdGFuZCB0aGUgcmVhc29ucywg ZXhjZXB0IHBlcmhhcHMg4oCcd2Ugd2FudCBvbmUgcm91bmQgdHJpcOKAnS4gSSBkb27igJl0DQog a25vdy4mbmJzcDsgUGVyaGFwcyBzb21lb25lIGNhbiBlZHVjYXRlIG1lIG9uIHRoZSDigJx3aHni gJ0uJm5ic3A7IEJ1dCwgaXQgZG9lcyBleGlzdCwgc28gdGhlcmUgaXMgYSByZWFzb24gYW5kIGl0 IG1lYW5zIHdlIG1pZ2h0IGVuZCB1cCB3aXRoIHR3byBzb2x1dGlvbnMuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TbywgY2FuIHdlIGF2 b2lkIHRoYXQ/Jm5ic3A7IEnigJlkIGJlIG9rIHdpdGggcHV0dGluZyBhc2lkZSB0aGUgV0Ygc3Bl YyBpbiBmYXZvciBhIG1lcmdlciBiZXR3ZWVuIFNXRC9XRi4mbmJzcDsgSSBkb27igJl0IHdhbnQg dG8gY2FsbCB0aGlzIGEg4oCcY29tcHJvbWlzZeKAnSwgYnV0IHJhdGhlciBhIGNsZWFuIHNvbHV0 aW9uIHRoYXQgYm9ycm93cyBmcm9tIGJvdGg6IHNpbmdsZQ0KIHJvdW5kIHRyaXAgKGxpa2UgU1dE KSwgYSByaWNoZXIgcmVzcG9uc2Ugd2l0aCBhIHNldCBvZiBsaW5rcyAoSlJEKSwgYWRoZXJlcyB0 byBhbmQgZm9sbG93cyBIVFRQIHByb2NlZHVyZXMgKGUuZy4sIG5vIOKAnFNXRF9zZXJ2aWNlX3Jl ZGlyZWN04oCdIHR5cGUgY29uc3RydWN0OyB1c2UgM3h4KSwgaGFzIG5vIHRlbXBsYXRlcyBpbiB0 aGUgSlJELCBhbGxvd3MgYW55IFVSSSB0eXBlIChpbmNsdWRpbmcg4oCcYWNjdDrigJ0pIGFzIHRo ZSDigJxzdWJqZWN04oCdIG9mIHRoZQ0KIHF1ZXJ5LCBhbmQgaXMgcm9vdGVkIGF0IHRoZSBob3N0 IGF0IHNvbWUgYWdyZWVkIGxvY2F0aW9uIGxpa2UgLy53ZWxsLWtub3duL3N3ZC48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYmVsaWV2 ZSBpZiB3ZSBkbyB0aGlzLCB3ZSBoYXZlIHRoZSBncmVhdGVzdCBjaGFuY2Ugb2YgZ2V0dGluZyB0 aGUgbGFyZ2VzdCBudW1iZXIgb2YgcGVvcGxlIG9uIGJvYXJkLiZuYnNwOyBQZXJoYXBzIE1pa2Ug b3Igc29tZW9uZSBzZXJ2ZSBhcyBlZGl0aW5nLCBidXQgSeKAmWQgYmUgaGFwcHkgdG8gaGVscCBj by1hdXRob3IuJm5ic3A7IEnigJlsbCBhbHNvIHdyaXRlDQogYW4gaW1wbGVtZW50YXRpb24gYXMg SSBkaWQgZm9yIFJGQyA2NDE1OyBpdCBzaG91bGQgYmUgc2ltcGxlIHRvIGRvLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SW4gYW55IGNh c2UsIEkgZG8gdGhpbmsgdGhlcmUgaXMgYSBzZXJpb3VzIHJpc2sgb2YgZmFpbHVyZSBpZiB3ZSBj b250aW51ZSBkb3duIHRoZSBjdXJyZW50IFdGIHBhdGgsIGVpdGhlciBiZWNhdXNlIHdlIGVuZCB1 cCB3aXRoIG11bHRpcGxlIGNvbXBldGluZyBzb2x1dGlvbnMgb3IgYmVjYXVzZSB3ZSBhbGllbmF0 ZSBvbmUgb2YgdGhlIHR3bw0KIGNhbXBzLiZuYnNwOyBTbyB3ZSBlaXRoZXIgc3RpY2sgd2l0aCA2 NDE1IGFuZCBzdG9wIHNwZW5kaW5nIHRpbWUgb24gdGhpcywgb3IgY3JlYXRlIHNvbWV0aGluZyBh bG9uZyB0aGUgbGluZXMgb2YgKDIpIHdoZXJlIHdlIGNhbiBnZXQgbmVhcmx5IGV2ZXJ5b25lIG9u IGJvYXJkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+UGF1bDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KJnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4N CjxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyI+YXBwcy1kaXNj dXNzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdvaXggTGF1cmVudCBXYWx0ZXI8YnI+DQo8Yj5TZW50Ojwv Yj4gRnJpZGF5LCBOb3ZlbWJlciAwMiwgMjAxMiAxMTozMCBBTTxicj4NCjxiPlRvOjwvYj4gRXZh biBQcm9kcm9tb3U7IDxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmciPmFwcHMt ZGlzY3Vzc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2FwcHMtZGlzY3Vzc10g UjogSGlnaC1sZXZlbCBjb25zaWRlcmF0aW9ucyBhYm91dCAmcXVvdDt3ZWJmaW5nZXImcXVvdDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBldmFuLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBkbyBoYXZlIHJlYWQgdGhlIGxh dGVzdCBhbHQtcjEgZHJhZnQuIEJ1dCBJIGRvIGJlbGlldmUgdGhlc2UgYXJlIHN0aWxsIGFwcGxp Y2FibGUgcXVlc3Rpb25zOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5J IGNvdWxkIHN0aWxsIHNlZSBwcm9zL2NvbnMgaW4gdGhlIGxpc3QgZm9yIHJlbC9yZXNvdXJjZSBw YXJhbWV0ZXJzIGluIGhvc3QtbWV0YS5qc29uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4t PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPlRoZSBxdWVzdGlvbiBvZiBjcmVhdGluZyBhIG5ldyBlbmRwb2ludCBoYXMgYmVl biByYWlzZWQgYW5kIHN0aWxsIHBlbmRpbmcgaW1vIChhbHNvIHdydCBwcmV2aW91cyBidWxsZXQp PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDIgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJlbGF0aW9uc2hpcCB3aXRo IHJmYzY0MTUgaXMgc3RpbGwgbm90IGNsZWFyIGFzIHNvbWUgcGFydHMgYXJlIGNsZWFybHkgcmVm ZXJlbmNlZCAobW9zdGx5IHByb2NlZHVyZXMpIHdoaWxzdCBvdGhlcnMgbWVudGlvbiBhIGNsZWFy IGRpc3RhbmNlIHdpdGggaXQgKGVnIHhyZCB2cyBqcmQpLiBBcyBhIGRldmVsb3BlciBJIGNvdWxk DQogbm90IGtub3cgdmVyeSB3ZWxsIHdoZXRoZXIgSSBuZWVkIHRvIGltcGxlbWVudCByZmM2NDE1 IGFuZCBob3cgbXVjaCBvZiBpdOKApmF0IHRoaXMgcG9pbnQgb25lIG1heSBjb25zaWRlciBob3cg bXVjaCB0aGUgZHJhZnQgZ2FpbnMgaW4gYWN0dWFsbHkgcmVmZXJlbmNpbmcgdGhvc2Ugc2VjdGlv bnMgaWYgaXQgaXMgdG8gbWFuZGF0ZSB0aGUgY29udHJhcnnigKY8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7DQptc28tbGlz dDpsMiBsZXZlbDIgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj5vPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkluIHNlY3Rpb24g MyBpdCByZWFkcyDigJx0aGUgcHJvdG9jb2wgYnVpbGRzIG9uIHJmYzY0MTXigJ0sIHdoaWNoIGlz IHZlcnkgdW5jbGVhciB0byB3aGljaCBleHRlbnQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7DQptc28tbGlzdDpsMiBsZXZl bDIgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj5vPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gNSB0YWxrcyBhYm91 dCBiYWNrd2FyZC1jb21wYXRpYmlsaXR5IGJ1dCBiYXNpY2FsbHkgc2F5cyBpdCDigJxtYXkgbm90 IGJl4oCdLiBUaGlzIGlzIG1haW5seSB0byByZXVzZSBqcmQgYW5kIOKAnGhvc3QtbWV0YS5qc29u 4oCdIHNvIGl0IG1heSBiZSBtb3JlIGFwcHJvcHJpYXRlIHRvIGNhbGwgdGhlbSBvdXQgZXhwbGlj aXRseQ0KIHdpdGhvdXQgYW55IGdlbmVyaWMgc2VudGVuY2UgKHN0aWxsIGlmIHRoaXMgaXMgdGhl IGZlZWxpbmcgb2YgdGhlIGdyb3VwKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCm1zby1saXN0OmwyIGxldmVsMiBsZm80 Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPm88c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U2VjdGlvbiA1LjEgcmVmZXJlbmNlcyBzZWN0 aW9uIDQuMiBvZiByZmM2NDE1IGJ1dCBhY3R1YWxseSBpbnRyb2R1Y2VzIHNvbWUgdmFyaWFudHMs IHNvIHdoeSBub3Qgd3JpdGUgYSBjbGVhbiBzdGFuZGFsb25lIHRleHQgd2l0aCBubyByZWZlcmVu Y2UgdG8gcmZjNjQxNT88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIu MHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7DQptc28tbGlzdDpsMiBsZXZlbDIgbGZvNCI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gNS4yIHJlZmVyZW5jZXMgYW4g4oCcZXhhbXBs ZeKAnSBvZiByZmM2NDE1IHNlY3Rpb24gMS4xLjEsIGJ1dCB0aGUgdmFsdWUgb2YgdGhhdCByZWZl cmVuY2UgaXMgbm90IGNsZWFyLiBCZXR0ZXIgcHJvYmFibHkgdG8gcmVmZXJlbmNlIHdlYmZpbmdl cuKAmXMgb3duIGV4YW1wbGVzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij50aGUgdmVyeSBsYXRlc3QgZHJhZnQgaXMgc3RpbGwgYWwg4oCcQUxU4oCdIGF0IHRoaXMgc3Rh Z2XigKY8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPknigJltIHBsYXlpbmcgdGhlIGRldmls4oCZcyBhZHZvY2F0ZSBoZXJlIGJ1dCBkbyB0 aGluayB0aGF0IHRoZSB2YXJpb3VzIGNhbXBzIGludGVuZCB2ZXJ5IGRpdmVyc2UgdXNhZ2VzIG9m IHdlYmZpbmdlciB0aGF0IG1heWJlIGRvIG5vdCBiZW5lZml0IG9mIG9uZSBzb2x1dGlvbi4gSXQg aXMgYSBwaXR5IHRob3NlIHVzZSBjYXNlcyBhcmUgbm90IHJlZmxlY3RlZA0KIGluIHRoZSBzaW1w bGlzdGljIGV4YW1wbGVzOiBJIHBlcnNvbmFsbHkgbGlrZWQgdGhlIG9wZW5pZCBvbmUgYXMgSSB0 aGluayBvcGVuZWQgY29ubmVjdCB3b3VsZCBiZSAxIGNhbmRpZGF0ZSwgYnV0IEnigJl2ZSBoZWFy ZCBhYm91dCBhdXRvY29uZmlndXJhdGlvbiAoc2VlIG9hdXRoIHVzZSBjYXNlKSBhbmQgZmVkZXJh dGVkIHNvY2lhbCBuZXR3b3JrcyAodGhlIHdob2xlIG9yaWdpbmFsIHBvaW50IG9mIGl0KS4gQWxs IG9mIHRoZW0gYXJlIHVzZWQgaW4NCiB2ZXJ5IGRpZmZlcmVudCBjb250ZXh0cyAodHJ1c3RlZC91 bnRydXN0ZWQsIGludHJhLS9pbnRlci1kb21haW4pIGFuZCB3aWxsIHByb2JhYmx5IGRpc3Rpbmd1 aXNoIHRoZW1zZWx2ZXMgZnJvbSB0aGUgYWN0dWFsIGxpbmsgcmVscyB0aGV5IHdpbGwgdXNlL2V4 cG9zZeKApjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+d2FsdGVyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJJVCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOndpbmRvd3RleHQiPkRhOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iSVQiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1p bHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5k b3d0ZXh0Ij4NCjxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyI+ YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86YXBwcy1k aXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRm Lm9yZzwvYT5dDQo8Yj5QZXIgY29udG8gZGkgPC9iPkV2YW4gUHJvZHJvbW91PGJyPg0KPGI+SW52 aWF0bzo8L2I+IHZlbmVyZMOsIDIgbm92ZW1icmUgMjAxMiAxNi4wNTxicj4NCjxiPkE6PC9iPiA8 YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnIj5hcHBzLWRpc2N1c3NAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+T2dnZXR0bzo8L2I+IFJlOiBbYXBwcy1kaXNjdXNzXSBIaWdoLWxldmVs IGNvbnNpZGVyYXRpb25zIGFib3V0ICZxdW90O3dlYmZpbmdlciZxdW90Ozwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNvbnZlcnNhdGlvbiBoYXMg cmVhbGx5IG1vdmVkIG9uISBJIHN1Z2dlc3QgeW91IHJlYWQgUGF1bCBKb25lcydzIGxhdGVzdCBl bWFpbCB0byBnZXQgY2F1Z2h0IHVwLjxicj4NCjxicj4NCi1FdmFuPGJyPg0KPGJyPg0KT24gMTIt MTEtMDIgMDg6MDIgQU0sIEdvaXggTGF1cmVudCBXYWx0ZXIgd3JvdGU6PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5EZWFyIGFsbCw8c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHRyaWVk IHRvIGNhdGNoIHVwIHdpdGggdGhlIGhvdCBkaXNjdXNzaW9uIG9mIHRoZSBsYXN0IGRheXMgYW5k IHdvdWxkIHRyeSB0byBob2xkIG9uIGZvciB0aGUgdGltZSBvZiBhbiBlbWFpbCB0cnlpbmcgdG8g c3VtbWFyaXplIHRoZSBjdXJyZW50IHNpdHVhdGlvbiBhbmQgdGFrZSBhIGJyZWF0aOKApjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+QXQgdGhpcyBzdGFnZSB3ZSBhcmUgaGF2aW5nIHZlcnkgZGlzdGluY3Qg Y2FtcHMgaW4gdGhlIGxpc3QgZm9yIHdoYXQgdGhleSBoYXZlIGluIG1pbmQgYmVoaW5kIHRoZSDi gJx3ZWJmaW5nZXLigJ0ga2V5d29yZDogeG1sIHZzIGpzb24sIDEgb3IgMiByb3VuZHRyaXBzLCBw cml2YWN5IGVjYy4gSXQgc2VlbXMgdG8gbWUgdGhhdCBQYXVsIGhhcyBiZWVuIGRvaW5nIGFuIG91 dHN0YW5kaW5nDQogd29yayB0cnlpbmcgdG8gY29tcHJvbWlzZSAoSSB3b3VsZCBoYXZlIGxvc3Qg cGF0aWVuY2XigKYpIGJ1dCBzdWNoIGNvbXByb21pc2VzIGRvIG5vdCBzZWVtIHRvIHNhdGlzZnkg YW55b25lOiBhY3R1YWxseSwgY29tcHJvbWlzZXMgYXJlIG1vdmluZyBtb3JlIGFuZCBtb3JlIHRv d2FyZHMgdGhlIG9yaWdpbmFsIFNXRCBpZGVhIGF0IHRoZSBlbmQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5NYXliZSB3ZSBjb3VsZCBhc2sgb3Vyc2VsdmVzIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvNiI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi Pi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5XaXRoIHRoZSDi gJx4cmTigJ0gaWRlYSBpbiBtaW5kIChwbGVhc2UsIGpyZC1lbnRodXNpYXN0cywgdHJ5IHRvIHB1 dCB0aGF0IGhhdCBvbiBhcyB3ZWxsKSwgd2hhdCBpcyBhY3R1YWxseSBtaXNzaW5nIGJleW9uZCBy ZmM2NDE1IGZvciDigJx3ZWJmaW5nZXLigJ0/IG5vdyB0aGUg4oCYYWNjdOKAmSBVUkkgaXMgYSBz ZXBhcmF0ZSBkcmFmdCAoYW4gaW5pdGlhbCBtb3RpdmF0aW9uKS4NCiBSZWwvcmVzb3VyY2UgcGFy YW1ldGVycyBmb3IgeHJkIHN1cHBvcnRlcnMgZG8gbm90IHNlZW0gZXNzZW50aWFsIGluIG15IHVu ZGVyc3RhbmRpbmcgbmVpdGhlci4gU28gKGFsdGhvdWdoIEkgYW0gYSBzdXBwb3J0cyBvZiB0aGF0 IGNhbXApIEkgaGF2ZSB0cm91YmxlIHNlZWluZyB3aGF0IHRydWx5IG5lZWQgdG8gYmUgYWRkZWQu IEkgY2FuIHVuZGVyc3RhbmQgRXZhbuKAmXMgcG9zaXRpb24gZm9yIGtlZXBpbmcgdGhlIGVudGly ZSB4cmQtYmFzZWQgY29tbXVuaXR5DQogKG9zdGF0dXMsIGRpYXNwb3JhLCBldGMpIGJ1dCBpc27i gJl0IHJmYzY0MTUtY29tcGxpYW5jZSBmb3IgdGhvc2UgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25z IGFscmVhZHkgZmFpciBlbm91Z2g/IElmIGEgbmV3IOKAnHdlYmZpbmdlcuKAnSBpcyBqcmQsIDEt cm91bmR0cmlwIG9ubHkgYXQgdGhlIGVuZCBpdOKAmXMganVzdCBhbm90aGVyIHJmYyBudW1iZXIg dG8gYmUgcmVmZXJlbmNlZCBpbnN0ZWFkL2luIGFkZGl0aW9uIGFuZCBhcyBzdWNoIGhhcyB0aGUg c2FtZQ0KIHZhbHVl4oCmKG5vdCBtZW50aW9uaW5nIHRoZSBpbXBsZW1lbnRhdGlvbiB3b3JrIG5l ZWRlZCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvNiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIGxhbmc9IkVOLVVTIj5SZmM2NDE1LWNvbXBsaWFuY2UgJmFtcDsgYmFja3dhcmQgY29tcGF0 aWJpbGl0eTogdGhpcyBzZWVtcyBhbHNvIGNvbnRlbnRpb3VzIGFzIHdoZXRoZXIgYmFja3dhcmQt Y29tcGF0aWJpbGl0eSBpcyBuZWVkZWQgb3Igbm90LiBob3dldmVyIHRoZSBjdXJyZW50IOKAnGNv bXByb21pc2Vz4oCdIGFyZSBvZGQgaW4gbWFpbnRhaW5pbmcgYmFja3dhcmQtY29tcGFiaWxpdHku IFdoYXQNCiBpcyBleGFjdGx5IGludGVyZXN0aW5nIGZvciDigJx3ZWJmaW5nZXLigJ0gZnJvbSB0 aGF0IHJmYz8gRnJvbSB0aGUgbGF0ZXN0IGFsdGVybmF0aXZlIGl0IHNlZW1zIG9ubHkgdGhlIOKA nGhvc3QtbWV0YS5qc29u4oCdIGVuZHBvaW50IG5hbWUgJmFtcDsgdGhlIGpyZC4gT3IgZWxzZT8g SG93IHRoZXNlIGNhbiBiZSByZWZlcmVuY2VkIGF0IGJlc3Qgd2l0aG91dCBuZWVkaW5nIHRoZSB3 aG9sZSB0aGluZz8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwwIGxldmVsMSBsZm82Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJF Ti1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPkhvc3QtbWV0YSYjNDM7bHJkZCB2cyBuZXcgZW5kcG9p bnQ6IFNob3VsZCB3ZSBwcm9wb3NlIGFuIGFsdGVybmF0aXZlIGVuZHBvaW50IG5hbWUgKHRoZXJl IHdlcmUgbWFueSBwcm9wb3NhbHMsIGluY2x1ZGluZyBvbmUgb2YgbWluZSBhIHdoaWxlIGFnbykg c28gdGhhdCB3ZSBzaW1wbHkg4oCcZGlzdGluZ3Vpc2jigJ0gdGhlIGV4aXN0aW5nIGhvc3QtbWV0 YSYjNDM7bHJkZCB3YXkgZnJvbQ0KIGEgbmV3IOKAnHdlYmZpbmdlcuKAnSB3YXkvZW5kcG9pbnQg YWxsLWluLTEtcm91bmR0cmlwLiBUaGlzIGlzIHdoYXQgc3dkIGlzIHByb3Bvc2luZy4gRXZlbnR1 YWxseSBvbmUgY291bGQgYXQgdGhlIGVuZCB1c2UgdGhlIHNhbWUgYmFja2VuZCBpbXBsZW1lbnRh dGlvbiB0byByZXR1cm4gcXVlcmllcyBjb21pbmcgYWxsIHRoZSB3YXkgZnJvbSBob3N0LW1ldGEm IzQzO2xyZGQgdGhhbiBvdGhlcnMgdXNpbmcgYW5vdGhlciB3ZWxsLWtub3duIChhbmQgZGlyZWN0 KQ0KIGVuZHBvaW50LiBUaGlzIHdvdWxkIGFsc28gYmUgbXVjaCBlYXNpZXIgdG8gc3VwcG9ydCBh bnkgcXVlcnkgcGFyYW1ldGVyIChyZXNvdXJjZSwgcmVsLCBldGMpIGFzIHNvbWUgYXJlIGFyZ3Vp bmcgYWdhaW5zdCBvdmVycmlkaW5nIGhvc3QtbWV0YSB3aXRoIHBhcmFtZXRlcnMuIEluIHRoYXQg Y2FzZSB0aGUgbmV3IOKAnHdlYmZpbmdlcuKAnSB3b3VsZCBiZSBhY3R1YWxseSBtb3JlIGxpa2Ug U1dEICh3aXRoIEpSRCBzdXBwb3J0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm82Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPkluIGFsdGVybmF0aXZlLCB3aGF0IGFi b3V0IHRoZSBwcm92b2NhdGl2ZSBpZGVhIGZyb20gRXZhbiB0byDigJxyZXBsYWNl4oCdIHJmYzY0 MTU/IEFyZSB0aGV5IG90aGVyIHVzYWdlcyBvZiByZmM2NDE1IHRoYW4gdGhlIOKAnHdlYmZpbmdl cuKAnSBvbmUgdGhyb3VnaG91dCB0aGUgY29tbXVuaXR5PyBJZiB5ZXMsIHRoZW4gaXQgbWF5IGJl IG1vcmUgZGlmZmljdWx0IHRvIHJlcGxhY2UNCiB1bmxlc3MgYWdyZWVkIHdpdGggd2hvbSBpcyB1 c2luZyBpdC4gT3RoZXJ3aXNlLCBhcyBpdCBzZWVtcyBtb3N0IHBlb3BsZSBkbyBub3QgbGlrZSBp dCwgd2h5IGtlZXAgaXQgYXMtaXMgYW5kIG5vdCB1cGdyYWRlIGRpcmVjdGx5IHRvIHdoYXRldmVy IGlzIG5vdyB1c2VmdWw/IEEgc3RhbmRhcmQgdGhhdCBpcyBub3QgdXNlZCBpcyB1c2VsZXNzIGFu ZCBoYXMgbm8gcG9pbnQgaW4gYmVpbmcgc3VwZXJzZWRlZCBieSBhIHBhcmFsbGVsIHNwZWMgbm90 DQogYWN0dWFsbHkgb2Jzb2xldGluZyBpdC4uLiBJZiBKUkQgYW5kIHRoZSB3ZWxsLWtub3duIGVu ZHBvaW50cyBhcmUgdXNlZnVsIGluIG90aGVyIGNvbnRleHQsIHRoZW4gd2h5IG5vdCBzcGxpdHRp bmcgdGhlbSBmcm9tIHRoZSBhY3R1YWwgcHJvdG9jb2wgcHJvY2VkdXJlcyBvZiBjdXJyZW50IHJm YzY0MTUgYW5kIGhhdmUgY2xlYW4gc3BlY3MgdGhhdCBjYW4gYmUgZ2VuZXJpY2FsbHkgcmVmZXJl bmNlZCB3aXRob3V0IGJ1eWluZyB0aGUgZnVsbCB0aGluZw0KIG9yIHdyaXRpbmcgY29tcGxleCB0 ZXh0IHRvIHNlbGVjdCBzb21lIHBhcnRzIG9mIGl0IGFuZCBjb250ZXN0IG90aGVyczogMSBmb3Ig SlJEIGFuZCAxIGZvciB0aGUgZW5kcG9pbnRzL2xpbmsgcmVnaXN0cmF0aW9ucy4gVGhlbiBhIHBy b3RvY29sLW9yaWVudGVkIHNwZWMgbGlrZSB3ZWJmaW5nZXIgY2FuIGVhc2lseSBkZWNpZGUgd2hh dCB0byB0YWtlIGFuZCByZXBsYWNlIGN1cnJlbnQgcmZjNjQxNSwgb3IgZGVjaWRlIHRvIGxpdmUg c2VwYXJhdGVseS9wYXJhbGxlbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlBlcnNvbmFsbHkgSSBoYXZlIG1vcmUgaW50ZXJlc3QgYW5kIGZlZWxpbmcgZm9y IHRoZSAyLXJvdW5kdHJpcCB4cmQgc29sdXRpb24gZnJvbSByZmM2NDE1IHN0aWxsLiBCdXQgaWYg SSBoYXZlIHRvIGNob29zZSBiZXR3ZWVuIGFuIG9kZC9wYXJ0aWFsL3Vuc3RhYmxlL3VuY2xlYXIv YnVnZ3kgcmVmZXJlbmNlIHRvIGl0IGFuZCBhIG5ldyBqc29uIHdheSBmb3Igc2F0aXNmeWluZw0K IGFub3RoZXIgdXNlIGNhc2UgSSBoYXZlIHRvIHB1dCBsaW1pdHMgaW4gY29tcHJvbWlzaW5nIGFu ZCBhdCB0aGlzIHBvaW50IHByZWZlciBhIHBhcmFsbGVsL2luZGVwZW5kZW50IGFwcHJvYWNoLiBP ZiBjb3Vyc2UgSeKAmWQgbGlrZSBwb3NzaWJseSB0byByZXVzZSB0aGUgZmlsZSBmb3JtYXQgKGpy ZCkgYXMgaXQgc2VlbXMgc3VpdGFibGUgZm9yIGFsbC4gQXQgbGVhc3QgdGhpcyB3YXkgcmZjNjQx NSBjYW4gc3RpbGwgbGl2ZSBpbmRlcGVuZGVudGx5DQogKGJlaW5nIHVwZGF0ZWQgb3Igbm90IGlm IHdlIHdhbnQgdG8gbWFrZSBpdCDigJxjbGVhbmVy4oCdKSBhbmQg4oCcd2ViZmluZ2Vy4oCdIGNh biBob3BlZnVsbHkgYmUgZmluYWxpemVkIHF1aWNrbHkgaW4gdGhlIGpzb24gJiM0MzsgMSByb3Vu ZHRyaXAgZGlyZWN0aW9u4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbmNlIHRoZXNlIG1hY3JvIHRv cGljcyBhcmUgY2xhcmlmaWVkIHRoZW4gd2UgY2FuIGJldHRlciBkaXNjdXNzIHRoZSBkZXRhaWxz IGFib3V0IHNlY3VyaW5nIHdmLCBzdXBwb3J0aW5nIHByaXZhY3ksIGRpc3RpbmN0IGRlbGl2ZXJ5 IGZvciBhdXRoL25vbi1hdXRoIHJlcXVlc3RzIGV0Y+KApkJ1dCBjYW4gd2UgZmlyc3QgZGlzY3Vz cyBhdCBoaWdoIGxldmVsIHdoYXQgd2Ugd2FudA0KIHRvIGFjaGlldmUgaW4gdGVybXMgb2YgcHJv Y2Vzcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj53YWx0ZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxw YWRkaW5nPSIwIiB3aWR0aD0iNjAwIiBzdHlsZT0id2lkdGg6NDUwLjBwdCI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgd2lkdGg9IjU4NSIgc3R5bGU9IndpZHRoOjQzOC43NXB0O3BhZGRpbmc6Ljc1cHQg Ljc1cHQgLjc1cHQgLjc1cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIGNsYXNzPSJtc29ub3JtYWwwIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+UXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGlu ZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVz aW9uZSwgY29waWEgbyBxdWFsc2lhc2kNCiBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNv bm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0 ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBz aWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9u ZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXpp ZS4NCjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIHN0eWxlPSJ0ZXh0 LWFsaWduOmp1c3RpZnkiPjxzcGFuIGNsYXNzPSJtc29ub3JtYWwwIj48aT48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMmbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5Lg0KIERpc3NlbWlu YXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRo b3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRl ciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuPC9zcGFuPjwvaT48L3NwYW4+PHNwYW4gY2xhc3M9 Im1zb25vcm1hbDAiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8 L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtYWxpZ246anVzdGlmeSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDsNCiAg Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bHQ7aW1hZ2UwMDEuZ2lmJmd0O1Jpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVz dGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9k eT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5hcHBzLWRpc2N1c3MgbWFpbGluZyBsaXN0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJt YWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnIj5hcHBzLWRpc2N1c3NAaWV0Zi5vcmc8L2E+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2FwcHMtZGlzY3VzcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBz LWRpc2N1c3M8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxl IiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNjAwIiBzdHlsZT0id2lkdGg6NDUw LjBwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgd2lkdGg9IjU4NSIgc3R5bGU9IndpZHRoOjQzOC43 NXB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIGNsYXNzPSJtc29ub3Jt YWwwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3Vv aSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBp bmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kNCiBhbHRyYSBhemlvbmUg ZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJp Z29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1 bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1l ZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEg ZGlzdHJ1emlvbmUsIEdyYXppZS4NCjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIGNsYXNzPSJtc29ub3JtYWww Ij48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoaXMgZS1tYWls IGFuZCBhbnkgYXR0YWNobWVudHMmbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbCBhbmQgbWF5IGNv bnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShz KSBvbmx5Lg0KIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnli b2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFu ZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuPC9zcGFuPjwvaT48 L3NwYW4+PHNwYW4gY2xhc3M9Im1zb25vcm1hbDAiPjxzcGFuIGxhbmc9IkVOLUdCIj4NCjwvc3Bh bj48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1hbGlnbjpqdXN0aWZ5Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0Ow0KICBmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZsdDtp bWFnZTAwMS5naWYmZ3Q7UmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBt YWlsIHNlIG5vbiDDqCBuZWNlc3NhcmlvLjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7DQpjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3Mi Pg0KPCEtLQ0Kc3Bhbi5HcmFtRSB7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5ZXM7 fQ0KLS0+DQo8L3N0eWxlPg0KPHRhYmxlIHN0eWxlPSJ3aWR0aDo2MDBweDsiPg0KPHRib2R5Pg0K PHRyPg0KPHRkIHN0eWxlPSJ3aWR0aDo1ODVweDsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFyaWFs OyBmb250LXNpemU6MTJweDsgY29sb3I6IzAwMDsgdGV4dC1hbGlnbjoganVzdGlmeSIgd2lkdGg9 IjM5NSI+DQo8ZGl2IGFsaWduPSJqdXN0aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1hbGlnbjpqdXN0aWZ5OyBsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYSI+UXVlc3RvIG1lc3NhZ2dpbyBlIGkg c3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29u ZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kNCiBhbHRyYSBhemlv bmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25v IHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBk b2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBp bW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBz dWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCjwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8cCBhbGlnbj0i anVzdGlmeSI+PHNwYW4gY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlm eTsgbGluZS1oZWlnaHQ6bm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj5U aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzPC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToNCiAgNy41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj4mbmJzcDs8c3Bh biBjbGFzcz0iR3JhbUUiPmlzPC9zcGFuPiZuYnNwOzwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6DQogIDcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNv LWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPmNvbmZpZGVudGlhbA0KIGFuZCBtYXkgY29udGFpbiBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERp c3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMg dW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhl IHNlbmRlcg0KIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy48L3NwYW4+PC9pPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPg0KPC9zcGFuPjwvc3Bhbj48 L3A+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0Ow0KICBmb250LWZhbWlseTpWZXJk YW5hIj48aW1nIHNyYz0iY2lkOjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzQFRJLkRp c2NsYWltZXIiIGFsdD0icmlzcGV0dGEgbCdhbWJpZW50ZSIgd2lkdGg9IjI2IiBoZWlnaHQ9IjQw Ij5SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOo IG5lY2Vzc2FyaW8uPC9zcGFuPjwvYj4NCjxwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A09A9E0A4B9C654E8672D1DC003633AE53A50F6FC2GRFMBX704BA02_-- --_728d5ac0-6582-4523-b4cc-3dfdfd6fdd7f_ 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= --_728d5ac0-6582-4523-b4cc-3dfdfd6fdd7f_-- From paulej@packetizer.com Mon Nov 5 05:44: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 50BFF21F8599 for ; Mon, 5 Nov 2012 05:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] 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 phagm3uDKaYh for ; Mon, 5 Nov 2012 05:44:19 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEBF21F84E8 for ; Mon, 5 Nov 2012 05:44:19 -0800 (PST) Received: from dhcp-4288.meeting.ietf.org (dhcp-4288.meeting.ietf.org [130.129.66.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qA5DiH2L016232 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 5 Nov 2012 08:44:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1352123058; bh=RD0aj9iF951LA2UM2kwiGGi3tvnc0UvEVlDrPRlMYVw=; h=MIME-Version:Content-Type:Subject:From:Date:To:Message-ID; b=I95KqBQG+Met02n8W/kR3oUlpxEoTFLzxW1bY7m4JcoZgF6sbUyT/13HbY9nWCemq Ls7/F5UxdaQQlj8Ysa39nTEECBb7pbdF80EiYDSnALnCIMpuArtzXMfz4drU+ogYDQ tjLRXHJ2uq0fFIGtQuLO0yoTdnSabnBRGYJ+7vPc= User-Agent: K-9 Mail for Android MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----483TQG68EFJ68O9TIUQNTWOEA63AAY" From: "Paul E. Jones" Date: Mon, 05 Nov 2012 08:44:11 -0500 To: apps-discuss@ietf.org Message-ID: <1e8757a8-659a-42d2-9708-309f4b8de076@email.android.com> Subject: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 05 Nov 2012 13:44:21 -0000 ------483TQG68EFJ68O9TIUQNTWOEA63AAY Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit FYI -------- Original Message -------- From: Mike Jones Sent: Mon Nov 05 07:55:14 EST 2012 To: "Paul E. Jones" Subject: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments Paul, could you do me a favor and forward this note to the apps-discuss list so people have context on why I updated SWD? For some reason, the list doesn't appear to be accepting my message. Thanks, -- Mike From: Mike Jones Sent: Sunday, November 04, 2012 9:21 PM To: apps-discuss@ietf.org Subject: Simple Web Discovery (SWD) Enabling Hosted Deployments I've updated the Simple Web Discovery (SWD) specification to incorporate a means of performing discovery on domains for which it may not be possible to create a .well-known endpoint. This can often be the case for hosted domains, where it is common for e-mail to be provided but no web server. This solution was developed in discussions by the OpenID Connect working group. This draft is being published now to facilitate discussions of the need to enable discovery for hosted domains and possible solutions for doing so at the IETF Applications Area working group meeting at IETF 85 in Atlanta. The updated specification is available at: * http://tools.ietf.org/html/draft-jones-simple-web-discovery-04 Changes made were: * Specified that the SWD server for a domain may be located at the simple-web-discovery subdomain of the domain and that SWD clients must first try the endpoint at the domain and then the endpoint at the subdomain. * Removed the SWD_service_redirect response, since redirection can be accomplished by pointing the simple-web-discovery subdomain to a different location than the domain's host. * Removed mailto: from examples in favor of bare e-mail address syntax. * Specified that SWD servers may also be run on ports other than 443, provided they use TLS on those ports. An HTML formatted version is available at: * http://self-issued.info/docs/draft-jones-simple-web-discovery-04.html (This notice was also posted to http://self-issued.info/?p=891.) -- Mike ------483TQG68EFJ68O9TIUQNTWOEA63AAY Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit FYI

From: Mike Jones <Michael.Jones@microsoft.com>
Sent: Mon Nov 05 07:55:14 EST 2012
To: "Paul E. Jones" <paulej@packetizer.com>
Subject: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments

Paul, could you do me a favor and forward this note to the apps-discuss list so people have context on why I updated SWD?  For some reason, the list doesn’t appear to be accepting my message.

 

                                                            Thanks,

                                                            -- Mike

 

From: Mike Jones
Sent: Sunday, November 04, 2012 9:21 PM
To: apps-discuss@ietf.org
Subject: Simple Web Discovery (SWD) Enabling Hosted Deployments

 

I’ve updated the Simple Web Discovery (SWD) specification to incorporate a means of performing discovery on domains for which it may not be possible to create a .well-known endpoint.  This can often be the case for hosted domains, where it is common for e-mail to be provided but no web server.  This solution was developed in discussions by the OpenID Connect working group.

 

This draft is being published now to facilitate discussions of the need to enable discovery for hosted domains and possible solutions for doing so at the IETF Applications Area working group meeting at IETF 85 in Atlanta.

 

The updated specification is available at:

·        http://tools.ietf.org/html/draft-jones-simple-web-discovery-04

 

Changes made were:

·        Specified that the SWD server for a domain may be located at the simple-web-discovery subdomain of the domain and that SWD clients must first try the endpoint at the domain and then the endpoint at the subdomain.

·        Removed the SWD_service_redirect response, since redirection can be accomplished by pointing the simple-web-discovery subdomain to a different location than the domain's host.

·        Removed mailto: from examples in favor of bare e-mail address syntax.

·        Specified that SWD servers may also be run on ports other than 443, provided they use TLS on those ports.

 

An HTML formatted version is available at:

·        http://self-issued.info/docs/draft-jones-simple-web-discovery-04.html

 

(This notice was also posted to http://self-issued.info/?p=891.)

 

                                                            -- Mike

 

------483TQG68EFJ68O9TIUQNTWOEA63AAY-- From andy@hxr.us Mon Nov 5 05:56: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 F093721F8582 for ; Mon, 5 Nov 2012 05:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, MIME_BAD_LINEBREAK=0.5, 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 yII8pETIDx+w for ; Mon, 5 Nov 2012 05:56:42 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7651A21F855F for ; Mon, 5 Nov 2012 05:56:41 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so4435199lam.31 for ; Mon, 05 Nov 2012 05:56:40 -0800 (PST) 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:x-gm-message-state; bh=WitE7gaupzQbw44C2bVVaqvzcO4wYSQ7dTnqAQ4LD3o=; b=Z7qzAYY3xYgiHT41kV5w8XKAFKKGP2KajGE49mnSiSfqbMkcQDSJWm2stAWndmWYkY XO4fUitIUinAG3/L1p0TSoGzXYhvkUnSpfS8jcZsgveZyr7tKHJ8uI0UgaXf1XGmZdMh U4Vrzr0NiMnkEXJ04++6pB7CfW/rQGybgbbG1LDVKhJdtIlSd+BahWzntuHYkfAmj6BX 9y+6E+HoQr3m0cWPykoi2NS7CuPJGnvmNN5EQPRyRrG+EedX1VO3E5GHl2qoe09vP0/P a2jlb66vg/1Zr/l06ynmKI9kqIpfN+VsRuEnQtlXgg6E/NkPxnHsSRe6EoALjesY8kl0 f7HA== MIME-Version: 1.0 Received: by 10.112.38.234 with SMTP id j10mr3929063lbk.80.1352123800360; Mon, 05 Nov 2012 05:56:40 -0800 (PST) Received: by 10.112.155.138 with HTTP; Mon, 5 Nov 2012 05:56:40 -0800 (PST) X-Originating-IP: [130.129.33.22] In-Reply-To: References: Date: Mon, 5 Nov 2012 11:56:40 -0200 Message-ID: From: Andrew Newton To: "Cullen Jennings (fluffy)" Content-Type: multipart/mixed; boundary=e0cb4efe2f14d0180e04cdbfdabb X-Gm-Message-State: ALoCoQm2/grrf5kbvWA8YsFv9UBsGd7nJVy+kFY9kGLk2nLeTNF+H47i0BAcyxb6pmuqFmwY4I/r Cc: bje@apnic.net, "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] draft-newton-json-content-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: Mon, 05 Nov 2012 13:56:43 -0000 --e0cb4efe2f14d0180e04cdbfdabb Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 4, 2012 at 9:48 PM, Cullen Jennings (fluffy) wrote: > > I think something like this would be useful for the folks writing specs that use JSON. I like it. > > Cullen Thanks Fluffy. BTW, Byron Ellacott has created ABNF for this. Here it is for those interested. -andy --e0cb4efe2f14d0180e04cdbfdabb Content-Type: text/plain; charset=US-ASCII; name="json-rules-abnf.txt" Content-Disposition: attachment; filename="json-rules-abnf.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h95nkbfj0 Z3JhbW1hciAgICAgICAgID0gMSoocnVsZSAvIGRpcmVjdGl2ZSkgKmMtd3NwDQ1ydWxlICAgICAg ICAgICAgPSBydWxlbmFtZSBkZWZpbml0aW9uDWRlZmluaXRpb24gICAgICA9ICpjLXdzcCAoIHZh bHVlLXJ1bGUgLyBtZW1iZXItcnVsZSAvIGFycmF5LXJ1bGUgLyBvYmplY3QtcnVsZSAvIGdyb3Vw LXJ1bGUgKQ0NOyBydWxlbmFtZXMgbXVzdCBiZSB1bmlxdWUsIGFuZCBtYXkgbm90IGJlIGEgcmVz ZXJ2ZWQgd29yZA1ydWxlbmFtZSAgICAgICAgPSAqYy13c3AgQUxQSEEgKihBTFBIQSAvIERJR0lU IC8gIi0iIC8gIl8iKQ0NOyBBZGFwdGVkIGZyb20gdGhlIEFCTkYgZm9yIEpTT04sIFJGQyA0NjI3 IHMgMi40DWZsb2F0ICAgICAgICAgICA9IFsgIi0iIF0gaW50IFsgZnJhYyBdIFsgZXhwIF0NaW50 ZWdlciAgICAgICAgID0gWyAiLSIgXSBpbnQgWyBleHAgXQ1leHAgICAgICAgICAgICAgPSAoICJl IiAvICJFIiApIFsgIisiIC8gIi0iIF0gMSpESUdJVA1mcmFjICAgICAgICAgICAgPSAiLiIgMSpE SUdJVA1pbnQgICAgICAgICAgICAgPSAiMCIgLyAoICV4MzEtMzkgKkRJR0lUICkNDTsgVGhlIHJl Z2V4LWNoYXIgcnVsZSBhbGxvd3MgZm9yIGFueSBzZXF1ZW5jZSBvZiBjaGFyYWN0ZXJzLCBpbmNs dWRpbmcNOyB3aGl0ZXNwYWNlIGFuZCBuZXdsaW5lcywgd2l0aCBiYWNrc2xhc2ggb25seSBhbGxv d2VkIGJlZm9yZSBlaXRoZXINOyBhIGZvcndhcmQgb3IgYSBiYWNrc2xhc2guDXJlZ2V4LWNoYXIg ICAgICA9ICV4MjEtMkUgLyAleDMwLTVEIC8gJXg1RS03RSAvIFdTUCAvDSAgICAgICAgICAgICAg ICAgIENSIC8gTEYgLyAiXC8iIC8gIlxcIg0NOyB1cmktc2NoZW1lIGZyb20gUkZDIDM5ODYNdXJp LXNjb3BlICAgICAgID0gKmMtd3NwICggInJlbGF0aXZlIiAvICJmdWxsIiApDXVyaS1zY2hlbWUg ICAgICA9ICpjLXdzcCBBTFBIQSAqKCBBTFBIQSAvIERJR0lUIC8gIisiIC8gIi0iIC8gIi4iICkN DWJvb2xlYW4tdHlwZSAgICA9ICJib29sZWFuIg1udWxsLXR5cGUgICAgICAgPSAibnVsbCINaW50 ZWdlci10eXBlICAgID0gImludGVnZXIiIFsgMSpjLXdzcCBpbnRlZ2VyICIuLiIgaW50ZWdlciBd DWZsb2F0LXR5cGUgICAgICA9ICJmbG9hdCIgICBbIDEqYy13c3AgZmxvYXQgICAiLi4iIGZsb2F0 ICAgXQ1zdHJpbmctdHlwZSAgICAgPSAic3RyaW5nIiAgWyAqYy13c3AgIi8iICpyZWdleC1jaGFy ICIvIiBdDXVyaS10eXBlICAgICAgICA9ICJ1cmkiICAgICBbIHVyaS1zY29wZSBdIFsgdXJpLXNj aGVtZSBdDWlwLXR5cGUgICAgICAgICA9ICJpcDQiIC8gImlwNiINZG5zLXR5cGUgICAgICAgID0g ImZxZG4iIC8gImlkbiINZGF0ZS10eXBlICAgICAgID0gImRhdGUtdGltZSIgLyAiZnVsbC1kYXRl IiAvICJmdWxsLXRpbWUiDWVtYWlsLXR5cGUgICAgICA9ICJlbWFpbCIgWyAqYy13c3AgKCAiMjgy MiIgLyAiNTMyMiIgKSBdDXBob25lLXR5cGUgICAgICA9ICJwaG9uZSINYmFzZTY0LXR5cGUgICAg ID0gImJhc2U2NCINYW55LXR5cGUgICAgICAgID0gImFueSINDXZhbHVlLXJ1bGUgICAgICA9ICI6 IiAqYy13c3AgdHlwZS1ydWxlDXR5cGUtcnVsZSAgICAgICA9IGJvb2xlYW4tdHlwZSAvDSAgICAg ICAgICAgICAgICAgIG51bGwtdHlwZSAvDSAgICAgICAgICAgICAgICAgIGludGVnZXItdHlwZSAv DSAgICAgICAgICAgICAgICAgIGZsb2F0LXR5cGUgLw0gICAgICAgICAgICAgICAgICBzdHJpbmct dHlwZSAvDSAgICAgICAgICAgICAgICAgIHVyaS10eXBlIC8NICAgICAgICAgICAgICAgICAgaXAt dHlwZSAvDSAgICAgICAgICAgICAgICAgIGRucy10eXBlIC8gDSAgICAgICAgICAgICAgICAgIGRh dGUtdHlwZSAvDSAgICAgICAgICAgICAgICAgIGVtYWlsLXR5cGUgLw0gICAgICAgICAgICAgICAg ICBwaG9uZS10eXBlIC8NICAgICAgICAgICAgICAgICAgYmFzZTY0LXR5cGUgLw0gICAgICAgICAg ICAgICAgICBhbnktdHlwZQ0NaW5saW5lLXJ1bGUgICAgID0gKmMtd3NwICggcnVsZW5hbWUgLyBk ZWZpbml0aW9uICkNDTsgVGhlIGRlZmludGlvbiBvZiBhIEpTT04gc3RyaW5nLCBmcm9tIFJGQyA0 NjI3IHMgMg1qc29uLW5hbWUgICAgICAgPSAleDIwLTIxIC8gJXgyMy01QiAvICV4NUQtMTBGRkZG IC8gIlwiICgNICAgICAgICAgICAgICAgICAgICAleDIyIC8gICAgICA7ICIgIHUrMDAyMg0gICAg ICAgICAgICAgICAgICAgICV4NUMgLyAgICAgIDsgXCAgdSswMDVDDSAgICAgICAgICAgICAgICAg ICAgJXgyRiAvICAgICAgOyAvICB1KzAwMkYNICAgICAgICAgICAgICAgICAgICAleDYyIC8gICAg ICA7IEJTIHUrMDAwOA0gICAgICAgICAgICAgICAgICAgICV4NjYgLyAgICAgIDsgRkYgdSswMDBD DSAgICAgICAgICAgICAgICAgICAgJXg2RSAvICAgICAgOyBMRiB1KzAwMEENICAgICAgICAgICAg ICAgICAgICAleDcyIC8gICAgICA7IENSIHUrMDAwRA0gICAgICAgICAgICAgICAgICAgICV4NzQg LyAgICAgIDsgSFQgdSswMDA5DSAgICAgICAgICAgICAgICAgICAgKCAleDc1IDRIRVhESUcgKSAp IDsgdVhYWFggdStYWFhYDQ1tZW1iZXItcnVsZSAgICAgPSAoICggIl4iICV4MjIuMjIgKSAvICgg JXgyMiAqanNvbi1uYW1lICV4MjIgKSApIGlubGluZS1ydWxlDQ1vYmplY3QtcnVsZSAgICAgPSAi eyIgWyBvYmplY3QtbWVtYmVyICooICpjLXdzcCAiLCIgb2JqZWN0LW1lbWJlciApIF0gKmMtd3Nw ICJ9Ig0Nb2JqZWN0LW1lbWJlciAgID0gKmMtd3NwIFsiPyJdICggcnVsZW5hbWUgLyBtZW1iZXIt cnVsZSAvIGdyb3VwLXJ1bGUgKQ0gICAgICAgICAgICAgICAgICBbICpjLXdzcCAoICIvIiAvICIm IiApIG9iamVjdC1tZW1iZXIgXQ0NYXJyYXktcnVsZSAgICAgID0gIlsiIFsgYXJyYXktbWVtYmVy ICooICpjLXdzcCAiLCIgYXJyYXktbWVtYmVyICkgXSAqYy13c3AgIl0iDQ1hcnJheS1jb3VudCAg ICAgPSAqYy13c3AgWyBbaW50XSAiKiIgW2ludF0gKmMtd3NwIF0NYXJyYXktbWVtYmVyICAgID0g YXJyYXktY291bnQgKCBydWxlbmFtZSAvIHZhbHVlLXJ1bGUgLyBvYmplY3QtcnVsZSAvIGdyb3Vw LXJ1bGUgKQ0gICAgICAgICAgICAgICAgICBbICpjLXdzcCAiLyIgYXJyYXktbWVtYmVyIF0NDWdy b3VwLXJ1bGUgICAgICA9ICIoIiBbIGdyb3VwLW1lbWJlciAqKCAqYy13c3AgIiwiIGdyb3VwLW1l bWJlcikgXSAqYy13c3AgIikiDQ1ncm91cC1tZW1iZXIgICAgPSAgWyI/Il0gaW5saW5lLXJ1bGUg WyAqYy13c3AgKCAiLyIgLyAiJiIgKSBncm91cC1tZW1iZXIgXQ0NZGlyZWN0aXZlICAgICAgID0g KmMtd3NwICIjIiAqKCBWQ0hBUiAvIFdTUCAvICV4N0YtMTBGRkZGICkgRU9MDQ07IFRha2VuIGZy b20gdGhlIEFCTkYgZm9yIEFCTkYgKFJGQyA0NjI3IHNlY3Rpb24gNCkgYW5kIHNsaWdodGx5IGFk YXB0ZWQNOyBuZXdsaW5lcyBpbiBhIGMtd3NwIGRvIG5vdCBuZWVkIHdoaXRlc3BhY2UgYXQgdGhl IHN0YXJ0IG9mIGEgbmV3bGluZQ07IHRvIGZvcm0gYSB2YWxpZCBjb250aW51YXRpb24gbGluZSwg YW5kIEVPTCBtaWdodCBub3QgYmUgYSBmdWxsIENSTEYNYy13c3AgICAgICAgICAgID0gV1NQIC8g Yy1ubA1jLW5sICAgICAgICAgICAgPSBjb21tZW50IC8gRU9MDWNvbW1lbnQgICAgICAgICA9ICAi OyIgKihXU1AgLyBWQ0hBUikgRU9MDUVPTCAgICAgICAgICAgICA9IDEqKCBDUiAvIExGICkNDTsg Y29yZSBydWxlcw1BTFBIQSAgICAgICAgICA9ICAleDQxLTVBIC8gJXg2MS03QSAgIDsgQS1aIC8g YS16DUNSICAgICAgICAgICAgID0gICV4MEQNRElHSVQgICAgICAgICAgPSAgJXgzMC0zOQ1IRVhE SUcgICAgICAgICA9ICBESUdJVCAvICJBIiAvICJCIiAvICJDIiAvICJEIiAvICJFIiAvICJGIg1M RiAgICAgICAgICAgICA9ICAleDBBDVZDSEFSICAgICAgICAgID0gICV4MjEtN0UNV1NQICAgICAg ICAgICAgPSAgU1AgLyBIVEFCDVNQICAgICAgICAgICAgID0gICV4MjANSFRBQiAgICAgICAgICAg PSAgJXgwOQ0= --e0cb4efe2f14d0180e04cdbfdabb-- From Jeff.Hodges@KingsMountain.com Mon Nov 5 06:07: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 0FC2B21F8BEA for ; Mon, 5 Nov 2012 06:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 tQQYupB7M4SM for ; Mon, 5 Nov 2012 06:07:39 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id D388121F8B61 for ; Mon, 5 Nov 2012 06:07:38 -0800 (PST) Received: (qmail 15976 invoked by uid 0); 5 Nov 2012 14:07:16 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 5 Nov 2012 14:07:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=XeHp9pb26DN5dWSEDGv7Bdg6iOEtbJHdfflX7ATNLrk=; b=dwozAGP6CTo7qvnnAEa0HxNNdLAzgsD7kG16O77RccWlRWq3OjvE9U7NbaQZrOHB13T6BkLqRpD5Kty9Pnxl/rVoW4LbfkP5/ry/IBUBIXWUNJhwiNUkZ6ZGWAJJqbIf; Received: from [130.129.80.110] (port=38398) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TVNKe-0007cU-CA for apps-discuss@ietf.org; Mon, 05 Nov 2012 07:07:16 -0700 Message-ID: <5097C809.4070405@KingsMountain.com> Date: Mon, 05 Nov 2012 06:07:05 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.80.110 authed with jeff.hodges+kingsmountain.com} Subject: [apps-discuss] jabber room for meeting is apparea@jabber.ietf.org 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, 05 Nov 2012 14:07:40 -0000 I'll be scribing in apparea@jabber.ietf.org, not in the other similarly-named jabber rooms =JeffH From paulej@packetizer.com Mon Nov 5 07:54: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 18E5E21F87F4 for ; Mon, 5 Nov 2012 07:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] 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 mx0cohxhMhRl for ; Mon, 5 Nov 2012 07:53:59 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D51DA21F8595 for ; Mon, 5 Nov 2012 07:53:58 -0800 (PST) Received: from dhcp-10a7.meeting.ietf.org (dhcp-10a7.meeting.ietf.org [130.129.16.167]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qA5FrtZl022173 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 5 Nov 2012 10:53:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1352130837; bh=qjMpGLushEvdt+pYMveiWyhs7lG4q9qbTVZnXkWSJFM=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=fciIDzYD808lRvpHMppSJ01qwmQs6QFOkMKBf6Td7kbWckY+4YY/EIUpsvreuwcK1 kzwzMveByWjavt4kXhgS6tCjzYFsngfZ7OBfk54gmwzHjb9dNWxltLyIggb9qVUN5P wEDw1pY/nYFJeU+U/A99xpdXEOQE5SqbeiWrLgyI= User-Agent: Kaiten Mail In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----EP4DGX5G5572MLWL4O6DQ4BMX31D70" From: "Paul E. Jones" Date: Mon, 05 Nov 2012 10:53:52 -0500 To: Goix Laurent Walter Message-ID: Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] R: R: High-level considerations about "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: Mon, 05 Nov 2012 15:54:02 -0000 ------EP4DGX5G5572MLWL4O6DQ4BMX31D70 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit So you want a JRD RFC, not just a JRD section in WF? If so, we need someone to author that immediately. Paul -------- Original Message -------- From: Goix Laurent Walter Sent: Mon Nov 05 05:57:58 EST 2012 To: "Paul E. Jones" Cc: 'Evan Prodromou' , "apps-discuss@ietf.org" , "webfinger@googlegroups.com" , 'Mike Jones' Subject: R: [apps-discuss] R: High-level considerations about "webfinger" Hello Paul, Comments as [walter] Da: Paul E. Jones [mailto:paulej@packetizer.com] Inviato: domenica 4 novembre 2012 0.38 A: Goix Laurent Walter Cc: 'Evan Prodromou'; apps-discuss@ietf.org; webfinger@googlegroups.com; 'Mike Jones' Oggetto: RE: [apps-discuss] R: High-level considerations about "webfinger" Walter, We could update RFC 6415, but we should keep that as a separate activity. That said, is there truly a benefit? No opposition, but I’m not sure if there is a lot of value in doing so. [walter] it is truly mainly aimed at “elevating†JRD to a standalone spec to be more easily referenceable than being nested as a simple appendix in another independent spec. Plus potential minor updates if needed. But no big issue. The relevance of the examples was a question with the current WebFinger draft, too. It would be useful to have real-world examples, I agree. That said, they should be simple ones so as to not loose effect. [walter] agreed. I can try to provide one for federated social networks for the next revision if you/group wish. Paul From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] Sent: Saturday, November 03, 2012 11:22 AM To: Paul E. Jones Cc: Evan Prodromou; apps-discuss@ietf.org; webfinger@googlegroups.com; Mike Jones Subject: Re: [apps-discuss] R: High-level considerations about "webfinger" Thanks Paul! It reminds me of an early discussion we had on this about document-oriented vs API approach. Option 2, probably the best way forward, is a sort of API...we can define parameters etc. If the group sticks with Jrd and the other considerations you made on http redirects etc I do guess this is a clean API (one could even think of POST/PUT/DELETE for this :) ). And it leaves 6415 unchanged and working. Some could say useless if wf/swd merger is created, but actually this way we build something parallel/independent indeed, so 6415 has still its dignity and is not broken into good and bad parts... Personally, for my own view of federated social networks and my OMA hat on, I do would sponsor an 6415-based solution across social network providers for peering and cross-discovery. But I do see value in a new json-based API/endpoint for other use cases and am willing to help. Note that this could actually be view as standardizing the 'Lrdd' endpoint :) (although json-only) so I still see it somehow compatible with the existing 6415 framework...if we name the endpoint .well-known/lrdd we even avoid the wf/swd name battle ;) Moving on towards option 2, I do have still the following concerns: - would the whole activity anyway benefit from slightly updating 6415 in parallel of the wf activity eg to call jrd out of a simple appendix for a cleaner reference (potentially also by other specs in the future), and maybe with other things as well such as cors or else? What is the view of the authors of 6415? - I still see that the most relevant use cases discussed over the last months are actually missing from the text. Fsn, openid connect, auto configuration & 'contact enrichment' are 4 main use cases with very different needs that would deserve being mentioned explicitly. As a side comment, I may be too optimistic/quick but I'd also like to work with whoever is interested at analyzing link rels relevant for the fsn use case in particular and possibly have some of them registered if missing to pave the way for interoperability. Walter Le 3 nov. 2012 à 07:50, "Paul E. Jones" > a écrit : Walter, et al, (Apologizes for the length, but I think we have an important directional decision to make…) I think down below you summarized the situation pretty well. While generalizing, what I think we have are two different camps. There are those who have a preference for RFC 6415 as it’s defined today. There are a list of people who said they like the host-meta approach with host-specific and then separate resource-specific information and the use of templates (notably the one for LRDD). Then there is the group who does not. They just want to issue a single query and get back a single response. The latter group do not like templates and do not want to make two requests. Oh, and they do not care one way or the other about preserving backward-compatibility with RFC 6415. (Now, my statements about the two camps is a generalization, a I said at the outset, and there are opinions that cross boundaries, but this is the cleanest division I can see for the purposes of discussion.) What I’ve tried to do is define a solution that would allow for a single request/response, but would maintain a high-degree of interoperability between this new document and 6415. As I was making changes to the draft and trying to take input, I was trying to think through how I could produce a solution to meet the requirements without a host-meta server modified in any way, except for the addition of “resource†and JRD support. Ignoring the editorial improvements that could be made, I think the current ALT-R1 draft does that. You are entirely correct that this spec is looking more like SWD. There are some very important distinctions, though. For one, SWD returns a single link to a single request. It makes discovering lots of information about somebody a pain, IMO. It’s primary purpose was to support OpenID Connect and it works fine for that, but if I want to ask a sever to “tell me everything you know about Paul Jonesâ€, it cannot. RFC 6415 can, and I like that. The difference is really a matter of the document returned. Also, there is application-level kind of redirect in SWD (or was) that really should be an HTTP-level (3xx). I don’t like that about SWD, either. Back to the two camps: neither is happy with the present solution (the -02 draft). People who like the single request approach like this ALT drafts better because XML is gone, there is a single resource to go query, and, of course, there is a single request/response. People who are in the 6415 camp do are not happy with the -02 draft because we turn “host metadata†into “resource†information: we merge the concepts. They also do not like the ALT drafts for the same reason. However, even the 6415 camp does seem to have an appreciation for a resource-centric approach that can use a single query. They just don’t like the “hack†(my term… that’s the one negative word I don’t think I’ve had thrown in my face ;-) ). I believe you are right to point out that the one thing people seem to be generally OK with is JRD. I think it’s a simple format, nice to work with, useful, and not overly complicated. Given that there are virtually no comments on the format, I gather people share the same sentiment. Now, having had conversations with a number of people both on the list and off, I believe we need to decide which direction to take and I think there are two choices: 1) We discard the current WebFinger draft and continue with RFC 6415 as-is 2) We re-write the spec in the spirit of the ALT versions, completely breaking away from RFC 6415 by a. Removing all references to and dependencies on RFC 6415 b. Defining JRD within the WebFinger spec, specifying such things as “the order of link relations is significant†or other rules we want to apply to the document c. Defining a new resource for this server at /.well-known/webfinger (or swd ?) d. Using no templates whatsoever e. Using the “resource†parameter as the current ALT draft has them (the concept of “host metadata†does not exist with this draft; I’m not sure what the server should do if the resource parameter is absent, though) f. (I would say use the “rel†parameter, too, but some have really expressed dissatisfaction with that. While I think it’s wonderful in order to reduce the number of link relations returned, some just saw no value in that… even on narrow-band network connections.) If I understand the two camps, I think those are the two options before us. I’m sure there may be other things to do for option 2, but you get the gist of where that is headed. More importantly, I am left with the impression that if we do go with option 2, we will get support from both camps. Some of those who are in the 6415 camp just have an objective of not breaking what is there now and some just don’t want the “hack†that is the current WF spec. But, I believe most are all for a clean specification that defines a useful service and that utilizes JRD to provide a set of link relations about a resource; a useful “web discovery protocolâ€. I just want a solution and would not be upset with either solution. What I do not like, though, is having two or three solutions for discovery. At present, we have RFC 6415, current WF draft, SWD, and draft-daboo-agreggated-service-discovery. That’s a few too many ;-) I do have a high opinion of XRD/JRD, so I would like to see either or both of those retained in any solution the group produces. Given that SWD exists, I take it that there is at least enough support to do something other than RFC 6415. I do not fully understand the reasons, except perhaps “we want one round tripâ€. I don’t know. Perhaps someone can educate me on the “whyâ€. But, it does exist, so there is a reason and it means we might end up with two solutions. So, can we avoid that? I’d be ok with putting aside the WF spec in favor a merger between SWD/WF. I don’t want to call this a “compromiseâ€, but rather a clean solution that borrows from both: single round trip (like SWD), a richer response with a set of links (JRD), adheres to and follows HTTP procedures (e.g., no “SWD_service_redirect†type construct; use 3xx), has no templates in the JRD, allows any URI type (including “acct:â€) as the “subject†of the query, and is rooted at the host at some agreed location like /.well-known/swd. I believe if we do this, we have the greatest chance of getting the largest number of people on board. Perhaps Mike or someone serve as editing, but I’d be happy to help co-author. I’ll also write an implementation as I did for RFC 6415; it should be simple to do. In any case, I do think there is a serious risk of failure if we continue down the current WF path, either because we end up with multiple competing solutions or because we alienate one of the two camps. So we either stick with 6415 and stop spending time on this, or create something along the lines of (2) where we can get nearly everyone on board. Paul From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Goix Laurent Walter Sent: Friday, November 02, 2012 11:30 AM To: Evan Prodromou; apps-discuss@ietf.org Subject: [apps-discuss] R: High-level considerations about "webfinger" Hi evan, I do have read the latest alt-r1 draft. But I do believe these are still applicable questions: - I could still see pros/cons in the list for rel/resource parameters in host-meta.json - The question of creating a new endpoint has been raised and still pending imo (also wrt previous bullet) - Relationship with rfc6415 is still not clear as some parts are clearly referenced (mostly procedures) whilst others mention a clear distance with it (eg xrd vs jrd). As a developer I could not know very well whether I need to implement rfc6415 and how much of it…at this point one may consider how much the draft gains in actually referencing those sections if it is to mandate the contrary… o In section 3 it reads “the protocol builds on rfc6415â€, which is very unclear to which extent o Section 5 talks about backward-compatibility but basically says it “may not beâ€. This is mainly to reuse jrd and “host-meta.json†so it may be more appropriate to call them out explicitly without any generic sentence (still if this is the feeling of the group) o Section 5.1 references section 4.2 of rfc6415 but actually introduces some variants, so why not write a clean standalone text with no reference to rfc6415? o Section 5.2 references an “example†of rfc6415 section 1.1.1, but the value of that reference is not clear. Better probably to reference webfinger’s own examples. - the very latest draft is still al “ALT†at this stage… I’m playing the devil’s advocate here but do think that the various camps intend very diverse usages of webfinger that maybe do not benefit of one solution. It is a pity those use cases are not reflected in the simplistic examples: I personally liked the openid one as I think opened connect would be 1 candidate, but I’ve heard about autoconfiguration (see oauth use case) and federated social networks (the whole original point of it). All of them are used in very different contexts (trusted/untrusted, intra-/inter-domain) and will probably distinguish themselves from the actual link rels they will use/expose… walter Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di Evan Prodromou Inviato: venerdì 2 novembre 2012 16.05 A: apps-discuss@ietf.org Oggetto: Re: [apps-discuss] High-level considerations about "webfinger" The conversation has really moved on! I suggest you read Paul Jones's latest email to get caught up. -Evan On 12-11-02 08:02 AM, Goix Laurent Walter wrote: Dear all, I tried to catch up with the hot discussion of the last days and would try to hold on for the time of an email trying to summarize the current situation and take a breath… At this stage we are having very distinct camps in the list for what they have in mind behind the “webfinger†keyword: xml vs json, 1 or 2 roundtrips, privacy ecc. It seems to me that Paul has been doing an outstanding work trying to compromise (I would have lost patience…) but such compromises do not seem to satisfy anyone: actually, compromises are moving more and more towards the original SWD idea at the end. Maybe we could ask ourselves the following questions: - With the “xrd†idea in mind (please, jrd-enthusiasts, try to put that hat on as well), what is actually missing beyond rfc6415 for “webfingerâ€? now the ‘acct’ URI is a separate draft (an initial motivation). Rel/resource parameters for xrd supporters do not seem essential in my understanding neither. So (although I am a supports of that camp) I have trouble seeing what truly need to be added. I can understand Evan’s position for keeping the entire xrd-based community (ostatus, diaspora, etc) but isn’t rfc6415-compliance for those existing implementations already fair enough? If a new “webfinger†is jrd, 1-roundtrip only at the end it’s just another rfc number to be referenced instead/in addition and as such has the same value…(not mentioning the implementation work needed) - Rfc6415-compliance & backward compatibility: this seems also contentious as whether backward-compatibility is needed or not. however the current “compromises†are odd in maintaining backward-compability. What is exactly interesting for “webfinger†from that rfc? From the latest alternative it seems only the “host-meta.json†endpoint name & the jrd. Or else? How these can be referenced at best without needing the whole thing? - Host-meta+lrdd vs new endpoint: Should we propose an alternative endpoint name (there were many proposals, including one of mine a while ago) so that we simply “distinguish†the existing host-meta+lrdd way from a new “webfinger†way/endpoint all-in-1-roundtrip. This is what swd is proposing. Eventually one could at the end use the same backend implementation to return queries coming all the way from host-meta+lrdd than others using another well-known (and direct) endpoint. This would also be much easier to support any query parameter (resource, rel, etc) as some are arguing against overriding host-meta with parameters. In that case the new “webfinger†would be actually more like SWD (with JRD support) - In alternative, what about the provocative idea from Evan to “replace†rfc6415? Are they other usages of rfc6415 than the “webfinger†one throughout the community? If yes, then it may be more difficult to replace unless agreed with whom is using it. Otherwise, as it seems most people do not like it, why keep it as-is and not upgrade directly to whatever is now useful? A standard that is not used is useless and has no point in being superseded by a parallel spec not actually obsoleting it... If JRD and the well-known endpoints are useful in other context, then why not splitting them from the actual protocol procedures of current rfc6415 and have clean specs that can be generically referenced without buying the full thing or writing complex text to select some parts of it and contest others: 1 for JRD and 1 for the endpoints/link registrations. Then a protocol-oriented spec like webfinger can easily decide what to take and replace current rfc6415, or decide ! to live separately/parallel. Personally I have more interest and feeling for the 2-roundtrip xrd solution from rfc6415 still. But if I have to choose between an odd/partial/unstable/unclear/buggy reference to it and a new json way for satisfying another use case I have to put limits in compromising and at this point prefer a parallel/independent approach. Of course I’d like possibly to reuse the file format (jrd) as it seems suitable for all. At least this way rfc6415 can still live independently (being updated or not if we want to make it “cleanerâ€) and “webfinger†can hopefully be finalized quickly in the json + 1 roundtrip direction… Once these macro topics are clarified then we can better discuss the details about securing wf, supporting privacy, distinct delivery for auth/non-auth requests etc…But can we first discuss at high level what we want to achieve in terms of process? Cheers walter 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. Rispetta l'ambiente. Non stampare questa mail se non è necessario. _______________________________________________ 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. Rispetta l'ambiente. Non stampare questa mail se non è necessario. 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. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non è necessario. ------EP4DGX5G5572MLWL4O6DQ4BMX31D70 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

So you want a JRD RFC, not just a JRD section in WF? If so, we need someone to author that immediately.

Paul



From: Goix Laurent Walter <laurentwalter.goix@telecomitalia.it>
Sent: Mon Nov 05 05:57:58 EST 2012
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: 'Evan Prodromou' <evan@status.net>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "webfinger@googlegroups.com" <webfinger@googlegroups.com>, 'Mike Jones' <Michael.Jones@microsoft.com>
Subject: R: [apps-discuss] R: High-level considerations about "webfinger"

Hello Paul,

Comments as [walter]

 

Da: Paul E. Jones [mailto:paulej@packetizer.com]
Inviato: domenica 4 novembre 2012 0.38
A: Goix Laurent Walter
Cc: 'Evan Prodromou'; apps-discuss@ietf.org; webfinger@googlegroups.com; 'Mike Jones'
Oggetto: RE: [apps-discuss] R: High-level considerations about "webfinger"

 

Walter,

 

We could update RFC 6415, but we should keep that as a separate activity. That said, is there truly a benefit?  No opposition, but I’m not sure if there is a lot of value in doing so.

 

[walter] it is truly mainly aimed at “elevating†JRD to a standalone spec to be more easily referenceable than being nested as a simple appendix in another independent spec. Plus potential minor updates if needed. But no big issue.

 

The relevance of the examples was a question with the current WebFinger draft, too.  It would be useful to have real-world examples, I agree.  That said, they should be simple ones so as to not loose effect.

 

[walter] agreed. I can try to provide one for federated social networks for the next revision if you/group wish.

 

Paul

 

From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]
Sent: Saturday, November 03, 2012 11:22 AM
To: Paul E. Jones
Cc: Evan Prodromou; apps-discuss@ietf.org; webfinger@googlegroups.com; Mike Jones
Subject: Re: [apps-discuss] R: High-level considerations about "webfinger"

 

Thanks Paul! It reminds me of an early discussion we had on this about document-oriented vs API approach. Option 2, probably the best way forward, is a sort of API...we can define parameters etc.

If the group sticks with Jrd and the other considerations you made on http redirects etc I do guess this is a clean API (one could even think of POST/PUT/DELETE for this :) ). And it leaves 6415 unchanged and working. Some could say useless if wf/swd merger is created, but actually this way we build something parallel/independent indeed, so 6415 has still its dignity and is not broken into good and bad parts...

 

Personally, for my own view of federated social networks and my OMA hat on,  I do would sponsor an 6415-based solution across social network providers for peering and cross-discovery.

But I do see value in a new json-based API/endpoint for other use cases and am willing to help. Note that this could actually be view as standardizing the 'Lrdd' endpoint :) (although json-only) so I still see it somehow compatible with the existing 6415 framework...if we name the endpoint .well-known/lrdd we even avoid the wf/swd name battle ;)

 

Moving on towards option 2, I do have still the following concerns:

- would the whole activity anyway benefit from slightly updating 6415 in parallel of the wf activity eg to call jrd out of a simple appendix for a cleaner reference (potentially also by other specs in the future), and maybe with other things as well such as cors or else? What is the view of the authors of 6415?

 

- I still see that the most relevant use cases discussed over the last months are actually missing from the text. Fsn, openid connect, auto configuration & 'contact enrichment' are 4 main use cases with very different needs that would deserve being mentioned explicitly.

 

As a side comment, I may be too optimistic/quick but I'd also like to work with whoever is interested at analyzing link rels relevant for the fsn use case in particular and possibly have some of them registered if missing to pave the way for interoperability.

 

Walter

Le 3 nov. 2012 à 07:50, "Paul E. Jones" <paulej@packetizer.com> a écrit :

Walter, et al,

 

(Apologizes for the length, but I think we have an important directional decision to make…)

 

I think down below you summarized the situation pretty well.  While generalizing, what I think we have are two different camps.  There are those who have a preference for RFC 6415 as it’s defined today.  There are a list of people who said they like the host-meta approach with host-specific and then separate resource-specific information and the use of templates (notably the one for LRDD).  Then there is the group who does not.  They just want to issue a single query and get back a single response.  The latter group do not like templates and do not want to make two requests.  Oh, and they do not care one way or the other about preserving backward-compatibility with RFC 6415.  (Now, my statements about the two camps is a generalization, a I said at the outset, and there are opinions that cross boundaries, but this is the cleanest division I can see for the purposes of discussion.)

 

What I’ve tried to do is define a solution that would allow for a single request/response, but would maintain a high-degree of interoperability between this new document and 6415.  As I was making changes to the draft and trying to take input, I was trying to think through how I could produce a solution to meet the requirements without a host-meta server modified in any way, except for the addition of “resource†and JRD support.  Ignoring the editorial improvements that could be made, I think the current ALT-R1 draft does that.

 

You are entirely correct that this spec is looking more like SWD.  There are some very important distinctions, though.  For one, SWD returns a single link to a single request.  It makes discovering lots of information about somebody a pain, IMO.  It’s primary purpose was to support OpenID Connect and it works fine for that, but if I want to ask a sever to “tell me everything you know about Paul Jonesâ€, it cannot.  RFC 6415 can, and I like that.  The difference is really a matter of the document returned.  Also, there is application-level kind of redirect in SWD (or was) that really should be an HTTP-level (3xx).  I don’t like that about SWD, either.

 

Back to the two camps: neither is happy with the present solution (the -02 draft).  People who like the single request approach like this ALT drafts better because XML is gone, there is a single resource to go query, and, of course, there is a single request/response.  People who are in the 6415 camp do are not happy with the -02 draft because we turn “host metadata†into “resource†information: we merge the concepts.  They also do not like the ALT drafts for the same reason.  However, even the 6415 camp does seem to have an appreciation for a resource-centric approach that can use a single query.  They just don’t like the “hack†(my term… that’s the one negative word I don’t think I’ve had thrown in my face ;-) ).

 

I believe you are right to point out that the one thing people seem to be generally OK with is JRD.  I think it’s a simple format, nice to work with, useful, and not overly complicated.  Given that there are virtually no comments on the format, I gather people share the same sentiment.

 

Now, having had conversations with a number of people both on the list and off, I believe we need to decide which direction to take and I think there are two choices:

1)      We discard the current WebFinger draft and continue with RFC 6415 as-is

2)      We re-write the spec in the spirit of the ALT versions, completely breaking away from RFC 6415 by

a.       Removing all references to and dependencies on RFC 6415

b.      Defining JRD within the WebFinger spec, specifying such things as “the order of link relations is significant†or other rules we want to apply to the document

c.       Defining a new resource for this server at /.well-known/webfinger (or swd ?)

d.      Using no templates whatsoever

e.      Using the “resource†parameter as the current ALT draft has them (the concept of “host metadata†does not exist with this draft; I’m not sure what the server should do if the resource parameter is absent, though)

f.        (I would say use the “rel†parameter, too, but some have really expressed dissatisfaction with that.  While I think it’s wonderful in order to reduce the number of link relations returned, some just saw no value in that… even on narrow-band network connections.)

 

If I understand the two camps, I think those are the two options before us.  I’m sure there may be other things to do for option 2, but you get the gist of where that is headed.

 

More importantly, I am left with the impression that if we do go with option 2, we will get support from both camps.  Some of those who are in the 6415 camp just have an objective of not breaking what is there now and some just don’t want the “hack†that is the current WF spec.  But, I believe most are all for a clean specification that defines a useful service and that utilizes JRD to provide a set of link relations about a resource; a useful “web discovery protocolâ€.

 

I just want a solution and would not be upset with either solution.  What I do not like, though, is having two or three solutions for discovery.  At present, we have RFC 6415, current WF draft, SWD, and  draft-daboo-agreggated-service-discovery.  That’s a few too many ;-)

 

I do have a high opinion of XRD/JRD, so I would like to see either or both of those retained in any solution the group produces.

 

Given that SWD exists, I take it that there is at least enough support to do something other than RFC 6415. I do not fully understand the reasons, except perhaps “we want one round tripâ€. I don’t know.  Perhaps someone can educate me on the “whyâ€.  But, it does exist, so there is a reason and it means we might end up with two solutions.

 

So, can we avoid that?  I’d be ok with putting aside the WF spec in favor a merger between SWD/WF.  I don’t want to call this a “compromiseâ€, but rather a clean solution that borrows from both: single round trip (like SWD), a richer response with a set of links (JRD), adheres to and follows HTTP procedures (e.g., no “SWD_service_redirect†type construct; use 3xx), has no templates in the JRD, allows any URI type (including “acct:â€) as the “subject†of the query, and is rooted at the host at some agreed location like /.well-known/swd.

 

I believe if we do this, we have the greatest chance of getting the largest number of people on board.  Perhaps Mike or someone serve as editing, but I’d be happy to help co-author.  I’ll also write an implementation as I did for RFC 6415; it should be simple to do.

 

In any case, I do think there is a serious risk of failure if we continue down the current WF path, either because we end up with multiple competing solutions or because we alienate one of the two camps.  So we either stick with 6415 and stop spending time on this, or create something along the lines of (2) where we can get nearly everyone on board.

 

Paul

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Goix Laurent Walter
Sent: Friday, November 02, 2012 11:30 AM
To: Evan Prodromou; apps-discuss@ietf.org
Subject: [apps-discuss] R: High-level considerations about "webfinger"

 

Hi evan,

 

I do have read the latest alt-r1 draft. But I do believe these are still applicable questions:

-          I could still see pros/cons in the list for rel/resource parameters in host-meta.json

-          The question of creating a new endpoint has been raised and still pending imo (also wrt previous bullet)

-          Relationship with rfc6415 is still not clear as some parts are clearly referenced (mostly procedures) whilst others mention a clear distance with it (eg xrd vs jrd). As a developer I could not know very well whether I need to implement rfc6415 and how much of it…at this point one may consider how much the draft gains in actually referencing those sections if it is to mandate the contrary…

o   In section 3 it reads “the protocol builds on rfc6415â€, which is very unclear to which extent

o   Section 5 talks about backward-compatibility but basically says it “may not beâ€. This is mainly to reuse jrd and “host-meta.json†so it may be more appropriate to call them out explicitly without any generic sentence (still if this is the feeling of the group)

o   Section 5.1 references section 4.2 of rfc6415 but actually introduces some variants, so why not write a clean standalone text with no reference to rfc6415?

o   Section 5.2 references an “example†of rfc6415 section 1.1.1, but the value of that reference is not clear. Better probably to reference webfinger’s own examples.

-          the very latest draft is still al “ALT†at this stage…

 

I’m playing the devil’s advocate here but do think that the various camps intend very diverse usages of webfinger that maybe do not benefit of one solution. It is a pity those use cases are not reflected in the simplistic examples: I personally liked the openid one as I think opened connect would be 1 candidate, but I’ve heard about autoconfiguration (see oauth use case) and federated social networks (the whole original point of it). All of them are used in very different contexts (trusted/untrusted, intra-/inter-domain) and will probably distinguish themselves from the actual link rels they will use/expose…

 

walter

 

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di Evan Prodromou
Inviato: venerdì 2 novembre 2012 16.05
A: apps-discuss@ietf.org
Oggetto: Re: [apps-discuss] High-level considerations about "webfinger"

 

The conversation has really moved on! I suggest you read Paul Jones's latest email to get caught up.

-Evan

On 12-11-02 08:02 AM, Goix Laurent Walter wrote:

Dear all,

 

I tried to catch up with the hot discussion of the last days and would try to hold on for the time of an email trying to summarize the current situation and take a breath…

 

At this stage we are having very distinct camps in the list for what they have in mind behind the “webfinger†keyword: xml vs json, 1 or 2 roundtrips, privacy ecc. It seems to me that Paul has been doing an outstanding work trying to compromise (I would have lost patience…) but such compromises do not seem to satisfy anyone: actually, compromises are moving more and more towards the original SWD idea at the end.

 

Maybe we could ask ourselves the following questions:

-          With the “xrd†idea in mind (please, jrd-enthusiasts, try to put that hat on as well), what is actually missing beyond rfc6415 for “webfingerâ€? now the ‘acct’ URI is a separate draft (an initial motivation). Rel/resource parameters for xrd supporters do not seem essential in my understanding neither. So (although I am a supports of that camp) I have trouble seeing what truly need to be added. I can understand Evan’s position for keeping the entire xrd-based community (ostatus, diaspora, etc) but isn’t rfc6415-compliance for those existing implementations already fair enough? If a new “webfinger†is jrd, 1-roundtrip only at the end it’s just another rfc number to be referenced instead/in addition and as such has the same value…(not mentioning the implementation work needed)

 

-          Rfc6415-compliance & backward compatibility: this seems also contentious as whether backward-compatibility is needed or not. however the current “compromises†are odd in maintaining backward-compability. What is exactly interesting for “webfinger†from that rfc? From the latest alternative it seems only the “host-meta.json†endpoint name & the jrd. Or else? How these can be referenced at best without needing the whole thing?

 

-          Host-meta+lrdd vs new endpoint: Should we propose an alternative endpoint name (there were many proposals, including one of mine a while ago) so that we simply “distinguish†the existing host-meta+lrdd way from a new “webfinger†way/endpoint all-in-1-roundtrip. This is what swd is proposing. Eventually one could at the end use the same backend implementation to return queries coming all the way from host-meta+lrdd than others using another well-known (and direct) endpoint. This would also be much easier to support any query parameter (resource, rel, etc) as some are arguing against overriding host-meta with parameters. In that case the new “webfinger†would be actually more like SWD (with JRD support)

 

-          In alternative, what about the provocative idea from Evan to “replace†rfc6415? Are they other usages of rfc6415 than the “webfinger†one throughout the community? If yes, then it may be more difficult to replace unless agreed with whom is using it. Otherwise, as it seems most people do not like it, why keep it as-is and not upgrade directly to whatever is now useful? A standard that is not used is useless and has no point in being superseded by a parallel spec not actually obsoleting it... If JRD and the well-known endpoints are useful in other context, then why not splitting them from the actual protocol procedures of current rfc6415 and have clean specs that can be generically referenced without buying the full thing or writing complex text to select some parts of it and contest others: 1 for JRD and 1 for the endpoints/link registrations. Then a protocol-oriented spec like webfinger can easily decide what to take and replace current rfc6415, or decide to live separately/parallel.

 

 

Personally I have more interest and feeling for the 2-roundtrip xrd solution from rfc6415 still. But if I have to choose between an odd/partial/unstable/unclear/buggy reference to it and a new json way for satisfying another use case I have to put limits in compromising and at this point prefer a parallel/independent approach. Of course I’d like possibly to reuse the file format (jrd) as it seems suitable for all. At least this way rfc6415 can still live independently (being updated or not if we want to make it “cleanerâ€) and “webfinger†can hopefully be finalized quickly in the json + 1 roundtrip direction…

 

Once these macro topics are clarified then we can better discuss the details about securing wf, supporting privacy, distinct delivery for auth/non-auth requests etc…But can we first discuss at high level what we want to achieve in terms of process?

 

Cheers

walter

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 è necessario. 



_______________________________________________
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 è necessario.

 

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.

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è necessario.

------EP4DGX5G5572MLWL4O6DQ4BMX31D70-- From internet-drafts@ietf.org Mon Nov 5 07:54: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 5608E21F8A5C; Mon, 5 Nov 2012 07:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 0umqXEOKLkCP; Mon, 5 Nov 2012 07:54:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD5721F884B; Mon, 5 Nov 2012 07:54:12 -0800 (PST) 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.35 Message-ID: <20121105155412.4054.20989.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 07:54:12 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-08.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, 05 Nov 2012 15:54:47 -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 : Additional Media Type Structured Syntax Suffixes Author(s) : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-media-type-suffix-regs-08.txt Pages : 16 Date : 2012-11-05 Abstract: A content media type name sometimes includes partitioned meta- information distinguish by a Structured Syntax, to permit noting an attribute of the media as a suffix to the name. This document defines several Structured Syntax Suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax Suffixes, and provides a Message Type Structured Syntax Suffix registration form for the "+xml" Structured Syntax Suffix. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-media-type-suffix-reg= s-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bradfitz@google.com Sun Nov 4 14:06: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 07A7921F855A for ; Sun, 4 Nov 2012 14:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.22 X-Spam-Level: X-Spam-Status: No, score=-102.22 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 ofblWqWD6h5T for ; Sun, 4 Nov 2012 14:06:22 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id E4C5521F84AF for ; Sun, 4 Nov 2012 14:06:21 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so5581511oag.31 for ; Sun, 04 Nov 2012 14:06:20 -0800 (PST) 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=UoGCEPriCNhCK2zl044yNpAmMli39AnuJF8Dcrbtoas=; b=jXCtO1sZHDkB13yhdgj4NPuNCeYTXFGsXSc6jTFec/rSFyQc8qwsUK9yBju5WzoapK n4mfgB70X8STqDWuGFigvYnl3CbAwBecpEoQ6K5xlUwZVxUlQ73y6KDiLLWX2VG5D2SQ 3j0VTkhtrEXyipK1l5pihjlZdif1M0aoMInTqzHjQNVhTdwRxhvw8O/m0CBnHLbnZlbQ +y6KFX2S71m3Udr8Ogjs9y2HVnceIaw7jypAVTjZJSzK2mKTV6d140ZIRCKjFO2izO4K pTvSx6/NS72szzKOw1R9lKFy+Z4CIUPd16TEM0r9hOqr5LJUN1/DXMedzzyLItmSQkZ2 gbqg== 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=UoGCEPriCNhCK2zl044yNpAmMli39AnuJF8Dcrbtoas=; b=fPkEy3XhF0fY4ya+r8SWSiwKyhyVQUqOp+Tf91Kxcmde9aj5ZbsxDv2vuWWuCeEO2r RuNgpHE0Zb7GEJ+BZgA7W15fRBMwHXItEPdU+zEOQ+klvfAOUWYAv9cHBaoyiMC9DCDo mCjxcrKeKoAu1ySghcZv7nCSq3OR1kRCgCiC4XFtFFz8i0TMzoi7qH6g7hezoOd77Giv gw1SsbHMxwIHfW0JJmdyOQSeeYzTZjerdjIjVFzmBLCeH3bRSMitlefHNfQnHYrwVU5x RoBaLE/pn4R1zJVYi8DuOrUtDTIX4+E4MGn49P/5vmxS1MRtM3z+T1n52c2ksc1oBeGI CU3w== MIME-Version: 1.0 Received: by 10.60.172.138 with SMTP id bc10mr6589394oec.33.1352066780434; Sun, 04 Nov 2012 14:06:20 -0800 (PST) Received: by 10.60.31.41 with HTTP; Sun, 4 Nov 2012 14:06:20 -0800 (PST) In-Reply-To: <072201cdbaad$78513970$68f3ac50$@packetizer.com> References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <072201cdbaad$78513970$68f3ac50$@packetizer.com> Date: Sun, 4 Nov 2012 23:06:20 +0100 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=bcaec54d41a8290f6f04cdb29466 X-System-Of-Record: true X-Gm-Message-State: ALoCoQktR8oNXxqbBET7A0CmAE5JHMnGeMFGy06gryS+CDee7gtoaNh/mcn4VP2bfPPtlkq7LfKai6a6o15NMxuu8VBvJUYOmyWJ7ZgyugR4oDmwABtos2KHVNksyKm1p4ToUzY7e93zTZyLNYSrVDgWSfff2zShUmvEoTL4PXnEXICCSA5dIIeIfJP2zDBC3GBqScTaOXNK X-Mailman-Approved-At: Mon, 05 Nov 2012 08:08:11 -0800 Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 04 Nov 2012 22:06:27 -0000 --bcaec54d41a8290f6f04cdb29466 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Nov 4, 2012 at 5:57 PM, Paul E. Jones wrote= : > > $ curl -v 'https://packetizer.com/.well-known/webfinger? > resource=3Dacct:paulej@packetizer.com& > rel=3Dvcard' > -- returns a JRD for the specified resource, filtered to include only > the space-separated list of link relations in the "rel" parameter**** > > ** ** > > Why space-separated? I can live with that, but it seems like the more > natural thing to do would be to use multiple rel parameters:**** > > ** ** > > webfinger?resource=3Dbob&rel=3Dvcard&rel=3Dblog&rel=3Dopenid.server**** > > ** ** > > PEJ: The reason for space-separating was to be consistent with HTML. > That=E2=80=99s exactly how you=E2=80=99ll find multiple link relation val= ues appearing in > an HTML document. An issue with using the same parameter multiple times = in > the URL is that I suspect many (or most) protocol libraries would either > take the first one or the last one it sees and discard the others. > But URLs aren't HTML (or JSON, or XML), and as Christian said: URLs can contain %20. Let's consider your real fear, that HTTP libraries suck at multiple parameters, first for a server and then for a client: For a server: a) Servers are generally written by more competent people. So they probably know how to use their language's HTTP library properly. All languages and frameworks I've ever seen let you do it. b) Support for rel is only a SHOULD. Even if a server ignores it, they're still compliant. c) The common case will be clients requesting 0 (all) or 1 rel anyway. For a client: a) The common case will be clients requesting 0 (all) or 1 rel anyway. b) If they want to filter on 2 or more, they can read some docs. Alternatively, they can request no filter and get all the rel/value pairs and do their own filtering, wasting a bit of bandwidth. I'm really not worried. Space separated seems like a hack. But I have a good card to play now: If we go with space-separated rel parameters, I'll endeavor to introduce rel URLs containing spaces, just to confuse clients. I can see it now: "Appendix A: recommended algorithm for string splitting on whitespace, re-joining fragments which don't begin with 'http' with their preceeding fragment." Or maybe some spec already says rel URLs can't contain " ", %20, or +? If so, we'd want to reinforce that in the webfinger spec. If not, I'd especially want to avoid space separation. But I'm happy we're down to discussing something as boring as this. I absolutely love the recent change of direction to a radically simplified spec. --bcaec54d41a8290f6f04cdb29466 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Sun, Nov 4, 2012 at 5:57 PM, Paul E. Jones <paulej@packetizer.com> wrote:


$ curl -v 'https://packetizer.com/.well-known/webfinger?
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0resource=3Dacct:paulej@packetizer.com&
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rel=3Dvcard'
-- returns a J= RD for the specified resource, filtered to include only
=C2=A0 =C2=A0the= space-separated list of link relations in the "rel" parameter=

=C2=A0

Why space-separated? =C2=A0I can live wi= th that, but it seems like the more natural thing to do would be to use mul= tiple rel parameters:

=C2=A0

webfinger?resource=3Dbob&= rel=3Dvcard&rel=3Dblog&rel=3Dopenid.server

=C2= =A0

PEJ:= The reason for space-separating was to be consistent with HTML.=C2=A0 That= =E2=80=99s exactly how you=E2=80=99ll find multiple link relation values ap= pearing in an HTML document.=C2=A0 An issue with using the same parameter m= ultiple times in the URL is that I suspect many (or most) protocol librarie= s would either take the first one or the last one it sees and discard the o= thers.


But URLs aren't HTML= (or JSON, or XML), and as Christian said: URLs can contain %20.
=
Let's consider your real fear, that HTTP libraries suck = at multiple parameters, first for a server and then for a client:

For a server:
a) Servers are generally written by = more competent people. =C2=A0So they probably know how to use their languag= e's HTTP library properly. =C2=A0All languages and frameworks I've = ever seen let you do it.
b) Support for rel is only a SHOULD. =C2=A0Even if a server ignores it= , they're still compliant.
c) The common case will be clients= requesting 0 (all) or 1 rel anyway.

For a client:=
a)=C2=A0The common case will be clients requesting 0 (all) or 1 = rel anyway.
b) If they want to filter on 2 or more, they can read= some docs. =C2=A0Alternatively, they can request no filter and get all the= rel/value pairs and do their own filtering, wasting a bit of bandwidth.

I'm really not worried.

Sp= ace separated seems like a hack.

But I have a good= card to play now: =C2=A0If we go with space-separated rel parameters, I= 9;ll endeavor to introduce rel URLs containing spaces, just to confuse clie= nts. =C2=A0I can see it now: "Appendix A: recommended algorithm for st= ring splitting on whitespace, re-joining fragments which don't begin wi= th 'http' with their preceeding fragment."

Or maybe some spec already says rel URLs can't cont= ain " ", %20, or +? =C2=A0If so, we'd want to reinforce that = in the webfinger spec. =C2=A0If not, I'd especially want to avoid space= separation.

But I'm happy we're down to discussing somethin= g as boring as this. =C2=A0I absolutely love the recent change of direction= to a radically simplified spec.
--bcaec54d41a8290f6f04cdb29466-- From bradfitz@google.com Sun Nov 4 14:07: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 8C73F21F84E3 for ; Sun, 4 Nov 2012 14:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.09 X-Spam-Level: X-Spam-Status: No, score=-101.09 tagged_above=-999 required=5 tests=[AWL=-1.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, MANGLED_OFF=2.3, 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 4ZNbSZFp7hYA for ; Sun, 4 Nov 2012 14:07:33 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5FC21F84AF for ; Sun, 4 Nov 2012 14:07:33 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id v19so5523120obq.31 for ; Sun, 04 Nov 2012 14:07:32 -0800 (PST) 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=kqWrTuJ1mfuxgUqsxR3elzms1567gDWKlFEYtJ7/bc8=; b=b1WV46QiR0l7fJbTbs99kK1HVHKnQia3bNuxW/XBB23003q99KbOjgVhTlEDSrkY1O QOaNpr7Ox45MneTbXVNMPlYtM5l2axkEqUvPRMwvzGWThhdsdp10fDOQYoJQJkeJkk4I vKCRsgouaPwjCfyJRjAY5RweKxBHvbLa8RVfjPynfaa903fuAm/AMpV7fe7TgiLTrmtu PyP6oY+J6VT1qFfEhONuruPxP0UXCYKQX1JGO3GpuBYFkfOytt5+FzpoRSxnqxoOd4jg kTp+Es+p/uqet3sbxI+8VtzpWUtAW2P5zxS/ysBaBZFeyNKbZ2S8vmOud9Q6wz3xp5LL 6SBA== 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=kqWrTuJ1mfuxgUqsxR3elzms1567gDWKlFEYtJ7/bc8=; b=PWHuTumIRmTAYMItgVZHNJ5TGQI3083oArxS7aff0rlAgdMuKOQv1mL1bWQm4xxPcD YBiTXnEh8ydIm+pU5MwrWRuDYej7LpmuzxXx86MlU1BZDCrWsAFxTKbxFV2Sifv2Gbpt RAcmPTXN6x4mxSP9sPwddmSzsGFcq8uNvtIRsRfkdqlsoFajj++1QWd0I4zaN2JnJ83v Fq6uxnzzdgZtUeqHXAuyEPwgtKKsngTwkoIUrH2I7q7NhP1n329FwvjaCc2HCq+m11bC 64Mxsa63n+Mq/VDZzOlTRjdA1fuWejCTAXo2UD64fw0tF7GIEJNx7qikXlemu0ovWf/1 /RIQ== MIME-Version: 1.0 Received: by 10.60.31.101 with SMTP id z5mr6616243oeh.110.1352066852675; Sun, 04 Nov 2012 14:07:32 -0800 (PST) Received: by 10.60.31.41 with HTTP; Sun, 4 Nov 2012 14:07:32 -0800 (PST) In-Reply-To: <20121104190826.4f1c1509@bogo> References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <20121104104228.5a49c685@bogo> <074701cdbab0$5d9f3de0$18ddb9a0$@packetizer.com> <20121104190826.4f1c1509@bogo> Date: Sun, 4 Nov 2012 23:07:32 +0100 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8fb1f19677606804cdb2984a X-System-Of-Record: true X-Gm-Message-State: ALoCoQkmcQ7Lq6U5ARCUYg//oWNnNx9bZrZyh3pNk/amdBofv5lUPlzHEX+/jFI5tslDz6+JraAnmP1BtIsrKULrF1UdJwzwQ1TtEwC/s+2ZiqOp+L6f/NTdsHs1aLqPJRAgZq/cwrmoPpcJaKczSMrZ2RFw4aS/YZxTU4o0QyEMp5EN1xaD3+a3W3TqRZk9AsIwD4SsxvKv X-Mailman-Approved-At: Mon, 05 Nov 2012 08:08:26 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 04 Nov 2012 22:07:33 -0000 --e89a8fb1f19677606804cdb2984a Content-Type: text/plain; charset=UTF-8 On Sun, Nov 4, 2012 at 7:08 PM, Christian Weiske wrote: > > PHP uses [] to "add" to the parameter, e.g. > > &f[]=a&f[]=b&f[]=c > > so you get a GET array of > > f = array(a, b, c) > I hope you're not proposing either a) using brackets in URL parameters, and/or b) letting PHP influence anything --e89a8fb1f19677606804cdb2984a Content-Type: text/html; charset=UTF-8
On Sun, Nov 4, 2012 at 7:08 PM, Christian Weiske <cweiske@cweiske.de> wrote:

PHP uses [] to "add" to the parameter, e.g.
> &f[]=a&f[]=b&f[]=c

so you get a GET array of
> f = array(a, b, c)

I hope you're not proposing either

a) using brackets in URL parameters, and/or
b) letting PHP influence anything

--e89a8fb1f19677606804cdb2984a-- From dick.hardt@gmail.com Sun Nov 4 14:43: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 EE8F421F8787 for ; Sun, 4 Nov 2012 14:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 VAQ72yogvfZH for ; Sun, 4 Nov 2012 14:43:46 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D01F21F8785 for ; Sun, 4 Nov 2012 14:43:46 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so3472270pbb.31 for ; Sun, 04 Nov 2012 14:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=ZxGcfmxsa3WNAG8C4JU6yIpso19x7ir5yctt6bXnxnY=; b=QhRIiUf2kLMHEd2AXnXHmdXz29bAt/rPk8eFmEdpcTAmAAabevsRY+8lRbxvTjO/fo mhdK/g4haKV/a3Nq7vCqDE2ZuDZ2B4/1MRyaOCQTJ/QbfQRi6PuflKoJyPGAkA2axjhc A92u8AotWlmN4Yhk7mvJg3BHZl4VMCT6/1BUzvkoD2W5UwnAGEmjpJjgur6QzWA6dfs4 BbgBgLdZCvEwdVPOgNLRfkVkTNYqoLPcRWMNcO9nwpMQBrX1cufcFCosThOOmpwjQnPU HS8e72pZY3XqqeEoxkfMZ1jgF8MRM/HijBfRxExvMF6IbWRWGKpm1E5Vo/T1rxFanZYV Ylyg== Received: by 10.68.224.138 with SMTP id rc10mr25222325pbc.34.1352069026220; Sun, 04 Nov 2012 14:43:46 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id lb4sm9463994pbc.6.2012.11.04.14.43.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Nov 2012 14:43:45 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F99559A0-6623-4410-811E-0AD89F8AA7C6" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Sun, 4 Nov 2012 14:43:42 -0800 Message-Id: <25D6EBEE-EABF-4321-AACE-74E2F8B49DD9@gmail.com> References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <072201cdbaad$78513970$68f3ac50$@packetizer.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Mon, 05 Nov 2012 08:09:15 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 04 Nov 2012 22:43:47 -0000 --Apple-Mail=_F99559A0-6623-4410-811E-0AD89F8AA7C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 4, 2012, at 2:06 PM, Brad Fitzpatrick = wrote: >=20 > Space separated seems like a hack. FWIW, space delimited values are used in OAuth 2.0 requests to separate = multiple scopes. I don't recall why it ended up being spaces. Personally I like multiple rel parameters as I think it will occur once = or zero times as Brad suggests. -- Dick --Apple-Mail=_F99559A0-6623-4410-811E-0AD89F8AA7C6 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Nov 4, 2012, at 2:06 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:

Space separated seems like a hack.

FWIW, space delimited values are used in OAuth 2.0 requests to separate multiple scopes. I don't recall why it ended up being spaces.

Personally I like multiple rel parameters as I think it will occur once or zero times as Brad suggests.

-- Dick

--Apple-Mail=_F99559A0-6623-4410-811E-0AD89F8AA7C6-- From dick.hardt@gmail.com Sun Nov 4 19:47: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 0EED821F8981 for ; Sun, 4 Nov 2012 19:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.82 X-Spam-Level: X-Spam-Status: No, score=-3.82 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 s-zO3WAbd-3n for ; Sun, 4 Nov 2012 19:47:06 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7329821F89B2 for ; Sun, 4 Nov 2012 19:47:06 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so2472532dan.31 for ; Sun, 04 Nov 2012 19:47:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=+9xfVTs1tAzeUEfzuQGxjyJnrP7wlMkAYCDETG90d7A=; b=fpdc0G9gICwiPY1HABJY7JFcbfPS0PRJ0Uo4Tmautr4rB0ytoH77wmePQ1L8mgZNdQ zc83o2IeZvEyfBi+HfKoIPyAZWWYT6ekDay38dFJOYLGMR5UDfcICmGqQ6iDB2vBTS/7 ydTEzXWPlRabfWA4JTIJvydfLEvkgqRjQU7oN3rZLwdxnLk3eNz9I7tvUq0vxOK8UZ9z D8/bj6GhG9V3s+lVXzNYperFIVEWDg6qFizYXuKazd4GpI3/G0Q1YyE/ABtraAN8C3JT gbhc79sCuBq0XT1Bx8DiEeBa/lY1LO44Op1AVR9B/gaThVsOn03GQdssd8jjayGCBk7f OXtg== Received: by 10.68.131.8 with SMTP id oi8mr26802253pbb.29.1352087226168; Sun, 04 Nov 2012 19:47:06 -0800 (PST) Received: from [10.0.0.58] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id n7sm9889725pav.26.2012.11.04.19.46.55 (version=SSLv3 cipher=OTHER); Sun, 04 Nov 2012 19:47:04 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5DEB313A-3D27-4B67-8CE0-139AB3BBEB47" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <509728A6.3070800@packetizer.com> Date: Sun, 4 Nov 2012 19:47:04 -0800 Message-Id: <2C2E8C60-6405-403B-95EE-E1BCDADE85F4@gmail.com> References: <061d01cdba23$d174d910$745e8b30$@packetizer.com> <1352004496.14504.YahooMailNeo@web31813.mail.mud.yahoo.com> <06cf01cdbaa6$05ad8dd0$1108a970$@packetizer.com> <1352047648.61656.YahooMailNeo@web31813.mail.mud.yahoo.com> <074901cdbab1$9b991110$d2cb3330$@packetizer.com> <1352052871.46114.YahooMailNeo@web31811.mail.mud.yahoo.com> <509728A6.3070800@packetizer.com> To: webfinger@googlegroups.com, "Paul E. Jones" X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Mon, 05 Nov 2012 08:09:26 -0800 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The /.well-known/webfinger resource 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, 05 Nov 2012 03:47:07 -0000 --Apple-Mail=_5DEB313A-3D27-4B67-8CE0-139AB3BBEB47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Not being in the meeting, wanted to give a +1 to this simplification. On Nov 4, 2012, at 6:47 PM, "Paul E. Jones" = wrote: > On 11/4/2012 1:14 PM, William Mills wrote: >> AH! OK, this is exactly the answer, host-meta is for generally = advertised information, webfinger requires a resource. Worth a mention = in the spec? >=20 > Possibly... so long as that mention does not cause a divide among the = interested parties :-) >=20 > If we draft a new spec around those points I listed in the previous = email (the option (2) list), then we could consider inserting that. = This will be a clean break from RFC 6415, whereas the current WF spec is = heavily dependent on RFC 6415. >=20 > We'll discuss this in the meeting tomorrow and see what the group = thinks. >=20 > Paul >=20 --Apple-Mail=_5DEB313A-3D27-4B67-8CE0-139AB3BBEB47 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Not being in the meeting, wanted to give a +1 to this simplification.

On Nov 4, 2012, at 6:47 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:

On 11/4/2012 1:14 PM, William Mills wrote:
AH!  OK, this is exactly the answer, host-meta is for generally advertised information, webfinger requires a resource.  Worth a mention in the spec?

Possibly... so long as that mention does not cause a divide among the interested parties :-)

If we draft a new spec around those points I listed in the previous email (the option (2) list), then we could consider inserting that.  This will be a clean break from RFC 6415, whereas the current WF spec is heavily dependent on RFC 6415.

We'll discuss this in the meeting tomorrow and see what the group thinks.

Paul


--Apple-Mail=_5DEB313A-3D27-4B67-8CE0-139AB3BBEB47-- From salvatore.loreto@ericsson.com Mon Nov 5 09: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 4012D21F84F3 for ; Mon, 5 Nov 2012 09:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.937 X-Spam-Level: X-Spam-Status: No, score=-105.937 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 G-7bugTLeZiR for ; Mon, 5 Nov 2012 09:21:01 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 22DE921F8552 for ; Mon, 5 Nov 2012 09:21:00 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-d3-5097f577080e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DC.8D.26143.775F7905; Mon, 5 Nov 2012 18:20:55 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Mon, 5 Nov 2012 18:20:54 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CC3632ABF for ; Mon, 5 Nov 2012 19:20:54 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0FA3753B70 for ; Mon, 5 Nov 2012 19:20:54 +0200 (EET) Received: from dhcp-12c3.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 87C5C4F356 for ; Mon, 5 Nov 2012 19:20:53 +0200 (EET) Message-ID: <5097F575.6080007@ericsson.com> Date: Mon, 5 Nov 2012 12:20:53 -0500 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Content-Type: multipart/alternative; boundary="------------040801070308000005080604" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+JvjW751+kBBiePKFmsfrmCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGSfaOpgLfolVnFyd0MD4VLCLkYNDQsBEYslG7i5GTiBTTOLC vfVsXYxcHEICJxklZqw4DOWsZ5S4Mf0QK4RzjVFi78z7zHBl2x7+YoRzWpbeYQYZxiugLXF2 7wkmEJtFQEXi37mHbCA2m4CZxPOHW8BqRAWSJdZ+esIOUS8ocXLmExYQW0TAWGLS5iVsIPcJ C2hJ9K4Aa2UWCJO4MHM1E8StahJXz20CGyMEUnK2k2kCo+AsJJNmIWmBsG0lLsy5DhWXl9j+ dg4zhK0rceH/FBTxBYxsqxjZcxMzc9LLjTYxAgP54JbfqjsY75wTOcQozcGiJM5rvXWPv5BA emJJanZqakFqUXxRaU5q8SFGJg5OqQbG9hdyH5t7JmxuMg+VWGfh+CG28W6jlcib3T8bNlqo Sby475E0mbvm51nFclYJxaffUvq+bdLX2iRQ8qj93t2rJ/I/L2G9rjaZqbTgz4pFCs/vejLN v8vFFOMuGxTvkxLM/LziwLaf0azKahP5zpU/SxHxM3tiF3OwPVD34a3JksWLak7+jv2oxFKc kWioxVxUnAgAY3snyDICAAA= Subject: [apps-discuss] ENUM-ACCT-URI draft - way forward 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, 05 Nov 2012 17:21:03 -0000 --------------040801070308000005080604 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit today at the APPSA wg meeting Kepeng Li gave an update of " ENUM Service Registration for acct URI" draft Abstract This document registers a Telephone Number Mapping (ENUM) service for 'acct:' URIs (Uniform Resource Identifiers). (see: http://tools.ietf.org/html/draft-goix-appsawg-enum-acct-uri-00 ) Kepeng also asked for suggestions on how to progress this draft, two possibilities 1. adopt this draft as wg item in APPSA wg , as this is the place that is already taking care of webfinger and acct-uri 2. go straight for an ENUM expert review and an APP (?) AD sponsorship we are looking for feedback, comments and suggestions. Please provide your thoughts to the mailing list thank a lot cheers Salvatore -- Salvatore Loreto, PhD www.sloreto.com --------------040801070308000005080604 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
today at the APPSA wg meeting
Kepeng Li gave an update of " ENUM Service Registration for acct URI" draft

Abstract

   This document registers a Telephone Number Mapping (ENUM) service for
   'acct:' URIs (Uniform Resource Identifiers).

(see: http://tools.ietf.org/html/draft-goix-appsawg-enum-acct-uri-00 )

Kepeng also asked for suggestions on how to progress this draft,
two possibilities

  1.  adopt this draft as wg item in APPSA wg , as this is the place that is already taking
    care of webfinger and acct-uri

  2. go straight for an ENUM expert review and an APP (?) AD sponsorship

we are looking for feedback, comments and suggestions.
Please provide your thoughts to the mailing list

thank a lot

cheers
Salvatore
-- 
Salvatore Loreto, PhD
www.sloreto.com
--------------040801070308000005080604-- From superuser@gmail.com Mon Nov 5 10:12: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 739DB21F8792 for ; Mon, 5 Nov 2012 10:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.160, 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 uZq1PvuF15xW for ; Mon, 5 Nov 2012 10:12:19 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5244621F856E for ; Mon, 5 Nov 2012 10:12:19 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so4693467lbo.31 for ; Mon, 05 Nov 2012 10:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2Jj7AUpxm34lAnVRyOXh6gRDniy9n59ilvb9ryWtsQs=; b=EbM1rJqpf01RjDJXYx0BRH78zE5cnwiljJelmla8vsfdWRrlsOLAefX3jLZjIjIVSb XFKTe6QYDvXHcUHx8IScG3z2LWBEumUHap8oxtg+iMuIIAdKTBpdNRl/eY4PloK660ei Jqcg0UxcxHnU1WHVWmLkJQOCtBvO27Umw079fbWH1xlW9tgRNbyqBCwUwyvrxCaru2su Xz4YSVHM2xkXwem/M60isd2aT5j/DOfPtKPq1dfORetJOeL5q+6DsIbu/F9w15r23xYN 8KX8HR/wxwuA9hPzmSbvQsuyrAabaLI/bMdqTRAFZG1DRXbfv8IIRdVVVEi8lfIWUOw0 3nfw== MIME-Version: 1.0 Received: by 10.112.40.42 with SMTP id u10mr4243194lbk.124.1352139138140; Mon, 05 Nov 2012 10:12:18 -0800 (PST) Received: by 10.112.83.232 with HTTP; Mon, 5 Nov 2012 10:12:18 -0800 (PST) Date: Mon, 5 Nov 2012 13:12:18 -0500 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=e0cb4efe30f4040bf904cdc36d1a Subject: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-json-pointer and draft-ietf-appsawg-json-patch 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, 05 Nov 2012 18:12:20 -0000 --e0cb4efe30f4040bf904cdc36d1a Content-Type: text/plain; charset=ISO-8859-1 As announced during today's meeting in Atlanta, the above two documents are now in Working Group Last Call, ending November 23rd. Please review the documents and provide feedback to the list, the chairs, or the editors. -MSK, APPSAWG co-chair --e0cb4efe30f4040bf904cdc36d1a Content-Type: text/html; charset=ISO-8859-1 As announced during today's meeting in Atlanta, the above two documents are now in Working Group Last Call, ending November 23rd.

Please review the documents and provide feedback to the list, the chairs, or the editors.

-MSK, APPSAWG co-chair

--e0cb4efe30f4040bf904cdc36d1a-- From paulej@packetizer.com Mon Nov 5 11:24: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 895AE21F84D2 for ; Mon, 5 Nov 2012 11:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] 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 PotguQa-UeFS for ; Mon, 5 Nov 2012 11:24:04 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2715C21F84A8 for ; Mon, 5 Nov 2012 11:24:04 -0800 (PST) Received: from dhcp-10a7.meeting.ietf.org (dhcp-10a7.meeting.ietf.org [130.129.16.167]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qA5JO0YU000418 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 5 Nov 2012 14:24:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1352143441; bh=HB3x8B0Qtj8ljCtlpUvsKwLJZV4SZUpuoDBoHcJgliY=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=RFf9k3fyWLlyGZ8R9d+87fnR0xLHq1cENWJKL5qctYBXsJNtFf3FEwZaF7ZV/egVC Ow7RjGN+mrXiEdZxMLEs7ZLWFg2g0ZZmHlz0M5cph0gyRwEwlzHJSY/zzDBEbfCVzp xOLBG13CmxuISYb/9MZY0IH7zyUmteEeJCSTESIQ= User-Agent: Kaiten Mail In-Reply-To: <20121105192152.6d65ed7a@bogo> References: <20121105192152.6d65ed7a@bogo> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----55S6EA9IHVCJQ33765NAOZTNQAILNW" From: "Paul E. Jones" Date: Mon, 05 Nov 2012 14:23:56 -0500 To: webfinger@googlegroups.com, Christian Weiske Message-ID: <6271c53a-454b-4553-943a-15979db70a00@email.android.com> Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] R: R: High-level considerations about "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: Mon, 05 Nov 2012 19:24:05 -0000 ------55S6EA9IHVCJQ33765NAOZTNQAILNW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit That offers a third option. We have: * New draft for JRD * Reference to RFC 6415 * inclusion of JRD description in new WF draft I thought folks wanted the latter, even if redundant. I have no preference, but I thought folks wanted to have no references to the host-meta do. Paul -------- Original Message -------- From: Christian Weiske Sent: Mon Nov 05 13:21:52 EST 2012 To: webfinger@googlegroups.com Cc: "apps-discuss@ietf.org" Subject: Re: R: [apps-discuss] R: High-level considerations about "webfinger" Hello Paul, > So you want a JRD RFC, not just a JRD section in WF? If so, we need > someone to author that immediately. I'm totally fine with JRD being defined as it is currently, in RFC 6415, Appendix A. I see no value in having it in an independent RFC. The goal cannot (and must not) be to have a totally self-contained RFC that is only two sentences long. It's very fine to built up on others. -- Regards/Mit freundlichen Grüßen Christian Weiske -=≡ Geeking around in the name of science since 1982 ≡=- ------55S6EA9IHVCJQ33765NAOZTNQAILNW Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

That offers a third option. We have:
* New draft for JRD
* Reference to RFC 6415
* inclusion of JRD description in new WF draft

I thought folks wanted the latter, even if redundant. I have no preference, but I thought folks wanted to have no references to the host-meta do.

Paul



From: Christian Weiske <cweiske@cweiske.de>
Sent: Mon Nov 05 13:21:52 EST 2012
To: webfinger@googlegroups.com
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: R: [apps-discuss] R: High-level considerations about "webfinger"

Hello Paul,


So you want a JRD RFC, not just a JRD section in WF? If so, we need
someone to author that immediately.

I'm totally fine with JRD being defined as it is currently, in RFC
6415, Appendix A. 

I see no value in having it in an independent RFC. The goal cannot (and
must not) be to have a totally self-contained RFC that is only two
sentences long. It's very fine to built up on others.

------55S6EA9IHVCJQ33765NAOZTNQAILNW-- From romeda@gmail.com Mon Nov 5 11:56: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 87DEA21F893D for ; Mon, 5 Nov 2012 11:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.523 X-Spam-Level: X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 6v6Jicl7z5W2 for ; Mon, 5 Nov 2012 11:56:26 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0BE21F8712 for ; Mon, 5 Nov 2012 11:56:06 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so4166849pad.31 for ; Mon, 05 Nov 2012 11:56:06 -0800 (PST) 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=6oaXwrRp6L+KLo8+Q1gSTciUkL1UW16AiMzDk7s0rOY=; b=DXYPK4IqOh1s5oPSut/QuYH08QuIMx1TURY+b6SvUAmYhQlXdhXV70kK8VsqzNCFbW PBPIyH1Ox7SQhUd4SRESBQD8kIMvbLA3lIg0FscM855eXmdLBP8MIT2ey9mzTr7QTjN7 5DM8E52EueS/kzW9lTMJMDSo7yce9AsxhxX9SUqxoncmY8g6Hy/cmmScMyUBXlzVu5na 4XwXuBpKiZPS8m0/5KWSYofsOvGUK5GSFvySxtmjCK+pzYBaRtXdBRW0MvvDDVr8/GtD vL/Z9Xd0AXRuVe2DkJeTiAv6SRAexqnBxPLbMqs6ci/Gyl3n7i0iE4sE/8Ry4LY0xznE WC6A== Received: by 10.66.88.4 with SMTP id bc4mr31213016pab.42.1352145366103; Mon, 05 Nov 2012 11:56:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.67.2.101 with HTTP; Mon, 5 Nov 2012 11:55:45 -0800 (PST) In-Reply-To: <1e8757a8-659a-42d2-9708-309f4b8de076@email.android.com> References: <1e8757a8-659a-42d2-9708-309f4b8de076@email.android.com> From: Blaine Cook Date: Mon, 5 Nov 2012 19:55:45 +0000 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d042e00d13b358e04cdc4e0b7 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 05 Nov 2012 19:56:27 -0000 --f46d042e00d13b358e04cdc4e0b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To continue with the "simplicity is the goal" theme, if it turns out that people are happier to use DNS records for discovering the Webfinger/SWD endpoint, then the host-meta lookup should be dropped entirely in favour of DNS lookups (or vice versa). If we're going to go the DNS route (and require it as a mandatory fallback), then it seems like following normal DNS semantics and making the lookup behave like MX or SRV records would be sensible. Rather than having a fallback, just have all lookups go immediately to the agreed-upon domain prefix / SRV record (I would express a slight bias towards SRV record, simply because the mechanism as specified is trivially vulnerable to attack on numerous existing platforms. E.g., http://simple-web-discovery.tumblr.com/ ) b. On 5 November 2012 13:44, Paul E. Jones wrote: > FYI > > ------------------------------ > *From:* Mike Jones > *Sent:* Mon Nov 05 07:55:14 EST 2012 > *To:* "Paul E. Jones" > *Subject:* FW: Simple Web Discovery (SWD) Enabling Hosted Deployments > > Paul, could you do me a favor and forward this note to the apps-discuss > list so people have context on why I updated SWD? For some reason, the > list doesn=E2=80=99t appear to be accepting my message.**** > > ** ** > > Thanks,**** > > -- Mike**** > > ** ** > > *From:* Mike Jones > *Sent:* Sunday, November 04, 2012 9:21 PM > *To:* apps-discuss@ietf.org > *Subject:* Simple Web Discovery (SWD) Enabling Hosted Deployments**** > > ** ** > > I=E2=80=99ve updated the Simple Web Discovery (SWD)specification to incorporate a means= of performing discovery on domains for > which it may not be possible to create a .well-known endpoint. This can > often be the case for hosted domains, where it is common for e-mail to be > provided but no web server. This solution was developed in discussions b= y > the OpenID Connect working group.**** > > ** ** > > This draft is being published now to facilitate discussions of the need t= o > enable discovery for hosted domains and possible solutions for doing so a= t > the IETF Applications Area working group meeting at IETF 85 in Atlanta > .**** > > ** ** > > The updated specification is available at:**** > > **=C2=B7 ** > http://tools.ietf.org/html/draft-jones-simple-web-discovery-04**** > > ** ** > > Changes made were:**** > > **=C2=B7 **Specified that the SWD server for a domain may be locat= ed at > the simple-web-discovery subdomain of the domain and that SWD clients > must first try the endpoint at the domain and then the endpoint at the > subdomain. **** > > **=C2=B7 **Removed the SWD_service_redirect response, since redire= ction > can be accomplished by pointing the simple-web-discovery subdomain to a > different location than the domain's host. **** > > **=C2=B7 **Removed mailto: from examples in favor of bare e-mail > address syntax. **** > > **=C2=B7 **Specified that SWD servers may also be run on ports oth= er > than 443, provided they use TLS on those ports.**** > > ** ** > > An HTML formatted version is available at:**** > > **=C2=B7 ** > http://self-issued.info/docs/draft-jones-simple-web-discovery-04.html**** > > ** ** > > (This notice was also posted to http://self-issued.info/?p=3D891.)**** > > ** ** > > -- Mike**** > > ** ** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d042e00d13b358e04cdc4e0b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To continue with the "simplicity is the goal" theme, if it turns = out that people are happier to use DNS records for discovering the Webfinge= r/SWD endpoint, then the host-meta lookup should be dropped entirely in fav= our of DNS lookups (or vice versa).

If we're going to go the DNS route (and require it as a = mandatory fallback), then it seems like following normal DNS semantics and = making the lookup behave like MX or SRV records would be sensible. Rather t= han having a fallback, just have all lookups go immediately to the agreed-u= pon domain prefix / SRV record (I would express a slight bias towards SRV r= ecord, simply because the mechanism as specified is trivially vulnerable to= attack on numerous existing platforms. E.g., http://simple-web-discovery.tumblr.com/ )

b.
 --f46d042e00d13b358e04cdc4e0b7-- From stpeter@stpeter.im Mon Nov 5 13: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 A168421F873D for ; Mon, 5 Nov 2012 13:29:24 -0800 (PST) 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_15=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 oZm95ftZPfX6 for ; Mon, 5 Nov 2012 13:29:23 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C094121F8510 for ; Mon, 5 Nov 2012 13:29:23 -0800 (PST) Received: from [130.129.84.156] (unknown [130.129.84.156]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CA6EB4010C; Mon, 5 Nov 2012 14:33:04 -0700 (MST) Message-ID: <50982FB2.3090903@stpeter.im> Date: Mon, 05 Nov 2012 16:29:22 -0500 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "t.petch" References: <508E9713.3030301@stpeter.im> <002201cdb843$09105f80$4001a8c0@gateway.2wire.net> In-Reply-To: <002201cdb843$09105f80$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Graham Klyne' , apps-discuss@ietf.org Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 05 Nov 2012 21:29:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/1/12 11:10 AM, t.petch wrote: > ----- Original Message ----- From: "Peter Saint-Andre" > To: Cc: "'Graham > Klyne'" Sent: Monday, October 29, 2012 2:47 PM >> >> I see two open issues with draft-ietf-appsawg-acct-uri (which I >> think we can resolve on the mailing list, thus saving precious >> meeting time for topics that require realtime discussion): >> >> 1. In version -01, I think that I was too aggressive about trying >> to simplify the ABNF, to wit: >> >> acctURI = "acct" ":" userinfo "@" host >> >> The userinfo rule allows the colon character ':', but I don't >> think that's what we want here. Instead, I think we want: >> >> acctURI = "acct" ":" userpart "@" host userpart = 1*( >> unreserved / pct-encoded / sub-delims ) >> >> If you disagree with that definition, please reply to this >> message. > > This definition bears a passing resemblance to that of an e-mail > address, which makes me wonder whether or not the syntax should be > aligned with that of e-mail with a reference thereto. I understand > the change you have just made, but cannot see a rationale for it. > It is not that I disagree with the definition but that I disagree > with the reason for it, not knowing what that is. The change is intended to remove ':' from the allowable characters in the localpart, since the point of ':' as a delimiter (as I understand it) was to allow localparts of the "username:password". I do think it would be helpful to show how various protocol identifiers (for email, SIP, XMPP, etc.) can be translated to 'acct' URIs, similar to what we did in section 4 of draft-saintandre-sip-xmpp-core: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-02#section-4 I'm not sure if that belongs in the acct-uri spec, but it might be helpful to document somewhere (e.g., on a wiki page). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCYL7IACgkQNL8k5A2w/vx60gCgw/jxQTIThFHRW7wqLXxfIziK OMUAn1XMFoRGn4eB5iT3nd31MsaU91Mx =5QSV -----END PGP SIGNATURE----- From superuser@gmail.com Mon Nov 5 20:24: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 42AA421F85C6 for ; Mon, 5 Nov 2012 20:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.158 X-Spam-Level: X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 erIxZeZDtv9o for ; Mon, 5 Nov 2012 20:24:18 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BFC3B21F85BA for ; Mon, 5 Nov 2012 20:24:17 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so14116lam.31 for ; Mon, 05 Nov 2012 20:24:16 -0800 (PST) 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=1WKVE4OK1yWqqQBjeECKekX+PvH6YkMLtSJivG61/8M=; b=bxUk0WR97g+N3/YAEz7y2U1DjBYdUXGcdL8aa7dMeVHa4s+2z4ElhwJPNjlQFe/j0u wXWBKF4smTnlv8O+w+zFQWt1L8fAZRKS6i6uwiTW969t36QeSUgrJ5svU4+H4fAdXCju xyXBAUEqF+nHR2lkpU3M+8VZgrDg27JlKslCitL+cHrxyrcmIKnRvFFuW13BNpLue3/M SkgsD8h/PLyMkVyLOv+Zg2VOkM3oGetbcynCQSRHVgn4bzmxVxckHTekNqBkXegLH3kH bnhx1tD2WM16Ndcq/jz1sh1p/nQWbgOkadOBL3CZNPpPebhH8IHZol5hw7ZZoMRXFlrH ScUA== MIME-Version: 1.0 Received: by 10.112.47.228 with SMTP id g4mr4524985lbn.21.1352175856464; Mon, 05 Nov 2012 20:24:16 -0800 (PST) Received: by 10.112.83.232 with HTTP; Mon, 5 Nov 2012 20:24:16 -0800 (PST) In-Reply-To: <50982FB2.3090903@stpeter.im> References: <508E9713.3030301@stpeter.im> <002201cdb843$09105f80$4001a8c0@gateway.2wire.net> <50982FB2.3090903@stpeter.im> Date: Mon, 5 Nov 2012 23:24:16 -0500 Message-ID: From: "Murray S. Kucherawy" To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=bcaec554ddfe9934c604cdcbf90a Cc: Graham Klyne , IETF Apps Discuss Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 06 Nov 2012 04:24:19 -0000 --bcaec554ddfe9934c604cdcbf90a Content-Type: text/plain; charset=ISO-8859-1 I've never seen a colon in an email address, but for the sake of not proscribing things needlessly, could a colon in a user part (what we in email call the "local part") simply be escaped somehow? I don't think this is especially critical. Just asking. -MSK, participatin' On Mon, Nov 5, 2012 at 4:29 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/1/12 11:10 AM, t.petch wrote: > > ----- Original Message ----- From: "Peter Saint-Andre" > > To: Cc: "'Graham > > Klyne'" Sent: Monday, October 29, 2012 2:47 PM > >> > >> I see two open issues with draft-ietf-appsawg-acct-uri (which I > >> think we can resolve on the mailing list, thus saving precious > >> meeting time for topics that require realtime discussion): > >> > >> 1. In version -01, I think that I was too aggressive about trying > >> to simplify the ABNF, to wit: > >> > >> acctURI = "acct" ":" userinfo "@" host > >> > >> The userinfo rule allows the colon character ':', but I don't > >> think that's what we want here. Instead, I think we want: > >> > >> acctURI = "acct" ":" userpart "@" host userpart = 1*( > >> unreserved / pct-encoded / sub-delims ) > >> > >> If you disagree with that definition, please reply to this > >> message. > > > > This definition bears a passing resemblance to that of an e-mail > > address, which makes me wonder whether or not the syntax should be > > aligned with that of e-mail with a reference thereto. I understand > > the change you have just made, but cannot see a rationale for it. > > It is not that I disagree with the definition but that I disagree > > with the reason for it, not knowing what that is. > > The change is intended to remove ':' from the allowable characters in > the localpart, since the point of ':' as a delimiter (as I understand > it) was to allow localparts of the "username:password". > > I do think it would be helpful to show how various protocol > identifiers (for email, SIP, XMPP, etc.) can be translated to 'acct' > URIs, similar to what we did in section 4 of > draft-saintandre-sip-xmpp-core: > > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-02#section-4 > > I'm not sure if that belongs in the acct-uri spec, but it might be > helpful to document somewhere (e.g., on a wiki page). > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlCYL7IACgkQNL8k5A2w/vx60gCgw/jxQTIThFHRW7wqLXxfIziK > OMUAn1XMFoRGn4eB5iT3nd31MsaU91Mx > =5QSV > -----END PGP SIGNATURE----- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --bcaec554ddfe9934c604cdcbf90a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've never seen a colon in an email address, but for the sake of not pr= oscribing things needlessly, could a colon in a user part (what we in email= call the "local part") simply be escaped somehow?

I don&#= 39;t think this is especially critical.=A0 Just asking.

-MSK, participatin'


On Mon, Nov 5, 2012 at 4:29 PM, Peter Saint-Andre <stpe= ter@stpeter.im> wrote:
-----BEGIN PGP SIGNED MESS= AGE-----
Hash: SHA1

On 11/1/12 11:10 AM, t.petch wrote:
> ----- Original Message ----- From: "Peter Saint-Andre"
> <stpeter@stpeter.im> T= o: <apps-discuss@ietf.org&g= t; Cc: "'Graham
> Klyne'" <GK@ninebynin= e.org> Sent: Monday, October 29, 2012 2:47 PM
>>
>> I see two open issues with draft-ietf-appsawg-acct-uri (which I >> think we can resolve on the mailing list, thus saving precious
>> meeting time for topics that require realtime discussion):
>>
>> 1. In version -01, I think that I was too aggressive about trying<= br> >> to simplify the ABNF, to wit:
>>
>> acctURI =A0 =A0 =A0=3D =A0"acct" ":" userinfo = "@" host
>>
>> The userinfo rule allows the colon character ':', but I do= n't
>> think that's what we want here. Instead, I think we want:
>>
>> acctURI =A0 =A0 =A0=3D =A0"acct" ":" userpart = "@" host userpart =A0 =A0 =3D =A01*(
>> unreserved / pct-encoded / sub-delims )
>>
>> If you disagree with that definition, please reply to this
>> message.
>
> This definition bears a passing resemblance to that of an e-mail
> address, which makes me wonder whether or not the syntax should be
> aligned with that of e-mail with a reference thereto. =A0I understand<= br> > the change you have just made, but cannot see a rationale for it.
> It is not that I disagree with the definition but that I disagree
> with the reason for it, not knowing what that is.

The change is intended to remove ':' from the allowable chara= cters in
the localpart, since the point of ':' as a delimiter (as I understa= nd
it) was to allow localparts of the "username:password".

I do think it would be helpful to show how various protocol
identifiers (for email, SIP, XMPP, etc.) can be translated to 'acct'= ;
URIs, similar to what we did in section 4 of
draft-saintandre-sip-xmpp-core:

http://tools.ietf.org/html/draft-saintandre-sip-x= mpp-core-02#section-4

I'm not sure if that belongs in the acct-uri spec, but it might be
helpful to document somewhere (e.g., on a wiki page).

Peter

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

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

iEYEARECAAYFAlCYL7IACgkQNL8k5A2w/vx60gCgw/jxQTIThFHRW7wqLXxfIziK
OMUAn1XMFoRGn4eB5iT3nd31MsaU91Mx
=3D5QSV
-----END PGP SIGNATURE-----
___________________________________= ____________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--bcaec554ddfe9934c604cdcbf90a-- From ht@inf.ed.ac.uk Tue Nov 6 02:03: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 9CA4A21F8456; Tue, 6 Nov 2012 02:03:10 -0800 (PST) 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 igSDOcANX5uL; Tue, 6 Nov 2012 02:03:09 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 88FAF21F8435; Tue, 6 Nov 2012 02:03:08 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id qA6A2wSH021573; Tue, 6 Nov 2012 10:03:03 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id qA6A2xcM012149; Tue, 6 Nov 2012 10:03:00 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id qA6A2xef010243; Tue, 6 Nov 2012 10:02:59 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id qA6A2x8u010239; Tue, 6 Nov 2012 10:02:59 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: internet-drafts@ietf.org References: <20121105155412.4054.20989.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 06 Nov 2012 10:02:59 +0000 In-Reply-To: <20121105155412.4054.20989.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Mon\, 05 Nov 2012 07\:54\:12 -0800") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: apps-discuss@ietf.org, i-d-announce@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-08.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, 06 Nov 2012 10:03:10 -0000 internet-drafts writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : Additional Media Type Structured Syntax Suffixes > Author(s) : Tony Hansen > Alexey Melnikov > Filename : draft-ietf-appsawg-media-type-suffix-regs-08.txt Given that draft-lilley-xml-mediatypes-00 has now been published, is the patch to RFC3023 in section 4 of this document really necessary? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From duerst@it.aoyama.ac.jp Tue Nov 6 04:04: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 F2A1621F8883 for ; Tue, 6 Nov 2012 04:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.749 X-Spam-Level: X-Spam-Status: No, score=-101.749 tagged_above=-999 required=5 tests=[AWL=2.041, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 taIvmaH-Yw4b for ; Tue, 6 Nov 2012 04:04:09 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0867F21F8863 for ; Tue, 6 Nov 2012 04:04:08 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id qA6C3set001361 for ; Tue, 6 Nov 2012 21:03:58 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 3fc4_371d_09062c40_280a_11e2_a8eb_001d096c5782; Tue, 06 Nov 2012 21:03:53 +0900 Received: from [IPv6:::1] ([133.2.210.1]:47485) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 6 Nov 2012 21:03:54 +0900 Message-ID: <5098FCA6.40809@it.aoyama.ac.jp> Date: Tue, 06 Nov 2012 21:03:50 +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: "Murray S. Kucherawy" References: <508E9713.3030301@stpeter.im> <002201cdb843$09105f80$4001a8c0@gateway.2wire.net> <50982FB2.3090903@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Graham Klyne , IETF Apps Discuss Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 06 Nov 2012 12:04:10 -0000 On 2012/11/06 13:24, Murray S. Kucherawy wrote: > I've never seen a colon in an email address, but for the sake of not > proscribing things needlessly, could a colon in a user part (what we in > email call the "local part") simply be escaped somehow? Not just "somehow". These are URIs, so it would be %3A. Regards, Martin. > I don't think this is especially critical. Just asking. > > -MSK, participatin' From ve7jtb@ve7jtb.com Tue Nov 6 04:49: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 E638121F88A3 for ; Tue, 6 Nov 2012 04:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 snEDsRAWApDs for ; Tue, 6 Nov 2012 04:49:14 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D523721F8861 for ; Tue, 6 Nov 2012 04:49:14 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so396643pbb.31 for ; Tue, 06 Nov 2012 04:49:14 -0800 (PST) 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 :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=SqGaPaDij2lopboHxEcNJdV66d6gaqCCLeUhO+uqeKU=; b=n4gtqBfM+dNZQTniae1Pj4N1YMwrW5wc3yyCBF0WnG29OAoZB5th84Qj6vo05RqAcS xHuEf+zvIl+i7quyMj05ZOP8Ltoa0oKb4PGDu4mK348166iOHxkWu+9vkyvDw4X1gMFy 7V8g9jf4GQUoAJQ8NKUMsbUKimXU/rZQ3LpXK4lASvrms5PIEGEAajozQRT1rE24nQXj ZR14d6a8z5etE1/1CqrsPGCcQ0vnHM5QtSOiORYpbBCDQTnualZPN0xsLJLXCOkSX/bP olhvXSCkmFm2Cm4f8G7C5y0rZF7MPJFrnGBW4VQgxkMtaIoiOJEw/3LkQPHHsJXZlSF3 oDbw== Received: by 10.66.85.10 with SMTP id d10mr2305959paz.52.1352206154392; Tue, 06 Nov 2012 04:49:14 -0800 (PST) Received: from ?IPv6:2001:df8::64:b0b4:7c19:59a9:246c? ([2001:df8:0:64:b0b4:7c19:59a9:246c]) by mx.google.com with ESMTPS id gv9sm12315782pbc.21.2012.11.06.04.49.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 04:49:13 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <50982FB2.3090903@stpeter.im> Date: Tue, 6 Nov 2012 07:49:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <508E9713.3030301@stpeter.im> <002201cdb843$09105f80$4001a8c0@gateway.2wire.net> <50982FB2.3090903@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkEGIkO/n1YtOao+r6D8xQldIlMnXZnINoifjAKwAAT/OHsbTlg5XmGiFhTaVTMCErb91mG Cc: 'Graham Klyne' , apps-discuss@ietf.org Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 06 Nov 2012 12:49:16 -0000 Is including a port number valid? =46rom my read it would not be. For debugging/testing we want to be able to run the resolver on an = alternate port. =20 Entering acct:ve7jtb@ve7jtb.com:4444 I think that was the proposal that Mike was making yesterday in the apps = area meeting. John B. On 2012-11-05, at 4:29 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 11/1/12 11:10 AM, t.petch wrote: >> ----- Original Message ----- From: "Peter Saint-Andre" >> To: Cc: "'Graham >> Klyne'" Sent: Monday, October 29, 2012 2:47 PM >>>=20 >>> I see two open issues with draft-ietf-appsawg-acct-uri (which I >>> think we can resolve on the mailing list, thus saving precious >>> meeting time for topics that require realtime discussion): >>>=20 >>> 1. In version -01, I think that I was too aggressive about trying >>> to simplify the ABNF, to wit: >>>=20 >>> acctURI =3D "acct" ":" userinfo "@" host >>>=20 >>> The userinfo rule allows the colon character ':', but I don't >>> think that's what we want here. Instead, I think we want: >>>=20 >>> acctURI =3D "acct" ":" userpart "@" host userpart =3D 1*( >>> unreserved / pct-encoded / sub-delims ) >>>=20 >>> If you disagree with that definition, please reply to this >>> message. >>=20 >> This definition bears a passing resemblance to that of an e-mail=20 >> address, which makes me wonder whether or not the syntax should be=20 >> aligned with that of e-mail with a reference thereto. I understand >> the change you have just made, but cannot see a rationale for it. >> It is not that I disagree with the definition but that I disagree >> with the reason for it, not knowing what that is. >=20 > The change is intended to remove ':' from the allowable characters in > the localpart, since the point of ':' as a delimiter (as I understand > it) was to allow localparts of the "username:password". >=20 > I do think it would be helpful to show how various protocol > identifiers (for email, SIP, XMPP, etc.) can be translated to 'acct' > URIs, similar to what we did in section 4 of > draft-saintandre-sip-xmpp-core: >=20 > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-02#section-4 >=20 > I'm not sure if that belongs in the acct-uri spec, but it might be > helpful to document somewhere (e.g., on a wiki page). >=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://www.enigmail.net/ >=20 > iEYEARECAAYFAlCYL7IACgkQNL8k5A2w/vx60gCgw/jxQTIThFHRW7wqLXxfIziK > OMUAn1XMFoRGn4eB5iT3nd31MsaU91Mx > =3D5QSV > -----END PGP SIGNATURE----- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From jhildebr@cisco.com Tue Nov 6 05:09: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 5894A21F8626 for ; Tue, 6 Nov 2012 05:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.299 X-Spam-Level: X-Spam-Status: No, score=-11.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 RnvFaW4EKIho for ; Tue, 6 Nov 2012 05:09:35 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 661B721F88DE for ; Tue, 6 Nov 2012 05:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3449; q=dns/txt; s=iport; t=1352207375; x=1353416975; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Rvv3yEV2EsmQIt1pCDCYvZeBZ7+U4QD57611wnsvHjA=; b=T87AEngLG3ar/khKAe1ItnCZb4XcTYJF3ByA2JUwR15gB2vBk9InjT3B Qg12zvGXyjqrpgtp48HErwPprbX3DStCU3dguVyEdoefQHC5TLSoN/ptN EiXPBBAGHnzMrelwm/wvaO7Lo1aLAEkKVU9cW7IsFA2VhV/8x6kLjxsHZ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIYLmVCtJXG+/2dsb2JhbABEwy+BCIIeAQEBBAEBAQ8BJzQLDAYBCA4HAQIKDgY3CyUCBAENBQgah2gLmzmPZJBPjAMagxiCQmEDlxeNPYFrgm+BZDU X-IronPort-AV: E=Sophos;i="4.80,722,1344211200"; d="scan'208";a="139288495" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 06 Nov 2012 13:09:34 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA6D9Yqu010632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 13:09:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 07:09:34 -0600 From: "Joe Hildebrand (jhildebr)" To: John Bradley , Peter Saint-Andre Thread-Topic: [apps-discuss] open issues with acct-uri spec Thread-Index: AQHNvB0qnaWn81ttYUOZuQjiNp3TcZfc2HUA Date: Tue, 6 Nov 2012 13:09:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.21.77.106] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--45.810200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <5768734FA4037544915DB036ABB91B6A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Graham Klyne' , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 06 Nov 2012 13:09:36 -0000 If there's a port, you have to specify a protocol, in which case acct: doesn't make sense to me. On 11/6/12 7:49 AM, "John Bradley" wrote: >Is including a port number valid? > >From my read it would not be. > >For debugging/testing we want to be able to run the resolver on an >alternate port. =20 > >Entering acct:ve7jtb@ve7jtb.com:4444 > >I think that was the proposal that Mike was making yesterday in the apps >area meeting. > > >John B. > >On 2012-11-05, at 4:29 PM, Peter Saint-Andre wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> On 11/1/12 11:10 AM, t.petch wrote: >>> ----- Original Message ----- From: "Peter Saint-Andre" >>> To: Cc: "'Graham >>> Klyne'" Sent: Monday, October 29, 2012 2:47 PM >>>>=20 >>>> I see two open issues with draft-ietf-appsawg-acct-uri (which I >>>> think we can resolve on the mailing list, thus saving precious >>>> meeting time for topics that require realtime discussion): >>>>=20 >>>> 1. In version -01, I think that I was too aggressive about trying >>>> to simplify the ABNF, to wit: >>>>=20 >>>> acctURI =3D "acct" ":" userinfo "@" host >>>>=20 >>>> The userinfo rule allows the colon character ':', but I don't >>>> think that's what we want here. Instead, I think we want: >>>>=20 >>>> acctURI =3D "acct" ":" userpart "@" host userpart =3D 1*( >>>> unreserved / pct-encoded / sub-delims ) >>>>=20 >>>> If you disagree with that definition, please reply to this >>>> message. >>>=20 >>> This definition bears a passing resemblance to that of an e-mail >>> address, which makes me wonder whether or not the syntax should be >>> aligned with that of e-mail with a reference thereto. I understand >>> the change you have just made, but cannot see a rationale for it. >>> It is not that I disagree with the definition but that I disagree >>> with the reason for it, not knowing what that is. >>=20 >> The change is intended to remove ':' from the allowable characters in >> the localpart, since the point of ':' as a delimiter (as I understand >> it) was to allow localparts of the "username:password". >>=20 >> I do think it would be helpful to show how various protocol >> identifiers (for email, SIP, XMPP, etc.) can be translated to 'acct' >> URIs, similar to what we did in section 4 of >> draft-saintandre-sip-xmpp-core: >>=20 >> http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-02#section-4 >>=20 >> I'm not sure if that belongs in the acct-uri spec, but it might be >> helpful to document somewhere (e.g., on a wiki page). >>=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://www.enigmail.net/ >>=20 >> iEYEARECAAYFAlCYL7IACgkQNL8k5A2w/vx60gCgw/jxQTIThFHRW7wqLXxfIziK >> OMUAn1XMFoRGn4eB5iT3nd31MsaU91Mx >> =3D5QSV >> -----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 > --=20 Joe Hildebrand From ve7jtb@ve7jtb.com Tue Nov 6 05:48: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 162FC21F84FA for ; Tue, 6 Nov 2012 05:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 AN0TnH1FovSU for ; Tue, 6 Nov 2012 05:48:56 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 384DE21F88E4 for ; Tue, 6 Nov 2012 05:48:56 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so371947pad.31 for ; Tue, 06 Nov 2012 05:48:56 -0800 (PST) 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 :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=4qftuZp+cSo7jhj4OH+B8Rxrl6F4gT9btTxsXwKO+tY=; b=WbW7scGn+kEUzAPrN28YCWw1jS1CuPzXKOdW570jNGFCDpRMFili1ThzNMHFN0qvfF 4sbNWBin4UF+fLIzkkUAkD2K9Z3eKQsuX9UTOhsKy1yDngWCc9/H2Cjb9Jm+TeYWaHm+ qklbgjjpwvwr7TfZh9WaunLfK1iCtKjT2q4xZUoThX+hwMhas/gtoeoPa+rZ8G6jjCdx EbFUKgXqk73JlJ7cq+RgxAB5umafolc9geY0JIzIadHg4jUKSx8lRinm8QLcD8NFDf9o IFyhNosVFN6ukt4dxU/XYIhwuijPZpyIxH/rFtt4kIOxUjeii/pHGjwgisBVmyoHBhGl /cGA== Received: by 10.68.213.33 with SMTP id np1mr3528646pbc.64.1352209735880; Tue, 06 Nov 2012 05:48:55 -0800 (PST) Received: from ?IPv6:2001:df8::64:b0b4:7c19:59a9:246c? ([2001:df8:0:64:b0b4:7c19:59a9:246c]) by mx.google.com with ESMTPS id is6sm12375960pbc.55.2012.11.06.05.48.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 05:48:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Tue, 6 Nov 2012 08:48:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6629092F-6FA6-4600-AB38-1D5184193ED2@ve7jtb.com> References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmfsOhfzWmo85R5w1gLSARvXFDKTtYeVn5iMh2ki6LOYl/4KEOfzH+Ixp10/obfbzrhBc4y Cc: 'Graham Klyne' , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 06 Nov 2012 13:48:57 -0000 There is a relationship between acct: and Web-Finger where it is treated = by the protocol as a locator.=20 Saying that you can't specify a alternate port for web-finger to use as = part of the locator is fine, as long as people understand what is = happening. The Web-Finger spec will have to provide guidance on how input is = normalized. acct:ve7jtb@ve7jtb.com:8888 Is invalid and rejected ve7jtb@ve7jtb.com Is normalized to = acct:ve7jtb@ve7jtb.com for input to the resolver ve7jtb@ve7jtb.com:8888 May be a interoperability issue as I = can imagine a number of interpretations. My concerns are that whatever the final spec it is interoperable. I have this nagging feeling that allowing any string as input in WF may = be something that is never used and complicates the spec or is never = used in practice. This is probably more a WF issue. John B. On 2012-11-06, at 8:09 AM, "Joe Hildebrand (jhildebr)" = wrote: > If there's a port, you have to specify a protocol, in which case acct: > doesn't make sense to me. >=20 >=20 > On 11/6/12 7:49 AM, "John Bradley" wrote: >=20 >> Is including a port number valid? >>=20 >> =46rom my read it would not be. >>=20 >> For debugging/testing we want to be able to run the resolver on an >> alternate port. =20 >>=20 >> Entering acct:ve7jtb@ve7jtb.com:4444 >>=20 >> I think that was the proposal that Mike was making yesterday in the = apps >> area meeting. >>=20 >>=20 >> John B. >>=20 >> On 2012-11-05, at 4:29 PM, Peter Saint-Andre = wrote: >>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>>=20 >>> On 11/1/12 11:10 AM, t.petch wrote: >>>> ----- Original Message ----- From: "Peter Saint-Andre" >>>> To: Cc: "'Graham >>>> Klyne'" Sent: Monday, October 29, 2012 2:47 PM >>>>>=20 >>>>> I see two open issues with draft-ietf-appsawg-acct-uri (which I >>>>> think we can resolve on the mailing list, thus saving precious >>>>> meeting time for topics that require realtime discussion): >>>>>=20 >>>>> 1. In version -01, I think that I was too aggressive about trying >>>>> to simplify the ABNF, to wit: >>>>>=20 >>>>> acctURI =3D "acct" ":" userinfo "@" host >>>>>=20 >>>>> The userinfo rule allows the colon character ':', but I don't >>>>> think that's what we want here. Instead, I think we want: >>>>>=20 >>>>> acctURI =3D "acct" ":" userpart "@" host userpart =3D = 1*( >>>>> unreserved / pct-encoded / sub-delims ) >>>>>=20 >>>>> If you disagree with that definition, please reply to this >>>>> message. >>>>=20 >>>> This definition bears a passing resemblance to that of an e-mail >>>> address, which makes me wonder whether or not the syntax should be >>>> aligned with that of e-mail with a reference thereto. I understand >>>> the change you have just made, but cannot see a rationale for it. >>>> It is not that I disagree with the definition but that I disagree >>>> with the reason for it, not knowing what that is. >>>=20 >>> The change is intended to remove ':' from the allowable characters = in >>> the localpart, since the point of ':' as a delimiter (as I = understand >>> it) was to allow localparts of the "username:password". >>>=20 >>> I do think it would be helpful to show how various protocol >>> identifiers (for email, SIP, XMPP, etc.) can be translated to 'acct' >>> URIs, similar to what we did in section 4 of >>> draft-saintandre-sip-xmpp-core: >>>=20 >>> = http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-02#section-4 >>>=20 >>> I'm not sure if that belongs in the acct-uri spec, but it might be >>> helpful to document somewhere (e.g., on a wiki page). >>>=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://www.enigmail.net/ >>>=20 >>> iEYEARECAAYFAlCYL7IACgkQNL8k5A2w/vx60gCgw/jxQTIThFHRW7wqLXxfIziK >>> OMUAn1XMFoRGn4eB5iT3nd31MsaU91Mx >>> =3D5QSV >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> 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 >=20 >=20 > --=20 > Joe Hildebrand >=20 >=20 >=20 From bradfitz@google.com Mon Nov 5 11: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 2CFC121F843F for ; Mon, 5 Nov 2012 11:28:10 -0800 (PST) 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.549, 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 R+oyAixfBlQz for ; Mon, 5 Nov 2012 11:28:09 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6886D21F88D1 for ; Mon, 5 Nov 2012 11:28:04 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id v19so6550105obq.31 for ; Mon, 05 Nov 2012 11:28:04 -0800 (PST) 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=T7jUqyAV1hfqjQxks/xK1jLlNjilGAsyUy/EfSElEPY=; b=ARGMhkm8I8SMjDVG/8F/6J8cMRUDQqNs2kTw3R3OZQPL5UJpSA/PXjx1ocqC+ANw3c 45D7gg9PL5L92rh2m7Sou/gAB0rpvMV6QKIZyVsb9PjiY75qH8nHq9Nz7zNlBY+QJvFN 4hm43F1Oxx9U3idWBZc+7pxwbBUu1E74xXIj1pNCWyfpDDzgZhU7zIKqycE7Tzp4yt3H 9djPt6pUHRnbmKkiWz6Z2fj91MKetqQtoTxiLz/ppByQK7/UWFgJJf+5TJfhGUkcxJAk ZVRvp0/SRdEGiG/mYv8zwEvHYoDqMwD2yucWF5WsTO8yN5GmFWlalBrJ2MGWbdmi0Nko T3tA== 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=T7jUqyAV1hfqjQxks/xK1jLlNjilGAsyUy/EfSElEPY=; b=Qq5rv5myI/01ROxanYZOGYJwRBiRR38EBg3+3fGoE7TfrC9TaG88wljJf+ihusd3Zf j8TvO6CIjHUx6/GLPxl0i0/K63n6Z2ozbx5eL83iePaVg4wm1q9BmrwjDJApvqJI4qrP SmcrMbtH5yaCNvRH3leNsstlsZGChKSwMi+D5ZGR7K+JNzJoDtXmyt+xHWcogeIpqXKB iZyU6rbtLHbkdhySczwGWW8J8afnco/qlf6LH4nkUuDAB1EWdXavSA0cLaKq6UeWtiAh undjllKOmJLnWUxxqZpjtQVI+UvORtlDFoZ6uh/Pd3KaDLJPkmd/NLg9i9wAuqYPHfIK m2VQ== MIME-Version: 1.0 Received: by 10.182.146.107 with SMTP id tb11mr1397292obb.30.1352143684034; Mon, 05 Nov 2012 11:28:04 -0800 (PST) Received: by 10.60.31.41 with HTTP; Mon, 5 Nov 2012 11:28:03 -0800 (PST) In-Reply-To: <6271c53a-454b-4553-943a-15979db70a00@email.android.com> References: <20121105192152.6d65ed7a@bogo> <6271c53a-454b-4553-943a-15979db70a00@email.android.com> Date: Mon, 5 Nov 2012 20:28:03 +0100 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d04447fb1f8e11604cdc47bb7 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkGC3yNx3oVZuP7CIvxsypBlk49wrWzZPIQDWG4BRG5joknJKQ0e6gw4kK6Cik12g+uhoCHBDJk7UZOuUu3siXRdXhE8NlNwbufEXt5kCkm6kVyXWEofd8O+mzCscGn73tabkSBOIdwWXyARSOcvDAhWFBJoNCY6BcvHpNiLbVOtwS3XYZ04AnzMK/n+nReYI5mFeXU X-Mailman-Approved-At: Tue, 06 Nov 2012 08:06:00 -0800 Cc: Christian Weiske , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] R: R: High-level considerations about "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: Mon, 05 Nov 2012 19:28:10 -0000 --f46d04447fb1f8e11604cdc47bb7 Content-Type: text/plain; charset=UTF-8 I'm fine with a reference to small, well-defined parts of RFC 6415. Especially if it's the most expedient option. I just don't want to override and insert into parts of RFC 6415 as the old drafts seemed to. But I'm fine with all three options, really. On Mon, Nov 5, 2012 at 8:23 PM, Paul E. Jones wrote: > That offers a third option. We have: > * New draft for JRD > * Reference to RFC 6415 > * inclusion of JRD description in new WF draft > > I thought folks wanted the latter, even if redundant. I have no > preference, but I thought folks wanted to have no references to the > host-meta do. > > *Paul* > > > ------------------------------ > *From:* Christian Weiske > *Sent:* Mon Nov 05 13:21:52 EST 2012 > *To:* webfinger@googlegroups.com > *Cc:* "apps-discuss@ietf.org" > *Subject:* Re: R: [apps-discuss] R: High-level considerations about > "webfinger" > > Hello Paul, > > > So you want a JRD RFC, not just a JRD section in WF? If so, we need >> someone to author that immediately. > > > I'm totally fine with JRD being defined as it is currently, in RFC > 6415, Appendix A. > > I see no value in having it in an independent RFC. The goal cannot (and > must not) be to have a totally self-contained RFC that is only two > sentences long. It's very fine to built up on others. > > --f46d04447fb1f8e11604cdc47bb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I= 'm fine with a reference to small, well-defined parts of RFC 6415. =C2= =A0Especially if it's the most expedient option.

I j= ust don't want to override and insert into parts of RFC 6415 as the old= drafts seemed to.

But I'm fine with all three options, really.
On Mon, Nov 5, 2012 at 8:23 PM, Paul E. Jones <= span dir=3D"ltr"><paulej@packetizer.com> wrote:

That offers a third= option. We have:
* New draft for JRD
* Reference to RFC 6415
* inclusion of JRD description in new WF draft

I thought folks wanted the latter, even if redundant. I have= no preference, but I thought folks wanted to have no references to the hos= t-meta do.

Paul



From: Christian Weiske <cweiske@cweiske.de>
Sent: Mon Nov 05 13:21:52 EST 2012
To: = webfinger@googlegroups.com
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: R: [apps-discuss] R: High-level considerations about &= quot;webfinger"

Hello Paul,



So you want a JRD RFC, not just a JRD section in WF? If so, we need
some=
one to author that immediately.

I'm totally fine with J=
RD being defined as it is currently, in RFC
6415, Appendix A. 


I see no value in having it in an independent RFC. The goal cannot (and
=
must not) be to have a totally self-contained RFC that is only two
sente=
nces long. It's very fine to built up on others.


--f46d04447fb1f8e11604cdc47bb7-- From bradfitz@google.com Mon Nov 5 12:56: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 3852721F874C for ; Mon, 5 Nov 2012 12:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.494, 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 zuEIOXdd70lN for ; Mon, 5 Nov 2012 12:56:38 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0DD121F874B for ; Mon, 5 Nov 2012 12:56:38 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so6719671oag.31 for ; Mon, 05 Nov 2012 12:56:38 -0800 (PST) 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=zrWCQmA/4mQToXYcSfhg+lz6juTjXjnSzHlX61eZxIA=; b=MYD+Dm7gsqMhB04C65tYUVbKg2uWaIMayV+G5aLHKCJyawc2AIZaNIuVvRx4JAluBt dbwdyUlUgdckFH8Kxz1oN0z042B5CR4zouIkNMmCZmrnrGBQZGeMhKC6TBKtBK95LsgS 7zOjFImsF4ytOHmsYn64MjOTWHohG6F/nADX4Iad0peSOZTQeCboUu0um9l9Q1k3r2Im Zlq29xgsSCAbqJTFSYCsImt1VR3/DnrYEugmLPZj8CJZpW3YN2NUtt/bFwASu62JomW0 gByaYQ/vCCouUBxeXwpDmWyoLduIyPfve9eovZQPdRCTVZ7JgjViJ2vplnQxouhBrvGb f//Q== 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=zrWCQmA/4mQToXYcSfhg+lz6juTjXjnSzHlX61eZxIA=; b=K0J0f6fdeM9G2Jwd/5+2bnV2Wo4jNMOneWbmOgMSwx/QbEZVy/MStKvm3gMS+itgYH JZuEsAM5ZR2FLgdeAxR0oP3a5ye5sXao/6Vk/acZL8PKHGM4NB6PymmV4YTUV+N8TpMx h2y0WLyqmZPxJESYYmY9W/oS3I56JQz0bxq1O8zyD30M1ax+gAHufj1qxpIob6VinzL2 VXtV4hP9MmUsUbdvM75NNLmz3MLY1KenKp7tfjlRwHzCkvo7mh3rY5KgkaIITwt1AWl4 thdCXVC+feYACxOkmHYksvabikvJXW7MUJX8Bd8rK4lJSucNChwPdWv+kNpBo5SPoYTU Tcow== MIME-Version: 1.0 Received: by 10.60.31.72 with SMTP id y8mr9002026oeh.118.1352148998069; Mon, 05 Nov 2012 12:56:38 -0800 (PST) Received: by 10.60.31.41 with HTTP; Mon, 5 Nov 2012 12:56:37 -0800 (PST) In-Reply-To: <325BF877-6D97-4F12-B532-278CFBA0191F@gmail.com> References: <20121105192152.6d65ed7a@bogo> <6271c53a-454b-4553-943a-15979db70a00@email.android.com> <325BF877-6D97-4F12-B532-278CFBA0191F@gmail.com> Date: Mon, 5 Nov 2012 21:56:37 +0100 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8f642ca2b69c5e04cdc5b833 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmL/TdWNjikLhVz7/XynzDGbyKuKsZxTfvSHVfq/ywM4cMpb2nmUk9WnsLSbBzvdDIH8I6xEmwN0XTHNGYls6gpvZ8bjzyeoAziR2PIhZ3+EtV2MTIUIqgmqxZL3kNRHDQJ2v21+uoPupEu/iTwwI6ra4CSETRf2KwfC4udTxP44vZfOLk6tZ4tTvR4ljXtbL35Eaoa X-Mailman-Approved-At: Tue, 06 Nov 2012 08:06:15 -0800 Cc: Christian Weiske , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] R: High-level considerations about "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: Mon, 05 Nov 2012 20:56:39 -0000 --e89a8f642ca2b69c5e04cdc5b833 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 5, 2012 at 9:04 PM, Dick Hardt wrote: > I just read RFC 6415 Appendix A > http://tools.ietf.org/html/rfc6415#appendix-A > > A JRD is defined in context of an XRD. To understand the Appendix, one > must understand XRD. > [...] > It is like defining JSON in terms of XML. Yuck. > I agree that it's twisty and not ideal, but on the other hand, it provides a JSON example which is pretty much sufficient on its own. I'm ambivalent here, torn between pedantry and impatience. +0 --e89a8f642ca2b69c5e04cdc5b833 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Mon, Nov 5, 2012 at 9:04 PM, Dick Hardt <dick.hardt@gmail.com>= wrote:
I just read RFC 6415 Appendix A=C2=A0h= ttp://tools.ietf.org/html/rfc6415#appendix-A

A JRD i= s defined in context of an XRD. To understand the Appendix, one must unders= tand XRD.=C2=A0
[...]=C2=A0
It is like defining JSON i= n terms of XML. Yuck.

I agree that it's twisty and not= ideal, but on the other hand, it provides a JSON example which is pretty m= uch sufficient on its own.

I'm ambivalent here= , torn between pedantry and impatience.

+0

--e89a8f642ca2b69c5e04cdc5b833-- From cweiske@cweiske.de Mon Nov 5 10:21: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 1A8FD21F8936 for ; Mon, 5 Nov 2012 10:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.458 X-Spam-Level: X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[AWL=1.141, 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 dHIzX1hwr1XR for ; Mon, 5 Nov 2012 10:21:58 -0800 (PST) Received: from mail.cweiske.de (mail.cweiske.de [IPv6:2a01:488:66:1000:53a9:7c6:0:1]) by ietfa.amsl.com (Postfix) with ESMTP id 8877221F8935 for ; Mon, 5 Nov 2012 10:21:58 -0800 (PST) Received: by mail.cweiske.de (Postfix, from userid 65534) id 111F610438006; Mon, 5 Nov 2012 19:21:57 +0100 (CET) Received: from bogo (p54BD7630.dip.t-dialin.net [84.189.118.48]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.cweiske.de (Postfix) with ESMTPSA id 718D710438003; Mon, 5 Nov 2012 19:21:55 +0100 (CET) Date: Mon, 5 Nov 2012 19:21:52 +0100 From: Christian Weiske To: webfinger@googlegroups.com Message-ID: <20121105192152.6d65ed7a@bogo> In-Reply-To: References: X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/TrLIQuQWSohLcg2w/Kz.3Ku"; protocol="application/pgp-signature" X-Mailman-Approved-At: Tue, 06 Nov 2012 08:06:34 -0800 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] R: R: High-level considerations about "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: Mon, 05 Nov 2012 18:21:59 -0000 --Sig_/TrLIQuQWSohLcg2w/Kz.3Ku Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Paul, > So you want a JRD RFC, not just a JRD section in WF? If so, we need > someone to author that immediately. I'm totally fine with JRD being defined as it is currently, in RFC 6415, Appendix A.=20 I see no value in having it in an independent RFC. The goal cannot (and must not) be to have a totally self-contained RFC that is only two sentences long. It's very fine to built up on others. --=20 Regards/Mit freundlichen Gr=C3=BC=C3=9Fen Christian Weiske -=3D=E2=89=A1 Geeking around in the name of science since 1982 =E2=89=A1=3D- --Sig_/TrLIQuQWSohLcg2w/Kz.3Ku Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlCYA8AACgkQFMhaCCTq+CM3bQCcDgmEQiTRKI30HOQNzQGT8jgB 0zUAniDOl24pugVpGwEv09Iki6+A6R2m =1v/m -----END PGP SIGNATURE----- --Sig_/TrLIQuQWSohLcg2w/Kz.3Ku-- From dick.hardt@gmail.com Mon Nov 5 12:04:55 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 1B18B21F8201 for ; Mon, 5 Nov 2012 12:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.871 X-Spam-Level: X-Spam-Status: No, score=-3.871 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 1UnxH+AnM+sn for ; Mon, 5 Nov 2012 12:04:54 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2546821F879E for ; Mon, 5 Nov 2012 12:04:54 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so2820272dan.31 for ; Mon, 05 Nov 2012 12:04:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=rct/TeOXY+1IHIL6Myzc2x2FJwLh6y2Be/M/1EavAko=; b=uHcSA45Xwu7LCryyaOamweoHfmY7Sb/uUnANWernNlTHsHzbbSeuDFJ6hLjYbgyvq0 eThI81Wbm6p8tG8kqZkz2uHTHW0XIK1xXRaFBkoeq4oBC733jzyHMeUg5hwYiJ6GPfRh +yLm5swjqbSFbjS/MX8NgsPe8JF8nEUo7154OYQ2xOW0ozHdUk1D3zk/vG3xrG6ZsBPg tB6LxhU8Xy2bb67YxNFxfea+VNGoHUhRERRp7otSCyhV309GFmR7f2hZMwLLoYTN9J/W UpSe0BZqUD1v8utHWYEgqD3Zr60IMR6qNu6RTN4PFxG4Q7l9+fEkiJsQnBBjJIkFgOin /1Pw== Received: by 10.68.224.69 with SMTP id ra5mr33320245pbc.114.1352145893532; Mon, 05 Nov 2012 12:04:53 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id us7sm11021524pbc.40.2012.11.05.12.04.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Nov 2012 12:04:50 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1BAF0A98-A28A-4514-A9E1-17C6C96DD7D7" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <6271c53a-454b-4553-943a-15979db70a00@email.android.com> Date: Mon, 5 Nov 2012 12:04:46 -0800 Message-Id: <325BF877-6D97-4F12-B532-278CFBA0191F@gmail.com> References: <20121105192152.6d65ed7a@bogo> <6271c53a-454b-4553-943a-15979db70a00@email.android.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Tue, 06 Nov 2012 08:06:48 -0800 Cc: Christian Weiske , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] R: High-level considerations about "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: Mon, 05 Nov 2012 20:04:55 -0000 --Apple-Mail=_1BAF0A98-A28A-4514-A9E1-17C6C96DD7D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I just read RFC 6415 Appendix A = http://tools.ietf.org/html/rfc6415#appendix-A A JRD is defined in context of an XRD. To understand the Appendix, one = must understand XRD.=20 Let's take for example the "expires" property. The Appendix says it is a = string. =20 To figure out the format of the string, one must dig through RFC 6415 to = realize that it does not define XRD, you must go to the OASIS spec, = specifically: = http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.expires When you go there, it is not clear what the format should be. The = example does not have a time string in it. There is a reference to it = being in URC form. IMHO: the JRD reference was an attempt to appease those that wanted JSON = instead of XML. Referencing RFC 6415 may be the easy path, but it puts a = large burden on implementors in trying to figure out the document = format. It is like defining JSON in terms of XML. Yuck. -- Dick On Nov 5, 2012, at 11:23 AM, "Paul E. Jones" = wrote: > That offers a third option. We have: > * New draft for JRD > * Reference to RFC 6415 > * inclusion of JRD description in new WF draft >=20 > I thought folks wanted the latter, even if redundant. I have no = preference, but I thought folks wanted to have no references to the = host-meta do. >=20 > Paul >=20 >=20 >=20 > From: Christian Weiske > Sent: Mon Nov 05 13:21:52 EST 2012 > To: webfinger@googlegroups.com > Cc: "apps-discuss@ietf.org" > Subject: Re: R: [apps-discuss] R: High-level considerations about = "webfinger" >=20 > Hello Paul, >=20 >=20 > So you want a JRD RFC, not just a JRD section in WF? If so, we need > someone to author that immediately. >=20 > I'm totally fine with JRD being defined as it is currently, in RFC > 6415, Appendix A.=20 >=20 > I see no value in having it in an independent RFC. The goal cannot = (and > must not) be to have a totally self-contained RFC that is only two > sentences long. It's very fine to built up on others. >=20 --Apple-Mail=_1BAF0A98-A28A-4514-A9E1-17C6C96DD7D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = just read RFC 6415 Appendix A http://tools.ietf.o= rg/html/rfc6415#appendix-A

A JRD is defined in = context of an XRD. To understand the Appendix, one must understand = XRD. 

Let's take for example the "expires" = property. The Appendix says it is a string. =  

To figure out the format of the string, = one must dig through RFC 6415 to realize that it does not define XRD, =  you must go to the OASIS spec, specifically: http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.expires





That offers a third option. We have:
* New draft for JRD
* Reference to RFC 6415
* inclusion of JRD description in new WF draft

I = thought folks wanted the latter, even if redundant. I have no = preference, but I thought folks wanted to have no references to the = host-meta do.

Paul



From: Christian Weiske <cweiske@cweiske.de>
Sent: Mon Nov 05 13:21:52 EST 2012
To: webfinger@googlegroups.com<= br> Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: R: [apps-discuss] R: High-level considerations = about "webfinger"

Hello Paul,


So you want a JRD RFC, not just a =
JRD section in WF? If so, we need
someone to author that =
immediately.

I'm totally fine with JRD being defined as =
it is currently, in RFC
6415, Appendix A. 

I see no value in =
having it in an independent RFC. The goal cannot (and
must not) be to =
have a totally self-contained RFC that is only two
sentences long. =
It's very fine to built up on =
others.


= --Apple-Mail=_1BAF0A98-A28A-4514-A9E1-17C6C96DD7D7-- From dick.hardt@gmail.com Mon Nov 5 13:50: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 3117021F882E for ; Mon, 5 Nov 2012 13:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 fsKURz-eL2lx for ; Mon, 5 Nov 2012 13:50:24 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 622DA21F8B46 for ; Mon, 5 Nov 2012 13:50:24 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so2853188dan.31 for ; Mon, 05 Nov 2012 13:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=YMyMRyNhThXKzffKdCTmpIMZMMw2JGg7FYX64f+iv7A=; b=gpXTwsfGWgZbeeKV68tjWGdrUUsFfg3p1vmXtAaMDAT/kvYUOCPhtUHYfGD4gAoRv0 5wpVlVVcA+t4AFo87E2OTkURcd4QR9t5W+LvX06e63n6KrACxb+rjIRYna8IPVLacrvS 5vH+sVn6ciYBBDN/6XH2hlurtAK7/1Ra8O65C6UBUYWAoB5Q+kj26cBlVpzaXjEHLbzU hLqIRv3LK1CJe/Zl4ix/07zcwkIFRM643mT07qmGe4/pBExYJ8EQFOlS3Viz86iHHBaE IXPsmtLmlgHDw7+/PKan+zPDHiOWGvi8hp/vd14SsxMLoRcnPV+nmq7I6KDrw4OuLNYv CevQ== Received: by 10.66.79.166 with SMTP id k6mr32144295pax.25.1352152223987; Mon, 05 Nov 2012 13:50:23 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id ju7sm11129054pbb.60.2012.11.05.13.50.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Nov 2012 13:50:20 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E98556D9-8A6D-4272-8DB0-25B8ABCC3F12" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Mon, 5 Nov 2012 13:50:15 -0800 Message-Id: References: <20121105192152.6d65ed7a@bogo> <6271c53a-454b-4553-943a-15979db70a00@email.android.com> <325BF877-6D97-4F12-B532-278CFBA0191F@gmail.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Tue, 06 Nov 2012 08:07:01 -0800 Cc: Christian Weiske , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] High-level considerations about "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: Mon, 05 Nov 2012 21:50:25 -0000 --Apple-Mail=_E98556D9-8A6D-4272-8DB0-25B8ABCC3F12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 5, 2012, at 12:56 PM, Brad Fitzpatrick = wrote: > On Mon, Nov 5, 2012 at 9:04 PM, Dick Hardt = wrote: > I just read RFC 6415 Appendix A = http://tools.ietf.org/html/rfc6415#appendix-A >=20 > A JRD is defined in context of an XRD. To understand the Appendix, one = must understand XRD.=20 > [...]=20 > It is like defining JSON in terms of XML. Yuck. >=20 > I agree that it's twisty and not ideal, but on the other hand, it = provides a JSON example which is pretty much sufficient on its own. >=20 > I'm ambivalent here, torn between pedantry and impatience. How about we ensure we have broad example JRD coverage in the WebFinger = specification and then reference RFC 6415 Appendix A? With enough variety in examples in this spec, an implementor can figure = out what to output and what to expect without having to parse several = other specifications. -- Dick --Apple-Mail=_E98556D9-8A6D-4272-8DB0-25B8ABCC3F12 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Nov 5, 2012, at 12:56 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:

On Mon, Nov 5, 2012 at 9:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I just read RFC 6415 Appendix A http://tools.ietf.org/html/rfc6415#appendix-A

A JRD is defined in context of an XRD. To understand the Appendix, one must understand XRD. 
[...] 
It is like defining JSON in terms of XML. Yuck.

I agree that it's twisty and not ideal, but on the other hand, it provides a JSON example which is pretty much sufficient on its own.

I'm ambivalent here, torn between pedantry and impatience.

How about we ensure we have broad example JRD coverage in the WebFinger specification and then reference RFC 6415 Appendix A?

With enough variety in examples in this spec, an implementor can figure out what to output and what to expect without having to parse several other specifications.

-- Dick

--Apple-Mail=_E98556D9-8A6D-4272-8DB0-25B8ABCC3F12-- From stefan@skoegl.net Mon Nov 5 08:52: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 7677F21F866F for ; Mon, 5 Nov 2012 08:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.574 X-Spam-Level: X-Spam-Status: No, score=-0.574 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HELO_IS_SMALL6=0.556, HOST_EQ_AT=0.745, 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 HZavDRPKXgYN for ; Mon, 5 Nov 2012 08:52:12 -0800 (PST) Received: from k-wh.at (k-wh.at [83.169.20.177]) by ietfa.amsl.com (Postfix) with ESMTP id F2B0D21F88F5 for ; Mon, 5 Nov 2012 08:52:11 -0800 (PST) Received: from [192.168.0.133] (vie-91-186-151-021.dsl.sil.at [91.186.151.21]) (Authenticated sender: stefan@skoegl.net) by k-wh.at (Postfix) with ESMTPSA id 0A0F23E70006; Mon, 5 Nov 2012 17:52:09 +0100 (CET) Message-ID: <5097EEB3.3020506@skoegl.net> Date: Mon, 05 Nov 2012 17:52:03 +0100 From: =?UTF-8?B?U3RlZmFuIEvDtmds?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Paul C. Bryan" References: <5086C026.7030908@skoegl.net> <1351207531.29744.17.camel@pbryan-wsl.internal.salesforce.com> In-Reply-To: <1351207531.29744.17.camel@pbryan-wsl.internal.salesforce.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 06 Nov 2012 08:07:14 -0800 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] draft-ietf-appsawg-json-pointer 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, 05 Nov 2012 16:53:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks for your answers! I'm using Python's built-in JSON library [1] but the general approach is that my library should work after JSON deserialization. Anyway, my intent was mainly to clarify if this was a topic that might be covered in the spec. I now understand that this is out of scope and should be decided by each implementation individually. Thanks, Stefan [1] http://docs.python.org/3/library/json.html On 10/26/2012 01:25 AM, Paul C. Bryan wrote: > I agree. JSON specifies only strings as member names, so there is > no ambiguity when resolving within an object. This issue boils-down > to the difference between JSON objects and Python dictionaries. > > To help answer your question, perhaps I could know more about the > Python JSON library you're using to serialize Python data > structures. How will it handle the case where a key is not a > string? > > Without knowing this, I would be inclined to fail on non-string > keys, because the data structure is not conforming to the JSON > specification. > > Paul > > On Wed, 2012-10-24 at 16:02 +1100, Mark Nottingham wrote: >> [forwarding to the WG] >> >> Hi Stefan, >> >> My .02 - this is really a question about JSON implementation, I >> think. JSON-Patch is designed to operate upon JSON documents >> (where this question doesn't come up), not upon Python data >> structures. >> >> Cheers, >> >> >> On 24/10/2012, at 3:04 AM, Stefan Kögl > > wrote: >> > Dear Working Group, > > I'm the maintainer of python-json-pointer [1], a Python > implementation of the json-pointer drafts. > > In Python the natural representation of a JSON object is a > dictionary. One of the differences is that a Python dictionary can > have keys of different types. I could, for instance, define the > following dictionary > > {"1": "a", 1: "b"} > > and try to resolve the pointer /1. I see several possible ways of > resolving such cases: > > * Ignore any non-string key * Fail on non-string keys * Interpret > both keys as equal and fail according to the following sentence of > the current draft: " If a referenced member name is not unique in > an object, the member that is referenced is not unique in an > object, the member that is referenced is undefined, and evaluation > fails (see below). " > > I understand that this problem can not occur in "pure" JSON where > keys can only be strings, but I assume that also implementations > in other languages will face the same issue. What is the opinion of > the working group on this? Maybe it could be addressed in future > drafts. > > > Best regards, > > Stefan Kögl > > > [1] https://github.com/stefankoegl/python-json-pointer >> >> -- Mark Nottingham http://www.mnot.net/ >> >> >> >> _______________________________________________ apps-discuss >> mailing list apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCX7rMACgkQ638pvJMAJ9AIFACgrcT9n9qfWcdUEc5AzISiCkZs BssAn1j+MfSCjXl/JZpVZ6DsPOgZaYSY =74JE -----END PGP SIGNATURE----- From ned.freed@mrochek.com Tue Nov 6 08: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 0C88A21F89CF; Tue, 6 Nov 2012 08:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 EuMchI1dW9Jn; Tue, 6 Nov 2012 08:17:43 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5396221F8A58; Tue, 6 Nov 2012 08:17:43 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMANPO7AYO001A9X@mauve.mrochek.com>; Tue, 6 Nov 2012 08:12:37 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OLSVO3D2CW00008S@mauve.mrochek.com>; Tue, 6 Nov 2012 08:12:33 -0800 (PST) Message-id: <01OMANPLEZ0400008S@mauve.mrochek.com> Date: Tue, 06 Nov 2012 07:58:51 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 06 Nov 2012 10:02:59 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20121105155412.4054.20989.idtracker@ietfa.amsl.com> To: ht@inf.ed.ac.uk Cc: internet-drafts@ietf.org, apps-discuss@ietf.org, i-d-announce@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-08.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, 06 Nov 2012 16:17:44 -0000 > internet-drafts writes: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > > > Title : Additional Media Type Structured Syntax Suffixes > > Author(s) : Tony Hansen > > Alexey Melnikov > > Filename : draft-ietf-appsawg-media-type-suffix-regs-08.txt > Given that > draft-lilley-xml-mediatypes-00 > has now been published, is the patch to RFC3023 in section 4 of this > document really necessary? Short answer: Yes. Long answer: The fact that another draft has been posted doesn't mean that it will ever become an RFC, or if it does, that it will happen in a useful amount of time. My records indicate that the process that led to RFC 3023 being published in January, 2001 actually began no later than April, 1999 - and that was when there were far fewer players and much simpler concerns to address. Additionally, this is a consensus document that has been through last call and is close to being approved for publication. Reopening it now just to remove something that might possibly in the future be addressed by some other document makes no sense. Ned From GK@ninebynine.org Tue Nov 6 09:08: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 B25EB21F8606 for ; Tue, 6 Nov 2012 09:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 roeJBJvXCMNo for ; Tue, 6 Nov 2012 09:08:47 -0800 (PST) Received: from relay8.mail.ox.ac.uk (relay8.mail.ox.ac.uk [129.67.1.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7309F21F855C for ; Tue, 6 Nov 2012 09:08:46 -0800 (PST) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay8.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TVmdn-0008Un-Ss; Tue, 06 Nov 2012 17:08:43 +0000 Received: from dhcp8.zoo.ox.ac.uk ([129.67.25.248]) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TVmdn-00083y-2p; Tue, 06 Nov 2012 17:08:43 +0000 Message-ID: <5099408C.7050702@ninebynine.org> Date: Tue, 06 Nov 2012 16:53:32 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" References: In-Reply-To: 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] open issues with acct-uri spec 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, 06 Nov 2012 17:08:48 -0000 I've argued elsewhere that I think the normal resolution protocol for acct: should be WebFinger. Then the port world make sense, IMO. #g -- On 06/11/2012 13:09, Joe Hildebrand (jhildebr) wrote: > If there's a port, you have to specify a protocol, in which case acct: > doesn't make sense to me. > > > On 11/6/12 7:49 AM, "John Bradley" wrote: > >> Is including a port number valid? >> >>From my read it would not be. >> >> For debugging/testing we want to be able to run the resolver on an >> alternate port. >> >> Entering acct:ve7jtb@ve7jtb.com:4444 >> >> I think that was the proposal that Mike was making yesterday in the apps >> area meeting. >> >> >> John B. >> >> On 2012-11-05, at 4:29 PM, Peter Saint-Andre wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 11/1/12 11:10 AM, t.petch wrote: >>>> ----- Original Message ----- From: "Peter Saint-Andre" >>>> To: Cc: "'Graham >>>> Klyne'" Sent: Monday, October 29, 2012 2:47 PM >>>>> >>>>> I see two open issues with draft-ietf-appsawg-acct-uri (which I >>>>> think we can resolve on the mailing list, thus saving precious >>>>> meeting time for topics that require realtime discussion): >>>>> >>>>> 1. In version -01, I think that I was too aggressive about trying >>>>> to simplify the ABNF, to wit: >>>>> >>>>> acctURI = "acct" ":" userinfo "@" host >>>>> >>>>> The userinfo rule allows the colon character ':', but I don't >>>>> think that's what we want here. Instead, I think we want: >>>>> >>>>> acctURI = "acct" ":" userpart "@" host userpart = 1*( >>>>> unreserved / pct-encoded / sub-delims ) >>>>> >>>>> If you disagree with that definition, please reply to this >>>>> message. >>>> >>>> This definition bears a passing resemblance to that of an e-mail >>>> address, which makes me wonder whether or not the syntax should be >>>> aligned with that of e-mail with a reference thereto. I understand >>>> the change you have just made, but cannot see a rationale for it. >>>> It is not that I disagree with the definition but that I disagree >>>> with the reason for it, not knowing what that is. >>> >>> The change is intended to remove ':' from the allowable characters in >>> the localpart, since the point of ':' as a delimiter (as I understand >>> it) was to allow localparts of the "username:password". >>> >>> I do think it would be helpful to show how various protocol >>> identifiers (for email, SIP, XMPP, etc.) can be translated to 'acct' >>> URIs, similar to what we did in section 4 of >>> draft-saintandre-sip-xmpp-core: >>> >>> http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-02#section-4 >>> >>> I'm not sure if that belongs in the acct-uri spec, but it might be >>> helpful to document somewhere (e.g., on a wiki page). >>> >>> Peter >>> >>> - -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>> >>> iEYEARECAAYFAlCYL7IACgkQNL8k5A2w/vx60gCgw/jxQTIThFHRW7wqLXxfIziK >>> OMUAn1XMFoRGn4eB5iT3nd31MsaU91Mx >>> =5QSV >>> -----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 >> > > > From GK@ninebynine.org Tue Nov 6 09:08: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 0C60B21F855C for ; Tue, 6 Nov 2012 09:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 8N+cgFFxUWVI for ; Tue, 6 Nov 2012 09:08:48 -0800 (PST) Received: from relay8.mail.ox.ac.uk (relay8.mail.ox.ac.uk [129.67.1.171]) by ietfa.amsl.com (Postfix) with ESMTP id AAD4E21F8604 for ; Tue, 6 Nov 2012 09:08:47 -0800 (PST) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay8.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TVmdo-0008Up-Qs; Tue, 06 Nov 2012 17:08:44 +0000 Received: from dhcp8.zoo.ox.ac.uk ([129.67.25.248]) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TVmdo-000841-0q; Tue, 06 Nov 2012 17:08:44 +0000 Message-ID: <50994269.8050701@ninebynine.org> Date: Tue, 06 Nov 2012 17:01:29 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mike Jones References: <6629092F-6FA6-4600-AB38-1D5184193ED2@ve7jtb.com> <4E1F6AAD24975D4BA5B1680429673943668A31C7@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668A31C7@TK5EX14MBXC283.redmond.corp.microsoft.com> 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] open issues with acct-uri spec 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, 06 Nov 2012 17:08:49 -0000 Hmmm. This feels a bit screwy to me. Not fatal, just with potential to surprise. If acct: URIs are considered as locators using the WebFinger protocol - this does not preclude using them as identifiers in other contexts using different protocols - then it makes sense to allow and recognize port numbers. Then all of this use of alternative ports for testing, etc., just works without any further dance. (As webfinger runs over HTTP, I expect the default port is just 80.) IMO, treating acct: URIs as much as possible like other familiar URIs reduces the need for additional verbal gymnastics to explain what's going on. #g -- On 06/11/2012 14:27, Mike Jones wrote: > The point I was making about ports at the meeting yesterday was that it should be explicitly allowed to run WebFinger on alternate ports, provided those ports also use TLS. This is useful for debugging configurations and potentially other situations as well. As I said yesterday, specifying how to select the alternative port is out of scope for the WebFinger spec. > > For OpenID Connect identifier normalization, I would propose that we do allow port numbers on e-mail-syntax identifiers. For instance, we should accept ve7jtb@ve7jtb.com:8888 to say that discovery for the identifier ve7jtb@ve7jtb.com is to be performed on the discovery server at port 8888. > > That's a different thing than whether acct: needs to allow port numbers. I could discover acct:ve7jtb@ve7jtb.com at the port 8888 discovery server based upon the user input ve7jtb@ve7jtb.com:8888 without incurring any interoperability issues. > > Make sense to everyone? > > -- Mike > > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley > Sent: Tuesday, November 06, 2012 5:49 AM > To: Joe Hildebrand (jhildebr) > Cc: 'Graham Klyne'; apps-discuss@ietf.org > Subject: Re: [apps-discuss] open issues with acct-uri spec > > There is a relationship between acct: and Web-Finger where it is treated by the protocol as a locator. > > Saying that you can't specify a alternate port for web-finger to use as part of the locator is fine, as long as people understand what is happening. > > The Web-Finger spec will have to provide guidance on how input is normalized. > acct:ve7jtb@ve7jtb.com:8888 Is invalid and rejected > ve7jtb@ve7jtb.com Is normalized to acct:ve7jtb@ve7jtb.com for input to the resolver > ve7jtb@ve7jtb.com:8888 May be a interoperability issue as I can imagine a number of interpretations. > > My concerns are that whatever the final spec it is interoperable. > > I have this nagging feeling that allowing any string as input in WF may be something that is never used and complicates the spec or is never used in practice. > > This is probably more a WF issue. > > John B. > > On 2012-11-06, at 8:09 AM, "Joe Hildebrand (jhildebr)" wrote: > >> If there's a port, you have to specify a protocol, in which case acct: >> doesn't make sense to me. >> >> >> On 11/6/12 7:49 AM, "John Bradley" wrote: >> >>> Is including a port number valid? >>> >>> From my read it would not be. >>> >>> For debugging/testing we want to be able to run the resolver on an >>> alternate port. >>> >>> Entering acct:ve7jtb@ve7jtb.com:4444 >>> >>> I think that was the proposal that Mike was making yesterday in the >>> apps area meeting. >>> >>> >>> John B. >>> >>> On 2012-11-05, at 4:29 PM, Peter Saint-Andre wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 11/1/12 11:10 AM, t.petch wrote: >>>>> ----- Original Message ----- From: "Peter Saint-Andre" >>>>> To: Cc: "'Graham >>>>> Klyne'" Sent: Monday, October 29, 2012 2:47 PM >>>>>> >>>>>> I see two open issues with draft-ietf-appsawg-acct-uri (which I >>>>>> think we can resolve on the mailing list, thus saving precious >>>>>> meeting time for topics that require realtime discussion): >>>>>> >>>>>> 1. In version -01, I think that I was too aggressive about trying >>>>>> to simplify the ABNF, to wit: >>>>>> >>>>>> acctURI = "acct" ":" userinfo "@" host >>>>>> >>>>>> The userinfo rule allows the colon character ':', but I don't >>>>>> think that's what we want here. Instead, I think we want: >>>>>> >>>>>> acctURI = "acct" ":" userpart "@" host userpart = 1*( >>>>>> unreserved / pct-encoded / sub-delims ) >>>>>> >>>>>> If you disagree with that definition, please reply to this >>>>>> message. >>>>> >>>>> This definition bears a passing resemblance to that of an e-mail >>>>> address, which makes me wonder whether or not the syntax should be >>>>> aligned with that of e-mail with a reference thereto. I understand >>>>> the change you have just made, but cannot see a rationale for it. >>>>> It is not that I disagree with the definition but that I disagree >>>>> with the reason for it, not knowing what that is. >>>> >>>> The change is intended to remove ':' from the allowable characters >>>> in the localpart, since the point of ':' as a delimiter (as I >>>> understand >>>> it) was to allow localparts of the "username:password". >>>> >>>> I do think it would be helpful to show how various protocol >>>> identifiers (for email, SIP, XMPP, etc.) can be translated to 'acct' >>>> URIs, similar to what we did in section 4 of >>>> draft-saintandre-sip-xmpp-core: >>>> >>>> http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-02#section >>>> -4 >>>> >>>> I'm not sure if that belongs in the acct-uri spec, but it might be >>>> helpful to document somewhere (e.g., on a wiki page). >>>> >>>> Peter >>>> >>>> - -- >>>> Peter Saint-Andre >>>> https://stpeter.im/ >>>> >>>> >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>>> >>>> iEYEARECAAYFAlCYL7IACgkQNL8k5A2w/vx60gCgw/jxQTIThFHRW7wqLXxfIziK >>>> OMUAn1XMFoRGn4eB5iT3nd31MsaU91Mx >>>> =5QSV >>>> -----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 >>> >> >> >> >> -- >> Joe Hildebrand >> >> >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From jasnell@gmail.com Tue Nov 6 09:49: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 C405F21F87F2 for ; Tue, 6 Nov 2012 09:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[AWL=0.330, 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 tKsApCRbHQbY for ; Tue, 6 Nov 2012 09:48:59 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF29521F85C7 for ; Tue, 6 Nov 2012 09:48:58 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so1159778iec.31 for ; Tue, 06 Nov 2012 09:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=NFf+/e+xvzQUEjAWygGqXUHdXNd/ZoNFuociDEgn+vs=; b=wuVeb5uTQNT2AJG3qaeVfraJmK0wN14hqk9PWRQAvDiy1teIED/mo4GFOYHGdmZTiL odSkxj2ZjGQ45GVLKPy3t65VkxamvTRXVo2kNvz+o7gAYCwkZwIzewXprKuWSlQR1xJd 9W3D8SGNjnOaaAtl5JpMADzfYOgyQQrUyQmFLL0zsDxrj3tbqIxF1V5aP98ttAkdmb3V Ntn/3GZeZp4rysS7BYZdS4z006AtQWDXzlyfKIwfVEc/jqRjDo/OStu1FMPH8sQDvPJE 92wQbR1dd/Hqgvz760lcTQGcaqvFlCdPpO1vGPfqegWAVutCIRvpWJbTZ+4ACV5OAhx3 pkYQ== Received: by 10.50.95.161 with SMTP id dl1mr14140855igb.0.1352224138429; Tue, 06 Nov 2012 09:48:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.225 with HTTP; Tue, 6 Nov 2012 09:48:38 -0800 (PST) From: James M Snell Date: Tue, 6 Nov 2012 09:48:38 -0800 Message-ID: To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=e89a8f3b9c3f6d854104cdd737ee Subject: [apps-discuss] Updated JSON Merge Patch 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, 06 Nov 2012 17:49:00 -0000 --e89a8f3b9c3f6d854104cdd737ee Content-Type: text/plain; charset=UTF-8 Slightly updated JSON Merge Patch draft posted yesterday... http://tools.ietf.org/html/draft-snell-merge-patch-07 Main difference is the inclusion of a simple reference javascript implementation. Not designed to be an optimal implementation, just get the point across and demonstrate the functionality. I'm quite certain better code could be written for it.. - James --e89a8f3b9c3f6d854104cdd737ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Slightly updated JSON Merge Patch dra= ft posted yesterday...=C2=A0


Main difference is the inclusion o= f a simple reference javascript implementation. Not designed to be an optim= al implementation, just get the point across and demonstrate the functional= ity. I'm quite certain better code could be written for it..

- James
--e89a8f3b9c3f6d854104cdd737ee-- From evan@status.net Tue Nov 6 11:30: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 0D10D21F85E8 for ; Tue, 6 Nov 2012 11:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=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 xtFhpAoxdo+A for ; Tue, 6 Nov 2012 11:30:02 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id CA6FB21F85C6 for ; Tue, 6 Nov 2012 11:30:02 -0800 (PST) Received: from [192.168.0.101] (modemcable036.53-22-96.mc.videotron.ca [96.22.53.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id B5D878D454D for ; Tue, 6 Nov 2012 19:41:33 +0000 (UTC) Message-ID: <5099652C.107@status.net> Date: Tue, 06 Nov 2012 14:29:48 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <6629092F-6FA6-4600-AB38-1D5184193ED2@ve7jtb.com> In-Reply-To: <6629092F-6FA6-4600-AB38-1D5184193ED2@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------050406080407090105040307" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 06 Nov 2012 19:30:04 -0000 This is a multi-part message in MIME format. --------------050406080407090105040307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -1 If you don't have control over port 80, you don't have control of the domain and you shouldn't be implementing Webfinger. There are many ways to test Webfinger implementations without using alternate ports. 1. Use the ".test" TLD reserved for this very use by RFC 2606. "ve7jtb@ve7jtb.test". 2. Use a sub-domain, "ve7jtb@test.ve7jtb.com" -Evan On 12-11-06 08:48 AM, John Bradley wrote: > There is a relationship between acct: and Web-Finger where it is treated by the protocol as a locator. > > Saying that you can't specify a alternate port for web-finger to use as part of the locator is fine, as long as people understand what is happening. > > The Web-Finger spec will have to provide guidance on how input is normalized. > acct:ve7jtb@ve7jtb.com:8888 Is invalid and rejected > ve7jtb@ve7jtb.com Is normalized to acct:ve7jtb@ve7jtb.com for input to the resolver > ve7jtb@ve7jtb.com:8888 May be a interoperability issue as I can imagine a number of interpretations. > > My concerns are that whatever the final spec it is interoperable. > > I have this nagging feeling that allowing any string as input in WF may be something that is never used and complicates the spec or is never used in practice. > > This is probably more a WF issue. > > John B. > > On 2012-11-06, at 8:09 AM, "Joe Hildebrand (jhildebr)" wrote: > >> If there's a port, you have to specify a protocol, in which case acct: >> doesn't make sense to me. >> >> >> On 11/6/12 7:49 AM, "John Bradley" wrote: >> >>> Is including a port number valid? >>> >>> From my read it would not be. >>> >>> For debugging/testing we want to be able to run the resolver on an >>> alternate port. >>> >>> Entering acct:ve7jtb@ve7jtb.com:4444 >>> >>> I think that was the proposal that Mike was making yesterday in the apps >>> area meeting. >>> >>> >>> John B. >>> >>> On 2012-11-05, at 4:29 PM, Peter Saint-Andre wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 11/1/12 11:10 AM, t.petch wrote: >>>>> ----- Original Message ----- From: "Peter Saint-Andre" >>>>> To: Cc: "'Graham >>>>> Klyne'" Sent: Monday, October 29, 2012 2:47 PM >>>>>> I see two open issues with draft-ietf-appsawg-acct-uri (which I >>>>>> think we can resolve on the mailing list, thus saving precious >>>>>> meeting time for topics that require realtime discussion): >>>>>> >>>>>> 1. In version -01, I think that I was too aggressive about trying >>>>>> to simplify the ABNF, to wit: >>>>>> >>>>>> acctURI = "acct" ":" userinfo "@" host >>>>>> >>>>>> The userinfo rule allows the colon character ':', but I don't >>>>>> think that's what we want here. Instead, I think we want: >>>>>> >>>>>> acctURI = "acct" ":" userpart "@" host userpart = 1*( >>>>>> unreserved / pct-encoded / sub-delims ) >>>>>> >>>>>> If you disagree with that definition, please reply to this >>>>>> message. >>>>> This definition bears a passing resemblance to that of an e-mail >>>>> address, which makes me wonder whether or not the syntax should be >>>>> aligned with that of e-mail with a reference thereto. I understand >>>>> the change you have just made, but cannot see a rationale for it. >>>>> It is not that I disagree with the definition but that I disagree >>>>> with the reason for it, not knowing what that is. >>>> The change is intended to remove ':' from the allowable characters in >>>> the localpart, since the point of ':' as a delimiter (as I understand >>>> it) was to allow localparts of the "username:password". >>>> >>>> I do think it would be helpful to show how various protocol >>>> identifiers (for email, SIP, XMPP, etc.) can be translated to 'acct' >>>> URIs, similar to what we did in section 4 of >>>> draft-saintandre-sip-xmpp-core: >>>> >>>> http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-02#section-4 >>>> >>>> I'm not sure if that belongs in the acct-uri spec, but it might be >>>> helpful to document somewhere (e.g., on a wiki page). >>>> >>>> Peter >>>> >>>> - -- >>>> Peter Saint-Andre >>>> https://stpeter.im/ >>>> >>>> >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>>> >>>> iEYEARECAAYFAlCYL7IACgkQNL8k5A2w/vx60gCgw/jxQTIThFHRW7wqLXxfIziK >>>> OMUAn1XMFoRGn4eB5iT3nd31MsaU91Mx >>>> =5QSV >>>> -----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 >>> >> >> >> -- >> Joe Hildebrand >> >> >> > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Evan Prodromou, CEO and Founder, StatusNet Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@status.net P: +1-514-554-3826 --------------050406080407090105040307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
-1

If you don't have control over port 80, you don't have control of the domain and you shouldn't be implementing Webfinger.

There are many ways to test Webfinger implementations without using alternate ports.
  1. Use the ".test" TLD reserved for this very use by RFC 2606. "ve7jtb@ve7jtb.test".
  2. Use a sub-domain, "ve7jtb@test.ve7jtb.com"
-Evan

On 12-11-06 08:48 AM, John Bradley wrote:
There is a relationship between acct: and Web-Finger where it is treated by the protocol as a locator. 

Saying that you can't specify a alternate port for web-finger to use as part of the locator is fine, as long as people understand what is happening.

The Web-Finger spec will have to provide guidance on how input is normalized.
acct:ve7jtb@ve7jtb.com:8888    Is invalid and rejected
ve7jtb@ve7jtb.com                       Is normalized to  acct:ve7jtb@ve7jtb.com  for input to the resolver
ve7jtb@ve7jtb.com:8888             May be a interoperability issue as I can imagine a number of interpretations.

My concerns are that whatever the final spec it is interoperable.

I have this nagging feeling that allowing any string as input in WF may be something that is never used and complicates the spec or is never used in practice.

This is probably more a WF issue.

John B.

On 2012-11-06, at 8:09 AM, "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com> wrote:


If there's a port, you have to specify a protocol, in which case acct:
doesn't make sense to me.


On 11/6/12 7:49 AM, "John Bradley" <ve7jtb@ve7jtb.com> wrote:


Is including a port number valid?

>From my read it would not be.

For debugging/testing we want to be able to run the resolver on an
alternate port.  

Entering acct:ve7jtb@ve7jtb.com:4444

I think that was the proposal that Mike was making yesterday in the apps
area meeting.


John B.

On 2012-11-05, at 4:29 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:


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

On 11/1/12 11:10 AM, t.petch wrote:

----- Original Message ----- From: "Peter Saint-Andre"
<stpeter@stpeter.im> To: <apps-discuss@ietf.org> Cc: "'Graham
Klyne'" <GK@ninebynine.org> Sent: Monday, October 29, 2012 2:47 PM

I see two open issues with draft-ietf-appsawg-acct-uri (which I
think we can resolve on the mailing list, thus saving precious
meeting time for topics that require realtime discussion):

1. In version -01, I think that I was too aggressive about trying
to simplify the ABNF, to wit:

acctURI      =  "acct" ":" userinfo "@" host

The userinfo rule allows the colon character ':', but I don't
think that's what we want here. Instead, I think we want:

acctURI      =  "acct" ":" userpart "@" host userpart     =  1*(
unreserved / pct-encoded / sub-delims )

If you disagree with that definition, please reply to this
message.

This definition bears a passing resemblance to that of an e-mail
address, which makes me wonder whether or not the syntax should be
aligned with that of e-mail with a reference thereto.  I understand
the change you have just made, but cannot see a rationale for it.
It is not that I disagree with the definition but that I disagree
with the reason for it, not knowing what that is.

The change is intended to remove ':' from the allowable characters in
the localpart, since the point of ':' as a delimiter (as I understand
it) was to allow localparts of the "username:password".

I do think it would be helpful to show how various protocol
identifiers (for email, SIP, XMPP, etc.) can be translated to 'acct'
URIs, similar to what we did in section 4 of
draft-saintandre-sip-xmpp-core:

http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-02#section-4

I'm not sure if that belongs in the acct-uri spec, but it might be
helpful to document somewhere (e.g., on a wiki page).

Peter

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


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

iEYEARECAAYFAlCYL7IACgkQNL8k5A2w/vx60gCgw/jxQTIThFHRW7wqLXxfIziK
OMUAn1XMFoRGn4eB5iT3nd31MsaU91Mx
=5QSV
-----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




-- 
Joe Hildebrand




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



-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net P: +1-514-554-3826
--------------050406080407090105040307-- From stpeter@stpeter.im Tue Nov 6 12:53: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 AA9A521F8A2B for ; Tue, 6 Nov 2012 12:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 LLyvtzpKS5ZS for ; Tue, 6 Nov 2012 12:53:44 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0B28521F8878 for ; Tue, 6 Nov 2012 12:53:42 -0800 (PST) Received: from [130.129.84.156] (unknown [130.129.84.156]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 169554010C; Tue, 6 Nov 2012 13:57:26 -0700 (MST) Message-ID: <509978D7.3090003@stpeter.im> Date: Tue, 06 Nov 2012 15:53:43 -0500 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Graham Klyne References: <5099408C.7050702@ninebynine.org> In-Reply-To: <5099408C.7050702@ninebynine.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 06 Nov 2012 20:53:44 -0000 On 11/6/12 11:53 AM, Graham Klyne wrote: > I've argued elsewhere that I think the normal resolution protocol for > acct: should be WebFinger. Graham, in the latest version of draft-ietf-appsawg-acct-uri I have: Because an 'acct' URI enables identification only and not interaction, it cannot be deferenced directly. Any protocol that might use the 'acct' URI scheme, such as the WebFinger protocol [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol [I-D.jones-simple-web-discovery], is responsible for specifying how an 'acct' URI is dereferenced in the context of that protocol. For example, an 'acct' URI might be passed as a parameter in an HTTP request and the service might retrieve the relevant information associated with the account identified by that URI and then provide that information to the requesting entity in an HTTP response. As far as I understand the discussion so far, other resolution protocols are allowed, which is why I wrote the text as it is right now. Feedback is welcome. Peter -- Peter Saint-Andre https://stpeter.im/ From GK@ninebynine.org Tue Nov 6 15:20: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 2F98D21F8B7B for ; Tue, 6 Nov 2012 15:20:18 -0800 (PST) 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 bLsDx3us3ORa for ; Tue, 6 Nov 2012 15:20:17 -0800 (PST) Received: from relay8.mail.ox.ac.uk (relay8.mail.ox.ac.uk [129.67.1.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1C01721F8B07 for ; Tue, 6 Nov 2012 15:20:16 -0800 (PST) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay8.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TVsRF-0005g6-RT; Tue, 06 Nov 2012 23:20:09 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TVsRF-0004hi-0T; Tue, 06 Nov 2012 23:20:09 +0000 Message-ID: <509991D0.9000007@ninebynine.org> Date: Tue, 06 Nov 2012 22:40:16 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im> In-Reply-To: <509978D7.3090003@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 06 Nov 2012 23:20:18 -0000 Peter, I saw your revised text, but it doesn't reflect my take. At the time, it didn't seem worth dragging out the discussion. You comment "other resolution protocols are allowed". Maybe there's something I'm misunderstanding here, but my perception is that this applies no more to acct: URIs than it does to any other URI scheme. That is, there's nothing to stop one using *any* URI in some resolution protocol (e.g. a database lookup, DDDS, a hash table, etc.) and there are specific situations in which this may be the right thing for an application to do. This is the light in which I see acct: URIs being used with other protocols. But stripped of context, all you're left with the the "native" dereferencing mechanism for the URI scheme, if there is one. For schemes like http:, ftp:, etc., it is generally pretty clear what is the the standard mechanism for dereferencing. For other schemes like, say, mailto: one may have to squint a little to see the standard operation (like firing uo an email client) as dereferencing, but And for schemes like urn: and info:, there is, by design, no common dereferencing mechanism. Against this background, my perception has been that acct: is not *only* about identification. It has a specific association with WebFinger, even if it is also expected to be used with other protocols. I'm not seeing that is any different from sending an HTML document containing a mailto: URI via HTTP, there the mailto: URI is ultimately used to identify a person, not send a mail message. So I expect the acct: scheme to be associated with WebFinger in the same way that http: scheme is associated with HTTP protocol. When I reviewed acct:, I expected that part of the reason for having it as a separate URI scheme was that it could be used free of protocol context (e.g. in a web page) and still be dereferencable by some common mechanism. If I'm missing something, or if other people see this differently then that's fine. I don't want to harp on about this. But the recent discussion about acct: URIs and port numbers was, for me, a nice example of how associating acct: specifically and concretely with WebFinger and making it behave like other commonly used URIs can simplify life for some people without, as far as I can tell, taking away any of the uses that others may have in mind. #g -- On 06/11/2012 20:53, Peter Saint-Andre wrote: > On 11/6/12 11:53 AM, Graham Klyne wrote: >> I've argued elsewhere that I think the normal resolution protocol for >> acct: should be WebFinger. > > Graham, in the latest version of draft-ietf-appsawg-acct-uri I have: > > Because an 'acct' URI enables identification only and not > interaction, it cannot be deferenced directly. Any protocol that > might use the 'acct' URI scheme, such as the WebFinger protocol > [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol > [I-D.jones-simple-web-discovery], is responsible for specifying how > an 'acct' URI is dereferenced in the context of that protocol. For > example, an 'acct' URI might be passed as a parameter in an HTTP > request and the service might retrieve the relevant information > associated with the account identified by that URI and then provide > that information to the requesting entity in an HTTP response. > > As far as I understand the discussion so far, other resolution protocols > are allowed, which is why I wrote the text as it is right now. Feedback > is welcome. > > Peter > From ve7jtb@ve7jtb.com Tue Nov 6 15:54: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 29F3E21F8B4C for ; Tue, 6 Nov 2012 15:54:23 -0800 (PST) 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 gygWdFrOThRx for ; Tue, 6 Nov 2012 15:54:22 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9639021F8A63 for ; Tue, 6 Nov 2012 15:54:20 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so725496pad.31 for ; Tue, 06 Nov 2012 15:54:20 -0800 (PST) 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 :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=xowuXCd2dqZ91JMkC8VwY0ZYsSGnnaSqDjIe3m6ON3Y=; b=iPP1i55lHALOtkA65GE24mvU6d5+u/19NPSddMm7KrNAD4D966RVqkZe0XFltx7cmP vyLTsR9yM3LdfisOO4vxiWE6RnQPdBL6jnNRapOm8US2jCAlAhpO6NWX7VtlL+Xj9NIZ DYVGQhIsWqn9X6Lv1icC+4oIxdtaXCQSQIb097ezXVBAXwhCm3ALtollD9AWbOehTV9e cyKANB/xaktDHBlu8O8ILyHlAd0ICdxglYcHCaZWplWbo+bfi2DgI1EyKek8VQ+f4GD0 DeccZWLIAkGL/eKxDxFND1hxnbIdQYUWZHviKGrGGHKu6kzFsTSAuRYGR1X51tCJa00j U+ZA== Received: by 10.68.234.100 with SMTP id ud4mr8079954pbc.82.1352246060339; Tue, 06 Nov 2012 15:54:20 -0800 (PST) Received: from ?IPv6:2001:df8::64:b152:3677:fba7:9d45? ([2001:df8:0:64:b152:3677:fba7:9d45]) by mx.google.com with ESMTPS id us7sm13063054pbc.40.2012.11.06.15.54.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 15:54:19 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <509991D0.9000007@ninebynine.org> Date: Tue, 6 Nov 2012 18:54:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3E7314FA-686D-4496-9AD8-4378DAECEAA4@ve7jtb.com> References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im> <509991D0.9000007@ninebynine.org> To: Graham Klyne X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnCRDyI1ODr6Q5skaxHjXrkQzpQKadn1eyG286XyeMNGwZSidk+tnnOFBxuGWblN5ypuxZ7 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 06 Nov 2012 23:54:23 -0000 This is essentially how I see the relationship. John B. On 2012-11-06, at 5:40 PM, Graham Klyne wrote: > Peter, >=20 > I saw your revised text, but it doesn't reflect my take. At the time, = it didn't seem worth dragging out the discussion. >=20 > You comment "other resolution protocols are allowed". Maybe there's = something I'm misunderstanding here, but my perception is that this = applies no more to acct: URIs than it does to any other URI scheme. = That is, there's nothing to stop one using *any* URI in some resolution = protocol (e.g. a database lookup, DDDS, a hash table, etc.) and there = are specific situations in which this may be the right thing for an = application to do. This is the light in which I see acct: URIs being = used with other protocols. But stripped of context, all you're left = with the the "native" dereferencing mechanism for the URI scheme, if = there is one. >=20 > For schemes like http:, ftp:, etc., it is generally pretty clear what = is the the standard mechanism for dereferencing. >=20 > For other schemes like, say, mailto: one may have to squint a little = to see the standard operation (like firing uo an email client) as = dereferencing, but >=20 > And for schemes like urn: and info:, there is, by design, no common = dereferencing mechanism. >=20 > Against this background, my perception has been that acct: is not = *only* about identification. It has a specific association with = WebFinger, even if it is also expected to be used with other protocols. = I'm not seeing that is any different from sending an HTML document = containing a mailto: URI via HTTP, there the mailto: URI is ultimately = used to identify a person, not send a mail message. So I expect the = acct: scheme to be associated with WebFinger in the same way that http: = scheme is associated with HTTP protocol. When I reviewed acct:, I = expected that part of the reason for having it as a separate URI scheme = was that it could be used free of protocol context (e.g. in a web page) = and still be dereferencable by some common mechanism. >=20 > If I'm missing something, or if other people see this differently then = that's fine. I don't want to harp on about this. But the recent = discussion about acct: URIs and port numbers was, for me, a nice example = of how associating acct: specifically and concretely with WebFinger and = making it behave like other commonly used URIs can simplify life for = some people without, as far as I can tell, taking away any of the uses = that others may have in mind. >=20 > #g > -- >=20 > On 06/11/2012 20:53, Peter Saint-Andre wrote: >> On 11/6/12 11:53 AM, Graham Klyne wrote: >>> I've argued elsewhere that I think the normal resolution protocol = for >>> acct: should be WebFinger. >>=20 >> Graham, in the latest version of draft-ietf-appsawg-acct-uri I have: >>=20 >> Because an 'acct' URI enables identification only and not >> interaction, it cannot be deferenced directly. Any protocol that >> might use the 'acct' URI scheme, such as the WebFinger protocol >> [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol >> [I-D.jones-simple-web-discovery], is responsible for specifying = how >> an 'acct' URI is dereferenced in the context of that protocol. = For >> example, an 'acct' URI might be passed as a parameter in an HTTP >> request and the service might retrieve the relevant information >> associated with the account identified by that URI and then = provide >> that information to the requesting entity in an HTTP response. >>=20 >> As far as I understand the discussion so far, other resolution = protocols >> are allowed, which is why I wrote the text as it is right now. = Feedback >> is welcome. >>=20 >> Peter >>=20 From tony@att.com Tue Nov 6 16:55: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 1BEA921F8B6B for ; Tue, 6 Nov 2012 16:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[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 QScS+CjZbWYW for ; Tue, 6 Nov 2012 16:55:50 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6BF21F8B3B for ; Tue, 6 Nov 2012 16:55:50 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 591b9905.0.966332.00-336.2657022.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 07 Nov 2012 00:55:50 +0000 (UTC) X-MXL-Hash: 5099b196626e3c7c-e2d6577385788ae0e8478d686c1c972742b9d085 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 qA70tnS8013391 for ; Tue, 6 Nov 2012 19:55:49 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qA70tiO2013387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Nov 2012 19:55:45 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Tue, 6 Nov 2012 19:55:30 -0500 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 qA70tUgp026052 for ; Tue, 6 Nov 2012 19:55:30 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qA70tLTi025873 for ; Tue, 6 Nov 2012 19:55:25 -0500 Received: from [130.10.161.202] (vpn-130-10-161-202.vpn.mwst.att.com[130.10.161.202]) by maillennium.att.com (mailgw1) with ESMTP id <20121107005544gw1006323re> (Authid: tony); Wed, 7 Nov 2012 00:55:45 +0000 X-Originating-IP: [130.10.161.202] Message-ID: <5099B177.5090506@att.com> Date: Tue, 06 Nov 2012 19:55:19 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Henry S. Thompson" References: <20121105155412.4054.20989.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080506060503000605090805" 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=2.0 cv=KI7t+i5o c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=CaNOsgFdgDQA:10 a=T3ddMRUbpJkA:10 a=q6fm-fMmBdMA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=fK92HPE7] X-AnalysisOut: [l_oA:10 a=9Mr3Ubm-oeqgL2HLH-gA:9 a=wPNLvfGTeEIA:10 a=aA-rk] X-AnalysisOut: [ObNAAAA:8 a=4_NUV46K6sX02w-Ty3oA:9 a=_W_S_7VecoQA:10 a=pBY] X-AnalysisOut: [l5yfJOqKrBx6p:21] Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-08.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, 07 Nov 2012 00:55:51 -0000 This is a multi-part message in MIME format. --------------080506060503000605090805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/6/2012 5:02 AM, Henry S. Thompson wrote: > internet-drafts writes: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Applications Area Working Group Working Group of the IETF. >> >> Title : Additional Media Type Structured Syntax Suffixes >> Author(s) : Tony Hansen >> Alexey Melnikov >> Filename : draft-ietf-appsawg-media-type-suffix-regs-08.txt > Given that > > draft-lilley-xml-mediatypes-00 > > has now been published, is the patch to RFC3023 in section 4 of this > document really necessary? > > ht Yes; drafts have no official status. Also, draft-ietf-appsawg-media-type-suffix-regs-08.txt is already in the RFC-EDITOR queue. When draft-lilley-xml-mediatypes gets published as an RFC, it will then be considered an update to both RFC3023 and the RFC that draft-ietf-appsawg-media-type-suffix-regs becomes. Also, draft-lilley-xml-mediatypes will need to incorporate the registration form for +xml. Tony Hansen --------------080506060503000605090805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/6/2012 5:02 AM, Henry S. Thompson wrote:
internet-drafts writes:


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

	Title           : Additional Media Type Structured Syntax Suffixes
	Author(s)       : Tony Hansen
                          Alexey Melnikov
	Filename        : draft-ietf-appsawg-media-type-suffix-regs-08.txt

Given that 

  draft-lilley-xml-mediatypes-00

has now been published, is the patch to RFC3023 in section 4 of this
document really necessary?

ht

Yes;  drafts have no official status. Also, draft-ietf-appsawg-media-type-suffix-regs-08.txt is already in the RFC-EDITOR queue. When draft-lilley-xml-mediatypes gets published as an RFC, it will then be considered an update to both RFC3023 and the RFC that draft-ietf-appsawg-media-type-suffix-regs becomes. Also, draft-lilley-xml-mediatypes will need to incorporate the registration form for +xml.

    Tony Hansen
--------------080506060503000605090805-- From James.H.Manger@team.telstra.com Tue Nov 6 20:54: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 6E71B21F8B3A for ; Tue, 6 Nov 2012 20:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 cMqOHMlRWrlS for ; Tue, 6 Nov 2012 20:54:40 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9246B21F8B34 for ; Tue, 6 Nov 2012 20:54:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,726,1344175200"; d="scan'208,217";a="102126162" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 07 Nov 2012 15:54:30 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6888"; a="96246067" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcbvi.tcif.telstra.com.au with ESMTP; 07 Nov 2012 15:54:30 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Wed, 7 Nov 2012 15:54:22 +1100 From: "Manger, James H" To: James M Snell , IETF Apps Discuss Date: Wed, 7 Nov 2012 15:54:20 +1100 Thread-Topic: [apps-discuss] Updated Merge Patch Thread-Index: Ac2tVR+4n2TXmXx7Qi+0gzHigeD0RgAKWihwA8TRQqA= Message-ID: <255B9BB34FB7D647A506DC292726F6E115001D4D55@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114FDE43DC2@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FDE43DC2@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115001D4D55WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Updated Merge Patch 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, 07 Nov 2012 04:54:41 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115001D4D55WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFtZXMsDQoNCmRyYWZ0LXNuZWxsLW1lcmdlLXBhdGNoLTA2IGRvZXNu4oCZdCBxdWl0ZSBmaXgg dGhlIGdsaXRjaGVzIEkgbWVudGlvbmVkIGxhc3QgbW9udGguDQpIYXZpbmcgdGhlIGphdmFzY3Jp cHQgaW4gZHJhZnQtc25lbGwtbWVyZ2UtcGF0Y2gtMDcgaXMgZ3JlYXQgaW4gc2hvd2luZyB0aGVz ZSBjYXNlcy4NCg0KT3JpZ2luYWwgKyBtZXJnZSA9DQogICByZXN1bHQgYnkgMDcgamF2YXNjcmlw dA0KICAgcmVzdWx0IGJ5IDA3IHRleHQNCiAgIHJlc3VsdCBpcyB3aGF0IGl0IHNob3VsZCBiZSAo YWNjb3JkaW5nIHRvIG1lKQ0KDQpbMSwyXSArIHsiYSI6MywgImIiOm51bGx9ID0NCiAgIFsxLDJd IGJ5IDA3IGphdmFzY3JpcHQ7DQogICB7ImEiOjN9IGJ5IDA3IHRleHQsIGFzIGl0IHNob3VsZCBi ZQ0KDQpbMSwyXSArIFs3LCBudWxsXSA9DQogICBbN10gYnkgMDcgamF2YXNjcmlwdCBhbmQgdGV4 dDsNCiAgIFs3LCBudWxsXSBpcyB3aGF0IGl0IHNob3VsZCBiZQ0KVGhlcmUgaXMgbm8gcG9zc2li aWxpdHkgb2YgdGhlIG51bGwgaW4gdGhpcyBwYXRjaCAoaW4gYW4gYXJyYXkpIGhhdmluZyBhbnkg YWZmZWN0IG9uIHRoZSBvcmlnaW5hbCBzbyB3aHkgYm90aGVyIHNlYXJjaGluZyB0aGUgcGF0Y2gg dG8gcmVtb3ZlIGl0PyBCZXR0ZXIgdG8gdHJlYXQgYXJyYXlzIGFzIOKAnHByaW1pdGl2ZeKAnS4N Cg0KWzEsMl0gKyBudWxsID0NCiAgIFsxLDJdIGJ5IDA3IGphdmFzY3JpcHQNCiAgIFVuZGVmaW5l ZCBieSAwNyB0ZXh0DQogICA8ZW1wdHk+IGlzIHdoYXQgaXQgc2hvdWxkIGJlDQoNClRoZSAyIHJ1 bGVzIGluIGRyYWZ0LTA3IHN0YXJ0Og0KDQoxLiAgICAgICBJZiBlaXRoZXIgdGhlIG9yaWdpbmFs IG9yIHBhdGNoIGFyZSBhcnJheXMuLi4NCg0KMi4gICAgICAgSWYgdGhlIHBhdGNoIGlzIGFuIG9i amVjdC4uLg0KVGhpcyBmYWlscyB0byBjb3ZlciBjYXNlcyB3aGVyZSB0aGUgb3JpZ2luYWwgb3Ig cGF0Y2ggYXJlIHByaW1pdGl2ZSAoc3RyaW5nLCBib29sZWFuLCBudW1iZXIsIG9yIG51bGwpLiBJ ZiByb290cyBjYW5ub3QgYmUgcHJpbWl0aXZlIHRoZW4gcnVsZSAyIGRvZXNu4oCZdCBuZWVkIGl0 cyDigJxpZuKAnSBzdGF0ZW1lbnQuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KRnJvbTogYXBwcy1k aXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIE1hbmdlciwgSmFtZXMgSA0KU2VudDogRnJpZGF5LCAxOSBPY3Rv YmVyIDIwMTIgMTE6MTQgQU0NClRvOiBKYW1lcyBNIFNuZWxsOyBJRVRGIEFwcHMgRGlzY3Vzcw0K U3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFVwZGF0ZWQgTWVyZ2UgUGF0Y2gNCg0KSmFtZXMs DQoNCmRyYWZ0LXNuZWxsLW1lcmdlLXBhdGNoLTA1IGxvb2tzIGJldHRlciwgYnV0IGlzIG5vdCBx dWl0ZSByaWdodC4NCg0KwqcyIHN0ZXAgMQ0KIElmIGVpdGhlciB0aGUgcm9vdCBvZiB0aGUgSlNP TiBkYXRhIHByb3ZpZGVkIGluIHRoZSBwYXlsb2FkIG9yDQogdGhlIHJvb3Qgb2YgdGhlIHRhcmdl dCByZXNvdXJjZSBhcmUgSlNPTiBBcnJheXMsIHRoZSB0YXJnZXQNCiByZXNvdXJjZSBpcyB0byBi ZSByZXBsYWNlZCwgaW4gd2hvbGUsIGJ5IHRoZSBwcm92aWRlZCBkYXRhLg0KSW1wbGllcyAodGFy Z2V0ICsgbWVyZ2UgPSByZXN1bHQpOg0KWzEsMl0gKyB7ImEiOjMsICJiIjpudWxsfSA9IHsiYSI6 MywgImIiOm51bGx9DQpCdXQgdGhlIHJlc3VsdCBzaG91bGQgaW5zdGVhZCBiZSB7ImEiOjN9Lg0K DQpUaGUgc2FtZSBtaXN0YWtlIGlzIG1hZGUgaW4gc3RlcCAyLCA0dGggZG90IHBvaW50Lg0KDQpT dGVwIDEgY291bGQgYmUgcmV3cml0dGVuIGFzOg0KICDigJxJZiB0aGUgcm9vdCBvZiB0aGUgcGF0 Y2ggaXMgYSBzdHJpbmcsIG51bWJlciwgYm9vbGVhbiwgb3IgYXJyYXksIHRoZSB0YXJnZXQgaXMg cmVwbGFjZWQgd2l0aCB0aGUgcGF0Y2ggdmFsdWUu4oCdDQoNClRoaXMgcnVsZSBpcyBub3QgYWN0 dWFsbHkgc3BlY2lmaWMgdG8gdGhlIHJvb3Qgc28gaXQgcHJvYmFibHkgZG9lc27igJl0IG5lZWQg dG8gYmUgYSBzcGVjaWFsIGNhc2UuDQoNCg0KTXkgc3RhYiBhdCB0aGUgcHJvY2Vzc2luZyBydWxl czoNCg0K4oCcVGhlIHByb2Nlc3Npbmcgc3RlcHMgd2FsayB0aHJvdWdoIHRoZSBvYmplY3QgZWxl bWVudHMgaW4gdGhlIG1lcmdlLXBhdGNoIGRvY3VtZW50IGFuZCB0aGUgY29ycmVzcG9uZGluZyBl bGVtZW50cyBpbiB0aGUgZG9jdW1lbnQgYmVpbmcgbW9kaWZpZWQuIExldCDigJhwYXRjaOKAmSBh bmQg4oCYdGFyZ2V04oCZIHJlcHJlc2VudCB0aGUgY3VycmVudCBwb3NpdGlvbiBpbiB0aGVzZSBk b2N1bWVudHMgcmVzcGVjdGl2ZWx5LiBJbml0aWFsbHkg4oCYcGF0Y2jigJkgaXMgdGhlIHJvb3Qg b2YgdGhlIG1lcmdlLXBhdGNoIGRvY3VtZW50LCBhbmQg4oCYdGFyZ2V04oCZIGlzIHRoZSByb290 IG9mIHRoZSBkb2N1bWVudCBiZWluZyBtb2RpZmllZC4gQXQgYW55IHBvaW50IOKAmHRhcmdldOKA mSBtYXkgbm90IGV4aXN0Lg0KDQoNCjEuICAgICAgIElmIHRoZSBwYXRjaCB2YWx1ZSBpcyBudWxs OiByZW1vdmUgdGFyZ2V0Lg0KSXQgaXMgbm90IGFuIGVycm9yIGlmIHRhcmdldCBkb2VzIG5vdCBl eGlzdCwgdGhlcmUgaXMgc2ltcGx5IG5vIG1vZGlmaWNhdGlvbiB0byBtYWtlLg0KUmVtb3Zpbmcg dGhlIHJvb3QgbGVhdmVzIGFuIGVtcHR5IGRvY3VtZW50IChpZSBhIHJlc291cmNlIHdpdGggYSBj b250ZW50LWxlbmd0aCBvZiAwKS4NCg0KMi4gICAgICAgT3RoZXJ3aXNlLCBpZiB0aGUgcGF0Y2gg dmFsdWUgaXMgYSBzdHJpbmcsIG51bWJlciwgYm9vbGVhbiwgb3IgYXJyYXk6IHNldCB0YXJnZXQg dG8gcGF0Y2guIFRoaXMgY3JlYXRlcyBhIG5ldyBvYmplY3QgZWxlbWVudCBpZiB0YXJnZXQgZGlk buKAmXQgZXhpc3QsIG9yIHJlcGxhY2VzIHRhcmdldOKAmXMgdmFsdWUgaWYgaXQgZGlkIGV4aXN0 Lg0KDQozLiAgICAgICBPdGhlcndpc2UsIHRoZSBwYXRjaCB2YWx1ZSBpcyBhbiBvYmplY3QuIFBl cmZvcm0gdGhlIG5leHQgdHdvIHN1Yi1zdGVwczoNCg0KYS4gICAgICAgSWYgdGFyZ2V0IGRvZXMg bm90IGV4aXN0IG9yIGlmIGl0cyB2YWx1ZSBpcyBub3QgYW4gb2JqZWN0OiBzZXQgdGFyZ2V0IHRv IGFuIGVsZW1lbnQgd2l0aCB0aGUgcGF0Y2ggbmFtZSwgYW5kIGFuIGVtcHR5IG9iamVjdCBhcyBp dHMgdmFsdWUgKGllIHt9KS4NCkZvciB0aGUgcm9vdCB0aGVyZSBpc27igJl0IHJlYWxseSBhbiBl bGVtZW50IG5hbWUsIGp1c3QgYSB2YWx1ZS4NCg0KYi4gICAgICBGb3IgZWFjaCBlbGVtZW50IG9m IHRoZSBwYXRjaCB2YWx1ZSBvYmplY3Q6IHJlcGVhdCB0aGUgcHJvY2Vzc2luZyBzdGVwcyB3aXRo IHBhdGNoIGJlaW5nIHRoYXQgZWxlbWVudCwgYW5kIHRhcmdldCBiZWluZyB0aGUgZWxlbWVudCBv ZiB0aGUgcHJldmlvdXMgdGFyZ2V0IHdpdGggdGhlIHNhbWUgbmFtZSAoaWYgc3VjaCBhbiBlbGVt ZW50IGV4aXN0cykuDQrigJ0NCg0KVGhpcyBpcyBoYXJkZXIgdG8gd3JpdGUgaW4gRW5nbGlzaCB0 aGFuIGNvZGUhDQoNCg0KSXQgd291bGQgYmUgd29ydGggaW5jbHVkaW5nIGV4YW1wbGVzIG9mIHRo ZSBsZXNzIG9idmlvdXMgY2FzZXMuDQoNClRhcmdldCAgICsgbWVyZ2UgPSByZXN1bHQNCg0KeyJh IjpbMSx7ImJiIjoyLCAiY2MiOjN9XX0gKyB7ImEiOlsxLHsiYmIiOjQsICJjYyI6bnVsbH1dfSA9 IHsiYSI6WzEseyJiYiI6NCwgImNjIjpudWxsfV19DQogIChzaG93aW5nIHRoYXQgeW91IGRvbuKA mXQgbWVyZ2Ugb2JqZWN0cyB3aXRoaW4gYW4gYXJyYXkpDQoNCnsiYSI6MX0gKyB7ImIiOnsiY2Mi OnsiZGRkIjpudWxsfX19ID0geyJhIjoxLCAiYiI6eyJjYyI6eyB9fX0NCiAgKHNob3dpbmcgdGhh dCBvYmplY3RzIG9uIGEgcGF0aCBnZXQgY3JlYXRlZCAoc3RlcCAzYSksIGV2ZW4gaWYgdGhlIG9u bHkgdGFza3MgYXQgdGhlIGVuZCBvZiB0aGUgcGF0aCB0dXJucyBvdXQgdG8gYmUgcmVtb3Zpbmcg ZWxlbWVudHMpDQoNClsxLDJdICsgeyJhIjozLCAiYiI6bnVsbH0gPSB7ImEiOjN9DQogIChzaG93 aW5nIHlvdSBzdGlsbCBoYXZlIHRvIHdhbGsgdGhyb3VnaCB0aGUgcGF0Y2gsIGV2ZW4gd2hlbiB0 aGUgY29ycmVzcG9uZGluZyBwYXJ0IG9mIHRoZSB0YXJnZXQgd2FzbuKAmXQgYWxzbyBhbiBvYmpl Y3QpDQoNCnsiYSI6MX0gKyBudWxsID0gPGVtcHR5Pg0KDQoNClNwbGl0dGluZyB0aGUgcHJvY2Vz c2luZyBzdGVwcyBhbmQgdGhlIHdvcmtlZCBleGFtcGxlIChzZWN0aW9uIDIpIGludG8gc2VwYXJh dGUgc2VjdGlvbnMgd291bGQgYmUgYW4gaW1wcm92ZW1lbnQuDQoNClRoZW4gY2FuIHdlIGhhdmUg dGhpcyBvcGVyYXRpb24gaW4ganNvbi1wYXRjaDogeyJvcCI6Im1lcmdlIiwgInBhdGgiOjxwb2lu dGVyPiwgInZhbHVlIjo8bWVyZ2UtcGF0Y2g+fT8NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQpGcm9t OiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5j ZXNAaWV0Zi5vcmc+IFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBKYW1lcyBNIFNuZWxsDQpTZW50OiBGcmlkYXksIDE5IE9jdG9iZXIgMjAxMiA0OjIy IEFNDQpUbzogSUVURiBBcHBzIERpc2N1c3MNClN1YmplY3Q6IFthcHBzLWRpc2N1c3NdIFVwZGF0 ZWQgTWVyZ2UgUGF0Y2gNCg0KQmFzZWQgb24gcmVjZWl2ZWQgZmVlZGJhY2ssIG1vc3RseSBlZGl0 b3JpYWwgbW9kaWZpY2F0aW9ucyBhbmQgYSBmZXcgdXBkYXRlcyB0byB0aGUgcnVsZXMgdG8gY292 ZXIgYSBjb3VwbGUgYWRkaXRpb25hbCBjYXNlcyAodGhhbmtzIHRvIEphbWVzIE1hbmdlciBmb3Ig cG9pbnRpbmcgb3V0IHRoZSBnYXBzIGFuZCBwcm92aWRpbmcgbmV3IGxhbmd1YWdlIGZvciB0aGUg aW50cm8pLg0KDQogIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtc25lbGwtbWVyZ2UtcGF0 Y2gtMDUudHh0DQoNCi0gSmFtZXMNCg== --_000_255B9BB34FB7D647A506DC292726F6E115001D4D55WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRh dGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDoz Ni4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoxNDg0MzQ4ODg2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTY3NDAwNDcwMiAyMDE5MTY0MzEgMjAxOTE2NDQxIDIwMTkxNjQ0 MyAyMDE5MTY0MzEgMjAxOTE2NDQxIDIwMTkxNjQ0MyAyMDE5MTY0MzEgMjAxOTE2NDQxIDIwMTkx NjQ0Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDENCgl7bXNvLWxpc3QtaWQ6MTUxNzAzODMxNDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NzUyNjQ4NTYyIDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAx OTE2NDQzIDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAxOTE2NDQzIDIwMTkxNjQzMSAyMDE5MTY0NDEg MjAxOTE2NDQzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZl bC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTps ZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJ e21zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1BVSBsaW5r PWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkphbWVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ZHJh ZnQtc25lbGwtbWVyZ2UtcGF0Y2gtMDYgZG9lc27igJl0IHF1aXRlIGZpeCB0aGUgZ2xpdGNoZXMg SSBtZW50aW9uZWQgbGFzdCBtb250aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGF2aW5nIHRoZSBqYXZhc2NyaXB0IGluIGRy YWZ0LXNuZWxsLW1lcmdlLXBhdGNoLTA3IGlzIGdyZWF0IGluIHNob3dpbmcgdGhlc2UgY2FzZXMu PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5PcmlnaW5hbCArIG1lcmdlID08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+wqDCoCByZXN1bHQg YnkgMDcgamF2YXNjcmlwdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoMKgIHJlc3VsdCBieSAwNyB0ZXh0PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqAg cmVzdWx0IGlzIHdoYXQgaXQgc2hvdWxkIGJlIChhY2NvcmRpbmcgdG8gbWUpPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5bMSwyXSArIHsmcXVvdDthJnF1b3Q7OjMsICZxdW90O2ImcXVvdDs6bnVsbH0gPTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz7CoCDCoFsxLDJdIGJ5IDA3IGphdmFzY3JpcHQ7PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqAgeyZxdW90O2EmcXVv dDs6M30gYnkgMDcgdGV4dCwgYXMgaXQgc2hvdWxkIGJlPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5bMSwy XSArIFs3LCBudWxsXSA9PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqAgWzddIGJ5IDA3IGphdmFzY3JpcHQgYW5kIHRleHQ7 PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPsKgwqAgWzcsIG51bGxdIGlzIHdoYXQgaXQgc2hvdWxkIGJlPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZXJlIGlz IG5vIHBvc3NpYmlsaXR5IG9mIHRoZSBudWxsIGluIHRoaXMgcGF0Y2ggKGluIGFuIGFycmF5KSBo YXZpbmcgYW55IGFmZmVjdCBvbiB0aGUgb3JpZ2luYWwgc28gd2h5IGJvdGhlciBzZWFyY2hpbmcg dGhlIHBhdGNoIHRvIHJlbW92ZSBpdD8gQmV0dGVyIHRvIHRyZWF0IGFycmF5cyBhcyDigJxwcmlt aXRpdmXigJ0uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5bMSwyXSArIG51bGwgPTxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoMKgIFsx LDJdIGJ5IDA3IGphdmFzY3JpcHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+wqDCoCBVbmRlZmluZWQgYnkgMDcgdGV4dDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz7CoMKgICZsdDtlbXB0eSZndDsgaXMgd2hhdCBpdCBzaG91bGQgYmU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPlRoZSAyIHJ1bGVzIGluIGRyYWZ0LTA3IHN0YXJ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwwIGxldmVsMSBsZm8zJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjEuPHNwYW4gc3R5bGU9J2ZvbnQ6 Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5JZiBlaXRoZXIgdGhlIG9yaWdpbmFsIG9yIHBhdGNoIGFyZSBhcnJheXMuLi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4yLjxzcGFu IHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+SWYgdGhlIHBhdGNoIGlzIGFuIG9iamVjdC4uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGlzIGZh aWxzIHRvIGNvdmVyIGNhc2VzIHdoZXJlIHRoZSBvcmlnaW5hbCBvciBwYXRjaCBhcmUgcHJpbWl0 aXZlIChzdHJpbmcsIGJvb2xlYW4sIG51bWJlciwgb3IgbnVsbCkuIElmIHJvb3RzIGNhbm5vdCBi ZSBwcmltaXRpdmUgdGhlbiBydWxlIDIgZG9lc27igJl0IG5lZWQgaXRzIOKAnGlm4oCdIHN0YXRl bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2VyPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQn PjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gYXBwcy1k aXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRm Lm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5NYW5nZXIsIEphbWVzIEg8YnI+PGI+U2VudDo8L2I+ IEZyaWRheSwgMTkgT2N0b2JlciAyMDEyIDExOjE0IEFNPGJyPjxiPlRvOjwvYj4gSmFtZXMgTSBT bmVsbDsgSUVURiBBcHBzIERpc2N1c3M8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbYXBwcy1kaXNj dXNzXSBVcGRhdGVkIE1lcmdlIFBhdGNoPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5KYW1lcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPmRyYWZ0 LXNuZWxsLW1lcmdlLXBhdGNoLTA1IGxvb2tzIGJldHRlciwgYnV0IGlzIG5vdCBxdWl0ZSByaWdo dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKnMiBzdGVwIDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz4mbmJzcDtJZiBlaXRo ZXIgdGhlIHJvb3Qgb2YgdGhlIEpTT04gZGF0YSBwcm92aWRlZCBpbiB0aGUgcGF5bG9hZCBvcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3BhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29s b3I6YmxhY2snPiZuYnNwO3RoZSByb290IG9mIHRoZSB0YXJnZXQgcmVzb3VyY2UgYXJlIEpTT04g QXJyYXlzLCB0aGUgdGFyZ2V0PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0ncGFnZS1icmVhay1iZWZvcmU6YWx3YXlzJz48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+Jm5ic3A7cmVzb3VyY2UgaXMgdG8gYmUgcmVw bGFjZWQsIGluIHdob2xlLCBieSB0aGUgcHJvdmlkZWQgZGF0YS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SW1wbGllcyAodGFy Z2V0ICsgbWVyZ2UgPSByZXN1bHQpOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5bMSwyXSArIHsmcXVvdDthJnF1b3Q7OjMsICZx dW90O2ImcXVvdDs6bnVsbH0gPSB7JnF1b3Q7YSZxdW90OzozLCAmcXVvdDtiJnF1b3Q7Om51bGx9 PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPkJ1dCB0aGUgcmVzdWx0IHNob3VsZCBpbnN0ZWFkIGJlIHsmcXVvdDthJnF1b3Q7OjN9 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIHNhbWUgbWlzdGFrZSBpcyBtYWRlIGluIHN0ZXAgMiwg NDxzdXA+dGg8L3N1cD4gZG90IHBvaW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+U3RlcCAxIGNvdWxk IGJlIHJld3JpdHRlbiBhczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7IOKAnElmIHRoZSByb290IG9mIHRoZSBwYXRj aCBpcyBhIHN0cmluZywgbnVtYmVyLCBib29sZWFuLCBvciBhcnJheSwgdGhlIHRhcmdldCBpcyBy ZXBsYWNlZCB3aXRoIHRoZSBwYXRjaCB2YWx1ZS7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoaXMg cnVsZSBpcyBub3QgYWN0dWFsbHkgc3BlY2lmaWMgdG8gdGhlIHJvb3Qgc28gaXQgcHJvYmFibHkg ZG9lc27igJl0IG5lZWQgdG8gYmUgYSBzcGVjaWFsIGNhc2UuPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+TXkgc3RhYiBhdCB0aGUgcHJvY2Vzc2luZyBydWxlczo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPuKAnFRoZSBwcm9jZXNzaW5nIHN0ZXBzIHdhbGsgdGhyb3VnaCB0aGUgb2JqZWN0IGVs ZW1lbnRzIGluIHRoZSBtZXJnZS1wYXRjaCBkb2N1bWVudCBhbmQgdGhlIGNvcnJlc3BvbmRpbmcg ZWxlbWVudHMgaW4gdGhlIGRvY3VtZW50IGJlaW5nIG1vZGlmaWVkLiBMZXQg4oCYcGF0Y2jigJkg YW5kIOKAmHRhcmdldOKAmSByZXByZXNlbnQgdGhlIGN1cnJlbnQgcG9zaXRpb24gaW4gdGhlc2Ug ZG9jdW1lbnRzIHJlc3BlY3RpdmVseS4gSW5pdGlhbGx5IOKAmHBhdGNo4oCZIGlzIHRoZSByb290 IG9mIHRoZSBtZXJnZS1wYXRjaCBkb2N1bWVudCwgYW5kIOKAmHRhcmdldOKAmSBpcyB0aGUgcm9v dCBvZiB0aGUgZG9jdW1lbnQgYmVpbmcgbW9kaWZpZWQuIEF0IGFueSBwb2ludCDigJh0YXJnZXTi gJkgbWF5IG5vdCBleGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+MS48c3BhbiBzdHlsZT0nZm9udDo3LjBw dCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklm IHRoZSBwYXRjaCB2YWx1ZSBpcyBudWxsOiByZW1vdmUgdGFyZ2V0Ljxicj5JdCBpcyBub3QgYW4g ZXJyb3IgaWYgdGFyZ2V0IGRvZXMgbm90IGV4aXN0LCB0aGVyZSBpcyBzaW1wbHkgbm8gbW9kaWZp Y2F0aW9uIHRvIG1ha2UuPGJyPlJlbW92aW5nIHRoZSByb290IGxlYXZlcyBhbiBlbXB0eSBkb2N1 bWVudCAoaWUgYSByZXNvdXJjZSB3aXRoIGEgY29udGVudC1sZW5ndGggb2YgMCkuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Mi48c3Bh biBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPk90aGVyd2lzZSwgaWYgdGhlIHBhdGNoIHZhbHVlIGlzIGEgc3RyaW5n LCBudW1iZXIsIGJvb2xlYW4sIG9yIGFycmF5OiBzZXQgdGFyZ2V0IHRvIHBhdGNoLiBUaGlzIGNy ZWF0ZXMgYSBuZXcgb2JqZWN0IGVsZW1lbnQgaWYgdGFyZ2V0IGRpZG7igJl0IGV4aXN0LCBvciBy ZXBsYWNlcyB0YXJnZXTigJlzIHZhbHVlIGlmIGl0IGRpZCBleGlzdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4zLjxzcGFuIHN0eWxl PSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+T3RoZXJ3aXNlLCB0aGUgcGF0Y2ggdmFsdWUgaXMgYW4gb2JqZWN0LiBQZXJmb3Jt IHRoZSBuZXh0IHR3byBzdWItc3RlcHM6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwxIGxldmVsMiBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPmEuPHNwYW4gc3R5 bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5JZiB0YXJnZXQgZG9lcyBub3QgZXhpc3Qgb3IgaWYgaXRzIHZhbHVlIGlzIG5v dCBhbiBvYmplY3Q6IHNldCB0YXJnZXQgdG8gYW4gZWxlbWVudCB3aXRoIHRoZSBwYXRjaCBuYW1l LCBhbmQgYW4gZW1wdHkgb2JqZWN0IGFzIGl0cyB2YWx1ZSAoaWUge30pLjxicj5Gb3IgdGhlIHJv b3QgdGhlcmUgaXNu4oCZdCByZWFsbHkgYW4gZWxlbWVudCBuYW1lLCBqdXN0IGEgdmFsdWUuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdp bi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMiBsZm8y Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxl PSdtc28tbGlzdDpJZ25vcmUnPmIuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBS b21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Gb3IgZWFjaCBlbGVtZW50IG9mIHRo ZSBwYXRjaCB2YWx1ZSBvYmplY3Q6IHJlcGVhdCB0aGUgcHJvY2Vzc2luZyBzdGVwcyB3aXRoIHBh dGNoIGJlaW5nIHRoYXQgZWxlbWVudCwgYW5kIHRhcmdldCBiZWluZyB0aGUgZWxlbWVudCBvZiB0 aGUgcHJldmlvdXMgdGFyZ2V0IHdpdGggdGhlIHNhbWUgbmFtZSAoaWYgc3VjaCBhbiBlbGVtZW50 IGV4aXN0cykuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhpcyBpcyBoYXJkZXIgdG8g d3JpdGUgaW4gRW5nbGlzaCB0aGFuIGNvZGUhPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+SXQgd291bGQgYmUgd29ydGggaW5jbHVkaW5nIGV4YW1wbGVzIG9mIHRoZSBsZXNzIG9idmlv dXMgY2FzZXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UYXJnZXQmbmJzcDsmbmJzcDsgKyBtZXJnZSA9 IHJlc3VsdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+eyZxdW90O2EmcXVvdDs6WzEseyZxdW90O2JiJnF1 b3Q7OjIsICZxdW90O2NjJnF1b3Q7OjN9XX0gKyB7JnF1b3Q7YSZxdW90OzpbMSx7JnF1b3Q7YmIm cXVvdDs6NCwgJnF1b3Q7Y2MmcXVvdDs6bnVsbH1dfSA9IHsmcXVvdDthJnF1b3Q7OlsxLHsmcXVv dDtiYiZxdW90Ozo0LCAmcXVvdDtjYyZxdW90OzpudWxsfV19PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyAoc2hvd2lu ZyB0aGF0IHlvdSBkb27igJl0IG1lcmdlIG9iamVjdHMgd2l0aGluIGFuIGFycmF5KTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+eyZxdW90O2EmcXVvdDs6MX0gKyB7JnF1b3Q7YiZxdW90Ozp7JnF1b3Q7Y2Mm cXVvdDs6eyZxdW90O2RkZCZxdW90OzpudWxsfX19ID0geyZxdW90O2EmcXVvdDs6MSwgJnF1b3Q7 YiZxdW90Ozp7JnF1b3Q7Y2MmcXVvdDs6eyB9fX08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7IChzaG93aW5nIHRoYXQg b2JqZWN0cyBvbiBhIHBhdGggZ2V0IGNyZWF0ZWQgKHN0ZXAgM2EpLCBldmVuIGlmIHRoZSBvbmx5 IHRhc2tzIGF0IHRoZSBlbmQgb2YgdGhlIHBhdGggdHVybnMgb3V0IHRvIGJlIHJlbW92aW5nIGVs ZW1lbnRzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+WzEsMl0gKyB7JnF1b3Q7YSZxdW90OzozLCAmcXVv dDtiJnF1b3Q7Om51bGx9ID0geyZxdW90O2EmcXVvdDs6M308bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7IChzaG93aW5n IHlvdSBzdGlsbCBoYXZlIHRvIHdhbGsgdGhyb3VnaCB0aGUgcGF0Y2gsIGV2ZW4gd2hlbiB0aGUg Y29ycmVzcG9uZGluZyBwYXJ0IG9mIHRoZSB0YXJnZXQgd2FzbuKAmXQgYWxzbyBhbiBvYmplY3Qp PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz57JnF1b3Q7YSZxdW90OzoxfSArIG51bGwgPSAmbHQ7ZW1wdHkm Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+U3BsaXR0aW5nIHRoZSBwcm9jZXNz aW5nIHN0ZXBzIGFuZCB0aGUgd29ya2VkIGV4YW1wbGUgKHNlY3Rpb24gMikgaW50byBzZXBhcmF0 ZSBzZWN0aW9ucyB3b3VsZCBiZSBhbiBpbXByb3ZlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRo ZW4gY2FuIHdlIGhhdmUgdGhpcyBvcGVyYXRpb24gaW4ganNvbi1wYXRjaDogeyZxdW90O29wJnF1 b3Q7OiZxdW90O21lcmdlJnF1b3Q7LCAmcXVvdDtwYXRoJnF1b3Q7OiZsdDtwb2ludGVyJmd0Oywg JnF1b3Q7dmFsdWUmcXVvdDs6Jmx0O21lcmdlLXBhdGNoJmd0O30/PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAg Y2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPiA8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0 Zi5vcmciPmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRv OmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkphbWVzIE0gU25lbGw8YnI+PGI+ U2VudDo8L2I+IEZyaWRheSwgMTkgT2N0b2JlciAyMDEyIDQ6MjIgQU08YnI+PGI+VG86PC9iPiBJ RVRGIEFwcHMgRGlzY3Vzczxicj48Yj5TdWJqZWN0OjwvYj4gW2FwcHMtZGlzY3Vzc10gVXBkYXRl ZCBNZXJnZSBQYXRjaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz5CYXNlZCBvbiByZWNlaXZlZCBmZWVkYmFj aywgbW9zdGx5IGVkaXRvcmlhbCBtb2RpZmljYXRpb25zIGFuZCBhIGZldyB1cGRhdGVzIHRvIHRo ZSBydWxlcyB0byBjb3ZlciBhIGNvdXBsZSBhZGRpdGlvbmFsIGNhc2VzICh0aGFua3MgdG8gSmFt ZXMgTWFuZ2VyIGZvciBwb2ludGluZyBvdXQgdGhlIGdhcHMgYW5kIHByb3ZpZGluZyBuZXcgbGFu Z3VhZ2UgZm9yIHRoZSBpbnRybykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgPGEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1zbmVsbC1tZXJnZS1wYXRjaC0wNS50eHQi Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtc25lbGwtbWVyZ2UtcGF0Y2gtMDUudHh0PC9h Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+LSBKYW1lczwvc3Bhbj48bzpwPjwvbzpwPjwv cD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E115001D4D55WSMSG3153Vsrv_-- From stpeter@stpeter.im Tue Nov 6 21:28: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 E8A9621F84E6 for ; Tue, 6 Nov 2012 21:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 Q6d7+3-ghJHu for ; Tue, 6 Nov 2012 21:28:27 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3B621F84DE for ; Tue, 6 Nov 2012 21:28:27 -0800 (PST) Received: from [10.0.0.74] (unknown [50.73.80.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 31EDD40062; Tue, 6 Nov 2012 22:32:08 -0700 (MST) Message-ID: <5099F175.3060703@stpeter.im> Date: Wed, 07 Nov 2012 00:28:21 -0500 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Graham Klyne References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im> <509991D0.9000007@ninebynine.org> In-Reply-To: <509991D0.9000007@ninebynine.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 07 Nov 2012 05:28:28 -0000 Graham, thanks for taking the time to explain your thinking at greater length. I now see your perspective and will ponder it a bit before replying further. Peter On 11/6/12 5:40 PM, Graham Klyne wrote: > Peter, > > I saw your revised text, but it doesn't reflect my take. At the time, > it didn't seem worth dragging out the discussion. > > You comment "other resolution protocols are allowed". Maybe there's > something I'm misunderstanding here, but my perception is that this > applies no more to acct: URIs than it does to any other URI scheme. > That is, there's nothing to stop one using *any* URI in some resolution > protocol (e.g. a database lookup, DDDS, a hash table, etc.) and there > are specific situations in which this may be the right thing for an > application to do. This is the light in which I see acct: URIs being > used with other protocols. But stripped of context, all you're left > with the the "native" dereferencing mechanism for the URI scheme, if > there is one. > > For schemes like http:, ftp:, etc., it is generally pretty clear what is > the the standard mechanism for dereferencing. > > For other schemes like, say, mailto: one may have to squint a little to > see the standard operation (like firing uo an email client) as > dereferencing, but > > And for schemes like urn: and info:, there is, by design, no common > dereferencing mechanism. > > Against this background, my perception has been that acct: is not *only* > about identification. It has a specific association with WebFinger, > even if it is also expected to be used with other protocols. I'm not > seeing that is any different from sending an HTML document containing a > mailto: URI via HTTP, there the mailto: URI is ultimately used to > identify a person, not send a mail message. So I expect the acct: > scheme to be associated with WebFinger in the same way that http: scheme > is associated with HTTP protocol. When I reviewed acct:, I expected > that part of the reason for having it as a separate URI scheme was that > it could be used free of protocol context (e.g. in a web page) and still > be dereferencable by some common mechanism. > > If I'm missing something, or if other people see this differently then > that's fine. I don't want to harp on about this. But the recent > discussion about acct: URIs and port numbers was, for me, a nice example > of how associating acct: specifically and concretely with WebFinger and > making it behave like other commonly used URIs can simplify life for > some people without, as far as I can tell, taking away any of the uses > that others may have in mind. > > #g > -- > > On 06/11/2012 20:53, Peter Saint-Andre wrote: >> On 11/6/12 11:53 AM, Graham Klyne wrote: >>> I've argued elsewhere that I think the normal resolution protocol for >>> acct: should be WebFinger. >> >> Graham, in the latest version of draft-ietf-appsawg-acct-uri I have: >> >> Because an 'acct' URI enables identification only and not >> interaction, it cannot be deferenced directly. Any protocol that >> might use the 'acct' URI scheme, such as the WebFinger protocol >> [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol >> [I-D.jones-simple-web-discovery], is responsible for specifying how >> an 'acct' URI is dereferenced in the context of that protocol. For >> example, an 'acct' URI might be passed as a parameter in an HTTP >> request and the service might retrieve the relevant information >> associated with the account identified by that URI and then provide >> that information to the requesting entity in an HTTP response. >> >> As far as I understand the discussion so far, other resolution protocols >> are allowed, which is why I wrote the text as it is right now. Feedback >> is welcome. >> >> Peter >> From duerst@it.aoyama.ac.jp Tue Nov 6 22:30: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 2A79321F8AFB for ; Tue, 6 Nov 2012 22:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.74 X-Spam-Level: X-Spam-Status: No, score=-99.74 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, 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 AAGpsTnEXCyG for ; Tue, 6 Nov 2012 22:30:44 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id CC7DB21F8B01 for ; Tue, 6 Nov 2012 22:30:42 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id qA76UaEt025481 for ; Wed, 7 Nov 2012 15:30:36 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 20f8_95f2_a3c6d58c_28a4_11e2_a98b_001d096c566a; Wed, 07 Nov 2012 15:30:36 +0900 Received: from [IPv6:::1] ([133.2.210.1]:54369) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 7 Nov 2012 15:30:37 +0900 Message-ID: <509A0006.90203@it.aoyama.ac.jp> Date: Wed, 07 Nov 2012 15:30:30 +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: "Joe Hildebrand (jhildebr)" References: 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] open issues with acct-uri spec 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, 07 Nov 2012 06:30:45 -0000 On 2012/11/06 22:09, Joe Hildebrand (jhildebr) wrote: > If there's a port, you have to specify a protocol, in which case acct: > doesn't make sense to me. Yes indeed. It would be the first time I'd heard of an account with a port. Just in case it matters, mailto: also doesn't have ports, because mail addresses don't have ports. Regards, Martin. > On 11/6/12 7:49 AM, "John Bradley" wrote: > >> Is including a port number valid? >> >> From my read it would not be. >> >> For debugging/testing we want to be able to run the resolver on an >> alternate port. >> >> Entering acct:ve7jtb@ve7jtb.com:4444 >> >> I think that was the proposal that Mike was making yesterday in the apps >> area meeting. >> >> >> John B. >> >> On 2012-11-05, at 4:29 PM, Peter Saint-Andre wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 11/1/12 11:10 AM, t.petch wrote: >>>> ----- Original Message ----- From: "Peter Saint-Andre" >>>> To: Cc: "'Graham >>>> Klyne'" Sent: Monday, October 29, 2012 2:47 PM >>>>> >>>>> I see two open issues with draft-ietf-appsawg-acct-uri (which I >>>>> think we can resolve on the mailing list, thus saving precious >>>>> meeting time for topics that require realtime discussion): >>>>> >>>>> 1. In version -01, I think that I was too aggressive about trying >>>>> to simplify the ABNF, to wit: >>>>> >>>>> acctURI = "acct" ":" userinfo "@" host >>>>> >>>>> The userinfo rule allows the colon character ':', but I don't >>>>> think that's what we want here. Instead, I think we want: >>>>> >>>>> acctURI = "acct" ":" userpart "@" host userpart = 1*( >>>>> unreserved / pct-encoded / sub-delims ) >>>>> >>>>> If you disagree with that definition, please reply to this >>>>> message. >>>> >>>> This definition bears a passing resemblance to that of an e-mail >>>> address, which makes me wonder whether or not the syntax should be >>>> aligned with that of e-mail with a reference thereto. I understand >>>> the change you have just made, but cannot see a rationale for it. >>>> It is not that I disagree with the definition but that I disagree >>>> with the reason for it, not knowing what that is. >>> >>> The change is intended to remove ':' from the allowable characters in >>> the localpart, since the point of ':' as a delimiter (as I understand >>> it) was to allow localparts of the "username:password". >>> >>> I do think it would be helpful to show how various protocol >>> identifiers (for email, SIP, XMPP, etc.) can be translated to 'acct' >>> URIs, similar to what we did in section 4 of >>> draft-saintandre-sip-xmpp-core: >>> >>> http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-02#section-4 >>> >>> I'm not sure if that belongs in the acct-uri spec, but it might be >>> helpful to document somewhere (e.g., on a wiki page). >>> >>> Peter >>> >>> - -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>> >>> iEYEARECAAYFAlCYL7IACgkQNL8k5A2w/vx60gCgw/jxQTIThFHRW7wqLXxfIziK >>> OMUAn1XMFoRGn4eB5iT3nd31MsaU91Mx >>> =5QSV >>> -----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 >> > > > From James.H.Manger@team.telstra.com Tue Nov 6 22:36: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 AA97F21F8B1C for ; Tue, 6 Nov 2012 22:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.482 X-Spam-Level: X-Spam-Status: No, score=0.482 tagged_above=-999 required=5 tests=[AWL=-0.917, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MANGLED_FORM=2.3, RELAY_IS_203=0.994] 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 THq8krXFUgem for ; Tue, 6 Nov 2012 22:36:00 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8E07B21F8B19 for ; Tue, 6 Nov 2012 22:35:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,727,1344175200"; d="scan'208";a="101880714" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 07 Nov 2012 17:35:57 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6888"; a="141537098" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcavi.tcif.telstra.com.au with ESMTP; 07 Nov 2012 17:35:57 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Wed, 7 Nov 2012 17:35:56 +1100 From: "Manger, James H" To: James M Snell , IETF Apps Discuss Date: Wed, 7 Nov 2012 17:35:55 +1100 Thread-Topic: [apps-discuss] Updated Merge Patch Thread-Index: Ac2tVR+4n2TXmXx7Qi+0gzHigeD0RgAKWihwA8TRQqAAB4B5YA== Message-ID: <255B9BB34FB7D647A506DC292726F6E115001D4FDE@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114FDE43DC2@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115001D4D55@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115001D4D55@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] Updated Merge Patch 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, 07 Nov 2012 06:36:00 -0000 SmFtZXMsDQoNCkhlcmUgaXMgc29tZSBhbHRlcm5hdGl2ZSBqYXZhc2NyaXB0IGZvciBBcHBlbmRp eCBBICJFeGFtcGxlIEphdmFTY3JpcHQgSW1wbGVtZW50YXRpb24iIG9mIGRyYWZ0LXNuZWxsLW1l cmdlLXBhdGNoLTA3OyBhbmQgdGhlcmUgaXMgYSB3ZWIgcGFnZSBhdCBodHRwOi8vaWQuY3RvLnRl bHN0cmEuY29tL2pzb24vbWVyZ2UuaHRtbCB0aGF0IHRlc3RzIHRoaXMgY29kZSBhbmQgdGhlIGRy YWZ0LTA3IGNvZGUuDQoNCg0KZnVuY3Rpb24gYmV0dGVyX2FwcGx5KG9yaWcsIHBhdGNoKSB7DQoJ dmFyIHJlc3VsdDsNCglpZiAocGF0Y2ggPT0gbnVsbCkgew0KCQkvLyBsZWF2ZSByZXN1bHQgdW5k ZWZpbmVkDQoJfQ0KCWVsc2UgaWYgKHR5cGVvZiBwYXRjaCA9PSAnc3RyaW5nJyB8fA0KCQl0eXBl b2YgcGF0Y2ggPT0gJ251bWJlcicgfHwNCgkJdHlwZW9mIHBhdGNoID09ICdib29sZWFuJyB8fA0K CQlwYXRjaCBpbnN0YW5jZW9mIEFycmF5KQ0KCXsNCgkJcmVzdWx0ID0gcGF0Y2g7DQoJfQ0KCWVs c2UgeyAvLyBwYXRjaCBpcyBhbiBvYmplY3QNCgkJcmVzdWx0ID0ge307DQoJCWlmIChvcmlnIGlu c3RhbmNlb2YgT2JqZWN0ICYmICEob3JpZyBpbnN0YW5jZW9mIEFycmF5KSkgew0KCQkJZm9yICht IGluIG9yaWcpDQoJCQkJcmVzdWx0W21dID0gb3JpZ1ttXTsNCgkJfQ0KCQlmb3IgKG0gaW4gcGF0 Y2gpIHsNCgkJCXJlc3VsdFttXSA9IGJldHRlcl9hcHBseShyZXN1bHRbbV0sIHBhdGNoW21dKTsN CgkJfQ0KCX0NCglyZXR1cm4gcmVzdWx0Ow0KfQ0KDQpQLlMuIEZyb20gYW4gcHJvZ3JhbW1lciBu b3QgdGhhdCBleHBlcmllbmNlZCB3aXRoIGphdmFzY3JpcHQgLS0gYmV3YXJlLg0KDQotLQ0KSmFt ZXMgTWFuZ2VyDQoNCg== From duerst@it.aoyama.ac.jp Wed Nov 7 02:22: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 2301421F8BAD for ; Wed, 7 Nov 2012 02:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.972 X-Spam-Level: X-Spam-Status: No, score=-101.972 tagged_above=-999 required=5 tests=[AWL=1.818, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 siiH2hjItrZI for ; Wed, 7 Nov 2012 02:22:33 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id C149E21F8B39 for ; Wed, 7 Nov 2012 02:22:32 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id qA7AMLIA001461 for ; Wed, 7 Nov 2012 19:22:21 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 7c7e_2431_041ba5be_28c5_11e2_8af5_001d096c5782; Wed, 07 Nov 2012 19:22:20 +0900 Received: from [IPv6:::1] ([133.2.210.1]:39265) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 7 Nov 2012 19:22:23 +0900 Message-ID: <509A3657.40100@it.aoyama.ac.jp> Date: Wed, 07 Nov 2012 19:22:15 +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: Graham Klyne References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im> <509991D0.9000007@ninebynine.org> In-Reply-To: <509991D0.9000007@ninebynine.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 07 Nov 2012 10:22:34 -0000 Hello Graham, On 2012/11/07 7:40, Graham Klyne wrote: > Peter, > > I saw your revised text, but it doesn't reflect my take. At the time, it > didn't seem worth dragging out the discussion. It would be good to know if you are making these comments as the reviewer, or just individually (or both, or whatever). > You comment "other resolution protocols are allowed". Maybe there's > something I'm misunderstanding here, but my perception is that this > applies no more to acct: URIs than it does to any other URI scheme. In theory, yes. In practical terms, it applies quite a bit more to the acct: protocol than to something like http: or ftp:. > That > is, there's nothing to stop one using *any* URI in some resolution > protocol (e.g. a database lookup, DDDS, a hash table, etc.) and there > are specific situations in which this may be the right thing for an > application to do. There's also the case where you can proxy most protocols over http. > This is the light in which I see acct: URIs being > used with other protocols. But stripped of context, all you're left with > the the "native" dereferencing mechanism for the URI scheme, if there is > one. > > For schemes like http:, ftp:, etc., it is generally pretty clear what is > the the standard mechanism for dereferencing. > > For other schemes like, say, mailto: one may have to squint a little to > see the standard operation (like firing uo an email client) as > dereferencing, but > > And for schemes like urn: and info:, there is, by design, no common > dereferencing mechanism. > > Against this background, my perception has been that acct: is not *only* > about identification. It has a specific association with WebFinger, even > if it is also expected to be used with other protocols. I'm not seeing > that is any different from sending an HTML document containing a mailto: > URI via HTTP, there the mailto: URI is ultimately used to identify a > person, not send a mail message. You mean because that's because the message ultimately reaches that person (assuming it gets sent) or in some other way? > So I expect the acct: scheme to be > associated with WebFinger in the same way that http: scheme is > associated with HTTP protocol. When I reviewed acct:, I expected that > part of the reason for having it as a separate URI scheme was that it > could be used free of protocol context (e.g. in a web page) and still be > dereferencable by some common mechanism. Yes. But it looks like currently, that common mechanism is "WebFinger or SimpleWebDiscovery". Sooner or later, there may be only one. > If I'm missing something, or if other people see this differently then > that's fine. I don't want to harp on about this. But the recent > discussion about acct: URIs and port numbers was, for me, a nice example > of how associating acct: specifically and concretely with WebFinger and > making it behave like other commonly used URIs can simplify life for > some people without, as far as I can tell, taking away any of the uses > that others may have in mind. As I said in a separate mail, mailto: never had a port. Syntax-wise, a port on a non-hierarchical scheme (i.e. not starting with //) is of curse not impossible, but I think it would be difficult to come up with an example scheme that did. Also, in terms of concept (acct: stands for account), it's difficult to conceptually associate accounts with ports. I think that using common syntax and thinking in common usage patterns (resource retrieval over a single preferred protocol) is very helpful as a framework, but the great advantage of URIs is that they aren't limited to to fixed usage patterns. Regards, Martin. > #g > -- > > On 06/11/2012 20:53, Peter Saint-Andre wrote: >> On 11/6/12 11:53 AM, Graham Klyne wrote: >>> I've argued elsewhere that I think the normal resolution protocol for >>> acct: should be WebFinger. >> >> Graham, in the latest version of draft-ietf-appsawg-acct-uri I have: >> >> Because an 'acct' URI enables identification only and not >> interaction, it cannot be deferenced directly. Any protocol that >> might use the 'acct' URI scheme, such as the WebFinger protocol >> [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol >> [I-D.jones-simple-web-discovery], is responsible for specifying how >> an 'acct' URI is dereferenced in the context of that protocol. For >> example, an 'acct' URI might be passed as a parameter in an HTTP >> request and the service might retrieve the relevant information >> associated with the account identified by that URI and then provide >> that information to the requesting entity in an HTTP response. >> >> As far as I understand the discussion so far, other resolution protocols >> are allowed, which is why I wrote the text as it is right now. Feedback >> is welcome. >> >> Peter >> > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From julian.reschke@gmx.de Wed Nov 7 04:48: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 42F4D21F887F for ; Wed, 7 Nov 2012 04:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.999 X-Spam-Level: X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=-2.400, 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 LVeQ2VgR6gqT for ; Wed, 7 Nov 2012 04:48:32 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 506AB21F888C for ; Wed, 7 Nov 2012 04:48:32 -0800 (PST) Received: (qmail invoked by alias); 07 Nov 2012 12:45:24 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp039) with SMTP; 07 Nov 2012 13:45:24 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18DR3ltE7wD57HrOiFLjTxjmwRS6duYmLqSlSUJcz tbbeuct0bF64s0 Message-ID: <509A57D9.1030901@gmx.de> Date: Wed, 07 Nov 2012 13:45:13 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Chris Lilley References: <1969645725.20121101120100@w3.org> In-Reply-To: <1969645725.20121101120100@w3.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org, eb2m-mrt@asahi-net.or.jp Subject: Re: [apps-discuss] FW: New Version Notification for draft-lilley-xml-mediatypes-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, 07 Nov 2012 12:48:33 -0000 On 2012-11-01 12:01, Chris Lilley wrote: > Hello apps-discuss, > > draft-lilley-xml-mediatypes-00.txt is a restart of a proposed replacement for RFC3023. The previous attempt foundered because the approach taken required deprecation of text/xml, and the implementor community was not happy with that as there is much legacy content using that type that still has to be supported. Useful links: Draft: Diff from RFC 3023: > The present draft takes advantage of recent changes in HTTP-bis which removes the default charset, and so treats text/xml the same as application/xml. This approach is also what most implementations already do, in practice. The present draft also introduces some clarifications on fragment identifiers for xml, and updates some references. Nit: you need to work on that HTTPbis reference :-). > It has been suggested that this document would be a good fit for the apps area WG, and the editors would like to request review and adoption by the WG (or an alternative suggestion of where/how to handle this document). > > This would be a standards-track document. +1 on doing this over here. I believe it would be good to start from RFC 3023, to raise issues, and then to resolve them one by one (re-playing the changes that the ID contains). Best regards, Julian From romeda@gmail.com Wed Nov 7 07:28: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 8334621F86C1 for ; Wed, 7 Nov 2012 07:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100, WEIRD_PORT=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 g-M9ONb3vACl for ; Wed, 7 Nov 2012 07:28:32 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABA2021F8444 for ; Wed, 7 Nov 2012 07:28:15 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1292440pad.31 for ; Wed, 07 Nov 2012 07:28:15 -0800 (PST) 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=5OFclq3wgQLskQLCoih46mEX3pkrWPJYhK/cLUmNuS8=; b=xZNan0X/+brR9w0rHLfz4H9WG6D22dw4IvYW+7OuXP31We4hzs/B48aCjLPXCK7s4Z lzyJT5n6UmdiEtPwPPpx6qeT2LlsuC/wVbg7yefu8OQWVu84Yx0RiunIe2GpFglK996r Q6VgFLsrJ1P1MCfFo0uNKcGZoecgjr4pN/JYBw7UloobE5t1apm1IUQYYQdlhfNIZB4O bTdBXhuQs0v4oOUiSAO+4vUuNYVN6tXUNxVsBXDan4ziAG7lBtut9C750+ZMm6NzjutU aD7ePjze/56z0Fh0oKiGcaAHa7UpdKICfvA5HmV5n5vNpZiefXVGJ59YrsTaT9CXjowD Nizw== Received: by 10.66.76.9 with SMTP id g9mr13459722paw.17.1352302095418; Wed, 07 Nov 2012 07:28:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.67.2.101 with HTTP; Wed, 7 Nov 2012 07:27:55 -0800 (PST) In-Reply-To: <509A3657.40100@it.aoyama.ac.jp> References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im> <509991D0.9000007@ninebynine.org> <509A3657.40100@it.aoyama.ac.jp> From: Blaine Cook Date: Wed, 7 Nov 2012 15:27:55 +0000 Message-ID: To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=f46d042f9df406c59204cde95efa Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 07 Nov 2012 15:28:33 -0000 --f46d042f9df406c59204cde95efa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -1000 to the idea of putting ports on acct "URIs". I'm biased, because I think the acct scheme / conceiving of these things as URIs is problematic in the first place. Beyond the mailto: counter-example I'll again raise DNS as an example where you can't specify, e.g., "example.com:5353" to have the DNS lookup happen on a different port than the default 53. The default is the only option. What would that look like in practice, were it possible? http://example.com:5353:8080/ ??? Please, can we agree that this should be as simple as possible if it's going to exist at all? What are the *problems* we're trying to solve? This feels like answering "how can we apply URI semantics to email addresses", which is not a good goal in and of itself. b. On 7 November 2012 10:22, "Martin J. D=C3=BCrst" w= rote: > Hello Graham, > > > On 2012/11/07 7:40, Graham Klyne wrote: > >> Peter, >> >> I saw your revised text, but it doesn't reflect my take. At the time, it >> didn't seem worth dragging out the discussion. >> > > It would be good to know if you are making these comments as the reviewer= , > or just individually (or both, or whatever). > > > You comment "other resolution protocols are allowed". Maybe there's >> something I'm misunderstanding here, but my perception is that this >> applies no more to acct: URIs than it does to any other URI scheme. >> > > In theory, yes. In practical terms, it applies quite a bit more to the > acct: protocol than to something like http: or ftp:. > > > That >> is, there's nothing to stop one using *any* URI in some resolution >> protocol (e.g. a database lookup, DDDS, a hash table, etc.) and there >> are specific situations in which this may be the right thing for an >> application to do. >> > > There's also the case where you can proxy most protocols over http. > > > > This is the light in which I see acct: URIs being >> used with other protocols. But stripped of context, all you're left with >> the the "native" dereferencing mechanism for the URI scheme, if there is >> one. >> >> For schemes like http:, ftp:, etc., it is generally pretty clear what is >> the the standard mechanism for dereferencing. >> >> For other schemes like, say, mailto: one may have to squint a little to >> see the standard operation (like firing uo an email client) as >> dereferencing, but >> >> And for schemes like urn: and info:, there is, by design, no common >> dereferencing mechanism. >> >> Against this background, my perception has been that acct: is not *only* >> about identification. It has a specific association with WebFinger, even >> if it is also expected to be used with other protocols. I'm not seeing >> that is any different from sending an HTML document containing a mailto: >> URI via HTTP, there the mailto: URI is ultimately used to identify a >> person, not send a mail message. >> > > You mean because that's because the message ultimately reaches that perso= n > (assuming it gets sent) or in some other way? > > > > So I expect the acct: scheme to be >> associated with WebFinger in the same way that http: scheme is >> associated with HTTP protocol. When I reviewed acct:, I expected that >> part of the reason for having it as a separate URI scheme was that it >> could be used free of protocol context (e.g. in a web page) and still be >> dereferencable by some common mechanism. >> > > Yes. But it looks like currently, that common mechanism is "WebFinger or > SimpleWebDiscovery". Sooner or later, there may be only one. > > > > If I'm missing something, or if other people see this differently then >> that's fine. I don't want to harp on about this. But the recent >> discussion about acct: URIs and port numbers was, for me, a nice example >> of how associating acct: specifically and concretely with WebFinger and >> making it behave like other commonly used URIs can simplify life for >> some people without, as far as I can tell, taking away any of the uses >> that others may have in mind. >> > > As I said in a separate mail, mailto: never had a port. Syntax-wise, a > port on a non-hierarchical scheme (i.e. not starting with //) is of curse > not impossible, but I think it would be difficult to come up with an > example scheme that did. Also, in terms of concept (acct: stands for > account), it's difficult to conceptually associate accounts with ports. > > I think that using common syntax and thinking in common usage patterns > (resource retrieval over a single preferred protocol) is very helpful as = a > framework, but the great advantage of URIs is that they aren't limited to > to fixed usage patterns. > > Regards, Martin. > > > #g >> -- >> >> On 06/11/2012 20:53, Peter Saint-Andre wrote: >> >>> On 11/6/12 11:53 AM, Graham Klyne wrote: >>> >>>> I've argued elsewhere that I think the normal resolution protocol for >>>> acct: should be WebFinger. >>>> >>> >>> Graham, in the latest version of draft-ietf-appsawg-acct-uri I have: >>> >>> Because an 'acct' URI enables identification only and not >>> interaction, it cannot be deferenced directly. Any protocol that >>> might use the 'acct' URI scheme, such as the WebFinger protocol >>> [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol >>> [I-D.jones-simple-web-**discovery], is responsible for specifying how >>> an 'acct' URI is dereferenced in the context of that protocol. For >>> example, an 'acct' URI might be passed as a parameter in an HTTP >>> request and the service might retrieve the relevant information >>> associated with the account identified by that URI and then provide >>> that information to the requesting entity in an HTTP response. >>> >>> As far as I understand the discussion so far, other resolution protocol= s >>> are allowed, which is why I wrote the text as it is right now. Feedback >>> is welcome. >>> >>> Peter >>> >>> ______________________________**_________________ >> 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 > --f46d042f9df406c59204cde95efa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -1000 to the idea of putting ports on acct "URIs". I'm biased= , because I think the acct scheme / conceiving of these things as URIs is p= roblematic in the first place.

Beyond the mailto: counte= r-example I'll again raise DNS as an example where you can't specif= y, e.g., "example.com:5353&quo= t; to have the DNS lookup happen on a different port than the default 53. T= he default is the only option.

What would that look like in practice, were it possible= ? http://example.com:5353:8080/ ???

Please, can we= agree that this should be as simple as possible if it's going to exist= at all? What are the *problems* we're trying to solve? This feels like= answering "how can we apply URI semantics to email addresses", w= hich is not a good goal in and of itself.

b.


On 7 November 2012 10:22, "Martin J. D=C3=BCrst"= <duerst@it.aoyama.ac.jp> wrote:
Hello Graham,


On 2012/11/07 7:40, Graham Klyne wrote:
Peter,

I saw your revised text, but it doesn't reflect my take. At the time, i= t
didn't seem worth dragging out the discussion.

It would be good to know if you are making these comments as the reviewer, = or just individually (or both, or whatever).


You comment "other resolution protocols are allowed". Maybe there= 's
something I'm misunderstanding here, but my perception is that this
applies no more to acct: URIs than it does to any other URI scheme.

In theory, yes. In practical terms, it applies quite a bit more to the acct= : protocol than to something like http: or ftp:.


That
is, there's nothing to stop one using *any* URI in some resolution
protocol (e.g. a database lookup, DDDS, a hash table, etc.) and there
are specific situations in which this may be the right thing for an
application to do.

There's also the case where you can proxy most protocols over http.


This is the light in which I see acct: URIs being
used with other protocols. But stripped of context, all you're left wit= h
the the "native" dereferencing mechanism for the URI scheme, if t= here is
one.

For schemes like http:, ftp:, etc., it is generally pretty clear what is the the standard mechanism for dereferencing.

For other schemes like, say, mailto: one may have to squint a little to
see the standard operation (like firing uo an email client) as
dereferencing, but

And for schemes like urn: and info:, there is, by design, no common
dereferencing mechanism.

Against this background, my perception has been that acct: is not *only* about identification. It has a specific association with WebFinger, even if it is also expected to be used with other protocols. I'm not seeing<= br> that is any different from sending an HTML document containing a mailto: URI via HTTP, there the mailto: URI is ultimately used to identify a
person, not send a mail message.

You mean because that's because the message ultimately reaches that per= son (assuming it gets sent) or in some other way?



So I expect the acct: scheme to be
associated with WebFinger in the same way that http: scheme is
associated with HTTP protocol. When I reviewed acct:, I expected that
part of the reason for having it as a separate URI scheme was that it
could be used free of protocol context (e.g. in a web page) and still be dereferencable by some common mechanism.

Yes. But it looks like currently, that common mechanism is "WebFinger = or SimpleWebDiscovery". Sooner or later, there may be only one.



If I'm missing something, or if other people see this differently then<= br> that's fine. I don't want to harp on about this. But the recent
discussion about acct: URIs and port numbers was, for me, a nice example of how associating acct: specifically and concretely with WebFinger and
making it behave like other commonly used URIs can simplify life for
some people without, as far as I can tell, taking away any of the uses
that others may have in mind.

As I said in a separate mail, mailto: never had a port. Syntax-wise, a port= on a non-hierarchical scheme (i.e. not starting with //) is of curse not i= mpossible, but I think it would be difficult to come up with an example sch= eme that did. Also, in terms of concept (acct: stands for account), it'= s difficult to conceptually associate accounts with ports.

I think that using common syntax and thinking in common usage patterns (res= ource retrieval over a single preferred protocol) is very helpful as a fram= ework, but the great advantage of URIs is that they aren't limited to t= o fixed usage patterns.

Regards, =C2=A0 Martin.


#g
--

On 06/11/2012 20:53, Peter Saint-Andre wrote:
On 11/6/12 11:53 AM, Graham Klyne wrote:
I've argued elsewhere that I think the normal resolution protocol for acct: should be WebFinger.

Graham, in the latest version of draft-ietf-appsawg-acct-uri I have:

Because an 'acct' URI enables identification only and not
interaction, it cannot be deferenced directly. Any protocol that
might use the 'acct' URI scheme, such as the WebFinger protocol
[I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol
[I-D.jones-simple-web-discovery], is responsible for specifying how<= br> an 'acct' URI is dereferenced in the context of that protocol. For<= br> example, an 'acct' URI might be passed as a parameter in an HTTP request and the service might retrieve the relevant information
associated with the account identified by that URI and then provide
that information to the requesting entity in an HTTP response.

As far as I understand the discussion so far, other resolution protocols are allowed, which is why I wrote the text as it is right now. Feedback
is welcome.

Peter

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

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

--f46d042f9df406c59204cde95efa-- From melvincarvalho@gmail.com Wed Nov 7 07:52: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 E43A921F8B8E for ; Wed, 7 Nov 2012 07:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[AWL=-0.734, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, WEIRD_PORT=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 YZS05jdxJ-G6 for ; Wed, 7 Nov 2012 07:52:21 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9100621F8C39 for ; Wed, 7 Nov 2012 07:52:21 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so2907247iec.31 for ; Wed, 07 Nov 2012 07:52:21 -0800 (PST) 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=GNdzAhBQcDUarMx33XdWZf7aLm8d0OCldxbHkXb9iS0=; b=o5RnklKfRh3oFo9BEiNZHbYV3Y2psD3ONP1pnoCZjY3+RWkNd+2V4MUfShddY/UiKG rRMO1czr1eIbNfGqxh3lqK0IL7+tuCJa8w56JIAIVZUPtByZjnJl2Q0wLk6mv9QFHxMU Ar7tFMoLj/HIz6zB4SNrTKr4jhXaXgAdeRuRYVGMWTllXz84JvSB2SBVethlY81k4Lex BEVQKKC578j8Sil0fzMyS+BSLXapuNR5Wh93L4GugOF/WLszk/5FUCcvIgR1nOYnkTz8 BFepUr1xaIt7DAC+0C2idKu2BtUyMAEQBkSvHIMoJlgj2NBcAQUfmTh6Pfpw0Ayh0hmQ V/Rw== MIME-Version: 1.0 Received: by 10.50.236.104 with SMTP id ut8mr5039274igc.20.1352303541108; Wed, 07 Nov 2012 07:52:21 -0800 (PST) Received: by 10.42.137.136 with HTTP; Wed, 7 Nov 2012 07:52:21 -0800 (PST) In-Reply-To: References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im> <509991D0.9000007@ninebynine.org> <509A3657.40100@it.aoyama.ac.jp> Date: Wed, 7 Nov 2012 16:52:21 +0100 Message-ID: From: Melvin Carvalho To: Blaine Cook Content-Type: multipart/alternative; boundary=14dae93403433241bd04cde9b436 Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 07 Nov 2012 15:52:23 -0000 --14dae93403433241bd04cde9b436 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7 November 2012 16:27, Blaine Cook wrote: > -1000 to the idea of putting ports on acct "URIs". I'm biased, because I > think the acct scheme / conceiving of these things as URIs is problematic > in the first place. > > Beyond the mailto: counter-example I'll again raise DNS as an example > where you can't specify, e.g., "example.com:5353" to have the DNS lookup > happen on a different port than the default 53. The default is the only > option. > > What would that look like in practice, were it possible? > http://example.com:5353:8080/ ??? > > Please, can we agree that this should be as simple as possible if it's > going to exist at all? What are the *problems* we're trying to solve? Thi= s > feels like answering "how can we apply URI semantics to email addresses", > which is not a good goal in and of itself. > I totally agree with you about keeping things simple. The advantage of using a URI is to have a global permanent identifier in a permanent way. You are absolutely right that www.example.com, "to all intents and purposes", might as well be the same as the http://. Similarly user@hostwe can reasonably assume is the mailto:version. But consider many years from now we may have http2 or spdy or any number of protocols that use domain names. Now our choices are less clear. Similarly *if* acct: gains widespread adoption, we've conflated what was a relatively simple choice ie is uesr@host a mailto: or an acct: ? So the reason to use a URI is for unambiguity and longevity ... ie a permanent global variable. But as of today, we can use some very valuable heuristics, as you suggest, to simplify things. But in future those heuristics may become less valid, especially if, in that future, we need to choose between acct: and mailto: Personally I'm not wild about acct: at all, but I can live with it. > > b. > > > On 7 November 2012 10:22, "Martin J. D=FCrst" wro= te: > >> Hello Graham, >> >> >> On 2012/11/07 7:40, Graham Klyne wrote: >> >>> Peter, >>> >>> I saw your revised text, but it doesn't reflect my take. At the time, i= t >>> didn't seem worth dragging out the discussion. >>> >> >> It would be good to know if you are making these comments as the >> reviewer, or just individually (or both, or whatever). >> >> >> You comment "other resolution protocols are allowed". Maybe there's >>> something I'm misunderstanding here, but my perception is that this >>> applies no more to acct: URIs than it does to any other URI scheme. >>> >> >> In theory, yes. In practical terms, it applies quite a bit more to the >> acct: protocol than to something like http: or ftp:. >> >> >> That >>> is, there's nothing to stop one using *any* URI in some resolution >>> protocol (e.g. a database lookup, DDDS, a hash table, etc.) and there >>> are specific situations in which this may be the right thing for an >>> application to do. >>> >> >> There's also the case where you can proxy most protocols over http. >> >> >> >> This is the light in which I see acct: URIs being >>> used with other protocols. But stripped of context, all you're left wit= h >>> the the "native" dereferencing mechanism for the URI scheme, if there i= s >>> one. >>> >>> For schemes like http:, ftp:, etc., it is generally pretty clear what i= s >>> the the standard mechanism for dereferencing. >>> >>> For other schemes like, say, mailto: one may have to squint a little to >>> see the standard operation (like firing uo an email client) as >>> dereferencing, but >>> >>> And for schemes like urn: and info:, there is, by design, no common >>> dereferencing mechanism. >>> >>> Against this background, my perception has been that acct: is not *only= * >>> about identification. It has a specific association with WebFinger, eve= n >>> if it is also expected to be used with other protocols. I'm not seeing >>> that is any different from sending an HTML document containing a mailto= : >>> URI via HTTP, there the mailto: URI is ultimately used to identify a >>> person, not send a mail message. >>> >> >> You mean because that's because the message ultimately reaches that >> person (assuming it gets sent) or in some other way? >> >> >> >> So I expect the acct: scheme to be >>> associated with WebFinger in the same way that http: scheme is >>> associated with HTTP protocol. When I reviewed acct:, I expected that >>> part of the reason for having it as a separate URI scheme was that it >>> could be used free of protocol context (e.g. in a web page) and still b= e >>> dereferencable by some common mechanism. >>> >> >> Yes. But it looks like currently, that common mechanism is "WebFinger or >> SimpleWebDiscovery". Sooner or later, there may be only one. >> >> >> >> If I'm missing something, or if other people see this differently then >>> that's fine. I don't want to harp on about this. But the recent >>> discussion about acct: URIs and port numbers was, for me, a nice exampl= e >>> of how associating acct: specifically and concretely with WebFinger and >>> making it behave like other commonly used URIs can simplify life for >>> some people without, as far as I can tell, taking away any of the uses >>> that others may have in mind. >>> >> >> As I said in a separate mail, mailto: never had a port. Syntax-wise, a >> port on a non-hierarchical scheme (i.e. not starting with //) is of curs= e >> not impossible, but I think it would be difficult to come up with an >> example scheme that did. Also, in terms of concept (acct: stands for >> account), it's difficult to conceptually associate accounts with ports. >> >> I think that using common syntax and thinking in common usage patterns >> (resource retrieval over a single preferred protocol) is very helpful as= a >> framework, but the great advantage of URIs is that they aren't limited t= o >> to fixed usage patterns. >> >> Regards, Martin. >> >> >> #g >>> -- >>> >>> On 06/11/2012 20:53, Peter Saint-Andre wrote: >>> >>>> On 11/6/12 11:53 AM, Graham Klyne wrote: >>>> >>>>> I've argued elsewhere that I think the normal resolution protocol for >>>>> acct: should be WebFinger. >>>>> >>>> >>>> Graham, in the latest version of draft-ietf-appsawg-acct-uri I have: >>>> >>>> Because an 'acct' URI enables identification only and not >>>> interaction, it cannot be deferenced directly. Any protocol that >>>> might use the 'acct' URI scheme, such as the WebFinger protocol >>>> [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol >>>> [I-D.jones-simple-web-**discovery], is responsible for specifying how >>>> an 'acct' URI is dereferenced in the context of that protocol. For >>>> example, an 'acct' URI might be passed as a parameter in an HTTP >>>> request and the service might retrieve the relevant information >>>> associated with the account identified by that URI and then provide >>>> that information to the requesting entity in an HTTP response. >>>> >>>> As far as I understand the discussion so far, other resolution protoco= ls >>>> are allowed, which is why I wrote the text as it is right now. Feedbac= k >>>> is welcome. >>>> >>>> Peter >>>> >>>> ______________________________**_________________ >>> 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 > > --14dae93403433241bd04cde9b436 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 7 November 2012 16:27, Blaine Cook <r= omeda@gmail.com> wrote:
-1000 to the idea of putting ports on acct "URIs". I'm biased= , because I think the acct scheme / conceiving of these things as URIs is p= roblematic in the first place.

Beyond the mailto: counte= r-example I'll again raise DNS as an example where you can't specif= y, e.g., "exampl= e.com:5353" to have the DNS lookup happen on a different port than= the default 53. The default is the only option.

What would that look like in practice, were it possible= ? http://example.com:5353:8080/ ???

Please, can we= agree that this should be as simple as possible if it's going to exist= at all? What are the *problems* we're trying to solve? This feels like= answering "how can we apply URI semantics to email addresses", w= hich is not a good goal in and of itself.

I totally agree with you about keeping things simple.=

The advantage of using a URI is to have a global permanent identifi= er in a permanent way.

You are absolutely right that www.example.com, "to all intents and purposes&= quot;, might as well be the same as the http://.=A0 Similarly user@host we = can reasonably assume is the mailto: version.

But consider many years from now we may have http2 or spdy or any numbe= r of protocols that use domain names.=A0 Now our choices are less clear.
Similarly *if* acct: gains widespread adoption, we've conflated wh= at was a relatively simple choice ie is uesr@host a mailto: or an acct: ?
So the reason to use a URI is for unambiguity and longevity ... ie a pe= rmanent global variable.=A0 But as of today, we can use some very valuable = heuristics, as you suggest, to simplify things.=A0 But in future those heur= istics may become less valid, especially if, in that future, we need to cho= ose between acct: and mailto:

Personally I'm not wild about acct: at all, but I can live with it.=
=A0

b.


On 7 = November 2012 10:22, "Martin J. D=FCrst" <duerst@it.aoyama.= ac.jp> wrote:
Hello Graham,


On 2012/11/07 7:40, Graham Klyne wrote:
Peter,

I saw your revised text, but it doesn't reflect my take. At the time, i= t
didn't seem worth dragging out the discussion.

It would be good to know if you are making these comments as the reviewer, = or just individually (or both, or whatever).


You comment "other resolution protocols are allowed". Maybe there= 's
something I'm misunderstanding here, but my perception is that this
applies no more to acct: URIs than it does to any other URI scheme.

In theory, yes. In practical terms, it applies quite a bit more to the acct= : protocol than to something like http: or ftp:.


That
is, there's nothing to stop one using *any* URI in some resolution
protocol (e.g. a database lookup, DDDS, a hash table, etc.) and there
are specific situations in which this may be the right thing for an
application to do.

There's also the case where you can proxy most protocols over http.


This is the light in which I see acct: URIs being
used with other protocols. But stripped of context, all you're left wit= h
the the "native" dereferencing mechanism for the URI scheme, if t= here is
one.

For schemes like http:, ftp:, etc., it is generally pretty clear what is the the standard mechanism for dereferencing.

For other schemes like, say, mailto: one may have to squint a little to
see the standard operation (like firing uo an email client) as
dereferencing, but

And for schemes like urn: and info:, there is, by design, no common
dereferencing mechanism.

Against this background, my perception has been that acct: is not *only* about identification. It has a specific association with WebFinger, even if it is also expected to be used with other protocols. I'm not seeing<= br> that is any different from sending an HTML document containing a mailto: URI via HTTP, there the mailto: URI is ultimately used to identify a
person, not send a mail message.

You mean because that's because the message ultimately reaches that per= son (assuming it gets sent) or in some other way?



So I expect the acct: scheme to be
associated with WebFinger in the same way that http: scheme is
associated with HTTP protocol. When I reviewed acct:, I expected that
part of the reason for having it as a separate URI scheme was that it
could be used free of protocol context (e.g. in a web page) and still be dereferencable by some common mechanism.

Yes. But it looks like currently, that common mechanism is "WebFinger = or SimpleWebDiscovery". Sooner or later, there may be only one.


If I'm missing something, or if other people see this differently then<= br> that's fine. I don't want to harp on about this. But the recent
discussion about acct: URIs and port numbers was, for me, a nice example of how associating acct: specifically and concretely with WebFinger and
making it behave like other commonly used URIs can simplify life for
some people without, as far as I can tell, taking away any of the uses
that others may have in mind.

As I said in a separate mail, mailto: never had a port. Syntax-wise, a port= on a non-hierarchical scheme (i.e. not starting with //) is of curse not i= mpossible, but I think it would be difficult to come up with an example sch= eme that did. Also, in terms of concept (acct: stands for account), it'= s difficult to conceptually associate accounts with ports.

I think that using common syntax and thinking in common usage patterns (res= ource retrieval over a single preferred protocol) is very helpful as a fram= ework, but the great advantage of URIs is that they aren't limited to t= o fixed usage patterns.

Regards, =A0 Martin.


#g
--

On 06/11/2012 20:53, Peter Saint-Andre wrote:
On 11/6/12 11:53 AM, Graham Klyne wrote:
I've argued elsewhere that I think the normal resolution protocol for acct: should be WebFinger.

Graham, in the latest version of draft-ietf-appsawg-acct-uri I have:

Because an 'acct' URI enables identification only and not
interaction, it cannot be deferenced directly. Any protocol that
might use the 'acct' URI scheme, such as the WebFinger protocol
[I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol
[I-D.jones-simple-web-discovery], is responsible for specifying how<= br> an 'acct' URI is dereferenced in the context of that protocol. For<= br> example, an 'acct' URI might be passed as a parameter in an HTTP request and the service might retrieve the relevant information
associated with the account identified by that URI and then provide
that information to the requesting entity in an HTTP response.

As far as I understand the discussion so far, other resolution protocols are allowed, which is why I wrote the text as it is right now. Feedback
is welcome.

Peter

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

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


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


--14dae93403433241bd04cde9b436-- From stpeter@stpeter.im Wed Nov 7 07:55: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 03C8B21F8BAD for ; Wed, 7 Nov 2012 07:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 0b90LeM3Aihx for ; Wed, 7 Nov 2012 07:55:40 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6297A21F8B8E for ; Wed, 7 Nov 2012 07:55:40 -0800 (PST) Received: from [130.129.84.156] (unknown [130.129.84.156]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6027B40062; Wed, 7 Nov 2012 08:59:27 -0700 (MST) Message-ID: <509A847F.3020301@stpeter.im> Date: Wed, 07 Nov 2012 10:55:43 -0500 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Melvin Carvalho References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im> <509991D0.9000007@ninebynine.org> <509A3657.40100@it.aoyama.ac.jp> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 07 Nov 2012 15:55:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/7/12 10:52 AM, Melvin Carvalho wrote: > Similarly *if* acct: gains widespread adoption, we've conflated > what was a relatively simple choice ie is uesr@host a mailto: or an > acct: ? No. The user just types "user@host" or even (depending on the UI) "user". The user agent converts that to acct:user@host and all is good. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCahH8ACgkQNL8k5A2w/vyglACfXOlaRgKYrqydEk/qRbOtq8NR JuoAoLN8e1tHCrfwPH/QaKc91pGjSGYV =jUNg -----END PGP SIGNATURE----- From GK@ninebynine.org Wed Nov 7 14:59: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 8218921F89D2 for ; Wed, 7 Nov 2012 14:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.915 X-Spam-Level: X-Spam-Status: No, score=-5.915 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, MIME_8BIT_HEADER=0.3, 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 7DRc2LJuRsaq for ; Wed, 7 Nov 2012 14:59:50 -0800 (PST) Received: from relay8.mail.ox.ac.uk (relay8.mail.ox.ac.uk [129.67.1.171]) by ietfa.amsl.com (Postfix) with ESMTP id F31BE21F85B1 for ; Wed, 7 Nov 2012 14:59:49 -0800 (PST) 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 1TWEb4-0006MZ-Q8; Wed, 07 Nov 2012 22:59:46 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TWEb3-0003h3-9E; Wed, 07 Nov 2012 22:59:46 +0000 Message-ID: <509A6BA8.5070303@ninebynine.org> Date: Wed, 07 Nov 2012 14:09:44 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im> <509991D0.9000007@ninebynine.org> <509A3657.40100@it.aoyama.ac.jp> In-Reply-To: <509A3657.40100@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 07 Nov 2012 22:59:50 -0000 On 07/11/2012 10:22, "Martin J. Dürst" wrote: > It would be good to know if you are making these comments as the reviewer, or > just individually (or both, or whatever). OK. For the avoidance of doubt, all my recent comments here about the acct: URI scheme are in a purely personal capacity. #g From GK@ninebynine.org Wed Nov 7 14:59:55 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 95F6721F89B3 for ; Wed, 7 Nov 2012 14:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.572 X-Spam-Level: X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, MIME_8BIT_HEADER=0.3, 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 V7DlhF3A0dOW for ; Wed, 7 Nov 2012 14:59:51 -0800 (PST) Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEFB21F89D2 for ; Wed, 7 Nov 2012 14:59:51 -0800 (PST) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TWEb5-0004db-1q; Wed, 07 Nov 2012 22:59:47 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TWEb4-0003hI-99; Wed, 07 Nov 2012 22:59:47 +0000 Message-ID: <509A7699.9030003@ninebynine.org> Date: Wed, 07 Nov 2012 14:56:25 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im> <509991D0.9000007@ninebynine.org> <509A3657.40100@it.aoyama.ac.jp> In-Reply-To: <509A3657.40100@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 07 Nov 2012 22:59:55 -0000 Hi Martin, Continuing to respond in a personal capacity... On 07/11/2012 10:22, "Martin J. Dürst" wrote: >> You comment "other resolution protocols are allowed". Maybe there's >> something I'm misunderstanding here, but my perception is that this >> applies no more to acct: URIs than it does to any other URI scheme. > > In theory, yes. In practical terms, it applies quite a bit more to the acct: > protocol than to something like http: or ftp:. Maybe, but I'm not sure it's to an extent that makes a qualitative difference. YMMV. >> That >> is, there's nothing to stop one using *any* URI in some resolution >> protocol (e.g. a database lookup, DDDS, a hash table, etc.) and there >> are specific situations in which this may be the right thing for an >> application to do. > > There's also the case where you can proxy most protocols over http. Yes, that too. (But I think the HTTP proxy is somewhat bound to break out to the implicit scheme semantics at some point. This raises a question: what should an HTTP proxy do when it receives a request for an acct: URI?) >> This is the light in which I see acct: URIs being >> used with other protocols. But stripped of context, all you're left with >> the the "native" dereferencing mechanism for the URI scheme, if there is >> one. >> >> For schemes like http:, ftp:, etc., it is generally pretty clear what is >> the the standard mechanism for dereferencing. >> >> For other schemes like, say, mailto: one may have to squint a little to >> see the standard operation (like firing uo an email client) as >> dereferencing, but >> >> And for schemes like urn: and info:, there is, by design, no common >> dereferencing mechanism. >> >> Against this background, my perception has been that acct: is not *only* >> about identification. It has a specific association with WebFinger, even >> if it is also expected to be used with other protocols. I'm not seeing >> that is any different from sending an HTML document containing a mailto: >> URI via HTTP, there the mailto: URI is ultimately used to identify a >> person, not send a mail message. > > You mean because that's because the message ultimately reaches that person > (assuming it gets sent) or in some other way? I'm not sure I understand the question here. I'm talking about a URI being used in a way that is independent of the protocol with which it's associated. Like http://... XML namespace URIs being used independently of HTTP protocol interactions. >> So I expect the acct: scheme to be >> associated with WebFinger in the same way that http: scheme is >> associated with HTTP protocol. When I reviewed acct:, I expected that >> part of the reason for having it as a separate URI scheme was that it >> could be used free of protocol context (e.g. in a web page) and still be >> dereferencable by some common mechanism. > > Yes. But it looks like currently, that common mechanism is "WebFinger or > SimpleWebDiscovery". Sooner or later, there may be only one. That's a point I hadn't previously realized, which does somewhat erode my position. I think it would be unfortunate, but not necessarily fatal, if there isn't a single dereferencing mechanism that can be arrived at by a "follow your nose" process from the URI scheme registration. >> If I'm missing something, or if other people see this differently then >> that's fine. I don't want to harp on about this. But the recent >> discussion about acct: URIs and port numbers was, for me, a nice example >> of how associating acct: specifically and concretely with WebFinger and >> making it behave like other commonly used URIs can simplify life for >> some people without, as far as I can tell, taking away any of the uses >> that others may have in mind. > > As I said in a separate mail, mailto: never had a port. Syntax-wise, a port on a > non-hierarchical scheme (i.e. not starting with //) is of curse not impossible, > but I think it would be difficult to come up with an example scheme that did. > Also, in terms of concept (acct: stands for account), it's difficult to > conceptually associate accounts with ports. Fair point. I concede it's less compelling to use ports with a non-hierarchical (i.e. non-authority-based) scheme. (In this case, a port wouldn't be associating the *account* with a port, but the account information discovery mechanism. I suppose a germane question here is if "acct:foo@example.com" and "acct:foo@example.com:8888" should be expected to refer to the same account. Hence dereference to information about the same account - but not necessarily the same information. As URIs, they're clearly different.) What all this says to me is that my using the port number issue as an excuse to re-raise this point was misguided. So I guess my other comments should be considered independently of the port number debate. > I think that using common syntax and thinking in common usage patterns (resource > retrieval over a single preferred protocol) is very helpful as a framework, but > the great advantage of URIs is that they aren't limited to to fixed usage patterns. "Yes, but..." is what I want to say. Hmmm, "but" what? I think one thing that all URIs should share is that there's an association between the URI and some "resource" (qua RFC3986) - the URI identifies a resource. When there is a mechanical way of getting from the URI to the resource (or a representation thereof), it's preferable that the URI can provide an indication of what that mechanism is - I think this is what allows the principle of URI opacity in web applications. Maybe this doesn't amount to a "fixed usage pattern", but I think it's a common benefit of using URIs. And it doesn't preclude other usage patterns, but those other patterns are possible only with additional context information which means that a given URI can be interpreted differently, possibly contradictory, fashion in different [protocol] environments. That's not necessarily a problem in itself, but who's to say which is right in a broader web context? #g -- >> On 06/11/2012 20:53, Peter Saint-Andre wrote: >>> On 11/6/12 11:53 AM, Graham Klyne wrote: >>>> I've argued elsewhere that I think the normal resolution protocol for >>>> acct: should be WebFinger. >>> >>> Graham, in the latest version of draft-ietf-appsawg-acct-uri I have: >>> >>> Because an 'acct' URI enables identification only and not >>> interaction, it cannot be deferenced directly. Any protocol that >>> might use the 'acct' URI scheme, such as the WebFinger protocol >>> [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol >>> [I-D.jones-simple-web-discovery], is responsible for specifying how >>> an 'acct' URI is dereferenced in the context of that protocol. For >>> example, an 'acct' URI might be passed as a parameter in an HTTP >>> request and the service might retrieve the relevant information >>> associated with the account identified by that URI and then provide >>> that information to the requesting entity in an HTTP response. >>> >>> As far as I understand the discussion so far, other resolution protocols >>> are allowed, which is why I wrote the text as it is right now. Feedback >>> is welcome. >>> >>> Peter >>> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > From stpeter@stpeter.im Thu Nov 8 04: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 2D48F21F8B75 for ; Thu, 8 Nov 2012 04:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 5PUs6FswFI7b for ; Thu, 8 Nov 2012 04:17:49 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C7AB621F8B71 for ; Thu, 8 Nov 2012 04:17:49 -0800 (PST) Received: from [10.0.0.86] (unknown [50.73.80.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BAFE840062; Thu, 8 Nov 2012 05:21:38 -0700 (MST) Message-ID: <509BA2F2.6000006@stpeter.im> Date: Thu, 08 Nov 2012 07:17:54 -0500 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Graham Klyne References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im> <509991D0.9000007@ninebynine.org> <5099F175.3060703@stpeter.im> In-Reply-To: <5099F175.3060703@stpeter.im> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 08 Nov 2012 12:17:51 -0000 Hi Graham, Thanks again for sharing your thoughts on the matter. I happened to chat about this with a few folks here at the IETF meeting in Atlanta, and here is how I see it... We have this protocol called WebFinger: in order to retrieve pointers to further information about a person associated with a domain, a client sends a special HTTP request to a server at that domain and passes as a parameter in that request a URI that identifies the person. That URI could be a 'mailto:', 'sip:', 'xmpp:', 'callto:' (?), or other URI that includes an identifier for the person (i.e., for an account controlled by the person). When the client completes that operation, is it dereferencing the 'mailto:', 'sip:', 'xmpp:' (etc.) URI that is passed as a parameter? Or it dereferencing the HTTP URL to which it sends the request? Example: http://example.com/lrdd/?f=json&uri=xmpp%3Abob%40example.com This might only indicate my ignorance of URIs, but that example doesn't feel to me like a dereferencing of an 'xmpp:' URI, which I would expect to be something like this (see XEP-0054 at xmpp.org): xmpp:bob@example.com?vcard Instead, the URI that is passed as a parameter in the WebFinger operation feels to me like something that is used purely for identification, not interaction (dereferencing). If that line of reasoning is just wrong, please do let me know. :-) The WebFinger community, through much conversation over the years, decided that it was potentially confusing to use 'mailto:' URIs when passing a parameter in the WebFinger operation, primarily because there might not be an email service running at the domain or associated with that person, and perhaps secondarily because they didn't want to set up the expectation that the requesting entity was initiating any kind of email-based interaction. Therefore, they decided to define a neutral URI scheme that would be used purely for identification. As I understand it, there is no expection that an HTML href attribute containing an 'acct:' URI would trigger a WebFinger interaction: info Instead, the client would need to include the correct HTTP URL: info Therefore, I continue to think that 'acct:' URIs are used purely for identification and not at all for interaction. It's just a parameter that you pass in the query part of an HTTP URL, not a URI that you dereference directly. If those who know more about URIs or WebFinger than I do disagree with the foregoing characterization, I'd love to hear it. Thanks for listening. Peter On 11/7/12 12:28 AM, Peter Saint-Andre wrote: > Graham, thanks for taking the time to explain your thinking at greater > length. I now see your perspective and will ponder it a bit before > replying further. > > Peter > > On 11/6/12 5:40 PM, Graham Klyne wrote: >> Peter, >> >> I saw your revised text, but it doesn't reflect my take. At the time, >> it didn't seem worth dragging out the discussion. >> >> You comment "other resolution protocols are allowed". Maybe there's >> something I'm misunderstanding here, but my perception is that this >> applies no more to acct: URIs than it does to any other URI scheme. >> That is, there's nothing to stop one using *any* URI in some resolution >> protocol (e.g. a database lookup, DDDS, a hash table, etc.) and there >> are specific situations in which this may be the right thing for an >> application to do. This is the light in which I see acct: URIs being >> used with other protocols. But stripped of context, all you're left >> with the the "native" dereferencing mechanism for the URI scheme, if >> there is one. >> >> For schemes like http:, ftp:, etc., it is generally pretty clear what is >> the the standard mechanism for dereferencing. >> >> For other schemes like, say, mailto: one may have to squint a little to >> see the standard operation (like firing uo an email client) as >> dereferencing, but >> >> And for schemes like urn: and info:, there is, by design, no common >> dereferencing mechanism. >> >> Against this background, my perception has been that acct: is not *only* >> about identification. It has a specific association with WebFinger, >> even if it is also expected to be used with other protocols. I'm not >> seeing that is any different from sending an HTML document containing a >> mailto: URI via HTTP, there the mailto: URI is ultimately used to >> identify a person, not send a mail message. So I expect the acct: >> scheme to be associated with WebFinger in the same way that http: scheme >> is associated with HTTP protocol. When I reviewed acct:, I expected >> that part of the reason for having it as a separate URI scheme was that >> it could be used free of protocol context (e.g. in a web page) and still >> be dereferencable by some common mechanism. >> >> If I'm missing something, or if other people see this differently then >> that's fine. I don't want to harp on about this. But the recent >> discussion about acct: URIs and port numbers was, for me, a nice example >> of how associating acct: specifically and concretely with WebFinger and >> making it behave like other commonly used URIs can simplify life for >> some people without, as far as I can tell, taking away any of the uses >> that others may have in mind. >> >> #g >> -- >> >> On 06/11/2012 20:53, Peter Saint-Andre wrote: >>> On 11/6/12 11:53 AM, Graham Klyne wrote: >>>> I've argued elsewhere that I think the normal resolution protocol for >>>> acct: should be WebFinger. >>> >>> Graham, in the latest version of draft-ietf-appsawg-acct-uri I have: >>> >>> Because an 'acct' URI enables identification only and not >>> interaction, it cannot be deferenced directly. Any protocol that >>> might use the 'acct' URI scheme, such as the WebFinger protocol >>> [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol >>> [I-D.jones-simple-web-discovery], is responsible for specifying how >>> an 'acct' URI is dereferenced in the context of that protocol. For >>> example, an 'acct' URI might be passed as a parameter in an HTTP >>> request and the service might retrieve the relevant information >>> associated with the account identified by that URI and then provide >>> that information to the requesting entity in an HTTP response. >>> >>> As far as I understand the discussion so far, other resolution protocols >>> are allowed, which is why I wrote the text as it is right now. Feedback >>> is welcome. >>> >>> Peter >>> From melvincarvalho@gmail.com Thu Nov 8 04:42: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 D5A4821F8B3B for ; Thu, 8 Nov 2012 04:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MANGLED_HERE=2.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 ybBj2KsxwnKT for ; Thu, 8 Nov 2012 04:42:17 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1384821F8B0D for ; Thu, 8 Nov 2012 04:42:17 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so4568109iec.31 for ; Thu, 08 Nov 2012 04:42:16 -0800 (PST) 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=dIthlacvsXpuZhhFUcz9AYdv9wKSq+iUpD6yJeCo2uo=; b=vH6zPu9x/plP3kYIjoM0kqSaaU4gOtElLzBR9Ac5qgRuaW31wZ8mKQ2gyIB759VYpN W8S0tKyfs0gFtViOsp64bpJDmpQtBAFrnWT2SnBRROrpXmoRzb1lIt9j4VgIfXmnQcIv JpctUlaJg286IR9SKa+XCZeFtvOAupIXp+hvC7k3bXmvWp4n5Zb6Hh/x0hQBJfIPeQI9 N4Q/zExyUAx/A005DkjQc+MZQF/qkJ7rZp1xCOaAUySCz7gwQNTxDN2O5j4c6HABEOD7 83BeTCzF3Priibxd3P4p/RLmbuBfStnBbsvmTtVcNX8sWdCunGoRcAmzRmlGm1BkyNZV lEPQ== MIME-Version: 1.0 Received: by 10.50.91.168 with SMTP id cf8mr19696243igb.20.1352378536630; Thu, 08 Nov 2012 04:42:16 -0800 (PST) Received: by 10.42.137.136 with HTTP; Thu, 8 Nov 2012 04:42:15 -0800 (PST) In-Reply-To: <509BA2F2.6000006@stpeter.im> References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im> <509991D0.9000007@ninebynine.org> <5099F175.3060703@stpeter.im> <509BA2F2.6000006@stpeter.im> Date: Thu, 8 Nov 2012 13:42:15 +0100 Message-ID: From: Melvin Carvalho To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=e89a8f3b9d3d47194d04cdfb2a76 Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 08 Nov 2012 12:42:18 -0000 --e89a8f3b9d3d47194d04cdfb2a76 Content-Type: text/plain; charset=ISO-8859-1 On 8 November 2012 13:17, Peter Saint-Andre wrote: > Hi Graham, > > Thanks again for sharing your thoughts on the matter. I happened to chat > about this with a few folks here at the IETF meeting in Atlanta, and > here is how I see it... > > We have this protocol called WebFinger: in order to retrieve pointers to > further information about a person associated with a domain, a client > sends a special HTTP request to a server at that domain and passes as a > parameter in that request a URI that identifies the person. That URI > could be a 'mailto:', 'sip:', 'xmpp:', 'callto:' (?), or other URI that > includes an identifier for the person (i.e., for an account controlled > by the person). > > When the client completes that operation, is it dereferencing the > 'mailto:', 'sip:', 'xmpp:' (etc.) URI that is passed as a parameter? Or > it dereferencing the HTTP URL to which it sends the request? Example: > > http://example.com/lrdd/?f=json&uri=xmpp%3Abob%40example.com > Here you are dereferencing the HTTP URL via the HTTP protocol, specifically GET. The xmpp URI would be a parameter. > > This might only indicate my ignorance of URIs, but that example doesn't > feel to me like a dereferencing of an 'xmpp:' URI, which I would expect > to be something like this (see XEP-0054 at xmpp.org): > > xmpp:bob@example.com?vcard > > Instead, the URI that is passed as a parameter in the WebFinger > operation feels to me like something that is used purely for > identification, not interaction (dereferencing). > URIs are Identifiers aka names aka references Not all URIs can be dereferenced, in particular, URNs are just names without the dereferencing part. By implication http URIs can be dereferenced via http > > If that line of reasoning is just wrong, please do let me know. :-) > > The WebFinger community, through much conversation over the years, > decided that it was potentially confusing to use 'mailto:' URIs when > passing a parameter in the WebFinger operation, primarily because there > might not be an email service running at the domain or associated with > that person, and perhaps secondarily because they didn't want to set up > the expectation that the requesting entity was initiating any kind of > email-based interaction. Therefore, they decided to define a neutral URI > scheme that would be used purely for identification. > I have a slightly different take on this, and that is one of the motivations for acct: was that it was considered better practice to use a direct identifier, rather than, an indirect identifier. Webfinger seems to be a specific query where the input identifier should be the subject of the data returned. Indirect identifiers are explained in : "Architecture of the World Wide Web, Volume One" http://www.w3.org/TR/webarch/#indirect-identification "Suppose that nadia@example.com is Nadia's email address. The organizers of a conference Nadia attends might use "mailto:nadia@example.com" to refer indirectly to her (e.g., by using the URI as a database key in their database of conference participants). This does not introduce a URI collision." > > As I understand it, there is no expection that an HTML href attribute > containing an 'acct:' URI would trigger a WebFinger interaction: > > info > > Instead, the client would need to include the correct HTTP URL: > > href='http://example.com/lrdd/?f=json&uri=xmpp%3Abob%40example.com > '>info > > Therefore, I continue to think that 'acct:' URIs are used purely for > identification and not at all for interaction. It's just a parameter > that you pass in the query part of an HTTP URL, not a URI that you > dereference directly. > As a slight aside, we had a really interested session with Tim Berners-Lee last week at TPAC on identity and auth on the web. The topic of webfinger came up in passing, where he made an interesting comment. He said that if you want to get an HTTP URI from an email address, the most logical place to do so is via the SMTP protocol (something I had never considered before!). He also seemed to suggest that there was already a specification for this, but people decided to turn it off, for security reasons. > > If those who know more about URIs or WebFinger than I do disagree with > the foregoing characterization, I'd love to hear it. > > Thanks for listening. > Above is based on my (limited) understanding of awww, corrections welcome :) > > Peter > > On 11/7/12 12:28 AM, Peter Saint-Andre wrote: > > Graham, thanks for taking the time to explain your thinking at greater > > length. I now see your perspective and will ponder it a bit before > > replying further. > > > > Peter > > > > On 11/6/12 5:40 PM, Graham Klyne wrote: > >> Peter, > >> > >> I saw your revised text, but it doesn't reflect my take. At the time, > >> it didn't seem worth dragging out the discussion. > >> > >> You comment "other resolution protocols are allowed". Maybe there's > >> something I'm misunderstanding here, but my perception is that this > >> applies no more to acct: URIs than it does to any other URI scheme. > >> That is, there's nothing to stop one using *any* URI in some resolution > >> protocol (e.g. a database lookup, DDDS, a hash table, etc.) and there > >> are specific situations in which this may be the right thing for an > >> application to do. This is the light in which I see acct: URIs being > >> used with other protocols. But stripped of context, all you're left > >> with the the "native" dereferencing mechanism for the URI scheme, if > >> there is one. > >> > >> For schemes like http:, ftp:, etc., it is generally pretty clear what is > >> the the standard mechanism for dereferencing. > >> > >> For other schemes like, say, mailto: one may have to squint a little to > >> see the standard operation (like firing uo an email client) as > >> dereferencing, but > >> > >> And for schemes like urn: and info:, there is, by design, no common > >> dereferencing mechanism. > >> > >> Against this background, my perception has been that acct: is not *only* > >> about identification. It has a specific association with WebFinger, > >> even if it is also expected to be used with other protocols. I'm not > >> seeing that is any different from sending an HTML document containing a > >> mailto: URI via HTTP, there the mailto: URI is ultimately used to > >> identify a person, not send a mail message. So I expect the acct: > >> scheme to be associated with WebFinger in the same way that http: scheme > >> is associated with HTTP protocol. When I reviewed acct:, I expected > >> that part of the reason for having it as a separate URI scheme was that > >> it could be used free of protocol context (e.g. in a web page) and still > >> be dereferencable by some common mechanism. > >> > >> If I'm missing something, or if other people see this differently then > >> that's fine. I don't want to harp on about this. But the recent > >> discussion about acct: URIs and port numbers was, for me, a nice example > >> of how associating acct: specifically and concretely with WebFinger and > >> making it behave like other commonly used URIs can simplify life for > >> some people without, as far as I can tell, taking away any of the uses > >> that others may have in mind. > >> > >> #g > >> -- > >> > >> On 06/11/2012 20:53, Peter Saint-Andre wrote: > >>> On 11/6/12 11:53 AM, Graham Klyne wrote: > >>>> I've argued elsewhere that I think the normal resolution protocol for > >>>> acct: should be WebFinger. > >>> > >>> Graham, in the latest version of draft-ietf-appsawg-acct-uri I have: > >>> > >>> Because an 'acct' URI enables identification only and not > >>> interaction, it cannot be deferenced directly. Any protocol that > >>> might use the 'acct' URI scheme, such as the WebFinger protocol > >>> [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol > >>> [I-D.jones-simple-web-discovery], is responsible for specifying how > >>> an 'acct' URI is dereferenced in the context of that protocol. For > >>> example, an 'acct' URI might be passed as a parameter in an HTTP > >>> request and the service might retrieve the relevant information > >>> associated with the account identified by that URI and then provide > >>> that information to the requesting entity in an HTTP response. > >>> > >>> As far as I understand the discussion so far, other resolution > protocols > >>> are allowed, which is why I wrote the text as it is right now. Feedback > >>> is welcome. > >>> > >>> Peter > >>> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --e89a8f3b9d3d47194d04cdfb2a76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 8 November 2012 13:17, Peter Saint-An= dre <stpeter@stpeter.im> wrote:
Hi Graham,

Thanks again for sharing your thoughts on the matter. I happened to chat about this with a few folks here at the IETF meeting in Atlanta, and
here is how I see it...

We have this protocol called WebFinger: in order to retrieve pointers to further information about a person associated with a domain, a client
sends a special HTTP request to a server at that domain and passes as a
parameter in that request a URI that identifies the person. That URI
could be a 'mailto:', 'sip:', 'xmpp:', 'callto:= ' (?), or other URI that
includes an identifier for the person (i.e., for an account controlled
by the person).

When the client completes that operation, is it dereferencing the
'mailto:', 'sip:', 'xmpp:' (etc.) URI that is passe= d as a parameter? Or
it dereferencing the HTTP URL to which it sends the request? Example:

http://example.com/lrdd/?f=3Djson&uri=3Dxmpp%3A= bob%40example.com

Here you are dereferencing t= he HTTP URL via the HTTP protocol, specifically GET.=A0 The xmpp URI would = be a parameter.
=A0

This might only indicate my ignorance of URIs, but that example doesn't=
feel to me like a dereferencing of an 'xmpp:' URI, which I would ex= pect
to be something like this (see XEP-0054 at xmpp.org):

xmpp:bob@ex= ample.com?vcard

Instead, the URI that is passed as a parameter in the WebFinger
operation feels to me like something that is used purely for
identification, not interaction (dereferencing).

U= RIs are Identifiers aka names aka references

Not all URIs can be de= referenced, in particular, URNs are just names without the dereferencing pa= rt.

By implication http URIs can be dereferenced via http
=A0

If that line of reasoning is just wrong, please do let me know. :-)

The WebFinger community, through much conversation over the years,
decided that it was potentially confusing to use 'mailto:' URIs whe= n
passing a parameter in the WebFinger operation, primarily because there
might not be an email service running at the domain or associated with
that person, and perhaps secondarily because they didn't want to set up=
the expectation that the requesting entity was initiating any kind of
email-based interaction. Therefore, they decided to define a neutral URI scheme that would be used purely for identification.
<= br>I have a slightly different take on this, and that is one of the motivat= ions for acct: was that it was considered better practice to use a direct i= dentifier, rather than, an indirect identifier.=A0 Webfinger seems to be a = specific query where the input identifier should be the subject of the data= returned.

Indirect identifiers are explained in : "Architecture of the World= Wide Web, Volume One"

http://www.w3.org/TR/webarch/#indirect-identifica= tion

"Suppose that nadia@example.c= om is Nadia's email address. The organizers of a conference Nadia a= ttends might use "mailto:nadia@ex= ample.com" to refer indirectly to her (e.g., by using the URI as a= database key in their database of conference participants). This does not = introduce a URI collision."
=A0

As I understand it, there is no expection that an HTML href attribute
containing an 'acct:' URI would trigger a WebFinger interaction:
<a href=3D'acct:bob@example'>info</a>

Instead, the client would need to include the correct HTTP URL:

<a
href=3D'http://example.com/lrdd/?f=3Djson&u= ri=3Dxmpp%3Abob%40example.com'>info</a>

Therefore, I continue to think that 'acct:' URIs are used purely fo= r
identification and not at all for interaction. It's just a parameter that you pass in the query part of an HTTP URL, not a URI that you
dereference directly.

As a slight aside, we had a = really interested session with Tim Berners-Lee last week at TPAC on identit= y and auth on the web.=A0 The topic of webfinger came up in passing, where = he made an interesting comment.

He said that if you want to get an HTTP URI from an email address, the = most logical place to do so is via the SMTP protocol (something I had never= considered before!).=A0 He also seemed to suggest that there was already a= specification for this, but people decided to turn it off, for security re= asons.
=A0

If those who know more about URIs or WebFinger than I do disagree with
the foregoing characterization, I'd love to hear it.

Thanks for listening.

Above is based on my (limite= d) understanding of awww, corrections welcome :)
=A0

Peter

On 11/7/12 12:28 AM, Peter Saint-Andre wrote:
> Graham, thanks for taking the time to explain your thinking at greater=
> length. I now see your perspective and will ponder it a bit before
> replying further.
>
> Peter
>
> On 11/6/12 5:40 PM, Graham Klyne wrote:
>> Peter,
>>
>> I saw your revised text, but it doesn't reflect my take. =A0At= the time,
>> it didn't seem worth dragging out the discussion.
>>
>> You comment "other resolution protocols are allowed". = =A0Maybe there's
>> something I'm misunderstanding here, but my perception is that= this
>> applies no more to acct: URIs than it does to any other URI scheme= .
>> That is, there's nothing to stop one using *any* URI in some r= esolution
>> protocol (e.g. a database lookup, DDDS, a hash table, etc.) and th= ere
>> are specific situations in which this may be the right thing for a= n
>> application to do. =A0This is the light in which I see acct: URIs = being
>> used with other protocols. =A0But stripped of context, all you'= ;re left
>> with the the "native" dereferencing mechanism for the UR= I scheme, if
>> there is one.
>>
>> For schemes like http:, ftp:, etc., it is generally pretty clear w= hat is
>> the the standard mechanism for dereferencing.
>>
>> For other schemes like, say, mailto: one may have to squint a litt= le to
>> see the standard operation (like firing uo an email client) as
>> dereferencing, but
>>
>> And for schemes like urn: and info:, there is, by design, no commo= n
>> dereferencing mechanism.
>>
>> Against this background, my perception has been that acct: is not = *only*
>> about identification. =A0It has a specific association with WebFin= ger,
>> even if it is also expected to be used with other protocols. =A0I&= #39;m not
>> seeing that is any different from sending an HTML document contain= ing a
>> mailto: URI via HTTP, there the mailto: URI is ultimately used to<= br> >> identify a person, not send a mail message. =A0So I expect the acc= t:
>> scheme to be associated with WebFinger in the same way that http: = scheme
>> is associated with HTTP protocol. =A0When I reviewed acct:, I expe= cted
>> that part of the reason for having it as a separate URI scheme was= that
>> it could be used free of protocol context (e.g. in a web page) and= still
>> be dereferencable by some common mechanism.
>>
>> If I'm missing something, or if other people see this differen= tly then
>> that's fine. =A0I don't want to harp on about this. =A0But= the recent
>> discussion about acct: URIs and port numbers was, for me, a nice e= xample
>> of how associating acct: specifically and concretely with WebFinge= r and
>> making it behave like other commonly used URIs can simplify life f= or
>> some people without, as far as I can tell, taking away any of the = uses
>> that others may have in mind.
>>
>> #g
>> --
>>
>> On 06/11/2012 20:53, Peter Saint-Andre wrote:
>>> On 11/6/12 11:53 AM, Graham Klyne wrote:
>>>> I've argued elsewhere that I think the normal resoluti= on protocol for
>>>> acct: should be WebFinger.
>>>
>>> Graham, in the latest version of draft-ietf-appsawg-acct-uri I= have:
>>>
>>> =A0 =A0 Because an 'acct' URI enables identification o= nly and not
>>> =A0 =A0 interaction, it cannot be deferenced directly. =A0Any = protocol that
>>> =A0 =A0 might use the 'acct' URI scheme, such as the W= ebFinger protocol
>>> =A0 =A0 [I-D.ietf-appsawg-webfinger] or the Simple Web Discove= ry protocol
>>> =A0 =A0 [I-D.jones-simple-web-discovery], is responsible for s= pecifying how
>>> =A0 =A0 an 'acct' URI is dereferenced in the context o= f that protocol. =A0For
>>> =A0 =A0 example, an 'acct' URI might be passed as a pa= rameter in an HTTP
>>> =A0 =A0 request and the service might retrieve the relevant in= formation
>>> =A0 =A0 associated with the account identified by that URI and= then provide
>>> =A0 =A0 that information to the requesting entity in an HTTP r= esponse.
>>>
>>> As far as I understand the discussion so far, other resolution= protocols
>>> are allowed, which is why I wrote the text as it is right now.= Feedback
>>> is welcome.
>>>
>>> Peter
>>>

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

--e89a8f3b9d3d47194d04cdfb2a76-- From jpalme@dsv.su.se Thu Nov 8 08:59: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 C43E921F855C for ; Thu, 8 Nov 2012 08:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_SE=0.35, SARE_MILLIONSOF=0.315] 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 BXPlJad8BlQZ for ; Thu, 8 Nov 2012 08:59:03 -0800 (PST) Received: from smtprelay-b22.telenor.se (smtprelay-b22.telenor.se [195.54.99.213]) by ietfa.amsl.com (Postfix) with ESMTP id CE13F21F8508 for ; Thu, 8 Nov 2012 08:59:02 -0800 (PST) Received: from ipb4.telenor.se (ipb4.telenor.se [195.54.127.167]) by smtprelay-b22.telenor.se (Postfix) with ESMTP id 11C17EA254 for ; Thu, 8 Nov 2012 17:58:17 +0100 (CET) X-SENDER-IP: [85.224.107.178] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgA9AEnjm1BV4GuyPGdsb2JhbAANLQqHBKp0AYNNjj0BAQEBOIJORTABAQIIVFMaExuFLoIlqFKTfIwiCoYtA6Ewh36BYw X-IronPort-AV: E=Sophos;i="4.80,739,1344204000"; d="scan'208";a="148828829" Received: from c-b26be055.022-17-73746f16.cust.bredbandsbolaget.se (HELO [192.168.0.101]) ([85.224.107.178]) by ipb4.telenor.se with ESMTP; 08 Nov 2012 17:58:17 +0100 Mime-Version: 1.0 Message-Id: Date: Thu, 8 Nov 2012 17:58:08 +0100 To: General discussion of application-layer protocols From: Jacob Palme Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [apps-discuss] SPAM is IETF-s largest failure 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, 08 Nov 2012 16:59:03 -0000 Talk to ordinary people, people who are not technical experts, as we are in this mailing list. Ask them what is good and bad about the Internet. You will find that most people will answer that spam control is IETF's largest failure. IETF started as a network for university people. They wanted a network to make interconnection between university and research people easy. They had no expectation that these people would misuse the network such as spammers do today. The root of the problem is that the cost of seinding e-mail is so low. You just submit your message, no fee, and a network of SMTP servers is eager and willing to forward your message to thousands or millions of recipients. We even get messages which ask us to buy software which makes it easy to forward your message to many recipients. Companies collect e-mail addresses from various sources and sell lists of millions of e-mail addresses for a low cost. The only solution which works is to make it more expensive to send messages. IETF should establish a new network, independent of the present e-mail forwarding network, with separate mail servers (SMTP, POP, IMAP servers) using new, separate ports for spam-free e-mail. The main difference is that there should be a charge, perhaps 0.10 dollars, to submit e-mail. 0.10 dollars per recipient when you submit your message. The new network should use cryptographic methods to stop bandits from using it without paying this fee. The money collected from paying clients should use to further recognize and stop any spammers which might get into the new network. But the important thing is not to detech and stop spammers - this has been tried for many years and thus not work. The important thing is the fee per recipient for submitting messages into the new network. Spammers will not be willing to pay this cost. Their business model is built on the idea that you can for a negligible cost submit mail to millions of recipients. Their business model will collapse if they have to pay for submitting messages. I expect that recipients will be happy to recieve messages from the new spam-free network. There are, of course, problems with this solution. One large problem is mailing lists. Mailing lists, such as the one to which I am sending this message, will be too costly if the list maintainer has to pay a fee for every recipient. And people who submit messages to mailing list may not be willing to pay 0.10 dollars for every member of the maling list. The solution will have to allow exceptions from the 0.10 dollars/message for messages coming from mailing lists. There should be some kind of authority, established by IETF, which identifies serious mailing lists which are allowed to forward messages to members of mailing lists. However, the 0.10 fee will pay for the cost of running such an authority body. Another possible problem might be spammers who are willing to pay 0.10 dollars/recipient because they are able to identify recipients who will buy the product they are selling, so that the 0.10 dollar is acceptable cost. However, if a message is so interesting to recipients that senders are willing to pay 0.10 dollars per recipient for the sales message, then the recipients may be willing to read this spam and not regard it as spam. The new network should run in parallel to the present mail networks. Protocols should be mostly the same as those used today for the mail networks used today. Recipients will have to modify their POP or IMAP client so that it collects mail from two networks, the old spam-allowing network and the new spam-safe network. Mail reading clients will either put incoming messages into two "In" folders, one for the new spam-free mail and another for the old spam-containing net. Or alternately mark messages with different colors for messages from the spam-free and spam-containing net. The result may be that most people will not want to download any message from the old network. But if that is the case, it just shows the value of establishing a spam-free network. The establishing of a spam-free network, based on a fee per recipient for sending messages, will not be entirely easy. Some people may not be willing to pay for sending messages. Especially senders of private mail may not be willing to pay. The running of two parallel mail networks, one for spam-safe and one for non-spam-safe messages, will be a major effort for the IETF. But the gain is so large, and many people will be so happy for getting spam-free messages, that this is an effort which will cause people to thank IETF for the effort of establishing this new mail network. The income of 0.10 dollars per recipient will allow paying the cost of running the new spam-safe mail network. -- Jacob Palme , university professor emeritus for more info see URL: http://www.dsv.su.se/jpalme/ From perpetual-tripper@wwelves.org Thu Nov 8 09:34: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 3FCE921F84D2 for ; Thu, 8 Nov 2012 09:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.705 X-Spam-Level: X-Spam-Status: No, score=-0.705 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_20=-0.74, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 JynHRRhcVBlu for ; Thu, 8 Nov 2012 09:34:17 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id A351521F84D5 for ; Thu, 8 Nov 2012 09:34:17 -0800 (PST) X-Originating-IP: 217.70.178.149 Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 4CCF917208C; Thu, 8 Nov 2012 18:34:06 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 7YgUk706owxA; Thu, 8 Nov 2012 18:34:04 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id B24B9172084; Thu, 8 Nov 2012 18:34:04 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Jacob Palme In-reply-to: References: Date: Thu, 08 Nov 2012 17:34:03 +0000 Message-Id: <1352395377-sup-5827@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] SPAM is IETF-s largest failure 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, 08 Nov 2012 17:34:18 -0000 Excerpts from Jacob Palme's message of 2012-11-08 16:58:08 +0000: > Talk to ordinary people, people who are not technical=20 > experts, as we are in this mailing list. Ask them what is=20 > good and bad about the Internet. You will find that most=20 > people will answer that spam control is IETF's largest=20 > failure. >=20 > IETF started as a network for university people. They=20 > wanted a network to make interconnection between university=20 > and research people easy. They had no expectation that=20 > these people would misuse the network such as spammers do=20 > today. >=20 > The root of the problem is that the cost of seinding e-mail=20 > is so low. You just submit your message, no fee, and a=20 > network of SMTP servers is eager and willing to forward=20 > your message to thousands or millions of recipients. We=20 > even get messages which ask us to buy software which makes=20 > it easy to forward your message to many recipients.=20 > Companies collect e-mail addresses from various sources and=20 > sell lists of millions of e-mail addresses for a low cost. >=20 > The only solution which works is to make it more expensive=20 > to send messages.=20 Hi Jacob, I see spam as an issue related not only to communication over SMTP, when = it comes to using cryptography to approach this problem you can check out= this email: http://www.w3.org/2005/Incubator/webid/track/issues/48 On funny side, reading your email as someone who quit using money already= couple of years ago, I would not recommend solving technical/cultural is= sues with assumption that people will choose to continue using such a leg= acy information systems like monetary currencies, especially those nowada= ys in mainstream $, =E2=82=AC, =C2=A3 & co. :D Cheers! From fanf2@hermes.cam.ac.uk Thu Nov 8 09:35: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 F0DE121F87EE for ; Thu, 8 Nov 2012 09:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=-1.071, 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 UVU6OUbkg23b for ; Thu, 8 Nov 2012 09:35:33 -0800 (PST) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) by ietfa.amsl.com (Postfix) with ESMTP id 671AD21F84D2 for ; Thu, 8 Nov 2012 09:35:30 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:34503) by ppsw-43.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1TWW0n-0001vo-mt (Exim 4.72) (return-path ); Thu, 08 Nov 2012 17:35:29 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TWW0n-0003IO-4M (Exim 4.72) (return-path ); Thu, 08 Nov 2012 17:35:29 +0000 Date: Thu, 8 Nov 2012 17:35:29 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Jacob Palme In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] SPAM is IETF-s largest failure 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, 08 Nov 2012 17:35:34 -0000 Jacob Palme wrote: > The only solution which works is to make it more expensive to send messages. Doesn't seem to have worked for the postal service. http://www.rhyolite.com/anti-spam/you-might-be.html#e-postage Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From pbryan@anode.ca Thu Nov 8 09:49: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 7A5F021F8536 for ; Thu, 8 Nov 2012 09:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 HgbHWcULMm1G for ; Thu, 8 Nov 2012 09:49:50 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8DE21F8533 for ; Thu, 8 Nov 2012 09:49:50 -0800 (PST) Received: from [10.126.22.51] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 3681168A4; Thu, 8 Nov 2012 17:49:49 +0000 (UTC) From: "Paul C. Bryan" To: Jacob Palme In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-JKPhJMeWwf8GdOzvZ5a3" Date: Thu, 08 Nov 2012 09:49:39 -0800 Message-ID: <1352396979.26468.31.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] SPAM is IETF-s largest failure 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, 08 Nov 2012 17:49:51 -0000 --=-JKPhJMeWwf8GdOzvZ5a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit With a subject like this, and the numerous unqualified assertions within the text, I should conclude you're just trolling. If you're actually posting this in good faith, then some preliminary research would certainly be in order. Start with some simple facts, like the actual origin of the IETF, and investigate past attempts to prevent spam through micropayment and proof-of-work schemes. Describe why these initiatives failed to gain adoption, and how you propose their shortcomings can be solved. Describe other anti-spam techniques that major ISPs (including Gmail and Hotmail) currently use today, and why your proposed solution will be more attractive to them than what they already have in place. Paul On Thu, 2012-11-08 at 17:58 +0100, Jacob Palme wrote: > Talk to ordinary people, people who are not technical > experts, as we are in this mailing list. Ask them what is > good and bad about the Internet. You will find that most > people will answer that spam control is IETF's largest > failure. > > IETF started as a network for university people. They > wanted a network to make interconnection between university > and research people easy. They had no expectation that > these people would misuse the network such as spammers do > today. > > The root of the problem is that the cost of seinding e-mail > is so low. You just submit your message, no fee, and a > network of SMTP servers is eager and willing to forward > your message to thousands or millions of recipients. We > even get messages which ask us to buy software which makes > it easy to forward your message to many recipients. > Companies collect e-mail addresses from various sources and > sell lists of millions of e-mail addresses for a low cost. > > The only solution which works is to make it more expensive > to send messages. IETF should establish a new network, > independent of the present e-mail forwarding network, with > separate mail servers (SMTP, POP, IMAP servers) using new, > separate ports for spam-free e-mail. The main difference is > that there should be a charge, perhaps 0.10 dollars, to > submit e-mail. 0.10 dollars per recipient when you submit > your message. The new network should use cryptographic > methods to stop bandits from using it without paying this > fee. The money collected from paying clients should use to > further recognize and stop any spammers which might get > into the new network. But the important thing is not to > detech and stop spammers - this has been tried for many > years and thus not work. The important thing is the fee per > recipient for submitting messages into the new network. > Spammers will not be willing to pay this cost. Their > business model is built on the idea that you can for a > negligible cost submit mail to millions of recipients. > Their business model will collapse if they have to pay for > submitting messages. > > I expect that recipients will be happy to recieve messages > from the new spam-free network. > > There are, of course, problems with this solution. > > One large problem is mailing lists. Mailing lists, such as > the one to which I am sending this message, will be too > costly if the list maintainer has to pay a fee for every > recipient. And people who submit messages to mailing list > may not be willing to pay 0.10 dollars for every member of > the maling list. The solution will have to allow exceptions > from the 0.10 dollars/message for messages coming from > mailing lists. There should be some kind of authority, > established by IETF, which identifies serious mailing lists > which are allowed to forward messages to members of mailing > lists. However, the 0.10 fee will pay for the cost of > running such an authority body. > > Another possible problem might be spammers who are willing > to pay 0.10 dollars/recipient because they are able to > identify recipients who will buy the product they are > selling, so that the 0.10 dollar is acceptable cost. > However, if a message is so interesting to recipients that > senders are willing to pay 0.10 dollars per recipient for > the sales message, then the recipients may be willing to > read this spam and not regard it as spam. > > The new network should run in parallel to the present mail > networks. Protocols should be mostly the same as those used > today for the mail networks used today. Recipients will > have to modify their POP or IMAP client so that it collects > mail from two networks, the old spam-allowing network and > the new spam-safe network. Mail reading clients will either > put incoming messages into two "In" folders, one for the > new spam-free mail and another for the old spam-containing > net. Or alternately mark messages with different colors for > messages from the spam-free and spam-containing net. The > result may be that most people will not want to download > any message from the old network. But if that is the case, > it just shows the value of establishing a spam-free network. > > The establishing of a spam-free network, based on a fee per > recipient for sending messages, will not be entirely easy. > Some people may not be willing to pay for sending messages. > Especially senders of private mail may not be willing to > pay. The running of two parallel mail networks, one for > spam-safe and one for non-spam-safe messages, will be a > major effort for the IETF. But the gain is so large, and > many people will be so happy for getting spam-free > messages, that this is an effort which will cause people to > thank IETF for the effort of establishing this new mail > network. > > The income of 0.10 dollars per recipient will allow paying > the cost of running the new spam-safe mail network. --=-JKPhJMeWwf8GdOzvZ5a3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit With a subject like this, and the numerous unqualified assertions within the text, I should conclude you're just trolling.

If you're actually posting this in good faith, then some preliminary research would certainly be in order. Start with some simple facts, like the actual origin of the IETF, and investigate past attempts to prevent spam through micropayment and proof-of-work schemes. Describe why these initiatives failed to gain adoption, and how you propose their shortcomings can be solved. Describe other anti-spam techniques that major ISPs (including Gmail and Hotmail) currently use today, and why your proposed solution will be more attractive to them than what they already have in place.

Paul  

On Thu, 2012-11-08 at 17:58 +0100, Jacob Palme wrote: 
Talk to ordinary people, people who are not technical 
experts, as we are in this mailing list. Ask them what is 
good and bad about the Internet. You will find that most 
people will answer that spam control is IETF's largest 
failure.

IETF started as a network for university people. They 
wanted a network to make interconnection between university 
and research people easy. They had no expectation that 
these people would misuse the network such as spammers do 
today.

The root of the problem is that the cost of seinding e-mail 
is so low. You just submit your message, no fee, and a 
network of SMTP servers is eager and willing to forward 
your message to thousands or millions of recipients. We 
even get messages which ask us to buy software which makes 
it easy to forward your message to many recipients. 
Companies collect e-mail addresses from various sources and 
sell lists of millions of e-mail addresses for a low cost.

The only solution which works is to make it more expensive 
to send messages. IETF should establish a new network, 
independent of the present e-mail forwarding network, with 
separate mail servers (SMTP, POP, IMAP servers) using new, 
separate ports for spam-free e-mail. The main difference is 
that there should be a charge, perhaps 0.10 dollars, to 
submit e-mail. 0.10 dollars per recipient when you submit 
your message. The new network should use cryptographic 
methods to stop bandits from using it without paying this 
fee. The money collected from paying clients should use to 
further recognize and stop any spammers which might get 
into the new network. But the important thing is not to 
detech and stop spammers - this has been tried for many 
years and thus not work. The important thing is the fee per 
recipient for submitting messages into the new network. 
Spammers will not be willing to pay this cost. Their 
business model is built on the idea that you can for a 
negligible cost submit mail to millions of recipients. 
Their business model will collapse if they have to pay for 
submitting messages.

I expect that recipients will be happy to recieve messages 
from the new spam-free network.

There are, of course, problems with this solution.

One large problem is mailing lists. Mailing lists, such as 
the one to which I am sending this message, will be too 
costly if the list maintainer has to pay a fee for every 
recipient. And people who submit messages to mailing list 
may not be willing to pay 0.10 dollars for every member of 
the maling list. The solution will have to allow exceptions 
from the 0.10 dollars/message for messages coming from 
mailing lists. There should be some kind of authority, 
established by IETF, which identifies serious mailing lists 
which are allowed to forward messages to members of mailing 
lists. However, the 0.10 fee will pay for the cost of 
running such an authority body.

Another possible problem might be spammers who are willing 
to pay 0.10 dollars/recipient because they are able to 
identify recipients who will buy the product they are 
selling, so that the 0.10 dollar is acceptable cost. 
However, if a message is so interesting to recipients that 
senders are willing to pay 0.10 dollars per recipient for 
the sales message, then the recipients may be willing to 
read this spam and not regard it as spam.

The new network should run in parallel to the present mail 
networks. Protocols should be mostly the same as those used 
today for the mail networks used today. Recipients will 
have to modify their POP or IMAP client so that it collects 
mail from two networks, the old spam-allowing network and 
the new spam-safe network. Mail reading clients will either 
put incoming messages into two "In" folders, one for the 
new spam-free mail and another for the old spam-containing 
net. Or alternately mark messages with different colors for 
messages from the spam-free and spam-containing net. The 
result may be that most people will not want to download 
any message from the old network. But if that is the case, 
it just shows the value of establishing a spam-free network.

The establishing of a spam-free network, based on a fee per 
recipient for sending messages, will not be entirely easy. 
Some people may not be willing to pay for sending messages. 
Especially senders of private mail may not be willing to 
pay. The running of two parallel mail networks, one for 
spam-safe and one for non-spam-safe messages, will be a 
major effort for the IETF. But the gain is so large, and 
many people will be so happy for getting spam-free 
messages, that this is an effort which will cause people to 
thank IETF for the effort of establishing this new mail 
network.

The income of 0.10 dollars per recipient will allow paying 
the cost of running the new spam-safe mail network.

--=-JKPhJMeWwf8GdOzvZ5a3-- From hallam@gmail.com Thu Nov 8 10:22: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 53A5221F87E3 for ; Thu, 8 Nov 2012 10:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.059, 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 Kf8sjdkU-CfD for ; Thu, 8 Nov 2012 10:22:36 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6101221F8691 for ; Thu, 8 Nov 2012 10:22:36 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so3421972oag.31 for ; Thu, 08 Nov 2012 10:22:35 -0800 (PST) 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=qa3h4abmzc2FQ3bQp3bod+mHkDxIK+QrPcrHuWt46fk=; b=0nX1XzuMNS+Xmg6RdGSDEt3KUNLINmVdLe7stIxwE3dZUkSZHD4H/AXo2ovw8h7fJF z2X7ZSscR08DfwQBgVxincZ8x1moLdFKvHp2LNjotOatCaLjB5gKZcF0budHxWBEKQ0l A6fHdAZe6OhOpDRHitv4dYGmXxd7gJxFSfBPs90Rdbyzf8gpRhHV7tAeiK/d8okCaErh l4JhOzGN2MPnNXi9pHJyRcyjy6aon+IOFoX9obKKTyHK+cv+9EirKEX/AN6KN3OY6etM JcBdkzojkUe/xElndaaRwdO/+IJUrRR/27GwVFl//uS/SzDNFyGK6IoCRyhLuL42TP2X wCjA== MIME-Version: 1.0 Received: by 10.60.31.135 with SMTP id a7mr5541480oei.26.1352398955709; Thu, 08 Nov 2012 10:22:35 -0800 (PST) Received: by 10.76.27.103 with HTTP; Thu, 8 Nov 2012 10:22:35 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Nov 2012 13:22:35 -0500 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=e89a8fb1f59a59852804cdffeba1 Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] SPAM is IETF-s largest failure 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, 08 Nov 2012 18:22:37 -0000 --e89a8fb1f59a59852804cdffeba1 Content-Type: text/plain; charset=ISO-8859-1 It isn't working for the telephone system either. The FCC is currently soliciting proposals for blocking RoboCalls. Spam is essentially a problem of costs, the cost to the sender is much less than the benefit to the sender and the sender does not care about the cost they impose on the recipients. But introducing additional costs into the system does not eliminate the problem, it merely changes the type of spam. Introducing cost into the system also affects people who are not spammers at all. And no amount of handwavy attempts to dismiss that flaw are going to change things. Telling people that they just have to accept the idea as inevitable is not an argument. In my last year at VeriSign I was getting over 3000 messages a day, most were spam. I have moved my IETF related work to Gmail precisely because I don't want to flood the corporate servers again. My gmail spam rate is much lower, likely because many of the big boy spam houses know their success rate against the google filter and decide it is not worth the effort. But at any rate, my spam problem was severe and it is now effectively solved at zero cost to me without the need for any micropayment scheme. Another issue that the proponents of these schemes never seem to get to is who gets the money. On Thu, Nov 8, 2012 at 12:35 PM, Tony Finch wrote: > Jacob Palme wrote: > > > The only solution which works is to make it more expensive to send > messages. > > Doesn't seem to have worked for the postal service. > > http://www.rhyolite.com/anti-spam/you-might-be.html#e-postage > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at > first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate or > good, > occasionally poor at first. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Website: http://hallambaker.com/ --e89a8fb1f59a59852804cdffeba1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It isn't working for the telephone system either. The FCC is currently = soliciting proposals for blocking RoboCalls.

Spam is ess= entially a problem of costs, the cost to the sender is much less than the b= enefit to the sender and the sender does not care about the cost they impos= e on the recipients. But introducing additional costs into the system does = not eliminate the problem, it merely changes the type of spam.

Introducing cost into the system also affects people wh= o are not spammers at all. And no amount of handwavy attempts to dismiss th= at flaw are going to change things. Telling people that they just have to a= ccept the idea as inevitable is not an argument.=A0

In my last year at VeriSign I was getting over 3000 mes= sages a day, most were spam. I have moved my IETF related work to Gmail pre= cisely because I don't want to flood the corporate servers again. My gm= ail spam rate is much lower, likely because many of the big boy spam houses= know their success rate against the google filter and decide it is not wor= th the effort. But at any rate, my spam problem was severe and it is now ef= fectively solved at zero cost to me without the need for any micropayment s= cheme.

Another issue that the proponents of these schemes neve= r seem to get to is who gets the money.=A0




On Thu, No= v 8, 2012 at 12:35 PM, Tony Finch <dot@dotat.at> wrote:
Jacob Palme <jpalme@dsv.su.se> wrote:

> The only solution which works is to make it more expensive to send mes= sages.

Doesn't seem to have worked for the postal service.

http://www.rhyolite.com/anti-spam/you-might-be.html#e-post= age

Tony.
--
f.anthony.n.finch =A0<dot@dotat.at&g= t; =A0http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first= .
Rough, becoming slight or moderate. Showers, rain at first. Moderate or goo= d,
occasionally poor at first.
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



--
= Website: http://hallambaker.com/
--e89a8fb1f59a59852804cdffeba1-- From fanf2@hermes.cam.ac.uk Thu Nov 8 10:33: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 DA5E521F8431 for ; Thu, 8 Nov 2012 10:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.134 X-Spam-Level: X-Spam-Status: No, score=-5.134 tagged_above=-999 required=5 tests=[AWL=1.465, 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 VAEUtuejQpxU for ; Thu, 8 Nov 2012 10:33:35 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id A5A3521F841E for ; Thu, 8 Nov 2012 10:33:35 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:52657) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1TWWux-0003VI-SU (Exim 4.72) (return-path ); Thu, 08 Nov 2012 18:33:32 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TWWux-0001mn-QV (Exim 4.72) (return-path ); Thu, 08 Nov 2012 18:33:31 +0000 Date: Thu, 8 Nov 2012 18:33:31 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] SPAM is IETF-s largest failure 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, 08 Nov 2012 18:33:37 -0000 Rather than discussing e-postage here we could go and read http://www.taugh.com/epostage.pdf Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From johnl@iecc.com Thu Nov 8 11:20: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 5621C21F87F7 for ; Thu, 8 Nov 2012 11:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.917 X-Spam-Level: X-Spam-Status: No, score=-110.917 tagged_above=-999 required=5 tests=[AWL=-1.018, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, MANGLED_SPAM=2.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 HQCZSB2-fThX for ; Thu, 8 Nov 2012 11:20:14 -0800 (PST) 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 C34E221F87F6 for ; Thu, 8 Nov 2012 11:20:06 -0800 (PST) Received: (qmail 45251 invoked from network); 8 Nov 2012 19:20:05 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 8 Nov 2012 19:20: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:mime-version:content-type:content-transfer-encoding:vbr-info; s=509c05e5.xn--btvx9d.k1211; i=johnl@user.iecc.com; bh=bggGGeABgqz8uMQ++pfnKDBqscShj556yWAz8WzLKKU=; b=SH9t97QkcvimyQXNbCkvVgOmaE9Jb4z0TeXe/jYCTu8Evib4acW/fWpTsaZyF/N/KPAKkTRbK2lCSU4ag4Cq/X3ofbpijbOCO2le5ODCuyNrBP5LhvFHfmt+b1Nf8b+Zi64R+W4mFFkkIA+DaGAFjGnEvuv+qL9GHGygSi5T1fg= 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=509c05e5.xn--btvx9d.k1211; olt=johnl@user.iecc.com; bh=bggGGeABgqz8uMQ++pfnKDBqscShj556yWAz8WzLKKU=; b=WuyepYoLODVuEpZFc5r8FN3CqAl58jb7JbhJm8uVZJGhleCCmjay1GVaDeCIM2dGcL9q3M+D1SSSJ4Kpx2bVhtShjIe8Mne78/lnMK1daYEF69BSNHt1O74Wyy2rRvQTm80LISqFu9+V4q83pVU4sZwHFQIePKEYqXuwKfVwrL0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 8 Nov 2012 19:19:42 -0000 Message-ID: <20121108191942.4619.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] SPAM is IETF-s largest failure 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, 08 Nov 2012 19:20:15 -0000 >The only solution which works is ... The IRTF anti-spam research group has a wiki on which we've put a lot of well known anti-spam techniques. To save time, how about looking up yours to see where they've failed before? http://wiki.asrg.sp.am/ From tzink@exchange.microsoft.com Thu Nov 8 11: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 23DEE21F866B for ; Thu, 8 Nov 2012 11:54:20 -0800 (PST) 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 c6wuMSuzMz4G for ; Thu, 8 Nov 2012 11:54:19 -0800 (PST) Received: from NA01-BY1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.90]) by ietfa.amsl.com (Postfix) with ESMTP id 41B6C21F85D5 for ; Thu, 8 Nov 2012 11:54:19 -0800 (PST) Received: from CH1SR01CA102.namsdf01.sdf.exchangelabs.com (10.255.157.19) by CH1SR01MB612.namsdf01.sdf.exchangelabs.com (10.255.157.40) with Microsoft SMTP Server (TLS) id 15.0.568.2; Thu, 8 Nov 2012 19:54:16 +0000 Received: from BY1FFOFD003.ffo.gbl (64.4.22.93) by CH1SR01CA102.outlook.com (10.255.157.19) with Microsoft SMTP Server (TLS) id 15.0.568.2 via Frontend Transport; Thu, 8 Nov 2012 19:54:16 +0000 Received: from hybrid.exchange.microsoft.com (131.107.1.27) by BY1FFOFD003.mail.o365filtering.com (10.1.16.90) with Microsoft SMTP Server (TLS) id 15.0.556.0 via Frontend Transport; Thu, 8 Nov 2012 19:54:15 +0000 Received: from DFM-TK5MBX15-03.exchange.corp.microsoft.com (157.54.110.22) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.3.107.0; Thu, 8 Nov 2012 11:53:59 -0800 Received: from PIO-MBX-02.exchange.corp.microsoft.com (157.54.94.28) by DFM-TK5MBX15-03.exchange.corp.microsoft.com (157.54.110.22) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 8 Nov 2012 11:53:59 -0800 Received: from PIO-MBX-02.exchange.corp.microsoft.com (2001:4898:0:fff:200:5efe:157.54.94.28) by PIO-MBX-02.exchange.corp.microsoft.com (2001:4898:0:fff:200:5efe:157.54.94.28) with Microsoft SMTP Server (TLS) id 15.0.568.1; Thu, 8 Nov 2012 11:53:58 -0800 Received: from PIO-MBX-02.exchange.corp.microsoft.com ([fe80::e950:5a76:cafe:c79]) by PIO-MBX-02.exchange.corp.microsoft.com ([fe80::e950:5a76:cafe:c79%13]) with mapi id 15.00.0568.000; Thu, 8 Nov 2012 11:53:58 -0800 From: Terry Zink To: General discussion of application-layer protocols Thread-Topic: [apps-discuss] SPAM is IETF-s largest failure Thread-Index: AQHNvdJi7FfrGoEuK0iV1OXbZF2amJfgvVCA//+cLoA= Date: Thu, 8 Nov 2012 19:53:55 +0000 Message-ID: <61672ec9bebe45998cab035e3e7dc865@PIO-MBX-02.exchange.corp.microsoft.com> References: <1352396979.26468.31.camel@pbryan-wsl.internal.salesforce.com> In-Reply-To: <1352396979.26468.31.camel@pbryan-wsl.internal.salesforce.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:1000:6003::10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.1.27; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377424002)(24454001)(377454001)(33646001)(50986001)(76482001)(54316001)(54356001)(47736001)(23676001)(47776002)(46102001)(47976001)(49866001)(4396001)(876001)(51856001)(550184003)(16406001)(53806001)(44976002)(47446002)(74502001)(31966008)(50466001)(5343655001)(74662001)(3826001)(24736002); DIR:OUT; SFP:; LANG:en; X-Forefront-PRVS: 06592CCE58 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [apps-discuss] SPAM is IETF-s largest failure 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, 08 Nov 2012 19:54:20 -0000 PiBXaXRoIGEgc3ViamVjdCBsaWtlIHRoaXMsIGFuZCB0aGUgbnVtZXJvdXMgdW5xdWFsaWZpZWQg YXNzZXJ0aW9ucw0KPiB3aXRoaW4gdGhlIHRleHQsIEkgc2hvdWxkIGNvbmNsdWRlIHlvdSdyZSBq dXN0IHRyb2xsaW5nLg0KDQpBZnRlciBnZXR0aW5nIHRocm91Z2ggdGhlIGZpcnN0IDEvMyBvZiB0 aGUgbWVzc2FnZSwgSSB0aG91Z2h0IHRoYXQgdGhlIG9yaWdpbmFsIGVtYWlsIHdhcyBvbmx5IGEg am9rZS4NCg0KLS0gVGVycnkNCg0KDQpGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF1 bCBDLiBCcnlhbg0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDA4LCAyMDEyIDk6NTAgQU0NClRv OiBKYWNvYiBQYWxtZQ0KQ2M6IEdlbmVyYWwgZGlzY3Vzc2lvbiBvZiBhcHBsaWNhdGlvbi1sYXll ciBwcm90b2NvbHMNClN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBTUEFNIGlzIElFVEYtcyBs YXJnZXN0IGZhaWx1cmUNCg0KV2l0aCBhIHN1YmplY3QgbGlrZSB0aGlzLCBhbmQgdGhlIG51bWVy b3VzIHVucXVhbGlmaWVkIGFzc2VydGlvbnMgd2l0aGluIHRoZSB0ZXh0LCBJIHNob3VsZCBjb25j bHVkZSB5b3UncmUganVzdCB0cm9sbGluZy4NCg0KSWYgeW91J3JlIGFjdHVhbGx5IHBvc3Rpbmcg dGhpcyBpbiBnb29kIGZhaXRoLCB0aGVuIHNvbWUgcHJlbGltaW5hcnkgcmVzZWFyY2ggd291bGQg Y2VydGFpbmx5IGJlIGluIG9yZGVyLiBTdGFydCB3aXRoIHNvbWUgc2ltcGxlIGZhY3RzLCBsaWtl IHRoZSBhY3R1YWwgb3JpZ2luIG9mIHRoZSBJRVRGLCBhbmQgaW52ZXN0aWdhdGUgcGFzdCBhdHRl bXB0cyB0byBwcmV2ZW50IHNwYW0gdGhyb3VnaCBtaWNyb3BheW1lbnQgYW5kIHByb29mLW9mLXdv cmsgc2NoZW1lcy4gRGVzY3JpYmUgd2h5IHRoZXNlIGluaXRpYXRpdmVzIGZhaWxlZCB0byBnYWlu IGFkb3B0aW9uLCBhbmQgaG93IHlvdSBwcm9wb3NlIHRoZWlyIHNob3J0Y29taW5ncyBjYW4gYmUg c29sdmVkLiBEZXNjcmliZSBvdGhlciBhbnRpLXNwYW0gdGVjaG5pcXVlcyB0aGF0IG1ham9yIElT UHMgKGluY2x1ZGluZyBHbWFpbCBhbmQgSG90bWFpbCkgY3VycmVudGx5IHVzZSB0b2RheSwgYW5k IHdoeSB5b3VyIHByb3Bvc2VkIHNvbHV0aW9uIHdpbGwgYmUgbW9yZSBhdHRyYWN0aXZlIHRvIHRo ZW0gdGhhbiB3aGF0IHRoZXkgYWxyZWFkeSBoYXZlIGluIHBsYWNlLg0KDQpQYXVswqDCoCANCg0K T24gVGh1LCAyMDEyLTExLTA4IGF0IDE3OjU4ICswMTAwLCBKYWNvYiBQYWxtZSB3cm90ZTogDQoN ClRhbGsgdG8gb3JkaW5hcnkgcGVvcGxlLCBwZW9wbGUgd2hvIGFyZSBub3QgdGVjaG5pY2FsIA0K ZXhwZXJ0cywgYXMgd2UgYXJlIGluIHRoaXMgbWFpbGluZyBsaXN0LiBBc2sgdGhlbSB3aGF0IGlz IA0KZ29vZCBhbmQgYmFkIGFib3V0IHRoZSBJbnRlcm5ldC4gWW91IHdpbGwgZmluZCB0aGF0IG1v c3QgDQpwZW9wbGUgd2lsbCBhbnN3ZXIgdGhhdCBzcGFtIGNvbnRyb2wgaXMgSUVURidzIGxhcmdl c3QgDQpmYWlsdXJlLg0KDQo8c25pcD4NCg0K From dhc@dcrocker.net Thu Nov 8 12:15: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 06B6221F8A48 for ; Thu, 8 Nov 2012 12:15:44 -0800 (PST) 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 j-l31ei7Jins for ; Thu, 8 Nov 2012 12:15:41 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9B821F84BF for ; Thu, 8 Nov 2012 12:15:41 -0800 (PST) Received: from [130.129.17.128] (dhcp-1180.meeting.ietf.org [130.129.17.128]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id qA8KFQme028580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Nov 2012 12:15:28 -0800 Message-ID: <509C12D8.3090208@dcrocker.net> Date: Thu, 08 Nov 2012 15:15:20 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jacob Palme References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 08 Nov 2012 12:15:29 -0800 (PST) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] SPAM is IETF-s largest failure X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 20:15:44 -0000 Jacob, On 11/8/2012 11:58 AM, Jacob Palme wrote: > Talk to ordinary people, people who are not technical experts, as we are > in this mailing list. Ask them what is good and bad about the Internet. > You will find that most people will answer that spam control is IETF's > largest failure. Yes, because the IETF should have found a way to prevent crime over the Internet, given how well others have done at preventing crime in the physical world. > IETF started as a network for university people. Not really. From the start, the net was a collaboration among academic, research and /military/ sites. What was missing, though, was a concern for commercial operation. Since the net was expected to remain as an exemplar technology, rather than become a global service, the lack of certain features was not a "failure". > They wanted a network > to make interconnection between university and research people easy. > They had no expectation that these people would misuse the network such > as spammers do today. The first spam was 1978. Do you think that no one saw that and considered it a harbinger? > The root of the problem is that the cost of seinding e-mail is so low. . Right. Because after all, we do not get the equivalent of spam via postal or telephonic channels. > The only solution which works is to make it more expensive to send > messages. So, this is the place for the standard citation: http://craphound.com/spamsolutions.txt Cory Doctorow meant it for humor, as nearly as we can tell, but quite a few of us find it helpful for filtering FUSSP proposals. This is also a reason place the usual reminder that most problems are easy to solve in theory, but that workable solutions for changing a large infrastructure service require that one not start with simplistic assertions about what will work. > IETF should establish a new network, The IETF does not "establish" networks. If you want to promote a new service, please do. independent of the > present e-mail forwarding network, with separate mail servers (SMTP, > POP, IMAP servers) using new, separate ports for spam-free e-mail. There is quite a bit of experience with folk who attempt, or have attempted, to provide such 'certified' email services. By 'provide' I mean make assurance about specific senders. You should learn about how delightful their life has been and how many of them have gone out of business. > The > main difference is that there should be a charge, perhaps 0.10 dollars, I don't remember how many business have attempted this model, but it's at least several. Good luck with that. > There are, of course, problems with this solution. Only one: it won't work. > The new network should run in parallel to the present mail networks. You might want to study issues with switching costs and the challenges they present as very high barriers to entry for replacement services. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From GK@ninebynine.org Fri Nov 9 03:35: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 CA29921F8651 for ; Fri, 9 Nov 2012 03:35:58 -0800 (PST) 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 v-bcXkAy9k4w for ; Fri, 9 Nov 2012 03:35:57 -0800 (PST) Received: from relay3.mail.ox.ac.uk (relay3.mail.ox.ac.uk [163.1.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id BB37D21F84C6 for ; Fri, 9 Nov 2012 03:35:56 -0800 (PST) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay3.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TWmsN-00037S-AV; Fri, 09 Nov 2012 11:35:55 +0000 Received: from [12.189.153.253] (helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TWmsN-00013g-04; Fri, 09 Nov 2012 11:35:55 +0000 Message-ID: <509CEA8B.7020507@ninebynine.org> Date: Fri, 09 Nov 2012 11:35:39 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im> <509991D0.9000007@ninebynine.org> <5099F175.3060703@stpeter.im> <509BA2F2.6000006@stpeter.im> In-Reply-To: <509BA2F2.6000006@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 09 Nov 2012 11:35:58 -0000 On 08/11/2012 12:17, Peter Saint-Andre wrote: > Hi Graham, > > Thanks again for sharing your thoughts on the matter. I happened to chat > about this with a few folks here at the IETF meeting in Atlanta, and > here is how I see it... > > We have this protocol called WebFinger: in order to retrieve pointers to > further information about a person associated with a domain, a client > sends a special HTTP request to a server at that domain and passes as a > parameter in that request a URI that identifies the person. That URI > could be a 'mailto:', 'sip:', 'xmpp:', 'callto:' (?), or other URI that > includes an identifier for the person (i.e., for an account controlled > by the person). > > When the client completes that operation, is it dereferencing the > 'mailto:', 'sip:', 'xmpp:' (etc.) URI that is passed as a parameter? Or > it dereferencing the HTTP URL to which it sends the request? Example: > > http://example.com/lrdd/?f=json&uri=xmpp%3Abob%40example.com > > This might only indicate my ignorance of URIs, but that example doesn't > feel to me like a dereferencing of an 'xmpp:' URI, which I would expect > to be something like this (see XEP-0054 at xmpp.org): > > xmpp:bob@example.com?vcard You're right. It's dereferencing an HTTP URI which happens to contain an encoded xmpp URI (but HTTP protocol doesn't know about that). > Instead, the URI that is passed as a parameter in the WebFinger > operation feels to me like something that is used purely for > identification, not interaction (dereferencing). > > If that line of reasoning is just wrong, please do let me know. :-) I don't disagree with anything you've said here. But it doesn't say anything about what you do when starting with an acct: URI and want to find out more. Let me posit for the purpose of debate that dereferencing an acct: URI is done using WebFinger. It happens that execution of the WebFinger protocol involves dereferencing HTTP URIs, and those HTTP URIs may contain references to (parts of) the acct: URIs, or any other ind of URI. So dereferencing an acct: URI involves constructing an http: URI and then dereferencing that. I see no conflict here. > The WebFinger community, through much conversation over the years, > decided that it was potentially confusing to use 'mailto:' URIs when > passing a parameter in the WebFinger operation, primarily because there > might not be an email service running at the domain or associated with > that person, and perhaps secondarily because they didn't want to set up > the expectation that the requesting entity was initiating any kind of > email-based interaction. Therefore, they decided to define a neutral URI > scheme that would be used purely for identification. Sure, no argument here from me. > As I understand it, there is no expection that an HTML href attribute > containing an 'acct:' URI would trigger a WebFinger interaction: > > info Maybe that's where our positions differ. I think it's quite reasonable that an acct: URI could in principle, be used in this way (i.e. as an arbitrary link in a document. Modulo implementation support, of course). And that kind of dereferencing may not be what the WebFinger designers had in mind, but they have chosen to adopt an artifact (URI) from another framework (the Web), so there are expectations that might be associated with that artifact. Web architecture tries to maintain a separation of purpose between URIs and protocols: in principle (though not always in practice) an application that uses a URI in a generic way (such as in HTML @href values) should strive be "colour blind" with respect to the URI provided (cf. "URI Opacity" - http://www.w3.org/TR/webarch/#uri-opacity) ... > > Instead, the client would need to include the correct HTTP URL: > > href='http://example.com/lrdd/?f=json&uri=xmpp%3Abob%40example.com'>info ... In this case, I'd say the application that is generating a web page with a link in it should ideally not have to treat the acct: scheme differently (i.e. not need know that it has to generate the corresponding WebFinger http: URI) - that level of treatment is, IMO, best taken as part of the dereferencing semantics of the URI scheme itself, not the application that uses it. > Therefore, I continue to think that 'acct:' URIs are used purely for > identification and not at all for interaction. It's just a parameter > that you pass in the query part of an HTTP URL, not a URI that you > dereference directly. > > If those who know more about URIs or WebFinger than I do disagree with > the foregoing characterization, I'd love to hear it. I don't think there's a definitive right-or-wrong position here. I just feel that, to the extent that acct: *is* associated with a specific protocol, that the dereferencing mechanism should be part of the URI specification. You appear see acct: as a kind of URN (in the broad sense of URN), I prefer to see it as a kind of URL. Either is technically acceptable, but I feel the URL view is potentially more useful as, among other things, it enables (automatable) follow-your-nose discovery to be associated with acct: URIs. > Thanks for listening. Thank you for listening :) #g -- > On 11/7/12 12:28 AM, Peter Saint-Andre wrote: >> Graham, thanks for taking the time to explain your thinking at greater >> length. I now see your perspective and will ponder it a bit before >> replying further. >> >> Peter >> >> On 11/6/12 5:40 PM, Graham Klyne wrote: >>> Peter, >>> >>> I saw your revised text, but it doesn't reflect my take. At the time, >>> it didn't seem worth dragging out the discussion. >>> >>> You comment "other resolution protocols are allowed". Maybe there's >>> something I'm misunderstanding here, but my perception is that this >>> applies no more to acct: URIs than it does to any other URI scheme. >>> That is, there's nothing to stop one using *any* URI in some resolution >>> protocol (e.g. a database lookup, DDDS, a hash table, etc.) and there >>> are specific situations in which this may be the right thing for an >>> application to do. This is the light in which I see acct: URIs being >>> used with other protocols. But stripped of context, all you're left >>> with the the "native" dereferencing mechanism for the URI scheme, if >>> there is one. >>> >>> For schemes like http:, ftp:, etc., it is generally pretty clear what is >>> the the standard mechanism for dereferencing. >>> >>> For other schemes like, say, mailto: one may have to squint a little to >>> see the standard operation (like firing uo an email client) as >>> dereferencing, but >>> >>> And for schemes like urn: and info:, there is, by design, no common >>> dereferencing mechanism. >>> >>> Against this background, my perception has been that acct: is not *only* >>> about identification. It has a specific association with WebFinger, >>> even if it is also expected to be used with other protocols. I'm not >>> seeing that is any different from sending an HTML document containing a >>> mailto: URI via HTTP, there the mailto: URI is ultimately used to >>> identify a person, not send a mail message. So I expect the acct: >>> scheme to be associated with WebFinger in the same way that http: scheme >>> is associated with HTTP protocol. When I reviewed acct:, I expected >>> that part of the reason for having it as a separate URI scheme was that >>> it could be used free of protocol context (e.g. in a web page) and still >>> be dereferencable by some common mechanism. >>> >>> If I'm missing something, or if other people see this differently then >>> that's fine. I don't want to harp on about this. But the recent >>> discussion about acct: URIs and port numbers was, for me, a nice example >>> of how associating acct: specifically and concretely with WebFinger and >>> making it behave like other commonly used URIs can simplify life for >>> some people without, as far as I can tell, taking away any of the uses >>> that others may have in mind. >>> >>> #g >>> -- >>> >>> On 06/11/2012 20:53, Peter Saint-Andre wrote: >>>> On 11/6/12 11:53 AM, Graham Klyne wrote: >>>>> I've argued elsewhere that I think the normal resolution protocol for >>>>> acct: should be WebFinger. >>>> >>>> Graham, in the latest version of draft-ietf-appsawg-acct-uri I have: >>>> >>>> Because an 'acct' URI enables identification only and not >>>> interaction, it cannot be deferenced directly. Any protocol that >>>> might use the 'acct' URI scheme, such as the WebFinger protocol >>>> [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol >>>> [I-D.jones-simple-web-discovery], is responsible for specifying how >>>> an 'acct' URI is dereferenced in the context of that protocol. For >>>> example, an 'acct' URI might be passed as a parameter in an HTTP >>>> request and the service might retrieve the relevant information >>>> associated with the account identified by that URI and then provide >>>> that information to the requesting entity in an HTTP response. >>>> >>>> As far as I understand the discussion so far, other resolution protocols >>>> are allowed, which is why I wrote the text as it is right now. Feedback >>>> is welcome. >>>> >>>> Peter >>>> > From martijn.grooten@virusbtn.com Fri Nov 9 04:49: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 54BD721F868F for ; Fri, 9 Nov 2012 04:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 sYU0z+FXfE9C for ; Fri, 9 Nov 2012 04:49:18 -0800 (PST) Received: from mx4.sophos.com (mx4.sophos.com [216.47.234.213]) by ietfa.amsl.com (Postfix) with ESMTP id AA3A721F8684 for ; Fri, 9 Nov 2012 04:49:17 -0800 (PST) Received: from mx4.sophos.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 355FE4E0324 for ; Fri, 9 Nov 2012 12:49:16 +0000 (GMT) Received: from ABN-EXCH1A.green.sophos (abn-exch1a.green.sophos [10.100.70.61]) by mx4.sophos.com (Postfix) with ESMTPS id B51534E0323 for ; Fri, 9 Nov 2012 12:49:15 +0000 (GMT) Received: from abn-exch1b.green.sophos ([fe80::dc96:facf:3d2c:c352]) by ABN-EXCH1A.green.sophos ([fe80::67:3150:dacd:910d%16]) with mapi id 14.02.0247.003; Fri, 9 Nov 2012 12:49:07 +0000 From: Martijn Grooten To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] SPAM is IETF-s largest failure Thread-Index: AQHNvdJgKbi1w8fRVUqcOrycVwuaRpfgX+gAgAEMLRA= Date: Fri, 9 Nov 2012 12:49:06 +0000 Message-ID: <0D79787962F6AE4B84B2CC41FC957D0B18C9CC85@abn-exch1b.green.sophos> References: <509C12D8.3090208@dcrocker.net> In-Reply-To: <509C12D8.3090208@dcrocker.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.110.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] SPAM is IETF-s largest failure 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, 09 Nov 2012 12:49:19 -0000 Dave Crocker wrote: > > There are, of course, problems with this solution. > > Only one: it won't work. Should this and other arguments posted here somehow not be convincing, cons= ider the following: There already is an implicit e-postage-like system in place. Sending email = does cost money. You need to have a computer, or pay to use one at an Inter= net cafe, to send an email. If you want to send a lot of emails, you need t= o buy/rent a mail server (or pay someone to send them for you). And you nee= d to pay someone to look after that server. And if you start sending a real= ly large amount of emails, you will have to handle abuse reports and scan o= utbound messages for spam and probably look into things like SPF and DKIM. = All of which requires time and knowledge - and thus costs money. So there is a strong correlation between money spent and delivery rates. Of= course, if what you're sending is crap no one cares to receive, your deliv= ery rates are likely going to be low, no matter how much you pay. And if wh= at you're sending is something people really, really want to receive, you c= an probably get away with spending relatively little on your mail server. W= hich to me seems better than a causal relation between the money invested i= n the infrastructure and delivery rates. With this implicit e-postage system in place, only a few per cent of spam m= akes it through to people's inboxes. False positive rates are very low. I challenge you to find an example of something bad where catch rates are t= his high. Malware? Burglaries? Drug trafficking? Diseases? Those fighting t= hem are jealous of the rates at which spam is caught. Note that I'm not saying that the spam problem is solved, because it isn't = and there is a lot of work to be done. But if you come up with a completely new way to deal with the spam problem = (whether it is something like e-postage, the failing of which has been disc= ussed in great detail, or something completely new) you shouldn't just expl= ain why it would work. You should also explain why it would work _better_ t= han what we currently have. Martijn. ________________________________ Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. From ietfc@btconnect.com Fri Nov 9 08:46: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 A0BAD21F870F for ; Fri, 9 Nov 2012 08:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.174 X-Spam-Level: X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 1-9ga3PRLomd for ; Fri, 9 Nov 2012 08:46:16 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id DC19A21F870C for ; Fri, 9 Nov 2012 08:46:15 -0800 (PST) Received: from mail57-co1-R.bigfish.com (10.243.78.247) by CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id 14.1.225.23; Fri, 9 Nov 2012 16:46:14 +0000 Received: from mail57-co1 (localhost [127.0.0.1]) by mail57-co1-R.bigfish.com (Postfix) with ESMTP id B5BC22E0274; Fri, 9 Nov 2012 16:46:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371Id772h542M1432Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h93fhd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h304l1155h) Received: from mail57-co1 (localhost.localdomain [127.0.0.1]) by mail57-co1 (MessageSwitch) id 135247957318965_8895; Fri, 9 Nov 2012 16:46:13 +0000 (UTC) Received: from CO1EHSMHS017.bigfish.com (unknown [10.243.78.228]) by mail57-co1.bigfish.com (Postfix) with ESMTP id ECBBA700074; Fri, 9 Nov 2012 16:46:12 +0000 (UTC) Received: from DB3PRD0710HT004.eurprd07.prod.outlook.com (157.56.253.85) by CO1EHSMHS017.bigfish.com (10.243.66.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 9 Nov 2012 16:46:12 +0000 Received: from AMXPRD0610HT005.eurprd06.prod.outlook.com (157.56.248.213) by pod51017.outlook.com (10.255.75.39) with Microsoft SMTP Server (TLS) id 14.16.233.4; Fri, 9 Nov 2012 16:46:12 +0000 Message-ID: <007d01cdbe99$9d1fe7c0$4001a8c0@gateway.2wire.net> From: t.petch To: Peter Saint-Andre References: <508E9713.3030301@stpeter.im> <002201cdb843$09105f80$4001a8c0@gateway.2wire.net> <50982FB2.3090903@stpeter.im> Date: Fri, 9 Nov 2012 16:45:12 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.213] X-OriginatorOrg: btconnect.com Cc: 'Graham Klyne' , apps-discuss@ietf.org Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 09 Nov 2012 16:46:16 -0000 --Original Message ----- From: "Peter Saint-Andre" To: "t.petch" Cc: ; "'Graham Klyne'" Sent: Monday, November 05, 2012 9:29 PM > > On 11/1/12 11:10 AM, t.petch wrote: > > ----- Original Message ----- From: "Peter Saint-Andre" > > To: Cc: "'Graham > > Klyne'" Sent: Monday, October 29, 2012 2:47 PM > >> > > I do think it would be helpful to show how various protocol > identifiers (for email, SIP, XMPP, etc.) can be translated to 'acct' > URIs, similar to what we did in section 4 of > draft-saintandre-sip-xmpp-core: > > http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-02#section-4 > > I'm not sure if that belongs in the acct-uri spec, but it might be > helpful to document somewhere (e.g., on a wiki page). Just to make it easy to see, the table is Table 1: Allowed and disallowed characters +---+----------------------------------+ | SIP/SIPS CHARACTERS | +---+----------------------------------+ | A | ! $ &'()*+,-./ ; = ? _ ~ | | D | "# % : < > @[\]^ `{|} | +---+----------------------------------+ | IM/PRES CHARACTERS | +---+----------------------------------+ | A | ! #$%&' *+ - / = ? ^_`{|}~ | | D | " () , . :;< > @[\] | +---+----------------------------------+ | XMPP CHARACTERS | +---+----------------------------------+ | A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ | | D | " &' /: < > @ | +---+----------------------------------+ which may be helpful, but only because what has gone before is so amazingly unhelpful - standards making should result in a standard, not four different ways of saying the same thing:-( We have an excellent specification in RFC5321 which the author of RFC6068 had the wisdom not to try and improve on. The point I was originally making, a bit coyly, was we need a very good reason to come up with something different from those two, those being the most widely visible. Or else fall back on RFC3986 (and yes, I have seen colons used with passwords and yes, it is an abysmal idea). Tom Petch > Peter > > Peter Saint-Andre > https://stpeter.im/ > From sm@elandsys.com Fri Nov 9 11:38: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 E8A2521F853D for ; Fri, 9 Nov 2012 11:38:14 -0800 (PST) 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 8vPMQW-Ao3e2 for ; Fri, 9 Nov 2012 11:38:14 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2A921F8536 for ; Fri, 9 Nov 2012 11:38:14 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.152.230]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qA9Jc2f4006398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Nov 2012 11:38:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352489893; bh=5bmNpT8Hal1niV/aU/76WhX9OBBbobiOuhnD87OynNo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=uoYYOGRf/t1Zq47yW5ML/kk8HESv0pe+gckTA/3QeumuomaIIf7gPMZqg0dvVLuGg 28uE3vK4CJHANPjbZqSw8fFoTb+YVNOVfGNfHK5FY1jXvyog+DktDlUPOyy6NVAdQ9 roS5/cz1dgHPX+xYIhyDjAXnJA8qKvHFhNC9/vQY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1352489893; i=@elandsys.com; bh=5bmNpT8Hal1niV/aU/76WhX9OBBbobiOuhnD87OynNo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=4cKe0QUJmymdypW/Crrnz8ilzkj5/gDo66UJacaFWvg1uKktFZjf3SWr6oXIUxnj8 ABo+qvXF0FhSWiC/3HFI3kT/ObYSTcgwbmxdmtAfeAM0X9Thewxk0x1bD4rviuRdgm /Ip59lukKElWPqHaTGYm/KcaPyTFI8VoDo47Fcng= Message-Id: <6.2.5.6.2.20121109111809.0bf25bb8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 09 Nov 2012 11:37:32 -0800 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <0D79787962F6AE4B84B2CC41FC957D0B18C9CC85@abn-exch1b.green. sophos> References: <509C12D8.3090208@dcrocker.net> <0D79787962F6AE4B84B2CC41FC957D0B18C9CC85@abn-exch1b.green.sophos> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] SPAM is IETF-s largest failure (off-topic) 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, 09 Nov 2012 19:38:15 -0000 Hello, During the Monday Apps Area meeting there were comments about mail traffic on apps-discuss. Nobody has complained about this thread yet. I suggest following on the topic of "SPAM is IETF-s largest failure" on the asrg@irtf.org mailing list. Thanks, S. Moonesamy From vesely@tana.it Fri Nov 9 16:53: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 C167921F842E for ; Fri, 9 Nov 2012 16:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 UGcrPP7r0w1N for ; Fri, 9 Nov 2012 16:53:41 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5885C21F8510 for ; Fri, 9 Nov 2012 16:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1352508816; bh=rb6I10VcWSerIC6SGsxMSqMH7YW63WYCRSFSpEQ3SDc=; l=792; h=Date:From:To:References:In-Reply-To; b=gmUjqTR0QughdjhaZOMJ8iAukIdcMOZxgtN0tHUMQSj+wSPiR+nikMd391Cwp3Llg zVhpmLmIaVNHR0cGRTS1f7OEWBKFt5jFxJmAydAS9QeMo3lGavRKvE99G//IbNZtNR pjI04EQ2LQnZFL9M/OtETVeyUkvaevQv4rg6LxdQ= Received: from [172.16.66.109] ([70.158.103.10]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 10 Nov 2012 01:53:35 +0100 id 00000000005DC035.00000000509DA58F.00000F58 Message-ID: <509DA58D.7070703@tana.it> Date: Fri, 09 Nov 2012 19:53:33 -0500 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] SPAM is IETF-s largest failure 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, 10 Nov 2012 00:53:41 -0000 On Thu 08/Nov/2012 13:22:35 -0500 Phillip Hallam-Baker wrote: > > Spam is essentially a problem of costs, the cost to the sender is much > less than the benefit to the sender and the sender does not care about > the cost they impose on the recipients. But introducing additional costs > into the system does not eliminate the problem, it merely changes the > type of spam. Couldn't we find a better term than "costs", please? That's a relic of the industrial revolution era, and we may consider it obsolete. (Also recall some comments at the plenary). -- I'll buy you a diamond ring my friend if it makes you feel alright I'll get you anything my friend if it makes you feel alright 'Cause I don't care too much for money, money can't buy me love Lennon–McCartney, 1964 From michael_b_jones@hotmail.com Sun Nov 11 12:58: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 F182621F84C8 for ; Sun, 11 Nov 2012 12:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, GB_ABOUTYOU=0.5, 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 jzKUqee7By-S for ; Sun, 11 Nov 2012 12:58:58 -0800 (PST) Received: from bay0-omc3-s26.bay0.hotmail.com (bay0-omc3-s26.bay0.hotmail.com [65.54.190.164]) by ietfa.amsl.com (Postfix) with ESMTP id AF1C821F8499 for ; Sun, 11 Nov 2012 12:58:58 -0800 (PST) Received: from BAY171-W95 ([65.54.190.189]) by bay0-omc3-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Nov 2012 12:58:57 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_9a915ceb-d45f-409c-981c-5e473bb486a3_" X-Originating-IP: [50.47.91.23] From: Michael Jones To: Date: Sun, 11 Nov 2012 12:58:57 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2012 20:58:57.0980 (UTC) FILETIME=[5E3FC7C0:01CDC04F] Subject: Re: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 11 Nov 2012 20:59:00 -0000 --_9a915ceb-d45f-409c-981c-5e473bb486a3_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Blaine=2C =20 Thanks for writing. =20 The problem with SRV records is they aren=92t ubiquitously accessible. Some Web development platforms don=92t support direct DNS queries. For instance=2C I don=92t believe that there are JavaScript functions available for doing DNS queries. Likewise=2C I=92ve been told th= at some web hosting companies don=92t expose a function to write SRV record va= lues. =20 Here=92s my thoughts about your tumblr example. The root of the problem you=92re describing is that the party in control of the subdoma= in may not be the same as the party in charge of the domain. (An amusing related anecdote told to me is that early in the web=2C an enterprising MIT student registered his machine with the name =93www=94. Apparently for years www.m= it.edu went to his personal machine=2C whereas web.mit.edu was the university web site. Eventually the administration decided to assert its control over the name www.mit.edu.) =20 Here=92s reasons I don=92t think your tumblr example is that damning: 1. =20 Most domains do not allow creation of arbitrary subdomains by third parties. 2. =20 If example.com is using SWD and has a web site=2C it will normally have an https://example.com/.well-known/simple-web-discovery endpoint and so it won=92t matter whether there=92s also an endpoint at htt= ps://simple-web-discovery.example.com/.well-known/simple-web-discovery (unless example.com is down or unreachable). 3. =20 Unless the party in control of the content at simple-web-discovery.example.com also has the authority to install a TLS certificate for https://simple-web-discovery.example.com/=2C an SWD query would fail. 4. =20 When a site decides to start using SWD=2C if it doesn=92t already control the subdomain=2C it can reclaim it at that time. =20 All that said=2C I do appreciate you pointing this out so we can be conscious of the possible attack. =20 I understand your suggestion to always do the lookup at the subdomain. The practical problem with that is that it effectively mandates purchasing a second TLS certificate to implement SWD. That=92s a big adoption blocker. It=92s fine as a workaround when necessary=2C but shouldn=92t be the default. =20 =20 Best wishes=2C =20 -- Mike =20 From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Blaine Cook Sent: Monday=2C November 05=2C 2012 11:56 AM To: Paul E. Jones Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments =20 To continue with the "simplicity is the goal" theme=2C if it turns out that people are happier to use DNS records for discovering the Webfinger/SWD endpoint=2C then the host-meta lookup should = be dropped entirely in favour of DNS lookups (or vice versa). =20 If we're going to go the DNS route (and require it as a mandatory fallback)=2C then it seems like following normal DNS semantics an= d making the lookup behave like MX or SRV records would be sensible. Rather t= han having a fallback=2C just have all lookups go immediately to the agreed-upo= n domain prefix / SRV record (I would express a slight bias towards SRV recor= d=2C simply because the mechanism as specified is trivially vulnerable to attack= on numerous existing platforms. E.g.=2C http://simple-web-discovery.tumblr.com= / ) =20 b. =20 On 5 November 2012 13:44=2C Paul E. Jones wrote: FYI From: Mike Jones Sent: Mon Nov 05 07:55:14 EST 2012 To: "Paul E. Jones" Subject: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments =20 Paul=2C could you do me a favor and forward this note to the apps-discuss list so people have context on why I updated SWD? For some reason=2C the list doesn=92t appear to be accepting my message. =20 =20 =20 Thanks=2C =20 -- Mike =20 From: Mike Jones=20 Sent: Sunday=2C November 04=2C 2012 9:21 PM To: apps-discuss@ietf.org Subject: Simple Web Discovery (SWD) Enabling Hosted Deployments =20 I=92ve updated the Simple Web Discovery (SWD) specification to incorporate = a means of performing discovery on domains for which it may not be possible t= o create a .well-known endpoint. This can often be the case for hosted domains=2C where it is common for e-mail to be provided but no web server.= =20 This solution was developed in discussions by the OpenID Connect working group. =20 This draft is being published now to facilitate discussions of the need to enable discovery for hosted domains and possible solutions for doing so at the IETF Applications Area working group meeting at IETF 85 in Atlanta. =20 The updated specification is available at: =B7 =20 http://tools.ietf.org/html/draft-jones-simple-web-discovery-04 =20 Changes made were: =B7 =20 Specified that the SWD server for a domain may be located at the simple-web= -discovery subdomain of the domain and that SWD clients must first try the endpoint at the domai= n and then the endpoint at the subdomain.=20 =B7 =20 Removed the SWD_service_redirect response=2C since redirection can be accomplished by pointing the simple-web-discovery = subdomain to a different location than the domain's host.=20 =B7 =20 Removed mailto: from examples in favor of bare e-mail address syntax.=20 =B7 =20 Specified that SWD servers may also be run on ports other than 443=2C provided they use TLS on those ports. =20 An HTML formatted version is available at: =B7 =20 http://self-issued.info/docs/draft-jones-simple-web-discovery-04.html =20 (This notice was also posted to http://self-issued.info/?p=3D891.) =20 =20 -- Mike = --_9a915ceb-d45f-409c-981c-5e473bb486a3_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Blaine=2C

 = =3B

Thanks for writing.

 = =3B

The problem with SRV records is they aren=92t ubiquito= usly accessible. =3B Some Web development platforms don=92t support direct D= NS queries. =3B For instance=2C I don=92t believe that there are JavaScrip= t functions available for doing DNS queries. =3B Likewise=2C I=92ve been = told that some web hosting companies don=92t expose a function to write SRV record va= lues.

 = =3B

Here=92s my thoughts about your tumblr example. = =3B The root of the problem you=92re describing is that the party in control of the subdoma= in may not be the same as the party in charge of the domain. =3B (An amusing r= elated anecdote told to me is that early in the web=2C an enterprising MIT student registered his machine with the name =93www=94. =3B Apparently for year= s www.mit.edu went to his personal machine=2C whereas web.mit.edu was the university web site. =3B Eventually the administrat= ion decided to assert its control over the name www.mit.edu.)

 = =3B

Here=92s reasons I don=92t think your tumblr example i= s that damning:

1. =3B =3B =3B =3B = =3B Most domains do not al= low creation of arbitrary subdomains by third parties.

2. =3B =3B =3B =3B = =3B If example.com is usin= g SWD and has a web site=2C it will normally have an https://example.com/.well-known/simple-web-discovery<= /font> endpoint and so it won=92t matter whether there=92s also an endpoint at https://simple-web-discovery.example.com/.w= ell-known/simple-web-discovery (unless example.com is down or unreachable).

3. =3B =3B =3B =3B = =3B Unless the party in co= ntrol of the content at simple-web-discovery.example.com also has the authority to install a TLS certificate for https://simple-web-discovery.example.com/=2C an SWD query would fail.

4. =3B =3B =3B =3B = =3B When a site decides to= start using SWD=2C if it doesn=92t already control the subdomain=2C it can reclaim it at that time.<= /p>

 = =3B

All that said=2C I do appreciate you pointing this out= so we can be conscious of the possible attack.

 = =3B

I understand your suggestion to always do the lookup a= t the subdomain. =3B The practical problem with that is that it effectively mandates purchasing a second TLS certificate to implement SWD. =3B That= =92s a big adoption blocker. =3B It=92s fine as a workaround when necessary=2C= but shouldn=92t be the default.

 = =3B

 =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B Best wishes=2C

 =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B -- Mike

 = =3B

From: apps-discuss-bounces@ietf.org [mailt= o:apps-discuss-bounces@ietf.org] On Behalf Of Blaine Cook
Sent: Monday=2C November 05=2C 2012 11:56 AM
To: Paul E. Jones
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enab= ling Hosted Deployments

 =3B

To continue with the "simplicity is t= he goal" theme=2C if it turns out that people are happier to use DNS records for discovering the Webfinger/SWD endpoint=2C then the host-meta lookup should = be dropped entirely in favour of DNS lookups (or vice versa).

 =3B

If we're going to go the DNS route (and req= uire it as a mandatory fallback)=2C then it seems like following normal DNS semantics an= d making the lookup behave like MX or SRV records would be sensible. Rather t= han having a fallback=2C just have all lookups go immediately to the agreed-upo= n domain prefix / SRV record (I would express a slight bias towards SRV recor= d=2C simply because the mechanism as specified is trivially vulnerable to attack= on numerous existing platforms. E.g.=2C http://simple-web-discovery.tumblr.com/ )

 =3B

b.

 =3B

On 5 November 2012 13:44=2C Paul E. Jones &= lt=3Bpaulej@packetizer.c= om>=3B wrote:

FYI

From: Mike Jones <=3BMichael.Jone= s@microsoft.com>=3B
Sent: Mon Nov 05 07:55:14 EST 2012
To: "Paul E. Jones" <=3Bpaulej@packetizer.com&g= t=3B
Subject: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments<= o:p>

 =3B

Paul=2C could you do me a favor and forward this note to the apps-discuss list so people have context on why I updated SWD? =3B For some reason=2C the li= st doesn=92t appear to be accepting my message.

 =3B

 =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B Thanks=2C

 =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B -- Mike

 =3B

From: Mike Jones
Sent: Sunday=2C November 04=2C 2012 9:21 PM
To: apps-discuss@ietf.org
Subject: Simple Web Discovery (SWD) Enabling Hosted Deployments

 =3B

I=92ve updated th= e Simple Web Discovery (SWD) specification to incorporate a means of performing discovery on domains for which it may not be possible t= o create a .well-known endpoint. =3B This can often be the case for hoste= d domains=2C where it is common for e-mail to be provided but no web server.&= nbsp=3B This solution was developed in discussions by the OpenID Connect working group.

 =3B

This draft is bei= ng published now to facilitate discussions of the need to enable discovery for hosted domains and possible solutions for doing so at the IETF Applications Area working group meeting at IETF 85 in Atlanta.

 =3B

The updated= specification is available at:

=B7<= font face=3D"Times New Roman"> =3B =3B =3B =3B =3B = =3B =3B http://tools.ietf.org/html/draft-jones-simple-web-discover= y-04

 =3B

Changes mad= e were:

=B7 =3B =3B =3B =3B =3B =3B =3B Specified that the SWD se= rver for a domain may be located at the simple-web-discovery subdomain of the domain and that SWD clients must first try the endpoint at the domai= n and then the endpoint at the subdomain.

=B7 =3B =3B =3B =3B =3B =3B =3B Removed the SWD_service_redirect response=2C since redirection can be accomplished by pointing the simple-web-discovery subd= omain to a different location than the domain's host.

=B7 =3B =3B =3B =3B =3B =3B =3B Removed mailto: from examples= in favor of bare e-mail address syntax.

=B7 =3B =3B =3B =3B =3B =3B =3B Specified that SWD server= s may also be run on ports other than 443=2C provided they use TLS on those ports.

 =3B

An HTML for= matted version is available at:

=B7<= font face=3D"Times New Roman"> =3B =3B =3B =3B =3B = =3B =3B http://self-issued.info/docs/draft-jones-simple-web= -discovery-04.html

 =3B

(This notice was = also posted to http://self-issue= d.info/?p=3D891.= )

 =3B

 =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B -- Mike

= --_9a915ceb-d45f-409c-981c-5e473bb486a3_-- From paf@frobbit.se Sun Nov 11 21:55: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 263D321F851B for ; Sun, 11 Nov 2012 21:55:11 -0800 (PST) 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 hbdA80-QQr2V for ; Sun, 11 Nov 2012 21:55:09 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9E321F8512 for ; Sun, 11 Nov 2012 21:55:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 14FD8177ABEB3; Mon, 12 Nov 2012 06:55:05 +0100 (CET) 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 7zs7-Ngd3XkP; Mon, 12 Nov 2012 06:55:04 +0100 (CET) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 7F06C177ABEA9; Mon, 12 Nov 2012 06:55:03 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 12 Nov 2012 06:55:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> References: To: Michael Jones X-Mailer: Apple Mail (2.1499) Cc: IAB IAB , apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 05:55:11 -0000 On 11 nov 2012, at 21:58, Michael Jones = wrote: > The problem with SRV records is they aren=92t ubiquitously accessible. = Some Web development platforms don=92t support direct DNS queries. For = instance, I don=92t believe that there are JavaScript functions = available for doing DNS queries. Likewise, I=92ve been told that some = web hosting companies don=92t expose a function to write SRV record = values. It is about time to: a) Stop referring to myths b) Fix the broken software in the cases there is SRV records (and similar new RR types added now more than 10 years ago) = MUST be possible to be used. It is time IETF says STOP to these arguments for non-evolution of the = protocols and standards IETF develop. Patrik F=E4ltstr=F6m From michael_b_jones@hotmail.com Sun Nov 11 22:08:55 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 B053721F8532 for ; Sun, 11 Nov 2012 22:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_20=-0.74, 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 6SwBVdZhZQcL for ; Sun, 11 Nov 2012 22:08:55 -0800 (PST) Received: from bay0-omc3-s23.bay0.hotmail.com (bay0-omc3-s23.bay0.hotmail.com [65.54.190.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2240621F84C8 for ; Sun, 11 Nov 2012 22:08:55 -0800 (PST) Received: from BAY171-W25 ([65.54.190.189]) by bay0-omc3-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Nov 2012 22:08:54 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_7c2c90e8-9cc4-4846-927b-08514b983bb5_" X-Originating-IP: [50.47.91.23] From: Michael Jones To: Date: Sun, 11 Nov 2012 22:08:54 -0800 Importance: Normal In-Reply-To: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> References: , <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Nov 2012 06:08:54.0777 (UTC) FILETIME=[31DF6E90:01CDC09C] Cc: iab@iab.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 06:08:55 -0000 --_7c2c90e8-9cc4-4846-927b-08514b983bb5_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Patrik=2C I don't believe that this is a myth. For instance=2C can you = point me to the API I would use from JavaScript to query for a SRV record? = And is it available on all the modern browsers? If it's not=2C can you de= monstrate agreement of all the major browser vendors to implement it and gi= ve me data on the expected time for deployment of the new API to reach 90+%= penetration in the installed browser base? The goal for the discovery spec= s is enabling ubiquitous deployment=2C where discovery is needed. Saying "= fix the software" effectively means that the problem will not be solved for= many many years. (No=2C I don't love the domain prefix solution either. I= t's just the least bad of those that have been explored that are actually w= orkable today. If you have another solution that's ubiquitously deployable= across all widely used web development tools=2C by all means=2C please giv= e us a better alternative. I put this one out there hoping someone would c= ome up with a better one!) Best wishes=2C-- Mike > Subject: Re: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling= Hosted Deployments > From: paf@frobbit.se > Date: Mon=2C 12 Nov 2012 06:55:01 +0100 > CC: apps-discuss@ietf.org=3B iab@iab.org > To: michael_b_jones@hotmail.com >=20 >=20 > On 11 nov 2012=2C at 21:58=2C Michael Jones = wrote: >=20 > > The problem with SRV records is they aren=92t ubiquitously accessible. = Some Web development platforms don=92t support direct DNS queries. For in= stance=2C I don=92t believe that there are JavaScript functions available f= or doing DNS queries. Likewise=2C I=92ve been told that some web hosting c= ompanies don=92t expose a function to write SRV record values. >=20 > It is about time to: >=20 > a) Stop referring to myths >=20 > b) Fix the broken software in the cases there is >=20 > SRV records (and similar new RR types added now more than 10 years ago) M= UST be possible to be used. >=20 > It is time IETF says STOP to these arguments for non-evolution of the pro= tocols and standards IETF develop. >=20 > Patrik F=E4ltstr=F6m >=20 >=20 = --_7c2c90e8-9cc4-4846-927b-08514b983bb5_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Patrik=2C
 =3B
I don't believe that this is a myth. =3B Fo= r instance=2C can you point me to the API I would use from JavaScript to qu= ery =3Bfor a SRV record? =3B And is it available on all the modern = browsers? =3B If it's not=2C can you demonstrate agreement of all the m= ajor browser vendors to implement it and give me data on the expected time = for deployment of the new API to reach 90+% penetration in the installed br= owser base?
 =3B
The goal for the discovery specs is enabling&nbs= p=3Bubiquitous deployment=2C where discovery is needed. =3B =3BSayi= ng "fix the software" =3Beffectively means that the problem will not be= solved for many =3Bmany years.
 =3B
(No=2C I don't love the = domain prefix solution either. =3B It's just the least bad of those tha= t have been explored that are actually workable today. =3B If you have = another solution that's =3Bubiquitously deployable across all widely us= ed web development tools=2C by all means=2C please give us a better alterna= tive. =3B I put this one out there hoping someone would come up with a = better one!)
 =3B
Best wishes=2C
-- Mike
 =3B
<= div id=3D"SkyDrivePlaceholder">
>=3B Subject: Re: [apps-discuss] Fwd= : FW: Simple Web Discovery (SWD) Enabling Hosted Deployments
>=3B From= : paf@frobbit.se
>=3B Date: Mon=2C 12 Nov 2012 06:55:01 +0100
>= =3B CC: apps-discuss@ietf.org=3B iab@iab.org
>=3B To: michael_b_jones@= hotmail.com
>=3B
>=3B
>=3B On 11 nov 2012=2C at 21:58=2C M= ichael Jones <=3Bmichael_b_jones@hotmail.com>=3B wrote:
>=3B
&= gt=3B >=3B The problem with SRV records is they aren=92t ubiquitously acc= essible. Some Web development platforms don=92t support direct DNS queries= . For instance=2C I don=92t believe that there are JavaScript functions av= ailable for doing DNS queries. Likewise=2C I=92ve been told that some web = hosting companies don=92t expose a function to write SRV record values.
= >=3B
>=3B It is about time to:
>=3B
>=3B a) Stop referri= ng to myths
>=3B
>=3B b) Fix the broken software in the cases th= ere is
>=3B
>=3B SRV records (and similar new RR types added now= more than 10 years ago) MUST be possible to be used.
>=3B
>=3B = It is time IETF says STOP to these arguments for non-evolution of the proto= cols and standards IETF develop.
>=3B
>=3B Patrik F=E4ltstr= =F6m
>=3B
>=3B
= --_7c2c90e8-9cc4-4846-927b-08514b983bb5_-- From paf@frobbit.se Sun Nov 11 22:32: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 51C0221E8030 for ; Sun, 11 Nov 2012 22:32:31 -0800 (PST) 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 NLwLhVUACZOE for ; Sun, 11 Nov 2012 22:32:30 -0800 (PST) Received: from srv01.frobbit.se (ns2.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 5A47221F84C4 for ; Sun, 11 Nov 2012 22:32:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id ED712177AC5EB; Mon, 12 Nov 2012 07:32:28 +0100 (CET) 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 S6Ktmh8JfdZN; Mon, 12 Nov 2012 07:32:28 +0100 (CET) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id BE44F177AC5E4; Mon, 12 Nov 2012 07:32:28 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 12 Nov 2012 07:32:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <72CAE7E4-B33D-49A9-A835-63583C750579@frobbit.se> References: , <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> To: Michael Jones X-Mailer: Apple Mail (2.1499) Cc: iab@iab.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 06:32:31 -0000 On 12 nov 2012, at 07:08, Michael Jones = wrote: > I don't believe that this is a myth. For instance, can you point me = to the API I would use from JavaScript to query for a SRV record? First, this is definitely not a complaint on you or your view. This what = I write is a generic statement that I think IETF should take on, and = resolve. Java Script is one of the things that can be fixed. And my view is that = that will be fixed when the browsers do start to use SRV records in = their resolution chain. > And is it available on all the modern browsers? Available on browsers? What do you mean? Of course browsers are not = looking up SRV records as that is not part of the resolution mechanism = to use for resolution of HTTP scheme URIs. But also see the discussions around future versions of HTTP where new = algorithms are necessary regardless of what happens, and it would be sad = if not more modern DNS resolution is included in that upgrade. Patrik From michael_b_jones@hotmail.com Sun Nov 11 22:39: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 0B73821F852E for ; Sun, 11 Nov 2012 22:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.482, 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 XJ-0cnKl8E28 for ; Sun, 11 Nov 2012 22:39:35 -0800 (PST) Received: from bay0-omc3-s10.bay0.hotmail.com (bay0-omc3-s10.bay0.hotmail.com [65.54.190.148]) by ietfa.amsl.com (Postfix) with ESMTP id 3682C21F852C for ; Sun, 11 Nov 2012 22:39:35 -0800 (PST) Received: from BAY171-W121 ([65.54.190.188]) by bay0-omc3-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Nov 2012 22:39:31 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_37d58856-126f-4f91-beab-ad3b9448bcd3_" X-Originating-IP: [50.47.91.23] From: Michael Jones To: Date: Sun, 11 Nov 2012 22:39:31 -0800 Importance: Normal In-Reply-To: <72CAE7E4-B33D-49A9-A835-63583C750579@frobbit.se> References: , <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> , <72CAE7E4-B33D-49A9-A835-63583C750579@frobbit.se> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Nov 2012 06:39:31.0898 (UTC) FILETIME=[78E1D9A0:01CDC0A0] Cc: iab@iab.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 06:39:36 -0000 --_37d58856-126f-4f91-beab-ad3b9448bcd3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I completely agree with you that the IETF should take this on so that it ev= entually gets fixed. And I agree that in the case of JavaScript=2C the opp= ortune time window in which to do it is probably when HTTP 2.0 is deployed.= =20 Best wishes=2C-- Mike> Subject: Re: [apps-discuss] Fwd: FW: Simple Web Dis= covery (SWD) Enabling Hosted Deployments > From: paf@frobbit.se > Date: Mon=2C 12 Nov 2012 07:32:27 +0100 > CC: apps-discuss@ietf.org=3B iab@iab.org > To: michael_b_jones@hotmail.com >=20 > On 12 nov 2012=2C at 07:08=2C Michael Jones = wrote: >=20 > > I don't believe that this is a myth. For instance=2C can you point me = to the API I would use from JavaScript to query for a SRV record? >=20 > First=2C this is definitely not a complaint on you or your view. This wha= t I write is a generic statement that I think IETF should take on=2C and re= solve. >=20 > Java Script is one of the things that can be fixed. And my view is that t= hat will be fixed when the browsers do start to use SRV records in their re= solution chain. >=20 > > And is it available on all the modern browsers? >=20 > Available on browsers? What do you mean? Of course browsers are not looki= ng up SRV records as that is not part of the resolution mechanism to use fo= r resolution of HTTP scheme URIs. >=20 > But also see the discussions around future versions of HTTP where new alg= orithms are necessary regardless of what happens=2C and it would be sad if = not more modern DNS resolution is included in that upgrade. >=20 > Patrik >=20 = --_37d58856-126f-4f91-beab-ad3b9448bcd3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I completely agree with you that the IETF should take this on so that it ev= entually gets fixed. =3B And I agree that in the case of =3BJavaScr= ipt=2C the opportune time window in which to do it is probably when HTTP 2.= 0 is deployed.
 =3B

 =3BBest wishes=2C
-- Mike
>=3B Subject: Re: [apps-discuss] F= wd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments
>=3B Fr= om: paf@frobbit.se
>=3B Date: Mon=2C 12 Nov 2012 07:32:27 +0100
>= =3B CC: apps-discuss@ietf.org=3B iab@iab.org
>=3B To: michael_b_jones@= hotmail.com
>=3B
>=3B On 12 nov 2012=2C at 07:08=2C Michael Jone= s <=3Bmichael_b_jones@hotmail.com>=3B wrote:
>=3B
>=3B >= =3B I don't believe that this is a myth. For instance=2C can you point me = to the API I would use from JavaScript to query for a SRV record?
>=3B=
>=3B First=2C this is definitely not a complaint on you or your view= . This what I write is a generic statement that I think IETF should take on= =2C and resolve.
>=3B
>=3B Java Script is one of the things that= can be fixed. And my view is that that will be fixed when the browsers do = start to use SRV records in their resolution chain.
>=3B
>=3B &g= t=3B And is it available on all the modern browsers?
>=3B
>=3B A= vailable on browsers? What do you mean? Of course browsers are not looking = up SRV records as that is not part of the resolution mechanism to use for r= esolution of HTTP scheme URIs.
>=3B
>=3B But also see the discus= sions around future versions of HTTP where new algorithms are necessary reg= ardless of what happens=2C and it would be sad if not more modern DNS resol= ution is included in that upgrade.
>=3B
>=3B Patrik
>=3B=
= --_37d58856-126f-4f91-beab-ad3b9448bcd3_-- From ned.freed@mrochek.com Mon Nov 12 00:10: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 52B1F21F84FA for ; Mon, 12 Nov 2012 00:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=-0.094, 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 8p8RKcIisJvA for ; Mon, 12 Nov 2012 00:09:59 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B4C8E21F8487 for ; Mon, 12 Nov 2012 00:09:59 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMIKG0V2HC001HD5@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 12 Nov 2012 00:04:54 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=windows-1252 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMGB2WUMLC00008S@mauve.mrochek.com>; Mon, 12 Nov 2012 00:04:48 -0800 (PST) Message-id: <01OMIKFX9UQ400008S@mauve.mrochek.com> Date: Mon, 12 Nov 2012 00:03:08 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 12 Nov 2012 06:55:01 +0100" <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> References: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> To: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= Cc: IAB IAB , apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 08:10:00 -0000 > On 11 nov 2012, at 21:58, Michael Jones wrote: > > The problem with SRV records is they aren’t ubiquitously accessible. Some Web development platforms don’t support direct DNS queries. For instance, I don’t believe that there are JavaScript functions available for doing DNS queries. Likewise, I’ve been told that some web hosting companies don’t expose a function to write SRV record values. > It is about time to: > a) Stop referring to myths > b) Fix the broken software in the cases there is > SRV records (and similar new RR types added now more than 10 years ago) MUST be possible to be used. > It is time IETF says STOP to these arguments for non-evolution of the protocols and standards IETF develop. I emphatically agree with every point you make here. It's one thing for individual vendors to make consessions to the failure of other vendors to do things correctly; it's quite another for standards bodies to take (or not take) actions that harm the evolution of the Internet. Ned From paul.hoffman@vpnc.org Mon Nov 12 09:08: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 3697921F85ED; Mon, 12 Nov 2012 09:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 7Sg-e4geiZGF; Mon, 12 Nov 2012 09:07:59 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A761221F85E6; Mon, 12 Nov 2012 09:07:59 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qACH7no3029314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Nov 2012 10:07:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> Date: Mon, 12 Nov 2012 09:07:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> References: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> To: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1499) Cc: IAB , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 17:08:00 -0000 On Nov 11, 2012, at 9:55 PM, Patrik F=E4ltstr=F6m = wrote: >=20 > On 11 nov 2012, at 21:58, Michael Jones = wrote: >=20 >> The problem with SRV records is they aren=92t ubiquitously = accessible. Some Web development platforms don=92t support direct DNS = queries. For instance, I don=92t believe that there are JavaScript = functions available for doing DNS queries. Likewise, I=92ve been told = that some web hosting companies don=92t expose a function to write SRV = record values. >=20 > It is about time to: >=20 > a) Stop referring to myths >=20 > b) Fix the broken software in the cases there is I repeat the question others asked: which "myths" are you referring to? In specific, a lot of web development is done in JavaScript. In current = JavaScript, there is no way to send DNS queries, I believe. In fact, for = security reasons, I believe all you can do is send HTTP queries. You = might consider this to be "broken software", but I might consider = allowing insecure code pushed into my (browser) application to send and = receive arbitrary messages on any transport and port to be a security = issue. I note that you Cc'd the IAB on this. Is the IAB considering requiring = applications that include active code such as JavaScript to be able to = do DNS? > SRV records (and similar new RR types added now more than 10 years = ago) MUST be possible to be used. Everywhere? Or only in systems that can already do their own DNS? > It is time IETF says STOP to these arguments for non-evolution of the = protocols and standards IETF develop. Yes, and hyperbole is killing the Internet. :-) --Paul Hoffman= From romeda@gmail.com Mon Nov 12 09:14: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 D1BE121F8654 for ; Mon, 12 Nov 2012 09:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.415 X-Spam-Level: X-Spam-Status: No, score=-103.415 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, 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 EueQ0Adf57v0 for ; Mon, 12 Nov 2012 09:14:53 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 04A4221F8630 for ; Mon, 12 Nov 2012 09:14:52 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1134636pbc.31 for ; Mon, 12 Nov 2012 09:14:52 -0800 (PST) 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=KtIh3ML5WuKp4oLLJBOZ1uTFkMGiuTRd6WqcAuiEre8=; b=WaBIjIOx5nI0XPJlGMrKRhfUkJX4fP8zr8bRjrjJI4sv+dcjhE3MXwQbcLKJaIxTz+ VnITz8ZVf1EdNk8FvjXNHChZ6PKxx/8VNvUYLqJRwJL641lfpg5I33qKzK0YFLd8eQUR 5htVXWBX8jkegz4vnSLoFEMmMokWZuIuc53rNqcUBtZseoe3Xl4+wrCvzUi+jndjp89R m8d0KbpYh/ufFXGf/5Ps/dy0vTVoIBJV/P48bVQvFi8kBeQ3pQJhD1q1m/v7y+GTMLax 83PyuMtp9HT2ikGNBNBxcXwZERLHLGUnXEBzpSRW66MLnrkMi/3gbNy6i328VAZS+F/6 pbHg== Received: by 10.68.191.229 with SMTP id hb5mr17121204pbc.57.1352740492820; Mon, 12 Nov 2012 09:14:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.67.2.101 with HTTP; Mon, 12 Nov 2012 09:14:32 -0800 (PST) In-Reply-To: <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> References: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> From: Blaine Cook Date: Mon, 12 Nov 2012 17:14:32 +0000 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=e89a8ff1c3a88c401004ce4f70da Cc: IAB , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 17:14:54 -0000 --e89a8ff1c3a88c401004ce4f70da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ... if the thing we're trying to guard against is environments where individuals can't deploy Webfinger / SWD because of constraints that are beyond their control, then subdomains aren't going to help, since beyond the blatant security issues, there's the fact that many people and groups aren't going to be able to setup sub-domains, and if they can, it's going to be harder than just using a document under /.well-known/ at their top-level domain. If we're making compromises, let's make compromises that actually achieve the goals we're trying to achieve, please! b. On 12 November 2012 17:07, Paul Hoffman wrote: > On Nov 11, 2012, at 9:55 PM, Patrik F=C3=A4ltstr=C3=B6m = wrote: > > > > > On 11 nov 2012, at 21:58, Michael Jones > wrote: > > > >> The problem with SRV records is they aren=E2=80=99t ubiquitously acces= sible. > Some Web development platforms don=E2=80=99t support direct DNS queries.= For > instance, I don=E2=80=99t believe that there are JavaScript functions ava= ilable for > doing DNS queries. Likewise, I=E2=80=99ve been told that some web hostin= g > companies don=E2=80=99t expose a function to write SRV record values. > > > > It is about time to: > > > > a) Stop referring to myths > > > > b) Fix the broken software in the cases there is > > I repeat the question others asked: which "myths" are you referring to? > > In specific, a lot of web development is done in JavaScript. In current > JavaScript, there is no way to send DNS queries, I believe. In fact, for > security reasons, I believe all you can do is send HTTP queries. You migh= t > consider this to be "broken software", but I might consider allowing > insecure code pushed into my (browser) application to send and receive > arbitrary messages on any transport and port to be a security issue. > > I note that you Cc'd the IAB on this. Is the IAB considering requiring > applications that include active code such as JavaScript to be able to do > DNS? > > > SRV records (and similar new RR types added now more than 10 years ago) > MUST be possible to be used. > > Everywhere? Or only in systems that can already do their own DNS? > > > It is time IETF says STOP to these arguments for non-evolution of the > protocols and standards IETF develop. > > Yes, and hyperbole is killing the Internet. :-) > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --e89a8ff1c3a88c401004ce4f70da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ... if the thing we're trying to guard against is environments where in= dividuals can't deploy Webfinger / SWD because of constraints that are = beyond their control, then subdomains aren't going to help, since beyon= d the blatant security issues, there's the fact that many people and gr= oups aren't going to be able to setup sub-domains, and if they can, it&= #39;s going to be harder than just using a document under /.well-known/ at = their top-level domain.

If we're making compromises, let's make compromises = that actually achieve the goals we're trying to achieve, please!
<= div>
b.


On 12 November 2012 17:07, Paul Hoffman <paul.hoffman@vpnc.org>= wrote:
On Nov 11, 2012, at 9:55 PM, Patrik F=C3=A4ltstr=C3=B6m &= lt;paf@frobbit.se> wrote:

>
> On 11 nov 2012, at 21:58, Michael Jones <michael_b_jones@hotmail.com> wrote:
>
>> The problem with SRV records is they aren=E2=80=99t ubiquitously a= ccessible. =C2=A0Some Web development platforms don=E2=80=99t support direc= t DNS queries. =C2=A0For instance, I don=E2=80=99t believe that there are J= avaScript functions available for doing DNS queries. =C2=A0Likewise, I=E2= =80=99ve been told that some web hosting companies don=E2=80=99t expose a f= unction to write SRV record values.
>
> It is about time to:
>
> a) Stop referring to myths
>
> b) Fix the broken software in the cases there is

I repeat the question others asked: which "myths" are you r= eferring to?

In specific, a lot of web development is done in JavaScript. In current Jav= aScript, there is no way to send DNS queries, I believe. In fact, for secur= ity reasons, I believe all you can do is send HTTP queries. You might consi= der this to be "broken software", but I might consider allowing i= nsecure code pushed into my (browser) application to send and receive arbit= rary messages on any transport and port to be a security issue.

I note that you Cc'd the IAB on this. Is the IAB considering requiring = applications that include active code such as JavaScript to be able to do D= NS?

> SRV records (and similar new RR types added now more than 10 years ago= ) MUST be possible to be used.

Everywhere? Or only in systems that can already do their own DNS?

> It is time IETF says STOP to these arguments for non-evolution of the = protocols and standards IETF develop.

Yes, and hyperbole is killing the Internet. :-)

--Paul Hoffman
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--e89a8ff1c3a88c401004ce4f70da-- From jasnell@gmail.com Mon Nov 12 09:15: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 15DF921F8652 for ; Mon, 12 Nov 2012 09:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[AWL=0.297, 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 pEDdfpdOQzo7 for ; Mon, 12 Nov 2012 09:15:51 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD8621F85D5 for ; Mon, 12 Nov 2012 09:15:50 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so10400374iec.31 for ; Mon, 12 Nov 2012 09:15:50 -0800 (PST) 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=6Q83plbLB7rJzJiZ3woVpI6Dtf6lDygc0IXrBSQR7YU=; b=fbdE/+UCanaFZqEr5pBe8O4fTjRafwIDSbre5YMt7uiqw6DEWuKM3UVFHKWfDyDMj6 nCdEjwQ0PLakzjvSlQVHpFYEbQoa2JRrwVJzjpeKgfg4jyyvC6VeOWqT/ViqfDTes79d xwhEmH3sGvx9WUfJTkEr2DaAG8M2Yqf+CjKgffqu5dPxv55smhXwJBRm4YrsccMdzT2g 20cs4OfLo0N559/P/HKGTzaQMeRyBBxT2VwAUrlWbHwOtabHet03WXUYUuQP3SdnLX0y lvAhOdTPJCLadFJx/hNK821LFCE8LC5mkWm48EJXvNWuHrNei51k7ae77io7aNlnAxNx IXCA== Received: by 10.50.182.133 with SMTP id ee5mr8702208igc.54.1352740549920; Mon, 12 Nov 2012 09:15:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.225 with HTTP; Mon, 12 Nov 2012 09:15:29 -0800 (PST) In-Reply-To: <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> References: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> From: James M Snell Date: Mon, 12 Nov 2012 09:15:29 -0800 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=14dae9340adbf3884304ce4f7385 Cc: IAB , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 17:15:52 -0000 --14dae9340adbf3884304ce4f7385 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Nov 12, 2012 at 9:07 AM, Paul Hoffman wrote= : > On Nov 11, 2012, at 9:55 PM, Patrik F=C3=A4ltstr=C3=B6m = wrote: > > > > > On 11 nov 2012, at 21:58, Michael Jones > wrote: > > > >> The problem with SRV records is they aren=E2=80=99t ubiquitously acces= sible. > Some Web development platforms don=E2=80=99t support direct DNS queries.= For > instance, I don=E2=80=99t believe that there are JavaScript functions ava= ilable for > doing DNS queries. Likewise, I=E2=80=99ve been told that some web hostin= g > companies don=E2=80=99t expose a function to write SRV record values. > > > > It is about time to: > > > > a) Stop referring to myths > > > > b) Fix the broken software in the cases there is > > I repeat the question others asked: which "myths" are you referring to? > > In specific, a lot of web development is done in JavaScript. In current > JavaScript, there is no way to send DNS queries, I believe. In fact, for > security reasons, I believe all you can do is send HTTP queries. You migh= t > consider this to be "broken software", but I might consider allowing > insecure code pushed into my (browser) application to send and receive > arbitrary messages on any transport and port to be a security issue. > > Indeed. There are very good reasons not to allow this...that said, however, a simplified "Discovery API" of sorts, based around DNS, could be defined and provided to javascript developers if we could get the browser developers on board. HTTP/2 could very well provide a strong motivation to do so given that srv-based upgrade discovery is one of the options on that table. It does not have to be code sending "arbitrary messages on any transport" ... it could be something as simple as.... Discovery.inspect(" example.org", "srv.service.type", callback) where any discovered matching srv records are passed to the callback. Fairly simple and straightforward and would not introduce any significant new security risks that do not already currently exist. All that would be necessary to make it happen is browser-vendor support and a relatively simple, well-defined interface. Certainly not impossible. - James > I note that you Cc'd the IAB on this. Is the IAB considering requiring > applications that include active code such as JavaScript to be able to do > DNS? > > > SRV records (and similar new RR types added now more than 10 years ago) > MUST be possible to be used. > > Everywhere? Or only in systems that can already do their own DNS? > > > > It is time IETF says STOP to these arguments for non-evolution of the > protocols and standards IETF develop. > > Yes, and hyperbole is killing the Internet. :-) > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --14dae9340adbf3884304ce4f7385 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Mon, Nov 12, 2012 at 9:07 AM, Paul Ho= ffman <paul.hoffman@vpnc.org> wrote:
On Nov 11, 2012, at 9:55 P= M, Patrik F=C3=A4ltstr=C3=B6m <paf@fro= bbit.se> wrote:

>
> On 11 nov 2012, at 21:58, Michael Jones <michael_b_jones@hotmail.com> wrote:
>
>> The problem with SRV records is they aren=E2=80=99t ubiquitously a= ccessible. =C2=A0Some Web development platforms don=E2=80=99t support direc= t DNS queries. =C2=A0For instance, I don=E2=80=99t believe that there are J= avaScript functions available for doing DNS queries. =C2=A0Likewise, I=E2= =80=99ve been told that some web hosting companies don=E2=80=99t expose a f= unction to write SRV record values.
>
> It is about time to:
>
> a) Stop referring to myths
>
> b) Fix the broken software in the cases there is

I repeat the question others asked: which "myths" are you r= eferring to?

In specific, a lot of web development is done in JavaScript. In current Jav= aScript, there is no way to send DNS queries, I believe. In fact, for secur= ity reasons, I believe all you can do is send HTTP queries. You might consi= der this to be "broken software", but I might consider allowing i= nsecure code pushed into my (browser) application to send and receive arbit= rary messages on any transport and port to be a security issue.


Indeed. There are very good reasons no= t to allow this...that said, however, a simplified "Discovery API"= ; of sorts, based around DNS, could be defined and provided to javascript d= evelopers if we could get the browser developers on board. HTTP/2 could ver= y well provide a strong motivation to do so given that srv-based upgrade di= scovery is one of the options on that table. It does not have to be code se= nding "arbitrary messages on any transport" ... it could be somet= hing as simple as.... =C2=A0Discovery.inspect("example.org", "srv.service.type", callback) wher= e any discovered matching srv records are passed to the callback. Fairly si= mple and straightforward and would not introduce any significant new securi= ty risks that do not already currently exist. All that would be necessary t= o make it happen is browser-vendor support and a relatively simple, well-de= fined interface. Certainly not impossible.

- James
=C2=A0
I note that you Cc'd the IAB on this. Is the IAB considering requiring = applications that include active code such as JavaScript to be able to do D= NS?

> SRV records (and similar new RR types added now more than 10 years ago= ) MUST be possible to be used.

Everywhere? Or only in systems that can already do their own DNS?

=C2=A0
> It is time IETF says STOP to these arguments for non-evolution of the = protocols and standards IETF develop.

Yes, and hyperbole is killing the Internet. :-)

--Paul Hoffman
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--14dae9340adbf3884304ce4f7385-- From gffletch@aol.com Mon Nov 12 09:28: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 292C921F846B for ; Mon, 12 Nov 2012 09:28:17 -0800 (PST) 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=[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 gMyT23ncIrES for ; Mon, 12 Nov 2012 09:28:14 -0800 (PST) Received: from imr-ma03.mx.aol.com (imr-ma03.mx.aol.com [64.12.206.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9748F21F8686 for ; Mon, 12 Nov 2012 09:28:14 -0800 (PST) Received: from mtaout-da01.r1000.mx.aol.com (mtaout-da01.r1000.mx.aol.com [172.29.51.129]) by imr-ma03.mx.aol.com (8.14.1/8.14.1) with ESMTP id qACHS4BL031469; Mon, 12 Nov 2012 12:28:04 -0500 Received: from palantir.local (unknown [10.181.191.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da01.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 858E6E0000B9; Mon, 12 Nov 2012 12:28:04 -0500 (EST) Message-ID: <50A131A4.3030001@aol.com> Date: Mon, 12 Nov 2012 12:28:04 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Blaine Cook References: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060607030401050901080703" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1352741284; bh=dnM7GdVw3j99Lm5gUT7ZfmVcSOQy5XALeDCylLA7mU8=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=yGZAZNf/3u5URVm7z/TnSaEi/7Zq+e4SzIvYzmoZRXkL8ry32a/IjPNv4GBPjzszo Kq4nLuh8LpDZoRP6NaP1YqPS5MGmYUXKHrSz6iO9rCZ9ASKITqoQUEVBiwlNFyGjXj EZ6hGWDgh+OR0JQUTLReY8svF2OH7bPRmi/4htqE= X-AOL-SCOLL-SCORE: 0:2:413907040:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d338150a131a411b4 X-AOL-IP: 10.181.191.18 Cc: IAB , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 17:28:17 -0000 This is a multi-part message in MIME format. --------------060607030401050901080703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Blaine, I can say that deploying the sub-domain solution is MUCH easier within my company than trying to put a dynamic web service on the "root" domain:) Discovery (especially resource= discovery) is largely an identity problem and in many large companies the "identity group" has no control over the corporate / main site. So for small companies deploying on the "root" domain is pretty straight forward (especially if they start with that in mind). I think for larger companies it will be significantly harder. For me, the sub-domain is the simplest solution to deploy because it doesn't require any coordination with other internal groups. The next easiest is a static redirect file that tells the requester to go to my deployed sub-domain. Solutions beyond these two start to get complicated very quickly (for me). Thanks, George On 11/12/12 12:14 PM, Blaine Cook wrote: > ... if the thing we're trying to guard against is environments where > individuals can't deploy Webfinger / SWD because of constraints that > are beyond their control, then subdomains aren't going to help, since > beyond the blatant security issues, there's the fact that many people > and groups aren't going to be able to setup sub-domains, and if they > can, it's going to be harder than just using a document under > /.well-known/ at their top-level domain. > > If we're making compromises, let's make compromises that actually > achieve the goals we're trying to achieve, please! > > b. > > > On 12 November 2012 17:07, Paul Hoffman > wrote: > > On Nov 11, 2012, at 9:55 PM, Patrik Fältström > wrote: > > > > > On 11 nov 2012, at 21:58, Michael Jones > > > wrote: > > > >> The problem with SRV records is they aren't ubiquitously > accessible. Some Web development platforms don't support direct > DNS queries. For instance, I don't believe that there are > JavaScript functions available for doing DNS queries. Likewise, > I've been told that some web hosting companies don't expose a > function to write SRV record values. > > > > It is about time to: > > > > a) Stop referring to myths > > > > b) Fix the broken software in the cases there is > > I repeat the question others asked: which "myths" are you > referring to? > > In specific, a lot of web development is done in JavaScript. In > current JavaScript, there is no way to send DNS queries, I > believe. In fact, for security reasons, I believe all you can do > is send HTTP queries. You might consider this to be "broken > software", but I might consider allowing insecure code pushed into > my (browser) application to send and receive arbitrary messages on > any transport and port to be a security issue. > > I note that you Cc'd the IAB on this. Is the IAB considering > requiring applications that include active code such as JavaScript > to be able to do DNS? > > > SRV records (and similar new RR types added now more than 10 > years ago) MUST be possible to be used. > > Everywhere? Or only in systems that can already do their own DNS? > > > It is time IETF says STOP to these arguments for non-evolution > of the protocols and standards IETF develop. > > Yes, and hyperbole is killing the Internet. :-) > > --Paul Hoffman > _______________________________________________ > 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 --------------060607030401050901080703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Blaine,

I can say that deploying the sub-domain solution is MUCH easier within my company than trying to put a dynamic web service on the "root" domain:)

Discovery (especially resource= discovery) is largely an identity problem and in many large companies the "identity group" has no control over the corporate / main site. So for small companies deploying on the "root" domain is pretty straight forward (especially if they start with that in mind). I think for larger companies it will be significantly harder.

For me, the sub-domain is the simplest solution to deploy because it doesn't require any coordination with other internal groups. The next easiest is a static redirect file that tells the requester to go to my deployed sub-domain.  Solutions beyond these two start to get complicated very quickly (for me).

Thanks,
George
On 11/12/12 12:14 PM, Blaine Cook wrote:
... if the thing we're trying to guard against is environments where individuals can't deploy Webfinger / SWD because of constraints that are beyond their control, then subdomains aren't going to help, since beyond the blatant security issues, there's the fact that many people and groups aren't going to be able to setup sub-domains, and if they can, it's going to be harder than just using a document under /.well-known/ at their top-level domain.

If we're making compromises, let's make compromises that actually achieve the goals we're trying to achieve, please!

b.


On 12 November 2012 17:07, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Nov 11, 2012, at 9:55 PM, Patrik Fältström <paf@frobbit.se> wrote:

>
> On 11 nov 2012, at 21:58, Michael Jones <michael_b_jones@hotmail.com> wrote:
>
>> The problem with SRV records is they aren’t ubiquitously accessible.  Some Web development platforms don’t support direct DNS queries.  For instance, I don’t believe that there are JavaScript functions available for doing DNS queries.  Likewise, I’ve been told that some web hosting companies don’t expose a function to write SRV record values.
>
> It is about time to:
>
> a) Stop referring to myths
>
> b) Fix the broken software in the cases there is

I repeat the question others asked: which "myths" are you referring to?

In specific, a lot of web development is done in JavaScript. In current JavaScript, there is no way to send DNS queries, I believe. In fact, for security reasons, I believe all you can do is send HTTP queries. You might consider this to be "broken software", but I might consider allowing insecure code pushed into my (browser) application to send and receive arbitrary messages on any transport and port to be a security issue.

I note that you Cc'd the IAB on this. Is the IAB considering requiring applications that include active code such as JavaScript to be able to do DNS?

> SRV records (and similar new RR types added now more than 10 years ago) MUST be possible to be used.

Everywhere? Or only in systems that can already do their own DNS?

> It is time IETF says STOP to these arguments for non-evolution of the protocols and standards IETF develop.

Yes, and hyperbole is killing the Internet. :-)

--Paul Hoffman
_______________________________________________
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

--------------060607030401050901080703-- From tbray@textuality.com Mon Nov 12 09:35: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 2B33821F859C for ; Mon, 12 Nov 2012 09:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[AWL=3.228, 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 sqfG1b42mpwq for ; Mon, 12 Nov 2012 09:35:22 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2535C21F857C for ; Mon, 12 Nov 2012 09:35:22 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so6967514oag.31 for ; Mon, 12 Nov 2012 09:35:21 -0800 (PST) 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:x-gm-message-state; bh=rmEyyXdLYcbUqrXJD6dmYTlhpmgU1wa2iKN3lTIhKu0=; b=aYFO7x5+8lqaU0IKaxaZ4Dk6+knOST+8PgADl86f+V0+iufADqo0mb3LLIN6zUJjMy K64Y4cDy7+1XEHrMRMSBPpfO0LooLiDWAMCkncRKVoPXt4JqWGzjhLQdZ/rBgfYS89P+ 5fQOFh0NejMSKxNHgSVEjAkh+x2sDzpTahxfx2kbHQ4R3wiMhGC17iT1LIBmoMXzcxu7 rXp9IETzDmYxbdD3R0D6HeMOjjzf7JAzesNg9SEhvqMfg0QzV6GETQzrWXFRmkCpkBwj yDxuD7jX34iYQsLvGEvwCgHwqPhT2ztnSHFKQ1IG1vrmyKEDRoJkjxl5HUKso8eRqHmI Seuw== MIME-Version: 1.0 Received: by 10.182.231.65 with SMTP id te1mr15959578obc.86.1352741721746; Mon, 12 Nov 2012 09:35:21 -0800 (PST) Received: by 10.76.12.134 with HTTP; Mon, 12 Nov 2012 09:35:21 -0800 (PST) X-Originating-IP: [24.84.208.217] In-Reply-To: <50A131A4.3030001@aol.com> References: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> <50A131A4.3030001@aol.com> Date: Mon, 12 Nov 2012 09:35:21 -0800 Message-ID: From: Tim Bray To: George Fletcher Content-Type: multipart/alternative; boundary=f46d04478981cc2e6b04ce4fb970 X-Gm-Message-State: ALoCoQlRBFhAncA/A1LsbfGzwSP+N2MmourURreD8PERI6tQoG7ldgdYaPJAV/uHm5+n3NDYJv7o Cc: IAB , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 17:35:23 -0000 --f46d04478981cc2e6b04ce4fb970 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Do we have any actual quantitative data? I can believe that there are some people for whom anything DNS-based is bad, and some other people for whom the webspace root is bad, but I haven=92t even the beginnings of a guess as to which group is larger. Or which class of problem is going to be easier to address at scale in the medium/long term. -T On Mon, Nov 12, 2012 at 9:28 AM, George Fletcher wrote: > Hi Blaine, > > I can say that deploying the sub-domain solution is MUCH easier within my > company than trying to put a dynamic web service on the "root" domain:) > > Discovery (especially resource=3D discovery) is largely an identity probl= em > and in many large companies the "identity group" has no control over the > corporate / main site. So for small companies deploying on the "root" > domain is pretty straight forward (especially if they start with that in > mind). I think for larger companies it will be significantly harder. > > For me, the sub-domain is the simplest solution to deploy because it > doesn't require any coordination with other internal groups. The next > easiest is a static redirect file that tells the requester to go to my > deployed sub-domain. Solutions beyond these two start to get complicated > very quickly (for me). > > Thanks, > George > > On 11/12/12 12:14 PM, Blaine Cook wrote: > > ... if the thing we're trying to guard against is environments where > individuals can't deploy Webfinger / SWD because of constraints that are > beyond their control, then subdomains aren't going to help, since beyond > the blatant security issues, there's the fact that many people and groups > aren't going to be able to setup sub-domains, and if they can, it's going > to be harder than just using a document under /.well-known/ at their > top-level domain. > > If we're making compromises, let's make compromises that actually > achieve the goals we're trying to achieve, please! > > b. > > > On 12 November 2012 17:07, Paul Hoffman wrote: > >> On Nov 11, 2012, at 9:55 PM, Patrik F=E4ltstr=F6m wrote= : >> >> > >> > On 11 nov 2012, at 21:58, Michael Jones >> wrote: >> > >> >> The problem with SRV records is they aren=92t ubiquitously accessible= . >> Some Web development platforms don=92t support direct DNS queries. For >> instance, I don=92t believe that there are JavaScript functions availabl= e for >> doing DNS queries. Likewise, I=92ve been told that some web hosting >> companies don=92t expose a function to write SRV record values. >> > >> > It is about time to: >> > >> > a) Stop referring to myths >> > >> > b) Fix the broken software in the cases there is >> >> I repeat the question others asked: which "myths" are you referring to? >> >> In specific, a lot of web development is done in JavaScript. In current >> JavaScript, there is no way to send DNS queries, I believe. In fact, for >> security reasons, I believe all you can do is send HTTP queries. You mig= ht >> consider this to be "broken software", but I might consider allowing >> insecure code pushed into my (browser) application to send and receive >> arbitrary messages on any transport and port to be a security issue. >> >> I note that you Cc'd the IAB on this. Is the IAB considering requiring >> applications that include active code such as JavaScript to be able to d= o >> DNS? >> >> > SRV records (and similar new RR types added now more than 10 years ago= ) >> MUST be possible to be used. >> >> Everywhere? Or only in systems that can already do their own DNS? >> >> > It is time IETF says STOP to these arguments for non-evolution of the >> protocols and standards IETF develop. >> >> Yes, and hyperbole is killing the Internet. :-) >> >> --Paul Hoffman >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > > > _______________________________________________ > apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailma= n/listinfo/apps-discuss > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d04478981cc2e6b04ce4fb970 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Do we have any actual quantitative data?=A0 I can believe that there are so= me people for whom anything DNS-based is bad, and some other people for who= m the webspace root is bad, but I haven=92t even the beginnings of a guess = as to which group is larger.=A0 Or which class of problem is going to be ea= sier to address at scale in the medium/long term.

=A0-T

On Mon, Nov 12, 2012 at 9:28 AM= , George Fletcher <gffletch@aol.com> wrote:
=20 =20 =20
Hi Blaine,

I can say that deploying the sub-domain solution is MUCH easier within my company than trying to put a dynamic web service on the "root" domain:)

Discovery (especially resource=3D discovery) is largely an identity problem and in many large companies the "identity group" ha= s no control over the corporate / main site. So for small companies deploying on the "root" domain is pretty straight forward (especially if they start with that in mind). I think for larger companies it will be significantly harder.

For me, the sub-domain is the simplest solution to deploy because it doesn't require any coordination with other internal groups. The next easiest is a static redirect file that tells the requester to go to my deployed sub-domain.=A0 Solutions beyond these two start to get complicated very quickly (for me).

Thanks,
George

On 11/12/12 12:14 PM, Blaine Cook wrote:
... if the thing we're trying to guard ag= ainst is environments where individuals can't deploy Webfinger / SWD because of constraints that are beyond their control, then subdomains aren't going to help, since beyond the blatant securit= y issues, there's the fact that many people and groups aren't g= oing to be able to setup sub-domains, and if they can, it's going to b= e harder than just using a document under /.well-known/ at their top-level domain.

If we're making compromises, let's make compromises that actually achieve the goals we're trying to achieve, please!

b.


On 12 November 2012 17:07, Paul Hoffman <paul.hoffman@vpnc.o= rg> wrote:
On Nov 11, 2012, at 9:55 PM, Patrik F=E4ltstr=F6m <paf@frobbit.se> wrote:

>
> On 11 nov 2012, at 21:58, Michael Jones <michael_b_jones@hotmai= l.com> wrote:
>
>> The problem with SRV records is they aren=92t ubiquitously accessible. =A0Some Web development platforms don=92t support direct DNS queries. =A0For instance, I don=92= t believe that there are JavaScript functions available for doing DNS queries. =A0Likewise, I=92ve been told that some we= b hosting companies don=92t expose a function to write SRV record values.
>
> It is about time to:
>
> a) Stop referring to myths
>
> b) Fix the broken software in the cases there is

I repeat the question others asked: which "myths" are= you referring to?

In specific, a lot of web development is done in JavaScript. In current JavaScript, there is no way to send DNS queries, I believe. In fact, for security reasons, I believe all you can do is send HTTP queries. You might consider this to be "broken software", but I might consider allowing inse= cure code pushed into my (browser) application to send and receive arbitrary messages on any transport and port to be a security issue.

I note that you Cc'd the IAB on this. Is the IAB considerin= g requiring applications that include active code such as JavaScript to be able to do DNS?

> SRV records (and similar new RR types added now more than 10 years ago) MUST be possible to be used.

Everywhere? Or only in systems that can already do their own DNS?

> It is time IETF says STOP to these arguments for non-evolution of the protocols and standards IETF develop.
Yes, and hyperbole is killing the Internet. :-)

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



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


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


--f46d04478981cc2e6b04ce4fb970-- From romeda@gmail.com Mon Nov 12 09:39: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 369A821F868B for ; Mon, 12 Nov 2012 09:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.456 X-Spam-Level: X-Spam-Status: No, score=-103.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, 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 kSPIIHhQtUxz for ; Mon, 12 Nov 2012 09:39:55 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A233921F85AF for ; Mon, 12 Nov 2012 09:39:55 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1150585pbc.31 for ; Mon, 12 Nov 2012 09:39:55 -0800 (PST) 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=6KYhP2EU9g2jIN1HPPaFzAIOylK4n0hk9mEvypP7E8k=; b=Ju6R60S7P6WRljDOcmv5owvVSc7tho5HtbP6xPzo0ejjQsZDC2iivZnVt37Uq+rzSm xwSQIPPKkTsBN0ArPjmggttUymw/WjSVwW3eN0uMQJ09NCgK0pojLoq/ScOtF8cFxKPP IogFL8sAvLJrRYPjqTPtu+N2xrK4zbFdDSjlzxXbPTwZ035rIv0XbdbFISwLlMNuryRQ Ju50UJ9iAV+Ooz78uafkr42YVi56At8G5xoahSREgQ4Tp6jSlNkZWlWQPjmfkMbx+wWf dNQNKqJaTtgVKfF6pNjm84ucOggb3ZgHNF5YWVonZ7sGosn5bClszcfeFF3yeHqt0aBP jKfQ== Received: by 10.68.244.6 with SMTP id xc6mr7041317pbc.94.1352741995352; Mon, 12 Nov 2012 09:39:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.67.2.101 with HTTP; Mon, 12 Nov 2012 09:39:35 -0800 (PST) In-Reply-To: <50A131A4.3030001@aol.com> References: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> <50A131A4.3030001@aol.com> From: Blaine Cook Date: Mon, 12 Nov 2012 17:39:35 +0000 Message-ID: To: George Fletcher Content-Type: multipart/alternative; boundary=e89a8ff24a531b13bd04ce4fca0a Cc: IAB , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 17:39:56 -0000 --e89a8ff24a531b13bd04ce4fca0a Content-Type: text/plain; charset=UTF-8 On 12 November 2012 17:28, George Fletcher wrote: > Hi Blaine, > > I can say that deploying the sub-domain solution is MUCH easier within my > company than trying to put a dynamic web service on the "root" domain:) > I meant the static solution, rather than the dynamic one, since this is about redirecting from one domain to another delegated domain, which it sounds like is a solution that would work for you (if slightly more complicated than setting up a subdomain for yourself). b. --e89a8ff24a531b13bd04ce4fca0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12 November 2012 17:28, George Fletcher <gffletch@aol.com>= wrote:
=20 =20 =20
Hi Blaine,

I can say that deploying the sub-domain solution is MUCH easier within my company than trying to put a dynamic web service on the "root" domain:)

I meant the static solution, rather than the dynamic one, since this = is about redirecting from one domain to another delegated domain, which it = sounds like is a solution that would work for you (if slightly more complic= ated than setting up a subdomain for yourself).
=C2=A0
b.
--e89a8ff24a531b13bd04ce4fca0a-- From romeda@gmail.com Mon Nov 12 09:42: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 4617021F86EB for ; Mon, 12 Nov 2012 09:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.47 X-Spam-Level: X-Spam-Status: No, score=-103.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, 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 If2TbwwaGM+n for ; Mon, 12 Nov 2012 09:42:06 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA23421F86D0 for ; Mon, 12 Nov 2012 09:42:06 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so4629185pad.31 for ; Mon, 12 Nov 2012 09:42:06 -0800 (PST) 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=RLHCYZqkYYTz+cvEivxUG0+UoEZ6WPmYUN84qGmhal8=; b=0WH5iNogr2XRsbJdtP8++8fyViDxAto/Y7UFHed1OKaojATneJC3nDNCIKbveey17E O+Hcc23swE4GcicVUpFdoWAzF0enR9uxQCCuz/ZHYnlK+3CoOL3GtJsf+UojdB+lDwee tidkBR4qKwX0psporWKwczILGJqrIY1qX6hfVTxMFrxb/CUJNCCZTDbsEgMibTL241zo vH+mX8pvZc7z0k6lscUvRahEfPKPEhnFsl1036OhqEvVU+5vKqKzJJqRLFcotFwD75gn fvERC4DVzKAf0bUPJ7ZpZc0Wwjaff99F0vGhkLn14AYlufM85D2NCqUR/5n1NobtWoT7 yf9A== Received: by 10.68.244.6 with SMTP id xc6mr7055001pbc.94.1352742126579; Mon, 12 Nov 2012 09:42:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.67.2.101 with HTTP; Mon, 12 Nov 2012 09:41:46 -0800 (PST) In-Reply-To: References: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> <50A131A4.3030001@aol.com> From: Blaine Cook Date: Mon, 12 Nov 2012 17:41:46 +0000 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=e89a8ff24a53ed6eac04ce4fd170 Cc: "apps-discuss@ietf.org Discuss" , IAB , Paul Hoffman Subject: Re: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 17:42:07 -0000 --e89a8ff24a53ed6eac04ce4fd170 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12 November 2012 17:35, Tim Bray wrote: > Do we have any actual quantitative data? I can believe that there are > some people for whom anything DNS-based is bad, and some other people for > whom the webspace root is bad, but I haven=E2=80=99t even the beginnings = of a guess > as to which group is larger. Or which class of problem is going to be > easier to address at scale in the medium/long term. It's maybe worth noting that Google's webmaster tools require modification of an HTTP location, as do many SSL-issuers and others who are authenticating ownership of a domain, so it's something that happens "extremely often" (I can't produce numbers since I don't have access to that sort of data). I'm not aware of any that use subdomains. b. --e89a8ff24a53ed6eac04ce4fd170 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 12 November 2012 1= 7:35, Tim Bray <tbray@textuality.com> wrote:
Do we have any actual quantitative data?=C2=A0 I can believe that there are= some people for whom anything DNS-based is bad, and some other people for = whom the webspace root is bad, but I haven=E2=80=99t even the beginnings of= a guess as to which group is larger.=C2=A0 Or which class of problem is go= ing to be easier to address at scale in the medium/long term.

It's maybe worth noting that Google's webmaster= tools require modification of an HTTP location, as do many SSL-issuers and= others who are authenticating ownership of a domain, so it's something= that happens "extremely often" (I can't produce numbers sinc= e I don't have access to that sort of data). I'm not aware of any t= hat use subdomains.

b.
--e89a8ff24a53ed6eac04ce4fd170-- From paf@frobbit.se Mon Nov 12 09:42: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 1875421F86E4 for ; Mon, 12 Nov 2012 09:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 9Gp6JubEzZuV for ; Mon, 12 Nov 2012 09:42:37 -0800 (PST) Received: from srv01.frobbit.se (ns2.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 5892521F8775 for ; Mon, 12 Nov 2012 09:42:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 6CBAB177C4286; Mon, 12 Nov 2012 18:42:36 +0100 (CET) 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 Ri+Nbi1adcSl; Mon, 12 Nov 2012 18:42:35 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id E65E7177C427E; Mon, 12 Nov 2012 18:42:35 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> Date: Mon, 12 Nov 2012 18:42:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1499) Cc: IAB , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 17:42:38 -0000 On 12 nov 2012, at 18:07, Paul Hoffman wrote: > I repeat the question others asked: which "myths" are you referring = to? As a myth I see for example that it is hard to use other RR Types. Yes, = hardER, as one can not use one of the libraries that exists. > In specific, a lot of web development is done in JavaScript. In = current JavaScript, there is no way to send DNS queries, I believe. In = fact, for security reasons, I believe all you can do is send HTTP = queries. You might consider this to be "broken software", but I might = consider allowing insecure code pushed into my (browser) application to = send and receive arbitrary messages on any transport and port to be a = security issue. This is why I said in my response that the day browsers use SRV records = to resolve HTTP URIs, then also javascript will do so. > I note that you Cc'd the IAB on this. Is the IAB considering requiring = applications that include active code such as JavaScript to be able to = do DNS? I cc:ed IAB as I think it is close to the point in time where IAB must = decide whether we should only(!) have the resource records A, AAAA, TXT, = or if we also should be able to start using other RR Types. We (IETF) waste time by repeating this discussion over and over again. >> SRV records (and similar new RR types added now more than 10 years = ago) MUST be possible to be used. >=20 > Everywhere? Or only in systems that can already do their own DNS? Enough so that IETF know whether new RR Types should be specified or = not. >> It is time IETF says STOP to these arguments for non-evolution of the = protocols and standards IETF develop. >=20 > Yes, and hyperbole is killing the Internet. :-) On Thursday next week in fact! Patrik From gffletch@aol.com Mon Nov 12 09: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 491D321F8765 for ; Mon, 12 Nov 2012 09:57:39 -0800 (PST) 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=[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 VE1A8U0CDUMW for ; Mon, 12 Nov 2012 09:57:38 -0800 (PST) Received: from imr-da02.mx.aol.com (imr-da02.mx.aol.com [205.188.105.144]) by ietfa.amsl.com (Postfix) with ESMTP id ED52F21F874D for ; Mon, 12 Nov 2012 09:57:35 -0800 (PST) Received: from mtaout-mb05.r1000.mx.aol.com (mtaout-mb05.r1000.mx.aol.com [172.29.41.69]) by imr-da02.mx.aol.com (Outbound Mail Relay) with ESMTP id 30F4D1C000167; Mon, 12 Nov 2012 12:57:35 -0500 (EST) Received: from palantir.local (unknown [10.181.191.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id F3C0BE0000BA; Mon, 12 Nov 2012 12:57:34 -0500 (EST) Message-ID: <50A1388D.3090306@aol.com> Date: Mon, 12 Nov 2012 12:57:33 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Blaine Cook References: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> <50A131A4.3030001@aol.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030303000807000204010700" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1352743055; bh=KNcN7R2OzETtxk4q3/BW6mBxsXlkgFJe3DupHPvBqG0=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=shj6qf8xNLpVc0aUwcGbHqVTK/m5ENG7NclOO1E8C9eg/gaHc+fjyXqpauuMT8f2b nlXHdYIe2GyzXD3ImKBwER/hhOEuHVvzTxt8jhTBHhX5Lw7jFGEgWY39ciuwPTtvW+ yAVXoWTKDiwN8TgP3dhNE5ddP/QbpumhXPA75DIU= X-AOL-SCOLL-SCORE: 0:2:431237440:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d294550a1388e3f72 X-AOL-IP: 10.181.191.18 Cc: IAB , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 17:57:40 -0000 This is a multi-part message in MIME format. --------------030303000807000204010700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/12/12 12:39 PM, Blaine Cook wrote: > On 12 November 2012 17:28, George Fletcher > wrote: > > Hi Blaine, > > I can say that deploying the sub-domain solution is MUCH easier > within my company than trying to put a dynamic web service on the > "root" domain:) > > > I meant the static solution, rather than the dynamic one, since this > is about redirecting from one domain to another delegated domain, > which it sounds like is a solution that would work for you (if > slightly more complicated than setting up a subdomain for yourself). > b. Yes, it's doable... however, given that we support multiple domains (from a SWD perspective) the complexity grows with each new static file we have to deploy. If my recollection of previous discussions is correct, there are some deployments where being able to serve a file from the "root" site is not possible. Hence the sub-domain solution was introduced. Thanks, George --------------030303000807000204010700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/12/12 12:39 PM, Blaine Cook wrote:
On 12 November 2012 17:28, George Fletcher <gffletch@aol.com> wrote:
Hi Blaine,

I can say that deploying the sub-domain solution is MUCH easier within my company than trying to put a dynamic web service on the "root" domain:)

I meant the static solution, rather than the dynamic one, since this is about redirecting from one domain to another delegated domain, which it sounds like is a solution that would work for you (if slightly more complicated than setting up a subdomain for yourself).
 
b.

Yes, it's doable... however, given that we support multiple domains (from a SWD perspective) the complexity grows with each new static file we have to deploy.

If my recollection of previous discussions is correct, there are some deployments where being able to serve a file from the "root" site is not possible. Hence the sub-domain solution was introduced.

Thanks,
George

--------------030303000807000204010700-- From paul.hoffman@vpnc.org Mon Nov 12 10:00: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 DD30621F84BA; Mon, 12 Nov 2012 10:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.074 X-Spam-Level: X-Spam-Status: No, score=-102.074 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 8J6HZBfpshhg; Mon, 12 Nov 2012 10:00:18 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC6821F8488; Mon, 12 Nov 2012 10:00:18 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qACI0DO3031306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Nov 2012 11:00:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Mon, 12 Nov 2012 10:00:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <663D4288-F716-4B88-94DA-06DAFBB5818A@vpnc.org> References: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> To: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1499) Cc: IAB , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 18:00:19 -0000 On Nov 12, 2012, at 9:42 AM, Patrik F=E4ltstr=F6m = wrote: > On 12 nov 2012, at 18:07, Paul Hoffman wrote: >=20 >> I repeat the question others asked: which "myths" are you referring = to? >=20 > As a myth I see for example that it is hard to use other RR Types. = Yes, hardER, as one can not use one of the libraries that exists. I fear that you are misunderstanding this thread then. The debate is not = "SRV vs. some other RRtype like TXT", but "SRV versus HTTP lookup and = redirect". >> In specific, a lot of web development is done in JavaScript. In = current JavaScript, there is no way to send DNS queries, I believe. In = fact, for security reasons, I believe all you can do is send HTTP = queries. You might consider this to be "broken software", but I might = consider allowing insecure code pushed into my (browser) application to = send and receive arbitrary messages on any transport and port to be a = security issue. >=20 > This is why I said in my response that the day browsers use SRV = records to resolve HTTP URIs, then also javascript will do so. Browsers currently use port 53 to look up A records, but they do not = allow JavaScript to do so. To many of us, that is a good thing. Even if = a browser used SRV to look up HTTP URIs, it sounds like you are saying = that the browser should let JavaScript look up arbitrary URIs in the = DNS. I'm not sure that the security properties of doing this have been = investigated. >> I note that you Cc'd the IAB on this. Is the IAB considering = requiring applications that include active code such as JavaScript to be = able to do DNS? >=20 > I cc:ed IAB as I think it is close to the point in time where IAB must = decide whether we should only(!) have the resource records A, AAAA, TXT, = or if we also should be able to start using other RR Types. >=20 > We (IETF) waste time by repeating this discussion over and over again. But that's not what this thread is about at all. If the IAB wants to = decide whether indirection in application protocols should be done in = the DNS with SRV versus in the protocols, that's fine, but for HTTP, = that's kinda late. >>> SRV records (and similar new RR types added now more than 10 years = ago) MUST be possible to be used. >>=20 >> Everywhere? Or only in systems that can already do their own DNS? >=20 > Enough so that IETF know whether new RR Types should be specified or = not. As you say above, SRV is not a new RRtype here. >>> It is time IETF says STOP to these arguments for non-evolution of = the protocols and standards IETF develop. >>=20 >> Yes, and hyperbole is killing the Internet. :-) >=20 > On Thursday next week in fact! Well played, sir! :-) --Paul Hoffman= From tbray@textuality.com Mon Nov 12 10:11: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 6F5D421F8531 for ; Mon, 12 Nov 2012 10:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=1.076, 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 xlTeT+OsDw9E for ; Mon, 12 Nov 2012 10:11:30 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8204821F85AF for ; Mon, 12 Nov 2012 10:11:30 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id wo10so3274076obc.31 for ; Mon, 12 Nov 2012 10:11:30 -0800 (PST) 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:x-gm-message-state; bh=DImsaRtBDe981LoF19RY4z6VgVuH49cWo5WQlUvtep8=; b=BIMj/nPgw4jEHegPpu6tG+XwN0RI3MMj7Ho58rP5zZYfEz4adUWggWGmNiDjtJsPYm xGxXMozlCHbowVpIcu6YO9hfm/6P151lDxbPgdxHYhJPh3RKx1O+z+6uRmhBfTUyhLqV YsrFtM6gqe/0tGeJMyuCKtVoFpyAYmP27MLmNCOrp0zKtBo/bDkNQonpnWdpVjY6sWiR FkANMhpIyu4imMLuKYiPidsifr8zKImtQqs7xdA+dClt98qtBFwv+M84qsyOWp3xwqMP jN2HbnxHP5eTFXta5Si8C+chggjaBUe+M9Pvq30+XvDrTL3svZIOujicA60VEWhsEm+k gBXw== MIME-Version: 1.0 Received: by 10.182.141.73 with SMTP id rm9mr15749657obb.99.1352743890037; Mon, 12 Nov 2012 10:11:30 -0800 (PST) Received: by 10.76.12.134 with HTTP; Mon, 12 Nov 2012 10:11:29 -0800 (PST) X-Originating-IP: [24.84.208.217] In-Reply-To: <663D4288-F716-4B88-94DA-06DAFBB5818A@vpnc.org> References: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> <663D4288-F716-4B88-94DA-06DAFBB5818A@vpnc.org> Date: Mon, 12 Nov 2012 10:11:29 -0800 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=e89a8f646a2909aa7504ce503bf5 X-Gm-Message-State: ALoCoQl2yWAZKHzmkvm/ZeYwbBZ9W4l2mGm1RqxH4P1NTSb5GA2Op+XVxTO8X8YYoNg2KSLa/dI9 Cc: IAB , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 18:11:32 -0000 --e89a8f646a2909aa7504ce503bf5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 12, 2012 at 10:00 AM, Paul Hoffman wrote= : > On Nov 12, 2012, at 9:42 AM, Patrik F=E4ltstr=F6m wrote: > > > > On Thursday next week in fact! > > Well played, sir! :-) > You guys are so wrong, per the Mayans the Internet and everything else ends Dec 21, which is not next week. -T > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --e89a8f646a2909aa7504ce503bf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 12, 2012 at 10:00 AM, Paul Hoffman <paul.hoffman@vpnc.org<= /a>> wrote:
On Nov 12, 2012, at 9:42 AM, Patrik F=E4ltstr=F6m <paf@frobbit.se> wrote:
>
> On Thursday next week in fact!

Well played, sir! :-)

You guys are so wrong,= per the Mayans the Internet and everything else ends Dec 21, which is not = next week. -T

=A0

--Paul Hoffman
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--e89a8f646a2909aa7504ce503bf5-- From paf@frobbit.se Mon Nov 12 10:13: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 7FDBE21F86E4 for ; Mon, 12 Nov 2012 10:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.300, 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 5o6RWuLB54EO for ; Mon, 12 Nov 2012 10:13:14 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id B0CCD21F86C1 for ; Mon, 12 Nov 2012 10:13:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 0D98D177C4D40; Mon, 12 Nov 2012 19:13:13 +0100 (CET) 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 kJ4rdlumoVeK; Mon, 12 Nov 2012 19:13:12 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id D7B2F177C4D39; Mon, 12 Nov 2012 19:13:12 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <663D4288-F716-4B88-94DA-06DAFBB5818A@vpnc.org> Date: Mon, 12 Nov 2012 19:13:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <38263EDD-AC43-40EA-A22F-AE1A1EE1963F@frobbit.se> References: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> <663D4288-F716-4B88-94DA-06DAFBB5818A@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1499) Cc: IAB , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 18:13:14 -0000 On 12 nov 2012, at 19:00, Paul Hoffman wrote: > On Nov 12, 2012, at 9:42 AM, Patrik F=E4ltstr=F6m = wrote: >=20 >> On 12 nov 2012, at 18:07, Paul Hoffman wrote: >>=20 >>> I repeat the question others asked: which "myths" are you referring = to? >>=20 >> As a myth I see for example that it is hard to use other RR Types. = Yes, hardER, as one can not use one of the libraries that exists. >=20 > I fear that you are misunderstanding this thread then. The debate is = not "SRV vs. some other RRtype like TXT", but "SRV versus HTTP lookup = and redirect". I absolutely understand the debate (and have in fact had a few phone = calls to me about it), but I started to see arguments that "SRV is not a = good choice as we can not deploy SRV". If that is an argument to use, = then, well, then we have the "SRV or TXT" discussion. At least in the = form of arguments. Patrik From paul.hoffman@vpnc.org Mon Nov 12 10:53: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 108A821F878E; Mon, 12 Nov 2012 10:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 rNEwHgoHyBvW; Mon, 12 Nov 2012 10:53:49 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD1321F8686; Mon, 12 Nov 2012 10:53:49 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qACIrilq032814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Nov 2012 11:53:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <38263EDD-AC43-40EA-A22F-AE1A1EE1963F@frobbit.se> Date: Mon, 12 Nov 2012 10:53:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3BC2750D-AD0C-4993-9425-8A36E6E5BF0D@vpnc.org> References: <704142AE-6545-4AAA-8FA9-4BAE05E0A5C4@frobbit.se> <07178852-2A03-4242-B426-3012FE3DD34A@vpnc.org> <663D4288-F716-4B88-94DA-06DAFBB5818A@vpnc.org> <38263EDD-AC43-40EA-A22F-AE1A1EE1963F@frobbit.se> To: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1499) Cc: IAB , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments 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, 12 Nov 2012 18:53:50 -0000 On Nov 12, 2012, at 10:13 AM, Patrik F=E4ltstr=F6m = wrote: >=20 > On 12 nov 2012, at 19:00, Paul Hoffman wrote: >=20 >> On Nov 12, 2012, at 9:42 AM, Patrik F=E4ltstr=F6m = wrote: >>=20 >>> On 12 nov 2012, at 18:07, Paul Hoffman = wrote: >>>=20 >>>> I repeat the question others asked: which "myths" are you referring = to? >>>=20 >>> As a myth I see for example that it is hard to use other RR Types. = Yes, hardER, as one can not use one of the libraries that exists. >>=20 >> I fear that you are misunderstanding this thread then. The debate is = not "SRV vs. some other RRtype like TXT", but "SRV versus HTTP lookup = and redirect". >=20 > I absolutely understand the debate (and have in fact had a few phone = calls to me about it), but I started to see arguments that "SRV is not a = good choice as we can not deploy SRV". If that is an argument to use, = then, well, then we have the "SRV or TXT" discussion. At least in the = form of arguments. Fair enough. I read them as "we cannot deploy DNS-in-JavaScript". --Paul Hoffman= From michael_b_jones@hotmail.com Tue Nov 13 15:33: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 41DB321F8691; Tue, 13 Nov 2012 15:33:27 -0800 (PST) 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=[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 ntI5ZIMOsIXx; Tue, 13 Nov 2012 15:33:26 -0800 (PST) Received: from bay0-omc1-s25.bay0.hotmail.com (bay0-omc1-s25.bay0.hotmail.com [65.54.190.36]) by ietfa.amsl.com (Postfix) with ESMTP id D57B521F868F; Tue, 13 Nov 2012 15:33:26 -0800 (PST) Received: from BAY171-W47 ([65.54.190.60]) by bay0-omc1-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Nov 2012 15:33:26 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_2df8537d-c1b1-4a26-b683-96413d67d4ed_" X-Originating-IP: [174.7.255.77] From: Michael Jones To: , , Date: Tue, 13 Nov 2012 15:33:26 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 13 Nov 2012 23:33:26.0611 (UTC) FILETIME=[479C2230:01CDC1F7] Cc: cfrg@irtf.org Subject: [apps-discuss] Vacationing this week & e-mail address 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, 13 Nov 2012 23:33:27 -0000 --_2df8537d-c1b1-4a26-b683-96413d67d4ed_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all=2C I wanted to let you know that I'm vacationing this week=2C and so= mostly won't be participating in discussions. I'll respond next week. Als= o=2C at present I=92m using the e-mail address michael_b_jones@hotmail.com to send e-mail to IETF mailing lists because currently I=92m unable to send= e-mail to any IETF lists using my normal e-mail address Michael.Jones@microsoft.com.=20 When corresponding with me individually=2C it would be better to use the Microsoft address=2C as the message is likely to be seen more quickly. Have= a good week=2C everyone! -- Mike=20 = --_2df8537d-c1b1-4a26-b683-96413d67d4ed_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi all=2C
 =3B
I wanted to let you know that I'm vacationing this= week=2C and so mostly won't be participating in discussions. =3B I'll = respond next week.
&nbs= p=3B

Also=2C at present I=92m using the e-ma= il address michael_b_jones@hotmail.com to send e-mail to IETF mailing lists because currently I=92m unable to send= e-mail to any IETF lists using my normal e-mail address Michael.Jones@microsoft.com. =3B When corresponding with me individually=2C it would be better to use the Microsoft address=2C as the message is likely to be seen more quickly.

 =3B
Have a good week=2C everyone!
 =3B
-- Mike
 =3B


= --_2df8537d-c1b1-4a26-b683-96413d67d4ed_-- From dirk.f5r@googlemail.com Wed Nov 14 03:37: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 0821C21F84E8 for ; Wed, 14 Nov 2012 03:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 tm3drt-4fWoh for ; Wed, 14 Nov 2012 03:37:05 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39021F84E3 for ; Wed, 14 Nov 2012 03:37:04 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so344745lbk.31 for ; Wed, 14 Nov 2012 03:37:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=j5dEdUNgSYC7Qou1oOJn081fOobeOdXn8zYyxZ5pk9w=; b=UDndF5N1al2VKK1is9j4p/MXsLHi0LgSokLadI/88q7Vf9z8yzA8ENZ1e8r8QXzgAd 6/7GM1KCGNfwxfw9SSGM2U5N9LAcxxxL719K/Wluoc20da1uJBqXVi7lRF18pVA3e0is Oeib5jadqZppQuHaYvRT0C4a2gJi+8TBjZzimMw5Zc4bY93FsgSTOMQKQRtHZro1bXfe ByL35YmMdsq8UWLDfU7T6OpRD1FOOtDT0nrDAjtb035zWe3xrmL+PKBkYaKITiQqKnmY LSz3mJ4w//PMLjRZ/uWG9VqZmKblLfuKBEYsXVnlYTb+NATCxZIdayRjxRk8tjhBpWME +hnw== Received: by 10.112.36.200 with SMTP id s8mr10719607lbj.92.1352893023587; Wed, 14 Nov 2012 03:37:03 -0800 (PST) Received: from limo3121.local ([62.213.146.106]) by mx.google.com with ESMTPS id d5sm502551lbk.10.2012.11.14.03.37.01 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 03:37:02 -0800 (PST) Message-ID: <50A38259.4050304@googlemail.com> Date: Wed, 14 Nov 2012 12:36:57 +0100 From: Dirk F5R User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [apps-discuss] json-home: comments and questions on draft 02 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, 14 Nov 2012 11:37:06 -0000 Hi all, hi Mark, I had a closer look at http://pretty-rfc.herokuapp.com/draft-nottingham-json-home and http://tools.ietf.org/html/draft-nottingham-json-home-02 since I also absolutely see the need for an API "home page" as well. As a matter of fact, the specs I have contributed to at work come with what we call a "service document" (I can't help using that term in the remainder of this mail). This is only another term for basically the same concept: one single entry point into a hypermedia API that reveals links to something like top-level resources. The URI to the service document is the only thing that needs to be published to client developers, from there we strictly follow the HATEOAS principle. I have a few comments / questions on json-home: When I look at the json-home draft, it looks to me as if it were actually two separate ones. One that deals with the need of a service document and how it might look like and one that defines how links should look like in JSON. The latter one though is nothing specific to the service document but would rather be a general convention. Shouldn't this be two separate draft documents? As to my current perception, I'm also not sure why the service document should have a different format or structure than any other document that comes back from an API. For instance, if your representations always come with an attribute called "links" that hosts explicit links by relation types, why should this be different for the service document? This leads me to the opinion that it should be defined as a requirement that hypermedia APIs must come with a service document but I don't necessarily see the need to define a particular format or media type for it. Thanks for listening and happy to read your comments. ;-) Glück auf! Dirk From mikekelly321@gmail.com Wed Nov 14 06:33: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 6D46321F8606 for ; Wed, 14 Nov 2012 06:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 r7knXDUWT950 for ; Wed, 14 Nov 2012 06:33:44 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8311221F8605 for ; Wed, 14 Nov 2012 06:33:44 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so510918obb.31 for ; Wed, 14 Nov 2012 06:33:43 -0800 (PST) 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=6QOLxDGCJB38Jnr/+WL8LyDYWTtDre1pyQfNX11kmnQ=; b=mfP9VY+yq2ktygpiTshADHcTwVbP398jocnSdmD/Mjs07WyH2TR0bWmfH6yQM5Q7Py hD5pQk+8gNL1WipRAC++btBtSWZRn5EoBnolvb6OXNzuKpOY4FeQedmyF5PVWEuz+zMc pgbRZfme3CL9hY2ZqmqNHCptziXwU16V22Mq31/2GorbsqqClsJkZV5/B+jnVNV5nf4W dW7UfY4/c7c8szcfQ5jGxw7eddem3xrWx5Uj2+2gGYfWnzXuY6kdrCkt8ZHNYr/1Vink BhXbgITh5woBUsbzzcUD8HTnor02nnbT/ZJ6QEgm6aBT6J8BG/QxWsQhEJr75mqe00u2 hfow== MIME-Version: 1.0 Received: by 10.182.202.39 with SMTP id kf7mr21122553obc.37.1352903623815; Wed, 14 Nov 2012 06:33:43 -0800 (PST) Received: by 10.60.48.99 with HTTP; Wed, 14 Nov 2012 06:33:43 -0800 (PST) In-Reply-To: <50A38259.4050304@googlemail.com> References: <50A38259.4050304@googlemail.com> Date: Wed, 14 Nov 2012 14:33:43 +0000 Message-ID: From: Mike Kelly To: Dirk F5R Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] json-home: comments and questions on draft 02 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, 14 Nov 2012 14:33:45 -0000 Hi Dirk, fwiw, I've authored a similar media type (hal+json) that's intended to be used for more than simply root/home resources. http://pretty-rfc.herokuapp.com/draft-kelly-json-hal One company I've discussed hal+json with have asked the same question about why I did not separate out the linking convention. As a result of that discussion, I have actually started efforts to extract it and make them two distinct I-Ds. Cheers, M On Wed, Nov 14, 2012 at 11:36 AM, Dirk F5R wrote: > Hi all, hi Mark, > > I had a closer look at > http://pretty-rfc.herokuapp.com/draft-nottingham-json-home and > http://tools.ietf.org/html/draft-nottingham-json-home-02 since I also > absolutely see the need for an API "home page" as well. As a matter of fa= ct, > the specs I have contributed to at work come with what we call a "service > document" (I can't help using that term in the remainder of this mail). T= his > is only another term for basically the same concept: one single entry poi= nt > into a hypermedia API that reveals links to something like top-level > resources. The URI to the service document is the only thing that needs t= o > be published to client developers, from there we strictly follow the HATE= OAS > principle. > > I have a few comments / questions on json-home: > > When I look at the json-home draft, it looks to me as if it were actually > two separate ones. One that deals with the need of a service document and > how it might look like and one that defines how links should look like in > JSON. The latter one though is nothing specific to the service document b= ut > would rather be a general convention. Shouldn't this be two separate draf= t > documents? > > As to my current perception, I'm also not sure why the service document > should have a different format or structure than any other document that > comes back from an API. For instance, if your representations always come > with an attribute called "links" that hosts explicit links by relation > types, why should this be different for the service document? This leads = me > to the opinion that it should be defined as a requirement tha= t > hypermedia APIs must come with a service document but I don't necessarily > see the need to define a particular format or media type for it. > > Thanks for listening and happy to read your comments. ;-) > > Gl=FCck auf! > Dirk > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=20 Mike http://twitter.com/mikekelly85 http://github.com/mikekelly http://linkedin.com/in/mikekelly123 From stpeter@stpeter.im Wed Nov 14 10:17: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 8069E21F85F3 for ; Wed, 14 Nov 2012 10:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 3MSpnp-ccvlM for ; Wed, 14 Nov 2012 10:17:40 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 29F5321F858E for ; Wed, 14 Nov 2012 10:17:39 -0800 (PST) Received: from [64.101.72.39] (unknown [64.101.72.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 197DD40062; Wed, 14 Nov 2012 11:21:46 -0700 (MST) Message-ID: <50A3E044.5000202@stpeter.im> Date: Wed, 14 Nov 2012 11:17:40 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Graham Klyne References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im> <509991D0.9000007@ninebynine.org> <5099F175.3060703@stpeter.im> <509BA2F2.6000006@stpeter.im> <509CEA8B.7020507@ninebynine.org> In-Reply-To: <509CEA8B.7020507@ninebynine.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 14 Nov 2012 18:17:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/9/12 4:35 AM, Graham Klyne wrote: > On 08/11/2012 12:17, Peter Saint-Andre wrote: >> Hi Graham, >> >> Thanks again for sharing your thoughts on the matter. I happened >> to chat about this with a few folks here at the IETF meeting in >> Atlanta, and here is how I see it... >> >> We have this protocol called WebFinger: in order to retrieve >> pointers to further information about a person associated with a >> domain, a client sends a special HTTP request to a server at that >> domain and passes as a parameter in that request a URI that >> identifies the person. That URI could be a 'mailto:', 'sip:', >> 'xmpp:', 'callto:' (?), or other URI that includes an identifier >> for the person (i.e., for an account controlled by the person). >> >> When the client completes that operation, is it dereferencing >> the 'mailto:', 'sip:', 'xmpp:' (etc.) URI that is passed as a >> parameter? Or it dereferencing the HTTP URL to which it sends the >> request? Example: >> >> http://example.com/lrdd/?f=json&uri=xmpp%3Abob%40example.com >> >> This might only indicate my ignorance of URIs, but that example >> doesn't feel to me like a dereferencing of an 'xmpp:' URI, which >> I would expect to be something like this (see XEP-0054 at >> xmpp.org): >> >> xmpp:bob@example.com?vcard > > You're right. It's dereferencing an HTTP URI which happens to > contain an encoded xmpp URI (but HTTP protocol doesn't know about > that). > >> Instead, the URI that is passed as a parameter in the WebFinger >> operation feels to me like something that is used purely for >> identification, not interaction (dereferencing). >> >> If that line of reasoning is just wrong, please do let me know. >> :-) > > I don't disagree with anything you've said here. > > But it doesn't say anything about what you do when starting with > an acct: URI and want to find out more. I think the short answer is: Don't do that. :) As I understand it, an acct: URI is not intended to be used directly as a way to "find out more". It's something that is passed around in the background, not exposed to humans. It's a kind of abstract identifier, if you will. > Let me posit for the purpose of debate that dereferencing an acct: > URI is done using WebFinger. If that's what folks wanted all long, I wish they'd called it webfinger: or wf:, not acct:... > It happens that execution of the WebFinger protocol involves > dereferencing HTTP URIs, and those HTTP URIs may contain references > to (parts of) the acct: URIs, or any other ind of URI. So > dereferencing an acct: URI involves constructing an http: URI and > then dereferencing that. I see no conflict here. Yes, that makes sense if we're talking about something that is specific to the WebFinger protocol. If, say, the Simple Web Discovery protocol or some other protocol decides to use acct: URIs then saying that a bare acct: URI is dereferenced by performing a WebFinger operation seems wrong to me. >> The WebFinger community, through much conversation over the >> years, decided that it was potentially confusing to use 'mailto:' >> URIs when passing a parameter in the WebFinger operation, >> primarily because there might not be an email service running at >> the domain or associated with that person, and perhaps >> secondarily because they didn't want to set up the expectation >> that the requesting entity was initiating any kind of email-based >> interaction. Therefore, they decided to define a neutral URI >> scheme that would be used purely for identification. > > Sure, no argument here from me. > >> As I understand it, there is no expection that an HTML href >> attribute containing an 'acct:' URI would trigger a WebFinger >> interaction: >> >> info > > Maybe that's where our positions differ. I think it's quite > reasonable that an acct: URI could in principle, be used in this > way (i.e. as an arbitrary link in a document. Modulo > implementation support, of course). > > And that kind of dereferencing may not be what the WebFinger > designers had in mind, but they have chosen to adopt an artifact > (URI) from another framework (the Web), so there are expectations > that might be associated with that artifact. Web architecture > tries to maintain a separation of purpose between URIs and > protocols: in principle (though not always in practice) an > application that uses a URI in a generic way (such as in HTML @href > values) should strive be "colour blind" with respect to the URI > provided (cf. "URI Opacity" - > http://www.w3.org/TR/webarch/#uri-opacity) ... What are the practical implications of URI opacity in this context? >> Instead, the client would need to include the correct HTTP URL: >> >> > > href='http://example.com/lrdd/?f=json&uri=xmpp%3Abob%40example.com'>info > > > > ... In this case, I'd say the application that is generating a web > page with a link in it should ideally not have to treat the acct: > scheme differently (i.e. not need know that it has to generate the > corresponding WebFinger http: URI) - that level of treatment is, > IMO, best taken as part of the dereferencing semantics of the URI > scheme itself, not the application that uses it. > >> Therefore, I continue to think that 'acct:' URIs are used purely >> for identification and not at all for interaction. It's just a >> parameter that you pass in the query part of an HTTP URL, not a >> URI that you dereference directly. >> >> If those who know more about URIs or WebFinger than I do disagree >> with the foregoing characterization, I'd love to hear it. > > I don't think there's a definitive right-or-wrong position here. I > just feel that, to the extent that acct: *is* associated with a > specific protocol, that the dereferencing mechanism should be part > of the URI specification. I think we all agree on that. The question is whether acct: is indeed strongly associated with the WebFinger protocol. That doesn't feel right to me, but if that's what we decide in the working group here then I'm happy to update the spec accordingly. > You appear see acct: as a kind of URN (in the broad sense of URN), > I prefer to see it as a kind of URL. In the terms of RFC 3986 (Section 1.2.2), I see acct: as a URI that provides identification, whereas you see acct: as a URI that enables interaction (i.e., access to a resource in the form of a JSON Resource Decriptor via the WebFinger protocol). Are identification-only URIs limited to URNs ("in the broad sense")? > Either is technically acceptable, but I feel the URL view is > potentially more useful as, among other things, it enables > (automatable) follow-your-nose discovery to be associated with > acct: URIs. Usefulness might be in the eye of the beholder or depend on the application one has in mind. Designers of protocols other than WebFinger might find it useful to have a URI scheme that provides pure identification of an account at a service, which is how I've always understood the acct: URI scheme. Clearly, the two of us see things in different ways. IMHO we might need the APPSAWG chairs to issue a call for consensus so that we can get unstuck here... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCj4EQACgkQNL8k5A2w/vwSggCcDIIHvucqEps47SpAPEYD0asx CEYAnRInk9UTnZLTXAhwRjUharbJ3n9/ =xuTL -----END PGP SIGNATURE----- From ve7jtb@ve7jtb.com Wed Nov 14 12:22: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 72C5921F8546 for ; Wed, 14 Nov 2012 12:22:41 -0800 (PST) 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=[AWL=-0.000, 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 PyAjXDWDEsbR for ; Wed, 14 Nov 2012 12:22:38 -0800 (PST) Received: from mail-gh0-f181.google.com (mail-gh0-f181.google.com [209.85.160.181]) by ietfa.amsl.com (Postfix) with ESMTP id 01CB421F8554 for ; Wed, 14 Nov 2012 12:22:37 -0800 (PST) Received: by mail-gh0-f181.google.com with SMTP id z22so241936ghb.26 for ; Wed, 14 Nov 2012 12:22:37 -0800 (PST) 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=8Cw0vX57C6upbL12bPnrILj5gvsS71QSG3E+RmEbli0=; b=GPV4MMUQE+Q30c5FzEqUuOOTjsGZu/ZgTbJjHzQsoxecu+AXxULhinZmoRiLuBuGJh P3BdFOPlvm7YpXvty1ZJhUTF1yLyut5x4hJ+6mTudvp1aO3TxzRin9q/gliWrNoMyJ/E e9DGlZ1RqrATmRofl8cybnjLnlhVEPCJFgepyuxUzgBmIN7Dac7pd0p8yiEMpn6e5jwG zTpXS9nXUhEFYbMp/Grcs56Zh2i3izbKMvAQXAThCmekmVODlzH7Bs2hqQSFG5oINsZ4 ybmqyDznzbhgOIHPGAXEzBwJv3ELrjHMww75guwLQQQzvARJHhGyCKGyxReIEc/C5cYl ARYQ== Received: by 10.101.105.24 with SMTP id h24mr7691746anm.53.1352924556756; Wed, 14 Nov 2012 12:22:36 -0800 (PST) Received: from [192.168.1.211] (190-20-39-191.baf.movistar.cl. [190.20.39.191]) by mx.google.com with ESMTPS id m51sm13859032yhh.16.2012.11.14.12.22.33 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Nov 2012 12:22:35 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_391C727C-465D-4539-B779-4D16BD2C5C19" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <50A3E044.5000202@stpeter.im> Date: Wed, 14 Nov 2012 17:22:26 -0300 Message-Id: <5B22209B-4ED8-402E-A0DD-1BC64416FFA0@ve7jtb.com> References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im> <509991D0.9000007@ninebynine.org> <5099F175.3060703@stpeter.im> <509BA2F2.6000006@stpeter.im> <509CEA8B.7020507@ninebynine.org> <50A3E044.5000202@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnCebaj3wzHxAqhEPqTFW2AKZSK2Um4mqqLolQPY9VaGUFT6mYe9C21O7CfWq1KpUINxce5 Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 14 Nov 2012 20:22:41 -0000 --Apple-Mail=_391C727C-465D-4539-B779-4D16BD2C5C19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The two ways of looking at it are the problem I have had for some time = with the acct: uri . If acct: is purely an identifier that is passed as a parameter then I = think the argument for having it's own scheme rather than a URN = namespace turns on how to encode a @. There are other ways to pass identifiers (Handle etc) that have yet to = require dedicated schemes. The value of a scheme comes from the ability to use follow your nose. =20= Without tying acct: to a resolution protocol you have ambiguity , = acct:ve7jtb@ve7jtb.com may be interpreted as different accounts by = different protocols. If we want to tie WF resolution to acct: we should just say so. It was = part of the WF spec so it shouldn't be a surprise. I think the argument for registering a scheme is weak without it. John B. On 2012-11-14, at 3:17 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 11/9/12 4:35 AM, Graham Klyne wrote: >> On 08/11/2012 12:17, Peter Saint-Andre wrote: >>> Hi Graham, >>>=20 >>> Thanks again for sharing your thoughts on the matter. I happened >>> to chat about this with a few folks here at the IETF meeting in >>> Atlanta, and here is how I see it... >>>=20 >>> We have this protocol called WebFinger: in order to retrieve >>> pointers to further information about a person associated with a >>> domain, a client sends a special HTTP request to a server at that >>> domain and passes as a parameter in that request a URI that >>> identifies the person. That URI could be a 'mailto:', 'sip:', >>> 'xmpp:', 'callto:' (?), or other URI that includes an identifier >>> for the person (i.e., for an account controlled by the person). >>>=20 >>> When the client completes that operation, is it dereferencing >>> the 'mailto:', 'sip:', 'xmpp:' (etc.) URI that is passed as a >>> parameter? Or it dereferencing the HTTP URL to which it sends the >>> request? Example: >>>=20 >>> http://example.com/lrdd/?f=3Djson&uri=3Dxmpp%3Abob%40example.com >>>=20 >>> This might only indicate my ignorance of URIs, but that example >>> doesn't feel to me like a dereferencing of an 'xmpp:' URI, which >>> I would expect to be something like this (see XEP-0054 at >>> xmpp.org): >>>=20 >>> xmpp:bob@example.com?vcard >>=20 >> You're right. It's dereferencing an HTTP URI which happens to >> contain an encoded xmpp URI (but HTTP protocol doesn't know about >> that). >>=20 >>> Instead, the URI that is passed as a parameter in the WebFinger=20 >>> operation feels to me like something that is used purely for=20 >>> identification, not interaction (dereferencing). >>>=20 >>> If that line of reasoning is just wrong, please do let me know. >>> :-) >>=20 >> I don't disagree with anything you've said here. >>=20 >> But it doesn't say anything about what you do when starting with >> an acct: URI and want to find out more. >=20 > I think the short answer is: Don't do that. :) >=20 > As I understand it, an acct: URI is not intended to be used directly > as a way to "find out more". It's something that is passed around in > the background, not exposed to humans. It's a kind of abstract > identifier, if you will. >=20 >> Let me posit for the purpose of debate that dereferencing an acct: >> URI is done using WebFinger. >=20 > If that's what folks wanted all long, I wish they'd called it > webfinger: or wf:, not acct:... >=20 >> It happens that execution of the WebFinger protocol involves >> dereferencing HTTP URIs, and those HTTP URIs may contain references >> to (parts of) the acct: URIs, or any other ind of URI. So >> dereferencing an acct: URI involves constructing an http: URI and >> then dereferencing that. I see no conflict here. >=20 > Yes, that makes sense if we're talking about something that is > specific to the WebFinger protocol. If, say, the Simple Web Discovery > protocol or some other protocol decides to use acct: URIs then saying > that a bare acct: URI is dereferenced by performing a WebFinger > operation seems wrong to me. >=20 >>> The WebFinger community, through much conversation over the >>> years, decided that it was potentially confusing to use 'mailto:' >>> URIs when passing a parameter in the WebFinger operation, >>> primarily because there might not be an email service running at >>> the domain or associated with that person, and perhaps >>> secondarily because they didn't want to set up the expectation >>> that the requesting entity was initiating any kind of email-based >>> interaction. Therefore, they decided to define a neutral URI=20 >>> scheme that would be used purely for identification. >>=20 >> Sure, no argument here from me. >>=20 >>> As I understand it, there is no expection that an HTML href >>> attribute containing an 'acct:' URI would trigger a WebFinger >>> interaction: >>>=20 >>> info >>=20 >> Maybe that's where our positions differ. I think it's quite >> reasonable that an acct: URI could in principle, be used in this >> way (i.e. as an arbitrary link in a document. Modulo >> implementation support, of course). >>=20 >> And that kind of dereferencing may not be what the WebFinger >> designers had in mind, but they have chosen to adopt an artifact >> (URI) from another framework (the Web), so there are expectations >> that might be associated with that artifact. Web architecture >> tries to maintain a separation of purpose between URIs and >> protocols: in principle (though not always in practice) an >> application that uses a URI in a generic way (such as in HTML @href >> values) should strive be "colour blind" with respect to the URI >> provided (cf. "URI Opacity" -=20 >> http://www.w3.org/TR/webarch/#uri-opacity) ... >=20 > What are the practical implications of URI opacity in this context? >=20 >>> Instead, the client would need to include the correct HTTP URL: >>>=20 >>> >>=20 >> = href=3D'http://example.com/lrdd/?f=3Djson&uri=3Dxmpp%3Abob%40example.com'>= info >>=20 >>=20 >>=20 >> ... In this case, I'd say the application that is generating a web >> page with a link in it should ideally not have to treat the acct: >> scheme differently (i.e. not need know that it has to generate the=20 >> corresponding WebFinger http: URI) - that level of treatment is, >> IMO, best taken as part of the dereferencing semantics of the URI >> scheme itself, not the application that uses it. >>=20 >>> Therefore, I continue to think that 'acct:' URIs are used purely >>> for identification and not at all for interaction. It's just a >>> parameter that you pass in the query part of an HTTP URL, not a >>> URI that you dereference directly. >>>=20 >>> If those who know more about URIs or WebFinger than I do disagree >>> with the foregoing characterization, I'd love to hear it. >>=20 >> I don't think there's a definitive right-or-wrong position here. I >> just feel that, to the extent that acct: *is* associated with a >> specific protocol, that the dereferencing mechanism should be part >> of the URI specification. >=20 > I think we all agree on that. The question is whether acct: is indeed > strongly associated with the WebFinger protocol. That doesn't feel > right to me, but if that's what we decide in the working group here > then I'm happy to update the spec accordingly. >=20 >> You appear see acct: as a kind of URN (in the broad sense of URN), >> I prefer to see it as a kind of URL. >=20 > In the terms of RFC 3986 (Section 1.2.2), I see acct: as a URI that > provides identification, whereas you see acct: as a URI that enables > interaction (i.e., access to a resource in the form of a JSON Resource > Decriptor via the WebFinger protocol). Are identification-only URIs > limited to URNs ("in the broad sense")? >=20 >> Either is technically acceptable, but I feel the URL view is >> potentially more useful as, among other things, it enables >> (automatable) follow-your-nose discovery to be associated with >> acct: URIs. >=20 > Usefulness might be in the eye of the beholder or depend on the > application one has in mind. Designers of protocols other than > WebFinger might find it useful to have a URI scheme that provides pure > identification of an account at a service, which is how I've always > understood the acct: URI scheme. >=20 > Clearly, the two of us see things in different ways. IMHO we might > need the APPSAWG chairs to issue a call for consensus so that we can > get unstuck here... >=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://www.enigmail.net/ >=20 > iEYEARECAAYFAlCj4EQACgkQNL8k5A2w/vwSggCcDIIHvucqEps47SpAPEYD0asx > CEYAnRInk9UTnZLTXAhwRjUharbJ3n9/ > =3DxuTL > -----END PGP SIGNATURE----- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_391C727C-465D-4539-B779-4D16BD2C5C19 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = two ways of looking at it are the problem I have had for some time with = the acct: uri .

If acct:  is purely an = identifier that is passed as a parameter then I think the argument for = having it's own scheme rather than a URN namespace turns on how to = encode a @.
There are other ways to pass identifiers  (Handle etc) that have yet to = require dedicated schemes.

The value of a = scheme comes from the ability to use follow your nose. =  

Without tying acct: to a resolution = protocol you have ambiguity , acct:ve7jtb@ve7jtb.com may be interpreted as = different accounts by different protocols.

If = we want to tie WF resolution to acct: we should just say so.   It = was part of the WF spec so it shouldn't be a = surprise.

I think the argument for registering = a scheme is weak without it.

John = B.


On 2012-11-14, at = 3:17 PM, Peter Saint-Andre <stpeter@stpeter.im> = wrote:

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

On = 11/9/12 4:35 AM, Graham Klyne wrote:
On = 08/11/2012 12:17, Peter Saint-Andre wrote:
Hi= Graham,

Thanks again for sharing your thoughts on the matter. I = happened
to chat about this with a few folks here at the IETF meeting = in
Atlanta, and here is how I see it...

We have this protocol = called WebFinger: in order to retrieve
pointers to further = information about a person associated with a
domain, a client sends a = special HTTP request to a server at that
domain and passes as a = parameter in that request a URI that
identifies the person. That URI = could be a 'mailto:', 'sip:',
'xmpp:', 'callto:' (?), or other URI that includes an = identifier
for the person (i.e., for an account controlled by the = person).

When the client completes that operation, is it = dereferencing
the 'mailto:', 'sip:', 'xmpp:' (etc.) URI that is = passed as a
parameter? Or it dereferencing the HTTP URL to which it = sends the
request? Example:

http://example.com/lrdd/?f=3Djson&uri=3Dxmpp%3Abob%40example.com

This might only indicate my ignorance of URIs, but that = example
doesn't feel to me like a dereferencing of an 'xmpp:' URI, = which
I would expect to be something like this (see XEP-0054 = at
xmpp.org):

xmpp:bob@example.com?vcard

You= 're right.  It's dereferencing an HTTP URI which happens = to
contain an encoded xmpp URI (but HTTP protocol doesn't know = about
that).

Instead, the URI that = is passed as a parameter in the WebFinger
operation feels to me like = something that is used purely for
identification, not interaction = (dereferencing).

If that line of reasoning is just wrong, please = do let me know.
:-)

I don't disagree with = anything you've said here.

But it doesn't say anything about what = you do when starting with
an acct: URI and want to find out = more.

I think the short answer is: Don't do that. = :)

As I understand it, an acct: URI is not intended to be used = directly
as a way to "find out more". It's something that is passed = around in
the background, not exposed to humans. It's a kind of = abstract
identifier, if you will.

Let = me posit for the purpose of debate that dereferencing an acct:
URI is = done using WebFinger.

If that's what folks wanted = all long, I wish they'd called it
webfinger: or wf:, not = acct:...

It happens that execution of = the WebFinger protocol involves
dereferencing HTTP URIs, and those = HTTP URIs may contain references
to (parts of) the acct: URIs, or any = other ind of URI.  So
dereferencing an acct: URI involves = constructing an http: URI and
then dereferencing that.  I see no = conflict here.

Yes, that makes sense if we're = talking about something that is
specific to the WebFinger protocol. = If, say, the Simple Web Discovery
protocol or some other protocol = decides to use acct: URIs then saying
that a bare acct: URI is = dereferenced by performing a WebFinger
operation seems wrong to = me.

The = WebFinger community, through much conversation over the
years, = decided that it was potentially confusing to use 'mailto:'
URIs when = passing a parameter in the WebFinger operation,
primarily because = there might not be an email service running at
the domain or = associated with that person, and perhaps
secondarily because they = didn't want to set up the expectation
that the requesting entity was = initiating any kind of email-based
interaction. Therefore, they = decided to define a neutral URI
scheme that would be used purely for = identification.

Sure, no argument here from = me.

As I understand it, there is no = expection that an HTML href
attribute containing an 'acct:' URI would = trigger a WebFinger
interaction:

<a = href=3D'acct:bob@example'>info</a>

Maybe = that's where our positions differ.  I think it's = quite
reasonable that an acct: URI could in principle, be used in = this
way (i.e. as an arbitrary link in a document. =  Modulo
implementation support, of course).

And that kind = of dereferencing may not be what the WebFinger
designers had in mind, = but they have chosen to adopt an artifact
(URI) from another = framework (the Web), so there are expectations
that might be = associated with that artifact.  Web architecture
tries to = maintain a separation of purpose between URIs and
protocols: in = principle (though not always in practice) an
application that uses a = URI in a generic way (such as in HTML @href
values) should strive be = "colour blind" with respect to the URI
provided (cf. "URI Opacity" - =
http://www.w3.org/TR/we= barch/#uri-opacity) ...

What are the practical = implications of URI opacity in this context?

Instead, the client would need = to include the correct HTTP = URL:

<a

href=3D'http://example.com/lrdd/?f=3Djson&uri=3Dxmpp%3Abob%40example.com'= >info</a>



... In  this case, I'd say = the application that is generating a web
page with a link in it = should ideally not have to treat the acct:
scheme differently (i.e. = not need know that it has to generate the
corresponding WebFinger = http: URI) - that level of treatment is,
IMO, best taken as part of = the dereferencing semantics of the URI
scheme itself, not the = application that uses it.

Therefore, I = continue to think that 'acct:' URIs are used purely
for = identification and not at all for interaction. It's just a
parameter = that you pass in the query part of an HTTP URL, not a
URI that you = dereference directly.

If those who know more about URIs or = WebFinger than I do disagree
with the foregoing characterization, I'd = love to hear it.

I don't think there's a definitive = right-or-wrong position here.  I
just feel that, to the extent = that acct: *is* associated with a
specific protocol, that the = dereferencing mechanism should be part
of the URI = specification.

I think we all agree on that. The = question is whether acct: is indeed
strongly associated with the = WebFinger protocol. That doesn't feel
right to me, but if that's what = we decide in the working group here
then I'm happy to update the spec = accordingly.

You appear see acct: as a = kind of URN (in the broad sense of URN),
I prefer to see it as a kind = of URL.

In the terms of RFC 3986 (Section 1.2.2), I = see acct: as a URI that
provides identification, whereas you see = acct: as a URI that enables
interaction (i.e., access to a resource = in the form of a JSON Resource
Decriptor via the WebFinger protocol). = Are identification-only URIs
limited to URNs ("in the broad = sense")?

Either is technically = acceptable, but I feel the URL view is
potentially more useful as, = among other things, it enables
(automatable) follow-your-nose = discovery to be associated with
acct: = URIs.

Usefulness might be in the eye of the beholder = or depend on the
application one has in mind. Designers of protocols = other than
WebFinger might find it useful to have a URI scheme that = provides pure
identification of an account at a service, which is how = I've always
understood the acct: URI scheme.

Clearly, the two = of us see things in different ways. IMHO we might
need the APPSAWG = chairs to issue a call for consensus so that we can
get unstuck = here...

Peter

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


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

iEYEARECAAYFAlCj4EQACgkQNL8k5A2w/vwSggCcDI= IHvucqEps47SpAPEYD0asx
CEYAnRInk9UTnZLTXAhwRjUharbJ3n9/
=3DxuTL
-= ----END PGP = SIGNATURE-----
_______________________________________________
apps-= discuss mailing = list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/app= s-discuss

= --Apple-Mail=_391C727C-465D-4539-B779-4D16BD2C5C19-- From presnick@qti.qualcomm.com Wed Nov 14 13:49: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 E995221F84ED for ; Wed, 14 Nov 2012 13:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 O8UuQAWFJlzo for ; Wed, 14 Nov 2012 13:49:58 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2A77A21F84E1 for ; Wed, 14 Nov 2012 13:49:58 -0800 (PST) X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="6890069" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 14 Nov 2012 13:34:56 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="370609133" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Nov 2012 13:49:57 -0800 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 14 Nov 2012 13:48:21 -0800 Message-ID: <50A411A3.6060600@qti.qualcomm.com> Date: Wed, 14 Nov 2012 15:48:19 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: IETF Apps Discuss Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Subject: [apps-discuss] AD Fail - MPTCP API 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, 14 Nov 2012 21:49:59 -0000 If I were a good AD, I'd have been monitoring this all along and would have given a long heads up, before IETF Last Call. If I were a good AD, I would have asked for an Apps Directorate review. Now, Last Call complete and less than 19 hours before an IESG Telechat, I come to you, head hung in shame. Bad Pete. https://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ is on tomorrow's telechat. I love MPTCP and think it is exactly the right way to deal with multiple interfaces, but some of the stuff in this particular document makes me nervous. Unfortunately, I have not written any code to a sockets API in too long. I have already bugged two people for comments (thanks Chris and Cyrus), but I wouldn't mind more people looking at this document. It's only Informational, but I am quite sure people will start coding this stuff. I'm personally more worried about the legacy API interactions (see section 4.2.2 in particular), but if you have thoughts on the new APIs as well, they would be welcome. I'm going to be writing up my comments, but at this point I'm not planning on asking to DISCUSS it. But if anyone has concerns where you think, "Holy crap! You can't let people start coding that, even if it is just experimental!", you've got not much time to let me know. Begging your forgiveness, pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From mnot@mnot.net Wed Nov 14 16:37: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 A333721F8772 for ; Wed, 14 Nov 2012 16:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.071 X-Spam-Level: X-Spam-Status: No, score=-105.071 tagged_above=-999 required=5 tests=[AWL=-2.472, 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 wxAzUYKjo1Oo for ; Wed, 14 Nov 2012 16:37:30 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2826D21F86E4 for ; Wed, 14 Nov 2012 16:37:30 -0800 (PST) Received: from [192.168.1.64] (unknown [118.209.81.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5861F509B5; Wed, 14 Nov 2012 19:37:28 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <50A38259.4050304@googlemail.com> Date: Thu, 15 Nov 2012 11:37:29 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <3B530232-381D-4370-980B-B5B308443DDF@mnot.net> References: <50A38259.4050304@googlemail.com> To: Dirk F5R X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] json-home: comments and questions on draft 02 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, 15 Nov 2012 00:37:32 -0000 On 14/11/2012, at 10:36 PM, Dirk F5R wrote: > Hi all, hi Mark, >=20 > I had a closer look at = http://pretty-rfc.herokuapp.com/draft-nottingham-json-home and = http://tools.ietf.org/html/draft-nottingham-json-home-02 since I also = absolutely see the need for an API "home page" as well. As a matter of = fact, the specs I have contributed to at work come with what we call a = "service document" (I can't help using that term in the remainder of = this mail). This is only another term for basically the same concept: = one single entry point into a hypermedia API that reveals links to = something like top-level resources. The URI to the service document is = the only thing that needs to be published to client developers, from = there we strictly follow the HATEOAS principle. >=20 > I have a few comments / questions on json-home: >=20 > When I look at the json-home draft, it looks to me as if it were = actually two separate ones. One that deals with the need of a service = document and how it might look like and one that defines how links = should look like in JSON. The latter one though is nothing specific to = the service document but would rather be a general convention. Shouldn't = this be two separate draft documents? Possibly. The thing is, I'm not yet convinced that there's a single = style of linking that's right for all uses -- or even a majority of = cases -- in JSON, so I haven't tackled this yet. Having a home document = seemed to be the low-hanging fruit, and I expect that if we do one day = have a predominant way of linking in JSON, we'll converge on that = somehow. I have talked to Mike about HAL; it may be a contender for enough use = cases to be interesting, but I didn't want to tie the fate of this spec = to HAL. In the meantime, the links in json-home are interoperable with other = serialisations of links (including HAL). The important thing is that the = underlying semantics of the link are well-defined, as per RFC5988. The = syntax doesn't matter as much (caveat: see below). > As to my current perception, I'm also not sure why the service = document should have a different format or structure than any other = document that comes back from an API. For instance, if your = representations always come with an attribute called "links" that hosts = explicit links by relation types, why should this be different for the = service document? This leads me to the opinion that it should be defined = as a requirement that hypermedia APIs must come with a = service document but I don't necessarily see the need to define a = particular format or media type for it. Well, we get concrete benefits when off-the-shelf software can consume a = known format; having to relearn every format as you encounter it is = expensive (in money, time and effort) and error-prone. My observation is that coming up with a framework that abstracts out the = world into a single format convention is Hard (see: RDF), so I decided = to try something more modest here. People intuitively understand "home = document." Cheers, -- Mark Nottingham http://www.mnot.net/ From ned.freed@mrochek.com Wed Nov 14 19:19:55 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 9DA3C21F8514 for ; Wed, 14 Nov 2012 19:19:55 -0800 (PST) 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 uhktuDbNHcgR for ; Wed, 14 Nov 2012 19:19:55 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 29FA321F8512 for ; Wed, 14 Nov 2012 19:19:55 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMMH6H9UVK001O0E@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 14 Nov 2012 19:14:51 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMGB2WUMLC00008S@mauve.mrochek.com>; Wed, 14 Nov 2012 19:14:49 -0800 (PST) Message-id: <01OMMH6GA83U00008S@mauve.mrochek.com> Date: Wed, 14 Nov 2012 19:06:32 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 14 Nov 2012 15:48:19 -0600" <50A411A3.6060600@qti.qualcomm.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <50A411A3.6060600@qti.qualcomm.com> To: Pete Resnick Cc: IETF Apps Discuss Subject: Re: [apps-discuss] AD Fail - MPTCP API 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, 15 Nov 2012 03:19:55 -0000 I noted this text: As this address may not be valid any more if the first subflow is closed, the MPTCP stack MAY close the whole MPTCP connection if the first subflow is closed (i.e. fate sharing between the initial subflow and the MPTCP connection as a whole). Whether to close the whole MPTCP connection by default SHOULD be controlled by a local policy. Further experiments are needed to investigate its implications. Presumably this "local policy" would be set system-wide? If so, that's a poor choice. Such choices need to be able to be made at a finer granularity than this, because in many cases not all connections a system handles have the same security considerations. The lack of user control for things like this has rendered other protocols a lot less useful than they might otherwise have been. Ned From presnick@qti.qualcomm.com Wed Nov 14 19:36: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 08E681F041A for ; Wed, 14 Nov 2012 19:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 zUAaHzLwzOlW for ; Wed, 14 Nov 2012 19:36:00 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id A0CD521F8473 for ; Wed, 14 Nov 2012 19:36:00 -0800 (PST) X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="6956548" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 14 Nov 2012 19:20:58 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="340539399" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Nov 2012 19:35:59 -0800 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 14 Nov 2012 19:35:59 -0800 Message-ID: <50A4631D.2060606@qti.qualcomm.com> Date: Wed, 14 Nov 2012 21:35:57 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ned Freed References: <50A411A3.6060600@qti.qualcomm.com> <01OMMH6GA83U00008S@mauve.mrochek.com> In-Reply-To: <01OMMH6GA83U00008S@mauve.mrochek.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: IETF Apps Discuss Subject: Re: [apps-discuss] AD Fail - MPTCP API 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, 15 Nov 2012 03:36:02 -0000 On 11/14/12 9:06 PM, Ned Freed wrote: > I noted this text: > > As this address may not be valid any more if the first subflow is > closed, the MPTCP stack MAY close the whole MPTCP connection if the > first subflow is closed (i.e. fate sharing between the initial > subflow and the MPTCP connection as a whole). Whether to close the > whole MPTCP connection by default SHOULD be controlled by a local > policy. Further experiments are needed to investigate its > implications. > > Presumably this "local policy" would be set system-wide? If so, that's > a poor > choice. Such choices need to be able to be made at a finer granularity > than > this, because in many cases not all connections a system handles have > the same > security considerations. > > The lack of user control for things like this has rendered other > protocols > a lot less useful than they might otherwise have been. Well, I'd certainly hope in the new APIs, you would be able to set an option to do this. (I expect this would be in the "Advanced API", which this document doesn't lay out.) But for the legacy API, which this paragraph is talking about, I don't see how it could be other than system-wide, since the legacy app is unaware that there's MPTCP going on underneath. That said, I'm not sure why the suggestion is in there in the first place. Under what circumstances would anyone want fate-sharing of the first subflow? Still finishing up my own review, pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From superuser@gmail.com Wed Nov 14 20:51: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 9CFDC21E8050 for ; Wed, 14 Nov 2012 20:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.141, 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 xHq9gTblHwmG for ; Wed, 14 Nov 2012 20:51:45 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC5C921E8048 for ; Wed, 14 Nov 2012 20:51:44 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1019712lah.31 for ; Wed, 14 Nov 2012 20:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=LmbZEqD2Z4OeASpTF9vp0i11ZK/K6h8M/g1910kxErY=; b=ohecstBZrmIjdZKxGhW2neprl6+eX0yp0jBxwmqdZ1Updw8qFpHKmuZFyrWbuGbxo/ N8dwsEG0b6627d2QOhr1ejMoRlr+sImhOE8NVslE7EhY9smGd0B2iheKv1t5mc3WKp7b iI6K0NEZkgE4ze3ZVltxNeEuLGk40fmp/a4mWECZGS/V1RvM44lAUQ6agLgmAbqgzJyL 7NcE0X1UznKmrK5VhFBGhK8FzAdrQ/seOWyQNWzec8/1ZjFW6QaHoM+H/sas+F7cvKUE Z9oO7uZZfyviA6P6wmXMymgZqUJlA5sFauebG9jp5cqQL6DS6iuaHrHRaHNc/6ZMTL44 TO/A== MIME-Version: 1.0 Received: by 10.112.50.205 with SMTP id e13mr121584lbo.63.1352955103730; Wed, 14 Nov 2012 20:51:43 -0800 (PST) Received: by 10.112.80.234 with HTTP; Wed, 14 Nov 2012 20:51:43 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Nov 2012 20:51:43 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d0401fe3b5adc5404ce81687f Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-json-pointer and draft-ietf-appsawg-json-patch 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, 15 Nov 2012 04:51:45 -0000 --f46d0401fe3b5adc5404ce81687f Content-Type: text/plain; charset=ISO-8859-1 This is a reminder about the WGLC in effect for these two documents. So far we have received no reviews or comments of any kind. The WGLC ends in nine days. Please review the documents and provide feedback. Earlier would be better so there's time for discussion during the WGLC if necessary. -MSK, APPSAWG co-chair On Mon, Nov 5, 2012 at 10:12 AM, Murray S. Kucherawy wrote: > As announced during today's meeting in Atlanta, the above two documents > are now in Working Group Last Call, ending November 23rd. > > Please review the documents and provide feedback to the list, the chairs, > or the editors. > > -MSK, APPSAWG co-chair > > --f46d0401fe3b5adc5404ce81687f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is a reminder about the WGLC in effect for these two documents.=A0 So = far we have received no reviews or comments of any kind.=A0 The WGLC ends i= n nine days.

Please review the documents and provide feedback.=A0 Ea= rlier would be better so there's time for discussion during the WGLC if= necessary.

-MSK, APPSAWG co-chair


On Mon, Nov 5, 2012 at 10:12 AM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
As announced during today's meeting in A= tlanta, the above two documents are now in Working Group Last Call, ending = November 23rd.

Please review the documents and provide feedback to the list, the chair= s, or the editors.

-MSK, APPSAWG co-chair


--f46d0401fe3b5adc5404ce81687f-- From mnot@mnot.net Wed Nov 14 23:44: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 A80D221F876A for ; Wed, 14 Nov 2012 23:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.362 X-Spam-Level: X-Spam-Status: No, score=-105.362 tagged_above=-999 required=5 tests=[AWL=-2.763, 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 x0XuGAQ3la4D for ; Wed, 14 Nov 2012 23:44:09 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id E243721F8618 for ; Wed, 14 Nov 2012 23:44:08 -0800 (PST) Received: from [192.168.1.64] (unknown [118.209.81.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2618F509B5; Thu, 15 Nov 2012 02:44:04 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Nov 2012 18:44:20 +1100 Message-Id: <060AEB60-8E59-4AB2-A178-5874BE36AF71@mnot.net> To: draft-ietf-pkix-est.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: Apps Discuss Subject: [apps-discuss] APPDIR review of draft-ietf-pkix-est-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: Thu, 15 Nov 2012 07:44:09 -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 = ). Document: draft-ietf-pkix-est-03 Title: Enrollment over Secure Transport Reviewer: Mark Nottingham Review Date: 15-Nov-2012 Summary: This draft is not ready for publication as a Proposed Standard = and should be revised before publication. Major Issues:=20 As written, this draft violates BCP56, "On the use of HTTP as a = Substrate:" > 2. New protocols - including but not limited to those using HTTP - > should not attempt to circumvent users' firewall policies, > particularly by masquerading as existing protocols. > "Substantially new services" should not reuse existing ports. >=20 > 3. In general, new protocols or services should not reuse http: or > other URL schemes. While there has been longstanding discussion about obsoleting BCP56, = because it's acknowledged that HTTP is useful for other protocols, that = document has not yet been published.=20 However, when it is, it's very likely to embody the intent behind = RFC5785 -- that the HTTP URI namespace of hosts is under their = individual control, and that standards ought not impinge upon it in any = way, except in the limited ways described by that document. In other words, IETF standards should not define URIs or patterns of = URIs, because servers may wish to provide other services (implying the = possibility of collision), or deploy resources in an alternate way, for = implementation or operational reasons.=20 This is a fundamental concept in the Web architecture; see = .=20 Possible remedies include: 1) Specifying a "home document" format that links (in the RFC5988 sense) = to the various resources as appropriate.=20 2) Specifying a well-known URI to root the interaction. Note that this = is suboptimal; while it avoids collisions, it does not allow alternate = deployments, or multiple deployments on the same host. Regards, -- Mark Nottingham http://www.mnot.net/ From mikekelly321@gmail.com Thu Nov 15 01:50: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 9988721F84CA for ; Thu, 15 Nov 2012 01:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 a6DDT2J+ytRN for ; Thu, 15 Nov 2012 01:50:31 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0AA21F84C4 for ; Thu, 15 Nov 2012 01:50:31 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1535478oag.31 for ; Thu, 15 Nov 2012 01:50:30 -0800 (PST) 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=XdvQ2c/pEoQjKq6ZTvg0bBDY4phwuUnuvZNxi6tMSo0=; b=g6mKG5zkMJLXhQ7j2IpEekm18+ZclA3cOK6YJBRWAyb88Wgwp5zoLwIS56HVSjEhuP EvZKK+gJcp4CV0XrJHHix8YCL5mJnzGqlEBUKGX9PyUTnqYv0GjnhbWqHRa0YknRMNuR KrV4NjzqARm0691n/MeiPJB9mr9QcX8XyyML9anJuzBDi7UB+x5pVKwZdGj1NzuyqPlg Pa+O5jrhpBdfQRLde+GplStbBWoZDHJgfXIotL1XkpyWeIDlz3z+P5g0UeMSa0wngz9I KqYe8W0Ch7GiLCddPWE0ukGLVKWnjNfpF5EiEZLQLPRojMBTpA78NcpdNK7eH7YLkr+G ByeQ== MIME-Version: 1.0 Received: by 10.60.13.198 with SMTP id j6mr416751oec.51.1352973030607; Thu, 15 Nov 2012 01:50:30 -0800 (PST) Received: by 10.60.48.99 with HTTP; Thu, 15 Nov 2012 01:50:30 -0800 (PST) In-Reply-To: <3B530232-381D-4370-980B-B5B308443DDF@mnot.net> References: <50A38259.4050304@googlemail.com> <3B530232-381D-4370-980B-B5B308443DDF@mnot.net> Date: Thu, 15 Nov 2012 09:50:30 +0000 Message-ID: From: Mike Kelly To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] json-home: comments and questions on draft 02 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, 15 Nov 2012 09:50:32 -0000 On Thu, Nov 15, 2012 at 12:37 AM, Mark Nottingham wrote: > > On 14/11/2012, at 10:36 PM, Dirk F5R wrote: > >> Hi all, hi Mark, >> >> I had a closer look at http://pretty-rfc.herokuapp.com/draft-nottingham-= json-home and http://tools.ietf.org/html/draft-nottingham-json-home-02 sinc= e I also absolutely see the need for an API "home page" as well. As a matte= r of fact, the specs I have contributed to at work come with what we call a= "service document" (I can't help using that term in the remainder of this = mail). This is only another term for basically the same concept: one single= entry point into a hypermedia API that reveals links to something like top= -level resources. The URI to the service document is the only thing that ne= eds to be published to client developers, from there we strictly follow the= HATEOAS principle. >> >> I have a few comments / questions on json-home: >> >> When I look at the json-home draft, it looks to me as if it were actuall= y two separate ones. One that deals with the need of a service document and= how it might look like and one that defines how links should look like in = JSON. The latter one though is nothing specific to the service document but= would rather be a general convention. Shouldn't this be two separate draft= documents? > > Possibly. The thing is, I'm not yet convinced that there's a single style= of linking that's right for all uses -- or even a majority of cases -- in = JSON, so I haven't tackled this yet. Having a home document seemed to be th= e low-hanging fruit, and I expect that if we do one day have a predominant = way of linking in JSON, we'll converge on that somehow. > > I have talked to Mike about HAL; it may be a contender for enough use cas= es to be interesting, but I didn't want to tie the fate of this spec to HAL= . > > In the meantime, the links in json-home are interoperable with other seri= alisations of links (including HAL). The important thing is that the underl= ying semantics of the link are well-defined, as per RFC5988. The syntax doe= sn't matter as much (caveat: see below). > > >> As to my current perception, I'm also not sure why the service document = should have a different format or structure than any other document that co= mes back from an API. For instance, if your representations always come wit= h an attribute called "links" that hosts explicit links by relation types, = why should this be different for the service document? This leads me to the= opinion that it should be defined as a requirement that hyperm= edia APIs must come with a service document but I don't necessarily see the= need to define a particular format or media type for it. > > > Well, we get concrete benefits when off-the-shelf software can consume a = known format; having to relearn every format as you encounter it is expensi= ve (in money, time and effort) and error-prone. > > My observation is that coming up with a framework that abstracts out the = world into a single format convention is Hard (see: RDF), so I decided to t= ry something more modest here. People intuitively understand "home document= ." > RDF made its own life hard by forcing a graph model down into the data. That is not what HAL is about. HAL is conventions that allow you to use link relations to identify the relationships between resources in your application, via outbound links and containment (aka 'embedded-ness'). The way HAL represents the state of the resources is just to defer to plain old JSON, there's no special model for the data. In practice, all HAL really does is add two reserved properties to the JSON representations you already expose, namely "_links" and "_embedded". So for me, it doesn't really make much sense to compare RDF with HAL. The word count on the JSON-LD spec vs the hal+json spec should say it all! :) Cheers, M From GK@ninebynine.org Thu Nov 15 05:37: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 B3FD321F88D4 for ; Thu, 15 Nov 2012 05:37:28 -0800 (PST) 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 xfVfAWRt-HQy for ; Thu, 15 Nov 2012 05:37:28 -0800 (PST) Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2395C21F88B6 for ; Thu, 15 Nov 2012 05:37:28 -0800 (PST) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TYzdH-0001Q9-0K; Thu, 15 Nov 2012 13:37:27 +0000 Received: from m952436d0.tmodns.net ([208.54.36.149] helo=[192.168.43.120]) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TYzdG-0006mU-7a; Thu, 15 Nov 2012 13:37:27 +0000 Message-ID: <50A4E7FD.5000705@ninebynine.org> Date: Thu, 15 Nov 2012 13:02:53 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mike Kelly References: <50A38259.4050304@googlemail.com> <3B530232-381D-4370-980B-B5B308443DDF@mnot.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: IETF Apps Discuss Subject: [apps-discuss] Links and graphs (was: json-home: comments and questions on draft 02) 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, 15 Nov 2012 13:37:28 -0000 On 15/11/2012 09:50, Mike Kelly wrote: > RDF made its own life hard by forcing a graph model down into the > data. That is not what HAL is about. I don't follow what you're saying here. I don't disagree (as someone involved with RDF) that RDF has made its life hard in several ways, but if what you have and want to pass around is a graph, how does one *not* push it down into the data? (Personally, I'd like to see json-home be something that has a clear mapping to RDF, but that's a different discussion.) #g -- From mikekelly321@gmail.com Thu Nov 15 05: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 8818721F852D for ; Thu, 15 Nov 2012 05:50:31 -0800 (PST) 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=[BAYES_00=-2.599, 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 ClbAr1o5bCBg for ; Thu, 15 Nov 2012 05:50:31 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3F9521F84FB for ; Thu, 15 Nov 2012 05:50:30 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1097208eek.31 for ; Thu, 15 Nov 2012 05:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=tdLOCuITs+5963Ui9tf5zCUBmdSP3TDnP/Igu0UHm6M=; b=eBEcsjJwsFD0eWibaHz7VIxFPhVRsThldxGm/tZ6DBCfu2kbDlQURHXnqZlLAovFQJ 2Ky2G51FZDAuUfpIerPZhSL15R1yZFamLXMV4+7zewqp3WLa8VtGJLs5jdIXL+WS90Kp AFSiTmFfdP2PO7aXSxPSwEkvPgcu4ehroK/cJ5EOyEPdP5IEFUxWXRx2Bj1APkIvY+0h tLG85eIGeYWyvGqLYsxslFD9/nI9k28fTx0C72ld7Zoc/iLuHxDLOTOU7vvO8m0tKaxV 9AdY3/RzrR1aYXeIxoI+T3Mx4Z/RY1BNnWjHVp9XBgaZYC2x48wmBhRk70iHVzUUDzzQ KCnw== Received: by 10.14.179.6 with SMTP id g6mr3779513eem.46.1352987429907; Thu, 15 Nov 2012 05:50:29 -0800 (PST) Received: from [10.175.97.169] ([212.183.128.111]) by mx.google.com with ESMTPS id d44sm36311879eeo.10.2012.11.15.05.50.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 05:50:29 -0800 (PST) References: <50A38259.4050304@googlemail.com> <3B530232-381D-4370-980B-B5B308443DDF@mnot.net> <50A4E7FD.5000705@ninebynine.org> In-Reply-To: <50A4E7FD.5000705@ninebynine.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Mike Kelly Date: Thu, 15 Nov 2012 13:50:22 +0000 To: Graham Klyne Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Links and graphs (was: json-home: comments and questions on draft 02) 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, 15 Nov 2012 13:50:31 -0000 On 15 Nov 2012, at 13:02, Graham Klyne wrote: > On 15/11/2012 09:50, Mike Kelly wrote: >> RDF made its own life hard by forcing a graph model down into the >> data. That is not what HAL is about. >=20 > I don't follow what you're saying here. I don't disagree (as someone invo= lved with RDF) that RDF has made its life hard in several ways, but if what y= ou have and want to pass around is a graph, how does one *not* push it down i= nto the data? Sorry I wasn't clear, I was claiming RDF's problem as a general purpose mode= l is that it assumes what you have and want to pass around is a graph. Most n= ormal people do not have that requirement they are happy with plain old JSON= and links between their resources.. so RDF carries a whole load of spec-blo= ating baggage around with it that a lot of people don't want. Cheers, M= From ned.freed@mrochek.com Thu Nov 15 06:32: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 59F2421F8891 for ; Thu, 15 Nov 2012 06:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 2y9zjiT4fwmq for ; Thu, 15 Nov 2012 06:32:24 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9534221F88A9 for ; Thu, 15 Nov 2012 06:32:24 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMMYVVI5G0001QCL@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 15 Nov 2012 03:41:42 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMGB2WUMLC00008S@mauve.mrochek.com>; Thu, 15 Nov 2012 03:41:39 -0800 (PST) Message-id: <01OMMYVTHCB000008S@mauve.mrochek.com> Date: Thu, 15 Nov 2012 03:37:56 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 14 Nov 2012 21:35:57 -0600" <50A4631D.2060606@qti.qualcomm.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <50A411A3.6060600@qti.qualcomm.com> <01OMMH6GA83U00008S@mauve.mrochek.com> <50A4631D.2060606@qti.qualcomm.com> To: Pete Resnick Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] AD Fail - MPTCP API 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, 15 Nov 2012 14:32:25 -0000 > On 11/14/12 9:06 PM, Ned Freed wrote: > > I noted this text: > > > > As this address may not be valid any more if the first subflow is > > closed, the MPTCP stack MAY close the whole MPTCP connection if the > > first subflow is closed (i.e. fate sharing between the initial > > subflow and the MPTCP connection as a whole). Whether to close the > > whole MPTCP connection by default SHOULD be controlled by a local > > policy. Further experiments are needed to investigate its > > implications. > > > > Presumably this "local policy" would be set system-wide? If so, that's > > a poor > > choice. Such choices need to be able to be made at a finer granularity > > than > > this, because in many cases not all connections a system handles have > > the same > > security considerations. > > > > The lack of user control for things like this has rendered other > > protocols > > a lot less useful than they might otherwise have been. > Well, I'd certainly hope in the new APIs, you would be able to set an > option to do this. (I expect this would be in the "Advanced API", which > this document doesn't lay out.) But for the legacy API, which this > paragraph is talking about, I don't see how it could be other than > system-wide, since the legacy app is unaware that there's MPTCP going on > underneath. Lots of ways: The obvious one is a sticky per-port default. > That said, I'm not sure why the suggestion is in there in the first > place. Under what circumstances would anyone want fate-sharing of the > first subflow? Because many applications make use of the remote IP address for various reasons, and need to see the original address that was used. Really, this alone looks to me like a recipe for systems enabling MPTCP, seeing a bunch of wierd random failures, and as a result disabling it permanently. Ned From superuser@gmail.com Thu Nov 15 06:36: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 8556E21F88DE for ; Thu, 15 Nov 2012 06:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.137, 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 A7YRFPuSvMQD for ; Thu, 15 Nov 2012 06:36:21 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 95A6B21F88EB for ; Thu, 15 Nov 2012 06:36:20 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1443740lbk.31 for ; Thu, 15 Nov 2012 06:36:16 -0800 (PST) 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=jrzRb/rlXSCn3r4etOCk3S8g8xgOhjmcqNELze2hx7I=; b=0h7JPqpgo1nY7bla3Qfdn8Ee1Op24gz9lK8OtIAm6tuLCOAervxfFsZoWa42eUDMtc pTKGcEXT2UDKmZy8NjKiMHCScct0IRJeV5Gnd8KNnrAjIQPwyOphHTERPhigNjH+r/rn HVnJwMnut2lezMv5sB57HqMlwZ3gjgGZj1nIj7xuIXjzz0qT6PA9YyUb+aiNS2ZA4LOP PfRQgk79C5Vn0hKtrSUPaqjcs6Kzw0zURZU40aYZXk9RhBDS7nmh+PgaCTadcoolirE+ 8KAc9st62wwXNJ9jomVQxE4rW+L4BxrLogy/B6jKrA6A+jaQ5jM1MJNKxR5aWAkiFwOo lUaQ== MIME-Version: 1.0 Received: by 10.152.124.83 with SMTP id mg19mr1284172lab.6.1352990176791; Thu, 15 Nov 2012 06:36:16 -0800 (PST) Received: by 10.112.80.234 with HTTP; Thu, 15 Nov 2012 06:36:16 -0800 (PST) In-Reply-To: <1969645725.20121101120100@w3.org> References: <1969645725.20121101120100@w3.org> Date: Thu, 15 Nov 2012 06:36:16 -0800 Message-ID: From: "Murray S. Kucherawy" To: Chris Lilley Content-Type: multipart/alternative; boundary=f46d042dfc95df4de804ce8992c2 Cc: IETF Apps Discuss , eb2m-mrt@asahi-net.or.jp Subject: Re: [apps-discuss] FW: New Version Notification for draft-lilley-xml-mediatypes-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, 15 Nov 2012 14:36:21 -0000 --f46d042dfc95df4de804ce8992c2 Content-Type: text/plain; charset=ISO-8859-1 So far there's been only one expression of support for processing this through appsawg. Are there any others? Any objections to processing it here? Other suggestions? -MSK, co-chair On Thu, Nov 1, 2012 at 4:01 AM, Chris Lilley wrote: > Hello apps-discuss, > > draft-lilley-xml-mediatypes-00.txt is a restart of a proposed replacement > for RFC3023. The previous attempt foundered because the approach taken > required deprecation of text/xml, and the implementor community was not > happy with that as there is much legacy content using that type that still > has to be supported. > > The present draft takes advantage of recent changes in HTTP-bis which > removes the default charset, and so treats text/xml the same as > application/xml. This approach is also what most implementations already > do, in practice. The present draft also introduces some clarifications on > fragment identifiers for xml, and updates some references. > > It has been suggested that this document would be a good fit for the apps > area WG, and the editors would like to request review and adoption by the > WG (or an alternative suggestion of where/how to handle this document). > > This would be a standards-track document. > > -- > Chris Lilley Technical Director, Interaction Domain > W3C Graphics Activity Lead, Fonts Activity Lead > Co-Chair, W3C Hypertext CG > Member, CSS, WebFonts, SVG Working Groups > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d042dfc95df4de804ce8992c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So far there's been only one expression of support for processing this = through appsawg.=A0 Are there any others?=A0 Any objections to processing i= t here?=A0 Other suggestions?

-MSK, co-chair


On Thu, Nov 1, 2012 at 4:01 AM, Chris Li= lley <chris@w3.org> wrote:
Hello apps-discuss,

draft-lilley-xml-mediatypes-00.txt is a restart of a proposed replacement f= or RFC3023. The previous attempt foundered because the approach taken requi= red deprecation of text/xml, and the implementor community was not happy wi= th that as there is much legacy content using that type that still has to b= e supported.

The present draft takes advantage of recent changes in HTTP-bis which remov= es the default charset, and so treats text/xml the same as application/xml.= This approach is also what most implementations already do, in practice. T= he present draft also introduces some clarifications on fragment identifier= s for xml, and updates some references.

It has been suggested that this document would be a good fit for the apps a= rea WG, and the editors would like to request review and adoption by the WG= (or an alternative suggestion of where/how to handle this document).

This would be a standards-track document.

--
=A0Chris Lilley =A0 Technical Director, Interaction Domain
=A0W3C Graphics Activity Lead, Fonts Activity Lead
=A0Co-Chair, W3C Hypertext CG
=A0Member, CSS, WebFonts, SVG Working Groups
_____________= __________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--f46d042dfc95df4de804ce8992c2-- From tbray@textuality.com Thu Nov 15 06:41: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 9E3B621F88DE for ; Thu, 15 Nov 2012 06:41:47 -0800 (PST) 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 seyhDw+DHaP9 for ; Thu, 15 Nov 2012 06:41:47 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id C517A21F86D1 for ; Thu, 15 Nov 2012 06:41:46 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1784529oag.31 for ; Thu, 15 Nov 2012 06:41:46 -0800 (PST) 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:x-gm-message-state; bh=4nfchtMcQUafYCVRkXVWV1EMiIIKT/CGY1SJBK7Td5s=; b=Rz72yhhnkOfsDAQzzl4+i88rO9axOqKoJukc+2n1J2k/7UTrhqzvzX82+h1pJG97A3 FNpKADRMb+x+MOJ3TgnXGnhnwMrMQpPiI9CAfY4ZeHH583c7GgujR0ywCEcNywLCcqHG Xdww1WoYXjTkn9aW5F3vHI69SpNTjXi8Kv/YjszEOB1RRMAIT82luwbZL9VJijWYpDO7 efeEcURBVPHW34blF460GXH6jZQnESxHzIKkbIq67Oh6PbsgNbwqUUTIe9aL5lNzkZDw 0OM0ZOPHmst3BZFB5TKINItoQObMupEAz/t2cw6x0WcbD8VPnFMFBSTC1mluBdNyEe6Z Cp1A== MIME-Version: 1.0 Received: by 10.182.177.72 with SMTP id co8mr1000942obc.53.1352990506344; Thu, 15 Nov 2012 06:41:46 -0800 (PST) Received: by 10.76.12.134 with HTTP; Thu, 15 Nov 2012 06:41:46 -0800 (PST) X-Originating-IP: [194.78.62.115] In-Reply-To: References: <1969645725.20121101120100@w3.org> Date: Thu, 15 Nov 2012 15:41:46 +0100 Message-ID: From: Tim Bray To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=e89a8f64310483e2c804ce89a636 X-Gm-Message-State: ALoCoQm8uzlH+iJkwzwPXsp9EfFbirRpQYLXXzlMlG3sfYLXhOz7S2WyVJHOe2tawzCR5HyhYtET Cc: Chris Lilley , IETF Apps Discuss , eb2m-mrt@asahi-net.or.jp Subject: Re: [apps-discuss] FW: New Version Notification for draft-lilley-xml-mediatypes-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, 15 Nov 2012 14:41:47 -0000 --e89a8f64310483e2c804ce89a636 Content-Type: text/plain; charset=ISO-8859-1 I would support APPSAWG taking it up. 3023 is so horribly wrong, it would be good to have a sane replacement. -T On Thu, Nov 15, 2012 at 3:36 PM, Murray S. Kucherawy wrote: > So far there's been only one expression of support for processing this > through appsawg. Are there any others? Any objections to processing it > here? Other suggestions? > > -MSK, co-chair > > > On Thu, Nov 1, 2012 at 4:01 AM, Chris Lilley wrote: > >> Hello apps-discuss, >> >> draft-lilley-xml-mediatypes-00.txt is a restart of a proposed replacement >> for RFC3023. The previous attempt foundered because the approach taken >> required deprecation of text/xml, and the implementor community was not >> happy with that as there is much legacy content using that type that still >> has to be supported. >> >> The present draft takes advantage of recent changes in HTTP-bis which >> removes the default charset, and so treats text/xml the same as >> application/xml. This approach is also what most implementations already >> do, in practice. The present draft also introduces some clarifications on >> fragment identifiers for xml, and updates some references. >> >> It has been suggested that this document would be a good fit for the apps >> area WG, and the editors would like to request review and adoption by the >> WG (or an alternative suggestion of where/how to handle this document). >> >> This would be a standards-track document. >> >> -- >> Chris Lilley Technical Director, Interaction Domain >> W3C Graphics Activity Lead, Fonts Activity Lead >> Co-Chair, W3C Hypertext CG >> Member, CSS, WebFonts, SVG Working Groups >> _______________________________________________ >> 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 > > --e89a8f64310483e2c804ce89a636 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would support APPSAWG taking it up.=A0 3023 is so horribly wrong, it woul= d be good to have a sane replacement. -T

= On Thu, Nov 15, 2012 at 3:36 PM, Murray S. Kucherawy <= superuser@gmail.co= m> wrote:
So far there's been only one expression = of support for processing this through appsawg.=A0 Are there any others?=A0= Any objections to processing it here?=A0 Other suggestions?

-MSK, co-chair


On Thu, Nov 1, 2012 at 4:01 AM, Chris Li= lley <chris@w3.org> wrote:
Hello apps-discuss,

draft-lilley-xml-mediatypes-00.txt is a restart of a proposed replacement f= or RFC3023. The previous attempt foundered because the approach taken requi= red deprecation of text/xml, and the implementor community was not happy wi= th that as there is much legacy content using that type that still has to b= e supported.

The present draft takes advantage of recent changes in HTTP-bis which remov= es the default charset, and so treats text/xml the same as application/xml.= This approach is also what most implementations already do, in practice. T= he present draft also introduces some clarifications on fragment identifier= s for xml, and updates some references.

It has been suggested that this document would be a good fit for the apps a= rea WG, and the editors would like to request review and adoption by the WG= (or an alternative suggestion of where/how to handle this document).

This would be a standards-track document.

--
=A0Chris Lilley =A0 Technical Director, Interaction Domain
=A0W3C Graphics Activity Lead, Fonts Activity Lead
=A0Co-Chair, W3C Hypertext CG
=A0Member, CSS, WebFonts, SVG Working Groups
_____________= __________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



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


--e89a8f64310483e2c804ce89a636-- From ietfc@btconnect.com Thu Nov 15 07:06: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 DEEE021F8930 for ; Thu, 15 Nov 2012 07:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.818 X-Spam-Level: X-Spam-Status: No, score=-4.818 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 7e6lvIiyT83X for ; Thu, 15 Nov 2012 07:06:57 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE2921F88E0 for ; Thu, 15 Nov 2012 07:06:56 -0800 (PST) Received: from mail214-co9-R.bigfish.com (10.236.132.234) by CO9EHSOBE027.bigfish.com (10.236.130.90) with Microsoft SMTP Server id 14.1.225.23; Thu, 15 Nov 2012 15:06:54 +0000 Received: from mail214-co9 (localhost [127.0.0.1]) by mail214-co9-R.bigfish.com (Postfix) with ESMTP id BFCAD380115 for ; Thu, 15 Nov 2012 15:06:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 4 X-BigFish: PS4(zzzz1de0h1202h1d1ah1d2ahzz17326ah8275dhz2dh2a8h5a9h668h839hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h304l1155h) Received: from mail214-co9 (localhost.localdomain [127.0.0.1]) by mail214-co9 (MessageSwitch) id 1352992012904569_27413; Thu, 15 Nov 2012 15:06:52 +0000 (UTC) Received: from CO9EHSMHS013.bigfish.com (unknown [10.236.132.247]) by mail214-co9.bigfish.com (Postfix) with ESMTP id B06B91E0049 for ; Thu, 15 Nov 2012 15:06:52 +0000 (UTC) Received: from DB3PRD0710HT001.eurprd07.prod.outlook.com (157.56.253.85) by CO9EHSMHS013.bigfish.com (10.236.130.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 15 Nov 2012 15:06:43 +0000 Received: from DB3PRD0610HT001.eurprd06.prod.outlook.com (157.56.252.53) by pod51017.outlook.com (10.255.75.36) with Microsoft SMTP Server (TLS) id 14.16.239.5; Thu, 15 Nov 2012 15:06:41 +0000 Message-ID: <018f01cdc342$afdbfc20$4001a8c0@gateway.2wire.net> From: t.petch CC: apps-discuss References: <20121105192152.6d65ed7a@bogo><6271c53a-454b-4553-943a-15979db70a00@email.android.com> <325BF877-6D97-4F12-B532-278CFBA0191F@gmail.com> Date: Thu, 15 Nov 2012 15:05:36 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.53] X-OriginatorOrg: btconnect.com Subject: [apps-discuss] IANA considerations in a tangle 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, 15 Nov 2012 15:06:58 -0000 This list has provided a home for a number of considerations of 'IANA Considerations' so I hope it may provide inspiration here. RFC4379 set up a registry http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-p arameters.xml of TLVs (functions) and sub-TLVs (parameters) with each TLV having its own namespace of sub-TLVs. The registry has expanded in both directions, with new TLVs being added and new sub-TLVs being added to existing TLVs. Last year, draft-ietf-mpls-ipv6-pw-lsp-ping added, and changed, the sub-TLVs of TLV Type 1, while draft-ietf-mpls-return-path-specified-lsp-ping added a new TLV, Type 21, and for it, duplicated the existing sub-TLVs of TLV Type 1, an early allocation of which is still visible in the IANA Registry. A later revision of this I-D switched to referencing the then existing sub-TLVs of the Type 1 TLV. This is an active area so more changes are likely - e.g. draft-zjns-mpls-lsp-ping-relay-reply may do so. The question that seems not to have been noticed (until pointed out by a lurker on the list), despite this being an active area, was whether or not the ipv6-pw changes to the sub-TLVs of Type 1 should be carried across to Type 21 or not, and equally, whether reusing the Type 1 sub-TLVs for Type 21 only applied to those then in existence, one of which ipv6-pw was deprecating, or should also be applied to any future updates to the sub-TLVs of Type 1. The ipv6-pw I-D is currently in with the IESG with a DISCUSS suggesting that the relevant part of the subject material belongs in a different WG, which would make the chances of spotting such interactions yet more remote:-( With the benefit of hindsight, RFC4379 might have split the range of sub-TLVs into a part common to all TLVs, and a part unique to a particular TLV; but it didn't and it would be impractical to retrofit that now. How could the IANA considerations be modified to alert those amending the sub-TLVs of Type 1 TLV to the fact that they are used elsewhere, and to alert those reusing the sub-TLVs of another Type of TLV to the fact that a registry of sub-TLVs is volatile and could be added to or deprecated? Since this (almost) did not happen a single list while this topic is still distinctly active, I expect that it will recur. Or do I worry too much? Tom Petch From presnick@qti.qualcomm.com Thu Nov 15 07:19: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 204EB21F892F for ; Thu, 15 Nov 2012 07:19:26 -0800 (PST) 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 MU6-HiRqCYsx for ; Thu, 15 Nov 2012 07:19:25 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4551A21F88EA for ; Thu, 15 Nov 2012 07:19:25 -0800 (PST) X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="7032883" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 15 Nov 2012 07:04:20 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="340819227" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Nov 2012 07:19:24 -0800 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 15 Nov 2012 07:19:23 -0800 Message-ID: <50A507F9.4070103@qti.qualcomm.com> Date: Thu, 15 Nov 2012 09:19:21 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ned Freed References: <50A411A3.6060600@qti.qualcomm.com> <01OMMH6GA83U00008S@mauve.mrochek.com> <50A4631D.2060606@qti.qualcomm.com> <01OMMYVTHCB000008S@mauve.mrochek.com> In-Reply-To: <01OMMYVTHCB000008S@mauve.mrochek.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: IETF Apps Discuss Subject: Re: [apps-discuss] AD Fail - MPTCP API 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, 15 Nov 2012 15:19:26 -0000 On 11/15/12 5:37 AM, Ned Freed wrote: >> Under what circumstances would anyone want fate-sharing of the >> first subflow? > > Because many applications make use of the remote IP address for various > reasons, and need to see the original address that was used. As proposed, the application *does* get to see the original address that was used, fate-sharing or not. I just don't understand why an application would care, on a connection that is still up and running, whether the remote end is still using that same remote IP address. Example: - I get a connection from 1.2.3.4. I note the remote IP address and am happy with it. - MPTCP adds a subflow on my connection from 5.6.7.8. We continue talking. - Remote side shuts down it's interface on 1.2.3.4 (walked out of Starbucks). 5.6.7.8 interface is still operational. Scenario 1. Non-fate-shared: Connection continues from 5.6.7.8 to me. My OS reports back from getpeername() that I am connected to 1.2.3.4, even though that particular subflow is now gone. Scenario 2. Fate-shared: Connection gets closed because the original subflow died. Why would I ever want Scenario 2? > Really, this alone looks to me like a recipe for systems enabling MPTCP, > seeing a bunch of wierd random failures, and as a result disabling it > permanently. If fate-sharing is enabled, that's exactly what I would expect. Are you saying that you think this will happen if fate-sharing is off? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From paul.hoffman@vpnc.org Thu Nov 15 07:24: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 51CF621F8937 for ; Thu, 15 Nov 2012 07:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 dlVKqTa7UYAh for ; Thu, 15 Nov 2012 07:24:23 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA3621F8936 for ; Thu, 15 Nov 2012 07:24:23 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAFFOL0N064198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 15 Nov 2012 08:24:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 15 Nov 2012 07:24:28 -0800 To: "apps-discuss@ietf.org Discuss" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [apps-discuss] Review of draft-ietf-appsawg-json-pointer 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, 15 Nov 2012 15:24:24 -0000 This document mostly looks fine. - I do not understand the use of "-"; at least one use of it in an = application should be given. - If "-" is useful, wouldn't it also be useful to have something that = indicates the (non-existant) member before the first array element? - Editorial nit in section 4: * characters that represent an unsigned base-10 integer value (possibly with leading zeros), making the new referenced value is the array element with the zero-based index identified by the token, or That should either be "the new referenced value is the" or "making the = new referenced value the", I believe. - One of the security considerations is too limited. Note that JSON pointers can contain the NUL (Unicode U+0000) character, which may not be representable in all programming languages. The same is true for all control characters, and for some programming = languages, all non-ASCII characters. Proposed rewording: Note that JSON pointers can contain the NUL (Unicode U+0000) character, control characters, non-ASCII characters, and so on. These characters may not be representable in all programming languages. --Paul Hoffman= From marc.blanchet@viagenie.ca Thu Nov 15 07:31: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 0373621F8488 for ; Thu, 15 Nov 2012 07:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.989 X-Spam-Level: X-Spam-Status: No, score=-101.989 tagged_above=-999 required=5 tests=[AWL=0.610, 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 ePc-NGOGdDey for ; Thu, 15 Nov 2012 07:31:13 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4693C21F891A for ; Thu, 15 Nov 2012 07:31:13 -0800 (PST) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 677C8413CF; Thu, 15 Nov 2012 10:31:12 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <50A507F9.4070103@qti.qualcomm.com> Date: Thu, 15 Nov 2012 10:31:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50A411A3.6060600@qti.qualcomm.com> <01OMMH6GA83U00008S@mauve.mrochek.com> <50A4631D.2060606@qti.qualcomm.com> <01OMMYVTHCB000008S@mauve.mrochek.com> <50A507F9.4070103@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1283) Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] AD Fail - MPTCP API 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, 15 Nov 2012 15:31:14 -0000 to me, it remains to be seen how the interaction of: - happy eyeballs - IPv4 vs IPv6 address family preference - application using a non-80 port and then falling back to port 80/443 = because of outgoing port blocking in some access networks (I wrote a = draft on that) - multiple interfaces which are pretty common these days, such as wifi = and cell data-3G-LTE-... all of those are common cases today, many with specific APIs. Then you = add MP-TCP on top of that. I fail to see how those interactions will work. Each of them, taken = separately, does a good job for its own purpose. but the common case = shall include all of these. Not sure the underlying OS could do all the = job for the APP, too. so, no clear suggestion, but a concern about complexity of apps and how = well these techniques will interact and work each other. Marc. Le 2012-11-15 =E0 10:19, Pete Resnick a =E9crit : > On 11/15/12 5:37 AM, Ned Freed wrote: >=20 >>> Under what circumstances would anyone want fate-sharing of the >>> first subflow? >>=20 >> Because many applications make use of the remote IP address for = various >> reasons, and need to see the original address that was used. >=20 > As proposed, the application *does* get to see the original address = that was used, fate-sharing or not. I just don't understand why an = application would care, on a connection that is still up and running, = whether the remote end is still using that same remote IP address. >=20 > Example: >=20 > - I get a connection from 1.2.3.4. I note the remote IP address and am = happy with it. > - MPTCP adds a subflow on my connection from 5.6.7.8. We continue = talking. > - Remote side shuts down it's interface on 1.2.3.4 (walked out of = Starbucks). 5.6.7.8 interface is still operational. >=20 > Scenario 1. Non-fate-shared: Connection continues from 5.6.7.8 to me. = My OS reports back from getpeername() that I am connected to 1.2.3.4, = even though that particular subflow is now gone. >=20 > Scenario 2. Fate-shared: Connection gets closed because the original = subflow died. >=20 > Why would I ever want Scenario 2? >=20 >> Really, this alone looks to me like a recipe for systems enabling = MPTCP, >> seeing a bunch of wierd random failures, and as a result disabling it >> permanently.=20 >=20 > If fate-sharing is enabled, that's exactly what I would expect. Are = you saying that you think this will happen if fate-sharing is off? >=20 > pr >=20 > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ned.freed@mrochek.com Thu Nov 15 07:56: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 5A13721F8513 for ; Thu, 15 Nov 2012 07:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 furs96Nkn3OF for ; Thu, 15 Nov 2012 07:56:53 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF8721F8506 for ; Thu, 15 Nov 2012 07:56:52 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMN7LZ99BK001QYD@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 15 Nov 2012 07:51:49 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMGB2WUMLC00008S@mauve.mrochek.com>; Thu, 15 Nov 2012 07:51:46 -0800 (PST) Message-id: <01OMN7LXLJ3S00008S@mauve.mrochek.com> Date: Thu, 15 Nov 2012 07:50:27 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 15 Nov 2012 09:19:21 -0600" <50A507F9.4070103@qti.qualcomm.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <50A411A3.6060600@qti.qualcomm.com> <01OMMH6GA83U00008S@mauve.mrochek.com> <50A4631D.2060606@qti.qualcomm.com> <01OMMYVTHCB000008S@mauve.mrochek.com> <50A507F9.4070103@qti.qualcomm.com> To: Pete Resnick Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] AD Fail - MPTCP API 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, 15 Nov 2012 15:56:54 -0000 My mistake, sorry. I misread the text on how this interacts with getpeername. Ned > On 11/15/12 5:37 AM, Ned Freed wrote: > >> Under what circumstances would anyone want fate-sharing of the > >> first subflow? > > > > Because many applications make use of the remote IP address for various > > reasons, and need to see the original address that was used. > As proposed, the application *does* get to see the original address that > was used, fate-sharing or not. I just don't understand why an > application would care, on a connection that is still up and running, > whether the remote end is still using that same remote IP address. > Example: > - I get a connection from 1.2.3.4. I note the remote IP address and am > happy with it. > - MPTCP adds a subflow on my connection from 5.6.7.8. We continue talking. > - Remote side shuts down it's interface on 1.2.3.4 (walked out of > Starbucks). 5.6.7.8 interface is still operational. > Scenario 1. Non-fate-shared: Connection continues from 5.6.7.8 to me. My > OS reports back from getpeername() that I am connected to 1.2.3.4, even > though that particular subflow is now gone. > Scenario 2. Fate-shared: Connection gets closed because the original > subflow died. > Why would I ever want Scenario 2? > > Really, this alone looks to me like a recipe for systems enabling MPTCP, > > seeing a bunch of wierd random failures, and as a result disabling it > > permanently. > If fate-sharing is enabled, that's exactly what I would expect. Are you > saying that you think this will happen if fate-sharing is off? > pr > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 From cyrus@daboo.name Thu Nov 15 07:57: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 DAE2A21F8514 for ; Thu, 15 Nov 2012 07:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 4hlF5IoKUgRf for ; Thu, 15 Nov 2012 07:57:06 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3F34A21F84F8 for ; Thu, 15 Nov 2012 07:57:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 827DE356161F for ; Thu, 15 Nov 2012 10:57:05 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMMIbuXLejgV for ; Thu, 15 Nov 2012 10:57:05 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 8CED73561614 for ; Thu, 15 Nov 2012 10:57:04 -0500 (EST) Date: Thu, 15 Nov 2012 10:57:01 -0500 From: Cyrus Daboo To: Apps Discuss Message-ID: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=1436 Subject: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 15 Nov 2012 15:57:07 -0000 Hi, Here are my review comments (mostly nits - nothing major): =C2=A71: Introduction focusses on the use of JSON patch in HTTP PATCH, but = of=20 course it could be used anywhere else a "patch" operation is needed (other=20 protocols". It might be worth adding some text explaining the more=20 "generic" use case. e.g.: This format is also applicable to any protocol that might want to process partial updates to a JSON document. =C2=A74.1 talks about the "-" value for arrays, but that value is also=20 applicable to "move" and "copy". Should that statement also appear in = =C2=A74.4=20 and =C2=A74.5 or be moved to a more "generic" location - e.g. in the main = text=20 of =C2=A74? =C2=A74.6 uses a very basic octet/code-point comparator. Do we care about=20 possible unicode normalizations issues? If so that will need to be dealt=20 with, if not there ought to be a clarifying statement - in fact an=20 "Internationalization Considerations" section may be warranted. =C2=A74.6 numbers - any concern about numeric precision affecting the=20 "subtracting one from another" behavior? =C2=A75 when an error occurs it would be handy to have some minimal form of = error reporting - simply the index of the operation that failed. Can we=20 define a JSON format for an HTTP PATCH error response? =C2=A76 XML patch uses a MIME type "patch-ops-error+xml", why is this not=20 "patch+json"? =C2=A7A.6 - missing comma between members "foo" and "qux" in the two = document=20 examples. --=20 Cyrus Daboo From dhc@dcrocker.net Thu Nov 15 08:08: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 C982F21F896E for ; Thu, 15 Nov 2012 08:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] 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 UevAeOS3pFmw for ; Thu, 15 Nov 2012 08:08:48 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 48AE121F8958 for ; Thu, 15 Nov 2012 08:08:45 -0800 (PST) Received: from [192.168.1.9] (adsl-67-127-56-94.dsl.pltn13.pacbell.net [67.127.56.94]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id qAFG8iVP001749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Nov 2012 08:08:44 -0800 Message-ID: <50A51385.3080806@dcrocker.net> Date: Thu, 15 Nov 2012 08:08:37 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Ned Freed References: <50A411A3.6060600@qti.qualcomm.com> <01OMMH6GA83U00008S@mauve.mrochek.com> In-Reply-To: <01OMMH6GA83U00008S@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 15 Nov 2012 08:08:44 -0800 (PST) Cc: Pete Resnick , IETF Apps Discuss Subject: Re: [apps-discuss] AD Fail - MPTCP API X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 16:08:48 -0000 On 11/14/2012 7:06 PM, Ned Freed wrote: > I noted this text: > > As this address may not be valid any more if the first subflow is > closed, the MPTCP stack MAY close the whole MPTCP connection if the > first subflow is closed (i.e. fate sharing between the initial > subflow and the MPTCP connection as a whole). Whether to close the > whole MPTCP connection by default SHOULD be controlled by a local > policy. Further experiments are needed to investigate its > implications. ... > The lack of user control for things like this has rendered other > protocols a lot less useful than they might otherwise have been. On its face, the choice to default to closing an entire session because one of several channels goes away seems exactly wrong to me. I would think that a major motivating factor for a multi-channel TCP is robustness against an outage. What the current normative language does is to encourage making multi-channel TCP as fragile as single-channel. Or have I missed something basic? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dirk.f5r@googlemail.com Thu Nov 15 08: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 83A6A21F8A0D for ; Thu, 15 Nov 2012 08:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 SiW47BgAZZ5P for ; Thu, 15 Nov 2012 08:30:03 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4492821F88D4 for ; Thu, 15 Nov 2012 08:30:02 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so886264bku.31 for ; Thu, 15 Nov 2012 08:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=27vb7NQp1mzXqUSZ3cmS94CWVI+F0nFMypx6v7BemIk=; b=ToPrdfKCcWbGY60YE640N2ux9pTIKibjMy7uGkx3V035+9YfWBJ0xgIBOP4DxrXcCe KlVo0YIbwm2gfTtmz+WicJAnYDoV8HGfgDnGk2q0vMXmGKlpBUHGGZUtSL1B2C7uEx6B Pa4aGLpQjKaGU1jh0rnVIrcCpZsNjiwF7qEBf/GGyYA8frGwqcb1EIqgBiEHrt+cm1V9 3mbOmvSu03SuX9Y1734aQQR9m8cr9fmrE+gsZ6ZgbucxrRtZk3dKVT4ynvetbpEls1Ni 7tDj9fg3KRkyKVd4MwkA0l/o+OCljP0DZXZ5kqAFGDK1/Tmy5CxGPbLutGmonyNTl6+v +5gQ== Received: by 10.204.130.10 with SMTP id q10mr673797bks.59.1352997001206; Thu, 15 Nov 2012 08:30:01 -0800 (PST) Received: from limo3121.local ([62.213.144.96]) by mx.google.com with ESMTPS id g8sm10807422bkv.6.2012.11.15.08.29.59 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 08:30:00 -0800 (PST) Message-ID: <50A51886.8010903@googlemail.com> Date: Thu, 15 Nov 2012 17:29:58 +0100 From: =?ISO-8859-1?Q?Dirk_Fr=F6hner?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <50A38259.4050304@googlemail.com> <3B530232-381D-4370-980B-B5B308443DDF@mnot.net> In-Reply-To: <3B530232-381D-4370-980B-B5B308443DDF@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] json-home: comments and questions on draft 02 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, 15 Nov 2012 16:30:05 -0000 Mark, thanks for your response. More comments inline. Glück auf! Dirk On 15/11/12 1:37 AM, Mark Nottingham wrote: > On 14/11/2012, at 10:36 PM, Dirk F5R wrote: > >> Hi all, hi Mark, >> >> I had a closer look at http://pretty-rfc.herokuapp.com/draft-nottingham-json-home and http://tools.ietf.org/html/draft-nottingham-json-home-02 since I also absolutely see the need for an API "home page" as well. As a matter of fact, the specs I have contributed to at work come with what we call a "service document" (I can't help using that term in the remainder of this mail). This is only another term for basically the same concept: one single entry point into a hypermedia API that reveals links to something like top-level resources. The URI to the service document is the only thing that needs to be published to client developers, from there we strictly follow the HATEOAS principle. >> >> I have a few comments / questions on json-home: >> >> When I look at the json-home draft, it looks to me as if it were actually two separate ones. One that deals with the need of a service document and how it might look like and one that defines how links should look like in JSON. The latter one though is nothing specific to the service document but would rather be a general convention. Shouldn't this be two separate draft documents? > Possibly. The thing is, I'm not yet convinced that there's a single style of linking that's right for all uses -- or even a majority of cases -- in JSON, so I haven't tackled this yet. Having a home document seemed to be the low-hanging fruit, and I expect that if we do one day have a predominant way of linking in JSON, we'll converge on that somehow. Different styles of linking (in JSON) is actually something about which we had many discussions in our office during the last months... > I have talked to Mike about HAL; it may be a contender for enough use cases to be interesting, but I didn't want to tie the fate of this spec to HAL. ...and I would actually be very interested to exchange our results with you and Mike - not sure if this should take place exactly here though? > In the meantime, the links in json-home are interoperable with other serialisations of links (including HAL). The important thing is that the underlying semantics of the link are well-defined, as per RFC5988. The syntax doesn't matter as much (caveat: see below). > > >> As to my current perception, I'm also not sure why the service document should have a different format or structure than any other document that comes back from an API. For instance, if your representations always come with an attribute called "links" that hosts explicit links by relation types, why should this be different for the service document? This leads me to the opinion that it should be defined as a requirement that hypermedia APIs must come with a service document but I don't necessarily see the need to define a particular format or media type for it. > > Well, we get concrete benefits when off-the-shelf software can consume a known format; having to relearn every format as you encounter it is expensive (in money, time and effort) and error-prone. That would mean that off-the-shelf software could consume the API home docs but it doesn't necessarily mean that it can consume any other representation that comes back when one of the links in the home doc is followed. We had something similar in place previously where we were kind of forced to employ a resource discovery format (JRD, i.e. XRD for JSON) as API home doc and found it very inconvenient to have a different format for this. By now we use the same format for API home docs as for any other representation that comes back from our APIs. In particular this means that we have a consistent way of representing links. But maybe I don't completely understand what you have in mind with the ability to "scan" API home docs and do stuff with it. > > My observation is that coming up with a framework that abstracts out the world into a single format convention is Hard (see: RDF), so I decided to try something more modest here. People intuitively understand "home document." I'm absolutely with you, I guess it's more a question if that home document has to be in a special format. If you compare it with the home page of a website, you also wouldn't expect that in a different format than any other page that comes from the site. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > From ht@inf.ed.ac.uk Thu Nov 15 09:07: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 E142A21F8940; Thu, 15 Nov 2012 09:07:00 -0800 (PST) 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 WvAsai8XmsrO; Thu, 15 Nov 2012 09:06:59 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 783BC21F8939; Thu, 15 Nov 2012 09:06:58 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id qAFH6en0001415; Thu, 15 Nov 2012 17:06:45 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id qAFH6eqH011163; Thu, 15 Nov 2012 17:06:40 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id qAFH6dMW031713; Thu, 15 Nov 2012 17:06:39 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id qAFH6djs031709; Thu, 15 Nov 2012 17:06:39 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org, draft-ietf-appsawg-json-patch.all@tools.ietf.org References: <6.2.5.6.2.20121114233206.0cbf0478@elandnews.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 15 Nov 2012 17:06:39 +0000 In-Reply-To: <6.2.5.6.2.20121114233206.0cbf0478@elandnews.com> (SM's message of "Thu\, 15 Nov 2012 00\:07\:06 -0800") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: appsdir@ietf.org, iesg@ietf.org Subject: [apps-discuss] Appsdir review of draft-ietf-appsawg-json-patch-06 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, 15 Nov 2012 17:07:01 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-appsawg-json-patch-06 Title: JSON Patch Reviewer: Henry S. Thompson Review Date: 15 November 2012 IETF Last Call Date: 2012-11-23 Summary: This draft is almost ready for publication as an Proposed Standard but has a related set of issues that should be fixed before publication Note that I have not read previous drafts of or comments on this document -- I presume I was asked to review as a fresh pair of eyes. If the result is to repeat some previously-expressed comments, so be it. Major Issues: 4.1 This operation ('add') seems underspecified in several respects. 1) I would have expected a short statement of the actual effect under each bullet, e.g. "The specified value becomes the entire contents of the document"; 2) I would have expected error conditions to be specified under each bullet. I assume it is an error for "path" to be empty and the document to have content. The discussion of index errors wrt arrays could/should move, and the "common use" 'note', which isn't a note at all, should be specific to objects. 3) I take it you also need to say that if an _existing_ member of an object is referenced, that's not an error (note that it _is_ a JSON Pointer error), and the result is to increase the number of such members by one, with the new value. 4) I don't see any basis in the JSON Pointer spec. for "[using the] '-' character ... to index the end of the array" -- as I read the JSON Pointer spec. "/a/b/-" is an error if "/a/b" addresses an array. Similarly, "/a/b/5" is an error if "/a/b" addresses an array and the array is of length 5, which is not consistent with the implication of "The specified index MUST NOT be greater than the number of elements in the array", i.e. that "/a/b/5" is not ruled out in this case. If the intent is that a value of n, where n is the size of the array, or a -, is allowed to end a path which has gotten to an array, and results in an append operation, this should be stated explicitly. [Ah, subsequent information reveal that wrt '-', the bug is in the references, not the text -- the addition of '-' to JSON Pointer is in a subsequent draft to the one referenced here! I have to say that if '-' was added purely for use by JSON patch, I'd much prefer that you take my suggestion immediately below and revert the '-' addition to JSON Pointer.] I think in fact you might be better off to handle this by cases and avoid all 'intentional' JSON Pointer errors, along the lines of a) If the "path" is "" and the document is empty then the "value" becomes the document; b) If the path excluding its last step identifies an object, then "value" is added at the end of that object, with the name given by the decoded reference token of the last step; c) If the path excluding its last step identifies an array then i) If the last step's reference token encodes an integer i with 0 <= i < |array|, then . . . ii) If the last step's reference token is '-' or encodes |array|, then . . . Otherwise, the operation raises an error. 4.2, 4.3 Nothing is said about the case where a path which identifies a multiply-valued object member is given, which per JSON Pointer is a pointer error. 4.4 Given the real complexity of both 'remove' and 'add', 'move' really should be defined by reference to those operations, rather than repeating (imperfectly at the moment) their definitions. This would have the additional benefit of removing the necessity for the side conditions, all of which will now follow from the definitions of 'remove' and 'add' (except the invalidity of replacing the root, which should as far as I can see be allowed - { "op": "move", "path": "/a/b", "to": "" } seems perfectly reasonable to me). 4.5 Again, although the first side condition would have to remain, this should be defined by reference to 'add'. See below under Minor Issues wrt the second side condition. Minor Issues: 1. This is perfectly clear, but I still missed it: This spec. (and JSON Pointer) are about _documents_ and not Javascript objects. It's very easy to slip into thinking about objects, and indeed the spec. itself talks about the target as if it consisted of objects and arrays! It would of course be obnoxious to require you to say "JSON encoding of an object" every time, instead of just "object", but I wonder if it wouldn't be a good idea to say, here in the introduction, precisely that -- that you will (mostly) talk about the target as if it had a root, consisted of arrays and objects with members and values, etc., but what you will always _mean_ is being pointed to, tested, changed, etc. is the _JSON encoding_ of those things. 3. In a similar vein, wrt the patch document itself, I think it would be better to say e.g. "A JSON Patch document is a JSON [RFC4627] document which [represents/encodes/whatever] an array of objects." 4.5 I don't understand the reason for barring copying to an existing member. The rest of the spec. seems content to allow multiple identically-named members to be specified. . . You would, I guess, need to say that where it goes, but if you defined by reference to "add" as I've given it above, that would be taken care of. 4.6 When you get to string-string equality the object / encoding duality discussed above at 1. becomes a problem -- you have treated the patch as an object up until now, in which case any escaping will already have been dealt with. If one took the words in this case literally, the following test would succeed: Target { "a":"\b" } Patch [ { "op": "test", "path": "/a", "value":"\\b" } ] which is presumably not what you meant. It's clear from the wording you've used in this case that you _meant_ to refer here (and only here) to the _encoding_ of the value of the "value" property of the patch, not its value. Phew! Nits: [none] ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From jasnell@gmail.com Thu Nov 15 09:28: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 802B421F89C3 for ; Thu, 15 Nov 2012 09:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.886 X-Spam-Level: X-Spam-Status: No, score=-3.886 tagged_above=-999 required=5 tests=[AWL=-0.288, 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 dttICDybCRcK for ; Thu, 15 Nov 2012 09:28:05 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF61F21F89BC for ; Thu, 15 Nov 2012 09:28:04 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1992116oag.31 for ; Thu, 15 Nov 2012 09:28:04 -0800 (PST) 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=HB4EyUSUbvmMJGSC9ig67s9uUi4PXww6zII/ME4Ug7Y=; b=cOYapMM/1Bz/vlNemrIxGdCJW0GPOJEA1Rot5mFnmu5X/55sI5KAcZ8rfCnqeU0Yc9 0IQvjDywxlPVCQTiZVlcXjM6vNP6XilNdgsl77PAR07J89iLZgRxy6VEhzcuGYwpdQPg TE/VfrxtC5upRUzJwsFwSGndcXKaiPKnYNFETTbv0uVa0qpbhh2eaqq42bxONPM1K/VN TP1ituMpJWPqtGSAYjWi+sxA6pLiSr1Wk4gsWMTKIQyZhRQBvjshMYiszBVb2eLhTkgx 5STif4Ja5r+Fj1fqyR5WfaPEyA2PoI7M++vTISnQ3g7XuF2WDP5niVvymJcx1oSsWp4D VyEA== Received: by 10.182.18.196 with SMTP id y4mr1505604obd.52.1353000484323; Thu, 15 Nov 2012 09:28:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.68.37 with HTTP; Thu, 15 Nov 2012 09:27:44 -0800 (PST) In-Reply-To: References: From: James M Snell Date: Thu, 15 Nov 2012 09:27:44 -0800 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d04388ef53fc0ee04ce8bf932 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-json-pointer 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, 15 Nov 2012 17:28:05 -0000 --f46d04388ef53fc0ee04ce8bf932 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 15, 2012 at 7:24 AM, Paul Hoffman wrote: > This document mostly looks fine. > > - I do not understand the use of "-"; at least one use of it in an > application should be given. > > - If "-" is useful, wouldn't it also be useful to have something that > indicates the (non-existant) member before the first array element? > > This came from a requirement with json patch to allow a way of appending new array items to the end. This was fairly extensively discussed and concluded that the - was the least-complicated option that met the requirement. - James > - Editorial nit in section 4: > * characters that represent an unsigned base-10 integer value > (possibly with leading zeros), making the new referenced value > is the array element with the zero-based index identified by > the token, or > That should either be "the new referenced value is the" or "making the new > referenced value the", I believe. > > - One of the security considerations is too limited. > Note that JSON pointers can contain the NUL (Unicode U+0000) > character, which may not be representable in all programming > languages. > The same is true for all control characters, and for some programming > languages, all non-ASCII characters. Proposed rewording: > Note that JSON pointers can contain the NUL (Unicode U+0000) > character, control characters, non-ASCII characters, and so > on. These characters may not be representable in all programming > languages. > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d04388ef53fc0ee04ce8bf932 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Thu, Nov 15, 2012 at 7:24 AM, Paul Ho= ffman <paul.hoffman@vpnc.org> wrote:
This document mostly looks fine.

- I do not understand the use of "-"; at least one use of it in a= n application should be given.

- If "-" is useful, wouldn't it also be useful to have someth= ing that indicates the (non-existant) member before the first array element= ?


This came from a requirement with json= patch to allow a way of appending new array items to the end. This was fai= rly extensively discussed and concluded that the - was the least-complicate= d option that met the requirement.=C2=A0

- James
=C2=A0
- Editorial nit in section 4:
=C2=A0 =C2=A0 =C2=A0 * =C2=A0characters that represent an unsigned base-10 = integer value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(possibly with leading zeros), making the= new referenced value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is the array element with the zero-based = index identified by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the token, or
That should either be "the new referenced value is the" or "= making the new referenced value the", I believe.

- One of the security considerations is too limited.
=C2=A0 =C2=A0Note that JSON pointers can contain the NUL (Unicode U+0000) =C2=A0 =C2=A0character, which may not be representable in all programming =C2=A0 =C2=A0languages.
The same is true for all control characters, and for some programming langu= ages, all non-ASCII characters. Proposed rewording:
=C2=A0 =C2=A0Note that JSON pointers can contain the NUL (Unicode U+0000) =C2=A0 =C2=A0character, control characters, non-ASCII characters, and so =C2=A0 =C2=A0on. These characters may not be representable in all programmi= ng
=C2=A0 =C2=A0languages.

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

--f46d04388ef53fc0ee04ce8bf932-- From sm@elandsys.com Thu Nov 15 09:28: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 0F90521F89C3 for ; Thu, 15 Nov 2012 09:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 oX1yryatpxc3 for ; Thu, 15 Nov 2012 09:28:05 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F08221F89C8 for ; Thu, 15 Nov 2012 09:28:04 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.152.44]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAFHRonT006702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 09:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353000483; bh=JDKU7Y/RgbM7pilqGJRT3ywI8dWc4TFuju3hp3JmBcQ=; h=Date:To:From:Subject:Cc; b=qYuB+kF2AvQw9GE+5dCq9o08f+L9AB8OAU0zeppKg9FBHmxbrA0JcDOQg7rit3OL3 iSWdkpaFrdLwtmr3/C+jaX5qRkuAmM4naTIMjsZyqLvwTyQkT+xqAkpsf6hPHm5qfl jWpdrcWy2a0N5eWSsQI02qLB4H2/7chmSBDpmbyc= Message-Id: <6.2.5.6.2.20121115091657.0cf84898@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 15 Nov 2012 09:19:44 -0800 To: apps-discuss@ietf.org From: ht@inf.ed.ac.uk (Henry S. Thompson) (by way of S Moonesamy ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-appsawg-json-patch.all@tools.ietf.org Subject: [apps-discuss] Appsdir review of draft-ietf-appsawg-json-patch-06 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, 15 Nov 2012 17:28:06 -0000 Hello, I am forwarding the review of draft-ietf-appsawg-json-patch-06 performed by Henry S. Thompson. Regards, S. Moonesamy I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-appsawg-json-patch-06 Title: JSON Patch Reviewer: Henry S. Thompson Review Date: 15 November 2012 IETF Last Call Date: 2012-11-23 Summary: This draft is almost ready for publication as an Proposed Standard but has a related set of issues that should be fixed before publication Note that I have not read previous drafts of or comments on this document -- I presume I was asked to review as a fresh pair of eyes. If the result is to repeat some previously-expressed comments, so be it. Major Issues: 4.1 This operation ('add') seems underspecified in several respects. 1) I would have expected a short statement of the actual effect under each bullet, e.g. "The specified value becomes the entire contents of the document"; 2) I would have expected error conditions to be specified under each bullet. I assume it is an error for "path" to be empty and the document to have content. The discussion of index errors wrt arrays could/should move, and the "common use" 'note', which isn't a note at all, should be specific to objects. 3) I take it you also need to say that if an _existing_ member of an object is referenced, that's not an error (note that it _is_ a JSON Pointer error), and the result is to increase the number of such members by one, with the new value. 4) I don't see any basis in the JSON Pointer spec. for "[using the] '-' character ... to index the end of the array" -- as I read the JSON Pointer spec. "/a/b/-" is an error if "/a/b" addresses an array. Similarly, "/a/b/5" is an error if "/a/b" addresses an array and the array is of length 5, which is not consistent with the implication of "The specified index MUST NOT be greater than the number of elements in the array", i.e. that "/a/b/5" is not ruled out in this case. If the intent is that a value of n, where n is the size of the array, or a -, is allowed to end a path which has gotten to an array, and results in an append operation, this should be stated explicitly. [Ah, subsequent information reveal that wrt '-', the bug is in the references, not the text -- the addition of '-' to JSON Pointer is in a subsequent draft to the one referenced here! I have to say that if '-' was added purely for use by JSON patch, I'd much prefer that you take my suggestion immediately below and revert the '-' addition to JSON Pointer.] I think in fact you might be better off to handle this by cases and avoid all 'intentional' JSON Pointer errors, along the lines of a) If the "path" is "" and the document is empty then the "value" becomes the document; b) If the path excluding its last step identifies an object, then "value" is added at the end of that object, with the name given by the decoded reference token of the last step; c) If the path excluding its last step identifies an array then i) If the last step's reference token encodes an integer i with 0 <= i < |array|, then . . . ii) If the last step's reference token is '-' or encodes |array|, then . . . Otherwise, the operation raises an error. 4.2, 4.3 Nothing is said about the case where a path which identifies a multiply-valued object member is given, which per JSON Pointer is a pointer error. 4.4 Given the real complexity of both 'remove' and 'add', 'move' really should be defined by reference to those operations, rather than repeating (imperfectly at the moment) their definitions. This would have the additional benefit of removing the necessity for the side conditions, all of which will now follow from the definitions of 'remove' and 'add' (except the invalidity of replacing the root, which should as far as I can see be allowed - { "op": "move", "path": "/a/b", "to": "" } seems perfectly reasonable to me). 4.5 Again, although the first side condition would have to remain, this should be defined by reference to 'add'. See below under Minor Issues wrt the second side condition. Minor Issues: 1. This is perfectly clear, but I still missed it: This spec. (and JSON Pointer) are about _documents_ and not Javascript objects. It's very easy to slip into thinking about objects, and indeed the spec. itself talks about the target as if it consisted of objects and arrays! It would of course be obnoxious to require you to say "JSON encoding of an object" every time, instead of just "object", but I wonder if it wouldn't be a good idea to say, here in the introduction, precisely that -- that you will (mostly) talk about the target as if it had a root, consisted of arrays and objects with members and values, etc., but what you will always _mean_ is being pointed to, tested, changed, etc. is the _JSON encoding_ of those things. 3. In a similar vein, wrt the patch document itself, I think it would be better to say e.g. "A JSON Patch document is a JSON [RFC4627] document which [represents/encodes/whatever] an array of objects." 4.5 I don't understand the reason for barring copying to an existing member. The rest of the spec. seems content to allow multiple identically-named members to be specified. . . You would, I guess, need to say that where it goes, but if you defined by reference to "add" as I've given it above, that would be taken care of. 4.6 When you get to string-string equality the object / encoding duality discussed above at 1. becomes a problem -- you have treated the patch as an object up until now, in which case any escaping will already have been dealt with. If one took the words in this case literally, the following test would succeed: Target { "a":"\b" } Patch [ { "op": "test", "path": "/a", "value":"\\b" } ] which is presumably not what you meant. It's clear from the wording you've used in this case that you _meant_ to refer here (and only here) to the _encoding_ of the value of the "value" property of the patch, not its value. Phew! Nits: [none] ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From paul.hoffman@vpnc.org Thu Nov 15 09:36: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 B3E8821F8940 for ; Thu, 15 Nov 2012 09:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 G1PD8TBoFYHl for ; Thu, 15 Nov 2012 09:36:38 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3631021F8896 for ; Thu, 15 Nov 2012 09:36:38 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAFHaSOS069323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Nov 2012 10:36:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Thu, 15 Nov 2012 09:36:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <362546D9-85FF-4BE8-B0ED-99CB57A55379@vpnc.org> References: To: James M Snell X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-json-pointer 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, 15 Nov 2012 17:36:38 -0000 On Nov 15, 2012, at 9:27 AM, James M Snell wrote: > This came from a requirement with json patch to allow a way of = appending new array items to the end. This was fairly extensively = discussed and concluded that the - was the least-complicated option that = met the requirement.=20 Understood. However, is there *no* reason to prepend something to the = beginning of the list? Or is that done with "1"? (I admit not fully = getting all the fun features of -patch). --Paul Hoffman= From dret@berkeley.edu Thu Nov 15 09:36: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 3E82721F8896 for ; Thu, 15 Nov 2012 09:36:39 -0800 (PST) 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 YnhBaLGZgKsc for ; Thu, 15 Nov 2012 09:36:38 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 5C63B21F88CC for ; Thu, 15 Nov 2012 09:36:38 -0800 (PST) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.64]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TZ3MX-0005wW-BD; Thu, 15 Nov 2012 09:36:27 -0800 Message-ID: <50A52817.7010505@berkeley.edu> Date: Thu, 15 Nov 2012 09:36:23 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Graham Klyne References: <50A38259.4050304@googlemail.com> <3B530232-381D-4370-980B-B5B308443DDF@mnot.net> <50A4E7FD.5000705@ninebynine.org> In-Reply-To: <50A4E7FD.5000705@ninebynine.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: LDP WG , IETF Apps Discuss Subject: Re: [apps-discuss] Links and graphs 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, 15 Nov 2012 17:36:39 -0000 hello graham. On 2012-11-15 5:02 , Graham Klyne wrote: > I don't follow what you're saying here. I don't disagree (as someone > involved with RDF) that RDF has made its life hard in several ways, but > if what you have and want to pass around is a graph, how does one *not* > push it down into the data? the big problem with RDF on the level we're discussing here is that RDF pushes everything into vocabularies, and thus renders media types almost meaningless (apart from distinguishing RDF serializations). that's a problem for home documents or similar web-oriented approaches that rely on the media type being a crucial signal for understanding the interaction semantics of resources. > (Personally, I'd like to see json-home be something that has a clear > mapping to RDF, but that's a different discussion.) fwiw, https://github.com/dret/I-D-1/tree/master/json-home is where i have started creating a mapping to XML, and i'd be more than happy to collaborate with others to do the same for an RDF schema. but like i said above, the whole concept of home documents hinges around the assumption that a media type signals interaction semantics, so that clients can decide what resources to engage with. in RDF, this is not how the world works (yet, i still hope that we'll see this tackled at some point in time), so maybe there's a little less utility in the whole approach. regardless of that, we have discovered in our current work in the "Linked Data Platform" W3C WG that we probably need some concept of a "service document" or a "home document", and thus it might be interesting to look at how the current json-home approach could be mapped to RDF and would give us some useful foundation. 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 jasnell@gmail.com Thu Nov 15 09:41: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 1BF9321F855F for ; Thu, 15 Nov 2012 09:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[AWL=-0.269, 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 AsWJcEuHTNKT for ; Thu, 15 Nov 2012 09:41:50 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 96D6E21F84FC for ; Thu, 15 Nov 2012 09:41:50 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2009353oag.31 for ; Thu, 15 Nov 2012 09:41:50 -0800 (PST) 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=GErnoKULlzgenBvCQflcWQqS1c79HHUpRSogq1QOFv0=; b=yxKQF1ZaN9nv6vN0cfBZ5RoA9SccAG4y9h2gdPWfrEhpT+vN9Drf56lDHuNTciy6Dm GTjz5Ry43plJbGagm+gxlgK3Z7eoYis6F49Suu1Ujj+wTcticVCoGMvb+U0HTDXCcw7K dzKvw4FxY5oO/SO7gmadeaUPTngSS7wQDtK5CTo9256RK0fCwFIqDBZnYAYGusGoWFvn GKIVjZmkmx6/QEXUhKEjG2BNvaTXDW9IS1Jmmpd+mCOAgDJep6YJnQyxxt4C8QwKSJWd LdaETN3T6HNboxh/WLam1d2Oar65CcNORrBGAXr0XXXG/RmjOtkvoNQ0ns2KL2o/kc+9 ZYDg== Received: by 10.182.18.196 with SMTP id y4mr1543879obd.52.1353001310176; Thu, 15 Nov 2012 09:41:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.68.37 with HTTP; Thu, 15 Nov 2012 09:41:30 -0800 (PST) In-Reply-To: <362546D9-85FF-4BE8-B0ED-99CB57A55379@vpnc.org> References: <362546D9-85FF-4BE8-B0ED-99CB57A55379@vpnc.org> From: James M Snell Date: Thu, 15 Nov 2012 09:41:30 -0800 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d04388ef579443e04ce8c2a5e Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-json-pointer 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, 15 Nov 2012 17:41:51 -0000 --f46d04388ef579443e04ce8c2a5e Content-Type: text/plain; charset=UTF-8 It's a zero-based array. With JSON patch, adding an item to the beginning of the array would be done using {"op":"add", "path": "/a/b/0", "value":1}, which causes the new value to be inserted at position 0 and all existing items to be shifted right. On Thu, Nov 15, 2012 at 9:36 AM, Paul Hoffman wrote: > On Nov 15, 2012, at 9:27 AM, James M Snell wrote: > > > This came from a requirement with json patch to allow a way of appending > new array items to the end. This was fairly extensively discussed and > concluded that the - was the least-complicated option that met the > requirement. > > Understood. However, is there *no* reason to prepend something to the > beginning of the list? Or is that done with "1"? (I admit not fully getting > all the fun features of -patch). > > --Paul Hoffman --f46d04388ef579443e04ce8c2a5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's a zero-based array. With JSON= patch, adding an item to the beginning of the array would be done using {&= quot;op":"add", "path": "/a/b/0", "= value":1}, which causes the new value to be inserted at position 0 and= all existing items to be shifted right.=C2=A0


On Thu, Nov 15, 2012 at 9:36 AM, Paul Ho= ffman <paul.hoffman@vpnc.org> wrote:
On Nov 15, 2012, at 9:27 AM, James M Snell <jasnell@gmail.com> wrote:

> This came from a requirement with json patch to allow a way of appendi= ng new array items to the end. This was fairly extensively discussed and co= ncluded that the - was the least-complicated option that met the requiremen= t.

Understood. However, is there *no* reason to prepend something to the= beginning of the list? Or is that done with "1"? (I admit not fu= lly getting all the fun features of -patch).

--Paul Hoffman

--f46d04388ef579443e04ce8c2a5e-- From paul.hoffman@vpnc.org Thu Nov 15 10:39: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 1BC9021F8499 for ; Thu, 15 Nov 2012 10:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 kXkX3Y-7j-7t for ; Thu, 15 Nov 2012 10:39:46 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 905AB21F8485 for ; Thu, 15 Nov 2012 10:39:46 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAFIdhNe071315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Nov 2012 11:39:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Thu, 15 Nov 2012 10:39:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <362546D9-85FF-4BE8-B0ED-99CB57A55379@vpnc.org> To: James M Snell X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-json-pointer 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, 15 Nov 2012 18:39:47 -0000 On Nov 15, 2012, at 9:41 AM, James M Snell wrote: > It's a zero-based array. With JSON patch, adding an item to the = beginning of the array would be done using {"op":"add", "path": = "/a/b/0", "value":1}, which causes the new value to be inserted at = position 0 and all existing items to be shifted right.=20 This is a good reason why I should not be a reviewer for -patch. :-) Ignore my question for -pointer: the "-" is sufficient for patching. --Paul Hoffman= From lear@cisco.com Thu Nov 15 10:55: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 6297121F8481 for ; Thu, 15 Nov 2012 10:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.595 X-Spam-Level: X-Spam-Status: No, score=-110.595 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YeD+qwqvH30J for ; Thu, 15 Nov 2012 10:55:24 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 210A221F8436 for ; Thu, 15 Nov 2012 10:55:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6657; q=dns/txt; s=iport; t=1353005724; x=1354215324; h=message-id:date:from:mime-version:to:cc:subject; bh=J0xYEtXYd9RjzJnlS74/uWRVpcqyJeIB+XwHyq0bQlw=; b=bOa18rI/b5AYcvfOrvawL55BLNs8U2TeynBcTRI/4qJsT6rcjonPWyaA F81fvYT8pF+uyMnb/aKVotiQdzCEvsguNV1ym1jgTuIkzLDccHynRkZtV zPReFvScldBjD+MePmeWEKGeDpmc6iqC/6nycdtO07wSMmzyUJGgqT6+l 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAEA5pVCQ/khN/2dsb2JhbABEhh2FX7ZFgQiCNwEQVQEvDRYLAgsDAgECAUsBDAEHAQEeh2sLnQSNKJJhjDGFGYETA5V8gRyNPIFrgnA X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="9601690" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 15 Nov 2012 18:55:23 +0000 Received: from dhcp-10-55-83-48.cisco.com (dhcp-10-55-83-48.cisco.com [10.55.83.48]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAFItMbk022094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 18:55:22 GMT Message-ID: <50A53A9A.3040302@cisco.com> Date: Thu, 15 Nov 2012 19:55:22 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: draft-ietf-tcpm-experimental-options.all@tools.ietf.org, "apps-discuss@ietf.org" X-Enigmail-Version: 1.4.5 Content-Type: multipart/alternative; boundary="------------050102000802010603010604" Cc: Wesley Eddy Subject: [apps-discuss] Apps Directorate Review of draft-ietf-tcpm-experimental-options-02 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, 15 Nov 2012 18:55:25 -0000 This is a multi-part message in MIME format. --------------050102000802010603010604 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear Joe, I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​ http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-tcpm-experimental-options-02 Title: Shared Use of Experimental TCP Options Reviewer: Eliot Lear Review Date: 15 Nov. 2012 IETF Last Call Date: none. IESG Telechat Date: none. This document is not yet ready for publication, and requires consideration of several major issues. As an apps directorate reviewer, I can say that since many if not most applications sit atop TCP, the impact of experimental options can be quite serious. Major Issues I would want to know that the working group seriously considered a fixed length for the magic field. In general, I'm uncomfortable with the SHOULD for the size of the field, and would be more comfortable with a MUST. More importantly this draft raises a concern about options that are meant to be EXPERIMENTAL, but somehow the experiments got out of the lab. I'd like to understand how often this has actually been a problem. IMHO I don't understand why we would think that implementers would follow the advice given in this draft if they didn't bother attempting registering allocation with IANA (Section 1, Page 3). This section, needs to more clearly state the problem meant to be addressed. If this draft is to move ahead, a specific PRN algorithm should be recommended for selection of the magic number so as to avoid collisions. The SAAG folk can help here. Similarly 3.2 argues against the whole concept. Let's not try to address backward compatibility of use of this feature with experiments in this document, other than to say that this mechanism isn't intended for use with a uniquely assigned option. Minor Issues The ASCII art in Section 3 should give field lengths. I really don't know what to make of Section 3.1. The SHOULD there tells me to do something if my implementation is not robust, but then if I do it, it is robust, right? Clearer advise should be given. Like perhaps the following: if an implementation receives a response that does not follow the the experiemental design, it MUST cease sending the option in question and interpreting any such results, and SHOULD terminate the TCP connection and try again. Perhaps hosts participating in the experiment should cache failures and log them? Eliot --------------050102000802010603010604 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Dear Joe,

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

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

Document: draft-ietf-tcpm-experimental-options-02
Title: Shared Use of Experimental TCP Options
Reviewer: Eliot Lear
Review Date: 15 Nov. 2012
IETF Last Call Date: none.
IESG Telechat Date: none.

This document is not yet ready for publication, and requires consideration of several major issues.  As an apps directorate reviewer, I can say that since many if not most applications sit atop TCP, the impact of experimental options can be quite serious.

Major Issues

I would want to know that the working group seriously considered a fixed length for the magic field. In general, I'm uncomfortable with the SHOULD for the size of the field, and would be more comfortable with a MUST.

More importantly this draft raises a concern about options that are meant to be EXPERIMENTAL, but somehow the experiments got out of the lab.  I'd like to understand how often this has actually been a problem.  IMHO I don't understand why we would think that implementers would follow the advice given in this draft if they didn't bother attempting registering allocation with IANA (Section 1, Page 3).  This section, needs to more clearly state the problem meant to be addressed.

If this draft is to move ahead, a specific PRN algorithm should be recommended for selection of the magic number so as to avoid collisions.  The SAAG folk can help here.

Similarly 3.2 argues against the whole concept.  Let's not try to address backward compatibility of use of this feature with experiments in this document, other than to say that this mechanism isn't intended for use with a uniquely assigned option.

Minor Issues

The ASCII art in Section 3 should give field lengths.

I really don't know what to make of Section 3.1.  The SHOULD there tells me to do something if my implementation is not robust, but then if I do it, it is robust, right?  Clearer advise should be given.  Like perhaps the following: if an implementation receives a response that does not follow the the experiemental design, it MUST cease sending the option in question and interpreting any such results, and SHOULD terminate the TCP connection and try again.  Perhaps hosts participating in the experiment should cache failures and log them?

Eliot

--------------050102000802010603010604-- From Claudio.Allocchio@garr.it Thu Nov 15 11:22: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 5FDBA21F85E4 for ; Thu, 15 Nov 2012 11:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_47=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 hyNpgUUIEfaN for ; Thu, 15 Nov 2012 11:22:45 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 39A3421F85E3 for ; Thu, 15 Nov 2012 11:22:44 -0800 (PST) Received: internal info suppressed Date: Thu, 15 Nov 2012 20:22:34 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@webcam1-all.garrtest.units.it To: dcrocker@bbiw.net In-Reply-To: <50A51385.3080806@dcrocker.net> Message-ID: References: <50A411A3.6060600@qti.qualcomm.com> <01OMMH6GA83U00008S@mauve.mrochek.com> <50A51385.3080806@dcrocker.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1353007356; bh=G6BXrOPjIaCw5zLWsz+x/uHzaNsP0Pp70o9/LypUFH4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Dr8E77L4hCXgXQwL7ngO8TJhBTBow7bqHllWxnwZF2B9GB3MN1QoxNpC4S1fH8+NA GiDu8Il/eQhl0sy1kB8L3ORPIGierNVaaNYi8RhoEzs4ggPCjnanUHyNWkxeU8hGxd wssMSXWjwnkmm5s+J46KdtNXPaXWH5sLwE06BGm4= Cc: Pete Resnick , Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] AD Fail - MPTCP API 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, 15 Nov 2012 19:22:46 -0000 On Thu, 15 Nov 2012, Dave Crocker wrote: > I would think that a major motivating factor for a multi-channel TCP is > robustness against an outage. What the current normative language does > is to encourage making multi-channel TCP as fragile as single-channel. yes, but we shall also point out clearly all potential 'problems' that can exist with MCTCP vs TCP. Not all appications are the same with respect to this change. I indeed decided to examine this set of issues in my review (it will come... just after 9pm GMT!) as most of the other issues have already been clearly discussed on the apps=discuss list already. Just a set of "caveats", nothing more... > > Or have I missed something basic? > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From sm@resistor.net Thu Nov 15 11:49: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 99DAF21F8522 for ; Thu, 15 Nov 2012 11:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 5nlNNRPrn6hg for ; Thu, 15 Nov 2012 11:49:34 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCA621F89F6 for ; Thu, 15 Nov 2012 11:49:34 -0800 (PST) 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 qAFJnPO0012798; Thu, 15 Nov 2012 11:49:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353008971; bh=u5rCC6pkPP1OuUh+02J874h+XOe80ymPUfHv939Kadc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gttnfN2VlCBxhCFvPbXG6kac+JJnl2qcU/YpW9N9WmR3AHknKLh8ejL89CZygmEqY O8T3qwdGhLu4/fuZ4GpGss3oHJ92rpY0sb06q11wCuISPMaikKlenOYnAc8bSLnsW9 ntDzOOHIQMXGj6OZ8iWJ6/NN0Vja8h4F849XGYFI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353008971; i=@resistor.net; bh=u5rCC6pkPP1OuUh+02J874h+XOe80ymPUfHv939Kadc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Q2BZW5pqbU5X6tCNVITw/cM/uym9OCNttR9+tsh7A87j9oF1/c4PjNqEcdQ9YGFiW Lc1AZZcNX4eyp2HvECqYIerjrIZuPPMsMIohT0+ZHB3t/z6IBqibSVgPDZ/m8m5gSX eQelsi1DSriu2UFOaRx4a2/X87dA8H2aPtDkucGA= Message-Id: <6.2.5.6.2.20121115113957.0a9c2ff8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 15 Nov 2012 11:47:45 -0800 To: apps-discuss@ietf.org From: SM In-Reply-To: References: <1969645725.20121101120100@w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Chris Lilley , eb2m-mrt@asahi-net.or.jp Subject: Re: [apps-discuss] FW: New Version Notification for draft-lilley-xml-mediatypes-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, 15 Nov 2012 19:49:36 -0000 At 06:36 15-11-2012, Murray S. Kucherawy wrote: >So far there's been only one expression of support for processing >this through appsawg. Are there any others? Any objections to >processing it here? Other suggestions? This draft seems like RFC 3023bis. It requires MIME, URI, XML and Internationalization expertise. It is difficult to assess the extent of the work. I'll commit to review as I have to give something back to two of the authors for having volunteered their time for other work. Regards, -sm From tony@att.com Thu Nov 15 12:26: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 3256B21F891B for ; Thu, 15 Nov 2012 12:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 i2ZyGVxDYY3q for ; Thu, 15 Nov 2012 12:26:36 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9D821F88A9 for ; Thu, 15 Nov 2012 12:26:35 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id bff45a05.0.1632261.00-248.4528405.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 15 Nov 2012 20:26:35 +0000 (UTC) X-MXL-Hash: 50a54ffb256f8f25-ead7f6a4303764a59525d82e90ea790f3ade0c8e 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 qAFKQXqd030422 for ; Thu, 15 Nov 2012 12:26:34 -0800 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 qAFKQGcV030035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Nov 2012 12:26:30 -0800 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint03.pst.cso.att.com (RSA Interceptor) for ; Thu, 15 Nov 2012 12:26:02 -0800 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 qAFKQ0ZN027095 for ; Thu, 15 Nov 2012 15:26:00 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qAFKPraV026980 for ; Thu, 15 Nov 2012 15:25:56 -0500 Received: from [135.70.92.3] (vpn-135-70-92-3.vpn.swst.att.com[135.70.92.3]) by maillennium.att.com (mailgw1) with ESMTP id <20121115202600gw100632dpe> (Authid: tony); Thu, 15 Nov 2012 20:26:08 +0000 X-Originating-IP: [135.70.92.3] Message-ID: <50A54FC6.7030409@att.com> Date: Thu, 15 Nov 2012 15:25:42 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <1969645725.20121101120100@w3.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090305000902000204030308" 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=2.0 cv=Cu4IhAED c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=lYdQ7UQbJqUA:10 a=1I5aD5_xVbAA:10 a=Qir7IMC8iwkA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=NBxtrAbx] X-AnalysisOut: [fJkA:10 a=SSmOFEACAAAA:8 a=48vgC7mUAAAA:8 a=rr12N7SGZFADF_] X-AnalysisOut: [t_qRAA:9 a=wPNLvfGTeEIA:10 a=69XIa8IdTDMA:10 a=lZB815dzVvQ] X-AnalysisOut: [A:10 a=pGLkceISAAAA:8 a=sZqMfEgct6-69z2T0g8A:9 a=_W_S_7Vec] X-AnalysisOut: [oQA:10 a=tXsnliwV7b4A:10 a=0sBLNRBBEDUk7ti4:21] Cc: IETF Apps Discuss , eb2m-mrt@asahi-net.or.jp Subject: Re: [apps-discuss] FW: New Version Notification for draft-lilley-xml-mediatypes-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, 15 Nov 2012 20:26:37 -0000 This is a multi-part message in MIME format. --------------090305000902000204030308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I support it. Tony On 11/15/2012 9:36 AM, Murray S. Kucherawy wrote: > So far there's been only one expression of support for processing this > through appsawg. Are there any others? Any objections to processing > it here? Other suggestions? > > -MSK, co-chair > > > On Thu, Nov 1, 2012 at 4:01 AM, Chris Lilley > wrote: > > Hello apps-discuss, > > draft-lilley-xml-mediatypes-00.txt is a restart of a proposed > replacement for RFC3023. The previous attempt foundered because > the approach taken required deprecation of text/xml, and the > implementor community was not happy with that as there is much > legacy content using that type that still has to be supported. > > The present draft takes advantage of recent changes in HTTP-bis > which removes the default charset, and so treats text/xml the same > as application/xml. This approach is also what most > implementations already do, in practice. The present draft also > introduces some clarifications on fragment identifiers for xml, > and updates some references. > > It has been suggested that this document would be a good fit for > the apps area WG, and the editors would like to request review and > adoption by the WG (or an alternative suggestion of where/how to > handle this document). > > This would be a standards-track document. > > -- > Chris Lilley Technical Director, Interaction Domain > W3C Graphics Activity Lead, Fonts Activity Lead > Co-Chair, W3C Hypertext CG > Member, CSS, WebFonts, SVG Working Groups > _______________________________________________ > 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 --------------090305000902000204030308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I support it.

    Tony

On 11/15/2012 9:36 AM, Murray S. Kucherawy wrote:
So far there's been only one expression of support for processing this through appsawg.  Are there any others?  Any objections to processing it here?  Other suggestions?

-MSK, co-chair


On Thu, Nov 1, 2012 at 4:01 AM, Chris Lilley <chris@w3.org> wrote:
Hello apps-discuss,

draft-lilley-xml-mediatypes-00.txt is a restart of a proposed replacement for RFC3023. The previous attempt foundered because the approach taken required deprecation of text/xml, and the implementor community was not happy with that as there is much legacy content using that type that still has to be supported.

The present draft takes advantage of recent changes in HTTP-bis which removes the default charset, and so treats text/xml the same as application/xml. This approach is also what most implementations already do, in practice. The present draft also introduces some clarifications on fragment identifiers for xml, and updates some references.

It has been suggested that this document would be a good fit for the apps area WG, and the editors would like to request review and adoption by the WG (or an alternative suggestion of where/how to handle this document).

This would be a standards-track document.

--
 Chris Lilley   Technical Director, Interaction Domain
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
_______________________________________________
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

--------------090305000902000204030308-- From GK@ninebynine.org Thu Nov 15 12:33: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 2602321F8A38 for ; Thu, 15 Nov 2012 12:33:58 -0800 (PST) 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 Y+keyosZUj5G for ; Thu, 15 Nov 2012 12:33:57 -0800 (PST) Received: from relay2.mail.ox.ac.uk (relay2.mail.ox.ac.uk [163.1.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2F621F85EF for ; Thu, 15 Nov 2012 12:33:57 -0800 (PST) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay2.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TZ68J-00057P-9O for apps-discuss@ietf.org; Thu, 15 Nov 2012 20:33:55 +0000 Received: from [38.111.39.254] (helo=conina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TZ68J-0001Im-5c for apps-discuss@ietf.org; Thu, 15 Nov 2012 20:33:55 +0000 Message-ID: <50A550F8.4000403@ninebynine.org> Date: Thu, 15 Nov 2012 20:30:48 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <50A38259.4050304@googlemail.com> <3B530232-381D-4370-980B-B5B308443DDF@mnot.net> <50A4E7FD.5000705@ninebynine.org> <50A52817.7010505@berkeley.edu> In-Reply-To: <50A52817.7010505@berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Subject: Re: [apps-discuss] Links and graphs 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, 15 Nov 2012 20:33:58 -0000 For information, I've replied to this copying public-ldp-wg@w3.org but not apps-discuss@ietf.org, as I think the discussion is headed into territory more germane to web application than general IETF application issues. Interested folks can pick up the discussion at http://lists.w3.org/Archives/Public/public-ldp-wg/ #g -- On 15/11/2012 17:36, Erik Wilde wrote: > hello graham. > > On 2012-11-15 5:02 , Graham Klyne wrote: >> I don't follow what you're saying here. I don't disagree (as someone >> involved with RDF) that RDF has made its life hard in several ways, but >> if what you have and want to pass around is a graph, how does one *not* >> push it down into the data? > > the big problem with RDF on the level we're discussing here is that RDF pushes > everything into vocabularies, and thus renders media types almost meaningless > (apart from distinguishing RDF serializations). that's a problem for home > documents or similar web-oriented approaches that rely on the media type being a > crucial signal for understanding the interaction semantics of resources. > >> (Personally, I'd like to see json-home be something that has a clear >> mapping to RDF, but that's a different discussion.) > > fwiw, https://github.com/dret/I-D-1/tree/master/json-home is where i have > started creating a mapping to XML, and i'd be more than happy to collaborate > with others to do the same for an RDF schema. but like i said above, the whole > concept of home documents hinges around the assumption that a media type signals > interaction semantics, so that clients can decide what resources to engage with. > in RDF, this is not how the world works (yet, i still hope that we'll see this > tackled at some point in time), so maybe there's a little less utility in the > whole approach. regardless of that, we have discovered in our current work in > the "Linked Data Platform" W3C WG that we probably need some concept of a > "service document" or a "home document", and thus it might be interesting to > look at how the current json-home approach could be mapped to RDF and would give > us some useful foundation. > > cheers, > > dret. > From touch@isi.edu Thu Nov 15 13:10: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 1922F21F8B50 for ; Thu, 15 Nov 2012 13:10:44 -0800 (PST) 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 P67Rmt0i4VBw for ; Thu, 15 Nov 2012 13:10:43 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 05D4621F8AC2 for ; Thu, 15 Nov 2012 13:10:43 -0800 (PST) Received: from [75.192.216.137] (137.sub-75-192-216.myvzw.com [75.192.216.137]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id qAFL9ceN013675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Nov 2012 13:09:49 -0800 (PST) Message-ID: <50A55A13.3070200@isi.edu> Date: Thu, 15 Nov 2012 13:09:39 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eliot Lear References: <50A53A9A.3040302@cisco.com> In-Reply-To: <50A53A9A.3040302@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-ietf-tcpm-experimental-options.all@tools.ietf.org, Wesley Eddy , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Apps Directorate Review of draft-ietf-tcpm-experimental-options-02 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, 15 Nov 2012 21:10:44 -0000 Hi, Eliot, On 11/15/2012 10:55 AM, Eliot Lear wrote: > Dear Joe, > > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see ​ > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). > > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-tcpm-experimental-options-02 > Title: Shared Use of Experimental TCP Options > Reviewer: Eliot Lear > Review Date: 15 Nov. 2012 > IETF Last Call Date: none. > IESG Telechat Date: none. > > This document is not yet ready for publication, and requires > consideration of several major issues. As an apps directorate reviewer, > I can say that since many if not most applications sit atop TCP, the > impact of experimental options can be quite serious. > > Major Issues > > I would want to know that the working group seriously considered a fixed > length for the magic field. In general, I'm uncomfortable with the > SHOULD for the size of the field, and would be more comfortable with a MUST. We discussed this in the WG. There is no reason for a fixed field; letting the protocol designer decide allows them to trade the potential for collision with the space cost, which for TCP options is a critical decision. > More importantly this draft raises a concern about options that are > meant to be EXPERIMENTAL, but somehow the experiments got out of the > lab. There is no IETF requirement that Experimental RFCs describe protocols which are excluded from the public Internet (e.g., see RFC 2026 which defines the tracks, as well as the Tao of the IETF). In some cases protocols are specified as experimental primarily because some aspects are in flux and require operational experience to resolve; in other cases the protocol is just not expected to be of widescale interest or deployment. Experiments do use assigned codepoints. Some confusion may be the result of the statement in RFC 4727 which asserts that some codepoints reserved for experiments MUST NOT be shipped as defaults. However, there is no prohibition in RFC 4727 or elsewhere in the IETF AFAIK that prohibits their deployment or use in the public Internet. The doc should be more clear on this point; I can updated it accordingly. > I'd like to understand how often this has actually been a > problem. As noted above, it's already permitted. Some systems already deploy experiments as defaults; some use experimental codepoints (as summarized in this doc already), and others use assigned codepoints or configurations that are set as default (e.g., the default Linux and MS TCP flow control is not standards-track AFAIR). > IMHO I don't understand why we would think that implementers > would follow the advice given in this draft if they didn't bother > attempting registering allocation with IANA (Section 1, Page 3). This > section, needs to more clearly state the problem meant to be addressed. I agree this can be more clear. There are two reasons this doc's approach is useful: 1) there are experimenters who do want to use this approach, and it has encouraged them to use the experimental codepoints rather than asking for assigned codepoints 2) the magic number approach in this doc protects those who follow its approach from those who do not but who 'squat' on the experimental codepoints Overall, we believe this will reduce squatting by encouraging good behavior, but it is not intended to track, punish, or otherwise prohibit squatters. > If this draft is to move ahead, a specific PRN algorithm should be > recommended for selection of the magic number so as to avoid > collisions. The SAAG folk can help here. Such algorithms are important when numbers are generated within a protocol. Magic numbers are generated by the author at the time the document is written, and so the method described (using the low-order bits of a clock, sampled when the doc is first written) are more than sufficient to avoid collision. > Similarly 3.2 argues against the whole concept. Let's not try to > address backward compatibility of use of this feature with experiments > in this document, other than to say that this mechanism isn't intended > for use with a uniquely assigned option. I discussed this with the AD given his review, and I think I agree with your approach. IMO, "backward compatible" implementations need to support both variants (experimental codepoint/magic number and assigned codepoint), and the user or system needs to pick one when the option is selected. > Minor Issues > > The ASCII art in Section 3 should give field lengths. Will do. > I really don't know what to make of Section 3.1. The SHOULD there > tells me to do something if my implementation is not robust, but then > if I do it, it is robust, right? Clearer advise should be given. > Like perhaps the following: if an implementation receives a response > that does not follow the the experiemental design, it MUST cease > sending the option in question and interpreting any such results, and > SHOULD terminate the TCP connection and try again. Perhaps hosts > participating in the experiment should cache failures and log them? Strictly, there's no way to know the difference between two experiments colliding and just a bad implementation of the intended option. How such errors are handled is up to the option designer. The section could be clearer on what could happen, e.g.: - two experiments collide using the same magic number - two experiments collide with different magic numbers - an experiment with a magic number collides with an experiment that doesn't use the magic number but whose option looks like it matches magic numbers - an experiment with a magic number collides with an experiment that doesn't use the magic number and whose option does not match the magic number In reality, the observer sees either: - magic number matches - magic number doesn't match TCP specifies that options not implemented are silently ignored. That's true not only during a SYN but throughout the entire connection. So AFAICT, if the magic number doesn't match the endpoint should treat it like an option that isn't implemented. If the magic number does match and the option can be detected as "malformed", that's handled by the option (that could be a bad implementation or a collision). I can add that to the discussion; let me know if it addresses your concerns. Joe > > Eliot > From lear@cisco.com Thu Nov 15 13:20: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 0306D21F849A for ; Thu, 15 Nov 2012 13:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.596 X-Spam-Level: X-Spam-Status: No, score=-110.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 tKykOsjJL9op for ; Thu, 15 Nov 2012 13:20:12 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B311721F8495 for ; Thu, 15 Nov 2012 13:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6192; q=dns/txt; s=iport; t=1353014412; x=1354224012; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zRCxH9ew8XqkQ7Sqp9Jn9/bXDY963c13CzOOGYnn5Dk=; b=EtvLIg74ssKw4l+/iq1zQexH4re1F5rGEMEdnvN8PjS9YpSc6X06JHJN jS5ahYa/wPyvrU+yrfiP9VgvKB2LLmvVWY/W5dAozbMW+rXWgJt67ujfT Ljo804Y1eHmw/r7BpooZo0Dtz6D4wNB8leRUZaJZMJXcXPs9ZlXJCO6XP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAIRbpVCQ/khR/2dsb2JhbABEDoYPuGCDRYEIgh4BAQEDARIBEFUBEAsYAgIFFgsCAgkDAgECAUUGDQEHAQEeh2UGnQuNKJJkgSKQKIETA5JKgzKOWIFrgjI+ X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="146812818" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 15 Nov 2012 21:20:11 +0000 Received: from dhcp-10-55-83-48.cisco.com (dhcp-10-55-83-48.cisco.com [10.55.83.48]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAFLK9V9009168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 21:20:10 GMT Message-ID: <50A55C89.3030508@cisco.com> Date: Thu, 15 Nov 2012 22:20:09 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Joe Touch References: <50A53A9A.3040302@cisco.com> <50A55A13.3070200@isi.edu> In-Reply-To: <50A55A13.3070200@isi.edu> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-tcpm-experimental-options.all@tools.ietf.org, Wesley Eddy , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Apps Directorate Review of draft-ietf-tcpm-experimental-options-02 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, 15 Nov 2012 21:20:15 -0000 Joe, On 11/15/12 10:09 PM, Joe Touch wrote: > > We discussed this in the WG. There is no reason for a fixed field; > letting the protocol designer decide allows them to trade the > potential for collision with the space cost, which for TCP options is > a critical decision. Ok, as long as it was discussed. > >> More importantly this draft raises a concern about options that are >> meant to be EXPERIMENTAL, but somehow the experiments got out of the >> lab. > > There is no IETF requirement that Experimental RFCs describe protocols > which are excluded from the public Internet (e.g., see RFC 2026 which > defines the tracks, as well as the Tao of the IETF). In some cases > protocols are specified as experimental primarily because some aspects > are in flux and require operational experience to resolve; in other > cases the protocol is just not expected to be of widescale interest or > deployment. > > Experiments do use assigned codepoints. > > Some confusion may be the result of the statement in RFC 4727 which > asserts that some codepoints reserved for experiments MUST NOT be > shipped as defaults. However, there is no prohibition in RFC 4727 or > elsewhere in the IETF AFAIK that prohibits their deployment or use in > the public Internet. > > The doc should be more clear on this point; I can updated it accordingly. Ok. > >> I'd like to understand how often this has actually been a >> problem. > > As noted above, it's already permitted. > > Some systems already deploy experiments as defaults; some use > experimental codepoints (as summarized in this doc already), and > others use assigned codepoints or configurations that are set as > default (e.g., the default Linux and MS TCP flow control is not > standards-track AFAIR). > > > IMHO I don't understand why we would think that implementers >> would follow the advice given in this draft if they didn't bother >> attempting registering allocation with IANA (Section 1, Page 3). This >> section, needs to more clearly state the problem meant to be addressed. > > I agree this can be more clear. > > There are two reasons this doc's approach is useful: > > 1) there are experimenters who do want to use this approach, and it > has encouraged them to use the experimental codepoints rather than > asking for assigned codepoints This is a BIG deal and should be in the draft!! > > 2) the magic number approach in this doc protects those who follow its > approach from those who do not but who 'squat' on the experimental > codepoints Ok. That needs to be clarified as well. Both good points. > > Overall, we believe this will reduce squatting by encouraging good > behavior, but it is not intended to track, punish, or otherwise > prohibit squatters. > >> If this draft is to move ahead, a specific PRN algorithm should be >> recommended for selection of the magic number so as to avoid >> collisions. The SAAG folk can help here. > > Such algorithms are important when numbers are generated within a > protocol. Magic numbers are generated by the author at the time the > document is written, and so the method described (using the low-order > bits of a clock, sampled when the doc is first written) are more than > sufficient to avoid collision. Sorry I meant it should be used JUST for the assignment, not operationally in path, but people do a poor job of this. Better to tell them how to do it. Think ULAs. > >> Similarly 3.2 argues against the whole concept. Let's not try to >> address backward compatibility of use of this feature with experiments >> in this document, other than to say that this mechanism isn't intended >> for use with a uniquely assigned option. > > I discussed this with the AD given his review, and I think I agree > with your approach. IMO, "backward compatible" implementations need to > support both variants (experimental codepoint/magic number and > assigned codepoint), and the user or system needs to pick one when the > option is selected. > >> Minor Issues >> >> The ASCII art in Section 3 should give field lengths. > > Will do. > >> I really don't know what to make of Section 3.1. The SHOULD there >> tells me to do something if my implementation is not robust, but then >> if I do it, it is robust, right? Clearer advise should be given. >> Like perhaps the following: if an implementation receives a response >> that does not follow the the experiemental design, it MUST cease >> sending the option in question and interpreting any such results, and >> SHOULD terminate the TCP connection and try again. Perhaps hosts >> participating in the experiment should cache failures and log them? > > Strictly, there's no way to know the difference between two > experiments colliding and just a bad implementation of the intended > option. How such errors are handled is up to the option designer. > > The section could be clearer on what could happen, e.g.: > > - two experiments collide using the same magic number > - two experiments collide with different magic numbers > - an experiment with a magic number collides with an experiment that > doesn't use the magic number but whose option looks like it matches > magic numbers > - an experiment with a magic number collides with an experiment that > doesn't use the magic number and whose option does not match the magic > number > > In reality, the observer sees either: > - magic number matches > - magic number doesn't match > > TCP specifies that options not implemented are silently ignored. > That's true not only during a SYN but throughout the entire > connection. So AFAICT, if the magic number doesn't match the endpoint > should treat it like an option that isn't implemented. > > If the magic number does match and the option can be detected as > "malformed", that's handled by the option (that could be a bad > implementation or a collision). > > I can add that to the discussion; let me know if it addresses your > concerns. In general, the more explicit you can be about normative language the better, so yes it helps. Thanks! Eliot From mnot@mnot.net Thu Nov 15 15:16: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 9180F21F86A2; Thu, 15 Nov 2012 15:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.864 X-Spam-Level: X-Spam-Status: No, score=-104.864 tagged_above=-999 required=5 tests=[AWL=-2.265, 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 ZxFVms+JBfof; Thu, 15 Nov 2012 15:16:41 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 4947321F8669; Thu, 15 Nov 2012 15:16:41 -0800 (PST) Received: from [192.168.1.64] (unknown [118.209.81.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5DD11509B7; Thu, 15 Nov 2012 18:16:37 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Fri, 16 Nov 2012 10:16:37 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <95605F61-E530-4985-B385-0DA3D1E6084F@mnot.net> References: <6.2.5.6.2.20121114233206.0cbf0478@elandnews.com> To: Henry S. Thompson X-Mailer: Apple Mail (2.1499) Cc: draft-ietf-appsawg-json-patch.all@tools.ietf.org, appsdir@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [appsdir] Appsdir review of draft-ietf-appsawg-json-patch-06 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, 15 Nov 2012 23:16:44 -0000 Hi Henry, Thanks for the review. Responses below. On 16/11/2012, at 4:06 AM, Henry S. Thompson 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)= . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. >=20 > Document: draft-ietf-appsawg-json-patch-06 > Title: JSON Patch > Reviewer: Henry S. Thompson > Review Date: 15 November 2012 > IETF Last Call Date: 2012-11-23 >=20 > Summary: This draft is almost ready for publication as an Proposed > Standard but has a related set of issues that should be fixed > before publication >=20 > Note that I have not read previous drafts of or comments on this > document -- I presume I was asked to review as a fresh pair of eyes. > If the result is to repeat some previously-expressed comments, so be > it. >=20 > Major Issues:=20 >=20 > 4.1 This operation ('add') seems underspecified in several respects. >=20 > 1) I would have expected a short statement of the actual effect > under each bullet, e.g. "The specified value becomes the entire > contents of the document"; I'll add these. > 2) I would have expected error conditions to be specified under each > bullet. I assume it is an error for "path" to be empty and the > document to have content. The discussion of index errors wrt > arrays could/should move, and the "common use" 'note', which > isn't a note at all, should be specific to objects. I'll look at reorganising these (is this really a *major* issue?). > 3) I take it you also need to say that if an _existing_ member of an > object is referenced, that's not an error (note that it _is_ a > JSON Pointer error), and the result is to increase the number of > such members by one, with the new value. I think that'll be the outcome of #1 above, yes. > I think in fact you might be better off to handle this by cases and > avoid all 'intentional' JSON Pointer errors, along the lines of >=20 > a) If the "path" is "" and the document is empty then the "value" > becomes the document; >=20 > b) If the path excluding its last step identifies an object, then > "value" is added at the end of that object, with the name given = by > the decoded reference token of the last step; >=20 > c) If the path excluding its last step identifies an array then >=20 > i) If the last step's reference token encodes an integer i with > 0 <=3D i < |array|, then . . . > ii) If the last step's reference token is '-' or encodes > |array|, then . . . >=20 > Otherwise, the operation raises an error. The "excluding its last step" is awkward. The error conditions in json = pointer were put there for exactly this kind of use; is it the word = 'error' that's causing you concern? > 4.2, 4.3 Nothing is said about the case where a path which identifies = a > multiply-valued object member is given, which per JSON Pointer is > a pointer error. To be clear - are you saying that we should handle the case where an = error in the underlying JSON bubbles up through JSON Pointer? E.g., { "foo": "bar", "foo": "baz" } ? > 4.4 Given the real complexity of both 'remove' and 'add', 'move' > really should be defined by reference to those operations, rather > than repeating (imperfectly at the moment) their definitions. > This would have the additional benefit of removing the necessity > for the side conditions, all of which will now follow from the > definitions of 'remove' and 'add' (except the invalidity of > replacing the root, which should as far as I can see be allowed - > { "op": "move", "path": "/a/b", "to": "" } seems perfectly > reasonable to me). To do that, I think we'd need to change "to" to "from", as the semantics = of "path" are so different.=20 I'm not averse to doing so, as long as we can get to agreement about it = quickly. Anyone object? > 4.5 Again, although the first side condition would have to remain, > this should be defined by reference to 'add'. See below under Minor > Issues wrt the second side condition To do that, I think we'd need to change "to" to "from", as the semantics = of "path" are so different.=20 I'm not averse to doing so, as long as we can get to agreement about it = quickly. Anyone object? > Minor Issues:=20 >=20 > 1. This is perfectly clear, but I still missed it: This spec. (and > JSON Pointer) are about _documents_ and not Javascript objects. > It's very easy to slip into thinking about objects, and indeed the > spec. itself talks about the target as if it consisted of objects > and arrays! It would of course be obnoxious to require you to say > "JSON encoding of an object" every time, instead of just "object", > but I wonder if it wouldn't be a good idea to say, here in the > introduction, precisely that -- that you will (mostly) talk about > the target as if it had a root, consisted of arrays and objects > with members and values, etc., but what you will always _mean_ is > being pointed to, tested, changed, etc. is the _JSON encoding_ of > those things. It *can* be about JavaScript objects; that was a use case for some = people, resulting in a bit of the dancing that we do. > 3. In a similar vein, wrt the patch document itself, I think it would > be better to say e.g. "A JSON Patch document is a JSON [RFC4627] > document which [represents/encodes/whatever] an array of objects." OK. > 4.5 I don't understand the reason for barring copying to an existing > member. The rest of the spec. seems content to allow multiple > identically-named members to be specified. . . You would, I > guess, need to say that where it goes, but if you defined by > reference to "add" as I've given it above, that would be taken > care of. We took similar language out of add (see thread 'json-patch: "op": = "insert" and "op": "put"'). I think it's reasonably to take it out of = copy as well -- others? > 4.6 When you get to string-string equality the object / encoding > duality discussed above at 1. becomes a problem -- you have > treated the patch as an object up until now, in which case any > escaping will already have been dealt with. If one took the words > in this case literally, the following test would succeed: >=20 > Target { "a":"\b" } >=20 > Patch [ { "op": "test", "path": "/a", "value":"\\b" } ] >=20 > which is presumably not what you meant. It's clear from the > wording you've used in this case that you _meant_ to refer here > (and only here) to the _encoding_ of the value of the "value" > property of the patch, not its value. Phew! I think we can address this by making it clear that all of the = operations are specified in term of JSON primitives (i.e., after = escaping), but examples are JSON documents, and giving a few more = examples to illustrate the corner cases. Make sense? Cheers, -- Mark Nottingham http://www.mnot.net/ From sm@elandsys.com Thu Nov 15 15:24: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 CC2C021F853C for ; Thu, 15 Nov 2012 15:24:51 -0800 (PST) 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 TgFAe6rrFoU6 for ; Thu, 15 Nov 2012 15:24:50 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA3A21F8522 for ; Thu, 15 Nov 2012 15:24:50 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.152.44]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAFNOa8I008105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 15:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353021889; bh=h3vSFRaSFCgGxXeoFRAq97BhfnSoNh7RzPqnjro4xv4=; h=Date:To:From:Subject:Cc; b=aKdlIrFiXHAVrhCvZwECWu97vc2zTcPR5oQyfRdvL/rys1R5NJQMQif3WYOvJn73w h5kgTgpjyqxCWB5dQVaHt2f9gV8yJch+XJEnh6OYJm2WRvTVLtyyJq2XZF2YBhL21b nMdm3z6HOWWZhAOlccqDlPzy65ViIrvXIy26FMN8= Message-Id: <6.2.5.6.2.20121115152250.09ffa450@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 15 Nov 2012 15:23:37 -0800 To: apps-discuss@ietf.org From: Mark Nottingham (by way of S Moonesamy ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Mark Nottingham Subject: Re: [apps-discuss] Appsdir review of draft-ietf-appsawg-json-patch-06 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, 15 Nov 2012 23:24:51 -0000 Hi Henry, Thanks for the review. Responses below. On 16/11/2012, at 4:06 AM, Henry S. Thompson 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 before posting a new version of the draft. > > Document: draft-ietf-appsawg-json-patch-06 > Title: JSON Patch > Reviewer: Henry S. Thompson > Review Date: 15 November 2012 > IETF Last Call Date: 2012-11-23 > > Summary: This draft is almost ready for publication as an Proposed > Standard but has a related set of issues that should be fixed > before publication > > Note that I have not read previous drafts of or comments on this > document -- I presume I was asked to review as a fresh pair of eyes. > If the result is to repeat some previously-expressed comments, so be > it. > > Major Issues: > > 4.1 This operation ('add') seems underspecified in several respects. > > 1) I would have expected a short statement of the actual effect > under each bullet, e.g. "The specified value becomes the entire > contents of the document"; I'll add these. > 2) I would have expected error conditions to be specified under each > bullet. I assume it is an error for "path" to be empty and the > document to have content. The discussion of index errors wrt > arrays could/should move, and the "common use" 'note', which > isn't a note at all, should be specific to objects. I'll look at reorganising these (is this really a *major* issue?). > 3) I take it you also need to say that if an _existing_ member of an > object is referenced, that's not an error (note that it _is_ a > JSON Pointer error), and the result is to increase the number of > such members by one, with the new value. I think that'll be the outcome of #1 above, yes. > I think in fact you might be better off to handle this by cases and > avoid all 'intentional' JSON Pointer errors, along the lines of > > a) If the "path" is "" and the document is empty then the "value" > becomes the document; > > b) If the path excluding its last step identifies an object, then > "value" is added at the end of that object, with the name given by > the decoded reference token of the last step; > > c) If the path excluding its last step identifies an array then > > i) If the last step's reference token encodes an integer i with > 0 <= i < |array|, then . . . > ii) If the last step's reference token is '-' or encodes > |array|, then . . . > > Otherwise, the operation raises an error. The "excluding its last step" is awkward. The error conditions in json pointer were put there for exactly this kind of use; is it the word 'error' that's causing you concern? > 4.2, 4.3 Nothing is said about the case where a path which identifies a > multiply-valued object member is given, which per JSON Pointer is > a pointer error. To be clear - are you saying that we should handle the case where an error in the underlying JSON bubbles up through JSON Pointer? E.g., { "foo": "bar", "foo": "baz" } ? > 4.4 Given the real complexity of both 'remove' and 'add', 'move' > really should be defined by reference to those operations, rather > than repeating (imperfectly at the moment) their definitions. > This would have the additional benefit of removing the necessity > for the side conditions, all of which will now follow from the > definitions of 'remove' and 'add' (except the invalidity of > replacing the root, which should as far as I can see be allowed - > { "op": "move", "path": "/a/b", "to": "" } seems perfectly > reasonable to me). To do that, I think we'd need to change "to" to "from", as the semantics of "path" are so different. I'm not averse to doing so, as long as we can get to agreement about it quickly. Anyone object? > 4.5 Again, although the first side condition would have to remain, > this should be defined by reference to 'add'. See below under Minor > Issues wrt the second side condition To do that, I think we'd need to change "to" to "from", as the semantics of "path" are so different. I'm not averse to doing so, as long as we can get to agreement about it quickly. Anyone object? > Minor Issues: > > 1. This is perfectly clear, but I still missed it: This spec. (and > JSON Pointer) are about _documents_ and not Javascript objects. > It's very easy to slip into thinking about objects, and indeed the > spec. itself talks about the target as if it consisted of objects > and arrays! It would of course be obnoxious to require you to say > "JSON encoding of an object" every time, instead of just "object", > but I wonder if it wouldn't be a good idea to say, here in the > introduction, precisely that -- that you will (mostly) talk about > the target as if it had a root, consisted of arrays and objects > with members and values, etc., but what you will always _mean_ is > being pointed to, tested, changed, etc. is the _JSON encoding_ of > those things. It *can* be about JavaScript objects; that was a use case for some people, resulting in a bit of the dancing that we do. > 3. In a similar vein, wrt the patch document itself, I think it would > be better to say e.g. "A JSON Patch document is a JSON [RFC4627] > document which [represents/encodes/whatever] an array of objects." OK. > 4.5 I don't understand the reason for barring copying to an existing > member. The rest of the spec. seems content to allow multiple > identically-named members to be specified. . . You would, I > guess, need to say that where it goes, but if you defined by > reference to "add" as I've given it above, that would be taken > care of. We took similar language out of add (see thread 'json-patch: "op": "insert" and "op": "put"'). I think it's reasonably to take it out of copy as well -- others? > 4.6 When you get to string-string equality the object / encoding > duality discussed above at 1. becomes a problem -- you have > treated the patch as an object up until now, in which case any > escaping will already have been dealt with. If one took the words > in this case literally, the following test would succeed: > > Target { "a":"\b" } > > Patch [ { "op": "test", "path": "/a", "value":"\\b" } ] > > which is presumably not what you meant. It's clear from the > wording you've used in this case that you _meant_ to refer here > (and only here) to the _encoding_ of the value of the "value" > property of the patch, not its value. Phew! I think we can address this by making it clear that all of the operations are specified in term of JSON primitives (i.e., after escaping), but examples are JSON documents, and giving a few more examples to illustrate the corner cases. Make sense? Cheers, -- Mark Nottingham http://www.mnot.net/ _______________________________________________ appsdir mailing list appsdir@ietf.org https://www.ietf.org/mailman/listinfo/appsdir From sm@elandsys.com Thu Nov 15 15:33: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 D99D921F8A58; Thu, 15 Nov 2012 15:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 gZ2Ct4gisk+f; Thu, 15 Nov 2012 15:33:22 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E033A21F8463; Thu, 15 Nov 2012 15:33:21 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.152.44]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAFNX8fw005863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 15:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353022400; bh=Nwfl7ELUAhBJKYbhAXWm395ogfTXDUwvFbWKuzStlxc=; h=Date:To:From:Subject:Cc; b=ugSFn7M757hOZhIAAtnzFvwISg8E2X0mTGy+/VARMRLZviczvF7HNRIxVvbmEBiRn nLy+GlnK8V90Q93gg8CgU4KVh5vBGa0zaWkZGHbomZR/akLRHgXVxL21i1FwsV4X5c Q4tO0nhm66HNE6oxgj0DTHxWAMTDUNxb/Fa2+I/4= Message-Id: <6.2.5.6.2.20121115153136.0a4db440@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 15 Nov 2012 15:32:50 -0800 To: apps-discuss@ietf.org From: Claudio Allocchio (by way of S Moonesamy ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-mptcp-api.all@tools.ietf.org, iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-mptcp-api-06 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, 15 Nov 2012 23:33:23 -0000 Hello all, I have been selected as the Applications Area Directorate co-reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mptcp-api-06 Title: MPTCP Application Interface Considerations Reviewer: Claudio Allocchio Review Date: November 15th 2012 IETF Last Call Date: n/a IESG Telechat Date: November 15th2012 Summary: Given the arelady given comments on the apps-discuss ML on many parts of this informaiton documents (and I agree with them) I focused my review on the effects that MPTCP can have on esisting applications and deployment. I think the doument is anyhow very well written and ready for publication. However there a few minor issues that shall be fixed. Major Issues: none. Minor Issues: 3.1.2. Delay "Since burstiness is commonplace on the Internet today, it is unlikely that applications will suffer from such an impact on the traffic profile, but application authors may wish to consider this in future development." well, even it is true the burstiness is common on most of the Internet, this is not the case in many other circumstances, and there are, maybe a few, applications which do expect the jitter to be low and the packet delivery rate to be stable to work correctly (being the developer of one of them... "LOLA - Low latency A/V system" I did expericend already a number of cases where MPTCP did a disaster work just because of its presence on multiple parallel 10G links). Thus I would at least be not to optimistic in the above sentence. It is just not for future work. I just suggest changing it reportig that "this might be a problem" instead of "it is unlikely". In the same 3.1.2 section, again there are some application (already now) they deeply rely for correct functiong on an accurate estimate of RTT (for example those dealing with audio echo cancellation, or those triggering large scale instrumentation synchronization (for example EVLBI radio telescopes). Thus it not just "new" applications, but what my happen to existing applications shall be mentioned. in 3.2.1: "An MPTCP implementation can learn the rate of MPTCP connection attempt successes or failures to particular hosts or networks, and on particular interfaces, and could therefore learn heuristics of when and when not to use MPTCP." Well... are we sure this is a good suggestion? If it is a suggestion, then, what happens when network condition changes dynamically (for example because an application running as a client on a mobile host is moving about?) A.2. MPTCP Usage Scenarios and Application Requirements There are also application which requires bulk data traffic (in the range 1G and above) AND anre higly interactive, thus ask for low latency and jitter. What should be the choice in this (already existing) case? SOm guidance should be added also for them. Nits: 3.1. Performance Impact --> Effects on Performanc 5.2. "This can be implicit in many cases, since MPTCP must BE disabled by the use of binding to a specific address. ^^^" ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From mnot@mnot.net Thu Nov 15 15:35: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 97B0021F8856 for ; Thu, 15 Nov 2012 15:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.795 X-Spam-Level: X-Spam-Status: No, score=-104.795 tagged_above=-999 required=5 tests=[AWL=-2.196, 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 zxZCVEA1V8up for ; Thu, 15 Nov 2012 15:35:41 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id E13F321F852B for ; Thu, 15 Nov 2012 15:35:40 -0800 (PST) Received: from [192.168.1.64] (unknown [118.209.81.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 97FD8509B6; Thu, 15 Nov 2012 18:35:38 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Fri, 16 Nov 2012 10:35:39 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> References: To: Cyrus Daboo X-Mailer: Apple Mail (2.1499) Cc: Apps Discuss Subject: Re: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 15 Nov 2012 23:35:41 -0000 Hi Cyrus, Thanks for the review. On 16/11/2012, at 2:57 AM, Cyrus Daboo wrote: > Hi, > Here are my review comments (mostly nits - nothing major): >=20 > =A71: Introduction focusses on the use of JSON patch in HTTP PATCH, = but of course it could be used anywhere else a "patch" operation is = needed (other protocols". It might be worth adding some text explaining = the more "generic" use case. e.g.: >=20 > This format is also applicable to any protocol that might want to > process partial updates to a JSON document. Will do. > =A74.1 talks about the "-" value for arrays, but that value is also = applicable to "move" and "copy". Should that statement also appear in = =A74.4 and =A74.5 or be moved to a more "generic" location - e.g. in the = main text of =A74? Will have a look. > =A74.6 uses a very basic octet/code-point comparator. Do we care about = possible unicode normalizations issues? If so that will need to be dealt = with, if not there ought to be a clarifying statement - in fact an = "Internationalization Considerations" section may be warranted. Urgh.=20 > =A74.6 numbers - any concern about numeric precision affecting the = "subtracting one from another" behavior? mumble. Any suggestion for a better way to specify? > =A75 when an error occurs it would be handy to have some minimal form = of error reporting - simply the index of the operation that failed. Can = we define a JSON format for an HTTP PATCH error response? Maybe one day... but not today :) > =A76 XML patch uses a MIME type "patch-ops-error+xml", why is this not = "patch+json"? I think the going answer is that this is not an effort to define a = single patch format with multiple serialisations; it's very very = specific to the JSON data model, so +json isn't warranted. > =A7A.6 - missing comma between members "foo" and "qux" in the two = document examples. ack Thanks again, -- Mark Nottingham http://www.mnot.net/ From James.H.Manger@team.telstra.com Thu Nov 15 19:56: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 E94A521E803F for ; Thu, 15 Nov 2012 19:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 xmI+OHAiUZiV for ; Thu, 15 Nov 2012 19:56:12 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 356D521E802E for ; Thu, 15 Nov 2012 19:56:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,261,1352034000"; d="scan'208";a="101708937" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 16 Nov 2012 14:56:05 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="99749123" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipccni.tcif.telstra.com.au with ESMTP; 16 Nov 2012 14:56:05 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 16 Nov 2012 14:56:05 +1100 From: "Manger, James H" To: Paul Hoffman , "apps-discuss@ietf.org Discuss" Date: Fri, 16 Nov 2012 14:56:04 +1100 Thread-Topic: [apps-discuss] Review of draft-ietf-appsawg-json-pointer Thread-Index: Ac3DRU+qCGHRhIzkTj6BYcdKrkOG+gAZkinw Message-ID: <255B9BB34FB7D647A506DC292726F6E115006C7A5C@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-json-pointer 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, 16 Nov 2012 03:56:13 -0000 PiAtIE9uZSBvZiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaXMgdG9vIGxpbWl0ZWQuDQo+ ICAgIE5vdGUgdGhhdCBKU09OIHBvaW50ZXJzIGNhbiBjb250YWluIHRoZSBOVUwgKFVuaWNvZGUg VSswMDAwKQ0KPiAgICBjaGFyYWN0ZXIsIHdoaWNoIG1heSBub3QgYmUgcmVwcmVzZW50YWJsZSBp biBhbGwgcHJvZ3JhbW1pbmcNCj4gICAgbGFuZ3VhZ2VzLg0KPiBUaGUgc2FtZSBpcyB0cnVlIGZv ciBhbGwgY29udHJvbCBjaGFyYWN0ZXJzLCBhbmQgZm9yIHNvbWUgcHJvZ3JhbW1pbmcNCj4gbGFu Z3VhZ2VzLCBhbGwgbm9uLUFTQ0lJIGNoYXJhY3RlcnMuIFByb3Bvc2VkIHJld29yZGluZzoNCj4g ICAgTm90ZSB0aGF0IEpTT04gcG9pbnRlcnMgY2FuIGNvbnRhaW4gdGhlIE5VTCAoVW5pY29kZSBV KzAwMDApDQo+ICAgIGNoYXJhY3RlciwgY29udHJvbCBjaGFyYWN0ZXJzLCBub24tQVNDSUkgY2hh cmFjdGVycywgYW5kIHNvDQo+ICAgIG9uLiBUaGVzZSBjaGFyYWN0ZXJzIG1heSBub3QgYmUgcmVw cmVzZW50YWJsZSBpbiBhbGwgcHJvZ3JhbW1pbmcNCj4gICAgbGFuZ3VhZ2VzLg0KDQpUaGUgaXNz dWUgd2l0aCBOVUwgaXMgdGhhdCB5b3UgbmVlZCB0byBiZSBjYXJlZnVsIG5vdCB0byBtaXNpbnRl cnByZXQgaXQgYXMgYW4gZW5kLW9mLXN0cmluZyBtYXJrZXIuIEhvdyBhYm91dDoNCg0KICAgTm90 ZSB0aGF0IEpTT04gcG9pbnRlcnMgY2FuIGNvbnRhaW4gdGhlIE5VTCAoVW5pY29kZSBVKzAwMDAp DQogICBjaGFyYWN0ZXIuIENhcmUgaXMgbmVlZGVkIG5vdCB0byBtaXNpbnRlcnByZXQgdGhpcyBj aGFyYWN0ZXINCiAgIGluIHByb2dyYW1taW5nIGxhbmd1YWdlcyB0aGF0IHVzZSBOVUwgdG8gbWFy ayB0aGUgZW5kIG9mIGEgc3RyaW5nLg0KDQoNCkFuZCBhIHJlbWluZGVyIHRoYXQgdGhlcmUgd2Fz IG9uZSBvdGhlciBqdXN0LWJlZm9yZS1XR0xDIGNvbW1lbnQ6IGRpc2FsbG93aW5nIHVubmVjZXNz YXJ5IGxlYWRpbmcgMCdzIChlZyBhbGxvdyAvNywgYnV0IG5vdCAvMDA3LCB0byBwb2ludCBpbnRv IGFuIGFycmF5KS4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From mnot@mnot.net Thu Nov 15 20:17: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 3A3B321E8051 for ; Thu, 15 Nov 2012 20:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.731 X-Spam-Level: X-Spam-Status: No, score=-104.731 tagged_above=-999 required=5 tests=[AWL=-2.132, 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 bMIxlli3tFlK for ; Thu, 15 Nov 2012 20:17:48 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 8659E21E803C for ; Thu, 15 Nov 2012 20:17:48 -0800 (PST) Received: from [192.168.1.64] (unknown [118.209.81.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A80DA509B7; Thu, 15 Nov 2012 23:17:46 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115006C7A5C@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 16 Nov 2012 15:17:42 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <45B7BA35-8717-4597-902B-168E7B894A68@mnot.net> References: <255B9BB34FB7D647A506DC292726F6E115006C7A5C@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1499) Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-json-pointer 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, 16 Nov 2012 04:17:49 -0000 On 16/11/2012, at 2:56 PM, "Manger, James H" = wrote: > The issue with NUL is that you need to be careful not to misinterpret = it as an end-of-string marker. How about: >=20 > Note that JSON pointers can contain the NUL (Unicode U+0000) > character. Care is needed not to misinterpret this character > in programming languages that use NUL to mark the end of a string. In Security Considerations? > And a reminder that there was one other just-before-WGLC comment: = disallowing unnecessary leading 0's (eg allow /7, but not /007, to point = into an array). Yes. probably needs to make it into the ABNF. -- Mark Nottingham http://www.mnot.net/ From James.H.Manger@team.telstra.com Thu Nov 15 20:50: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 1C07021F8477 for ; Thu, 15 Nov 2012 20:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 cxYAfOp8IdDe for ; Thu, 15 Nov 2012 20:50:13 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA7E21F8472 for ; Thu, 15 Nov 2012 20:50:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,261,1352034000"; d="scan'208";a="103758810" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 16 Nov 2012 15:50:10 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="142969302" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcavi.tcif.telstra.com.au with ESMTP; 16 Nov 2012 15:50:09 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Fri, 16 Nov 2012 15:50:09 +1100 From: "Manger, James H" To: Mark Nottingham Date: Fri, 16 Nov 2012 15:50:08 +1100 Thread-Topic: [apps-discuss] Review of draft-ietf-appsawg-json-pointer Thread-Index: Ac3DsVfpb1RjC6APRY2NyTWdVSnQewAACFNg Message-ID: <255B9BB34FB7D647A506DC292726F6E115006C7BCF@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E115006C7A5C@WSMSG3153V.srv.dir.telstra.com> <45B7BA35-8717-4597-902B-168E7B894A68@mnot.net> In-Reply-To: <45B7BA35-8717-4597-902B-168E7B894A68@mnot.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-json-pointer 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, 16 Nov 2012 04:50:18 -0000 PiA+IFRoZSBpc3N1ZSB3aXRoIE5VTCBpcyB0aGF0IHlvdSBuZWVkIHRvIGJlIGNhcmVmdWwgbm90 IHRvIG1pc2ludGVycHJldA0KPiBpdCBhcyBhbiBlbmQtb2Ytc3RyaW5nIG1hcmtlci4gSG93IGFi b3V0Og0KPiA+DQo+ID4gICBOb3RlIHRoYXQgSlNPTiBwb2ludGVycyBjYW4gY29udGFpbiB0aGUg TlVMIChVbmljb2RlIFUrMDAwMCkNCj4gPiAgIGNoYXJhY3Rlci4gQ2FyZSBpcyBuZWVkZWQgbm90 IHRvIG1pc2ludGVycHJldCB0aGlzIGNoYXJhY3Rlcg0KPiA+ICAgaW4gcHJvZ3JhbW1pbmcgbGFu Z3VhZ2VzIHRoYXQgdXNlIE5VTCB0byBtYXJrIHRoZSBlbmQgb2YgYSBzdHJpbmcuDQogDQo+IElu IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPw0KDQpZZXMuIFRyZWF0aW5nIE5VTCBhcyBlbmQtb2Yt c3RyaW5nIGlzIG1vcmUgb2YgYSBzZWN1cml0eSBpc3N1ZSB0aGFuIG5vdCBiZWluZyBhYmxlIHJl cHJlc2VudCBzb21lIGNoYXJhY3RlcnMuDQoNCkJhZCBndXlzIHN0dWNrIE5VTHMgaW4gZG9tYWlu IG5hbWUgZmllbGRzIGluIGNlcnRpZmljYXRlcyAoZWcgcGF5cGFsLmNvbTxOVUw+d3d3LmJhZGd1 eS5uZXQpLiBPbmUgcGFydHkgdHJlYXRzIGl0IGFzIGEgKGhhcm1sZXNzKSBzdWJkb21haW4gb2Yg YmFkZ3V5Lm5ldDsgYW5vdGhlciBwYXJ0eSBpcyBmb29sZWQgaW50byBiZWxpZXZpbmcgaXQgaXMg Zm9yIHBheXBhbC5jb20uIFJlc3VsdDogc2VjdXJpdHkgZmFpbHVyZS4NCg0KQ29uc2lkZXIgdGhl IHBvaW50ZXIgIi9yZWFkb25seVx1MDAwMGFiYyIgaW4gYSBwYXRjaCB7Im9wIjoicmVtb3ZlIiwg InBhdGgiOiIvcmVhZG9ubHlcdTAwMDBhYmMifSBhcHBsaWVkIHRvIGEgZG9jIHsicmVhZG9ubHki OiJNVVNUIE5PVCBCRSBUT1VDSEVEIiwgImFueW9uZSI6ImNhbiBjaGFuZ2UgYW55dGhpbmcgZWxz ZSJ9LiBBIHNlY3VyaXR5IGxheWVyIHRoYXQgcHJvcGVybHkgaGFuZGxlcyBOVUwgd2lsbCBhbGxv dyB0aGUgcGF0Y2ggdGhyb3VnaDsgYnV0IGEgc3Vic2VxdWVudCBwcm9jZXNzb3IgdGhhdCBpc24n dCBjYXJlZnVsIGFib3V0IE5VTCBtaWdodCB0cmVhdCB0aGUgcG9pbnRlciBhcyAiL3JlYWRvbmx5 IiBhbmQgZGlzYXN0ZXIgcmVzdWx0cy4NCg0KDQpBYm91dCB0aGUgb25seSBvdGhlciBzZWN1cml0 eSBjb25zaWRlcmF0aW9uIEkgY2FuIHRoaW5rIG9mIGlzIGNoZWNraW5nIHRoYXQgYW4gYXJyYXkg aW5kZXggZG9lcyBub3Qgb3ZlcmZsb3cgYSBwcm9ncmFtcyByZXByZXNlbnRhdGlvbiAoZWcgZG9u 4oCZdCB0cmVhdCAiLzQyOTQ5NjcyOTciIGFzICIvMSIsIHRocm93IGFuIGVycm9yIGlmIG5lY2Vz c2FyeSkuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From duerst@it.aoyama.ac.jp Thu Nov 15 21:02: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 1F83C21E8043 for ; Thu, 15 Nov 2012 21:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 mfOShObQhepI for ; Thu, 15 Nov 2012 21:02:43 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id A734621E802E for ; Thu, 15 Nov 2012 21:02:42 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id qAG52WBs004198 for ; Fri, 16 Nov 2012 14:02:32 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 208d_9042_d409cf76_2faa_11e2_9b5a_001d096c5782; Fri, 16 Nov 2012 14:02:32 +0900 Received: from [IPv6:::1] ([133.2.210.1]:41003) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 16 Nov 2012 14:02:34 +0900 Message-ID: <50A5C8E0.6010704@it.aoyama.ac.jp> Date: Fri, 16 Nov 2012 14:02:24 +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: Tim Bray References: <1969645725.20121101120100@w3.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Lilley , IETF Apps Discuss , eb2m-mrt@asahi-net.or.jp Subject: Re: [apps-discuss] FW: New Version Notification for draft-lilley-xml-mediatypes-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, 16 Nov 2012 05:02:44 -0000 I agree with APPSAWG taking it up. 3023 is really outdated, and needs to be fixed. Regards, Martin. On 2012/11/15 23:41, Tim Bray wrote: > I would support APPSAWG taking it up. 3023 is so horribly wrong, it would > be good to have a sane replacement. -T > > On Thu, Nov 15, 2012 at 3:36 PM, Murray S. Kucherawywrote: > >> So far there's been only one expression of support for processing this >> through appsawg. Are there any others? Any objections to processing it >> here? Other suggestions? >> >> -MSK, co-chair >> >> >> On Thu, Nov 1, 2012 at 4:01 AM, Chris Lilley wrote: >> >>> Hello apps-discuss, >>> >>> draft-lilley-xml-mediatypes-00.txt is a restart of a proposed replacement >>> for RFC3023. The previous attempt foundered because the approach taken >>> required deprecation of text/xml, and the implementor community was not >>> happy with that as there is much legacy content using that type that still >>> has to be supported. >>> >>> The present draft takes advantage of recent changes in HTTP-bis which >>> removes the default charset, and so treats text/xml the same as >>> application/xml. This approach is also what most implementations already >>> do, in practice. The present draft also introduces some clarifications on >>> fragment identifiers for xml, and updates some references. >>> >>> It has been suggested that this document would be a good fit for the apps >>> area WG, and the editors would like to request review and adoption by the >>> WG (or an alternative suggestion of where/how to handle this document). >>> >>> This would be a standards-track document. >>> >>> -- >>> Chris Lilley Technical Director, Interaction Domain >>> W3C Graphics Activity Lead, Fonts Activity Lead >>> Co-Chair, W3C Hypertext CG >>> Member, CSS, WebFonts, SVG Working Groups >>> _______________________________________________ >>> 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 James.H.Manger@team.telstra.com Thu Nov 15 21:14: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 7EBD921E8043 for ; Thu, 15 Nov 2012 21:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.762 X-Spam-Level: X-Spam-Status: No, score=-0.762 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 lKTHjBOIiwMZ for ; Thu, 15 Nov 2012 21:14:09 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id B695321E8039 for ; Thu, 15 Nov 2012 21:14:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,261,1352034000"; d="scan'208";a="101977768" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 16 Nov 2012 16:13:55 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="47608970" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcani.tcif.telstra.com.au with ESMTP; 16 Nov 2012 16:13:55 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Fri, 16 Nov 2012 16:13:54 +1100 From: "Manger, James H" To: Mark Nottingham , "apps-discuss@ietf.org" Date: Fri, 16 Nov 2012 16:13:54 +1100 Thread-Topic: [apps-discuss] Appsdir review of draft-ietf-appsawg-json-patch-06 Thread-Index: Ac3DiG1kF/NzxO6RTKuvCIJWJTEgUwAKN5BA Message-ID: <255B9BB34FB7D647A506DC292726F6E115006C7C4E@WSMSG3153V.srv.dir.telstra.com> References: <6.2.5.6.2.20121115152250.09ffa450@elandnews.com> In-Reply-To: <6.2.5.6.2.20121115152250.09ffa450@elandnews.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] Appsdir review of draft-ietf-appsawg-json-patch-06 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, 16 Nov 2012 05:14:09 -0000 PiAgPiA0LjQgR2l2ZW4gdGhlIHJlYWwgY29tcGxleGl0eSBvZiBib3RoICdyZW1vdmUnIGFuZCAn YWRkJywgJ21vdmUnDQo+ICA+ICAgIHJlYWxseSBzaG91bGQgYmUgZGVmaW5lZCBieSByZWZlcmVu Y2UgdG8gdGhvc2Ugb3BlcmF0aW9ucywgcmF0aGVyDQo+ICA+ICAgIHRoYW4gcmVwZWF0aW5nIChp bXBlcmZlY3RseSBhdCB0aGUgbW9tZW50KSB0aGVpciBkZWZpbml0aW9ucy4NCj4gID4gICAgVGhp cyB3b3VsZCBoYXZlIHRoZSBhZGRpdGlvbmFsIGJlbmVmaXQgb2YgcmVtb3ZpbmcgdGhlIG5lY2Vz c2l0eQ0KPiAgPiAgICBmb3IgdGhlIHNpZGUgY29uZGl0aW9ucywgYWxsIG9mIHdoaWNoIHdpbGwg bm93IGZvbGxvdyBmcm9tIHRoZQ0KPiAgPiAgICBkZWZpbml0aW9ucyBvZiAncmVtb3ZlJyBhbmQg J2FkZCcgKGV4Y2VwdCB0aGUgaW52YWxpZGl0eSBvZg0KPiAgPiAgICByZXBsYWNpbmcgdGhlIHJv b3QsIHdoaWNoIHNob3VsZCBhcyBmYXIgYXMgSSBjYW4gc2VlIGJlIGFsbG93ZWQgLQ0KPiAgPiAg ICB7ICJvcCI6ICJtb3ZlIiwgInBhdGgiOiAiL2EvYiIsICJ0byI6ICIiIH0gc2VlbXMgcGVyZmVj dGx5DQo+ICA+ICAgIHJlYXNvbmFibGUgdG8gbWUpLg0KPiANCj4gVG8gZG8gdGhhdCwgSSB0aGlu ayB3ZSdkIG5lZWQgdG8gY2hhbmdlICJ0byIgdG8gImZyb20iLCBhcyB0aGUNCj4gc2VtYW50aWNz IG9mICJwYXRoIiBhcmUgc28gZGlmZmVyZW50Lg0KPiANCj4gSSdtIG5vdCBhdmVyc2UgdG8gZG9p bmcgc28sIGFzIGxvbmcgYXMgd2UgY2FuIGdldCB0byBhZ3JlZW1lbnQgYWJvdXQgaXQNCj4gcXVp Y2tseS4gQW55b25lIG9iamVjdD8NCg0KU291bmRzIG9rLg0KDQo+ICA+IDQuNSBBZ2FpbiwgYWx0 aG91Z2ggdGhlIGZpcnN0IHNpZGUgY29uZGl0aW9uIHdvdWxkIGhhdmUgdG8gcmVtYWluLA0KPiA+ IHRoaXMgc2hvdWxkIGJlIGRlZmluZWQgYnkgcmVmZXJlbmNlIHRvICdhZGQnLiAgU2VlIGJlbG93 IHVuZGVyIE1pbm9yDQo+ID4gSXNzdWVzIHdydCB0aGUgc2Vjb25kIHNpZGUgY29uZGl0aW9uDQo+ IA0KPiBUbyBkbyB0aGF0LCBJIHRoaW5rIHdlJ2QgbmVlZCB0byBjaGFuZ2UgInRvIiB0byAiZnJv bSIsIGFzIHRoZQ0KPiBzZW1hbnRpY3Mgb2YgInBhdGgiIGFyZSBzbyBkaWZmZXJlbnQuDQo+IA0K PiBJJ20gbm90IGF2ZXJzZSB0byBkb2luZyBzbywgYXMgbG9uZyBhcyB3ZSBjYW4gZ2V0IHRvIGFn cmVlbWVudCBhYm91dCBpdA0KPiBxdWlja2x5LiBBbnlvbmUgb2JqZWN0Pw0KDQpTb3VuZHMgb2su DQoNCj4gID4gNC41IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcmVhc29uIGZvciBiYXJyaW5nIGNv cHlpbmcgdG8gYW4gZXhpc3RpbmcNCj4gID4gICAgbWVtYmVyLiAgVGhlIHJlc3Qgb2YgdGhlIHNw ZWMuIHNlZW1zIGNvbnRlbnQgdG8gYWxsb3cgbXVsdGlwbGUNCj4gID4gICAgaWRlbnRpY2FsbHkt bmFtZWQgbWVtYmVycyB0byBiZSBzcGVjaWZpZWQuIC4gLiAgWW91IHdvdWxkLCBJDQo+ICA+ICAg IGd1ZXNzLCBuZWVkIHRvIHNheSB0aGF0IHdoZXJlIGl0IGdvZXMsIGJ1dCBpZiB5b3UgZGVmaW5l ZCBieQ0KPiAgPiAgICByZWZlcmVuY2UgdG8gImFkZCIgYXMgSSd2ZSBnaXZlbiBpdCBhYm92ZSwg dGhhdCB3b3VsZCBiZSB0YWtlbg0KPiAgPiAgICBjYXJlIG9mLg0KPiANCj4gV2UgdG9vayBzaW1p bGFyIGxhbmd1YWdlIG91dCBvZiBhZGQgKHNlZSB0aHJlYWQgJ2pzb24tcGF0Y2g6ICJvcCI6DQo+ ICJpbnNlcnQiIGFuZCAib3AiOiAicHV0IicpLiBJIHRoaW5rIGl0J3MgcmVhc29uYWJseSB0byB0 YWtlIGl0IG91dCBvZg0KPiBjb3B5IGFzIHdlbGwgLS0gb3RoZXJzPw0KDQpJIGFncmVlLCBsZXQg Y29weSByZXBsYWNlIGFuIGV4aXN0aW5nIHRhcmdldC4NCg0KQW4gZXhhbXBsZSBzaG93aW5nIGFu IGFkZCwgbW92ZSwgb3IgY29weSByZXBsYWNpbmcgYW4gZXhpc3RpbmcgdmFsdWUgd291bGQgaGVs cC4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From duerst@it.aoyama.ac.jp Thu Nov 15 21:19: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 C263721E8043 for ; Thu, 15 Nov 2012 21:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.637 X-Spam-Level: X-Spam-Status: No, score=-100.637 tagged_above=-999 required=5 tests=[AWL=-0.847, 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 UuRh+kBrVTZp for ; Thu, 15 Nov 2012 21:19:45 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2101F21E802E for ; Thu, 15 Nov 2012 21:19:44 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id qAG5JX91017406 for ; Fri, 16 Nov 2012 14:19:35 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 42fa_7332_34fcff2c_2fad_11e2_9855_001d096c566a; Fri, 16 Nov 2012 14:19:33 +0900 Received: from [IPv6:::1] ([133.2.210.1]:59669) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 16 Nov 2012 14:19:36 +0900 Message-ID: <50A5CCDE.6090905@it.aoyama.ac.jp> Date: Fri, 16 Nov 2012 14:19:26 +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: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-json-pointer 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, 16 Nov 2012 05:19:45 -0000 On 2012/11/16 0:24, Paul Hoffman wrote: > - One of the security considerations is too limited. > Note that JSON pointers can contain the NUL (Unicode U+0000) > character, which may not be representable in all programming > languages. > The same is true for all control characters, and for some programming languages, all non-ASCII characters. Proposed rewording: > Note that JSON pointers can contain the NUL (Unicode U+0000) > character, control characters, non-ASCII characters, and so > on. These characters may not be representable in all programming > languages. I have to disagree here. There may indeed be programming languages that cannot handle non-ASCII characters. But these days, this means that they are very much fringe languages. On the other hand, there are also programming languages, or implementations of programming languages, that cannot handle ASCII (think EBCDIC machines). The original warning, although it doesn't say so explicitly, is more or less specifically about string representation in C. C is an extremely widely used programming language, and its usual string representation takes the null byte to signal the end of a string. So the warning essentially just reads: If you language happens to use a null byte to signal the end of a string (e.g. like in C) then you may have to be careful and invest additional effort (e.g. use a string library that handles null bytes, too). Same applies to wide strings and null 16-bit or 32-bit units. So I don't think it's a good idea to widen this warning. Regards, Martin. From mnot@mnot.net Thu Nov 15 22:12: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 0CA1321F888D for ; Thu, 15 Nov 2012 22:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.67 X-Spam-Level: X-Spam-Status: No, score=-104.67 tagged_above=-999 required=5 tests=[AWL=-2.071, 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 fdArf0CjrhOV for ; Thu, 15 Nov 2012 22:12:29 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 59CA021F8891 for ; Thu, 15 Nov 2012 22:12:17 -0800 (PST) Received: from [192.168.1.64] (unknown [118.209.81.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 02F6C509B5; Fri, 16 Nov 2012 01:12:14 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115006C7BCF@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 16 Nov 2012 17:12:13 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <255B9BB34FB7D647A506DC292726F6E115006C7A5C@WSMSG3153V.srv.dir.telstra.com> <45B7BA35-8717-4597-902B-168E7B894A68@mnot.net> <255B9BB34FB7D647A506DC292726F6E115006C7BCF@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1499) Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-json-pointer 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, 16 Nov 2012 06:12:30 -0000 In SVN. On 16/11/2012, at 3:50 PM, "Manger, James H" = wrote: >>> The issue with NUL is that you need to be careful not to = misinterpret >> it as an end-of-string marker. How about: >>>=20 >>> Note that JSON pointers can contain the NUL (Unicode U+0000) >>> character. Care is needed not to misinterpret this character >>> in programming languages that use NUL to mark the end of a string. >=20 >> In Security Considerations? >=20 > Yes. Treating NUL as end-of-string is more of a security issue than = not being able represent some characters. >=20 > Bad guys stuck NULs in domain name fields in certificates (eg = paypal.comwww.badguy.net). One party treats it as a (harmless) = subdomain of badguy.net; another party is fooled into believing it is = for paypal.com. Result: security failure. >=20 > Consider the pointer "/readonly\u0000abc" in a patch {"op":"remove", = "path":"/readonly\u0000abc"} applied to a doc {"readonly":"MUST NOT BE = TOUCHED", "anyone":"can change anything else"}. A security layer that = properly handles NUL will allow the patch through; but a subsequent = processor that isn't careful about NUL might treat the pointer as = "/readonly" and disaster results. >=20 >=20 > About the only other security consideration I can think of is checking = that an array index does not overflow a programs representation (eg = don=92t treat "/4294967297" as "/1", throw an error if necessary). >=20 > -- > James Manger -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Thu Nov 15 23:06: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 C1D5E21F877C for ; Thu, 15 Nov 2012 23:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.612 X-Spam-Level: X-Spam-Status: No, score=-104.612 tagged_above=-999 required=5 tests=[AWL=-2.013, 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 7NxWUdkdOhWU for ; Thu, 15 Nov 2012 23:06:15 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 81E7A21F843B for ; Thu, 15 Nov 2012 23:06:15 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.81.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A7218509B9 for ; Fri, 16 Nov 2012 02:06:13 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <6.2.5.6.2.20121115152250.09ffa450@elandnews.com> Date: Fri, 16 Nov 2012 18:06:12 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20121115152250.09ffa450@elandnews.com> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1499) Subject: Re: [apps-discuss] Appsdir review of draft-ietf-appsawg-json-patch-06 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, 16 Nov 2012 07:06:16 -0000 On 16/11/2012, at 10:23 AM, Mark Nottingham (by way of S Moonesamy = ) wrote: > Hi Henry, >=20 > Thanks for the review. Responses below. >=20 > On 16/11/2012, at 4:06 AM, Henry S. Thompson wrote: >=20 > > I have been selected as the Applications Area Directorate reviewer = for > > this draft (for background on appsdir, please see > > = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)= . > > > > Please resolve these comments along with any other Last Call = comments > > you may receive. Please wait for direction from your document = shepherd > > or AD before posting a new version of the draft. > > > > Document: draft-ietf-appsawg-json-patch-06 > > Title: JSON Patch > > Reviewer: Henry S. Thompson > > Review Date: 15 November 2012 > > IETF Last Call Date: 2012-11-23 > > > > Summary: This draft is almost ready for publication as an Proposed > > Standard but has a related set of issues that should be = fixed > > before publication > > > > Note that I have not read previous drafts of or comments on this > > document -- I presume I was asked to review as a fresh pair of eyes. > > If the result is to repeat some previously-expressed comments, so be > > it. > > > > Major Issues: > > > > 4.1 This operation ('add') seems underspecified in several respects. > > > > 1) I would have expected a short statement of the actual effect > > under each bullet, e.g. "The specified value becomes the entire > > contents of the document"; >=20 > I'll add these. In SVN. > > 2) I would have expected error conditions to be specified under = each > > bullet. I assume it is an error for "path" to be empty and the > > document to have content. The discussion of index errors wrt > > arrays could/should move, and the "common use" 'note', which > > isn't a note at all, should be specific to objects. >=20 > I'll look at reorganising these (is this really a *major* issue?). In SVN >=20 > > 3) I take it you also need to say that if an _existing_ member of = an > > object is referenced, that's not an error (note that it _is_ a > > JSON Pointer error), and the result is to increase the number of > > such members by one, with the new value. >=20 > I think that'll be the outcome of #1 above, yes. Sorry, replay that? If an existing member of an object is referenced, = that member will be replaced... > > I think in fact you might be better off to handle this by cases and > > avoid all 'intentional' JSON Pointer errors, along the lines of > > > > a) If the "path" is "" and the document is empty then the "value" > > becomes the document; > > > > b) If the path excluding its last step identifies an object, then > > "value" is added at the end of that object, with the name given = by > > the decoded reference token of the last step; > > > > c) If the path excluding its last step identifies an array then > > > > i) If the last step's reference token encodes an integer i with > > 0 <=3D i < |array|, then . . . > > ii) If the last step's reference token is '-' or encodes > > |array|, then . . . > > > > Otherwise, the operation raises an error. >=20 > The "excluding its last step" is awkward. The error conditions in json = pointer were put there for exactly this kind of use; is it the word = 'error' that's causing you concern? >=20 > > 4.2, 4.3 Nothing is said about the case where a path which = identifies a > > multiply-valued object member is given, which per JSON Pointer = is > > a pointer error. >=20 > To be clear - are you saying that we should handle the case where an = error in the underlying JSON bubbles up through JSON Pointer? E.g., >=20 > { "foo": "bar", "foo": "baz" } >=20 > ? >=20 > > 4.4 Given the real complexity of both 'remove' and 'add', 'move' > > really should be defined by reference to those operations, rather > > than repeating (imperfectly at the moment) their definitions. > > This would have the additional benefit of removing the necessity > > for the side conditions, all of which will now follow from the > > definitions of 'remove' and 'add' (except the invalidity of > > replacing the root, which should as far as I can see be allowed - > > { "op": "move", "path": "/a/b", "to": "" } seems perfectly > > reasonable to me). >=20 > To do that, I think we'd need to change "to" to "from", as the = semantics of "path" are so different. >=20 > I'm not averse to doing so, as long as we can get to agreement about = it quickly. Anyone object? In SVN >=20 > > 4.5 Again, although the first side condition would have to remain, > > this should be defined by reference to 'add'. See below under Minor > > Issues wrt the second side condition >=20 > To do that, I think we'd need to change "to" to "from", as the = semantics of "path" are so different. >=20 > I'm not averse to doing so, as long as we can get to agreement about = it quickly. Anyone object? In SVN >=20 > > Minor Issues: > > > > 1. This is perfectly clear, but I still missed it: This spec. (and > > JSON Pointer) are about _documents_ and not Javascript objects. > > It's very easy to slip into thinking about objects, and indeed the > > spec. itself talks about the target as if it consisted of objects > > and arrays! It would of course be obnoxious to require you to say > > "JSON encoding of an object" every time, instead of just "object", > > but I wonder if it wouldn't be a good idea to say, here in the > > introduction, precisely that -- that you will (mostly) talk about > > the target as if it had a root, consisted of arrays and objects > > with members and values, etc., but what you will always _mean_ is > > being pointed to, tested, changed, etc. is the _JSON encoding_ of > > those things. >=20 > It *can* be about JavaScript objects; that was a use case for some = people, resulting in a bit of the dancing that we do. >=20 > > 3. In a similar vein, wrt the patch document itself, I think it = would > > be better to say e.g. "A JSON Patch document is a JSON [RFC4627] > > document which [represents/encodes/whatever] an array of objects." >=20 > OK. In SVN > > 4.5 I don't understand the reason for barring copying to an existing > > member. The rest of the spec. seems content to allow multiple > > identically-named members to be specified. . . You would, I > > guess, need to say that where it goes, but if you defined by > > reference to "add" as I've given it above, that would be taken > > care of. >=20 > We took similar language out of add (see thread 'json-patch: "op": = "insert" and "op": "put"'). I think it's reasonably to take it out of = copy as well -- others? In SVN >=20 > > 4.6 When you get to string-string equality the object / encoding > > duality discussed above at 1. becomes a problem -- you have > > treated the patch as an object up until now, in which case any > > escaping will already have been dealt with. If one took the = words > > in this case literally, the following test would succeed: > > > > Target { "a":"\b" } > > > > Patch [ { "op": "test", "path": "/a", "value":"\\b" } ] > > > > which is presumably not what you meant. It's clear from the > > wording you've used in this case that you _meant_ to refer here > > (and only here) to the _encoding_ of the value of the "value" > > property of the patch, not its value. Phew! >=20 > I think we can address this by making it clear that all of the = operations are specified in term of JSON primitives (i.e., after = escaping), but examples are JSON documents, and giving a few more = examples to illustrate the corner cases. Make sense? >=20 >=20 > Cheers, >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 > _______________________________________________ > appsdir mailing list > appsdir@ietf.org > https://www.ietf.org/mailman/listinfo/appsdir >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From superuser@gmail.com Thu Nov 15 23:35:55 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 384F621F8577 for ; Thu, 15 Nov 2012 23:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 EOzXbCaEqUdo for ; Thu, 15 Nov 2012 23:35:54 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0B30E21F856E for ; Thu, 15 Nov 2012 23:35:53 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2056445lbk.31 for ; Thu, 15 Nov 2012 23:35:52 -0800 (PST) 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=7PVEwMzTNFafpp7PPyD0rRO/2xqqXASXyaMsKjy6ISY=; b=Eq5bdo4Q8Ts6XxlKn5ZcHbp0k0k+5pxsDqqSor8bmhO8Hb1VbKBbMMpTFHbzGINqev H/iFC9QQVl5AXfrHNUVl7n/Y0HvihfyOlWbYi+xsyUis+H6el7zAEJ9W0EGLSb0AaSNJ XX65M2MnugHpwE2Ty7RqzEybFM8oDijRyK4JZF4CbiUyKpPoMsrT41xCp+fpJiJ4gefU A1hnBaApsoYCN/fYfMRN4FdRMvFNZwfk0BdZSWcEeqD52Zr4cpBZQ7607uawSxB8zGkw +HbyvUFwQ8FELBmUIWJyNcPhBx6Jf67di9mMKIhN0uuN885L5JgTksWz5Tjm4Pfy1tHG hu5w== MIME-Version: 1.0 Received: by 10.112.99.8 with SMTP id em8mr1613073lbb.13.1353051352645; Thu, 15 Nov 2012 23:35:52 -0800 (PST) Received: by 10.112.80.234 with HTTP; Thu, 15 Nov 2012 23:35:52 -0800 (PST) In-Reply-To: <50A5C8E0.6010704@it.aoyama.ac.jp> References: <1969645725.20121101120100@w3.org> <50A5C8E0.6010704@it.aoyama.ac.jp> Date: Thu, 15 Nov 2012 23:35:52 -0800 Message-ID: From: "Murray S. Kucherawy" To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: multipart/alternative; boundary=f46d040173113cc1c004ce97d1e3 Cc: Chris Lilley , IETF Apps Discuss , eb2m-mrt@asahi-net.or.jp Subject: Re: [apps-discuss] FW: New Version Notification for draft-lilley-xml-mediatypes-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, 16 Nov 2012 07:35:55 -0000 --f46d040173113cc1c004ce97d1e3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Are the people agreeing that it should be processed in appsawg (Julian, Martin, Tony, and Tim so far; hopefully others) committing to doing reviews if we adopt this document? SM has already said he will. -MSK On Thu, Nov 15, 2012 at 9:02 PM, "Martin J. D=FCrst" wrote: > I agree with APPSAWG taking it up. 3023 is really outdated, and needs to > be fixed. > > Regards, Martin. > > > On 2012/11/15 23:41, Tim Bray wrote: > >> I would support APPSAWG taking it up. 3023 is so horribly wrong, it wou= ld >> be good to have a sane replacement. -T >> >> On Thu, Nov 15, 2012 at 3:36 PM, Murray S. Kucherawy >> **wrote: >> >> So far there's been only one expression of support for processing this >>> through appsawg. Are there any others? Any objections to processing i= t >>> here? Other suggestions? >>> >>> -MSK, co-chair >>> >>> >>> On Thu, Nov 1, 2012 at 4:01 AM, Chris Lilley wrote: >>> >>> Hello apps-discuss, >>>> >>>> draft-lilley-xml-mediatypes-**00.txt is a restart of a proposed >>>> replacement >>>> for RFC3023. The previous attempt foundered because the approach taken >>>> required deprecation of text/xml, and the implementor community was no= t >>>> happy with that as there is much legacy content using that type that >>>> still >>>> has to be supported. >>>> >>>> The present draft takes advantage of recent changes in HTTP-bis which >>>> removes the default charset, and so treats text/xml the same as >>>> application/xml. This approach is also what most implementations alrea= dy >>>> do, in practice. The present draft also introduces some clarifications >>>> on >>>> fragment identifiers for xml, and updates some references. >>>> >>>> It has been suggested that this document would be a good fit for the >>>> apps >>>> area WG, and the editors would like to request review and adoption by >>>> the >>>> WG (or an alternative suggestion of where/how to handle this document)= . >>>> >>>> This would be a standards-track document. >>>> >>>> -- >>>> Chris Lilley Technical Director, Interaction Domain >>>> W3C Graphics Activity Lead, Fonts Activity Lead >>>> Co-Chair, W3C Hypertext CG >>>> Member, CSS, WebFonts, SVG Working Groups >>>> ______________________________**_________________ >>>> 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 >> > --f46d040173113cc1c004ce97d1e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Are the people agreeing that it should be processed in appsawg (Julian, Mar= tin, Tony, and Tim so far; hopefully others) committing to doing reviews if= we adopt this document?=A0 SM has already said he will.

-MSK


On Thu, Nov 15, 2012 at 9:02 PM, "M= artin J. D=FCrst" <duerst@it.aoyama.ac.jp> wrote:<= br>
I agree with APPSAWG taking it up. 3023 is really outdated, and needs to be= fixed.

Regards, =A0 Martin.


On 2012/11/15 23:41, Tim Bray wrote:
I would support APPSAWG taking it up. =A03023 is so horribly wrong, it woul= d
be good to have a sane replacement. -T

On Thu, Nov 15, 2012 at 3:36 PM, Murray S. Kucherawy<superuser@gmail.com>wro= te:

So far there's been only one expression of support for processing this<= br> through appsawg. =A0Are there any others? =A0Any objections to processing i= t
here? =A0Other suggestions?

-MSK, co-chair


On Thu, Nov 1, 2012 at 4:01 AM, Chris Lilley<chris@w3.org> =A0wrote:

Hello apps-discuss,

draft-lilley-xml-mediatypes-00.txt is a restart of a proposed replac= ement
for RFC3023. The previous attempt foundered because the approach taken
required deprecation of text/xml, and the implementor community was not
happy with that as there is much legacy content using that type that still<= br> has to be supported.

The present draft takes advantage of recent changes in HTTP-bis which
removes the default charset, and so treats text/xml the same as
application/xml. This approach is also what most implementations already do, in practice. The present draft also introduces some clarifications on fragment identifiers for xml, and updates some references.

It has been suggested that this document would be a good fit for the apps area WG, and the editors would like to request review and adoption by the WG (or an alternative suggestion of where/how to handle this document).

This would be a standards-track document.

--
=A0 Chris Lilley =A0 Technical Director, Interaction Domain
=A0 W3C Graphics Activity Lead, Fonts Activity Lead
=A0 Co-Chair, W3C Hypertext CG
=A0 Member, CSS, WebFonts, SVG Working Groups
_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



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





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

--f46d040173113cc1c004ce97d1e3-- From duerst@it.aoyama.ac.jp Thu Nov 15 23:52: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 76AA721F87E4 for ; Thu, 15 Nov 2012 23:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=1.242, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 ljbT1bm+LWrO for ; Thu, 15 Nov 2012 23:52:44 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 55CA921F87E1 for ; Thu, 15 Nov 2012 23:52:44 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id qAG7qWgi005503 for ; Fri, 16 Nov 2012 16:52:32 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 208d_bd40_93fbc6c4_2fc2_11e2_9b5a_001d096c5782; Fri, 16 Nov 2012 16:52:32 +0900 Received: from [IPv6:::1] ([133.2.210.1]:32910) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 16 Nov 2012 16:52:34 +0900 Message-ID: <50A5F0B8.2080400@it.aoyama.ac.jp> Date: Fri, 16 Nov 2012 16:52:24 +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: "Murray S. Kucherawy" References: <1969645725.20121101120100@w3.org> <50A5C8E0.6010704@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Chris Lilley , IETF Apps Discuss , eb2m-mrt@asahi-net.or.jp Subject: Re: [apps-discuss] FW: New Version Notification for draft-lilley-xml-mediatypes-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, 16 Nov 2012 07:52:45 -0000 Yes, I volunteer to review the document. Regards, Martin. On 2012/11/16 16:35, Murray S. Kucherawy wrote: > Are the people agreeing that it should be processed in appsawg (Julian, > Martin, Tony, and Tim so far; hopefully others) committing to doing reviews > if we adopt this document? SM has already said he will. > > -MSK > > > On Thu, Nov 15, 2012 at 9:02 PM, "Martin J. Dürst" > wrote: > >> I agree with APPSAWG taking it up. 3023 is really outdated, and needs to >> be fixed. >> >> Regards, Martin. >> >> >> On 2012/11/15 23:41, Tim Bray wrote: >> >>> I would support APPSAWG taking it up. 3023 is so horribly wrong, it would >>> be good to have a sane replacement. -T >>> >>> On Thu, Nov 15, 2012 at 3:36 PM, Murray S. Kucherawy >>> **wrote: >>> >>> So far there's been only one expression of support for processing this >>>> through appsawg. Are there any others? Any objections to processing it >>>> here? Other suggestions? >>>> >>>> -MSK, co-chair >>>> >>>> >>>> On Thu, Nov 1, 2012 at 4:01 AM, Chris Lilley wrote: >>>> >>>> Hello apps-discuss, >>>>> >>>>> draft-lilley-xml-mediatypes-**00.txt is a restart of a proposed >>>>> replacement >>>>> for RFC3023. The previous attempt foundered because the approach taken >>>>> required deprecation of text/xml, and the implementor community was not >>>>> happy with that as there is much legacy content using that type that >>>>> still >>>>> has to be supported. >>>>> >>>>> The present draft takes advantage of recent changes in HTTP-bis which >>>>> removes the default charset, and so treats text/xml the same as >>>>> application/xml. This approach is also what most implementations already >>>>> do, in practice. The present draft also introduces some clarifications >>>>> on >>>>> fragment identifiers for xml, and updates some references. >>>>> >>>>> It has been suggested that this document would be a good fit for the >>>>> apps >>>>> area WG, and the editors would like to request review and adoption by >>>>> the >>>>> WG (or an alternative suggestion of where/how to handle this document). >>>>> >>>>> This would be a standards-track document. >>>>> >>>>> -- >>>>> Chris Lilley Technical Director, Interaction Domain >>>>> W3C Graphics Activity Lead, Fonts Activity Lead >>>>> Co-Chair, W3C Hypertext CG >>>>> Member, CSS, WebFonts, SVG Working Groups >>>>> ______________________________**_________________ >>>>> 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 mnot@mnot.net Fri Nov 16 00:32: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 E182321F8675 for ; Fri, 16 Nov 2012 00:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.558 X-Spam-Level: X-Spam-Status: No, score=-104.558 tagged_above=-999 required=5 tests=[AWL=-1.959, 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 gc-ZyLIAHixU for ; Fri, 16 Nov 2012 00:32:29 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id E620D21F8668 for ; Fri, 16 Nov 2012 00:32:28 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.81.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 50216509B7; Fri, 16 Nov 2012 03:32:26 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> Date: Fri, 16 Nov 2012 19:32:30 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5875BD50-6C2D-43C2-8207-F0300F470266@mnot.net> References: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> To: Cyrus Daboo X-Mailer: Apple Mail (2.1499) Cc: Apps Discuss Subject: Re: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 16 Nov 2012 08:32:30 -0000 On 16/11/2012, at 10:35 AM, Mark Nottingham wrote: > Hi Cyrus, >=20 > Thanks for the review. >=20 >=20 > On 16/11/2012, at 2:57 AM, Cyrus Daboo wrote: >=20 >> Hi, >> Here are my review comments (mostly nits - nothing major): >>=20 >> =A71: Introduction focusses on the use of JSON patch in HTTP PATCH, = but of course it could be used anywhere else a "patch" operation is = needed (other protocols". It might be worth adding some text explaining = the more "generic" use case. e.g.: >>=20 >> This format is also applicable to any protocol that might want to >> process partial updates to a JSON document. >=20 > Will do. In SVN > =A74.1 talks about the "-" value for arrays, but that value is also = applicable to "move" and "copy". Should that statement also appear in = =A74.4 and =A74.5 or be moved to a more "generic" location - e.g. in the = main text of =A74? >=20 > Will have a look. Move and Copy are now defined in terms of add, so I think this is dealt = with. >> =A74.6 uses a very basic octet/code-point comparator. Do we care = about possible unicode normalizations issues? If so that will need to be = dealt with, if not there ought to be a clarifying statement - in fact an = "Internationalization Considerations" section may be warranted. >=20 > Urgh.=20 >=20 >=20 >> =A74.6 numbers - any concern about numeric precision affecting the = "subtracting one from another" behavior? >=20 > mumble. Any suggestion for a better way to specify? >=20 >=20 >> =A75 when an error occurs it would be handy to have some minimal form = of error reporting - simply the index of the operation that failed. Can = we define a JSON format for an HTTP PATCH error response? >=20 > Maybe one day... but not today :) >=20 >=20 >> =A76 XML patch uses a MIME type "patch-ops-error+xml", why is this = not "patch+json"? >=20 > I think the going answer is that this is not an effort to define a = single patch format with multiple serialisations; it's very very = specific to the JSON data model, so +json isn't warranted. >=20 >=20 >> =A7A.6 - missing comma between members "foo" and "qux" in the two = document examples. >=20 >=20 > ack In SVN -- Mark Nottingham http://www.mnot.net/ From nickshanks@gmail.com Fri Nov 16 02:01: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 6847021F856E for ; Fri, 16 Nov 2012 02:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 vYYtbUo8S2UT for ; Fri, 16 Nov 2012 02:01:11 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4DD21F8561 for ; Fri, 16 Nov 2012 02:01:11 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1677614eek.31 for ; Fri, 16 Nov 2012 02:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=pO9zjNw3xHSSwcfUnGnbS8AWPP4b6C15vb0uNXDncHg=; b=ZXazvLPw3BWQ1vTxD2jY6lcJKGb7BDY2+uqf/aEoV/FRfdMV+XAcEw07/PtGVPMW3I qn+U9OMMirJDXycryggYBjYYgigWBBc5aYiiw+Q4wk0XLBv4vGW5wqp0oi589yZkbzZK F2wgsLC2dB04p+NlSoBeU75/8LBbsa1OEQfHply2fMa5YwwXRLx5jr8igui63ZC4+qc4 hv83w4L5nIPBt9rY7JqAQ6EgjaotSe5ajTv7xgiM+TOT3A+6MbOJomLbxVlaQPtUHBRq QyNS65mnZsvazY9gSemK+uUuZj1rTjm9xNMMZOOwJciDjBOGvX6OzWrIjuEsWVS8BwdO UNBw== Received: by 10.14.199.134 with SMTP id x6mr12145033een.31.1353060070505; Fri, 16 Nov 2012 02:01:10 -0800 (PST) MIME-Version: 1.0 Sender: nickshanks@gmail.com Received: by 10.14.189.14 with HTTP; Fri, 16 Nov 2012 02:00:29 -0800 (PST) From: Nicholas Shanks Date: Fri, 16 Nov 2012 10:00:29 +0000 X-Google-Sender-Auth: 2wgMG_Zse3c25mczg6W75OOEgEg Message-ID: To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [apps-discuss] HTTP Browser Hints 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, 16 Nov 2012 10:14:46 -0000 Regarding http://tools.ietf.org/html/draft-nottingham-http-browser-hints-04 I suggest a new property: Browser Hint Name: no-referer Description: Tells the client to either not send the Referer header (true), or use its own discretion (false). Value Type: true | false Contact: Nicholas Shanks Specification: Notes: Usual behaviour when hint is not present is equivalent to a value of false. Indicates that the server does not use the Referer header for access control, session tracking, negotiation, or other activities which may vary responses for any URI in its domain, including 404 responses, feedback forms, and the like. Implies that the server is not interested in recording the referring URI for statistical analysis purposes or client fingerprinting. -- Nicholas. From ht@inf.ed.ac.uk Fri Nov 16 03:15: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 2F9FD21F8471 for ; Fri, 16 Nov 2012 03:15:04 -0800 (PST) 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 gMkSbwp71GWl for ; Fri, 16 Nov 2012 03:15:03 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id CDC0F21F846C for ; Fri, 16 Nov 2012 03:15:01 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id qAGBEnOG007729; Fri, 16 Nov 2012 11:14:54 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id qAGBEm9v011346; Fri, 16 Nov 2012 11:14:48 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id qAGBEmYk018961; Fri, 16 Nov 2012 11:14:48 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id qAGBEltw018957; Fri, 16 Nov 2012 11:14:47 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Mark Nottingham (by way of S Moonesamy ) References: <6.2.5.6.2.20121115152250.09ffa450@elandnews.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 16 Nov 2012 11:14:47 +0000 In-Reply-To: <6.2.5.6.2.20121115152250.09ffa450@elandnews.com> (Mark Nottingham's message of "Thu\, 15 Nov 2012 15\:23\:37 -0800") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Appsdir review of draft-ietf-appsawg-json-patch-06 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, 16 Nov 2012 11:15:04 -0000 mnot writes: > Thanks for the review. Responses below. [some responses here, some to a subsequent message] > On 16/11/2012, at 4:06 AM, Henry S. Thompson wrote: >> 2) I would have expected error conditions to be specified under each >> bullet. I assume it is an error for "path" to be empty and the >> document to have content. The discussion of index errors wrt >> arrays could/should move, and the "common use" 'note', which >> isn't a note at all, should be specific to objects. > > I'll look at reorganising these (is this really a *major* issue?). I swithered about this -- I agree not 'major' in the sense of "this is broken and must be fixed", but by the time I finished I thought "yes, 'major' in the sense that I'm suggesting a substantial structural change" >> 3) I take it you also need to say that if an _existing_ member of an >> object is referenced, that's not an error (note that it _is_ a >> JSON Pointer error), and the result is to increase the number of >> such members by one, with the new value. > > I think that'll be the outcome of #1 above, yes. > >> I think in fact you might be better off to handle this by cases and >> avoid all 'intentional' JSON Pointer errors, along the lines of >> >> a) If the "path" is "" and the document is empty then the "value" >> becomes the document; >> >> b) If the path excluding its last step identifies an object, >> ... > > The "excluding its last step" is awkward. The error conditions in json > pointer were put there for exactly this kind of use; is it the word > 'error' that's causing you concern? No, just that the whole architecture as it stands feels awkward, and the addition of "-" to JSON Pointer just in order to service Patch seems especially awkward. I would think the right change to Pointer would be to define, say, 'container' as the object or array identified by the pointer-less-last-step, then you can use that term in Patch. >> 4.2, 4.3 Nothing is said about the case where a path which identifies a >> multiply-valued object member is given, which per JSON Pointer is >> a pointer error. > > To be clear - are you saying that we should handle the case where an > error in the underlying JSON bubbles up through JSON Pointer? E.g., > > { "foo": "bar", "foo": "baz" } > > ? That's not a JSON error, and it's only a Javascript error in 'strict' mode, as I understand it. And 4.1 already deals with this case. >> 4.4 Given the real complexity of both 'remove' and 'add', 'move' >> really should be defined by reference to those operations, rather >> than repeating (imperfectly at the moment) their definitions. >> This would have the additional benefit of removing the necessity >> for the side conditions, all of which will now follow from the >> definitions of 'remove' and 'add' (except the invalidity of >> replacing the root, which should as far as I can see be allowed - >> { "op": "move", "path": "/a/b", "to": "" } seems perfectly >> reasonable to me). > > To do that, I think we'd need to change "to" to "from", as the > semantics of "path" are so different. Sure. >> 1. This is perfectly clear, but I still missed it: This spec. (and >> JSON Pointer) are about _documents_ and not Javascript objects. >> It's very easy to slip into thinking about objects, and indeed the >> spec. itself talks about the target as if it consisted of objects >> and arrays! It would of course be obnoxious to require you to say >> "JSON encoding of an object" every time, instead of just "object", >> but I wonder if it wouldn't be a good idea to say, here in the >> introduction, precisely that -- that you will (mostly) talk about >> the target as if it had a root, consisted of arrays and objects >> with members and values, etc., but what you will always _mean_ is >> being pointed to, tested, changed, etc. is the _JSON encoding_ of >> those things. > > It *can* be about JavaScript objects; that was a use case for some > people, resulting in a bit of the dancing that we do. I think that use needs to be called out, and the ways in which it has incompatible semantics warned about -- particularly wrt multiple members of objects with the same name: this is possible in JSON and Javascript syntax, but is incoherent in Javascript objects as such. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ht@inf.ed.ac.uk Fri Nov 16 03:23: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 055EE21F84D8 for ; Fri, 16 Nov 2012 03:23:06 -0800 (PST) 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 CCG-LmgN11xB for ; Fri, 16 Nov 2012 03:23:05 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id E6D8C21F8495 for ; Fri, 16 Nov 2012 03:23:04 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id qAGBMmn3012356; Fri, 16 Nov 2012 11:22:53 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id qAGBMmbC011585; Fri, 16 Nov 2012 11:22:48 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id qAGBMm5T019151; Fri, 16 Nov 2012 11:22:48 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id qAGBMmQb019147; Fri, 16 Nov 2012 11:22:48 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Mark Nottingham References: <6.2.5.6.2.20121115152250.09ffa450@elandnews.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 16 Nov 2012 11:22:48 +0000 In-Reply-To: (Mark Nottingham's message of "Fri\, 16 Nov 2012 18\:06\:12 +1100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Appsdir review of draft-ietf-appsawg-json-patch-06 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, 16 Nov 2012 11:23:06 -0000 Mark Nottingham writes: >> > 3) I take it you also need to say that if an _existing_ member of an >> > object is referenced, that's not an error (note that it _is_ a >> > JSON Pointer error), and the result is to increase the number of >> > such members by one, with the new value. >> >> I think that'll be the outcome of #1 above, yes. > > Sorry, replay that? If an existing member of an object is referenced, that member will be replaced... What? If 'add' adds an additional member, and 'move' is 'remove' plus 'add', then 'move' adds, not replaces. Concrete examples: Target document: [ { "key": "apples", "status": "ripe", "count": 3 }, { "key": "apples", "status": "green", "count": 10 } ] Ex 1 Patch: [ { "op": "add", "path": "/1/count", "value": 4 } ] Result: [ { "key": "apples", "status": "ripe", "count": 3, "count": 4 }, { "key": "apples", "status": "green", "count": 10 } ] Ex 2 Patch: [ { "op": "move", "from": "/2/count", "path": "/1/count" } ] Result: [ { "key": "apples", "status": "ripe", "count": 3, "count": 10 }, { "key": "apples", "status": "green" } ] Does this clarify? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ietfc@btconnect.com Fri Nov 16 06:20: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 175E521F885D for ; Fri, 16 Nov 2012 06:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.525 X-Spam-Level: X-Spam-Status: No, score=-5.525 tagged_above=-999 required=5 tests=[AWL=1.074, 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 JnSQkctEhBvu for ; Fri, 16 Nov 2012 06:20:45 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBAC21F885B for ; Fri, 16 Nov 2012 06:20:45 -0800 (PST) Received: from mail139-co9-R.bigfish.com (10.236.132.241) by CO9EHSOBE020.bigfish.com (10.236.130.83) with Microsoft SMTP Server id 14.1.225.23; Fri, 16 Nov 2012 14:20:44 +0000 Received: from mail139-co9 (localhost [127.0.0.1]) by mail139-co9-R.bigfish.com (Postfix) with ESMTP id 48BE94C0161; Fri, 16 Nov 2012 14:20:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zzbb2dI98dI9371I542M1432I1418Izz1de0h1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h5a9h668h839hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h304l1155h) Received: from mail139-co9 (localhost.localdomain [127.0.0.1]) by mail139-co9 (MessageSwitch) id 1353075643159997_25025; Fri, 16 Nov 2012 14:20:43 +0000 (UTC) Received: from CO9EHSMHS017.bigfish.com (unknown [10.236.132.250]) by mail139-co9.bigfish.com (Postfix) with ESMTP id 24186440058; Fri, 16 Nov 2012 14:20:43 +0000 (UTC) Received: from DB3PRD0710HT001.eurprd07.prod.outlook.com (157.56.253.85) by CO9EHSMHS017.bigfish.com (10.236.130.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 16 Nov 2012 14:20:41 +0000 Received: from CH1PRD0410HT003.namprd04.prod.outlook.com (157.56.244.181) by pod51017.outlook.com (10.255.75.36) with Microsoft SMTP Server (TLS) id 14.16.239.5; Fri, 16 Nov 2012 14:20:36 +0000 Message-ID: <006901cdc405$698ad840$4001a8c0@gateway.2wire.net> From: t.petch To: Peter Saint-Andre , Graham Klyne References: <5099408C.7050702@ninebynine.org> <509978D7.3090003@stpeter.im><509991D0.9000007@ninebynine.org> <5099F175.3060703@stpeter.im><509BA2F2.6000006@stpeter.im> <509CEA8B.7020507@ninebynine.org> <50A3E044.5000202@stpeter.im> Date: Fri, 16 Nov 2012 12:36:40 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.244.181] X-OriginatorOrg: btconnect.com Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 16 Nov 2012 14:20:46 -0000 ---- Original Message ----- From: "Peter Saint-Andre" To: "Graham Klyne" Cc: Sent: Wednesday, November 14, 2012 6:17 PM > On 11/9/12 4:35 AM, Graham Klyne wrote: > > On 08/11/2012 12:17, Peter Saint-Andre wrote: > As I understand it, an acct: URI is not intended to be used directly > as a way to "find out more". It's something that is passed around in > the background, not exposed to humans. It's a kind of abstract > identifier, if you will. Not sure about the abstract but identifier yes, and I think that there may be other quite different uses for it. Twice, with other, Operations protocols, I have found localpart@domain used to identify, well, an account, a person or persons accessing or using a system, sometimes with a need to know more about them, such as rights or security credentials, so a scheme with a nailed-down syntax would have been useful, as opposed to reinventing the wheel. mailto: might do but is rather 'e-mailly', as one would expect! Whether or not Webfinger would be suitable for dereferencing I do not know enough about Webfinger to say; most of the discussion here seems to be about 'Webby' type uses which might be too limiting; but even so, having a usable syntax would be a step forward. Tom Petch > > Let me posit for the purpose of debate that dereferencing an acct: > > URI is done using WebFinger. > > If that's what folks wanted all long, I wish they'd called it > webfinger: or wf:, not acct:... > From cyrus@daboo.name Fri Nov 16 07:56: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 2221B21F8521 for ; Fri, 16 Nov 2012 07:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.668 X-Spam-Level: X-Spam-Status: No, score=-101.668 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 13X85Ycgp7Rw for ; Fri, 16 Nov 2012 07:56:00 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 07F3521F8797 for ; Fri, 16 Nov 2012 07:55:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id D8259357500D; Fri, 16 Nov 2012 10:55:57 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfE5LIyFnVav; Fri, 16 Nov 2012 10:55:52 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 552A23574FFC; Fri, 16 Nov 2012 10:55:50 -0500 (EST) Date: Fri, 16 Nov 2012 10:55:48 -0500 From: Cyrus Daboo To: Mark Nottingham Message-ID: <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> In-Reply-To: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> References: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=2023 Cc: Apps Discuss Subject: Re: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 16 Nov 2012 15:56:01 -0000 Hi Mark, --On November 16, 2012 10:35:39 AM +1100 Mark Nottingham =20 wrote: >> =C2=A74.6 uses a very basic octet/code-point comparator. Do we care = about >> possible unicode normalizations issues? If so that will need to be dealt >> with, if not there ought to be a clarifying statement - in fact an >> "Internationalization Considerations" section may be warranted. > > Urgh. Advice from i18n "experts" on language would be good. My guess is it might=20 be sufficient to allow the patch-processing entity to normalize the two=20 strings being tested in some consistent manner for comparison, rather than=20 require "code point" equality. Note: I guess the JSON base spec also has a similar issue in that it talks=20 about "names within an object SHOULD be unique" and names are strings - so=20 the question of string comparison/normalization comes up there too. > >> =C2=A74.6 numbers - any concern about numeric precision affecting the >> "subtracting one from another" behavior? > > mumble. Any suggestion for a better way to specify? "numerically equal" - anyone writing actual code to implement this test=20 will use "a =3D=3D b" rather than "a - b =3D=3D 0". So how about: numbers: are considered equal if their values are numerically equal. Another point, you have this for the "string" test: strings: are considered equal if, after unescaping any sequence(s) in both strings starting with a reverse solidus, they contain the same number of Unicode characters and their code points are position-wise equal. However, I believe the value of a string is the unescaped result of=20 processing a string "representation" in the JSON document, so your text on=20 unescaping is not needed, and arguably it could cause someone to=20 incorrectly "double unescape" a string representation, if they don't pay=20 close attention. So I would prefer the following: strings: are considered equal if they contain the same number of Unicode characters and their code points are position-wise equal. --=20 Cyrus Daboo From stpeter@stpeter.im Fri Nov 16 08:01: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 CD42721F884F for ; Fri, 16 Nov 2012 08:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.301 X-Spam-Level: X-Spam-Status: No, score=-102.301 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, 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 d8UxNA9llUIh for ; Fri, 16 Nov 2012 08:01:20 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAD821F85DF for ; Fri, 16 Nov 2012 08:01:20 -0800 (PST) Received: from [64.101.72.39] (unknown [64.101.72.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5903B40062; Fri, 16 Nov 2012 09:05:36 -0700 (MST) Message-ID: <50A65D0C.7060201@stpeter.im> Date: Fri, 16 Nov 2012 08:34:36 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <1969645725.20121101120100@w3.org> <50A5C8E0.6010704@it.aoyama.ac.jp> <50A5F0B8.2080400@it.aoyama.ac.jp> In-Reply-To: <50A5F0B8.2080400@it.aoyama.ac.jp> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Chris Lilley , IETF Apps Discuss , eb2m-mrt@asahi-net.or.jp Subject: Re: [apps-discuss] FW: New Version Notification for draft-lilley-xml-mediatypes-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, 16 Nov 2012 16:01:20 -0000 Me, too. On 11/16/12 12:52 AM, "Martin J. Dürst" wrote: > Yes, I volunteer to review the document. Regards, Martin. > > On 2012/11/16 16:35, Murray S. Kucherawy wrote: >> Are the people agreeing that it should be processed in appsawg (Julian, >> Martin, Tony, and Tim so far; hopefully others) committing to doing >> reviews >> if we adopt this document? SM has already said he will. >> >> -MSK >> >> >> On Thu, Nov 15, 2012 at 9:02 PM, "Martin J. Dürst" >> wrote: >> >>> I agree with APPSAWG taking it up. 3023 is really outdated, and needs to >>> be fixed. >>> >>> Regards, Martin. >>> >>> >>> On 2012/11/15 23:41, Tim Bray wrote: >>> >>>> I would support APPSAWG taking it up. 3023 is so horribly wrong, it >>>> would >>>> be good to have a sane replacement. -T >>>> >>>> On Thu, Nov 15, 2012 at 3:36 PM, Murray S. >>>> Kucherawy >>>> **wrote: >>>> >>>> So far there's been only one expression of support for processing >>>> this >>>>> through appsawg. Are there any others? Any objections to >>>>> processing it >>>>> here? Other suggestions? >>>>> >>>>> -MSK, co-chair >>>>> >>>>> >>>>> On Thu, Nov 1, 2012 at 4:01 AM, Chris Lilley wrote: >>>>> >>>>> Hello apps-discuss, >>>>>> >>>>>> draft-lilley-xml-mediatypes-**00.txt is a restart of a proposed >>>>>> replacement >>>>>> for RFC3023. The previous attempt foundered because the approach >>>>>> taken >>>>>> required deprecation of text/xml, and the implementor community >>>>>> was not >>>>>> happy with that as there is much legacy content using that type that >>>>>> still >>>>>> has to be supported. >>>>>> >>>>>> The present draft takes advantage of recent changes in HTTP-bis which >>>>>> removes the default charset, and so treats text/xml the same as >>>>>> application/xml. This approach is also what most implementations >>>>>> already >>>>>> do, in practice. The present draft also introduces some >>>>>> clarifications >>>>>> on >>>>>> fragment identifiers for xml, and updates some references. >>>>>> >>>>>> It has been suggested that this document would be a good fit for the >>>>>> apps >>>>>> area WG, and the editors would like to request review and adoption by >>>>>> the >>>>>> WG (or an alternative suggestion of where/how to handle this >>>>>> document). >>>>>> >>>>>> This would be a standards-track document. >>>>>> >>>>>> -- >>>>>> Chris Lilley Technical Director, Interaction Domain >>>>>> W3C Graphics Activity Lead, Fonts Activity Lead >>>>>> Co-Chair, W3C Hypertext CG >>>>>> Member, CSS, WebFonts, SVG Working Groups >>>>>> ______________________________**_________________ >>>>>> 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 ajs@anvilwalrusden.com Fri Nov 16 08:27: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 20D4821F86AF for ; Fri, 16 Nov 2012 08:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[AWL=-1.108, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 B9p+xj4JypQa for ; Fri, 16 Nov 2012 08:27:26 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8498021F86AB for ; Fri, 16 Nov 2012 08:27:26 -0800 (PST) Received: from mx1.yitter.info (nat-03-mht.dyndns.com [216.146.45.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E91678A031 for ; Fri, 16 Nov 2012 16:27:23 +0000 (UTC) Date: Fri, 16 Nov 2012 11:27:16 -0500 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20121116162715.GA90582@mx1.yitter.info> References: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 16 Nov 2012 16:27:27 -0000 On Fri, Nov 16, 2012 at 10:55:48AM -0500, Cyrus Daboo wrote: > > Advice from i18n "experts" on language would be good. My guess is it > might be sufficient to allow the patch-processing entity to > normalize the two strings being tested in some consistent manner for > comparison, rather than require "code point" equality. The scare quotes around experts are entirely appropriate in my case. But yes, normalization is probably a good idea. What isn't clear to me is what kind of comparison you want. If you use NFKC, you maximize matches, but the danger is that you'll match something you didn't want to match. The thing to read is probably http://www.unicode.org/reports/tr15/. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From jasnell@gmail.com Fri Nov 16 08:55: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 59DB521F8516 for ; Fri, 16 Nov 2012 08:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[AWL=-0.252, 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 Y1PTL2AaxHn5 for ; Fri, 16 Nov 2012 08:55:30 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 502C221F85FC for ; Fri, 16 Nov 2012 08:55:29 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so4369089iec.31 for ; Fri, 16 Nov 2012 08:55:28 -0800 (PST) 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=smxzAtU2obPBbLaOXFd13LnILEDZWiZFeI3Dz4ZWAnM=; b=HoNGi4gIFNt+ZS01ZagzBV+U5clhZ4e4Kw0r1r1Nn85g6gBFbIf4sHuyv8FOHgAojL 4SG5c9bv/u5x+2NscGqJkNsjdHXoSUdLAolWQkQVamtV9pq9uyeEKntUaa/oVQrsn0As K8NiaQWL6tj3S084wEic2PvkuGcWDHzQsHKbzyxBsTaXFqQ1OnUMwh68hr1vCoOs9WEa pPlE86O4yNKmpzAh3+DykFsNc4SHPq4UJf0AVTqaf5DseyIj4alwTO5k7uEddfFgcmm+ BmLgpGJPpNHHl2m+qyi0CaQxnrFqEvUywA9/THcWHWird15OaAKNCZNiaT4R4Rp1A1UJ PI4A== Received: by 10.42.210.12 with SMTP id gi12mr4420670icb.22.1353084928812; Fri, 16 Nov 2012 08:55:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.225 with HTTP; Fri, 16 Nov 2012 08:55:08 -0800 (PST) In-Reply-To: <20121116162715.GA90582@mx1.yitter.info> References: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> <20121116162715.GA90582@mx1.yitter.info> From: James M Snell Date: Fri, 16 Nov 2012 08:55:08 -0800 Message-ID: To: Andrew Sullivan Content-Type: multipart/alternative; boundary=20cf304351d288659f04ce9fa277 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 16 Nov 2012 16:55:32 -0000 --20cf304351d288659f04ce9fa277 Content-Type: text/plain; charset=UTF-8 For a patch operation, I'm definitely not convinced that anything other than codepoint comparison should be allowed. The motivation of the "test" operation is to ensure that the state of the target resource is what we expect it to be before or after making a change. Normalization could short circuit such checks in various situations. - James On Fri, Nov 16, 2012 at 8:27 AM, Andrew Sullivan wrote: > On Fri, Nov 16, 2012 at 10:55:48AM -0500, Cyrus Daboo wrote: > > > > Advice from i18n "experts" on language would be good. My guess is it > > might be sufficient to allow the patch-processing entity to > > normalize the two strings being tested in some consistent manner for > > comparison, rather than require "code point" equality. > > The scare quotes around experts are entirely appropriate in my case. > But yes, normalization is probably a good idea. What isn't clear to > me is what kind of comparison you want. If you use NFKC, you maximize > matches, but the danger is that you'll match something you didn't want > to match. > > The thing to read is probably http://www.unicode.org/reports/tr15/. > > Best, > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --20cf304351d288659f04ce9fa277 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For a patch operation, I'm defini= tely not convinced that anything other than codepoint comparison should be = allowed. The motivation of the "test" operation is to ensure that= the state of the target resource is what we expect it to be before or afte= r making a change. Normalization could short circuit such checks in various= situations.

- James

<= br>
On Fri, Nov 16, 2012 at 8:27 AM, Andrew Sulli= van <ajs@anvilwalrusden.com> wrote:
On Fri, Nov 16, 2012 at 10= :55:48AM -0500, Cyrus Daboo wrote:
>
> Advice from i18n "experts" on language would be good. My gue= ss is it
> might be sufficient to allow the patch-processing entity to
> normalize the two strings being tested in some consistent manner for > comparison, rather than require "code point" equality.

The scare quotes around experts are entirely appropriate in my case.<= br> But yes, normalization is probably a good idea. =C2=A0What isn't clear = to
me is what kind of comparison you want. =C2=A0If you use NFKC, you maximize=
matches, but the danger is that you'll match something you didn't w= ant
to match.

The thing to read is probably http://www.unicode.org/reports/tr15/.

Best,
A

--
Andrew Sullivan
ajs@anvilwalrusden.com
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--20cf304351d288659f04ce9fa277-- From cyrus@daboo.name Fri Nov 16 09:23: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 6C5F421F86AF for ; Fri, 16 Nov 2012 09:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 j9JEhvhXkkeb for ; Fri, 16 Nov 2012 09:23:10 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id E6EB621F842A for ; Fri, 16 Nov 2012 09:23:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 4AEE83576734; Fri, 16 Nov 2012 12:23:09 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXeq3KHWpq6F; Fri, 16 Nov 2012 12:23:08 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id F22753576729; Fri, 16 Nov 2012 12:23:07 -0500 (EST) Date: Fri, 16 Nov 2012 12:23:04 -0500 From: Cyrus Daboo To: James M Snell , Andrew Sullivan Message-ID: In-Reply-To: References: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> <20121116162715.GA90582@mx1.yitter.info> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=831 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 16 Nov 2012 17:23:10 -0000 Hi James, --On November 16, 2012 8:55:08 AM -0800 James M Snell wrote: > For a patch operation, I'm definitely not convinced that anything other > than codepoint comparison should be allowed. The motivation of the "test" > operation is to ensure that the state of the target resource is what we > expect it to be before or after making a change. Normalization could > short circuit such checks in various situations. > If the input value to the test is going to come directly from what was in the original JSON document, then what you say seems fine (though I think a statement along those lines should be made somewhere to clarify that point). However, isn't it possible that a test might be used to see if a document has a specific new value present as opposed to the original value? -- Cyrus Daboo From jasnell@gmail.com Fri Nov 16 09:48: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 03C1B21F8AA2 for ; Fri, 16 Nov 2012 09:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.835 X-Spam-Level: X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[AWL=-0.237, 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 7qi-hRApgVXu for ; Fri, 16 Nov 2012 09:48:42 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5608E21F8AA1 for ; Fri, 16 Nov 2012 09:48:42 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so2058142iaf.31 for ; Fri, 16 Nov 2012 09:48:41 -0800 (PST) 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=Gag8GIB5loLWtHQw6ATpj/xJwxYyzWWaPaoI6qOkOwk=; b=SMtcNE1LTJ15gdpFGpaFork9AngaU4912D9DrybxAITQe7dd3VvJsFlQ9p5X3CUjaB dxcCDrXzEHuhyB7h/QNqSalFwPnJvYOtUrqr6768eZTz7a9a+M3vjc81+wxrEKkA/zXZ DMneWYHFWRlvaGY75RfsHCpQf/Cg3240q9MU6Hg3W9c9DH6hlyb7VZnmvGkYdGU6ltYE vuLILhpdNyRdcB1T4OQBUMDOIwXfKol4VBcg61Hl2SxnGhlf3Yge9L+s6OeRa4SLDxwH ykCbcJfGwyj1r0vKaTmt+bnyxindncJEg8iVSya0gEDQ/keMjOi9HtqIG6HkQiCPRHTD bGQg== Received: by 10.42.210.12 with SMTP id gi12mr4588663icb.22.1353088121723; Fri, 16 Nov 2012 09:48:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.225 with HTTP; Fri, 16 Nov 2012 09:48:21 -0800 (PST) In-Reply-To: References: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> <20121116162715.GA90582@mx1.yitter.info> From: James M Snell Date: Fri, 16 Nov 2012 09:48:21 -0800 Message-ID: To: Cyrus Daboo Content-Type: multipart/alternative; boundary=20cf304351d2d85b1104cea060df Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 16 Nov 2012 17:48:43 -0000 --20cf304351d2d85b1104cea060df Content-Type: text/plain; charset=UTF-8 Yes, that's reasonable of course... but even in that case a codepoint based comparison is still the most reliable. On Fri, Nov 16, 2012 at 9:23 AM, Cyrus Daboo wrote: > Hi James, > > > --On November 16, 2012 8:55:08 AM -0800 James M Snell > wrote: > > For a patch operation, I'm definitely not convinced that anything other >> than codepoint comparison should be allowed. The motivation of the "test" >> operation is to ensure that the state of the target resource is what we >> expect it to be before or after making a change. Normalization could >> short circuit such checks in various situations. >> >> > If the input value to the test is going to come directly from what was in > the original JSON document, then what you say seems fine (though I think a > statement along those lines should be made somewhere to clarify that > point). However, isn't it possible that a test might be used to see if a > document has a specific new value present as opposed to the original value? > > -- > Cyrus Daboo > > --20cf304351d2d85b1104cea060df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, that's reasonable of course.= .. but even in that case a codepoint based comparison is still the most rel= iable.=C2=A0


On Fri, Nov 16, 2012 at 9:23 AM, Cyrus Daboo <cyrus@daboo.name>= ; wrote:
Hi James,


--On November 16, 2012 8:55:08 AM -0800 James M Snell <jasnell@gmail.com> wrote:

For a patch operation, I'm definitely not convinced that anything other=
than codepoint comparison should be allowed. The motivation of the "te= st"
operation is to ensure that the state of the target resource is what we
expect it to be before or after making a change. Normalization could
short circuit such checks in various situations.


If the input value to the test is going to come directly from what was in t= he original JSON document, then what you say seems fine (though I think a s= tatement along those lines should be made somewhere to clarify that point).= However, isn't it possible that a test might be used to see if a docum= ent has a specific new value present as opposed to the original value?

--
Cyrus Daboo


--20cf304351d2d85b1104cea060df-- From john-ietf@jck.com Fri Nov 16 10:52: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 C23CE21F8AED for ; Fri, 16 Nov 2012 10:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 v5hIUSaQPB+t for ; Fri, 16 Nov 2012 10:52:19 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 267F421F84CC for ; Fri, 16 Nov 2012 10:52:19 -0800 (PST) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TZR1W-0004gC-9f; Fri, 16 Nov 2012 13:52:18 -0500 Date: Fri, 16 Nov 2012 13:52:10 -0500 From: John C Klensin To: Andrew Sullivan , apps-discuss@ietf.org Message-ID: <75B32794FBAAC69101701DE0@JcK-HP8200.jck.com> In-Reply-To: <20121116162715.GA90582@mx1.yitter.info> References: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> <20121116162715.GA90582@mx1.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] WGLC review: draft-ietf-appsawg-json-patch-06 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, 16 Nov 2012 18:52:19 -0000 --On Friday, November 16, 2012 11:27 -0500 Andrew Sullivan wrote: > On Fri, Nov 16, 2012 at 10:55:48AM -0500, Cyrus Daboo wrote: >> >> Advice from i18n "experts" on language would be good. My >> guess is it might be sufficient to allow the patch-processing >> entity to normalize the two strings being tested in some >> consistent manner for comparison, rather than require "code >> point" equality. > > The scare quotes around experts are entirely appropriate in my > case. But yes, normalization is probably a good idea. What > isn't clear to me is what kind of comparison you want. If you > use NFKC, you maximize matches, but the danger is that you'll > match something you didn't want to match. > > The thing to read is probably > http://www.unicode.org/reports/tr15/. And draft-iab-identifier-comparison john From paul.hoffman@vpnc.org Fri Nov 16 11:03: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 CCA0C21F8AD2 for ; Fri, 16 Nov 2012 11:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 DZE7fnkvvwKF for ; Fri, 16 Nov 2012 11:03:17 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 49CED21F8924 for ; Fri, 16 Nov 2012 11:03:17 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAGJ3FAx014121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 16 Nov 2012 12:03:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Fri, 16 Nov 2012 11:03:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> <20121116162715.GA90582@mx1.yitter.info> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1499) Subject: Re: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 16 Nov 2012 19:03:17 -0000 On Nov 16, 2012, at 9:48 AM, James M Snell wrote: > Yes, that's reasonable of course... but even in that case a codepoint = based comparison is still the most reliable.=20 +1. If a system that is doing a patch wants fuzzy comparison, it can = build that in itself. If we specify exactly one fuzzy comparison, it = will only satisfy part of the market. If we specify a fuzzy comparison = framework with one worked out example of normalization, we descend into = madness. i18n is not *needed* for JSON patching; it would be useful in some = limited cases. --Paul Hoffman= From superuser@gmail.com Fri Nov 16 12:27: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 8C04221F860E for ; Fri, 16 Nov 2012 12:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.147, 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 Hq7OnUnmetqs for ; Fri, 16 Nov 2012 12:27:20 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E353D21F85DF for ; Fri, 16 Nov 2012 12:27:19 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2637935lbk.31 for ; Fri, 16 Nov 2012 12:27:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Jk27gPA0+iM90/dyq2SoI0chQWh3D5UgG8dQLRl9iGQ=; b=LInFq/mq2xm1KQZkylAzQozvdtISMbYmvjcdOfWfK31VvLCujWSVaB3dUObBvdgZwK M3RBTiFtvbAHknv7E3M3vPTTkNvriXIjO9+szqlTqGII6LPdKUwPjz4jkQEY/tZ/h/dt gPc7nBIHBp5wIGeTWoe11NcFk+tH6lM3i8Ucic9TnfQgHAjpQq6+YYLqYtcAQHd2r+lS TkSGjeOpm8u6b0X6A6GUV4xDGXJOTXuXc17zfJinsNCMdqbwz0H+jdcPFEKuCNUWAl5N mJGVwtGj9fyZDhwXTxjZEaaKLstmPVA+xJmGkiPuaccQPzXp1+jhf4b/lYiHxB4JcMXI Z4wA== MIME-Version: 1.0 Received: by 10.112.42.34 with SMTP id k2mr2415411lbl.26.1353097638658; Fri, 16 Nov 2012 12:27:18 -0800 (PST) Received: by 10.112.80.234 with HTTP; Fri, 16 Nov 2012 12:27:18 -0800 (PST) Date: Fri, 16 Nov 2012 12:27:18 -0800 Message-ID: From: "Murray S. Kucherawy" To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=485b390f7dae19446f04cea29886 Cc: Chris Lilley , IETF Apps Discuss , eb2m-mrt@asahi-net.or.jp Subject: [apps-discuss] Call For Adoption: draft-lilley-xml-mediatypes 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, 16 Nov 2012 20:27:24 -0000 --485b390f7dae19446f04cea29886 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK, I think we have enough to move forward here. This is an official call for adoption of this draft. What I need to hear now is objections, if there are any. Otherwise we'll adopt this document in a few days. I will be acting as document shepherd. -MSK, co-chair On Fri, Nov 16, 2012 at 7:34 AM, Peter Saint-Andre wrot= e: > Me, too. > > On 11/16/12 12:52 AM, "Martin J. D=FCrst" wrote: > > Yes, I volunteer to review the document. Regards, Martin. > > > > On 2012/11/16 16:35, Murray S. Kucherawy wrote: > >> Are the people agreeing that it should be processed in appsawg (Julian= , > >> Martin, Tony, and Tim so far; hopefully others) committing to doing > >> reviews > >> if we adopt this document? SM has already said he will. > >> > >> -MSK > >> > >> > >> On Thu, Nov 15, 2012 at 9:02 PM, "Martin J. D=FCrst" > >> wrote: > >> > >>> I agree with APPSAWG taking it up. 3023 is really outdated, and needs > to > >>> be fixed. > >>> > >>> Regards, Martin. > >>> > >>> > >>> On 2012/11/15 23:41, Tim Bray wrote: > >>> > >>>> I would support APPSAWG taking it up. 3023 is so horribly wrong, it > >>>> would > >>>> be good to have a sane replacement. -T > >>>> > >>>> On Thu, Nov 15, 2012 at 3:36 PM, Murray S. > >>>> Kucherawy > >>>> **wrote: > >>>> > >>>> So far there's been only one expression of support for processing > >>>> this > >>>>> through appsawg. Are there any others? Any objections to > >>>>> processing it > >>>>> here? Other suggestions? > >>>>> > >>>>> -MSK, co-chair > >>>>> > >>>>> > >>>>> On Thu, Nov 1, 2012 at 4:01 AM, Chris Lilley wrote: > >>>>> > >>>>> Hello apps-discuss, > >>>>>> > >>>>>> draft-lilley-xml-mediatypes-**00.txt is a restart of a proposed > >>>>>> replacement > >>>>>> for RFC3023. The previous attempt foundered because the approach > >>>>>> taken > >>>>>> required deprecation of text/xml, and the implementor community > >>>>>> was not > >>>>>> happy with that as there is much legacy content using that type th= at > >>>>>> still > >>>>>> has to be supported. > >>>>>> > >>>>>> The present draft takes advantage of recent changes in HTTP-bis > which > >>>>>> removes the default charset, and so treats text/xml the same as > >>>>>> application/xml. This approach is also what most implementations > >>>>>> already > >>>>>> do, in practice. The present draft also introduces some > >>>>>> clarifications > >>>>>> on > >>>>>> fragment identifiers for xml, and updates some references. > >>>>>> > >>>>>> It has been suggested that this document would be a good fit for t= he > >>>>>> apps > >>>>>> area WG, and the editors would like to request review and adoption > by > >>>>>> the > >>>>>> WG (or an alternative suggestion of where/how to handle this > >>>>>> document). > >>>>>> > >>>>>> This would be a standards-track document. > >>>>>> > >>>>>> -- > >>>>>> Chris Lilley Technical Director, Interaction Domain > >>>>>> W3C Graphics Activity Lead, Fonts Activity Lead > >>>>>> Co-Chair, W3C Hypertext CG > >>>>>> Member, CSS, WebFonts, SVG Working Groups > >>>>>> ______________________________**_________________ > >>>>>> apps-discuss mailing list > >>>>>> apps-discuss@ietf.org > >>>>>> https://www.ietf.org/mailman/**listinfo/apps-discuss< > https://www.ietf.org/mailman/listinfo/apps-discuss> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> ______________________________**_________________ > >>>>> apps-discuss mailing list > >>>>> apps-discuss@ietf.org > >>>>> https://www.ietf.org/mailman/**listinfo/apps-discuss< > https://www.ietf.org/mailman/listinfo/apps-discuss> > >>>>> > >>>>> > > --485b390f7dae19446f04cea29886 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK, I think we have enough to move forward here.

This is an official= call for adoption of this draft.=A0 What I need to hear now is objections,= if there are any.=A0 Otherwise we'll adopt this document in a few days= .=A0 I will be acting as document shepherd.

-MSK, co-chair



On Fri, Nov 16, 2012 at 7:34 AM, Peter Saint-Andre <stpete= r@stpeter.im> wrote:
Me, too.

On 11/16/12 12:52 AM, "Martin J. D=FCrst" wrote:
> Yes, I volunteer to review the document. =A0 =A0Regards, =A0 Martin. >
> On 2012/11/16 16:35, Murray S. Kucherawy wrote:
>> Are the people agreeing that it should be processed in appsawg (Ju= lian,
>> Martin, Tony, and Tim so far; hopefully others) committing to doin= g
>> reviews
>> if we adopt this document? =A0SM has already said he will.
>>
>> -MSK
>>
>>
>> On Thu, Nov 15, 2012 at 9:02 PM, "Martin J. D=FCrst"
>> <duerst@it.aoyama.ac.= jp>wrote:
>>
>>> I agree with APPSAWG taking it up. 3023 is really outdated, an= d needs to
>>> be fixed.
>>>
>>> Regards, =A0 Martin.
>>>
>>>
>>> On 2012/11/15 23:41, Tim Bray wrote:
>>>
>>>> I would support APPSAWG taking it up. =A03023 is so horrib= ly wrong, it
>>>> would
>>>> be good to have a sane replacement. -T
>>>>
>>>> On Thu, Nov 15, 2012 at 3:36 PM, Murray S.
>>>> Kucherawy<superu= ser@gmail.com>
>>>> **wrote:
>>>>
>>>> =A0 So far there's been only one expression of support= for processing
>>>> this
>>>>> through appsawg. =A0Are there any others? =A0Any objec= tions to
>>>>> processing it
>>>>> here? =A0Other suggestions?
>>>>>
>>>>> -MSK, co-chair
>>>>>
>>>>>
>>>>> On Thu, Nov 1, 2012 at 4:01 AM, Chris Lilley<chris@w3.org> =A0 wrote:
>>>>>
>>>>> =A0 Hello apps-discuss,
>>>>>>
>>>>>> draft-lilley-xml-mediatypes-**00.txt is a restart = of a proposed
>>>>>> replacement
>>>>>> for RFC3023. The previous attempt foundered becaus= e the approach
>>>>>> taken
>>>>>> required deprecation of text/xml, and the implemen= tor community
>>>>>> was not
>>>>>> happy with that as there is much legacy content us= ing that type that
>>>>>> still
>>>>>> has to be supported.
>>>>>>
>>>>>> The present draft takes advantage of recent change= s in HTTP-bis which
>>>>>> removes the default charset, and so treats text/xm= l the same as
>>>>>> application/xml. This approach is also what most i= mplementations
>>>>>> already
>>>>>> do, in practice. The present draft also introduces= some
>>>>>> clarifications
>>>>>> on
>>>>>> fragment identifiers for xml, and updates some ref= erences.
>>>>>>
>>>>>> It has been suggested that this document would be = a good fit for the
>>>>>> apps
>>>>>> area WG, and the editors would like to request rev= iew and adoption by
>>>>>> the
>>>>>> WG (or an alternative suggestion of where/how to h= andle this
>>>>>> document).
>>>>>>
>>>>>> This would be a standards-track document.
>>>>>>
>>>>>> --
>>>>>> =A0 =A0Chris Lilley =A0 Technical Director, Intera= ction Domain
>>>>>> =A0 =A0W3C Graphics Activity Lead, Fonts Activity = Lead
>>>>>> =A0 =A0Co-Chair, W3C Hypertext CG
>>>>>> =A0 =A0Member, CSS, WebFonts, SVG Working Groups >>>>>> ______________________________**_________________<= br> >>>>>> apps-discuss mailing list
>>>>>> apps-disc= uss@ietf.org
>>>>>> https://www.ietf.org/mailman/**listinfo/ap= ps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss<= /a>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ______________________________**_________________
>>>>> apps-discuss mailing list
>>>>> apps-discuss@= ietf.org
>>>>> https://www.ietf.org/mailman/**listinfo/apps-d= iscuss<https://www.ietf.org/mailman/listinfo/apps-discuss&= gt;
>>>>>
>>>>>


--485b390f7dae19446f04cea29886-- From internet-drafts@ietf.org Fri Nov 16 19:39: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 A2EE021F8B81; Fri, 16 Nov 2012 19:39:42 -0800 (PST) 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 lQh0EZ9fpQoF; Fri, 16 Nov 2012 19:39:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314FA21F8B8D; Fri, 16 Nov 2012 19:39:42 -0800 (PST) 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.36 Message-ID: <20121117033942.25633.68806.idtracker@ietfa.amsl.com> Date: Fri, 16 Nov 2012 19:39:42 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-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, 17 Nov 2012 03:39:42 -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 : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-ietf-appsawg-webfinger-03.txt Pages : 16 Date : 2012-11-16 Abstract: This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paulej@packetizer.com Fri Nov 16 20:18: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 1517221F8B36 for ; Fri, 16 Nov 2012 20:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.437, 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 oqB1tj5THSqp for ; Fri, 16 Nov 2012 20:18:26 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id CE56F21F850D for ; Fri, 16 Nov 2012 20:18:20 -0800 (PST) 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 qAH4IJbK017651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Nov 2012 23:18:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353125899; bh=QMqRgPs/q6kN+sGnL5H/2Xyz/G9aS6XcsZo9Ca6BRtQ=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=MGo2QZ3DxdbgBO/6z6fgUwHTVpGL7SEoAdjSOq32bvu2rPktxwJnIGfQSvQNExfo/ QRwARPtHG+M2HQ3oPNmnuy9WmOBq8KfVYfTr1T08thZERlXqw59ETSIJN4rRZ9kBfc uWVVywaJMYDL3vHsTpXhpwwvbm6G84kg6h+SVP2I= From: "Paul E. Jones" To: , Date: Fri, 16 Nov 2012 23:18:28 -0500 Message-ID: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D91_01CDC450.B0258890" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3EeazC+J3GuJdzRa6rNtcrBqxOfA== Content-Language: en-us Subject: [apps-discuss] New draft-ietf-appsawg-webfinger-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, 17 Nov 2012 04:18:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0D91_01CDC450.B0258890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, I published a new -03 version of the WebFinger draft. I made substantial changes throughout the document, with changes in nearly every section. The changes should be in line with the views of the group and, most notably, gets rid of everything related to XRD, introduces a new /.well-known/webfinger resource, and species the default format to be JRD. Dependencies on RFC 6415 are removed, except for the reference to the JRD document itself. I know there was a request for more "real-world" examples. Mike was going to provide one, but I certainly welcome others if you think it might be useful. I tried to make use of most JRD features so that developers would see at least one example. I did find one error right after publishing the draft. In the example near the bottom of page 4, the word "properties" should be "titles" in the JRD. I used two different languages to illustrate how to add a title to a link. Your comments are certainly welcome! Paul ------=_NextPart_000_0D91_01CDC450.B0258890 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I published = a new -03 version of the WebFinger draft.  I made substantial = changes throughout the document, with changes in nearly every = section.  The changes should be in line with the views of the group = and, most notably, gets rid of everything related to XRD, introduces a = new /.well-known/webfinger resource, and species the default format to = be JRD.

 

Dependencies on RFC 6415 are removed, except for the = reference to the JRD document itself.

 

I know there = was a request for more “real-world” examples.  Mike was = going to provide one, but I certainly welcome others if you think it = might be useful.  I tried to make use of most JRD features so that = developers would see at least one example.

 

I did find = one error right after publishing the draft.  In the example near = the bottom of page 4, the word “properties” should be = “titles” in the JRD.  I used two different languages to = illustrate how to add a title to a link.

 

Your = comments are certainly welcome!

 

Paul

 

------=_NextPart_000_0D91_01CDC450.B0258890-- From john@jlc.net Fri Nov 16 20:30: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 94B7C21F86CE for ; Fri, 16 Nov 2012 20:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.364 X-Spam-Level: X-Spam-Status: No, score=-106.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 E89gBUjVrBQZ for ; Fri, 16 Nov 2012 20:30:30 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 97C0721F84E2 for ; Fri, 16 Nov 2012 20:30:28 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id B1FA733D2A; Fri, 16 Nov 2012 23:30:28 -0500 (EST) Date: Fri, 16 Nov 2012 23:30:28 -0500 From: John Leslie To: Marc Blanchet Message-ID: <20121117043028.GK72469@verdi> References: <50A411A3.6060600@qti.qualcomm.com> <01OMMH6GA83U00008S@mauve.mrochek.com> <50A4631D.2060606@qti.qualcomm.com> <01OMMYVTHCB000008S@mauve.mrochek.com> <50A507F9.4070103@qti.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: IETF Apps Discuss Subject: Re: [apps-discuss] AD Fail - MPTCP API 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, 17 Nov 2012 04:30:30 -0000 Marc Blanchet wrote: > > to me, it remains to be seen how the interaction of: > - happy eyeballs > - IPv4 vs IPv6 address family preference > - application using a non-80 port and then falling back to port > 80/443 because of outgoing port blocking in some access networks > (I wrote a draft on that) > - multiple interfaces which are pretty common these days, such as > wifi and cell data-3G-LTE-... > > all of those are common cases today, many with specific APIs. > Then you add MP-TCP on top of that. > > I fail to see how those interactions will work. Each of them, taken > separately, does a good job for its own purpose. but the common case > shall include all of these. Not sure the underlying OS could do all > the job for the APP, too. > > so, no clear suggestion, but a concern about complexity of apps and > how well these techniques will interact and work each other. I think this deserves some discussion (and I was hoping someone else would start it. ;^) Understand, first, that MPTCP can only use multiple paths if - one TCP connection is established with MP_CAPABLE negotiated by three-way handshake with the MP_CAPABLE TCP option (this presumably will be quite common, eventually); - at least one endpoint originates another TCP connection with MP_JOIN (instead of MP_CAPABLE) negotiated by three-way handshake with the MP_JOIN TCP option. (i.e. without three MP_CAPABLE TCP options, followed by three MP_JOIN options, there can be no multiple paths involved.) The MP_CAPABLE handshake exchanges keys. If for any reason the MP_JOIN reaches a different endpoint, the keys will not match. In the simple case, the host originating the MP_JOIN will send it to the same remote address, but from a different interface using a different source IP address. But there's also a way to advise the other endpoint of another local address, using ADD_ADDR. With ADD_ADDR it is possible to enable multiple paths using both IPv4 and IPv6, as well as different ports, though some implementations may not support this, and even if supported by the endpoints, things can go wrong in the middle. So, let me try to chip away at the cases Marc asked about... > - happy eyeballs Happy eyeballs is implemented in different ways, but generally overlaps an attempt to establish an IPv6 connection with an attempt to establish an IPv4 connection, discarding the one which doesn't complete first. Both attempted connections are likely to carry the MP_CAPABLE option, and may or may not succeed in negotiating it. But only one will be used. Attempting an MP_JOIN must happen later, though I suppose ADD_ADDRs could be exchanged so that the other IP version could be tried for a secondary path -- that probably won't be common -- and even with that there would be no re-use of the connection which finished second. > - IPv4 vs IPv6 address family preference Same as "happy eyeballs". (Note that ADD_ADDRs would need to be exchanged to make use of both address families.) > - application using a non-80 port and then falling back to port > 80/443 because of outgoing port blocking in some access networks Really the same, also; though different ports within the same address families are easier to implement. > - multiple interfaces which are pretty common these days, such as > wifi and cell data-3G-LTE-... It would be quite practical to establish the initial TCP connection on a more expensive service; then do MP_JOINs on the less expensive service, essentially dropping the more expensive service so long as the less expensive one keeps working. Note also that MPTCP _intends_ to keep the same MPTCP connection (group) functioning as an interface gets different IP addresses. ==== (I have only answered for what the protocol allows for. YMMV with differing implementations.) The draft named in this thread covers only a basic API, which could give the endpoint application(s) better control over various tradeoffs involved in the internals of an MPTCP implementation. The protocol itself is found in draft-ietf-mptcp-multiaddressed, which is already approved for publication as an Experimental track RFC. -- John Leslie From julian.reschke@gmx.de Sat Nov 17 03:53: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 8F39021F8563 for ; Sat, 17 Nov 2012 03:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=-0.914, 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 uPB3crvDKcG1 for ; Sat, 17 Nov 2012 03:53:50 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9F0F421F8462 for ; Sat, 17 Nov 2012 03:53:49 -0800 (PST) Received: (qmail invoked by alias); 17 Nov 2012 11:53:46 -0000 Received: from p5DD96AA7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.106.167] by mail.gmx.net (mp035) with SMTP; 17 Nov 2012 12:53:46 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX188+FAPsVA8oCmDjznBYl54pJZItq2/AkDEQxfqdW ZaeDiQMqhlVfrv Message-ID: <50A77AC2.3070800@gmx.de> Date: Sat, 17 Nov 2012 12:53:38 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: James M Snell References: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> <20121116162715.GA90582@mx1.yitter.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 17 Nov 2012 11:53:50 -0000 On 2012-11-16 17:55, James M Snell wrote: > For a patch operation, I'm definitely not convinced that anything other > than codepoint comparison should be allowed. The motivation of the > ... +1000 From superuser@gmail.com Sat Nov 17 09:21: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 D580621F8434 for ; Sat, 17 Nov 2012 09:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 D8RrvICCXeZD for ; Sat, 17 Nov 2012 09:21:46 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1798821F8432 for ; Sat, 17 Nov 2012 09:21:45 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3065265lbk.31 for ; Sat, 17 Nov 2012 09:21:44 -0800 (PST) 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=lZKxkV65vbO5BdONNEEdoQSAe7TNHs45QHIBmZX2Y9U=; b=NKfacwTvZ8bprP2ov8A1VdOBNMtg3zjySkI9fplk8AcEwAL5vvdU/89LYQhkbmPjny YDPx9MghF8jWdH3tFQvxNMDDgS4bybm8Zg+p2nfoPCWRxCmu2Fy7kncZJdB/hvZHAVHv T7EFNHXyKyvSeE3NQmhdREz+zWNUBXQUXe0D5Y5fInifW7LkKbDRw2W3Co+3wJqFMqDu 57obXkEWogxJ33UMFlyrP3ULUfATqUVtYcVN2KHzgpMtWxSKuqJrhmKh0A/mWssUXZ/G ukuUD6P+rEFgOlYgdXsd3WVWiUbYKq6pbvtMg5fedFOO9I/zXV3Vo9A0VDSvjcQ3m/iD QyOw== MIME-Version: 1.0 Received: by 10.112.98.131 with SMTP id ei3mr1666689lbb.63.1353172904717; Sat, 17 Nov 2012 09:21:44 -0800 (PST) Received: by 10.112.80.234 with HTTP; Sat, 17 Nov 2012 09:21:44 -0800 (PST) In-Reply-To: <50A77AC2.3070800@gmx.de> References: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> <20121116162715.GA90582@mx1.yitter.info> <50A77AC2.3070800@gmx.de> Date: Sat, 17 Nov 2012 09:21:44 -0800 Message-ID: From: "Murray S. Kucherawy" To: Julian Reschke Content-Type: multipart/alternative; boundary=f46d0401fb954e2f0b04ceb41ebe Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 17 Nov 2012 17:21:47 -0000 --f46d0401fb954e2f0b04ceb41ebe Content-Type: text/plain; charset=ISO-8859-1 This may be an ignorant question, but is this really something about which JSON pointer/patch needs to worry? It seems to me that this is a property of JSON, so any semantics about key equality that exist are defined in there, and we shouldn't be adding any here. -MSK On Sat, Nov 17, 2012 at 3:53 AM, Julian Reschke wrote: > On 2012-11-16 17:55, James M Snell wrote: > >> For a patch operation, I'm definitely not convinced that anything other >> than codepoint comparison should be allowed. The motivation of the >> > > ... > > +1000 > > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --f46d0401fb954e2f0b04ceb41ebe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This may be an ignorant question, but is this really something about which = JSON pointer/patch needs to worry?=A0 It seems to me that this is a propert= y of JSON, so any semantics about key equality that exist are defined in th= ere, and we shouldn't be adding any here.

-MSK


O= n Sat, Nov 17, 2012 at 3:53 AM, Julian Reschke <julian.reschke@gmx.de<= /a>> wrote:
On 2012-11-16 17:55, James= M Snell wrote:
For a patch operation, I'm definitely not convinced that anything other=
than codepoint comparison should be allowed. The motivation of the
> ...

+1000


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

--f46d0401fb954e2f0b04ceb41ebe-- From paul.hoffman@vpnc.org Sat Nov 17 10:19: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 1912321F841D for ; Sat, 17 Nov 2012 10:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 hReHV3Oq17gy for ; Sat, 17 Nov 2012 10:18:59 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A76BE21F8805 for ; Sat, 17 Nov 2012 10:18:58 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAHIIttr050970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Nov 2012 11:18:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Sat, 17 Nov 2012 10:18:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2586828B-7715-4D8D-A6DB-49EBB8154677@vpnc.org> References: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> <20121116162715.GA90582@mx1.yitter.info> <50A77AC2.3070800@gmx.de> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1499) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 17 Nov 2012 18:19:00 -0000 On Nov 17, 2012, at 9:21 AM, Murray S. Kucherawy = wrote: > This may be an ignorant question, but is this really something about = which JSON pointer/patch needs to worry? It seems to me that this is a = property of JSON, so any semantics about key equality that exist are = defined in there, and we shouldn't be adding any here. Blame Cyrus. :-) So far, it seems like most people don't want this in = the document. --Paul Hoffman= From cyrus@daboo.name Sat Nov 17 18: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 1A07021F85FC for ; Sat, 17 Nov 2012 18:41:04 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMFgX+SGoXAQ for ; Sat, 17 Nov 2012 18:41:03 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2D18821F84D4 for ; Sat, 17 Nov 2012 18:41:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 4086635936C1; Sat, 17 Nov 2012 21:41:01 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPo1wBgtSAeV; Sat, 17 Nov 2012 21:41:00 -0500 (EST) Received: from [10.0.1.10] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 1D78735936B7; Sat, 17 Nov 2012 21:40:59 -0500 (EST) Date: Sat, 17 Nov 2012 21:41:00 -0500 From: Cyrus Daboo To: "Murray S. Kucherawy" , Julian Reschke Message-ID: <0D25A11DA5E7C04FE3474C94@cyrus.local> In-Reply-To: References: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> <20121116162715.GA90582@mx1.yitter.info> <50A77AC2.3070800@gmx.de> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=761 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 18 Nov 2012 02:41:04 -0000 Hi Murray, --On November 17, 2012 9:21:44 AM -0800 "Murray S. Kucherawy"=20 wrote: > This may be an ignorant question, but is this really something about > which JSON pointer/patch needs to worry?=C2=A0 It seems to me that this = is a > property of JSON, so any semantics about key equality that exist are > defined in there, and we shouldn't be adding any here. No we are not talking about the keys (object member names) but rather=20 actual string values which can come from any arbitrary source with its own=20 choice of unicode normalization. Actually the base spec 4627 says nothing about string comparison or=20 normalization as it applies to either string values or "key" names. Just a=20 statement of fact - no need to act... --=20 Cyrus Daboo From cyrus@daboo.name Sat Nov 17 19:27:55 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 CFE0321F84EE for ; Sat, 17 Nov 2012 19:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 l-3FTnSYLYY9 for ; Sat, 17 Nov 2012 19:27:55 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAD821F84DE for ; Sat, 17 Nov 2012 19:27:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 777F135940EF; Sat, 17 Nov 2012 22:27:54 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S31HstqEs3tR; Sat, 17 Nov 2012 22:27:51 -0500 (EST) Received: from [10.0.1.10] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 3E65035940E2; Sat, 17 Nov 2012 22:27:50 -0500 (EST) Date: Sat, 17 Nov 2012 22:27:57 -0500 From: Cyrus Daboo To: Paul Hoffman , "Murray S. Kucherawy" Message-ID: In-Reply-To: <2586828B-7715-4D8D-A6DB-49EBB8154677@vpnc.org> References: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> <20121116162715.GA90582@mx1.yitter.info> <50A77AC2.3070800@gmx.de> <2586828B-7715-4D8D-A6DB-49EBB8154677@vpnc.org> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1068 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 18 Nov 2012 03:27:55 -0000 Hi Paul, --On November 17, 2012 10:18:57 AM -0800 Paul Hoffman wrote: >> This may be an ignorant question, but is this really something about >> which JSON pointer/patch needs to worry? It seems to me that this is a >> property of JSON, so any semantics about key equality that exist are >> defined in there, and we shouldn't be adding any here. > > Blame Cyrus. :-) So far, it seems like most people don't want this in the > document. Occasionally it is fun to be a trouble maker :-) Anyway, my position is this: I am OK with the way the current comparison is defined in the spec. However, I am concerned that that an implementor may fail to appreciate that normalization could be a problem (and really it could). As I suggested before, all I am really after is some text that clarifies the current state - namely that implementations should make sure no normalization is done on string values from the original document when re-used in a test. But if no one thinks that adds anything - then we can leave it be. -- Cyrus Daboo From bradfitz@google.com Sat Nov 17 17:51: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 1848A21F869B for ; Sat, 17 Nov 2012 17:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.449, 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 rY2NthA2fWB2 for ; Sat, 17 Nov 2012 17:51:05 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 200F521F86AB for ; Sat, 17 Nov 2012 17:51:05 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so4188258obb.31 for ; Sat, 17 Nov 2012 17:51:04 -0800 (PST) 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; bh=8ddcpLmFZ9uk3+nMsNEmfS6f4U7wXYXEkZ4nlF99a6Q=; b=SjNfmhiePL8XgzkPEEkt3bYZAiMZHk77qbJ9oqj4dlUHMd78PjSfKK/Qmr5ouoCNFe 9eTy0bQdEzEgMfi6vIcv9BhyVezOggZd5p9XeHF43gSqvoZgbgBsqeHcS5Ruy6kA5RBo PSSVp6fQYc3/c87IzT8U9u01KnEks9o4TfoG84S7gl5OVAKnl4LmRbxvBmTg3CqE9NW/ Cp5xIqLM8IHP6KU/C9V5ynbyZ7zBmAlmLL0y5QjdOKIuUkOZk8R+xjaEVY6/nuYRzAl0 1JqvdkuQ/b6o8hdpEXYjOQXFC9fJVrUSiYwP7F5yiT6PsJObeKsvkVkWPaJPQ5xGLkbb jkrQ== 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=8ddcpLmFZ9uk3+nMsNEmfS6f4U7wXYXEkZ4nlF99a6Q=; b=SmKK9ztzVP/nFa+RkcVSK8yG7WFznwbSngBovOm9EWSytCzMOjkEQn8I/KOOWSMSkm hC3FRMmzcjQrwS0nmVFIW1uOv+DIdThkaH4NBgXXEZzwK7ftXhfJ5mGG4D9ovlt+c9uH HVYKkTVBo8mVNUS7CVUR54GGjK6RZk8NHdbWW3O20cmV0qbBw+jfJCGnsggycBhBPj+I AtpNpwPvUj+AtKYjdceZD98O0ixPaCH5omutWMB3k6USeIqofMGbg38mBrJqXkVxI2o3 uqgrOiY37TdBrobFwb9lykl6PxyE+t/Kilcc6GqzZS3iXyVe97tHBfwpzVMYHHzL+Plm BCMA== MIME-Version: 1.0 Received: by 10.182.146.107 with SMTP id tb11mr7391486obb.30.1353203464662; Sat, 17 Nov 2012 17:51:04 -0800 (PST) Received: by 10.60.31.41 with HTTP; Sat, 17 Nov 2012 17:51:04 -0800 (PST) In-Reply-To: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> Date: Sat, 17 Nov 2012 17:51:04 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d04447fb1d1ee7704cebb3b4c X-Gm-Message-State: ALoCoQnp3Ie4Upg61wTnMTWi4nf+WKMLzeGXurbPZROJCBqWhss+RkFqp6yA7Tjd3/lfckmKhzI2Hq5u9hh4qXB+oaoC1oDfjh5p3Seb7YHCwxBbBdBX4jHRqGCzxY9YT6cCLut+An8IJUg6Q8szaDcwzokzCu0DsjCw7jzzI0N9tR0VxbVdiOph3mJLXQ3jaUbRvuSGj+bY X-Mailman-Approved-At: Sun, 18 Nov 2012 08:07:40 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Sun, 18 Nov 2012 01:51:06 -0000 --f46d04447fb1d1ee7704cebb3b4c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is wonderful. Thank you! Some comments, all minor: are the rels in the non-normative section 4.1 and 4.2 real? (i.e. avatar, profile-page, blog, smtp-server) like it or not, people will use them if they're not. the HTTPS-to-HTTP safeguards in section 5.1 look useless. what are you trying to protect? I would just say MUST use https first, MAY fall back to http, servers SHOULD serve on https, MAY serve on http, clients SHOULD NOT trust anything for anything important not over https. (certainly some things I can imagine being valid over http=E2=80=A6 but not tons) But all = the stuff about clients dealing with 4xx vs 5xx vs 2xx vs TCP connection failures seems useless. A MITM could just force https connection errors and hide any 4xx / 5xx anyway. section 5.3, "rel" parameter: the example with a URL rel as well as a token rel might lead to confusion on whether the client's rel query is an exact match or a substring match. Maybe worth clarifying. section 5.4: love it. section 6: I've tripped over reading this section a few times now in different drafts. I don't like the MUST sentence (starting with "Specifically, all =E2=80=A6") when that sentence alone is not a MUST. The= intent of the sentence is that it's only a MUST if the previous sentence is true ("intended for public consumption"). And "MUST support CORS" doesn't clarify what "support" means--- having the header vs having the header with an open "*" policy. I would rephrase the whole thing like: "WebFinger is most useful when it is accessible without restrictions on the Internet, including web browsers. Therefore, when serving content intended for public consumption, WebFinger servers MUST advertise a public Cross-Origin Resource Sharing (CORS) header. Specifically, public responses MUST include the following HTTP header:" section 7: I might also note that despite the "avatar" and "blog" examples above, it's not assumed that people would put their personal information (social networking-related or otherwise) into their WebFinger document. Rather, for social networking applications, it's assumed that WebFinger will merely contain pointers to other servers which then require auth. WebFinger exists just to bootstrap that discovery, and not to disseminate personal information itself. section 9: oh wait, this is much like section 7. can we merge these two sections a bit? On Fri, Nov 16, 2012 at 8:18 PM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > I published a new -03 version of the WebFinger draft. I made substantial > changes throughout the document, with changes in nearly every section. T= he > changes should be in line with the views of the group and, most notably, > gets rid of everything related to XRD, introduces a new > /.well-known/webfinger resource, and species the default format to be JRD= . > **** > > ** ** > > Dependencies on RFC 6415 are removed, except for the reference to the JRD > document itself.**** > > ** ** > > I know there was a request for more =E2=80=9Creal-world=E2=80=9D examples= . Mike was going > to provide one, but I certainly welcome others if you think it might be > useful. I tried to make use of most JRD features so that developers woul= d > see at least one example.**** > > ** ** > > I did find one error right after publishing the draft. In the example > near the bottom of page 4, the word =E2=80=9Cproperties=E2=80=9D should b= e =E2=80=9Ctitles=E2=80=9D in the > JRD. I used two different languages to illustrate how to add a title to = a > link.**** > > ** ** > > Your comments are certainly welcome!**** > > ** ** > > Paul**** > > ** ** > --f46d04447fb1d1ee7704cebb3b4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
T= his is wonderful. =C2=A0Thank you!

Some comments, all mi= nor:

are the rels in the non-normative sectio= n 4.1 and 4.2 real? (i.e. avatar, profile-page, blog, smtp-server) =C2=A0li= ke it or not, people will use them if they're not.

the HTTPS-to-HTTP safeguards in section 5.1 look useles= s. =C2=A0what are you trying to protect? =C2=A0I would just say MUST use ht= tps first, MAY fall back to http, servers SHOULD serve on https, MAY serve = on http, clients SHOULD NOT trust anything for anything important not over = https. =C2=A0(certainly some things I can imagine being valid over http=E2= =80=A6 but not tons) =C2=A0But all the stuff about clients dealing with 4xx= vs 5xx vs 2xx vs TCP connection failures seems useless. =C2=A0A MITM could= just force https connection errors and hide any 4xx / 5xx anyway.

section 5.3, "rel" parameter: the example wit= h a URL rel as well as a token rel might lead to confusion on whether the c= lient's rel query is an exact match or a substring match. =C2=A0Maybe w= orth clarifying.

section 5.4: love it.

section = 6: I've tripped over reading this section a few times now in different = drafts. =C2=A0I don't like the MUST sentence (starting with "Speci= fically, all =E2=80=A6") when that sentence alone is not a MUST. =C2= =A0The intent of the sentence is that it's only a MUST if the previous = sentence is true ("intended for public consumption"). =C2=A0And &= quot;MUST support CORS" doesn't clarify what "support" m= eans--- having the header vs having the header with an open "*" p= olicy. =C2=A0I would rephrase the whole thing like:

=C2=A0 =C2=A0"WebFinger is most useful when it is = accessible without restrictions on the Internet, including web browsers. Th= erefore, when serving content intended for public consumption, WebFinger se= rvers MUST advertise a public Cross-Origin Resource Sharing (CORS) header. = =C2=A0Specifically, public responses MUST include the following HTTP header= :"

section 7: I might also note that despite the "ava= tar" and "blog" examples above, it's not assumed that pe= ople would put their personal information (social networking-related or oth= erwise) into their WebFinger document. =C2=A0Rather, for social networking = applications, it's assumed that WebFinger will merely contain pointers = to other servers which then require auth. =C2=A0WebFinger exists just to bo= otstrap that discovery, and not to disseminate personal information itself.=

section 9: oh wait, this is much like section 7. =C2=A0= can we merge these two sections a bit?


On Fri, Nov 16, 2012 at 8:18 PM, Paul E. Jones <pau= lej@packetizer.com> wrote:

Folks,

=C2=A0

I published a new -03 version of the WebFinger draft= .=C2=A0 I made substantial changes throughout the document, with changes in= nearly every section.=C2=A0 The changes should be in line with the views o= f the group and, most notably, gets rid of everything related to XRD, intro= duces a new /.well-known/webfinger resource, and species the default format= to be JRD.

=C2=A0

Depen= dencies on RFC 6415 are removed, except for the reference to the JRD docume= nt itself.

=C2=A0

=

I know there was a request for more =E2=80=9Creal-world=E2=80=9D examples.= =C2=A0 Mike was going to provide one, but I certainly welcome others if you= think it might be useful. =C2=A0I tried to make use of most JRD features s= o that developers would see at least one example.

=C2=A0

I did= find one error right after publishing the draft.=C2=A0 In the example near= the bottom of page 4, the word =E2=80=9Cproperties=E2=80=9D should be =E2= =80=9Ctitles=E2=80=9D in the JRD.=C2=A0 I used two different languages to i= llustrate how to add a title to a link.

=C2=A0

Your = comments are certainly welcome!

=C2=A0

Paul

=C2=A0


--f46d04447fb1d1ee7704cebb3b4c-- From dick.hardt@gmail.com Sat Nov 17 18:14: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 F228A21F84F3 for ; Sat, 17 Nov 2012 18:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.829 X-Spam-Level: X-Spam-Status: No, score=-3.829 tagged_above=-999 required=5 tests=[AWL=-0.231, 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 pGWIjA386bLQ for ; Sat, 17 Nov 2012 18:14:37 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 77D9A21F84DE for ; Sat, 17 Nov 2012 18:14:37 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so739977pad.31 for ; Sat, 17 Nov 2012 18:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=D8ThRz3YTcXQlJpmnhyRyl41g3oRmugAkccaqWgLnk4=; b=wmWncum6j1SRES+pbpTGKFLh3NzYDvRlN9Ao46mhdHtk96LtqCFLcxjqfHyVgD5sN8 NuDzm+2wbBHRtySCwDG8oPANyfHaNpYIO+Rx3my5q78IGvfvDPIX/tUVHTkwPV17Us6V xCrMbn2wqi5NRFIUYBNTQqZY7qj3vQNJXXe5MquGbMgtPB7XeMp/TwK00NyrfYXCu6po LD6Wlu0Cm7I68M42i3KQGLY1U6bj2G7oxbK14MzY9yUSxKCfrOYKK+RUG92cLbZUmnlU poDaBDqObWlhrKu8eXJLt4/wWMyyfGorolj2RZjWgBCDFkBCNHppDi2Pds1GcRs4vS/H KhoA== Received: by 10.68.137.228 with SMTP id ql4mr22708048pbb.125.1353204877054; Sat, 17 Nov 2012 18:14:37 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id na4sm3741895pbc.18.2012.11.17.18.14.28 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Nov 2012 18:14:31 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F1FD3933-AF65-4105-BC3B-FA3BA768898F" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Sat, 17 Nov 2012 18:14:26 -0800 Message-Id: <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Sun, 18 Nov 2012 08:07:52 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Sun, 18 Nov 2012 02:14:39 -0000 --Apple-Mail=_F1FD3933-AF65-4105-BC3B-FA3BA768898F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I agree with Brad, this is a great improvement! Thanks Paul! A few comments on Brad's comments and a couple extras. There are a number of other standards based nits, but I would suggest = let's get the issues below dealt with and then can dig into nits. On Nov 17, 2012, at 5:51 PM, Brad Fitzpatrick = wrote: > This is wonderful. Thank you! >=20 > Some comments, all minor: >=20 > are the rels in the non-normative section 4.1 and 4.2 real? (i.e. = avatar, profile-page, blog, smtp-server) like it or not, people will = use them if they're not. Let's get clear on what these are. Is "rel" : = "http://packetizer.com/rel/blog" really going to be the standard way to = query for a blog? >=20 > the HTTPS-to-HTTP safeguards in section 5.1 look useless. what are = you trying to protect? I would just say MUST use https first, MAY fall = back to http, servers SHOULD serve on https, MAY serve on http, clients = SHOULD NOT trust anything for anything important not over https. = (certainly some things I can imagine being valid over http=85 but not = tons) But all the stuff about clients dealing with 4xx vs 5xx vs 2xx vs = TCP connection failures seems useless. A MITM could just force https = connection errors and hide any 4xx / 5xx anyway. +1 5.2 Why is there a preferred order for the JSON? That seems weird, and = difficult to do if you are serving dynamically and using an object->JSON = library to output the JSON. > section 7: I might also note that despite the "avatar" and "blog" = examples above, it's not assumed that people would put their personal = information (social networking-related or otherwise) into their = WebFinger document. Rather, for social networking applications, it's = assumed that WebFinger will merely contain pointers to other servers = which then require auth. WebFinger exists just to bootstrap that = discovery, and not to disseminate personal information itself. +1 >=20 > section 9: oh wait, this is much like section 7. can we merge these = two sections a bit? These should stay separate. Security Considerations is a standard RFC = section. (7) is about Access Control. >=20 >=20 > On Fri, Nov 16, 2012 at 8:18 PM, Paul E. Jones = wrote: > Folks, >=20 > =20 >=20 > I published a new -03 version of the WebFinger draft. I made = substantial changes throughout the document, with changes in nearly = every section. The changes should be in line with the views of the = group and, most notably, gets rid of everything related to XRD, = introduces a new /.well-known/webfinger resource, and species the = default format to be JRD. >=20 > =20 >=20 > Dependencies on RFC 6415 are removed, except for the reference to the = JRD document itself. >=20 > =20 >=20 > I know there was a request for more =93real-world=94 examples. Mike = was going to provide one, but I certainly welcome others if you think it = might be useful. I tried to make use of most JRD features so that = developers would see at least one example. >=20 > =20 >=20 > I did find one error right after publishing the draft. In the example = near the bottom of page 4, the word =93properties=94 should be =93titles=94= in the JRD. I used two different languages to illustrate how to add a = title to a link. >=20 > =20 >=20 > Your comments are certainly welcome! >=20 > =20 >=20 > Paul >=20 > =20 >=20 >=20 --Apple-Mail=_F1FD3933-AF65-4105-BC3B-FA3BA768898F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = agree with Brad, this is a great improvement! Thanks = Paul!

A few comments on Brad's comments and a couple = extras.

There are a number of other standards = based nits, but I would suggest let's get the issues below dealt with = and then can dig into nits.

On Nov 17, 2012, at = 5:51 PM, Brad Fitzpatrick <bradfitz@google.com> = wrote:

This is wonderful.  Thank = you!

Some comments, all = minor:

are the rels in the non-normative = section 4.1 and 4.2 real? (i.e. avatar, profile-page, blog, smtp-server) =  like it or not, people will use them if they're = not.

Let's get clear = on what these are. Is "rel" : = "http://packetizer.com/rel/blog


the HTTPS-to-HTTP safeguards in section 5.1 look = useless.  what are you trying to protect?  I would just say = MUST use https first, MAY fall back to http, servers SHOULD serve on = https, MAY serve on http, clients SHOULD NOT trust anything for anything = important not over https.  (certainly some things I can imagine = being valid over http=85 but not tons)  But all the stuff about = clients dealing with 4xx vs 5xx vs 2xx vs TCP connection failures seems = useless.  A MITM could just force https connection errors and hide = any 4xx / 5xx = anyway.

+1
5.2

Why is there a preferred order = for the JSON? That seems weird, and difficult to do if you are serving = dynamically and using an object->JSON library to output the = JSON.

section 7: I might also note that despite the "avatar" and "blog" = examples above, it's not assumed that people would put their personal = information (social networking-related or otherwise) into their = WebFinger document.  Rather, for social networking applications, = it's assumed that WebFinger will merely contain pointers to other = servers which then require auth.  WebFinger exists just to = bootstrap that discovery, and not to disseminate personal information = itself.

+1


section 9: oh wait, this is much like section 7. =  can we merge these two sections a = bit?

These should stay = separate. Security Considerations is a standard RFC section. (7) is = about Access Control.



On Fri, Nov 16, = 2012 at 8:18 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

 

I = published a new -03 version of the WebFinger draft.  I made = substantial changes throughout the document, with changes in nearly = every section.  The changes should be in line with the views of the = group and, most notably, gets rid of everything related to XRD, = introduces a new /.well-known/webfinger resource, and species the = default format to be JRD.

 

Dependencies on RFC 6415 are removed, except for the = reference to the JRD document itself.

 

I know there was a request for more =93real-world=94 examples.  = Mike was going to provide one, but I certainly welcome others if you = think it might be useful.  I tried to make use of most JRD features = so that developers would see at least one example.

 

I did = find one error right after publishing the draft.  In the example = near the bottom of page 4, the word =93properties=94 should be =93titles=94= in the JRD.  I used two different languages to illustrate how to = add a title to a link.

 

Your = comments are certainly welcome!

 

Paul

 



= --Apple-Mail=_F1FD3933-AF65-4105-BC3B-FA3BA768898F-- From paulej@packetizer.com Sun Nov 18 13:35: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 4767D21F8542 for ; Sun, 18 Nov 2012 13:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.426, 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 UK-+fnUfJL+M for ; Sun, 18 Nov 2012 13:34:59 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BBCEA21F8538 for ; Sun, 18 Nov 2012 13:34:58 -0800 (PST) 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 qAILYu7V006477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 18 Nov 2012 16:34:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353274497; bh=sH+vMxGNuBR4ryYMAvuh0Xof7PR9zqIrbTZhztsFarc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=tnAQ2XIPoRcl8j2d4oscNLUDuOM8iJoUEqD3K0F66103/0UFc66QLTlAR03SiHiyR 5yLC6rWaqAS4jgCy5W3D4AS3UozNdIl7OFy5X4Oxpu9PWuKKD+sQyF7mxz6QHs74XM yqF5iH+Q1S+ULXucgbeu4Bzl60o/m4CinvzyyfeM= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" , References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> In-Reply-To: Date: Sun, 18 Nov 2012 16:35:03 -0500 Message-ID: <00ae01cdc5d4$9221f510$b665df30$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AF_01CDC5AA.A94D73B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI/YWaFkAYvx4DQsUUjuXKAy/yifQJJ+dZ9lvqFxIA= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Sun, 18 Nov 2012 21:35:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AF_01CDC5AA.A94D73B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brad, =20 Comments below: =20 =20 From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Brad Fitzpatrick Sent: Saturday, November 17, 2012 8:51 PM To: webfinger@googlegroups.com Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt =20 This is wonderful. Thank you! =20 Some comments, all minor: =20 are the rels in the non-normative section 4.1 and 4.2 real? (i.e. = avatar, profile-page, blog, smtp-server) like it or not, people will = use them if they're not. =20 PEJ: The first paragraph in section 4 says that the entire section is = non-normative (and I=E2=80=99ll make sentence more direct). Some of the = rels are =E2=80=9Creal=E2=80=9D in the sense that people do use them. = Some that look like they might defined, like =E2=80=9Cvcard=E2=80=9D, = are not defined. I think it=E2=80=99s important to show rel values that = are simple tokens and some that are URIs, but I=E2=80=99m not worried if = people use any of these. I doubt the printer example ever would be = defined, but the others likely would. Suggestions? =20 the HTTPS-to-HTTP safeguards in section 5.1 look useless. what are you = trying to protect? I would just say MUST use https first, MAY fall back = to http, servers SHOULD serve on https, MAY serve on http, clients = SHOULD NOT trust anything for anything important not over https. = (certainly some things I can imagine being valid over http=E2=80=A6 but = not tons) But all the stuff about clients dealing with 4xx vs 5xx vs = 2xx vs TCP connection failures seems useless. A MITM could just force = https connection errors and hide any 4xx / 5xx anyway. =20 PEJ: I tried to keep this simple. If a connection can be established = using HTTPS, use that. Only if a connection cannot be established = (e.g., there is nothing listening on 443), then use HTTP. The other = language is there only to prevent a client from trying HTTPS and then = HTTP, moving back and forth like a kid going to the mother and father = trying to get permission to do something ;-) =20 section 5.3, "rel" parameter: the example with a URL rel as well as a = token rel might lead to confusion on whether the client's rel query is = an exact match or a substring match. Maybe worth clarifying. =20 PEJ: OK.. I=E2=80=99ll try. =20 section 5.4: love it. =20 section 6: I've tripped over reading this section a few times now in = different drafts. I don't like the MUST sentence (starting with = "Specifically, all =E2=80=A6") when that sentence alone is not a MUST. = The intent of the sentence is that it's only a MUST if the previous = sentence is true ("intended for public consumption"). And "MUST support = CORS" doesn't clarify what "support" means--- having the header vs = having the header with an open "*" policy. I would rephrase the whole = thing like: =20 "WebFinger is most useful when it is accessible without restrictions = on the Internet, including web browsers. Therefore, when serving content = intended for public consumption, WebFinger servers MUST advertise a = public Cross-Origin Resource Sharing (CORS) header. Specifically, = public responses MUST include the following HTTP header:" =20 PEJ: I think we can simplify this even further. Here=E2=80=99s what I = propose: =20 WebFinger is most useful when it is accessible without restrictions on = the Internet, including web browsers. Therefore, WebFinger servers MUST = support Cross-Origin Resource Sharing (CORS) [10] by including the = following HTTP header in responses: =20 Access-Control-Allow-Origin: * =20 Enterprise WebFinger servers that wish to restrict access to information = from external entities SHOULD use a more restrictive = Access-Control-Allow-Origin header. =20 PEJ: That=E2=80=99s it=E2=80=A6 the whole section. One might argue that = the MUST and SHOULD contradict. However, there is a desire to allow = enterprise servers to be more restrictive. =20 section 7: I might also note that despite the "avatar" and "blog" = examples above, it's not assumed that people would put their personal = information (social networking-related or otherwise) into their = WebFinger document. Rather, for social networking applications, it's = assumed that WebFinger will merely contain pointers to other servers = which then require auth. WebFinger exists just to bootstrap that = discovery, and not to disseminate personal information itself. =20 PEJ: I=E2=80=99m one example of a person who did put info out there = directly. Few people will do that. Rather, it will be populated via = social networking sites (as you note), corporate directories, or = somewhere else. That said, what else do you want to add here, exactly? =20 section 9: oh wait, this is much like section 7. can we merge these two = sections a bit? =20 PEJ: Yeah, we can certainly do that. I=E2=80=99ll just move it. = I=E2=80=99m not sure how to merge it, though. I invite suggestions. :-) =20 Paul =20 On Fri, Nov 16, 2012 at 8:18 PM, Paul E. Jones = wrote: Folks, =20 I published a new -03 version of the WebFinger draft. I made = substantial changes throughout the document, with changes in nearly = every section. The changes should be in line with the views of the = group and, most notably, gets rid of everything related to XRD, = introduces a new /.well-known/webfinger resource, and species the = default format to be JRD. =20 Dependencies on RFC 6415 are removed, except for the reference to the = JRD document itself. =20 I know there was a request for more =E2=80=9Creal-world=E2=80=9D = examples. Mike was going to provide one, but I certainly welcome others = if you think it might be useful. I tried to make use of most JRD = features so that developers would see at least one example. =20 I did find one error right after publishing the draft. In the example = near the bottom of page 4, the word =E2=80=9Cproperties=E2=80=9D should = be =E2=80=9Ctitles=E2=80=9D in the JRD. I used two different languages = to illustrate how to add a title to a link. =20 Your comments are certainly welcome! =20 Paul =20 =20 ------=_NextPart_000_00AF_01CDC5AA.A94D73B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Brad,

 

Comments below:

 

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Brad Fitzpatrick
Sent: Saturday, November = 17, 2012 8:51 PM
To: webfinger@googlegroups.com
Cc: = apps-discuss@ietf.org
Subject: Re: [apps-discuss] New = draft-ietf-appsawg-webfinger-03.txt

 

This is = wonderful.  Thank you!

 

Some = comments, all minor:

 

are the rels = in the non-normative section 4.1 and 4.2 real? (i.e. avatar, = profile-page, blog, smtp-server)  like it or not, people will use = them if they're not.

 

PEJ: The first paragraph in section 4 says that the entire section = is non-normative (and I=E2=80=99ll make sentence more direct).=C2=A0 = Some of the rels are =E2=80=9Creal=E2=80=9D in the sense that people do = use them.=C2=A0=C2=A0 Some that look like they might defined,=C2=A0 like = =E2=80=9Cvcard=E2=80=9D, are not defined. =C2=A0I think it=E2=80=99s = important to show rel values that are simple tokens and some that are = URIs, but I=E2=80=99m not worried if people use any of these.=C2=A0 I = doubt the printer example ever would be defined, but the others likely = would.=C2=A0 Suggestions?

 

the = HTTPS-to-HTTP safeguards in section 5.1 look useless.  what are you = trying to protect?  I would just say MUST use https first, MAY fall = back to http, servers SHOULD serve on https, MAY serve on http, clients = SHOULD NOT trust anything for anything important not over https. =  (certainly some things I can imagine being valid over = http=E2=80=A6 but not tons)  But all the stuff about clients = dealing with 4xx vs 5xx vs 2xx vs TCP connection failures seems useless. =  A MITM could just force https connection errors and hide any 4xx / = 5xx anyway.

 

PEJ: I tried to keep this simple. If a connection can be = established using HTTPS, use that.=C2=A0 Only if a connection cannot be = established (e.g., there is nothing listening on 443), then use = HTTP.=C2=A0 The other language is there only to prevent a client from = trying HTTPS and then HTTP, moving back and forth like a kid going to = the mother and father trying to get permission to do something = ;-)

 

section 5.3, = "rel" parameter: the example with a URL rel as well as a token = rel might lead to confusion on whether the client's rel query is an = exact match or a substring match.  Maybe worth = clarifying.

 

PEJ: OK.. I=E2=80=99ll try.

 

section 5.4: = love it.

 

section 6: = I've tripped over reading this section a few times now in different = drafts.  I don't like the MUST sentence (starting with = "Specifically, all =E2=80=A6") when that sentence alone is not = a MUST.  The intent of the sentence is that it's only a MUST if the = previous sentence is true ("intended for public consumption"). =  And "MUST support CORS" doesn't clarify what = "support" means--- having the header vs having the header with = an open "*" policy.  I would rephrase the whole thing = like:

 

  =  "WebFinger is most useful when it is accessible without = restrictions on the Internet, including web browsers. Therefore, when = serving content intended for public consumption, WebFinger servers MUST = advertise a public Cross-Origin Resource Sharing (CORS) header. =  Specifically, public responses MUST include the following HTTP = header:"

 

PEJ: I think we can simplify this even further.=C2=A0 = Here=E2=80=99s what I propose:

 

WebFinger is most useful when it is accessible without restrictions = on the Internet, including web browsers.=C2=A0 Therefore, WebFinger = servers MUST support Cross-Origin Resource Sharing (CORS) [10] by = including the following HTTP header in = responses:

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Access-Control-Allow-Origin: = *

 

Enterprise WebFinger servers that wish to restrict access to = information from external entities SHOULD use a more restrictive = Access-Control-Allow-Origin header.

 

PEJ: That=E2=80=99s it=E2=80=A6 the whole section.=C2=A0 One might = argue that the MUST and SHOULD contradict. However, there is a desire to = allow enterprise servers to be more = restrictive.

 

section 7: I = might also note that despite the "avatar" and "blog" = examples above, it's not assumed that people would put their personal = information (social networking-related or otherwise) into their = WebFinger document.  Rather, for social networking applications, = it's assumed that WebFinger will merely contain pointers to other = servers which then require auth.  WebFinger exists just to = bootstrap that discovery, and not to disseminate personal information = itself.

 

PEJ: I=E2=80=99m one example of a person who did put info out there = directly. Few people will do that.=C2=A0 Rather, it will be populated = via social networking sites (as you note), corporate directories, or = somewhere else.=C2=A0 That said, what else do you want to add here, = exactly?

 

section 9: = oh wait, this is much like section 7.  can we merge these two = sections a bit?

 

PEJ: Yeah, we can certainly do that.=C2=A0 I=E2=80=99ll just move = it.=C2=A0 I=E2=80=99m not sure how to merge it, though.=C2=A0 I invite = suggestions. :-)

 

Paul

 

On Fri, Nov = 16, 2012 at 8:18 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

I published = a new -03 version of the WebFinger draft.  I made substantial = changes throughout the document, with changes in nearly every = section.  The changes should be in line with the views of the group = and, most notably, gets rid of everything related to XRD, introduces a = new /.well-known/webfinger resource, and species the default format to = be JRD.

 <= /o:p>

Dependencies= on RFC 6415 are removed, except for the reference to the JRD document = itself.

 <= /o:p>

I know = there was a request for more =E2=80=9Creal-world=E2=80=9D = examples.  Mike was going to provide one, but I certainly welcome = others if you think it might be useful.  I tried to make use of = most JRD features so that developers would see at least one = example.

 <= /o:p>

I did find = one error right after publishing the draft.  In the example near = the bottom of page 4, the word =E2=80=9Cproperties=E2=80=9D should be = =E2=80=9Ctitles=E2=80=9D in the JRD.  I used two different = languages to illustrate how to add a title to a link.

 <= /o:p>

Your = comments are certainly welcome!

 

Paul

 

 

------=_NextPart_000_00AF_01CDC5AA.A94D73B0-- From paulej@packetizer.com Sun Nov 18 13:40: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 1296421F846C for ; Sun, 18 Nov 2012 13:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.415, 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 JoTFycqsvVaD for ; Sun, 18 Nov 2012 13:40:18 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C8B2021F8459 for ; Sun, 18 Nov 2012 13:40:17 -0800 (PST) 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 qAILeFtF006753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 18 Nov 2012 16:40:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353274816; bh=9B1OQOBTiFDjohQMlVXvZsYTu1HqCaO3DJ+0g4U+NCU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=lT9jcFnNraPtNuvSeSo5v415rNOSjcJQFo5cXXKno1tskNiRWKDscCeuCcrnMrLKO H2AabXu4Lq+lJ6QHMNuFdBsb0yqR/NYp/X3wFmo/m3qjX37Wi1XM43BwEiq1KIvJaa CpyEKylXDObwFovz/ANTpjT9gnP5XrHX42zSYZXM= From: "Paul E. Jones" To: "'Dick Hardt'" , References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> In-Reply-To: <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> Date: Sun, 18 Nov 2012 16:40:22 -0500 Message-ID: <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BC_01CDC5AB.67A330C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI/YWaFkAYvx4DQsUUjuXKAy/yifQJJ+dZ9Ajy5+22W6LDvIA== Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Sun, 18 Nov 2012 21:40:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BC_01CDC5AB.67A330C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dick, Comments below: From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Dick Hardt Sent: Saturday, November 17, 2012 9:14 PM To: webfinger@googlegroups.com Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt I agree with Brad, this is a great improvement! Thanks Paul! A few comments on Brad's comments and a couple extras. There are a number of other standards based nits, but I would suggest let's get the issues below dealt with and then can dig into nits. On Nov 17, 2012, at 5:51 PM, Brad Fitzpatrick wrote: This is wonderful. Thank you! Some comments, all minor: are the rels in the non-normative section 4.1 and 4.2 real? (i.e. avatar, profile-page, blog, smtp-server) like it or not, people will use them if they're not. Let's get clear on what these are. Is "rel" : "http://packetizer.com/rel/blog" really going to be the standard way to query for a blog? PEJ: They could. The challenge is that we have no other URI type defined for this purpose. For the examples, we have a chicken and egg problem. the HTTPS-to-HTTP safeguards in section 5.1 look useless. what are you trying to protect? I would just say MUST use https first, MAY fall back to http, servers SHOULD serve on https, MAY serve on http, clients SHOULD NOT trust anything for anything important not over https. (certainly some things I can imagine being valid over http. but not tons) But all the stuff about clients dealing with 4xx vs 5xx vs 2xx vs TCP connection failures seems useless. A MITM could just force https connection errors and hide any 4xx / 5xx anyway. +1 5.2 Why is there a preferred order for the JSON? That seems weird, and difficult to do if you are serving dynamically and using an object->JSON library to output the JSON. section 7: I might also note that despite the "avatar" and "blog" examples above, it's not assumed that people would put their personal information (social networking-related or otherwise) into their WebFinger document. Rather, for social networking applications, it's assumed that WebFinger will merely contain pointers to other servers which then require auth. WebFinger exists just to bootstrap that discovery, and not to disseminate personal information itself. +1 section 9: oh wait, this is much like section 7. can we merge these two sections a bit? These should stay separate. Security Considerations is a standard RFC section. (7) is about Access Control. PEJ: What if we took section 7 and put all of the contents in as the second paragraph in 9? Would you like it there or prefer it separate? I have no strong preference. Paul ------=_NextPart_000_00BC_01CDC5AB.67A330C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dick,

 

Comments below:

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Dick Hardt
Sent: Saturday, November 17, = 2012 9:14 PM
To: webfinger@googlegroups.com
Cc: = apps-discuss@ietf.org
Subject: Re: [apps-discuss] New = draft-ietf-appsawg-webfinger-03.txt

 

I agree with = Brad, this is a great improvement! Thanks Paul!

 

A = few comments on Brad's comments and a couple = extras.

 

There are a number of other standards based nits, but = I would suggest let's get the issues below dealt with and then can dig = into nits.

 

On = Nov 17, 2012, at 5:51 PM, Brad Fitzpatrick <bradfitz@google.com> = wrote:



This is = wonderful.  Thank you!

 

Some = comments, all minor:

 

are the rels = in the non-normative section 4.1 and 4.2 real? (i.e. avatar, = profile-page, blog, smtp-server)  like it or not, people will use = them if they're not.

 

 

PEJ: They could.  The challenge is that we have no other URI = type defined for this purpose.  For the examples, we have a chicken = and egg problem.



 

PEJ: What if we took section 7 and put all of the contents in as = the second paragraph in 9?  Would you like it there or prefer it = separate?  I have no strong preference.

 

Paul

------=_NextPart_000_00BC_01CDC5AB.67A330C0-- From paulej@packetizer.com Sun Nov 18 14:02: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 3A7D621F8570 for ; Sun, 18 Nov 2012 14:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.405, 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 QOcwHMzlbF9n for ; Sun, 18 Nov 2012 14:02:40 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DA2DC21F8578 for ; Sun, 18 Nov 2012 14:02:39 -0800 (PST) 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 qAIM2bn5007711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 18 Nov 2012 17:02:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353276158; bh=Arv3YF/yv+kihmgboW1lGC7Ng9VOvrvASWxi3nKQZI0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=rAGBzwKicGz2I0gdYpxRBhT3u7LspgG1JYVa/AvlTYzwCjmWnCpWHZP0boL6mKiiJ vAN3Kos2CpPnPMvXxlFmpDN3jOT+9xhYIEb/b81u4z8WRI844zcas9kkFaOBlAm4hv MJ9PGgCb3xXq3nc65rVlWBZmLu5QKA/cfN1p8da8= From: "Paul E. Jones" To: "'Dick Hardt'" References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> In-Reply-To: <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> Date: Sun, 18 Nov 2012 17:02:44 -0500 Message-ID: <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E2_01CDC5AE.8793E390" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI/YWaFkAYvx4DQsUUjuXKAy/yifQJJ+dZ9Ajy5+20BY9p1VAJ+l/RslsmkJ1A= Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Sun, 18 Nov 2012 22:02:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E2_01CDC5AE.8793E390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dick, These should be separate drafts. I agree "blog" is good, but there are surely more. A lot of good ones are defined under webfinger.net, too. But I would really prefer to not slow down this draft with addition of link relation values. If somebody (you?) wants to start a WebFinger Link Relations document, I think it would be timely. Paul PEJ: They could. The challenge is that we have no other URI type defined for this purpose. For the examples, we have a chicken and egg problem. Let's define some then! This is the one area that is vague and IMHO is a barrier to adoption. What should the "rel" values be for items that I want to publish? If we don't spec the common ones, we will end up with several different identifiers for the same thing. Challenge of course is that getting agreement on schema is always fun, but better to have some that will be used that are not already defined. Need to add an IANA section for that of course. "blog" is a good one :) ------=_NextPart_000_00E2_01CDC5AE.8793E390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dick,

 

These should be separate drafts.  I agree “blog” is = good, but there are surely more.  A lot of good ones are defined = under webfinger.net, too.

 

But I would really prefer to not slow down this draft with addition = of link relation values.  If somebody (you?) wants to start a = WebFinger Link Relations document, I think it would be = timely.

 

Paul

 

 

PEJ: They could.  The challenge is that we have no other URI = type defined for this purpose.  For the examples, we have a chicken = and egg = problem.

 

Let's define some then! This is the one area that is = vague and IMHO is a barrier to adoption. What should the "rel" = values be for items that I want to publish? If we don't spec the common = ones, we will end up with several different identifiers for the same = thing. Challenge of course is that getting agreement on schema is always = fun, but better to have some that will be used that are not already = defined.

 

Need to add an IANA section for that of = course.

 

"blog" is a good one = :)



------=_NextPart_000_00E2_01CDC5AE.8793E390-- From paulej@packetizer.com Sun Nov 18 14:43: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 6A30321F842F for ; Sun, 18 Nov 2012 14:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.536 X-Spam-Level: X-Spam-Status: No, score=-1.536 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] 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 jqbKEijIBzOB for ; Sun, 18 Nov 2012 14:43:34 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DCB9C21F8427 for ; Sun, 18 Nov 2012 14:43:33 -0800 (PST) Received: from dyn-157.arid.us (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 qAIMhVpR009559 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 18 Nov 2012 17:43:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353278612; bh=kNXsJzxEIAYgIdjbSRf5x2wSOxTtpvwG8NeROWLkvxc=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=Z+bgI5irrYWlvsFAnycsrcyrFYpjKl/Rq63JSCSma8Y4Qr1nKjSC4B7Fm+kyEbZEJ WJWFzOM7tDnPfKVtQFiyZl1ddkkbdD9XHxzbpYoZT1tlYlubKvnGb15zTNhNcZY8fn ODfHemT0gt2+4t/2Nlz9oMe7qyRVnPxL77EU+Z58= User-Agent: K-9 Mail for Android In-Reply-To: <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----Q55A1IDZ5LQTTCGTL7727XW6CH1PSN" From: "Paul E. Jones" Date: Sun, 18 Nov 2012 17:43:29 -0500 To: Dick Hardt Message-ID: Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Sun, 18 Nov 2012 22:43:35 -0000 ------Q55A1IDZ5LQTTCGTL7727XW6CH1PSN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Dick, The first example is fairly meaningful in that most of the rels are in use. The vcard one is not, but I'd like to see that defined. I'd be OK with using the token 'blog' if we're going to agree on that. The second example does not use real values, but it is important in that it shows use of properties. The third example is important in that it related to non-humans. We are supposed to get one more example related to OpenID Connect, but that is not in there yet. Paul -------- Original Message -------- From: Dick Hardt Sent: Sun Nov 18 17:22:37 EST 2012 To: "Paul E. Jones" Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt Hi Paul I agree it should be separate drafts. I'd be willing to edit if there is interest. My interest in WebFinger is as a consumer much more than a publisher - so I don't feel I am a domain expert. Is it possible to have meaningful examples with existing "rel" values, or do we need to have some others defined to have meaningful examples? -- Dick On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" wrote: > Dick, > > These should be separate drafts. I agree “blog†is good, but there are surely more. A lot of good ones are defined under webfinger.net, too. > > But I would really prefer to not slow down this draft with addition of link relation values. If somebody (you?) wants to start a WebFinger Link Relations document, I think it would be timely. > > Paul > > > PEJ: They could. The challenge is that we have no other URI type defined for this purpose. For the examples, we have a chicken and egg problem. > > Let's define some then! This is the one area that is vague and IMHO is a barrier to adoption. What should the "rel" values be for items that I want to publish? If we don't spec the common ones, we will end up with several different identifiers for the same thing. Challenge of course is that getting agreement on schema is always fun, but better to have some that will be used that are not already defined. > > Need to add an IANA section for that of course. > > "blog" is a good one :) ------Q55A1IDZ5LQTTCGTL7727XW6CH1PSN Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dick,

The first example is fairly meaningful in that most of the rels are in use. The vcard one is not, but I'd like to see that defined. I'd be OK with using the token 'blog' if we're going to agree on that.

The second example does not use real values, but it is important in that it shows use of properties.

The third example is important in that it related to non-humans.

We are supposed to get one more example related to OpenID Connect, but that is not in there yet.

Paul

From: Dick Hardt <dick.hardt@gmail.com>
Sent: Sun Nov 18 17:22:37 EST 2012
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger@googlegroups.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

Hi Paul

I agree it should be separate drafts. I'd be willing to edit if there is interest. My interest in WebFinger is as a consumer much more than a publisher - so I don't feel I am a domain expert.

Is it possible to have meaningful examples with existing "rel" values, or do we need to have some others defined to have meaningful examples?

-- Dick


Dick,

 
These should be separate drafts.  I agree “blog†is good, but there are surely more.  A lot of good ones are defined under webfinger.net, too.

 
But I would really prefer to not slow down this draft with addition of link relation values.  If somebody (you?) wants to start a WebFinger Link Relations document, I think it would be timely.

 
Paul

 

 

PEJ: They could.  The challenge is that we have no other URI type defined for this purpose.  For! the examples, we have a chicken and egg problem.

 

Let's define some then! This is the one area that is vague and IMHO is a barrier to adoption. What should the "rel" values be for items that I want to publish? If we don't spec the common ones, we will end up with several different identifiers for the same thing. Challenge of course is that getting agreement on schema is always fun, but better to have some that will be used that are not already defined.

 

Need to add an IANA section ! for that of course.

 

"blog" is a good one :)


------Q55A1IDZ5LQTTCGTL7727XW6CH1PSN-- From gsalguei@cisco.com Sun Nov 18 18:34: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 DBD4221F84C4 for ; Sun, 18 Nov 2012 18:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.455 X-Spam-Level: X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 vF8Bq5QRXyet for ; Sun, 18 Nov 2012 18:34:10 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id D81EF21F846C for ; Sun, 18 Nov 2012 18:34:09 -0800 (PST) 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 qAJ2Y8b1006160 for ; Sun, 18 Nov 2012 21:34:08 -0500 (EST) Received: from rtp-gsalguei-8918.cisco.com (rtp-gsalguei-8918.cisco.com [10.116.132.57]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAJ2Y79W000521; Sun, 18 Nov 2012 21:34:07 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Gonzalo Salgueiro In-Reply-To: <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> Date: Sun, 18 Nov 2012 21:34:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <67A5328F-CBC6-4E8D-AF3E-A3673637FB34@cisco.com> References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> To: Dick Hardt X-Mailer: Apple Mail (2.1283) Cc: webfinger@googlegroups.com, General discussion of application-layer protocols Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Mon, 19 Nov 2012 02:34:11 -0000 Dick -=20 I made a commitment to the APPSAWG chairs that I'd take the acct link = relation (that we just removed from the latest Webfinger draft) and put = it into a separate draft. I think it makes a lot of sense to add that to = the effort proposed below of standardizing the set of useful link = relations for Webfinger. With that in mind, I'll offer to help merge = those parallel efforts and co-author such a document with you. Cheers, Gonzalo On Nov 18, 2012, at 5:22 PM, Dick Hardt wrote: > Hi Paul >=20 > I agree it should be separate drafts. I'd be willing to edit if there = is interest. My interest in WebFinger is as a consumer much more than a = publisher - so I don't feel I am a domain expert. >=20 > Is it possible to have meaningful examples with existing "rel" values, = or do we need to have some others defined to have meaningful examples? >=20 > -- Dick >=20 > On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" = wrote: >=20 >> Dick, >> =20 >> These should be separate drafts. I agree =93blog=94 is good, but = there are surely more. A lot of good ones are defined under = webfinger.net, too. >> =20 >> But I would really prefer to not slow down this draft with addition = of link relation values. If somebody (you?) wants to start a WebFinger = Link Relations document, I think it would be timely. >> =20 >> Paul >> =20 >> =20 >> PEJ: They could. The challenge is that we have no other URI type = defined for this purpose. For the examples, we have a chicken and egg = problem. >> =20 >> Let's define some then! This is the one area that is vague and IMHO = is a barrier to adoption. What should the "rel" values be for items that = I want to publish? If we don't spec the common ones, we will end up with = several different identifiers for the same thing. Challenge of course is = that getting agreement on schema is always fun, but better to have some = that will be used that are not already defined. >> =20 >> Need to add an IANA section for that of course. >> =20 >> "blog" is a good one :) >=20 From mnot@mnot.net Sun Nov 18 23:01: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 C7CEE21F8459 for ; Sun, 18 Nov 2012 23:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.502 X-Spam-Level: X-Spam-Status: No, score=-104.502 tagged_above=-999 required=5 tests=[AWL=-1.903, 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 bZhMKNYWB5EE for ; Sun, 18 Nov 2012 23:01:47 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id B913821F86F3 for ; Sun, 18 Nov 2012 23:01:46 -0800 (PST) Received: from [192.168.1.75] (unknown [118.209.151.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CD96222E253; Mon, 19 Nov 2012 02:01:31 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> Date: Mon, 19 Nov 2012 18:01:30 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E1A9A62-5777-4D49-AA67-9BF900293D0A@mnot.net> <6E4F9BC8BAC9530B87773C14@caldav.corp.apple.com> To: Cyrus Daboo X-Mailer: Apple Mail (2.1499) Cc: Apps Discuss Subject: Re: [apps-discuss] WGLC review: draft-ietf-appsawg-json-patch-06 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, 19 Nov 2012 07:01:47 -0000 On 17/11/2012, at 2:55 AM, Cyrus Daboo wrote: > Hi Mark, >=20 > --On November 16, 2012 10:35:39 AM +1100 Mark Nottingham = wrote: >=20 >>> =A74.6 uses a very basic octet/code-point comparator. Do we care = about >>> possible unicode normalizations issues? If so that will need to be = dealt >>> with, if not there ought to be a clarifying statement - in fact an >>> "Internationalization Considerations" section may be warranted. >>=20 >> Urgh. >=20 > Advice from i18n "experts" on language would be good. My guess is it = might be sufficient to allow the patch-processing entity to normalize = the two strings being tested in some consistent manner for comparison, = rather than require "code point" equality. >=20 > Note: I guess the JSON base spec also has a similar issue in that it = talks about "names within an object SHOULD be unique" and names are = strings - so the question of string comparison/normalization comes up = there too. It sounds like we want to leave this one alone -- make sense? I could see adding a note of some sort warning people that = canonicalisation isn't done... >>> =A74.6 numbers - any concern about numeric precision affecting the >>> "subtracting one from another" behavior? >>=20 >> mumble. Any suggestion for a better way to specify? >=20 > "numerically equal" - anyone writing actual code to implement this = test will use "a =3D=3D b" rather than "a - b =3D=3D 0". So how about: >=20 > numbers: are considered equal if their values are numerically = equal. in SVN > Another point, you have this for the "string" test: >=20 > strings: are considered equal if, after unescaping any sequence(s) > in both strings starting with a reverse solidus, they contain the > same number of Unicode characters and their code points are > position-wise equal. >=20 > However, I believe the value of a string is the unescaped result of = processing a string "representation" in the JSON document, so your text = on unescaping is not needed, and arguably it could cause someone to = incorrectly "double unescape" a string representation, if they don't pay = close attention. So I would prefer the following: >=20 > strings: are considered equal if they contain the same number of > Unicode characters and their code points are position-wise equal. in SVN. I think we have a bit more cleaning up to do WRT Henry's = comments, to make it clear what we're operating upon. Cheers and thanks again, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Sun Nov 18 23:07: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 9D07221F86E2 for ; Sun, 18 Nov 2012 23:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.457 X-Spam-Level: X-Spam-Status: No, score=-104.457 tagged_above=-999 required=5 tests=[AWL=-1.858, 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 vCHMbUd6E1vN for ; Sun, 18 Nov 2012 23:07:20 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA6421F85EB for ; Sun, 18 Nov 2012 23:07:20 -0800 (PST) Received: from [192.168.1.75] (unknown [118.209.151.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9F47722E200; Mon, 19 Nov 2012 02:07:12 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Mon, 19 Nov 2012 18:07:12 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <7B79A6AC-B355-4828-9DBE-2AA99A0DC498@mnot.net> References: <6.2.5.6.2.20121115152250.09ffa450@elandnews.com> To: Henry S. Thompson X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Appsdir review of draft-ietf-appsawg-json-patch-06 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, 19 Nov 2012 07:07:21 -0000 It does, but that isn't the intent, and I think many people would find = that result extremely surprising. The result of ex 1 should be: [ { "key": "apples", "status": "ripe", "count": 3 }, { "key": "apples", "status": "green", "count": 4 } ] I.e., array references are zero-based, and members are replaced, not = repeated, when added to. On 16/11/2012, at 10:22 PM, Henry S. Thompson wrote: > Mark Nottingham writes: >=20 >>>> 3) I take it you also need to say that if an _existing_ member of = an >>>> object is referenced, that's not an error (note that it _is_ a >>>> JSON Pointer error), and the result is to increase the number of >>>> such members by one, with the new value. >>>=20 >>> I think that'll be the outcome of #1 above, yes. >>=20 >> Sorry, replay that? If an existing member of an object is referenced, = that member will be replaced... >=20 > What? If 'add' adds an additional member, and 'move' is 'remove' plus > 'add', then 'move' adds, not replaces. >=20 > Concrete examples: >=20 > Target document: > [ { "key": "apples", "status": "ripe", "count": 3 }, > { "key": "apples", "status": "green", "count": 10 } ] >=20 > Ex 1 > Patch: [ { "op": "add", "path": "/1/count", "value": 4 } ] > Result: > [ { "key": "apples", "status": "ripe", "count": 3, "count": 4 = }, > { "key": "apples", "status": "green", "count": 10 } ] >=20 > Ex 2 >=20 > Patch: [ { "op": "move", "from": "/2/count", "path": "/1/count" } ] > Result: > [ { "key": "apples", "status": "ripe", "count": 3, "count": 10 = }, > { "key": "apples", "status": "green" } ] >=20 > Does this clarify? >=20 > ht > --=20 > Henry S. Thompson, School of Informatics, University of = Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 = 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is = forged spam] -- Mark Nottingham http://www.mnot.net/ From masinter@adobe.com Mon Nov 19 00:53: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 AA65121F8533 for ; Mon, 19 Nov 2012 00:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.066 X-Spam-Level: X-Spam-Status: No, score=-105.066 tagged_above=-999 required=5 tests=[AWL=1.534, 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 lNfMmCYEhBYr for ; Mon, 19 Nov 2012 00:53:36 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 18ED421F850E for ; Mon, 19 Nov 2012 00:53:36 -0800 (PST) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUKnzi74wOWXNYsMZlQbRxSjek9Gx88nm@postini.com; Mon, 19 Nov 2012 00:53:36 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qAJ8oe1v028468; Mon, 19 Nov 2012 00:50:40 -0800 (PST) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id qAJ8rSXL007672; Mon, 19 Nov 2012 00:53:28 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Mon, 19 Nov 2012 00:53:27 -0800 From: Larry Masinter To: "Joe Hildebrand (jhildebr)" , John Bradley , Peter Saint-Andre Date: Mon, 19 Nov 2012 00:53:25 -0800 Thread-Topic: [apps-discuss] open issues with acct-uri spec Thread-Index: AQHNvB0qnaWn81ttYUOZuQjiNp3TcZfc2HUAgBQSHcA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Graham Klyne' , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 19 Nov 2012 08:53:36 -0000 Joe Hildebrand (jhildebr) wrote Tuesday, November 06, 2012 5:10 AM > If there's a port, you have to specify a protocol, in which case acct: > doesn't make sense to me. I see quite a bit of discussion about URI scheme guidelines. RFC 4395 really needs updating. This kind of advice SHOULD be in the BCP fo= r guidelines for new URI schemes:=20 You have to decide whether the scheme is protocol based (in which it really= is tied to the protocol whether http, ftp, imap .. and has port and can ha= ve an IPv6 or IPv4 address) Or it is *Not* protocol based and no port is needed, like mailto (with a ho= st name but no port and no raw addresses) or tel:,mid:, cid: with no host = name at all. However, I think the update of RFC 4395 was taken up by the IRI working gro= up which had little attention on it.=20 http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg-04 expired. Actua= lly, quite a bit got re-written, but I don't remember any review comments. http://tools.ietf.org/rfcdiff?url1=3Drfc4395&url2=3Ddraft-ietf-iri-4395bis-= irireg-04.txt Now, if apps-discuss is willing to put so much energy into a single URI sch= eme definition, perhaps some energy could be put into updating the guidelin= es. Maybe someone who hasn't been working on this topic for 20 years could find= more energy to work on an update? Larry From duerst@it.aoyama.ac.jp Mon Nov 19 01:01: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 65A0621F842F for ; Mon, 19 Nov 2012 01:01:06 -0800 (PST) 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=1.219, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 VWWvwXXGBHuw for ; Mon, 19 Nov 2012 01:01:05 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 68AC121F8446 for ; Mon, 19 Nov 2012 01:01:05 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id qAJ90rLr012716 for ; Mon, 19 Nov 2012 18:00:53 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 78a7_9698_9f4313a4_3227_11e2_9f7b_001d096c566a; Mon, 19 Nov 2012 18:00:52 +0900 Received: from [IPv6:::1] ([133.2.210.1]:35082) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 19 Nov 2012 18:00:54 +0900 Message-ID: <50A9F543.2040405@it.aoyama.ac.jp> Date: Mon, 19 Nov 2012 18:00:51 +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: Larry Masinter References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 19 Nov 2012 09:01:06 -0000 Hello Larry, On 2012/11/19 17:53, Larry Masinter wrote: > > Joe Hildebrand (jhildebr) wrote Tuesday, November 06, 2012 5:10 AM >> If there's a port, you have to specify a protocol, in which case acct: >> doesn't make sense to me. > > I see quite a bit of discussion about URI scheme guidelines. > However, I think the update of RFC 4395 was taken up by the IRI working group which had little attention on it. > > http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg-04 expired. Actually, quite a bit got re-written, but I don't remember any review comments. > http://tools.ietf.org/rfcdiff?url1=rfc4395&url2=draft-ietf-iri-4395bis-irireg-04.txt > > Now, if apps-discuss is willing to put so much energy into a single URI scheme definition, perhaps some energy could be put into updating the guidelines. > > Maybe someone who hasn't been working on this topic for 20 years could find more energy to work on an update? Is the XML at http://tools.ietf.org/id/draft-ietf-iri-4395bis-irireg-04.xml up to date, or is there a more up-to-date internal version? If not, can one of the authors who is in possession of the newest version commit it to the IRI WG svg repo or some other suitable location and announce where it's avaliable? I have added a new issues for this in the IRI WG tracker. Regards, Martin. P.S.: All this just to make sure things don't get dropped. From masinter@adobe.com Mon Nov 19 01:21: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 C7D8B21F849F for ; Mon, 19 Nov 2012 01:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-3.500, 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 kXI-wVQ2ykZJ for ; Mon, 19 Nov 2012 01:21:12 -0800 (PST) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id CA12E21F8466 for ; Mon, 19 Nov 2012 01:21:11 -0800 (PST) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUKn6APnCk0UIUYaL9E2EULyvWDTRyaPQ@postini.com; Mon, 19 Nov 2012 01:21:11 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qAJ9ID1v000805; Mon, 19 Nov 2012 01:18:14 -0800 (PST) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qAJ9L2Nc003208; Mon, 19 Nov 2012 01:21:03 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Mon, 19 Nov 2012 01:21:02 -0800 From: Larry Masinter To: John C Klensin , Ned Freed , Paul Hoffman Date: Mon, 19 Nov 2012 01:21:00 -0800 Thread-Topic: [apps-discuss] Solving the file format problem Thread-Index: Ac21ykMQ5RX4fb55QhqhzB6Ki+EwvwQavWbQ Message-ID: References: <9EAB966B-4B21-4CF9-BFEB-4DAD639FE81C@vpnc.org> <18D4E4AB-FE5D-4D66-A076-19BF81830845@vpnc.org> <01OLZ58XOQAE00008S@mauve.mrochek.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Solving the file format problem 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, 19 Nov 2012 09:21:12 -0000 I think there are problems with determining file format based on sniffing o= r depending on file extensions. So we don't have a way of naming file forma= ts that works for the applications the librarians want for understanding fi= le formats, or any standards or documented ways of determining file format = (if we had a way of naming file format) based on giving a file (an applicat= ion/octet-stream stream of data.) Now that MIMESNIFF is no longer in WebSe= c, http://mimesniff.spec.whatwg.org/ doesn't seem like it's going to answer= the question ... how do you tell? An underlying problem to the naming problem is that we don't have a good ex= planatory model of how file formats change and extend over time, so it's ha= rd to identify what we're naming (especially in a world where file formats = are described by versionless Living Standards). http://tools.ietf.org/html/rfc6709 looks at protocol extensions but from a = proscriptive "how to build extensible protocols well" point of view. And pr= otocols and file formats are both kinds of evolvable interfaces, but they e= volve differently. I started writing about file format evolution http://www.w3.org/2001/tag/20= 11/12/evolution/ but got bogged down; moving it to a Wiki http://www.w3.o= rg/wiki/Evolution only got spam. > >> > The fact that > >> > >> > ist_of_Places_Keeping_Track_of_Formats> does not list > >> > > >> > says something; I'm not sure who about, but I doubt it's > >> > good. From duerst@it.aoyama.ac.jp Mon Nov 19 01:34: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 8B3F421F8549 for ; Mon, 19 Nov 2012 01:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.627 X-Spam-Level: X-Spam-Status: No, score=-100.627 tagged_above=-999 required=5 tests=[AWL=-0.837, 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 WP3+CyzNJe8z for ; Mon, 19 Nov 2012 01:34:59 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id F10B421F853C for ; Mon, 19 Nov 2012 01:34:58 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id qAJ9YqpS010015 for ; Mon, 19 Nov 2012 18:34:52 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 55b6_d854_5eaa6e32_322c_11e2_b6ab_001d096c5782; Mon, 19 Nov 2012 18:34:51 +0900 Received: from [IPv6:::1] ([133.2.210.1]:36497) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 19 Nov 2012 18:34:53 +0900 Message-ID: <50A9FD3B.7090908@it.aoyama.ac.jp> Date: Mon, 19 Nov 2012 18:34:51 +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: "apps-discuss@ietf.org" References: <50A9F543.2040405@it.aoyama.ac.jp> In-Reply-To: <50A9F543.2040405@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] open issues with acct-uri spec 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, 19 Nov 2012 09:34:59 -0000 On 2012/11/19 18:00, "Martin J. Dürst" wrote: > Hello Larry, > > On 2012/11/19 17:53, Larry Masinter wrote: >> Now, if apps-discuss is willing to put so much energy into a single >> URI scheme definition, perhaps some energy could be put into updating >> the guidelines. >> >> Maybe someone who hasn't been working on this topic for 20 years could >> find more energy to work on an update? > > Is the XML at > http://tools.ietf.org/id/draft-ietf-iri-4395bis-irireg-04.xml > up to date, or is there a more up-to-date internal version? > If not, can one of the authors who is in possession of the newest > version commit it to the IRI WG svg repo or some other suitable location > and announce where it's avaliable? > > I have added a new issues for this in the IRI WG tracker. I had to wait for Larry's mail to show up in the archives to create the issue. It's now at http://trac.tools.ietf.org/wg/iri/trac/ticket/137. Regards, Martin. From ht@inf.ed.ac.uk Mon Nov 19 02:10: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 EA9D321F853C for ; Mon, 19 Nov 2012 02:10:35 -0800 (PST) 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 Od0i1kyPnM7Z for ; Mon, 19 Nov 2012 02:10:35 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 24CCA21F84D4 for ; Mon, 19 Nov 2012 02:10:34 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id qAJAAInW012528; Mon, 19 Nov 2012 10:10:23 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id qAJAAIvk032046; Mon, 19 Nov 2012 10:10:18 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id qAJAAIiY025967; Mon, 19 Nov 2012 10:10:18 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id qAJAAHjv025963; Mon, 19 Nov 2012 10:10:17 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Mark Nottingham References: <6.2.5.6.2.20121115152250.09ffa450@elandnews.com> <7B79A6AC-B355-4828-9DBE-2AA99A0DC498@mnot.net> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 19 Nov 2012 10:10:17 +0000 In-Reply-To: <7B79A6AC-B355-4828-9DBE-2AA99A0DC498@mnot.net> (Mark Nottingham's message of "Mon\, 19 Nov 2012 18\:07\:12 +1100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Appsdir review of draft-ietf-appsawg-json-patch-06 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, 19 Nov 2012 10:10:36 -0000 Mark Nottingham writes: > It does, but that isn't the intent, and I think many people would find that result extremely surprising. > > The result of ex 1 should be: > > [ { "key": "apples", "status": "ripe", "count": 3 }, > { "key": "apples", "status": "green", "count": 4 } ] > > I.e., array references are zero-based, and members are replaced, not repeated, when added to. Sorry for the array-base error, which just confuses things, but the 'add' text nowhere says that 'add' == 'replace' for existing members, and surely that's not obvious, given that 'add' very definitely does _not_ == 'replace' for existing array members. . . OTOH, I was just arguing for consistency, _not_ because I believe that constructing documents with multiple same-name object member settings was a good thing, so I'm happy if you clarify in 'add' that this does _not_ happen, and then we're back to a clean state if 'move' and 'copy' are defined in terms of 'add'. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From laurentwalter.goix@telecomitalia.it Mon Nov 19 03:07: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 1083721F8598 for ; Mon, 19 Nov 2012 03:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 6UmZjKG9N0jg for ; Mon, 19 Nov 2012 03:07:36 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id CE8D221F8557 for ; Mon, 19 Nov 2012 03:07:35 -0800 (PST) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Mon, 19 Nov 2012 12:07:33 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Mon, 19 Nov 2012 12:07:32 +0100 From: Goix Laurent Walter To: Gonzalo Salgueiro , Dick Hardt Date: Mon, 19 Nov 2012 12:07:30 +0100 Thread-Topic: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt Thread-Index: Ac3F/mB+hFyEH+89Tq+kMzZ8ntk1KgARy5AA Message-ID: References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> <67A5328F-CBC6-4E8D-AF3E-A3673637FB34@cisco.com> In-Reply-To: <67A5328F-CBC6-4E8D-AF3E-A3673637FB34@cisco.com> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "webfinger@googlegroups.com" , General discussion of application-layer protocols Subject: [apps-discuss] R: New draft-ietf-appsawg-webfinger-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: Mon, 19 Nov 2012 11:07:37 -0000 +1 for the suggestions on the link relations. I definitely think it would be valuable to start consider: - existing iana-registered link relations that can be useful with webfinger= . This could act as appendix to the draft - work on one or more separate drafts to register additional meaningful lin= k rels. I am thinking especially at the context of social networks (federat= ion) where most of the current most popular link rels are not yet registere= d (updates-from, avatar, etc) I'd be happy to help as well. walter > -----Messaggio originale----- > Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = Per > conto di Gonzalo Salgueiro > Inviato: luned=EC 19 novembre 2012 3.34 > A: Dick Hardt > Cc: webfinger@googlegroups.com; General discussion of application-layer > protocols > Oggetto: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt > > Dick - > > I made a commitment to the APPSAWG chairs that I'd take the acct link rel= ation > (that we just removed from the latest Webfinger draft) and put it into a > separate draft. I think it makes a lot of sense to add that to the effort > proposed below of standardizing the set of useful link relations for > Webfinger. With that in mind, I'll offer to help merge those parallel eff= orts > and co-author such a document with you. > > Cheers, > > Gonzalo > > On Nov 18, 2012, at 5:22 PM, Dick Hardt wrote: > > > Hi Paul > > > > I agree it should be separate drafts. I'd be willing to edit if there i= s > interest. My interest in WebFinger is as a consumer much more than a publ= isher > - so I don't feel I am a domain expert. > > > > Is it possible to have meaningful examples with existing "rel" values, = or do > we need to have some others defined to have meaningful examples? > > > > -- Dick > > > > On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" wr= ote: > > > >> Dick, > >> > >> These should be separate drafts. I agree "blog" is good, but there ar= e > surely more. A lot of good ones are defined under webfinger.net, too. > >> > >> But I would really prefer to not slow down this draft with addition of= link > relation values. If somebody (you?) wants to start a WebFinger Link Rela= tions > document, I think it would be timely. > >> > >> Paul > >> > >> > >> PEJ: They could. The challenge is that we have no other URI type defi= ned > for this purpose. For the examples, we have a chicken and egg problem. > >> > >> Let's define some then! This is the one area that is vague and IMHO is= a > barrier to adoption. What should the "rel" values be for items that I wan= t to > publish? If we don't spec the common ones, we will end up with several > different identifiers for the same thing. Challenge of course is that get= ting > agreement on schema is always fun, but better to have some that will be u= sed > that are not already defined. > >> > >> Need to add an IANA section for that of course. > >> > >> "blog" is a good one :) > > > > _______________________________________________ > 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. From laurentwalter.goix@telecomitalia.it Mon Nov 19 03:14: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 0791A21F84E0 for ; Mon, 19 Nov 2012 03:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.313 X-Spam-Level: X-Spam-Status: No, score=-1.313 tagged_above=-999 required=5 tests=[AWL=0.405, 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 6ozqaDnsF-BN for ; Mon, 19 Nov 2012 03:14:05 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 173E021F8473 for ; Mon, 19 Nov 2012 03:14:05 -0800 (PST) Content-Type: multipart/mixed; boundary="_84e7f75b-104f-4c58-b24d-7abb2def3d6d_" Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Mon, 19 Nov 2012 12:14:03 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Mon, 19 Nov 2012 12:14:02 +0100 From: Goix Laurent Walter To: "Paul E. Jones" , Dick Hardt Date: Mon, 19 Nov 2012 12:14:01 +0100 Thread-Topic: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt Thread-Index: Ac3F3iqaLzSeZ60gSHOqMjPvM8VjegAZ+qyA Message-ID: References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" Subject: [apps-discuss] R: New draft-ietf-appsawg-webfinger-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: Mon, 19 Nov 2012 11:14:07 -0000 --_84e7f75b-104f-4c58-b24d-7abb2def3d6d_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A5575514GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5575514GRFMBX704BA02_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VmVyeSBjbGVhbiBzcGVjIG5vdywgdGhhbmtzIHBhdWwgZm9yIHRoaXMgaHVnZSBjbGVhbnVwIQ0K DQppIGFsc28gYmVsaWV2ZSB0aGF0IHdlIHNob3VsZCBiZSBjYXJlZnVsIHdpdGggdGhlIGxpbmsg cmVscyBpbiB0aGUgZXhhbXBsZXMuIFdoZW5ldmVyIHRoZSBsaW5rIHJlbHMgbWVudGlvbmVkIGFy ZSB0b2tlbnMgYW5kIHRydWx5IGV4aXN0LCBJIHdvdWxkIHN1Z2dlc3QgdG8gcmVmZXJlbmNlIHRo ZSBzcGVjaWZpYyBzcGVjLiBpbiBvdGhlciBjYXNlcyB3ZSBjb3VsZCBlaXRoZXIgdXNlIHVyaXMg dW5kZXIgc29tZSBleGFtcGxlLm5ldCBuYW1lc3BhY2UsIG9yIHNpbXBseSBzdGF0ZSB0aGF0IHRo ZSB0b2tlbiB1c2VkIGlzIGZpY3RpdGlvdXMgYXQgdGhlIHRpbWUgb2Ygd3JpdGluZy4NCg0KU29t ZSBvdGhlciBtaW5vciBjb21tZW50czoNCg0KLSAgICAgICAgICBJbiBzZWN0aW9uIDMgSSBoYXZl IG5vdCBjbGVhciB0aGUgcHVycG9zZSBvZiB0aGUgZWR1Y2F0aW9uYWwgcGFyYWdyYXBoIG9uIGxp bmsgcmVscyBhbmQgdGhlIGVmZmVjdGl2ZSByZWxhdGlvbiB3aXRoIHdlYmZpbmdlciBiYXNlZCBv biB0aGUgY3VycmVudCB0ZXh0LiBDb3VsZCB3ZSByZW1vdmUgaXQ/DQoNCi0gICAgICAgICAgSW4g c2VjdGlvbiA0LjEgeW91IG1lbnRpb24g4oCcYW55IHZhbGlkIGFsaWFzIGZvciB0aGUgdXNlcuKA nS4gSXQgbWF5IGJlIGNsZWFuZXIgdG8gc3RhdGUg4oCcYW55IHZhbGlkIFVSSSBhcyBhbGlhcyBm b3IgdGhlIHVzZXLigJ0gdG8gZW1waGFzaXplIHRoZSB1c2FnZSBvZiB1cmlzDQoNCi0gICAgICAg ICAgSW4gc2VjdGlvbiA1LjIgSSB3b3VsZCBzdWdnZXN0IHRvIGludmVydCB0aGUg4oCcZXhwaXJl c+KAnSBhbmQg4oCcc3ViamVjdOKAnSBidWxsZXRzIHRvIG1lbnRpb24gcmVxdWlyZWQgZWxlbWVu dHMgZmlyc3QuDQoNCg0KRGE6IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBQYXVsIEUuIEpvbmVz DQpJbnZpYXRvOiBkb21lbmljYSAxOCBub3ZlbWJyZSAyMDEyIDIzLjQzDQpBOiBEaWNrIEhhcmR0 DQpDYzogd2ViZmluZ2VyQGdvb2dsZWdyb3Vwcy5jb207IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0K T2dnZXR0bzogUmU6IFthcHBzLWRpc2N1c3NdIE5ldyBkcmFmdC1pZXRmLWFwcHNhd2ctd2ViZmlu Z2VyLTAzLnR4dA0KDQpEaWNrLA0KDQpUaGUgZmlyc3QgZXhhbXBsZSBpcyBmYWlybHkgbWVhbmlu Z2Z1bCBpbiB0aGF0IG1vc3Qgb2YgdGhlIHJlbHMgYXJlIGluIHVzZS4gVGhlIHZjYXJkIG9uZSBp cyBub3QsIGJ1dCBJJ2QgbGlrZSB0byBzZWUgdGhhdCBkZWZpbmVkLiBJJ2QgYmUgT0sgd2l0aCB1 c2luZyB0aGUgdG9rZW4gJ2Jsb2cnIGlmIHdlJ3JlIGdvaW5nIHRvIGFncmVlIG9uIHRoYXQuDQoN ClRoZSBzZWNvbmQgZXhhbXBsZSBkb2VzIG5vdCB1c2UgcmVhbCB2YWx1ZXMsIGJ1dCBpdCBpcyBp bXBvcnRhbnQgaW4gdGhhdCBpdCBzaG93cyB1c2Ugb2YgcHJvcGVydGllcy4NCg0KVGhlIHRoaXJk IGV4YW1wbGUgaXMgaW1wb3J0YW50IGluIHRoYXQgaXQgcmVsYXRlZCB0byBub24taHVtYW5zLg0K DQpXZSBhcmUgc3VwcG9zZWQgdG8gZ2V0IG9uZSBtb3JlIGV4YW1wbGUgcmVsYXRlZCB0byBPcGVu SUQgQ29ubmVjdCwgYnV0IHRoYXQgaXMgbm90IGluIHRoZXJlIHlldC4NCg0KUGF1bA0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IERpY2sgSGFyZHQgPGRpY2suaGFyZHRA Z21haWwuY29tPg0KU2VudDogU3VuIE5vdiAxOCAxNzoyMjozNyBFU1QgMjAxMg0KVG86ICJQYXVs IEUuIEpvbmVzIiA8cGF1bGVqQHBhY2tldGl6ZXIuY29tPg0KQ2M6IHdlYmZpbmdlckBnb29nbGVn cm91cHMuY29tLCBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbYXBwcy1kaXNj dXNzXSBOZXcgZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0wMy50eHQNCg0KSGkgUGF1bA0K DQpJIGFncmVlIGl0IHNob3VsZCBiZSBzZXBhcmF0ZSBkcmFmdHMuIEknZCBiZSB3aWxsaW5nIHRv IGVkaXQgaWYgdGhlcmUgaXMgaW50ZXJlc3QuIE15IGludGVyZXN0IGluIFdlYkZpbmdlciBpcyBh cyBhIGNvbnN1bWVyIG11Y2ggbW9yZSB0aGFuIGEgcHVibGlzaGVyIC0gc28gSSBkb24ndCBmZWVs IEkgYW0gYSBkb21haW4gZXhwZXJ0Lg0KDQpJcyBpdCBwb3NzaWJsZSB0byBoYXZlIG1lYW5pbmdm dWwgZXhhbXBsZXMgd2l0aCBleGlzdGluZyAicmVsIiB2YWx1ZXMsIG9yIGRvIHdlIG5lZWQgdG8g aGF2ZSBzb21lIG90aGVycyBkZWZpbmVkIHRvIGhhdmUgbWVhbmluZ2Z1bCBleGFtcGxlcz8NCg0K LS0gRGljaw0KDQpPbiBOb3YgMTgsIDIwMTIsIGF0IDI6MDIgUE0sICJQYXVsIEUuIEpvbmVzIiA8 cGF1bGVqQHBhY2tldGl6ZXIuY29tPG1haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20+PiB3cm90 ZToNCg0KDQpEaWNrLA0KDQpUaGVzZSBzaG91bGQgYmUgc2VwYXJhdGUgZHJhZnRzLiAgSSBhZ3Jl ZSDigJxibG9n4oCdIGlzIGdvb2QsIGJ1dCB0aGVyZSBhcmUgc3VyZWx5IG1vcmUuICBBIGxvdCBv ZiBnb29kIG9uZXMgYXJlIGRlZmluZWQgdW5kZXIgd2ViZmluZ2VyLm5ldDxodHRwOi8vd2ViZmlu Z2VyLm5ldD4sIHRvby4NCg0KQnV0IEkgd291bGQgcmVhbGx5IHByZWZlciB0byBub3Qgc2xvdyBk b3duIHRoaXMgZHJhZnQgd2l0aCBhZGRpdGlvbiBvZiBsaW5rIHJlbGF0aW9uIHZhbHVlcy4gIElm IHNvbWVib2R5ICh5b3U/KSB3YW50cyB0byBzdGFydCBhIFdlYkZpbmdlciBMaW5rIFJlbGF0aW9u cyBkb2N1bWVudCwgSSB0aGluayBpdCB3b3VsZCBiZSB0aW1lbHkuDQoNClBhdWwNCg0KDQoNClBF SjogVGhleSBjb3VsZC4gIFRoZSBjaGFsbGVuZ2UgaXMgdGhhdCB3ZSBoYXZlIG5vIG90aGVyIFVS SSB0eXBlIGRlZmluZWQgZm9yIHRoaXMgcHVycG9zZS4gIEZvciEgdGhlIGV4YW1wbGVzLCB3ZSBo YXZlIGEgY2hpY2tlbiBhbmQgZWdnIHByb2JsZW0uDQoNCg0KTGV0J3MgZGVmaW5lIHNvbWUgdGhl biEgVGhpcyBpcyB0aGUgb25lIGFyZWEgdGhhdCBpcyB2YWd1ZSBhbmQgSU1ITyBpcyBhIGJhcnJp ZXIgdG8gYWRvcHRpb24uIFdoYXQgc2hvdWxkIHRoZSAicmVsIiB2YWx1ZXMgYmUgZm9yIGl0ZW1z IHRoYXQgSSB3YW50IHRvIHB1Ymxpc2g/IElmIHdlIGRvbid0IHNwZWMgdGhlIGNvbW1vbiBvbmVz LCB3ZSB3aWxsIGVuZCB1cCB3aXRoIHNldmVyYWwgZGlmZmVyZW50IGlkZW50aWZpZXJzIGZvciB0 aGUgc2FtZSB0aGluZy4gQ2hhbGxlbmdlIG9mIGNvdXJzZSBpcyB0aGF0IGdldHRpbmcgYWdyZWVt ZW50IG9uIHNjaGVtYSBpcyBhbHdheXMgZnVuLCBidXQgYmV0dGVyIHRvIGhhdmUgc29tZSB0aGF0 IHdpbGwgYmUgdXNlZCB0aGF0IGFyZSBub3QgYWxyZWFkeSBkZWZpbmVkLg0KDQoNCk5lZWQgdG8g YWRkIGFuIElBTkEgc2VjdGlvbiAhIGZvciB0aGF0IG9mIGNvdXJzZS4NCg0KDQoiYmxvZyIgaXMg YSBnb29kIG9uZSA6KQ0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8g aW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZm dXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNv bm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0 ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBz aWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9u ZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXpp ZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5k IG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRy ZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5 IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVu dHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0KW2Np ZDowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM0BUSS5EaXNjbGFpbWVyXVJpc3BldHRh IGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJp by4NCg0K --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5575514GRFMBX704BA02_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug aHJlZj0ieC1tc2c6Ly8yNTEwLyI+PCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnZcOioge2JlaGF2 aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwp O30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6 dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwhW2VuZGlmXS0tPjxzdHlsZT4NCjwhLS0N CiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNl Z29lIFVJIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQogLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJn aW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTph cHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5TdGlsZU1lc3NhZ2dpb0RpUG9zdGFFbGV0dHJv bmljYTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNt IDIuMGNtIDIuMGNtO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCiAvKiBMaXN0 IERlZmluaXRpb25zICovDQogQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NzY0MDM3MDc4Ow0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNzAzMDY5OTE0IDQy MzQ2NDgwIDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1 Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3Rh cnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTow Y207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOiBi cmVhay13b3JkOy13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsNCi13ZWJraXQtbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2UiPg0KPGRpdiBjbGFzcz0iU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPlZlcnkgY2xlYW4gc3BlYyBub3csIHRoYW5rcyBwYXVsIGZvciB0aGlzIGh1Z2Ug Y2xlYW51cCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPmkgYWxzbyBi ZWxpZXZlIHRoYXQgd2Ugc2hvdWxkIGJlIGNhcmVmdWwgd2l0aCB0aGUgbGluayByZWxzIGluIHRo ZSBleGFtcGxlcy4gV2hlbmV2ZXIgdGhlIGxpbmsgcmVscyBtZW50aW9uZWQgYXJlIHRva2VucyBh bmQgdHJ1bHkgZXhpc3QsIEkgd291bGQNCiBzdWdnZXN0IHRvIHJlZmVyZW5jZSB0aGUgc3BlY2lm aWMgc3BlYy4gaW4gb3RoZXIgY2FzZXMgd2UgY291bGQgZWl0aGVyIHVzZSB1cmlzIHVuZGVyIHNv bWUgZXhhbXBsZS5uZXQgbmFtZXNwYWNlLCBvciBzaW1wbHkgc3RhdGUgdGhhdCB0aGUgdG9rZW4g dXNlZCBpcyBmaWN0aXRpb3VzIGF0IHRoZSB0aW1lIG9mIHdyaXRpbmcuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5Tb21lIG90aGVyIG1pbm9yIGNvbW1lbnRzOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsNCmZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JbiBzZWN0aW9uIDMgSSBoYXZlIG5vdCBjbGVhciB0aGUgcHVycG9zZSBvZiB0aGUg ZWR1Y2F0aW9uYWwgcGFyYWdyYXBoIG9uIGxpbmsgcmVscyBhbmQgdGhlIGVmZmVjdGl2ZSByZWxh dGlvbiB3aXRoIHdlYmZpbmdlciBiYXNlZA0KIG9uIHRoZSBjdXJyZW50IHRleHQuIENvdWxkIHdl IHJlbW92ZSBpdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7DQpjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gc2VjdGlvbiA0LjEgeW91IG1lbnRpb24g4oCcYW55 IHZhbGlkIGFsaWFzIGZvciB0aGUgdXNlcuKAnS4gSXQgbWF5IGJlIGNsZWFuZXIgdG8gc3RhdGUg 4oCcYW55IHZhbGlkIFVSSSBhcyBhbGlhcyBmb3IgdGhlIHVzZXLigJ0gdG8gZW1waGFzaXplDQog dGhlIHVzYWdlIG9mIHVyaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gc2VjdGlvbiA1LjIgSSB3b3VsZCBzdWdn ZXN0IHRvIGludmVydCB0aGUg4oCcZXhwaXJlc+KAnSBhbmQg4oCcc3ViamVjdOKAnSBidWxsZXRz IHRvIG1lbnRpb24gcmVxdWlyZWQgZWxlbWVudHMgZmlyc3QuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCiZxdW90O1NlZ29lIFVJJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRhOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5QZXIgY29udG8gZGkg PC9iPlBhdWwgRS4gSm9uZXM8YnI+DQo8Yj5JbnZpYXRvOjwvYj4gZG9tZW5pY2EgMTggbm92ZTwv c3Bhbj48c3BhbiBsYW5nPSJJVCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWls eTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYnJlIDIwMTIg MjMuNDM8YnI+DQo8Yj5BOjwvYj4gRGljayBIYXJkdDxicj4NCjxiPkNjOjwvYj4gd2ViZmluZ2Vy QGdvb2dsZWdyb3Vwcy5jb207IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzxicj4NCjxiPk9nZ2V0dG86 PC9iPiBSZTogW2FwcHMtZGlzY3Vzc10gTmV3IGRyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXIt MDMudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5EaWNrLDxicj4NCjxicj4NClRoZSBmaXJzdCBleGFt cGxlIGlzIGZhaXJseSBtZWFuaW5nZnVsIGluIHRoYXQgbW9zdCBvZiB0aGUgcmVscyBhcmUgaW4g dXNlLiBUaGUgdmNhcmQgb25lIGlzIG5vdCwgYnV0IEknZCBsaWtlIHRvIHNlZSB0aGF0IGRlZmlu ZWQuIEknZCBiZSBPSyB3aXRoIHVzaW5nIHRoZSB0b2tlbiAnYmxvZycgaWYgd2UncmUgZ29pbmcg dG8gYWdyZWUgb24gdGhhdC48YnI+DQo8YnI+DQpUaGUgc2Vjb25kIGV4YW1wbGUgZG9lcyBub3Qg dXNlIHJlYWwgdmFsdWVzLCBidXQgaXQgaXMgaW1wb3J0YW50IGluIHRoYXQgaXQgc2hvd3MgdXNl IG9mIHByb3BlcnRpZXMuPGJyPg0KPGJyPg0KVGhlIHRoaXJkIGV4YW1wbGUgaXMgaW1wb3J0YW50 IGluIHRoYXQgaXQgcmVsYXRlZCB0byBub24taHVtYW5zLjxicj4NCjxicj4NCldlIGFyZSBzdXBw b3NlZCB0byBnZXQgb25lIG1vcmUgZXhhbXBsZSByZWxhdGVkIHRvIE9wZW5JRCBDb25uZWN0LCBi dXQgdGhhdCBpcyBub3QgaW4gdGhlcmUgeWV0Ljxicj4NCjxicj4NClBhdWw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0 ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGhyIHNpemU9 IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0 QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TZW50OjwvYj4gU3VuIE5vdiAxOCAxNzoyMjozNyBFU1Qg MjAxMjxicj4NCjxiPlRvOjwvYj4gJnF1b3Q7UGF1bCBFLiBKb25lcyZxdW90OyAmbHQ7cGF1bGVq QHBhY2tldGl6ZXIuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gd2ViZmluZ2VyQGdvb2dsZWdyb3Vw cy5jb20sIGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2Fw cHMtZGlzY3Vzc10gTmV3IGRyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXItMDMudHh0PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpIaSBQ YXVsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVl IGl0IHNob3VsZCBiZSBzZXBhcmF0ZSBkcmFmdHMuIEknZCBiZSB3aWxsaW5nIHRvIGVkaXQgaWYg dGhlcmUgaXMgaW50ZXJlc3QuIE15IGludGVyZXN0IGluIFdlYkZpbmdlciBpcyBhcyBhIGNvbnN1 bWVyIG11Y2ggbW9yZSB0aGFuIGEgcHVibGlzaGVyIC0gc28gSSBkb24ndCBmZWVsIEkgYW0gYSBk b21haW4gZXhwZXJ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JcyBpdCBwb3NzaWJsZSB0byBoYXZlIG1lYW5pbmdmdWwgZXhhbXBsZXMgd2l0 aCBleGlzdGluZyAmcXVvdDtyZWwmcXVvdDsgdmFsdWVzLCBvciBkbyB3ZSBuZWVkIHRvIGhhdmUg c29tZSBvdGhlcnMgZGVmaW5lZCB0byBoYXZlIG1lYW5pbmdmdWwgZXhhbXBsZXM/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIERpY2s8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBOb3Yg MTgsIDIwMTIsIGF0IDI6MDIgUE0sICZxdW90O1BhdWwgRS4gSm9uZXMmcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20iPnBhdWxlakBwYWNrZXRpemVyLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPkRpY2ssPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsNCmNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlRo ZXNlIHNob3VsZCBiZSBzZXBhcmF0ZSBkcmFmdHMuJm5ic3A7IEkgYWdyZWUg4oCcYmxvZ+KAnSBp cyBnb29kLCBidXQgdGhlcmUgYXJlIHN1cmVseSBtb3JlLiZuYnNwOyBBIGxvdCBvZiBnb29kIG9u ZXMgYXJlIGRlZmluZWQgdW5kZXI8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3dlYmZpbmdlci5uZXQiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPndlYmZpbmdlci5uZXQ8L3NwYW4+PC9hPiwNCiB0b28uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkJ1dCBJIHdvdWxkIHJlYWxseSBwcmVmZXIgdG8g bm90IHNsb3cgZG93biB0aGlzIGRyYWZ0IHdpdGggYWRkaXRpb24gb2YgbGluayByZWxhdGlvbiB2 YWx1ZXMuJm5ic3A7IElmIHNvbWVib2R5ICh5b3U/KSB3YW50cyB0byBzdGFydCBhIFdlYkZpbmdl ciBMaW5rDQogUmVsYXRpb25zIGRvY3VtZW50LCBJIHRoaW5rIGl0IHdvdWxkIGJlIHRpbWVseS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+UGF1bDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7DQp6LWlu ZGV4OmF1dG8iPg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiM5NTM3MzUiPlBFSjogVGhleSBjb3VsZC4mbmJzcDsgVGhlIGNoYWxsZW5nZSBpcyB0 aGF0IHdlIGhhdmUgbm8gb3RoZXIgVVJJIHR5cGUgZGVmaW5lZCBmb3IgdGhpcyBwdXJwb3NlLiZu YnNwOyBGb3IhIHRoZSBleGFtcGxlcywgd2UgaGF2ZSBhIGNoaWNrZW4gYW5kIGVnZyBwcm9ibGVt Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TGV0J3MgZGVm aW5lIHNvbWUgdGhlbiEgVGhpcyBpcyB0aGUgb25lIGFyZWEgdGhhdCBpcyB2YWd1ZSBhbmQgSU1I TyBpcyBhIGJhcnJpZXIgdG8gYWRvcHRpb24uIFdoYXQgc2hvdWxkIHRoZSAmcXVvdDtyZWwmcXVv dDsgdmFsdWVzIGJlIGZvciBpdGVtcyB0aGF0IEkgd2FudCB0byBwdWJsaXNoPyBJZiB3ZSBkb24n dCBzcGVjIHRoZSBjb21tb24gb25lcywgd2Ugd2lsbCBlbmQgdXAgd2l0aCBzZXZlcmFsDQogZGlm ZmVyZW50IGlkZW50aWZpZXJzIGZvciB0aGUgc2FtZSB0aGluZy4gQ2hhbGxlbmdlIG9mIGNvdXJz ZSBpcyB0aGF0IGdldHRpbmcgYWdyZWVtZW50IG9uIHNjaGVtYSBpcyBhbHdheXMgZnVuLCBidXQg YmV0dGVyIHRvIGhhdmUgc29tZSB0aGF0IHdpbGwgYmUgdXNlZCB0aGF0IGFyZSBub3QgYWxyZWFk eSBkZWZpbmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+TmVlZCB0byBhZGQgYW4gSUFOQSBzZWN0aW9uICEgZm9yIHRoYXQgb2Yg Y291cnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+JnF1b3Q7YmxvZyZxdW90OyBpcyBhIGdvb2Qgb25lIDopPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwhLS0NCnNwYW4uR3JhbUUge21zby1zdHls ZS1uYW1lOiIiOw0KCW1zby1ncmFtLWU6eWVzO30NCi0tPg0KPC9zdHlsZT4NCjx0YWJsZSBzdHls ZT0id2lkdGg6NjAwcHg7Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0id2lkdGg6NTg1cHg7 IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBBcmlhbDsgZm9udC1zaXplOjEycHg7IGNvbG9yOiMwMDA7 IHRleHQtYWxpZ246IGp1c3RpZnkiIHdpZHRoPSIzOTUiPg0KPGRpdiBhbGlnbj0ianVzdGlmeSI+ PHNwYW4gY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTsgbGluZS1o ZWlnaHQ6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OlZl cmRhbmEiPlF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0 aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNv cGlhIG8gcXVhbHNpYXNpDQogYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2Nlbnph IGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxv cmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29y dGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0 dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQo8L3Nw YW4+PC9zcGFuPjwvZGl2Pg0KPHAgYWxpZ249Imp1c3RpZnkiPjxzcGFuIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+PGk+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6VmVyZGFu YTttc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+VGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50 czwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6DQogIDcu NXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTttc28tYW5z aS1sYW5ndWFnZTpFTi1HQiI+Jm5ic3A7PHNwYW4gY2xhc3M9IkdyYW1FIj5pczwvc3Bhbj4mbmJz cDs8L3NwYW4+PC9pPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOg0KICA3 LjVwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj5jb25maWRl bnRpYWwNCiBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBm b3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGlu ZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFu eSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXINCiBieSByZXR1cm4gZS1tYWlsLCBU aGFua3MuPC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1hbnNpLWxhbmd1 YWdlOkVOLUdCIj4NCjwvc3Bhbj48L3NwYW4+PC9wPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjVwdDsNCiAgZm9udC1mYW1pbHk6VmVyZGFuYSI+PGltZyBzcmM9ImNpZDowMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwM0BUSS5EaXNjbGFpbWVyIiBhbHQ9InJpc3BldHRhIGwnYW1i aWVudGUiIHdpZHRoPSIyNiIgaGVpZ2h0PSI0MCI+UmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0 YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3NhcmlvLjwvc3Bhbj48L2I+DQo8cD48 L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5575514GRFMBX704BA02_-- --_84e7f75b-104f-4c58-b24d-7abb2def3d6d_ 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= --_84e7f75b-104f-4c58-b24d-7abb2def3d6d_-- From dick.hardt@gmail.com Sun Nov 18 13:47: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 0D79F21F85D2 for ; Sun, 18 Nov 2012 13:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.816 X-Spam-Level: X-Spam-Status: No, score=-3.816 tagged_above=-999 required=5 tests=[AWL=-0.218, 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 r78puQDR5-aS for ; Sun, 18 Nov 2012 13:47:15 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF05A21F84E9 for ; Sun, 18 Nov 2012 13:47:14 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so1011991pad.31 for ; Sun, 18 Nov 2012 13:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=t6gbcdRJ84uM2khY63zniUXioJTMvaX1uuUK62G4o7k=; b=ykm53tlELbryaXNeFxnxwL48gc7kACsLzFAEhvE/DcP+Zr88i+xPKs2LAhPdKUdGJL lVAWHXnseMa8IuLlprIYCixzFmwS4oVgazK0nwhInFvDoq77v24JAEiFtLzq3EFTLwQS E8DoayHrtBRMN1Ta+OHHDiHAi2PfGRxx34VEMsurT/KdgeEB+iSmwdkIEgFxEZ839ff9 m9r++8/cm6Aa1DOInLmOCDMj0uX+m/bpoxVP9UQREat80sUCU0R0JW3qLo/oAYWCikIz bOcIWStH3csZ5qW7ZYGqrrgfSY+NZyR/VMmtxmZqhvaIeHPm3mjpyp5NKY9uySplG3Dt zMwA== Received: by 10.68.138.137 with SMTP id qq9mr34260836pbb.74.1353275234639; Sun, 18 Nov 2012 13:47:14 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id oj1sm5003564pbb.19.2012.11.18.13.47.05 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Nov 2012 13:47:09 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_74060875-29EB-4F23-BEB0-CDF0F3AAEBA7" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> Date: Sun, 18 Nov 2012 13:47:04 -0800 Message-Id: <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Mon, 19 Nov 2012 08:43:39 -0800 Cc: webfinger@googlegroups.com, apps-discuss@ietf.org, 'Dick Hardt' Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Sun, 18 Nov 2012 21:47:16 -0000 --Apple-Mail=_74060875-29EB-4F23-BEB0-CDF0F3AAEBA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 18, 2012, at 1:40 PM, "Paul E. Jones" = wrote: > Dick, > =20 > Comments below: > =20 > From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Dick Hardt > Sent: Saturday, November 17, 2012 9:14 PM > To: webfinger@googlegroups.com > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt > =20 > I agree with Brad, this is a great improvement! Thanks Paul! > =20 > A few comments on Brad's comments and a couple extras. > =20 > There are a number of other standards based nits, but I would suggest = let's get the issues below dealt with and then can dig into nits. > =20 > On Nov 17, 2012, at 5:51 PM, Brad Fitzpatrick = wrote: >=20 >=20 > This is wonderful. Thank you! > =20 > Some comments, all minor: > =20 > are the rels in the non-normative section 4.1 and 4.2 real? (i.e. = avatar, profile-page, blog, smtp-server) like it or not, people will = use them if they're not. > =20 > Let's get clear on what these are. Is "rel" : = "http://packetizer.com/rel/blog" really going to be the standard way to = query for a blog? > =20 > PEJ: They could. The challenge is that we have no other URI type = defined for this purpose. For the examples, we have a chicken and egg = problem. Let's define some then! This is the one area that is vague and IMHO is a = barrier to adoption. What should the "rel" values be for items that I = want to publish? If we don't spec the common ones, we will end up with = several different identifiers for the same thing. Challenge of course is = that getting agreement on schema is always fun, but better to have some = that will be used that are not already defined. Need to add an IANA section for that of course. "blog" is a good one :) > =20 > the HTTPS-to-HTTP safeguards in section 5.1 look useless. what are = you trying to protect? I would just say MUST use https first, MAY fall = back to http, servers SHOULD serve on https, MAY serve on http, clients = SHOULD NOT trust anything for anything important not over https. = (certainly some things I can imagine being valid over http=85 but not = tons) But all the stuff about clients dealing with 4xx vs 5xx vs 2xx vs = TCP connection failures seems useless. A MITM could just force https = connection errors and hide any 4xx / 5xx anyway. > =20 > +1 > =20 > 5.2 > =20 > Why is there a preferred order for the JSON? That seems weird, and = difficult to do if you are serving dynamically and using an object->JSON = library to output the JSON. > =20 > section 7: I might also note that despite the "avatar" and "blog" = examples above, it's not assumed that people would put their personal = information (social networking-related or otherwise) into their = WebFinger document. Rather, for social networking applications, it's = assumed that WebFinger will merely contain pointers to other servers = which then require auth. WebFinger exists just to bootstrap that = discovery, and not to disseminate personal information itself. > =20 > +1 >=20 >=20 > =20 > section 9: oh wait, this is much like section 7. can we merge these = two sections a bit? > =20 > These should stay separate. Security Considerations is a standard RFC = section. (7) is about Access Control. > =20 > PEJ: What if we took section 7 and put all of the contents in as the = second paragraph in 9? Would you like it there or prefer it separate? = I have no strong preference. Sorry I was not clear. I think your current structure is good. I would = rename (7) to be Access Control, which is not the same as Security = Considerations.= --Apple-Mail=_74060875-29EB-4F23-BEB0-CDF0F3AAEBA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Nov 18, 2012, = at 1:40 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:

 
Comments below 
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Dick = Hardt
Sent: Saturday, November 17, 2012 = 9:14 PM
To:   Re: [apps-discuss] New = draft-ietf-appsawg-webfinger-03.txt
 
This is = wonderful.  Thank you!
 
Some = comments, all minor:
 
are = the rels in the non-normative section 4.1 and 4.2 real? (i.e. avatar, = profile-page, blog, smtp-server)  like it or not, people will use = them if they're not.
 
Let's get clear on what these are. Is "rel" : = "http://packetizer.com/rel/blog" really = going to be the standard way to query for a = blog?
 
PEJ: They could.  = The challenge is that we have no other URI type defined for this = purpose.  For the examples, we have a chicken and egg = problem.

<= /div>
Let's define some then! This is the one area that is vague and = IMHO is a barrier to adoption. What should the "rel" values be for items = that I want to publish? If we don't spec the common ones, we will end up = with several different identifiers for the same thing. Challenge of = course is that getting agreement on schema is always fun, but better to = have some that will be used that are not already = defined.

Need to add an IANA section for that = of course.

"blog" is a good one = :)

the = HTTPS-to-HTTP safeguards in section 5.1 look useless.  what are you = trying to protect?  I would just say MUST use https first, MAY fall = back to http, servers SHOULD serve on https, MAY serve on http, clients = SHOULD NOT trust anything for anything important not over https. =  (certainly some things I can imagine being valid over http=85 but = not tons)  But all the stuff about clients dealing with 4xx vs 5xx = vs 2xx vs TCP connection failures seems useless.  A MITM could just = force https connection errors and hide any 4xx / 5xx = anyway.
 
Why = is there a preferred order for the JSON? That seems weird, and difficult = to do if you are serving dynamically and using an object->JSON = library to output the JSON.
 
 
section 9: = oh wait, this is much like section 7.  can we merge these two = sections a bit?
 
These should stay separate. Security Considerations = is a standard RFC section. (7) is about Access = Control.
 
PEJ: What if we took = section 7 and put all of the contents in as the second paragraph in = 9?  Would you like it there or prefer it separate?  I have no = strong = preference.

Sorry I was not clear. I think your current structure is good. I = would rename (7) to be Access Control, which is not the same as Security = Considerations.
= --Apple-Mail=_74060875-29EB-4F23-BEB0-CDF0F3AAEBA7-- From dick.hardt@gmail.com Sun Nov 18 14:22: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 180D821F859E for ; Sun, 18 Nov 2012 14:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.804 X-Spam-Level: X-Spam-Status: No, score=-3.804 tagged_above=-999 required=5 tests=[AWL=-0.206, 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 iVfsZ-0raHGM for ; Sun, 18 Nov 2012 14:22:44 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29D5D21F8578 for ; Sun, 18 Nov 2012 14:22:44 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1902054dan.31 for ; Sun, 18 Nov 2012 14:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=feCG0mLR6Z59kFBt7CXkaivwzqkoJkwoj5t7kV6/zAA=; b=SVI2lr6JG6pYneXEYlNzo9w4VIietPkOiLTY8ULRRLJ49ffTpmYNW+wvrL8Ak5w4tN h/ZHRUfjVD9qL857zrMj2hR3CM14hrMweEQZ4z3ETO0i+2M29RVsYjeilDwqhZcnNDQG oelCZklzG57m4Nwxqo+a9C0cHnHai3ByyjEJ2GKLtjIWUKdyh913AscA0aanEG4PMoud 59fCIKXIp3lc0dYMFIAIwn2EqqEOZWT0LR0mRHZ/jfRvrGx9Jz0UMb3rBN8l8hMbChYh qH6Fr8+4W6Rny0SrwUKb2bpHEMJIKHJE1denu+vHspc696N5/bAFQO4axf7jpay4vqxW huuw== Received: by 10.68.192.5 with SMTP id hc5mr34400643pbc.16.1353277363756; Sun, 18 Nov 2012 14:22:43 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id nf9sm5041164pbc.17.2012.11.18.14.22.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Nov 2012 14:22:42 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E52F42FD-611A-4D17-B951-C524BA6D771D" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> Date: Sun, 18 Nov 2012 14:22:37 -0800 Message-Id: <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Mon, 19 Nov 2012 08:44:01 -0800 Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Sun, 18 Nov 2012 22:22:45 -0000 --Apple-Mail=_E52F42FD-611A-4D17-B951-C524BA6D771D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Paul I agree it should be separate drafts. I'd be willing to edit if there is = interest. My interest in WebFinger is as a consumer much more than a = publisher - so I don't feel I am a domain expert. Is it possible to have meaningful examples with existing "rel" values, = or do we need to have some others defined to have meaningful examples? -- Dick On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" = wrote: > Dick, > =20 > These should be separate drafts. I agree =93blog=94 is good, but = there are surely more. A lot of good ones are defined under = webfinger.net, too. > =20 > But I would really prefer to not slow down this draft with addition of = link relation values. If somebody (you?) wants to start a WebFinger = Link Relations document, I think it would be timely. > =20 > Paul > =20 > =20 > PEJ: They could. The challenge is that we have no other URI type = defined for this purpose. For the examples, we have a chicken and egg = problem. > =20 > Let's define some then! This is the one area that is vague and IMHO is = a barrier to adoption. What should the "rel" values be for items that I = want to publish? If we don't spec the common ones, we will end up with = several different identifiers for the same thing. Challenge of course is = that getting agreement on schema is always fun, but better to have some = that will be used that are not already defined. > =20 > Need to add an IANA section for that of course. > =20 > "blog" is a good one :) --Apple-Mail=_E52F42FD-611A-4D17-B951-C524BA6D771D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Paul

I = agree it should be separate drafts. I'd be willing to edit if there is = interest. My interest in WebFinger is as a consumer much more than a = publisher - so I don't feel I am a domain = expert.

Is it possible to have meaningful = examples with existing "rel" values, or do we need to have some others = defined to have meaningful examples?

-- = Dick

On Nov 18, 2012, at 2:02 PM, "Paul E. = Jones" <paulej@packetizer.com> = wrote:

 
These should be separate drafts.  I = agree =93blog=94 is good, but there are surely more.  A lot of good = ones are defined under webfinger.net, too.
 
But I would really = prefer to not slow down this draft with addition of link relation = values.  If somebody (you?) wants to start a WebFinger Link = Relations document, I think it would be = timely.
 
Paul
 
PEJ: They could.  The challenge is that = we have no other URI type defined for this purpose.  For the = examples, we have a chicken and egg = problem.
 
Let's define some then! This is the one area that = is vague and IMHO is a barrier to adoption. What should the "rel" values = be for items that I want to publish? If we don't spec the common ones, = we will end up with several different identifiers for the same thing. = Challenge of course is that getting agreement on schema is always fun, = but better to have some that will be used that are not already = defined.
Need = to add an IANA section for that of = course.

To: Dick Hardt , "Paul E. Jones" Date: Mon, 19 Nov 2012 18:09:51 +0100 Thread-Topic: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt Thread-Index: Ac3GdRkkfleq8GX6SZ+MlPl6QXkHmAAAmVzg Message-ID: References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> In-Reply-To: <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.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: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" Subject: [apps-discuss] R: New draft-ietf-appsawg-webfinger-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: Mon, 19 Nov 2012 17:10:16 -0000 --_c89c4e38-ce3b-41ad-84a2-9031e2561bf2_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A55757FDGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A55757FDGRFMBX704BA02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Although it is an XRD, here is a good example of link rels widely used in t= he context of federated social networks [1]. Amongst them, it could be worth registering in the new draft: - http://webfinger.net/rel/profile-page -> "profile-page" ? - http://webfinger.net/rel/avatar -> "avatar" ? - http://schemas.google.com/g/2010#updates-from -> "activitystream= " ? to cite a few generic. I do expect others to remain URLs referred to a spec= ific company/project but the ones above would definitely help in having a c= ommon framework for interoperability made of *registered* link rels. walter [1] http://identi.ca/main/xrd?uri=3Dhttp://identi.ca/w3c Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Pe= r conto di Dick Hardt Inviato: domenica 18 novembre 2012 23.23 A: Paul E. Jones Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Oggetto: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt Hi Paul I agree it should be separate drafts. I'd be willing to edit if there is in= terest. My interest in WebFinger is as a consumer much more than a publishe= r - so I don't feel I am a domain expert. Is it possible to have meaningful examples with existing "rel" values, or d= o we need to have some others defined to have meaningful examples? -- Dick On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" > wrote: Dick, These should be separate drafts. I agree "blog" is good, but there are sur= ely more. A lot of good ones are defined under webfinger.net, too. But I would really prefer to not slow down this draft with addition of link= relation values. If somebody (you?) wants to start a WebFinger Link Relat= ions document, I think it would be timely. Paul PEJ: They could. The challenge is that we have no other URI type defined f= or this purpose. For the examples, we have a chicken and egg problem. Let's define some then! This is the one area that is vague and IMHO is a ba= rrier to adoption. What should the "rel" values be for items that I want to= publish? If we don't spec the common ones, we will end up with several dif= ferent identifiers for the same thing. Challenge of course is that getting = agreement on schema is always fun, but better to have some that will be use= d that are not already defined. Need to add an IANA section for that of course. "blog" is a good one :) 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 ? necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE53A55757FDGRFMBX704BA02_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Although it is an XRD, here is a good example of link rels w= idely used in the context of federated social networks [1].

 

Amongst them, it could be worth registering in the new draft= :

-          http://webfinger.net/rel/profile-page -> “profile-page” ?

-          http://webfinger.net/rel/avatar -> “avatar” ?

-        = ;  http://schemas.google.com/g/2010#updates-from<= /a> -> “activitystream” ?

 

to cite a few generic. I do expect others to remain URLs ref= erred to a specific company/project but the ones above would definitely hel= p in having a common framework for interoperability made of *registered* link r= els.

 

walter

 

[1] http://ide= nti.ca/main/xrd?uri=3Dhttp://identi.ca/w3c

 

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounce= s@ietf.org] Per conto di Dick Hardt
Inviato: domenica 18 novembre 2012 23.23
A: Paul E. Jones
Cc: webfinger@googlegroups.com; apps-discuss@ietf.org
Oggetto: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt<= o:p>

 

Hi Paul

 

I agree it should be separate drafts. I'd be willing= to edit if there is interest. My interest in WebFinger is as a consumer mu= ch more than a publisher - so I don't feel I am a domain expert.=

 

Is it possible to have meaningful examples with exis= ting "rel" values, or do we need to have some others defined to h= ave meaningful examples?

 

-- Dick

 

On Nov 18, 2012, at 2:02 PM, "Paul E. Jones&quo= t; <paulej@packetizer.com&g= t; wrote:



Dick,

 

These should be separate drafts.  I agree “blog&#= 8221; is good, but there are surely more.  A lot of good ones are defi= ned under webfinger.net, too.

 

But I would really prefer to not slow down this draft with a= ddition of link relation values.  If somebody (you?) wants to start a = WebFinger Link Relations document, I think it would be timely.

 

Paul

 

 

PEJ: They could.  The challenge is that we have no othe= r URI type defined for this purpose.  For the examples, we have a chic= ken and egg problem.

 

Let's define some then! This is= the one area that is vague and IMHO is a barrier to adoption. What should = the "rel" values be for items that I want to publish? If we don't= spec the common ones, we will end up with several different identifiers for the same thing. Challenge of course is that gett= ing agreement on schema is always fun, but better to have some that will be= used that are not already defined.

 

Need to add an IANA section for= that of course.

 

"blog" is a good one = :)

 

= 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 è necessario.

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A55757FDGRFMBX704BA02_-- --_c89c4e38-ce3b-41ad-84a2-9031e2561bf2_ 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= --_c89c4e38-ce3b-41ad-84a2-9031e2561bf2_-- From jasnell@gmail.com Mon Nov 19 09:19: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 2B65021F86C8 for ; Mon, 19 Nov 2012 09:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.822 X-Spam-Level: X-Spam-Status: No, score=-3.822 tagged_above=-999 required=5 tests=[AWL=-0.224, 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 VMiZMaPrSQmb for ; Mon, 19 Nov 2012 09:19:48 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CACB121F86CD for ; Mon, 19 Nov 2012 09:19:47 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so3886374iaf.31 for ; Mon, 19 Nov 2012 09:19:47 -0800 (PST) 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=0CkWoK7SkFajiDcRz7mo9LsMjzQwwwiNwuItx9D/k6Q=; b=mXPzxtNYzmcfV05ieGhqhcakcJ5xmDGgOMtatWhUEi+83wIz5DQnEBbbbyaWKTi/75 eqffnOSQ39nNUsJ1hnYxteUxfpuPVHTpNboUutwCNKEHNvDnoW1DM4rXJ8+uSHTDVXig kg+CeLy1rp1vjdzctDG+zoSmsxcX8tqthmabrrYecu8Vu9XsqqrFNnzerXyeD6DcNc9y vzB5UEcYQatEXIw9Vmbhk1BHYOtp7k8pgMllZLdWHO2rBQOdAxOLX7InoW8TImGgOdxa UmpcDhtjtgSvHxSsThfvOGJv/ncx4bjTtyZYXf7PekBXnV0N5LXb+Y1RUz0OGFX3c72j kFgg== Received: by 10.42.29.5 with SMTP id p5mr11681778icc.33.1353345587022; Mon, 19 Nov 2012 09:19:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.225 with HTTP; Mon, 19 Nov 2012 09:19:26 -0800 (PST) In-Reply-To: References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> From: James M Snell Date: Mon, 19 Nov 2012 09:19:26 -0800 Message-ID: To: Goix Laurent Walter Content-Type: multipart/alternative; boundary=20cf303f6c30f90a8304cedc527c Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" , Dick Hardt Subject: Re: [apps-discuss] R: New draft-ietf-appsawg-webfinger-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: Mon, 19 Nov 2012 17:19:49 -0000 --20cf303f6c30f90a8304cedc527c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Nov 19, 2012 at 9:09 AM, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > Although it is an XRD, here is a good example of link rels widely used > in the context of federated social networks [1].**** > > ** ** > > Amongst them, it could be worth registering in the new draft:**** > > **- **http://webfinger.net/rel/profile-page -> =E2=80=9Cprofile-= page=E2=80=9D ? > Hmm.. does this one need a separate rel? We already have "about" (being registered by my "additional link rels" draft). Given the usual purpose and use of a profile page, rel=3D"about" could serve the use case well. > **** > > **- **http://webfinger.net/rel/avatar -> =E2=80=9Cavatar=E2=80= =9D ? > +1 > **** > > **- **http://schemas.google.com/g/2010#updates-from -> > =E2=80=9Cactivitystream=E2=80=9D ?**** > > ** > "activitystream" is too specific, I think... Perhaps just "updates". - James > ** > > to cite a few generic. I do expect others to remain URLs referred to a > specific company/project but the ones above would definitely help in havi= ng > a common framework for interoperability made of **registered** link rels.= * > *** > > ** ** > > walter**** > > ** ** > > [1] http://identi.ca/main/xrd?uri=3Dhttp://identi.ca/w3c **** > > ** ** > > *Da:* apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] > *Per conto di *Dick Hardt > *Inviato:* domenica 18 novembre 2012 23.23 > *A:* Paul E. Jones > > *Cc:* webfinger@googlegroups.com; apps-discuss@ietf.org > *Oggetto:* Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt**** > > ** ** > > Hi Paul**** > > ** ** > > I agree it should be separate drafts. I'd be willing to edit if there is > interest. My interest in WebFinger is as a consumer much more than a > publisher - so I don't feel I am a domain expert.**** > > ** ** > > Is it possible to have meaningful examples with existing "rel" values, or > do we need to have some others defined to have meaningful examples?**** > > ** ** > > -- Dick**** > > ** ** > > On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" > wrote:**** > > > > **** > > Dick,**** > > **** > > These should be separate drafts. I agree =E2=80=9Cblog=E2=80=9D is good,= but there are > surely more. A lot of good ones are defined under webfinger.net, too.***= * > > **** > > But I would really prefer to not slow down this draft with addition of > link relation values. If somebody (you?) wants to start a WebFinger Link > Relations document, I think it would be timely.**** > > **** > > Paul**** > > **** > > **** > > PEJ: They could. The challenge is that we have no other URI type defined > for this purpose. For the examples, we have a chicken and egg problem.**= * > * > > **** > > Let's define some then! This is the one area that is vague and IMHO is a > barrier to adoption. What should the "rel" values be for items that I wan= t > to publish? If we don't spec the common ones, we will end up with several > different identifiers for the same thing. Challenge of course is that > getting agreement on schema is always fun, but better to have some that > will be used that are not already defined.**** > > **** > > Need to add an IANA section for that of course.**** > > **** > > "blog" is a good one :)**** > > ** ** > 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 an= d > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa > mail se non =C3=A8 necessario.* > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --20cf303f6c30f90a8304cedc527c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Mon, Nov 19, 2012 at 9:09 AM, Goix La= urent Walter <laurentwalter.goix@telecomitalia.it>= ; wrote:

Although it is an XRD, here is a good = example of link rels widely used in the context of federated social network= s [1].

=C2=A0

Amongst them, it could be worth regist= ering in the new draft:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://webfinger.net/rel/profile-page -> =E2=80=9Cprofile-page=E2=80=9D ?

=
Hmm.. does this one need a separate rel? We already have "about&q= uot; (being registered by my "additional link rels" draft). Given= the usual purpose and use of a profile page, rel=3D"about" could= serve the use case well.=C2=A0
=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://webfinger.net/rel/avatar<= /a> -> =E2=80=9Cavatar=E2=80=9D ?

"activitystream" is too specific, I think... Perhaps ju= st "updates".

- James
=C2=A0

=C2=A0

to cite a few generic. I do expect oth= ers to remain URLs referred to a specific company/project but the ones abov= e would definitely help in having a common framework for interoperability made of *registered* link r= els.

=C2=A0

walter

=C2=A0

[1] http://identi.ca/main/xrd?uri=3Dhttp://identi.ca/w3c

=C2=A0

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di Dick Hardt
Inviato: domenica 18 novembre 2012 23.23
A: Paul E. Jones


Cc: = webfinger@googlegroups.com; apps-discuss@ietf.org
Oggetto: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt<= u>

=C2=A0

Hi Paul

=C2=A0

I agree it should be separate drafts. I'd be willing to e= dit if there is interest. My interest in WebFinger is as a consumer much mo= re than a publisher - so I don't feel I am a domain expert.

=C2=A0

Is it possible to have meaningful examples with existing &quo= t;rel" values, or do we need to have some others defined to have meani= ngful examples?

=C2=A0

-- Dick

=C2=A0

On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" <paulej@packetizer.= com> wrote:



Dick,

=C2=A0<= /u>

These should be separate drafts.=C2=A0= I agree =E2=80=9Cblog=E2=80=9D is good, but there are surely more.=C2=A0 A= lot of good ones are defined under=C2=A0webfinger.net, too.

=C2=A0<= /u>

But I would really prefer to not slow = down this draft with addition of link relation values.=C2=A0 If somebody (y= ou?) wants to start a WebFinger Link Relations document, I think it would be timely.

=C2=A0<= /u>

Paul

=C2=A0<= /u>

=C2=A0

PEJ: They could.=C2=A0 The challenge i= s that we have no other URI type defined for this purpose.=C2=A0 For the ex= amples, we have a chicken and egg problem.

=C2=A0

Let's define some then! This is the = one area that is vague and IMHO is a barrier to adoption. What should the &= quot;rel" values be for items that I want to publish? If we don't = spec the common ones, we will end up with several different identifiers for the same thing. Challenge of course is that gett= ing agreement on schema is always fun, but better to have some that will be= used that are not already defined.

=C2=A0

Need to add an IANA section for that of = course.

=C2=A0

"blog" is a good one :)=

=C2=A0

Questo mes= saggio e i suoi allegati sono indirizzati esclusivamente alle persone indic= ate. 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=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. 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"rispetta=Rispetta l'ambiente. Non st= ampare questa mail se non =C3=A8 necessario.


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


--20cf303f6c30f90a8304cedc527c-- From jasnell@gmail.com Mon Nov 19 09:36: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 51EB221F86D1 for ; Mon, 19 Nov 2012 09:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.81 X-Spam-Level: X-Spam-Status: No, score=-3.81 tagged_above=-999 required=5 tests=[AWL=-0.212, 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 94WgAHWGRNBk for ; Mon, 19 Nov 2012 09:36:42 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0E921F86C7 for ; Mon, 19 Nov 2012 09:36:42 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so3900068iaf.31 for ; Mon, 19 Nov 2012 09:36:41 -0800 (PST) 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=NxjgA7c1rdEsx2e4F4z39TMDS+QgyiO5p5W2h7Ygb0o=; b=T+/HMkQo4kgyJ2r4M9sADqvVZv3XaPKNfoLGc/zTf5zug4Tayn1G8kyf+Yrd6pxC8D IUlzPhL6/ofE2ptE1R0UWTT//wTiObFSTSZ5xtpyE2MNrRAH4zNVZFXY8ipg9iNAVvEJ ANqDBXlfVdvp/utYvUg+5fNkkU4CDbGWLRku2tVgDDnQ6y8lCcOImkYijl2fETVNkA0C 2x/cb879VdzoZ4Wlc9aLEl9OjfmrepuTUrAI19SZYDPr+Pok/j9u42G2WTrzqX7ueXw/ bTEologAUV5xNP2JWayRG4XZzqSxxqqb51PXkdSd2xqMG5vtF8e9mAmHlVupIM66bjQO Qrsw== Received: by 10.50.53.147 with SMTP id b19mr7277907igp.12.1353346601796; Mon, 19 Nov 2012 09:36:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.225 with HTTP; Mon, 19 Nov 2012 09:36:20 -0800 (PST) In-Reply-To: <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> From: James M Snell Date: Mon, 19 Nov 2012 09:36:20 -0800 Message-ID: To: Dick Hardt Content-Type: multipart/alternative; boundary=f46d04339c9675444104cedc8f1d Cc: webfinger@googlegroups.com, IETF Apps Discuss Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Mon, 19 Nov 2012 17:36:43 -0000 --f46d04339c9675444104cedc8f1d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just a quick note on this... I already have the existing "Additional Link Relations" draft [1] in progress (currently submitted as an independent submission) that registers link relations such as "about", "type", "terms-of-service", "privacy-policy" and "preview". It would be possible to pull this draft back and add a few more link relation types to it if necessary. We would just need to identify the set of new link rels and I could very easily drop them in or write up a quick second document based on the same simple template. [1] http://tools.ietf.org/html/draft-snell-additional-link-relations-06 That said, the "about" link relation can be used to link to both profile-page and vcard type resources... differentiated, of course, by the media type of the linked resource. Also... We need to be careful not to get too specific with link relation labels. The rel values themselves are intended to state the nature of the relationship and not the type of resource it is. Having something like {"rel":"updates","href":"http://example.org/my/blog","type":"text/html"} should be generally preferable over something like {"rel":"blog","href":" http://example.org/my/blog"}. - James On Sun, Nov 18, 2012 at 2:22 PM, Dick Hardt wrote: > Hi Paul > > I agree it should be separate drafts. I'd be willing to edit if there is > interest. My interest in WebFinger is as a consumer much more than a > publisher - so I don't feel I am a domain expert. > > Is it possible to have meaningful examples with existing "rel" values, or > do we need to have some others defined to have meaningful examples? > > -- Dick > > On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" > wrote: > > Dick,**** > > These should be separate drafts. I agree =E2=80=9Cblog=E2=80=9D is good,= but there are > surely more. A lot of good ones are defined under webfinger.net, too.***= * > > But I would really prefer to not slow down this draft with addition of > link relation values. If somebody (you?) wants to start a WebFinger Link > Relations document, I think it would be timely.**** > > Paul**** > > ** ** > PEJ: They could. The challenge is that we have no other URI type defined > for this purpose. For the examples, we have a chicken and egg problem.**= * > * > ** ** > Let's define some then! This is the one area that is vague and IMHO is a > barrier to adoption. What should the "rel" values be for items that I wan= t > to publish? If we don't spec the common ones, we will end up with several > different identifiers for the same thing. Challenge of course is that > getting agreement on schema is always fun, but better to have some that > will be used that are not already defined.**** > ** ** > Need to add an IANA section for that of course.**** > ** ** > "blog" is a good one :)**** > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d04339c9675444104cedc8f1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just a quick note on this... I already= have the existing "Additional Link Relations" draft [1] in progr= ess (currently submitted as an independent submission) that registers link = relations such as "about", "type", "terms-of-servi= ce", "privacy-policy" and "preview". It would be p= ossible to pull this draft back and add a few more link relation types to i= t if necessary. We would just need to identify the set of new link rels and= I could very easily drop them in or write up a quick second document based= on the same simple template.


That said, the "about" l= ink relation can be used to link to both profile-page and vcard type resour= ces... differentiated, of course, by the media type of the linked resource.= =C2=A0

- James

On Sun, Nov 18, 2012 at 2:22 PM, Dick Hard= t <dick.hardt@gmail.com> wrote:
Hi Paul<= div>
I agree it should be separate drafts. I'd be willing= to edit if there is interest. My interest in WebFinger is as a consumer mu= ch more than a publisher - so I don't feel I am a domain expert.

Is it possible to have meaningful examples with existin= g "rel" values, or do we need to have some others defined to have= meaningful examples?
<= div>
-- Dick

<= div>
On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:

Dick,
=C2=A0
=C2=A0
But I would really prefer to not slow down this draft with addition= of link relation values.=C2=A0 If somebody (you?) wants to start a WebFing= er Link Relations document, I think it would be timely.
=C2=A0
Paul
=C2= =A0
=C2=A0
PEJ: They could.=C2=A0 The challenge is that we have no other URI t= ype defined for this purpose.=C2=A0 For the examples, we have a chicken and= egg problem.
=C2=A0
Let's define some then! This is the one area that is vague and IMHO is = a barrier to adoption. What should the "rel" values be for items = that I want to publish? If we don't spec the common ones, we will end u= p with several different identifiers for the same thing. Challenge of cours= e is that getting agreement on schema is always fun, but better to have som= e that will be used that are not already defined.
=C2=A0
Need to add an IANA section for that of course.
=C2=A0
"blog" is a good one :)


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


--f46d04339c9675444104cedc8f1d-- From paulej@packetizer.com Mon Nov 19 20:55: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 C369E21F85C2 for ; Mon, 19 Nov 2012 20:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[AWL=-0.308, 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 J8Cth-kG7wKa for ; Mon, 19 Nov 2012 20:55:10 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id CC8C721F87E1 for ; Mon, 19 Nov 2012 20:55:07 -0800 (PST) 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 qAK4t4r8026535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Nov 2012 23:55:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353387305; bh=z7ISv9W9TuMLtRwKU7Pcg1TPaTqiItMIBo0wmXlBrHE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=G8LeM4NaIoUk63+EThiZSsv5ymsgLCzXeXjUbIHbnnOlwz7AdKfTwTbiaCP/OTyLy WAXzu5eY+61V7jQvKtFTqm9UurlX3O6wauLv15TqJRH4M/iFzHTcU0esC3dVnzbNcr mmREnLmPSdTT7J/kCM8iy4iIJIX7jfjqvUvBs9RY= From: "Paul E. Jones" To: "'Goix Laurent Walter'" , "'Dick Hardt'" References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> In-Reply-To: Date: Mon, 19 Nov 2012 23:55:13 -0500 Message-ID: <024301cdc6db$3aed2550$b0c76ff0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0244_01CDC6B1.52171D50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI/YWaFkAYvx4DQsUUjuXKAy/yifQJJ+dZ9Ajy5+20BY9p1VAJ+l/RsAmfvVTQB2jbl4gLBmsrkAatQWkqWhi/U8A== Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Tue, 20 Nov 2012 04:55:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0244_01CDC6B1.52171D50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0245_01CDC6B1.52171D50" ------=_NextPart_001_0245_01CDC6B1.52171D50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Walter, =20 For the link relations=E2=80=A6 this gets tough. I could certainly = replace: http://webfinger.net/rel/profile-page with http://example.com/rel/profile-page =20 However, the former is really used today. I think we can be fairly safe = in assuming =E2=80=9Cvcard=E2=80=9D is going to exist one day. We can = probably agree that =E2=80=9Cblog=E2=80=9D will exist. I could make = that one change. But, what about the webfinger.net URIs? Those are = real, but there is nothing I can reference. Since they are URIs rels, = it should be expected. =20 For the text in section 3, I think you are referring to the bit about = IRIs? I forgot who provided that text, but it has been there for a = while and I didn=E2=80=99t write it. I, too, think it=E2=80=99s = unnecessary at this point, but=E2=80=A6 what is the preference of the = group? (Especially whomever provided the text in the first place.) =20 For 4.1, I really meant =E2=80=9Cany valid alias=E2=80=9D. Not all URIs = for a user are aliases that will return the same content. In the = follow-on sentence, I refer explicitly to the alias shown in the = example. =20 In 5.2, the =E2=80=9Cexpires=E2=80=9D element is supposed to come first. = This is an error in RFC 6415. =20 Paul =20 From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]=20 Sent: Monday, November 19, 2012 6:14 AM To: Paul E. Jones; Dick Hardt Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Subject: R: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt =20 Very clean spec now, thanks paul for this huge cleanup! =20 i also believe that we should be careful with the link rels in the = examples. Whenever the link rels mentioned are tokens and truly exist, I = would suggest to reference the specific spec. in other cases we could = either use uris under some example.net namespace, or simply state that = the token used is fictitious at the time of writing. =20 Some other minor comments: - In section 3 I have not clear the purpose of the educational = paragraph on link rels and the effective relation with webfinger based = on the current text. Could we remove it? - In section 4.1 you mention =E2=80=9Cany valid alias for the = user=E2=80=9D. It may be cleaner to state =E2=80=9Cany valid URI as = alias for the user=E2=80=9D to emphasize the usage of uris - In section 5.2 I would suggest to invert the = =E2=80=9Cexpires=E2=80=9D and =E2=80=9Csubject=E2=80=9D bullets to = mention required elements first. =20 =20 Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = Per conto di Paul E. Jones Inviato: domenica 18 novembre 2012 23.43 A: Dick Hardt Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Oggetto: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt =20 Dick, The first example is fairly meaningful in that most of the rels are in = use. The vcard one is not, but I'd like to see that defined. I'd be OK = with using the token 'blog' if we're going to agree on that. The second example does not use real values, but it is important in that = it shows use of properties. The third example is important in that it related to non-humans. We are supposed to get one more example related to OpenID Connect, but = that is not in there yet. Paul _____ =20 From: Dick Hardt Sent: Sun Nov 18 17:22:37 EST 2012 To: "Paul E. Jones" Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt Hi Paul =20 I agree it should be separate drafts. I'd be willing to edit if there is = interest. My interest in WebFinger is as a consumer much more than a = publisher - so I don't feel I am a domain expert. =20 Is it possible to have meaningful examples with existing "rel" values, = or do we need to have some others defined to have meaningful examples? =20 -- Dick =20 On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" = wrote: =20 Dick, =20 These should be separate drafts. I agree =E2=80=9Cblog=E2=80=9D is = good, but there are surely more. A lot of good ones are defined under = webfinger.net, too. =20 But I would really prefer to not slow down this draft with addition of = link relation values. If somebody (you?) wants to start a WebFinger = Link Relations document, I think it would be timely. =20 Paul =20 =20 PEJ: They could. The challenge is that we have no other URI type = defined for this purpose. For! the examples, we have a chicken and egg = problem. =20 Let's define some then! This is the one area that is vague and IMHO is a = barrier to adoption. What should the "rel" values be for items that I = want to publish? If we don't spec the common ones, we will end up with = several different identifiers for the same thing. Challenge of course is = that getting agreement on schema is always fun, but better to have some = that will be used that are not already defined. =20 Need to add an IANA section ! for that of course. =20 "blog" is a good one :) =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 = =C3=A8 necessario.=20 =20 ------=_NextPart_001_0245_01CDC6B1.52171D50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Walter,

 

For the link relations=E2=80=A6 this gets tough.=C2=A0 I could = certainly replace:

http://webfinger.net/rel/profile-page

with

http://example.com/rel/profile-page

 

However, the former is really used today.=C2=A0 I think we can be = fairly safe in assuming =E2=80=9Cvcard=E2=80=9D is going to exist one = day.=C2=A0 We can probably agree that =E2=80=9Cblog=E2=80=9D will = exist.=C2=A0 I could make that one change.=C2=A0 But, what about the = webfinger.net URIs?=C2=A0 Those are real, but there is nothing I can = reference.=C2=A0 Since they are URIs rels, it should be = expected.

 

For the text in section 3, I think you are referring to the bit about = IRIs?=C2=A0 I forgot who provided that text, but it has been there for a = while and I didn=E2=80=99t write it.=C2=A0 I, too, think it=E2=80=99s = unnecessary at this point, but=E2=80=A6 what is the preference of the = group? =C2=A0(Especially whomever provided the text in the first = place.)

 

For 4.1, I really meant =E2=80=9Cany valid alias=E2=80=9D.=C2=A0 Not = all URIs for a user are aliases that will return the same content.=C2=A0 = In the follow-on sentence, I refer explicitly to the alias shown in the = example.

 

In 5.2, the =E2=80=9Cexpires=E2=80=9D element is supposed to come = first.=C2=A0 This is an error in RFC 6415.

 

Paul

 

From:= = Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] =
Sent: Monday, November 19, 2012 6:14 AM
To: Paul E. = Jones; Dick Hardt
Cc: webfinger@googlegroups.com; = apps-discuss@ietf.org
Subject: R: [apps-discuss] New = draft-ietf-appsawg-webfinger-03.txt

 

Very clean spec now, thanks paul for this huge = cleanup!

 

i also believe that we should be careful with the link rels in the = examples. Whenever the link rels mentioned are tokens and truly exist, I = would suggest to reference the specific spec. in other cases we could = either use uris under some example.net namespace, or simply state that = the token used is fictitious at the time of = writing.

 

Some other minor comments:

-          = In section 3 I have not clear the purpose of the educational = paragraph on link rels and the effective relation with webfinger based = on the current text. Could we remove it?

-          = In section 4.1 you mention =E2=80=9Cany valid alias for the = user=E2=80=9D. It may be cleaner to state =E2=80=9Cany valid URI as = alias for the user=E2=80=9D to emphasize the usage of = uris

-          = In section 5.2 I would suggest to invert the = =E2=80=9Cexpires=E2=80=9D and =E2=80=9Csubject=E2=80=9D bullets to = mention required elements first.

 

 

Da: apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-bounces= @ietf.org] Per conto di Paul E. Jones
Inviato: = domenica 18 novembre 2012 = 23.43
A: Dick Hardt
Cc: webfinger@googlegroups.com= ; apps-discuss@ietf.org
Ogg= etto: Re: [apps-discuss] New = draft-ietf-appsawg-webfinger-03.txt

 

Dick,

The first example is fairly meaningful in that = most of the rels are in use. The vcard one is not, but I'd like to see = that defined. I'd be OK with using the token 'blog' if we're going to = agree on that.

The second example does not use real values, but = it is important in that it shows use of properties.

The third = example is important in that it related to non-humans.

We are = supposed to get one more example related to OpenID Connect, but that is = not in there yet.

Paul

From:= Dick Hardt = <dick.hardt@gmail.com>
S= ent: Sun Nov 18 17:22:37 EST 2012
To: "Paul E. = Jones" <paulej@packetizer.com>
Cc: webfinger@googlegroups.com= , apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] New = draft-ietf-appsawg-webfinger-03.txt


Hi = Paul

 

I agree it should be separate drafts. = I'd be willing to edit if there is interest. My interest in WebFinger is = as a consumer much more than a publisher - so I don't feel I am a domain = expert.

 

Is it possible to have meaningful = examples with existing "rel" values, or do we need to have = some others defined to have meaningful = examples?

 

-- = Dick

 

On Nov 18, 2012, at 2:02 PM, = "Paul E. Jones" <paulej@packetizer.com> = wrote:

 

Dick,

 

These should be separate drafts.  I agree =E2=80=9Cblog=E2=80=9D = is good, but there are surely more.  A lot of good ones are defined = under webfinger.net, = too.

 

But I would really prefer to not slow down this draft with addition = of link relation values.  If somebody (you?) wants to start a = WebFinger Link Relations document, I think it would be = timely.

 

Paul

 

 

PEJ: They could.  The challenge is that we have no other URI = type defined for this purpose.  For! the examples, we have a = chicken and egg = problem.

 =

Let's define = some then! This is the one area that is vague and IMHO is a barrier to = adoption. What should the "rel" values be for items that I = want to publish? If we don't spec the common ones, we will end up with = several different identifiers for the same thing. Challenge of course is = that getting agreement on schema is always fun, but better to have some = that will be used that are not already = defined.

 

Need to add an IANA section ! for = that of = course.

 

"blog" is a good one = :)

 

= 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 =C3=A8 = necessario.=

 

------=_NextPart_001_0245_01CDC6B1.52171D50-- ------=_NextPart_000_0244_01CDC6B1.52171D50 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_0244_01CDC6B1.52171D50-- From paulej@packetizer.com Mon Nov 19 21:00: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 721B821F8713 for ; Mon, 19 Nov 2012 21:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.409, 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 261QYiV7n9AH for ; Mon, 19 Nov 2012 21:00:29 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4F22421E8050 for ; Mon, 19 Nov 2012 21:00:29 -0800 (PST) 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 qAK50R8u026783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Nov 2012 00:00:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353387627; bh=VsqMp5gCGK7+pKf0XBGr0/Xxe2d2668oSGd4ozPXfBw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=dRT1XI7tt5gjiqcBPAiueuSTm7QHLXOBB+Ud38q/FByOGtBKCfgRAl3cJvTYNZTqa f0xX+DiyvgysjCpdabPlnsVBJQ1rYMpDOyKDW1eEj0qVmTi99CQ0FgNPxUOKOttAJg NkFMz7lSUMY5hvaVTjGHrjj+xqedLicumt0PjBn8= From: "Paul E. Jones" To: "'James M Snell'" , "'Dick Hardt'" References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> In-Reply-To: Date: Tue, 20 Nov 2012 00:00:36 -0500 Message-ID: <025e01cdc6db$faf26720$f0d73560$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_025F_01CDC6B2.121EA910" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI/YWaFkAYvx4DQsUUjuXKAy/yifQJJ+dZ9Ajy5+20BY9p1VAJ+l/RsAmfvVTQB2jbl4gLLVYb6lpM/odA= Content-Language: en-us Cc: webfinger@googlegroups.com, 'IETF Apps Discuss' Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Tue, 20 Nov 2012 05:00:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_025F_01CDC6B2.121EA910 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable James, =20 I think the =E2=80=9Cupdates-from=E2=80=9D was intended to be an ATOM = feed, though I might be wrong. In your example, you show a blog. But, = at the same time we want to define =E2=80=9Cblog=E2=80=9D as its own = rel. =20 I think it=E2=80=99s important that we have a very narrow scope for any = rel. I don=E2=80=99t care what the values are, but we need to ensure = there is no ambiguity in what a given token means. =20 Paul =20 From: James M Snell [mailto:jasnell@gmail.com]=20 Sent: Monday, November 19, 2012 12:36 PM To: Dick Hardt Cc: Paul E. Jones; webfinger@googlegroups.com; IETF Apps Discuss Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt =20 Just a quick note on this... I already have the existing "Additional = Link Relations" draft [1] in progress (currently submitted as an = independent submission) that registers link relations such as "about", = "type", "terms-of-service", "privacy-policy" and "preview". It would be = possible to pull this draft back and add a few more link relation types = to it if necessary. We would just need to identify the set of new link = rels and I could very easily drop them in or write up a quick second = document based on the same simple template. =20 [1] http://tools.ietf.org/html/draft-snell-additional-link-relations-06 =20 That said, the "about" link relation can be used to link to both = profile-page and vcard type resources... differentiated, of course, by = the media type of the linked resource.=20 =20 Also... We need to be careful not to get too specific with link relation = labels. The rel values themselves are intended to state the nature of = the relationship and not the type of resource it is. Having something = like = {"rel":"updates","href":"http://example.org/my/blog","type":"text/html"} = should be generally preferable over something like = {"rel":"blog","href":"http://example.org/my/blog"}.=20 =20 - James =20 On Sun, Nov 18, 2012 at 2:22 PM, Dick Hardt = wrote: Hi Paul =20 I agree it should be separate drafts. I'd be willing to edit if there is = interest. My interest in WebFinger is as a consumer much more than a = publisher - so I don't feel I am a domain expert. =20 Is it possible to have meaningful examples with existing "rel" values, = or do we need to have some others defined to have meaningful examples? =20 -- Dick =20 On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" = wrote: Dick, =20 These should be separate drafts. I agree =E2=80=9Cblog=E2=80=9D is = good, but there are surely more. A lot of good ones are defined under = webfinger.net, too. =20 But I would really prefer to not slow down this draft with addition of = link relation values. If somebody (you?) wants to start a WebFinger = Link Relations document, I think it would be timely. =20 Paul =20 =20 PEJ: They could. The challenge is that we have no other URI type = defined for this purpose. For the examples, we have a chicken and egg = problem. =20 Let's define some then! This is the one area that is vague and IMHO is a = barrier to adoption. What should the "rel" values be for items that I = want to publish? If we don't spec the common ones, we will end up with = several different identifiers for the same thing. Challenge of course is = that getting agreement on schema is always fun, but better to have some = that will be used that are not already defined. =20 Need to add an IANA section for that of course. =20 "blog" is a good one :) =20 _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss =20 ------=_NextPart_000_025F_01CDC6B2.121EA910 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

James,

 

I think the =E2=80=9Cupdates-from=E2=80=9D was intended to be an ATOM = feed, though I might be wrong.=C2=A0 In your example, you show a = blog.=C2=A0 But, at the same time we want to define = =E2=80=9Cblog=E2=80=9D as its own rel.

 

I think it=E2=80=99s important that we have a very narrow scope for = any rel.=C2=A0 I don=E2=80=99t care what the values are, but we need to = ensure there is no ambiguity in what a given token = means.

 

Paul

 

From:= = James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, = November 19, 2012 12:36 PM
To: Dick Hardt
Cc: Paul = E. Jones; webfinger@googlegroups.com; IETF Apps = Discuss
Subject: Re: [apps-discuss] New = draft-ietf-appsawg-webfinger-03.txt

 

Just a quick note on this... I = already have the existing "Additional Link Relations" draft = [1] in progress (currently submitted as an independent submission) that = registers link relations such as "about", "type", = "terms-of-service", "privacy-policy" and = "preview". It would be possible to pull this draft back and = add a few more link relation types to it if necessary. We would just = need to identify the set of new link rels and I could very easily drop = them in or write up a quick second document based on the same simple = template.

 

- James

 

On Sun, Nov 18, 2012 at 2:22 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:

Hi = Paul

 

I = agree it should be separate drafts. I'd be willing to edit if there is = interest. My interest in WebFinger is as a consumer much more than a = publisher - so I don't feel I am a domain = expert.

 

Is it possible to have meaningful examples with = existing "rel" values, or do we need to have some others = defined to have meaningful examples?

 

-- = Dick

 

On = Nov 18, 2012, at 2:02 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:



Dick,

 

These should be separate drafts.  I agree =E2=80=9Cblog=E2=80=9D = is good, but there are surely more.  A lot of good ones are defined = under webfinger.net, = too.

 

But I would really prefer to not slow down this draft with addition = of link relation values.  If somebody (you?) wants to start a = WebFinger Link Relations document, I think it would be = timely.

 

Paul

 

 

PEJ: They could.  The challenge is that we have no other URI = type defined for this purpose.  For the examples, we have a chicken = and egg = problem.

 

Let's define some then! This is the one area that is = vague and IMHO is a barrier to adoption. What should the "rel" = values be for items that I want to publish? If we don't spec the common = ones, we will end up with several different identifiers for the same = thing. Challenge of course is that getting agreement on schema is always = fun, but better to have some that will be used that are not already = defined.

 

Need to add an IANA section for that of = course.

 

"blog" is a good one = :)

 


______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 

------=_NextPart_000_025F_01CDC6B2.121EA910-- From laurentwalter.goix@telecomitalia.it Tue Nov 20 05: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 4B43F21F862C for ; Tue, 20 Nov 2012 05:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[AWL=0.331, 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 SDx-X+iGvthF for ; Tue, 20 Nov 2012 05:39:29 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id D915421F8609 for ; Tue, 20 Nov 2012 05:39:28 -0800 (PST) Content-Type: multipart/mixed; boundary="_efc1a210-3699-4238-b707-1727e5a9f31e_" 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.279.5; Tue, 20 Nov 2012 14:39:15 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Tue, 20 Nov 2012 14:39:05 +0100 From: Goix Laurent Walter To: "Paul E. Jones" , 'James M Snell' , 'Dick Hardt' Date: Tue, 20 Nov 2012 14:39:03 +0100 Thread-Topic: [apps-discuss] Link rels Thread-Index: AQI/YWaFkAYvx4DQsUUjuXKAy/yifQJJ+dZ9Ajy5+20BY9p1VAJ+l/RsAmfvVTQB2jbl4gLLVYb6lpM/odCAAI7WQA== Message-ID: References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> <025e01cdc6db$faf26720$f0d73560$@packetizer.com> In-Reply-To: <025e01cdc6db$faf26720$f0d73560$@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 MIME-Version: 1.0 Cc: "webfinger@googlegroups.com" , 'IETF Apps Discuss' Subject: [apps-discuss] Link rels 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, 20 Nov 2012 13:39:31 -0000 --_efc1a210-3699-4238-b707-1727e5a9f31e_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A5575B44GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5575B44GRFMBX704BA02_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIG5hcnJvdyAmIHVuYW1iaWd1b3VzIHJlbHMgd2l0aCBjbGVhciBzZW1hbnRpY3MgdGhh dCBndWFyYW50ZWUgaW50ZXJvcCAoYnR3IEkgdGhpbmsgd2UgYXJlIGRlcml2aW5nIGZyb20gdGhl IGNvcmUgd2ViZmluZ2VyIGRpc2N1c3Npb24gaGVyZSBzbyBJIGNoYW5nZWQgdGhlIHN1YmplY3Qp DQoNClRoZSBsaW5rIHJlbHMgcHJvcG9zZWQgYnkgamFtZXMgaW4gdGhlIGRyYWZ0IGFyZSBtZWFu aW5nZnVsIChJIGRvIGhhdmUgc29tZSBkb3VidHMgb24gYWJvdXQgdnMgcmVsYXRlZCwgd2hpY2gg aXMgYWxyZWFkeSByZWdpc3RlcmVkKS4g4oCcYXZhdGFy4oCdIGNvdWxkIGJlIGFkZGVkIHRoZXJl IGluIGNhc2UgdGhlIGRyYWZ0IGNhbiBzZXJ2ZSBhcyBiYXNpcyBmb3IgdGhpcyBhY3Rpdml0eS4N Cg0KRm9yIOKAnHVwZGF0ZXMtZnJvbeKAnSBpbmRlZWQgdGhlc2UgYXJlIHNwZWNpZmljIHRvIGFj dGl2aXR5IHN0cmVhbXMgcmVwcmVzZW50ZWQgaW4gYXRvbSwgYW5kIHNob3VsZCBub3QgdmFyeSB0 aGVpciBtZWFuaW5nIChiZXNpZGVzIGEgdHlwZSBwYXJhbWV0ZXIgd2hpY2ggY291bGQgYWxsb3cg Zm9yIGpzb24gYXMgd2VsbCk6IGZvciB0aGlzIHJlYXNvbiB0aGUgcmVmZXJlbmNlIHRvIGFjdGl2 aXR5c3RyZWFtcyBjb3VsZCBiZSBzdHJvbmdlciBpbW8uIG1heWJlIOKAnGFjdGl2aXRpZXPigJ0/ DQoNCndhbHRlcg0KDQpEYTogYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzph cHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRpIFBhdWwgRS4gSm9uZXMN CkludmlhdG86IG1hcnRlZMOsIDIwIG5vdmVtYnJlIDIwMTIgNi4wMQ0KQTogJ0phbWVzIE0gU25l bGwnOyAnRGljayBIYXJkdCcNCkNjOiB3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbTsgJ0lFVEYg QXBwcyBEaXNjdXNzJw0KT2dnZXR0bzogUmU6IFthcHBzLWRpc2N1c3NdIE5ldyBkcmFmdC1pZXRm LWFwcHNhd2ctd2ViZmluZ2VyLTAzLnR4dA0KDQpKYW1lcywNCg0KSSB0aGluayB0aGUg4oCcdXBk YXRlcy1mcm9t4oCdIHdhcyBpbnRlbmRlZCB0byBiZSBhbiBBVE9NIGZlZWQsIHRob3VnaCBJIG1p Z2h0IGJlIHdyb25nLiAgSW4geW91ciBleGFtcGxlLCB5b3Ugc2hvdyBhIGJsb2cuICBCdXQsIGF0 IHRoZSBzYW1lIHRpbWUgd2Ugd2FudCB0byBkZWZpbmUg4oCcYmxvZ+KAnSBhcyBpdHMgb3duIHJl bC4NCg0KSSB0aGluayBpdOKAmXMgaW1wb3J0YW50IHRoYXQgd2UgaGF2ZSBhIHZlcnkgbmFycm93 IHNjb3BlIGZvciBhbnkgcmVsLiAgSSBkb27igJl0IGNhcmUgd2hhdCB0aGUgdmFsdWVzIGFyZSwg YnV0IHdlIG5lZWQgdG8gZW5zdXJlIHRoZXJlIGlzIG5vIGFtYmlndWl0eSBpbiB3aGF0IGEgZ2l2 ZW4gdG9rZW4gbWVhbnMuDQoNClBhdWwNCg0KRnJvbTogSmFtZXMgTSBTbmVsbCBbbWFpbHRvOmph c25lbGxAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxOSwgMjAxMiAxMjozNiBQ TQ0KVG86IERpY2sgSGFyZHQNCkNjOiBQYXVsIEUuIEpvbmVzOyB3ZWJmaW5nZXJAZ29vZ2xlZ3Jv dXBzLmNvbTsgSUVURiBBcHBzIERpc2N1c3MNClN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBO ZXcgZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0wMy50eHQNCg0KSnVzdCBhIHF1aWNrIG5v dGUgb24gdGhpcy4uLiBJIGFscmVhZHkgaGF2ZSB0aGUgZXhpc3RpbmcgIkFkZGl0aW9uYWwgTGlu ayBSZWxhdGlvbnMiIGRyYWZ0IFsxXSBpbiBwcm9ncmVzcyAoY3VycmVudGx5IHN1Ym1pdHRlZCBh cyBhbiBpbmRlcGVuZGVudCBzdWJtaXNzaW9uKSB0aGF0IHJlZ2lzdGVycyBsaW5rIHJlbGF0aW9u cyBzdWNoIGFzICJhYm91dCIsICJ0eXBlIiwgInRlcm1zLW9mLXNlcnZpY2UiLCAicHJpdmFjeS1w b2xpY3kiIGFuZCAicHJldmlldyIuIEl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIHB1bGwgdGhpcyBk cmFmdCBiYWNrIGFuZCBhZGQgYSBmZXcgbW9yZSBsaW5rIHJlbGF0aW9uIHR5cGVzIHRvIGl0IGlm IG5lY2Vzc2FyeS4gV2Ugd291bGQganVzdCBuZWVkIHRvIGlkZW50aWZ5IHRoZSBzZXQgb2YgbmV3 IGxpbmsgcmVscyBhbmQgSSBjb3VsZCB2ZXJ5IGVhc2lseSBkcm9wIHRoZW0gaW4gb3Igd3JpdGUg dXAgYSBxdWljayBzZWNvbmQgZG9jdW1lbnQgYmFzZWQgb24gdGhlIHNhbWUgc2ltcGxlIHRlbXBs YXRlLg0KDQpbMV0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc25lbGwtYWRkaXRp b25hbC1saW5rLXJlbGF0aW9ucy0wNg0KDQpUaGF0IHNhaWQsIHRoZSAiYWJvdXQiIGxpbmsgcmVs YXRpb24gY2FuIGJlIHVzZWQgdG8gbGluayB0byBib3RoIHByb2ZpbGUtcGFnZSBhbmQgdmNhcmQg dHlwZSByZXNvdXJjZXMuLi4gZGlmZmVyZW50aWF0ZWQsIG9mIGNvdXJzZSwgYnkgdGhlIG1lZGlh IHR5cGUgb2YgdGhlIGxpbmtlZCByZXNvdXJjZS4NCg0KQWxzby4uLiBXZSBuZWVkIHRvIGJlIGNh cmVmdWwgbm90IHRvIGdldCB0b28gc3BlY2lmaWMgd2l0aCBsaW5rIHJlbGF0aW9uIGxhYmVscy4g VGhlIHJlbCB2YWx1ZXMgdGhlbXNlbHZlcyBhcmUgaW50ZW5kZWQgdG8gc3RhdGUgdGhlIG5hdHVy ZSBvZiB0aGUgcmVsYXRpb25zaGlwIGFuZCBub3QgdGhlIHR5cGUgb2YgcmVzb3VyY2UgaXQgaXMu IEhhdmluZyBzb21ldGhpbmcgbGlrZSB7InJlbCI6InVwZGF0ZXMiLCJocmVmIjoiaHR0cDovL2V4 YW1wbGUub3JnL215L2Jsb2ciLCJ0eXBlIjoidGV4dC9odG1sIn0gc2hvdWxkIGJlIGdlbmVyYWxs eSBwcmVmZXJhYmxlIG92ZXIgc29tZXRoaW5nIGxpa2UgeyJyZWwiOiJibG9nIiwiaHJlZiI6Imh0 dHA6Ly9leGFtcGxlLm9yZy9teS9ibG9nIn0uDQoNCi0gSmFtZXMNCg0KT24gU3VuLCBOb3YgMTgs IDIwMTIgYXQgMjoyMiBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBQYXVsDQoNCkkgYWdyZWUgaXQgc2hv dWxkIGJlIHNlcGFyYXRlIGRyYWZ0cy4gSSdkIGJlIHdpbGxpbmcgdG8gZWRpdCBpZiB0aGVyZSBp cyBpbnRlcmVzdC4gTXkgaW50ZXJlc3QgaW4gV2ViRmluZ2VyIGlzIGFzIGEgY29uc3VtZXIgbXVj aCBtb3JlIHRoYW4gYSBwdWJsaXNoZXIgLSBzbyBJIGRvbid0IGZlZWwgSSBhbSBhIGRvbWFpbiBl eHBlcnQuDQoNCklzIGl0IHBvc3NpYmxlIHRvIGhhdmUgbWVhbmluZ2Z1bCBleGFtcGxlcyB3aXRo IGV4aXN0aW5nICJyZWwiIHZhbHVlcywgb3IgZG8gd2UgbmVlZCB0byBoYXZlIHNvbWUgb3RoZXJz IGRlZmluZWQgdG8gaGF2ZSBtZWFuaW5nZnVsIGV4YW1wbGVzPw0KDQotLSBEaWNrDQoNCk9uIE5v diAxOCwgMjAxMiwgYXQgMjowMiBQTSwgIlBhdWwgRS4gSm9uZXMiIDxwYXVsZWpAcGFja2V0aXpl ci5jb208bWFpbHRvOnBhdWxlakBwYWNrZXRpemVyLmNvbT4+IHdyb3RlOg0KDQpEaWNrLA0KDQpU aGVzZSBzaG91bGQgYmUgc2VwYXJhdGUgZHJhZnRzLiAgSSBhZ3JlZSDigJxibG9n4oCdIGlzIGdv b2QsIGJ1dCB0aGVyZSBhcmUgc3VyZWx5IG1vcmUuICBBIGxvdCBvZiBnb29kIG9uZXMgYXJlIGRl ZmluZWQgdW5kZXIgd2ViZmluZ2VyLm5ldDxodHRwOi8vd2ViZmluZ2VyLm5ldD4sIHRvby4NCg0K QnV0IEkgd291bGQgcmVhbGx5IHByZWZlciB0byBub3Qgc2xvdyBkb3duIHRoaXMgZHJhZnQgd2l0 aCBhZGRpdGlvbiBvZiBsaW5rIHJlbGF0aW9uIHZhbHVlcy4gIElmIHNvbWVib2R5ICh5b3U/KSB3 YW50cyB0byBzdGFydCBhIFdlYkZpbmdlciBMaW5rIFJlbGF0aW9ucyBkb2N1bWVudCwgSSB0aGlu ayBpdCB3b3VsZCBiZSB0aW1lbHkuDQoNClBhdWwNCg0KDQpQRUo6IFRoZXkgY291bGQuICBUaGUg Y2hhbGxlbmdlIGlzIHRoYXQgd2UgaGF2ZSBubyBvdGhlciBVUkkgdHlwZSBkZWZpbmVkIGZvciB0 aGlzIHB1cnBvc2UuICBGb3IgdGhlIGV4YW1wbGVzLCB3ZSBoYXZlIGEgY2hpY2tlbiBhbmQgZWdn IHByb2JsZW0uDQoNCkxldCdzIGRlZmluZSBzb21lIHRoZW4hIFRoaXMgaXMgdGhlIG9uZSBhcmVh IHRoYXQgaXMgdmFndWUgYW5kIElNSE8gaXMgYSBiYXJyaWVyIHRvIGFkb3B0aW9uLiBXaGF0IHNo b3VsZCB0aGUgInJlbCIgdmFsdWVzIGJlIGZvciBpdGVtcyB0aGF0IEkgd2FudCB0byBwdWJsaXNo PyBJZiB3ZSBkb24ndCBzcGVjIHRoZSBjb21tb24gb25lcywgd2Ugd2lsbCBlbmQgdXAgd2l0aCBz ZXZlcmFsIGRpZmZlcmVudCBpZGVudGlmaWVycyBmb3IgdGhlIHNhbWUgdGhpbmcuIENoYWxsZW5n ZSBvZiBjb3Vyc2UgaXMgdGhhdCBnZXR0aW5nIGFncmVlbWVudCBvbiBzY2hlbWEgaXMgYWx3YXlz IGZ1biwgYnV0IGJldHRlciB0byBoYXZlIHNvbWUgdGhhdCB3aWxsIGJlIHVzZWQgdGhhdCBhcmUg bm90IGFscmVhZHkgZGVmaW5lZC4NCg0KTmVlZCB0byBhZGQgYW4gSUFOQSBzZWN0aW9uIGZvciB0 aGF0IG9mIGNvdXJzZS4NCg0KImJsb2ciIGlzIGEgZ29vZCBvbmUgOikNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYXBwcy1kaXNjdXNzIG1haWxp bmcgbGlzdA0KYXBwcy1kaXNjdXNzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0K DQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNj bHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBv IHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVl c3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJp YXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVu dGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBl IGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4g RGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBp cyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0 aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0KW2NpZDowMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwM0BUSS5EaXNjbGFpbWVyXVJpc3BldHRhIGwnYW1iaWVudGUuIE5v biBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4NCg0K --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5575B44GRFMBX704BA02_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4NCjwhLS0N CiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFu b3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQog cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uU3Rp bGVNZXNzYWdnaW9EaVBvc3RhRWxldHRyb25pY2ExOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5TdGlsZU1lc3NhZ2dpb0RpUG9zdGFFbGV0dHJvbmljYTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IlNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mIzQzOzEgZm9yIG5hcnJvdyAmYW1wOyB1bmFtYmln dW91cyByZWxzIHdpdGggY2xlYXIgc2VtYW50aWNzIHRoYXQgZ3VhcmFudGVlIGludGVyb3AgKGJ0 dyBJIHRoaW5rIHdlIGFyZSBkZXJpdmluZyBmcm9tIHRoZSBjb3JlIHdlYmZpbmdlciBkaXNjdXNz aW9uDQogaGVyZSBzbyBJIGNoYW5nZWQgdGhlIHN1YmplY3QpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7DQpjb2xvcjojMUY0OTdEIj5UaGUgbGluayByZWxzIHByb3Bvc2VkIGJ5IGphbWVzIGluIHRo ZSBkcmFmdCBhcmUgbWVhbmluZ2Z1bCAoSSBkbyBoYXZlIHNvbWUgZG91YnRzIG9uIGFib3V0IHZz IHJlbGF0ZWQsIHdoaWNoIGlzIGFscmVhZHkgcmVnaXN0ZXJlZCkuIOKAnGF2YXRhcuKAnQ0KIGNv dWxkIGJlIGFkZGVkIHRoZXJlIGluIGNhc2UgdGhlIGRyYWZ0IGNhbiBzZXJ2ZSBhcyBiYXNpcyBm b3IgdGhpcyBhY3Rpdml0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi PkZvciDigJx1cGRhdGVzLWZyb23igJ0gaW5kZWVkIHRoZXNlIGFyZSBzcGVjaWZpYyB0byBhY3Rp dml0eSBzdHJlYW1zIHJlcHJlc2VudGVkIGluIGF0b20sIGFuZCBzaG91bGQgbm90IHZhcnkgdGhl aXIgbWVhbmluZyAoYmVzaWRlcyBhIHR5cGUgcGFyYW1ldGVyDQogd2hpY2ggY291bGQgYWxsb3cg Zm9yIGpzb24gYXMgd2VsbCk6IGZvciB0aGlzIHJlYXNvbiB0aGUgcmVmZXJlbmNlIHRvIGFjdGl2 aXR5c3RyZWFtcyBjb3VsZCBiZSBzdHJvbmdlciBpbW8uIG1heWJlIOKAnGFjdGl2aXRpZXPigJ0/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj53YWx0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJJVCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vn b2UgVUkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGE6PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJJVCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2Ug VUkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5QZXIgY29u dG8gZGkgPC9iPlBhdWwgRS4gSm9uZXM8YnI+DQo8Yj5JbnZpYXRvOjwvYj4gbWFydGVkw6wgMjAg bm92ZW1icmUgMjAxMiA2LjAxPGJyPg0KPGI+QTo8L2I+ICdKYW1lcyBNIFNuZWxsJzsgJ0RpY2sg SGFyZHQnPGJyPg0KPGI+Q2M6PC9iPiB3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbTsgJ0lFVEYg QXBwcyBEaXNjdXNzJzxicj4NCjxiPk9nZ2V0dG86PC9iPiBSZTogW2FwcHMtZGlzY3Vzc10gTmV3 IGRyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXItMDMudHh0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkphbWVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGUg4oCcdXBkYXRlcy1mcm9t4oCdIHdhcyBpbnRl bmRlZCB0byBiZSBhbiBBVE9NIGZlZWQsIHRob3VnaCBJIG1pZ2h0IGJlIHdyb25nLiZuYnNwOyBJ biB5b3VyIGV4YW1wbGUsIHlvdSBzaG93IGEgYmxvZy4mbmJzcDsgQnV0LCBhdCB0aGUgc2FtZSB0 aW1lDQogd2Ugd2FudCB0byBkZWZpbmUg4oCcYmxvZ+KAnSBhcyBpdHMgb3duIHJlbC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgaXTigJlzIGltcG9ydGFu dCB0aGF0IHdlIGhhdmUgYSB2ZXJ5IG5hcnJvdyBzY29wZSBmb3IgYW55IHJlbC4mbmJzcDsgSSBk b27igJl0IGNhcmUgd2hhdCB0aGUgdmFsdWVzIGFyZSwgYnV0IHdlIG5lZWQgdG8gZW5zdXJlIHRo ZXJlIGlzIG5vIGFtYmlndWl0eQ0KIGluIHdoYXQgYSBnaXZlbiB0b2tlbiBtZWFucy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlBhdWw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gSmFtZXMgTSBTbmVsbCBbbWFpbHRvOmphc25lbGxAZ21haWwuY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTm92ZW1iZXIgMTksIDIwMTIgMTI6MzYgUE08YnI+ DQo8Yj5Ubzo8L2I+IERpY2sgSGFyZHQ8YnI+DQo8Yj5DYzo8L2I+IFBhdWwgRS4gSm9uZXM7IHdl YmZpbmdlckBnb29nbGVncm91cHMuY29tOyBJRVRGIEFwcHMgRGlzY3Vzczxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW2FwcHMtZGlzY3Vzc10gTmV3IGRyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5n ZXItMDMudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5KdXN0IGEgcXVpY2sgbm90ZSBvbiB0aGlz Li4uIEkgYWxyZWFkeSBoYXZlIHRoZSBleGlzdGluZyAmcXVvdDtBZGRpdGlvbmFsIExpbmsgUmVs YXRpb25zJnF1b3Q7IGRyYWZ0IFsxXSBpbiBwcm9ncmVzcyAoY3VycmVudGx5IHN1Ym1pdHRlZCBh cyBhbiBpbmRlcGVuZGVudCBzdWJtaXNzaW9uKSB0aGF0IHJlZ2lzdGVycyBsaW5rIHJlbGF0aW9u cw0KIHN1Y2ggYXMgJnF1b3Q7YWJvdXQmcXVvdDssICZxdW90O3R5cGUmcXVvdDssICZxdW90O3Rl cm1zLW9mLXNlcnZpY2UmcXVvdDssICZxdW90O3ByaXZhY3ktcG9saWN5JnF1b3Q7IGFuZCAmcXVv dDtwcmV2aWV3JnF1b3Q7LiBJdCB3b3VsZCBiZSBwb3NzaWJsZSB0byBwdWxsIHRoaXMgZHJhZnQg YmFjayBhbmQgYWRkIGEgZmV3IG1vcmUgbGluayByZWxhdGlvbiB0eXBlcyB0byBpdCBpZiBuZWNl c3NhcnkuIFdlIHdvdWxkIGp1c3QgbmVlZCB0byBpZGVudGlmeSB0aGUgc2V0IG9mIG5ldyBsaW5r IHJlbHMgYW5kIEkgY291bGQgdmVyeSBlYXNpbHkNCiBkcm9wIHRoZW0gaW4gb3Igd3JpdGUgdXAg YSBxdWljayBzZWNvbmQgZG9jdW1lbnQgYmFzZWQgb24gdGhlIHNhbWUgc2ltcGxlIHRlbXBsYXRl Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5b MV0mbmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zbmVsbC1h ZGRpdGlvbmFsLWxpbmstcmVsYXRpb25zLTA2Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1zbmVsbC1hZGRpdGlvbmFsLWxpbmstcmVsYXRpb25zLTA2PC9hPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoYXQgc2Fp ZCwgdGhlICZxdW90O2Fib3V0JnF1b3Q7IGxpbmsgcmVsYXRpb24gY2FuIGJlIHVzZWQgdG8gbGlu ayB0byBib3RoIHByb2ZpbGUtcGFnZSBhbmQgdmNhcmQgdHlwZSByZXNvdXJjZXMuLi4gZGlmZmVy ZW50aWF0ZWQsIG9mIGNvdXJzZSwgYnkgdGhlIG1lZGlhIHR5cGUgb2YgdGhlIGxpbmtlZCByZXNv dXJjZS4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5BbHNvLi4uIFdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBub3QgdG8gZ2V0 IHRvbyBzcGVjaWZpYyB3aXRoIGxpbmsgcmVsYXRpb24gbGFiZWxzLiBUaGUgcmVsIHZhbHVlcyB0 aGVtc2VsdmVzIGFyZSBpbnRlbmRlZCB0byBzdGF0ZSB0aGUgbmF0dXJlIG9mIHRoZSByZWxhdGlv bnNoaXAgYW5kIG5vdCB0aGUgdHlwZSBvZiByZXNvdXJjZQ0KIGl0IGlzLiBIYXZpbmcgc29tZXRo aW5nIGxpa2UgeyZxdW90O3JlbCZxdW90OzomcXVvdDt1cGRhdGVzJnF1b3Q7LCZxdW90O2hyZWYm cXVvdDs6JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUub3JnL215L2Jsb2ciPmh0dHA6Ly9l eGFtcGxlLm9yZy9teS9ibG9nPC9hPiZxdW90OywmcXVvdDt0eXBlJnF1b3Q7OiZxdW90O3RleHQv aHRtbCZxdW90O30gc2hvdWxkIGJlIGdlbmVyYWxseSBwcmVmZXJhYmxlIG92ZXIgc29tZXRoaW5n IGxpa2UmbmJzcDt7JnF1b3Q7cmVsJnF1b3Q7OiZxdW90O2Jsb2cmcXVvdDssJnF1b3Q7aHJlZiZx dW90OzomcXVvdDs8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5vcmcvbXkvYmxvZyI+aHR0cDovL2V4 YW1wbGUub3JnL215L2Jsb2c8L2E+JnF1b3Q7fS4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LSBK YW1lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+T24gU3VuLCBOb3YgMTgsIDIwMTIgYXQgMjoyMiBQTSwgRGljayBI YXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhp IFBhdWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFncmVlIGl0 IHNob3VsZCBiZSBzZXBhcmF0ZSBkcmFmdHMuIEknZCBiZSB3aWxsaW5nIHRvIGVkaXQgaWYgdGhl cmUgaXMgaW50ZXJlc3QuIE15IGludGVyZXN0IGluIFdlYkZpbmdlciBpcyBhcyBhIGNvbnN1bWVy IG11Y2ggbW9yZSB0aGFuIGEgcHVibGlzaGVyIC0gc28gSSBkb24ndCBmZWVsIEkgYW0gYSBkb21h aW4gZXhwZXJ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+SXMgaXQgcG9zc2libGUgdG8gaGF2ZSBtZWFuaW5nZnVsIGV4YW1wbGVzIHdpdGggZXhpc3Rp bmcgJnF1b3Q7cmVsJnF1b3Q7IHZhbHVlcywgb3IgZG8gd2UgbmVlZCB0byBoYXZlIHNvbWUgb3Ro ZXJzIGRlZmluZWQgdG8gaGF2ZSBtZWFuaW5nZnVsIGV4YW1wbGVzPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojODg4ODg4Ij4tLSBEaWNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gTm92IDE4LCAyMDEyLCBhdCAyOjAy IFBNLCAmcXVvdDtQYXVsIEUuIEpvbmVzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cGF1bGVq QHBhY2tldGl6ZXIuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGF1bGVqQHBhY2tldGl6ZXIuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+RGljayw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5UaGVzZSBzaG91bGQgYmUgc2VwYXJhdGUgZHJh ZnRzLiZuYnNwOyBJIGFncmVlIOKAnGJsb2figJ0gaXMgZ29vZCwgYnV0IHRoZXJlIGFyZSBzdXJl bHkgbW9yZS4mbmJzcDsgQSBsb3Qgb2YgZ29vZCBvbmVzIGFyZSBkZWZpbmVkIHVuZGVyJm5ic3A7 PGEgaHJlZj0iaHR0cDovL3dlYmZpbmdlci5uZXQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj53ZWJmaW5nZXIubmV0PC9zcGFuPjwvYT4sDQogdG9vLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi PkJ1dCBJIHdvdWxkIHJlYWxseSBwcmVmZXIgdG8gbm90IHNsb3cgZG93biB0aGlzIGRyYWZ0IHdp dGggYWRkaXRpb24gb2YgbGluayByZWxhdGlvbiB2YWx1ZXMuJm5ic3A7IElmIHNvbWVib2R5ICh5 b3U/KSB3YW50cyB0byBzdGFydCBhIFdlYkZpbmdlciBMaW5rDQogUmVsYXRpb25zIGRvY3VtZW50 LCBJIHRoaW5rIGl0IHdvdWxkIGJlIHRpbWVseS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5QYXVsPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojOTUzNzM1Ij5QRUo6IFRoZXkgY291 bGQuJm5ic3A7IFRoZSBjaGFsbGVuZ2UgaXMgdGhhdCB3ZSBoYXZlIG5vIG90aGVyIFVSSSB0eXBl IGRlZmluZWQgZm9yIHRoaXMgcHVycG9zZS4mbmJzcDsgRm9yIHRoZSBleGFtcGxlcywgd2UgaGF2 ZSBhIGNoaWNrZW4gYW5kIGVnZyBwcm9ibGVtLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TGV0J3MgZGVmaW5lIHNvbWUgdGhl biEgVGhpcyBpcyB0aGUgb25lIGFyZWEgdGhhdCBpcyB2YWd1ZSBhbmQgSU1ITyBpcyBhIGJhcnJp ZXIgdG8gYWRvcHRpb24uIFdoYXQgc2hvdWxkIHRoZSAmcXVvdDtyZWwmcXVvdDsgdmFsdWVzIGJl IGZvciBpdGVtcyB0aGF0IEkgd2FudCB0byBwdWJsaXNoPyBJZiB3ZSBkb24ndCBzcGVjIHRoZSBj b21tb24gb25lcywgd2Ugd2lsbCBlbmQgdXAgd2l0aCBzZXZlcmFsDQogZGlmZmVyZW50IGlkZW50 aWZpZXJzIGZvciB0aGUgc2FtZSB0aGluZy4gQ2hhbGxlbmdlIG9mIGNvdXJzZSBpcyB0aGF0IGdl dHRpbmcgYWdyZWVtZW50IG9uIHNjaGVtYSBpcyBhbHdheXMgZnVuLCBidXQgYmV0dGVyIHRvIGhh dmUgc29tZSB0aGF0IHdpbGwgYmUgdXNlZCB0aGF0IGFyZSBub3QgYWxyZWFkeSBkZWZpbmVkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+TmVlZCB0byBhZGQgYW4gSUFOQSBzZWN0aW9uIGZvciB0aGF0 IG9mIGNvdXJzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90O2Jsb2cmcXVvdDsgaXMgYSBn b29kIG9uZSA6KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmciPmFwcHMtZGlzY3Vzc0BpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2FwcHMtZGlzY3VzcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHN0eWxl IHR5cGU9InRleHQvY3NzIj4NCjwhLS0NCnNwYW4uR3JhbUUge21zby1zdHlsZS1uYW1lOiIiOw0K CW1zby1ncmFtLWU6eWVzO30NCi0tPg0KPC9zdHlsZT4NCjx0YWJsZSBzdHlsZT0id2lkdGg6NjAw cHg7Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0id2lkdGg6NTg1cHg7IGZvbnQtZmFtaWx5 OiBWZXJkYW5hLCBBcmlhbDsgZm9udC1zaXplOjEycHg7IGNvbG9yOiMwMDA7IHRleHQtYWxpZ246 IGp1c3RpZnkiIHdpZHRoPSIzOTUiPg0KPGRpdiBhbGlnbj0ianVzdGlmeSI+PHNwYW4gY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTsgbGluZS1oZWlnaHQ6bm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmEiPlF1ZXN0 byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFt ZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNp YXNpDQogYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBp bmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSBy aWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHBy ZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBw cm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQo8L3NwYW4+PC9zcGFuPjwv ZGl2Pg0KPHAgYWxpZ249Imp1c3RpZnkiPjxzcGFuIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWFsaWduOmp1c3RpZnk7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTttc28tYW5zaS1s YW5ndWFnZTpFTi1HQiI+VGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50czwvc3Bhbj48L2k+ PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6DQogIDcuNXB0O21zby1iaWRp LWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTttc28tYW5zaS1sYW5ndWFnZTpF Ti1HQiI+Jm5ic3A7PHNwYW4gY2xhc3M9IkdyYW1FIj5pczwvc3Bhbj4mbmJzcDs8L3NwYW4+PC9p PjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOg0KICA3LjVwdDtmb250LWZh bWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj5jb25maWRlbnRpYWwNCiBhbmQg bWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJl c3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkg YW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50 cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXINCiBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuPC9zcGFu PjwvaT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj4N Cjwvc3Bhbj48L3NwYW4+PC9wPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDsNCiAg Zm9udC1mYW1pbHk6VmVyZGFuYSI+PGltZyBzcmM9ImNpZDowMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwM0BUSS5EaXNjbGFpbWVyIiBhbHQ9InJpc3BldHRhIGwnYW1iaWVudGUiIHdpZHRo PSIyNiIgaGVpZ2h0PSI0MCI+UmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0 YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3NhcmlvLjwvc3Bhbj48L2I+DQo8cD48L3A+DQo8L3RkPg0K PC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5575B44GRFMBX704BA02_-- --_efc1a210-3699-4238-b707-1727e5a9f31e_ 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= --_efc1a210-3699-4238-b707-1727e5a9f31e_-- From laurentwalter.goix@telecomitalia.it Tue Nov 20 05:57: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 7A9D421F85B4 for ; Tue, 20 Nov 2012 05:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.414 X-Spam-Level: X-Spam-Status: No, score=-1.414 tagged_above=-999 required=5 tests=[AWL=0.304, 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 9DMwi+nGiMHf for ; Tue, 20 Nov 2012 05:57:29 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id F185F21F85B1 for ; Tue, 20 Nov 2012 05:57:28 -0800 (PST) Content-Type: multipart/mixed; boundary="_ca8d72e1-4692-4eba-b064-227cc6b06869_" Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Tue, 20 Nov 2012 14:57:15 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 20 Nov 2012 14:57:13 +0100 From: Goix Laurent Walter To: "Paul E. Jones" , 'Dick Hardt' Date: Tue, 20 Nov 2012 14:57:11 +0100 Thread-Topic: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt Thread-Index: AQI/YWaFkAYvx4DQsUUjuXKAy/yifQJJ+dZ9Ajy5+20BY9p1VAJ+l/RsAmfvVTQB2jbl4gLBmsrkAatQWkqWhi/U8IAAlHTA Message-ID: References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> <024301cdc6db$3aed2550$b0c76ff0$@packetizer.com> In-Reply-To: <024301cdc6db$3aed2550$b0c76ff0$@packetizer.com> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" Subject: [apps-discuss] R: New draft-ietf-appsawg-webfinger-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: Tue, 20 Nov 2012 13:57:30 -0000 --_ca8d72e1-4692-4eba-b064-227cc6b06869_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A5575B77GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5575B77GRFMBX704BA02_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgcGF1bCwNCg0KQ29tbWVudHMgaW4gcmVkIHc+DQoNCkRhOiBQYXVsIEUuIEpvbmVzIFttYWls dG86cGF1bGVqQHBhY2tldGl6ZXIuY29tXQ0KSW52aWF0bzogbWFydGVkw6wgMjAgbm92ZW1icmUg MjAxMiA1LjU1DQpBOiBHb2l4IExhdXJlbnQgV2FsdGVyOyAnRGljayBIYXJkdCcNCkNjOiB3ZWJm aW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbTsgYXBwcy1kaXNjdXNzQGlldGYub3JnDQpPZ2dldHRvOiBS RTogW2FwcHMtZGlzY3Vzc10gTmV3IGRyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXItMDMudHh0 DQoNCldhbHRlciwNCg0KRm9yIHRoZSBsaW5rIHJlbGF0aW9uc+KApiB0aGlzIGdldHMgdG91Z2gu ICBJIGNvdWxkIGNlcnRhaW5seSByZXBsYWNlOg0KaHR0cDovL3dlYmZpbmdlci5uZXQvcmVsL3By b2ZpbGUtcGFnZQ0Kd2l0aA0KaHR0cDovL2V4YW1wbGUuY29tL3JlbC9wcm9maWxlLXBhZ2UNCg0K SG93ZXZlciwgdGhlIGZvcm1lciBpcyByZWFsbHkgdXNlZCB0b2RheS4gIEkgdGhpbmsgd2UgY2Fu IGJlIGZhaXJseSBzYWZlIGluIGFzc3VtaW5nIOKAnHZjYXJk4oCdIGlzIGdvaW5nIHRvIGV4aXN0 IG9uZSBkYXkuICBXZSBjYW4gcHJvYmFibHkgYWdyZWUgdGhhdCDigJxibG9n4oCdIHdpbGwgZXhp c3QuICBJIGNvdWxkIG1ha2UgdGhhdCBvbmUgY2hhbmdlLiAgQnV0LCB3aGF0IGFib3V0IHRoZSB3 ZWJmaW5nZXIubmV0IFVSSXM/ICBUaG9zZSBhcmUgcmVhbCwgYnV0IHRoZXJlIGlzIG5vdGhpbmcg SSBjYW4gcmVmZXJlbmNlLiAgU2luY2UgdGhleSBhcmUgVVJJcyByZWxzLCBpdCBzaG91bGQgYmUg ZXhwZWN0ZWQuDQoNCnc+IFRoaXMgaXMgbXkgZmVlbGluZyBhcyB3ZWxsIHRoYXQgVVJJcyByZWxz IHNob3VsZCBiZSByZWZlcmVuY2VhYmxlLiBBbnl3YXkgdGhlIOKAnHdlYmZpbmdlci5uZXTigJ0g b25lcyBhcmUgaW5kZWVkIHVzZWQgc28gdGhleSBjYW4gYmUga2VwdCBpbiB0aGUgY3VycmVudCBl eGFtcGxlcyAobXkgY29tbWVudCB3YXMgbW9yZSBmb3IgZnV0dXJlIHdvcmsgaW4gaGF2aW5nIHRo ZW0gcmVnaXN0ZXJlZCB0byBhdm9pZCB0aGlzIGlzc3VlKS4gUmVnYXJkaW5nIHNpbXBsZSB0b2tl bnMgbWVudGlvbmVkIGFzIGV4YW1wbGVzICh2Y2FyZCwgYmxvZykgSSBkbyBoYXZlIHNvbWUgbW9y ZSBkb3VidHMgaWYgdGhleSBhcmUgbm90IHJlZ2lzdGVyZWQgeWV0IGFuZCBhcyBzdWNoIGlmIHdl IGRvbuKAmXQgcmVwbGFjZSB0aGVtIHdpdGggZXhhbXBsZSBVUklzIEkgd291bGQgc3VnZ2VzdCB0 byBzdGF0ZSBleHBsaWNpdGx5IHRoYXQgdGhleSBhcmUgZmljdGl0aW91cy4NCg0KRm9yIHRoZSB0 ZXh0IGluIHNlY3Rpb24gMywgSSB0aGluayB5b3UgYXJlIHJlZmVycmluZyB0byB0aGUgYml0IGFi b3V0IElSSXM/ICBJIGZvcmdvdCB3aG8gcHJvdmlkZWQgdGhhdCB0ZXh0LCBidXQgaXQgaGFzIGJl ZW4gdGhlcmUgZm9yIGEgd2hpbGUgYW5kIEkgZGlkbuKAmXQgd3JpdGUgaXQuICBJLCB0b28sIHRo aW5rIGl04oCZcyB1bm5lY2Vzc2FyeSBhdCB0aGlzIHBvaW50LCBidXTigKYgd2hhdCBpcyB0aGUg cHJlZmVyZW5jZSBvZiB0aGUgZ3JvdXA/ICAoRXNwZWNpYWxseSB3aG9tZXZlciBwcm92aWRlZCB0 aGUgdGV4dCBpbiB0aGUgZmlyc3QgcGxhY2UuKQ0KDQp3PiBJIHdhcyByZWZlcnJpbmcgdG8gdGhh dCBwYXJ0IHllcy4NCg0KRm9yIDQuMSwgSSByZWFsbHkgbWVhbnQg4oCcYW55IHZhbGlkIGFsaWFz 4oCdLiAgTm90IGFsbCBVUklzIGZvciBhIHVzZXIgYXJlIGFsaWFzZXMgdGhhdCB3aWxsIHJldHVy biB0aGUgc2FtZSBjb250ZW50LiAgSW4gdGhlIGZvbGxvdy1vbiBzZW50ZW5jZSwgSSByZWZlciBl eHBsaWNpdGx5IHRvIHRoZSBhbGlhcyBzaG93biBpbiB0aGUgZXhhbXBsZS4NCg0Kdz4gSSBhZ3Jl ZSBub3QgYWxsIHVyaXMgYXJlIGFsaWFzZXMuIE15IHBvaW50IHdhcyBvbiBjbGFyaWZ5aW5nIHRo YXQgYWxsIGFsaWFzZXMgbmVlZCB0byBiZSBVUklTIOKYui4gWW91IG1heSBhZGQgYXQgdGhlIGVu ZCBvZiB0aGF0IHNlbnRlbmNlIOKAnChhcyBsb25nIGFzIGl0IGlzIGEgVVJJKeKAnSBvciBzb21l dGhpbmcgc2ltaWxhci4NCg0KSW4gNS4yLCB0aGUg4oCcZXhwaXJlc+KAnSBlbGVtZW50IGlzIHN1 cHBvc2VkIHRvIGNvbWUgZmlyc3QuICBUaGlzIGlzIGFuIGVycm9yIGluIFJGQyA2NDE1Lg0KDQp3 PiByaWdodCwgSSBkb3VibGUtY2hlY2tlZCB0aGUgeHJkIHNwZWMuDQp3YWx0ZXINClF1ZXN0byBt ZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50 ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNp IGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3Jt YXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1 dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRp IGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZl ZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55 IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0 aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9y aXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIg YnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQpbY2lkOjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAzQFRJLkRpc2NsYWltZXJdUmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJl IHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3NhcmlvLg0KDQo= --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5575B77GRFMBX704BA02_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxiYXNlIGhyZWY9Ingt bXNnOi8vMjUxMC8iPjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAg MCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBh bm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpD YWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIjsNCglwYW5vc2UtMToyIDExIDUgMiA0 IDIgNCAyIDIgMzt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBj bTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRlc3RvIGZ1bWV0dG8gQ2Fy YXR0ZXJlIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5UZXN0b2Z1bWV0dG9DYXJhdHRlcmUNCgl7bXNvLXN0 eWxlLW5hbWU6IlRlc3RvIGZ1bWV0dG8gQ2FyYXR0ZXJlIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRlc3RvIGZ1bWV0dG8iOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5 bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5TdGlsZU1lc3NhZ2dpb0RpUG9z dGFFbGV0dHJvbmljYTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsO30NCnNwYW4uU3RpbGVNZXNzYWdnaW9EaVBv c3RhRWxldHRyb25pY2EyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KcC5CYWxsb29uVGV4 dCwgbGkuQmFsbG9vblRleHQsIGRpdi5CYWxsb29uVGV4dA0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IjsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5TdGlsZU1lc3NhZ2dpb0RpUG9zdGFFbGV0dHJv bmljYTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNt IDIuMGNtIDIuMGNtO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCiAvKiBMaXN0 IERlZmluaXRpb25zICovDQogQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NzY0MDM3MDc4Ow0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNzAzMDY5OTE0IDQy MzQ2NDgwIDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1 Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3Rh cnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC10 YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPg0KPC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJG UiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SGkgcGF1bCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOiMxRjQ5N0QiPkNvbW1lbnRzIGluDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+cmVkIHcmZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iSVQiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29l IFVJJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRhOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iSVQiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJ JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBQYXVsIEUuIEpvbmVzIFttYWlsdG86cGF1 bGVqQHBhY2tldGl6ZXIuY29tXQ0KPGJyPg0KPGI+SW52aWF0bzo8L2I+IG1hcnRlZMOsIDIwIG5v dmVtYnJlIDIwMTIgNS41NTxicj4NCjxiPkE6PC9iPiBHb2l4IExhdXJlbnQgV2FsdGVyOyAnRGlj ayBIYXJkdCc8YnI+DQo8Yj5DYzo8L2I+IHdlYmZpbmdlckBnb29nbGVncm91cHMuY29tOyBhcHBz LWRpc2N1c3NAaWV0Zi5vcmc8YnI+DQo8Yj5PZ2dldHRvOjwvYj4gUkU6IFthcHBzLWRpc2N1c3Nd IE5ldyBkcmFmdC1pZXRmLWFwcHNhd2ctd2ViZmluZ2VyLTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5XYWx0ZXIsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7DQpjb2xvcjojMUY0OTdEIj5Gb3IgdGhlIGxpbmsgcmVsYXRpb25z4oCmIHRoaXMgZ2V0 cyB0b3VnaC4mbmJzcDsgSSBjb3VsZCBjZXJ0YWlubHkgcmVwbGFjZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+aHR0cDovL3dlYmZpbmdlci5uZXQvcmVsL3By b2ZpbGUtcGFnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj53 aXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPmh0dHA6Ly9l eGFtcGxlLmNvbS9yZWwvcHJvZmlsZS1wYWdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xv cjojMUY0OTdEIj5Ib3dldmVyLCB0aGUgZm9ybWVyIGlzIHJlYWxseSB1c2VkIHRvZGF5LiZuYnNw OyBJIHRoaW5rIHdlIGNhbiBiZSBmYWlybHkgc2FmZSBpbiBhc3N1bWluZyDigJx2Y2FyZOKAnSBp cyBnb2luZyB0byBleGlzdCBvbmUgZGF5LiZuYnNwOyBXZSBjYW4gcHJvYmFibHkgYWdyZWUNCiB0 aGF0IOKAnGJsb2figJ0gd2lsbCBleGlzdC4mbmJzcDsgSSBjb3VsZCBtYWtlIHRoYXQgb25lIGNo YW5nZS4mbmJzcDsgQnV0LCB3aGF0IGFib3V0IHRoZSB3ZWJmaW5nZXIubmV0IFVSSXM/Jm5ic3A7 IFRob3NlIGFyZSByZWFsLCBidXQgdGhlcmUgaXMgbm90aGluZyBJIGNhbiByZWZlcmVuY2UuJm5i c3A7IFNpbmNlIHRoZXkgYXJlIFVSSXMgcmVscywgaXQgc2hvdWxkIGJlIGV4cGVjdGVkLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6cmVkIj53Jmd0OyBUaGlzIGlzIG15IGZlZWxpbmcg YXMgd2VsbCB0aGF0IFVSSXMgcmVscyBzaG91bGQgYmUgcmVmZXJlbmNlYWJsZS4gQW55d2F5IHRo ZSDigJx3ZWJmaW5nZXIubmV04oCdIG9uZXMgYXJlIGluZGVlZCB1c2VkIHNvIHRoZXkgY2FuIGJl IGtlcHQgaW4gdGhlDQogY3VycmVudCBleGFtcGxlcyAobXkgY29tbWVudCB3YXMgbW9yZSBmb3Ig ZnV0dXJlIHdvcmsgaW4gaGF2aW5nIHRoZW0gcmVnaXN0ZXJlZCB0byBhdm9pZCB0aGlzIGlzc3Vl KS4gUmVnYXJkaW5nIHNpbXBsZSB0b2tlbnMgbWVudGlvbmVkIGFzIGV4YW1wbGVzICh2Y2FyZCwg YmxvZykgSSBkbyBoYXZlIHNvbWUgbW9yZSBkb3VidHMgaWYgdGhleSBhcmUgbm90IHJlZ2lzdGVy ZWQgeWV0IGFuZCBhcyBzdWNoIGlmIHdlIGRvbuKAmXQgcmVwbGFjZSB0aGVtDQogd2l0aCBleGFt cGxlIFVSSXMgSSB3b3VsZCBzdWdnZXN0IHRvIHN0YXRlIGV4cGxpY2l0bHkgdGhhdCB0aGV5IGFy ZSBmaWN0aXRpb3VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Rm9y IHRoZSB0ZXh0IGluIHNlY3Rpb24gMywgSSB0aGluayB5b3UgYXJlIHJlZmVycmluZyB0byB0aGUg Yml0IGFib3V0IElSSXM/Jm5ic3A7IEkgZm9yZ290IHdobyBwcm92aWRlZCB0aGF0IHRleHQsIGJ1 dCBpdCBoYXMgYmVlbiB0aGVyZSBmb3IgYSB3aGlsZQ0KIGFuZCBJIGRpZG7igJl0IHdyaXRlIGl0 LiZuYnNwOyBJLCB0b28sIHRoaW5rIGl04oCZcyB1bm5lY2Vzc2FyeSBhdCB0aGlzIHBvaW50LCBi dXTigKYgd2hhdCBpcyB0aGUgcHJlZmVyZW5jZSBvZiB0aGUgZ3JvdXA/ICZuYnNwOyhFc3BlY2lh bGx5IHdob21ldmVyIHByb3ZpZGVkIHRoZSB0ZXh0IGluIHRoZSBmaXJzdCBwbGFjZS4pPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpyZWQiPncmZ3Q7IEkgd2FzIHJlZmVycmluZyB0byB0 aGF0IHBhcnQgeWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Rm9y IDQuMSwgSSByZWFsbHkgbWVhbnQg4oCcYW55IHZhbGlkIGFsaWFz4oCdLiZuYnNwOyBOb3QgYWxs IFVSSXMgZm9yIGEgdXNlciBhcmUgYWxpYXNlcyB0aGF0IHdpbGwgcmV0dXJuIHRoZSBzYW1lIGNv bnRlbnQuJm5ic3A7IEluIHRoZSBmb2xsb3ctb24gc2VudGVuY2UsDQogSSByZWZlciBleHBsaWNp dGx5IHRvIHRoZSBhbGlhcyBzaG93biBpbiB0aGUgZXhhbXBsZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOnJlZCI+dyZndDsgSSBhZ3JlZSBub3QgYWxsIHVyaXMgYXJlIGFsaWFzZXMu IE15IHBvaW50IHdhcyBvbiBjbGFyaWZ5aW5nIHRoYXQgYWxsIGFsaWFzZXMgbmVlZCB0byBiZSBV UklTDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ow0K Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOnJlZCI+Sjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToNCjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj4uIFlvdSBtYXkgYWRkIGF0IHRo ZSBlbmQgb2YgdGhhdCBzZW50ZW5jZSDigJwoYXMgbG9uZyBhcyBpdCBpcyBhIFVSSSnigJ0gb3Ig c29tZXRoaW5nDQogc2ltaWxhci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5 N0QiPkluIDUuMiwgdGhlIOKAnGV4cGlyZXPigJ0gZWxlbWVudCBpcyBzdXBwb3NlZCB0byBjb21l IGZpcnN0LiZuYnNwOyBUaGlzIGlzIGFuIGVycm9yIGluIFJGQyA2NDE1LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ow0KY29sb3I6cmVkIj53Jmd0OyByaWdodCwgSSBkb3VibGUtY2hlY2tlZCB0aGUg eHJkIHNwZWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpyZWQiPndhbHRlcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+ DQo8IS0tDQpzcGFuLkdyYW1FIHttc28tc3R5bGUtbmFtZToiIjsNCgltc28tZ3JhbS1lOnllczt9 DQotLT4NCjwvc3R5bGU+DQo8dGFibGUgc3R5bGU9IndpZHRoOjYwMHB4OyI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgc3R5bGU9IndpZHRoOjU4NXB4OyBmb250LWZhbWlseTogVmVyZGFuYSwgQXJpYWw7 IGZvbnQtc2l6ZToxMnB4OyBjb2xvcjojMDAwOyB0ZXh0LWFsaWduOiBqdXN0aWZ5IiB3aWR0aD0i Mzk1Ij4NCjxkaXYgYWxpZ249Imp1c3RpZnkiPjxzcGFuIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWFsaWduOmp1c3RpZnk7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hIj5RdWVzdG8gbWVzc2FnZ2lvIGUgaSBz dW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25l IGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaQ0KIGFsdHJhIGF6aW9u ZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8g cmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRv Y3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGlt bWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1 YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KPC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjxwIGFsaWduPSJq dXN0aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5 OyBsaW5lLWhlaWdodDpub3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPlRo aXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHM8L3NwYW4+PC9pPjxpPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOg0KICA3LjVwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPiZuYnNwOzxzcGFu IGNsYXNzPSJHcmFtRSI+aXM8L3NwYW4+Jm5ic3A7PC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToNCiAgNy41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTttc28t YW5zaS1sYW5ndWFnZTpFTi1HQiI+Y29uZmlkZW50aWFsDQogYW5kIG1heSBjb250YWluIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlz c2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1 bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUg c2VuZGVyDQogYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLjwvc3Bhbj48L2k+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+DQo8L3NwYW4+PC9zcGFuPjwv cD4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7DQogIGZvbnQtZmFtaWx5OlZlcmRh bmEiPjxpbWcgc3JjPSJjaWQ6MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDNAVEkuRGlz Y2xhaW1lciIgYWx0PSJyaXNwZXR0YSBsJ2FtYmllbnRlIiB3aWR0aD0iMjYiIGhlaWdodD0iNDAi PlJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6gg bmVjZXNzYXJpby48L3NwYW4+PC9iPg0KPHA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5575B77GRFMBX704BA02_-- --_ca8d72e1-4692-4eba-b064-227cc6b06869_ 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= --_ca8d72e1-4692-4eba-b064-227cc6b06869_-- From jasnell@gmail.com Tue Nov 20 07:42: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 9345621F8427 for ; Tue, 20 Nov 2012 07:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[AWL=-0.202, 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 umSg894lbA0Y for ; Tue, 20 Nov 2012 07:42:25 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9AF21F8660 for ; Tue, 20 Nov 2012 07:42:25 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so4727955iaf.31 for ; Tue, 20 Nov 2012 07:42:25 -0800 (PST) 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=FuPgnwNeVl5JUiyPVCcq1h/0cgOJFLY5rzNQ1to5Y6E=; b=o+XTiIR+UcKQqZlWpMDtovWqudNnB3GiayNrMHHXNiSBFaN3G54t1MaT9kPdEhsSi8 38+Fqh0xhKkgnNzgr0e6Fbm3rgPBNf1e0+7LDiUu6X32UF7FiaDs/coHx0Egzb3U/y3H KQDYNdT8OLUoS+8kVksO9B6bv2e5eBGV84ldqkuLIeJY5P8HHtxULzqbKZou2aHJJa0y r+sdsXC0lyjycPGpggeV07gwtCAsoZkxPepC2kXifoSdVa2Bs+UnSr4jzcTUV9IeZtqc MYa0G8qq9L3qgXB+LTgNkxIxuxZZNJc1ve/H6LBTOzlq6XYxra3ppnrtsKkuZ90e55vF 7qdQ== Received: by 10.50.196.133 with SMTP id im5mr10289687igc.61.1353426144936; Tue, 20 Nov 2012 07:42:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.225 with HTTP; Tue, 20 Nov 2012 07:42:04 -0800 (PST) In-Reply-To: References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> <025e01cdc6db$faf26720$f0d73560$@packetizer.com> From: James M Snell Date: Tue, 20 Nov 2012 07:42:04 -0800 Message-ID: To: Goix Laurent Walter Content-Type: multipart/alternative; boundary=14dae934118599427304ceef14f8 Cc: "webfinger@googlegroups.com" , IETF Apps Discuss Subject: Re: [apps-discuss] Link rels 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, 20 Nov 2012 15:42:28 -0000 --14dae934118599427304ceef14f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 20, 2012 at 5:39 AM, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > +1 for narrow & unambiguous rels with clear semantics that guarantee > interop (btw I think we are deriving from the core webfinger discussion > here so I changed the subject)**** > > ** > Clear and unambiguous is good... overly specific is not. Remember that we have the media type attribute to help make things less ambiguous... the link rel itself should never be defined in terms of a single representation type (e.g. "updates-from" could point to any type of resource, not just an atom document). - James > ** > > The link rels proposed by james in the draft are meaningful (I do have > some doubts on about vs related, which is already registered). =E2=80=9Ca= vatar=E2=80=9D > could be added there in case the draft can serve as basis for this activi= ty. > **** > > ** ** > > For =E2=80=9Cupdates-from=E2=80=9D indeed these are specific to activity = streams > represented in atom, and should not vary their meaning (besides a type > parameter which could allow for json as well): for this reason the > reference to activitystreams could be stronger imo. maybe =E2=80=9Cactivi= ties=E2=80=9D?*** > * > > ** ** > > walter**** > > ** ** > > *Da:* apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] > *Per conto di *Paul E. Jones > *Inviato:* marted=C3=AC 20 novembre 2012 6.01 > *A:* 'James M Snell'; 'Dick Hardt' > *Cc:* webfinger@googlegroups.com; 'IETF Apps Discuss' > *Oggetto:* Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt**** > > ** ** > > James,**** > > ** ** > > I think the =E2=80=9Cupdates-from=E2=80=9D was intended to be an ATOM fee= d, though I might > be wrong. In your example, you show a blog. But, at the same time we wa= nt > to define =E2=80=9Cblog=E2=80=9D as its own rel.**** > > ** ** > > I think it=E2=80=99s important that we have a very narrow scope for any r= el. I > don=E2=80=99t care what the values are, but we need to ensure there is no= ambiguity > in what a given token means.**** > > ** ** > > Paul**** > > ** ** > > *From:* James M Snell [mailto:jasnell@gmail.com] > *Sent:* Monday, November 19, 2012 12:36 PM > *To:* Dick Hardt > *Cc:* Paul E. Jones; webfinger@googlegroups.com; IETF Apps Discuss > *Subject:* Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt**** > > ** ** > > Just a quick note on this... I already have the existing "Additional Link > Relations" draft [1] in progress (currently submitted as an independent > submission) that registers link relations such as "about", "type", > "terms-of-service", "privacy-policy" and "preview". It would be possible = to > pull this draft back and add a few more link relation types to it if > necessary. We would just need to identify the set of new link rels and I > could very easily drop them in or write up a quick second document based = on > the same simple template.**** > > ** ** > > [1] http://tools.ietf.org/html/draft-snell-additional-link-relations-06**= * > * > > ** ** > > That said, the "about" link relation can be used to link to both > profile-page and vcard type resources... differentiated, of course, by th= e > media type of the linked resource. **** > > ** ** > > Also... We need to be careful not to get too specific with link relation > labels. The rel values themselves are intended to state the nature of the > relationship and not the type of resource it is. Having something like > {"rel":"updates","href":"http://example.org/my/blog","type":"text/html"} > should be generally preferable over something like {"rel":"blog","href":" > http://example.org/my/blog"}. **** > > ** ** > > - James**** > > ** ** > > On Sun, Nov 18, 2012 at 2:22 PM, Dick Hardt wrote:= * > *** > > Hi Paul**** > > ** ** > > I agree it should be separate drafts. I'd be willing to edit if there is > interest. My interest in WebFinger is as a consumer much more than a > publisher - so I don't feel I am a domain expert.**** > > ** ** > > Is it possible to have meaningful examples with existing "rel" values, or > do we need to have some others defined to have meaningful examples?**** > > ** ** > > -- Dick**** > > ** ** > > On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" > wrote:**** > > ** ** > > Dick,**** > > **** > > These should be separate drafts. I agree =E2=80=9Cblog=E2=80=9D is good,= but there are > surely more. A lot of good ones are defined under webfinger.net, too.***= * > > **** > > But I would really prefer to not slow down this draft with addition of > link relation values. If somebody (you?) wants to start a WebFinger Link > Relations document, I think it would be timely.**** > > **** > > Paul**** > > **** > > **** > > PEJ: They could. The challenge is that we have no other URI type defined > for this purpose. For the examples, we have a chicken and egg problem.**= * > * > > **** > > Let's define some then! This is the one area that is vague and IMHO is a > barrier to adoption. What should the "rel" values be for items that I wan= t > to publish? If we don't spec the common ones, we will end up with several > different identifiers for the same thing. Challenge of course is that > getting agreement on schema is always fun, but better to have some that > will be used that are not already defined.**** > > **** > > Need to add an IANA section for that of course.**** > > **** > > "blog" is a good one :)**** > > ** ** > > > _______________________________________________ > 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 an= d > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa > mail se non =C3=A8 necessario.* > > --14dae934118599427304ceef14f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Tue, Nov 20, 2012 at 5:39 AM, Goix La= urent Walter <laurentwalter.goix@telecomitalia.it>= ; wrote:

+1 for nar= row & unambiguous rels with clear semantics that guarantee interop (btw= I think we are deriving from the core webfinger discussion here so I changed the subject)

=C2= =A0


Clear and unambi= guous is good... overly specific is not. Remember that we have the media ty= pe attribute to help make things less ambiguous... the link rel itself shou= ld never be defined in terms of a single representation type (e.g. "up= dates-from" could point to any type of resource, not just an atom docu= ment).

- James
=C2=A0

The link r= els proposed by james in the draft are meaningful (I do have some doubts on= about vs related, which is already registered). =E2=80=9Cavatar=E2=80=9D could be added there in case the draft can serve as basis for this activit= y.

=C2= =A0

For =E2=80= =9Cupdates-from=E2=80=9D indeed these are specific to activity streams repr= esented in atom, and should not vary their meaning (besides a type paramete= r which could allow for json as well): for this reason the reference to acti= vitystreams could be stronger imo. maybe =E2=80=9Cactivities=E2=80=9D?

=C2= =A0

walter<= /u>

=C2=A0

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] Per conto di Paul E. Jones
Inviato: marted=C3=AC 20 novembre 2012 6.01
A: 'James M Snell'; 'Dick Hardt'
Cc: = webfinger@googlegroups.com; 'IETF Apps Discuss'
Oggetto: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt<= u>

=C2=A0

James,<= /u>

=C2= =A0

I think th= e =E2=80=9Cupdates-from=E2=80=9D was intended to be an ATOM feed, though I = might be wrong.=C2=A0 In your example, you show a blog.=C2=A0 But, at the s= ame time we want to define =E2=80=9Cblog=E2=80=9D as its own rel.

=C2= =A0

I think it= =E2=80=99s important that we have a very narrow scope for any rel.=C2=A0 I = don=E2=80=99t care what the values are, but we need to ensure there is no a= mbiguity in what a given token means.

=C2= =A0

Paul

=C2= =A0

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, November 19, 2012 12:36 PM
To: Dick Hardt
Cc: Paul E. Jones; webfinger@googlegroups.com; IETF Apps Discuss
Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt<= u>

=C2=A0

Just a quick note on this... I already have the existing &qu= ot;Additional Link Relations" draft [1] in progress (currently submitt= ed as an independent submission) that registers link relations such as "about", "type", "terms-of-service",= "privacy-policy" and "preview". It would be possible t= o pull this draft back and add a few more link relation types to it if nece= ssary. We would just need to identify the set of new link rels and I could = very easily drop them in or write up a quick second document based on the same simple = template.

=C2=A0

=C2=A0

That said, the "about" link relation can be used t= o link to both profile-page and vcard type resources... differentiated, of = course, by the media type of the linked resource.=C2=A0

=C2=A0

Also... We need to be careful not to get too specific with l= ink relation labels. The rel values themselves are intended to state the na= ture of the relationship and not the type of resource it is. Having something like {"rel":"updates","hr= ef":"htt= p://example.org/my/blog","type":"text/html"} s= hould be generally preferable over something like=C2=A0{"rel":&qu= ot;blog","href":"http://example.org/my/blog"}.=C2=A0

=C2=A0

- James

= =C2=A0

On Sun, Nov 18, 2012 at 2:22 PM= , Dick Hardt <= dick.hardt@gmail.com> wrote:

Hi Paul

=C2=A0

I agree it should be separate d= rafts. I'd be willing to edit if there is interest. My interest in WebF= inger is as a consumer much more than a publisher - so I don't feel I a= m a domain expert.

=C2=A0

Is it possible to have meaningf= ul examples with existing "rel" values, or do we need to have som= e others defined to have meaningful examples?

= =C2=A0

-- Dick=

=C2=A0

On Nov 18, 2012, at 2:02 PM, &q= uot;Paul E. Jones" <paulej@packetizer.com> wrote:

= =C2=A0

Dick,

=C2=A0

These shou= ld be separate drafts.=C2=A0 I agree =E2=80=9Cblog=E2=80=9D is good, but th= ere are surely more.=C2=A0 A lot of good ones are defined under=C2=A0w= ebfinger.net, too.

=C2=A0

But I woul= d really prefer to not slow down this draft with addition of link relation = values.=C2=A0 If somebody (you?) wants to start a WebFinger Link Relations document, I think it would be timely.

=C2=A0

Paul

=C2=A0

=C2=A0

PEJ: They = could.=C2=A0 The challenge is that we have no other URI type defined for th= is purpose.=C2=A0 For the examples, we have a chicken and egg problem.

=C2=A0

Let's define some then! Thi= s is the one area that is vague and IMHO is a barrier to adoption. What sho= uld the "rel" values be for items that I want to publish? If we d= on't spec the common ones, we will end up with several different identifiers for the same thing. Challenge of course is that gett= ing agreement on schema is always fun, but better to have some that will be= used that are not already defined.

=C2=A0

Need to add an IANA section for= that of course.

=C2=A0

"blog" is a good one = :)

=C2=A0

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

=C2=A0

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one 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=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. 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"rispetta=Rispetta l'ambiente. Non st= ampare questa mail se non =C3=A8 necessario.


--14dae934118599427304ceef14f8-- From dret@berkeley.edu Tue Nov 20 09:18: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 3AE6421F8736 for ; Tue, 20 Nov 2012 09:18:09 -0800 (PST) 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 FC4m59DA5FKu for ; Tue, 20 Nov 2012 09:18:08 -0800 (PST) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6C821F86FE for ; Tue, 20 Nov 2012 09:18:08 -0800 (PST) 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 1TarSV-0004LS-Lq; Tue, 20 Nov 2012 09:18:06 -0800 Message-ID: <50ABBB38.7090900@berkeley.edu> Date: Tue, 20 Nov 2012 09:17:44 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: James M Snell References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> <025e01cdc6db$faf26720$f0d73560$@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss , "webfinger@googlegroups.com" Subject: Re: [apps-discuss] Link rels 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, 20 Nov 2012 17:18:09 -0000 On 2012-11-20 7:42 , James M Snell wrote: > On Tue, Nov 20, 2012 at 5:39 AM, Goix Laurent Walter > > wrote: > +1 for narrow & unambiguous rels with clear semantics that guarantee > interop (btw I think we are deriving from the core webfinger > discussion here so I changed the subject)____ > Clear and unambiguous is good... overly specific is not. Remember that > we have the media type attribute to help make things less ambiguous... > the link rel itself should never be defined in terms of a single > representation type (e.g. "updates-from" could point to any type of > resource, not just an atom document). +1; specific rels when it comes to *why* a client would want to follow a link is good and should be a goal, specific rels when it comes to *what* a client expects to find at the other end of the link (in terms of a specific media type, for example) should be avoided. 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 mikekelly321@gmail.com Tue Nov 20 09:21: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 CB3C321F876F for ; Tue, 20 Nov 2012 09:21:25 -0800 (PST) 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 IKVm-hWhCoD3 for ; Tue, 20 Nov 2012 09:21:25 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3200121F8765 for ; Tue, 20 Nov 2012 09:21:25 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so4470636vcb.31 for ; Tue, 20 Nov 2012 09:21:24 -0800 (PST) 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=eRVTYQXLndhymmxS39mQ9pR6bh13ASn8qa608f4JPxg=; b=WksUzd4/tkSP1ybEVAGu+d+l7pNYdQCHGNaKSGT7rt2URYjzv6qx1kWVjV4Udm8dVS q+4bQ1LP5oSHERVGZi9rimxDZVJ09s16axBSkCnKDd4mFZ6Ed6DLer/gikUNJKfhIkHA ZN8OgxrWCKxkFQBz8cxiXRjmQ+ERIk/Cfp883jeKriqSp+UjAWudr+TJjc/rU0Fn9x0I VoCMdIAdgDCiWOpRaC+Q42z2YrDRZ9nOiQhkkLqiPSPjj8QcHoQWdU9l5DO+mn3hf/NS h2BXfI/rqVHCTUVqU09xq4pmzMmC6PAoki3ivgzeAKha53HocgoonM6MwlqDgiOubygK 4uGA== MIME-Version: 1.0 Received: by 10.52.23.20 with SMTP id i20mr21331143vdf.42.1353432084490; Tue, 20 Nov 2012 09:21:24 -0800 (PST) Received: by 10.58.248.136 with HTTP; Tue, 20 Nov 2012 09:21:24 -0800 (PST) In-Reply-To: <50ABBB38.7090900@berkeley.edu> References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> <025e01cdc6db$faf26720$f0d73560$@packetizer.com> <50ABBB38.7090900@berkeley.edu> Date: Tue, 20 Nov 2012 17:21:24 +0000 Message-ID: From: Mike Kelly To: Erik Wilde Content-Type: text/plain; charset=ISO-8859-1 Cc: "webfinger@googlegroups.com" , IETF Apps Discuss Subject: Re: [apps-discuss] Link rels 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, 20 Nov 2012 17:21:26 -0000 On Tue, Nov 20, 2012 at 5:17 PM, Erik Wilde wrote: > On 2012-11-20 7:42 , James M Snell wrote: >> >> On Tue, Nov 20, 2012 at 5:39 AM, Goix Laurent Walter >> > > wrote: >> +1 for narrow & unambiguous rels with clear semantics that guarantee >> interop (btw I think we are deriving from the core webfinger >> discussion here so I changed the subject)____ >> >> Clear and unambiguous is good... overly specific is not. Remember that >> we have the media type attribute to help make things less ambiguous... >> the link rel itself should never be defined in terms of a single >> representation type (e.g. "updates-from" could point to any type of >> resource, not just an atom document). > > > +1; specific rels when it comes to *why* a client would want to follow a > link is good and should be a goal, specific rels when it comes to *what* a > client expects to find at the other end of the link (in terms of a specific > media type, for example) should be avoided. > Are there any objective reasons for this? Or is it just your opinion? Cheers, M From paulej@packetizer.com Tue Nov 20 09:44: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 7676021F873A for ; Tue, 20 Nov 2012 09:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[AWL=-0.310, 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 YncJaHKsbjuR for ; Tue, 20 Nov 2012 09:44:46 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DB00721F875B for ; Tue, 20 Nov 2012 09:44:45 -0800 (PST) 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 qAKHihuM030372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Nov 2012 12:44:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353433484; bh=c/E3fDpubYKFLWmTcZz9/czFNP1yG2fSWWDv6wy1ack=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=SFIkcHnzUUZSh2f12LDEmTI75OXs5tvLPbu6S46ENRWTu2/p7Eio/Js3jcPGXsc54 hAjg3j0A3qoWFDXogKikxFIXonmS8AvFN4sz2szKpNCckKsK2A9VuorVgn/niKkXYv Fwi/x8xxqMt3s2tE71FZ3DpZFQr3t9VWQagG8XHE= From: "Paul E. Jones" To: "'Goix Laurent Walter'" , "'Dick Hardt'" References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> <024301cdc6db$3aed2550$b0c76ff0$@packetizer.com> In-Reply-To: Date: Tue, 20 Nov 2012 12:44:53 -0500 Message-ID: <02d601cdc746$bffd2950$3ff77bf0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_02D7_01CDC71C.D728A7F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI/YWaFkAYvx4DQsUUjuXKAy/yifQJJ+dZ9Ajy5+20BY9p1VAJ+l/RsAmfvVTQB2jbl4gLBmsrkAatQWkoAfYviCQHZHmtTlnRNKZA= Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Tue, 20 Nov 2012 17:44:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D7_01CDC71C.D728A7F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02D8_01CDC71C.D728A7F0" ------=_NextPart_001_02D8_01CDC71C.D728A7F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If we can agree to add =E2=80=9Cvcard=E2=80=9D and = =E2=80=9Cblog=E2=80=9D to the document James and/or Dick and/or Gonzalo = are working on, the that would be best. I=E2=80=99ll change the IMAP = and SMTP server ones to be http://example.net/rel/imap-server, for = example. =20 =20 I=E2=80=99ll remove the second paragraph in section 3. Since = we=E2=80=99re removing that and there is already some dialog in section = 2, I propose we add one more sentence to the end of Section 2 that says: =20 WebFinger also uses the "rel" attribute, where the "rel" value is either = a single IANA-registered link relation type or a URI. =20 It is stated in section 5.4 that a host may return one or more URIs that = serve as aliases. However, I=E2=80=99ll add another sentence in Section = 4. It=E2=80=99s important that we ensure we have all of the normative = language somewhere other than Section 4, though. How about this right = after =E2=80=9Cany valid alias for the user might also be = used.=E2=80=9D: =20 An alias is a URI that is different from the =E2=80=9Csubject=E2=80=9D = URI that identifies the same entity. In the above example, there is one = =E2=80=9Chttp=E2=80=9D alias returned, though there might have been more = than one. =20 Paul =20 From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]=20 Sent: Tuesday, November 20, 2012 8:57 AM To: Paul E. Jones; 'Dick Hardt' Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Subject: R: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt =20 Hi paul, =20 Comments in red w> =20 Da: Paul E. Jones [mailto:paulej@packetizer.com]=20 Inviato: marted=C3=AC 20 novembre 2012 5.55 A: Goix Laurent Walter; 'Dick Hardt' Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Oggetto: RE: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt =20 Walter, =20 For the link relations=E2=80=A6 this gets tough. I could certainly = replace: http://webfinger.net/rel/profile-page with http://example.com/rel/profile-page =20 However, the former is really used today. I think we can be fairly safe = in assuming =E2=80=9Cvcard=E2=80=9D is going to exist one day. We can = probably agree that =E2=80=9Cblog=E2=80=9D will exist. I could make = that one change. But, what about the webfinger.net URIs? Those are = real, but there is nothing I can reference. Since they are URIs rels, = it should be expected. =20 w> This is my feeling as well that URIs rels should be referenceable. = Anyway the =E2=80=9Cwebfinger.net=E2=80=9D ones are indeed used so they = can be kept in the current examples (my comment was more for future work = in having them registered to avoid this issue). Regarding simple tokens = mentioned as examples (vcard, blog) I do have some more doubts if they = are not registered yet and as such if we don=E2=80=99t replace them with = example URIs I would suggest to state explicitly that they are = fictitious. =20 For the text in section 3, I think you are referring to the bit about = IRIs? I forgot who provided that text, but it has been there for a = while and I didn=E2=80=99t write it. I, too, think it=E2=80=99s = unnecessary at this point, but=E2=80=A6 what is the preference of the = group? (Especially whomever provided the text in the first place.) =20 w> I was referring to that part yes. =20 For 4.1, I really meant =E2=80=9Cany valid alias=E2=80=9D. Not all URIs = for a user are aliases that will return the same content. In the = follow-on sentence, I refer explicitly to the alias shown in the = example. =20 w> I agree not all uris are aliases. My point was on clarifying that all = aliases need to be URIS J. You may add at the end of that sentence = =E2=80=9C(as long as it is a URI)=E2=80=9D or something similar. =20 In 5.2, the =E2=80=9Cexpires=E2=80=9D element is supposed to come first. = This is an error in RFC 6415. =20 w> right, I double-checked the xrd spec. walter 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 = =C3=A8 necessario.=20 =20 ------=_NextPart_001_02D8_01CDC71C.D728A7F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

If we can agree to add =E2=80=9Cvcard=E2=80=9D and = =E2=80=9Cblog=E2=80=9D to the document James and/or Dick and/or Gonzalo = are working on, the that would be best.=C2=A0 I=E2=80=99ll change the = IMAP and SMTP server ones to be http://example.net/rel/imap-s= erver, for example.=C2=A0

 

I=E2=80=99ll remove the second paragraph in section 3.=C2=A0 Since = we=E2=80=99re removing that and there is already some dialog in section = 2, I propose we add one more sentence to the end of Section 2 that = says:

 

WebFinger also uses the "rel" attribute, where the = "rel" value is either a single IANA-registered link relation = type or a URI.

 

It is stated in section 5.4 that a host may return one or more URIs = that serve as aliases.=C2=A0 However, I=E2=80=99ll add another sentence = in Section 4.=C2=A0 It=E2=80=99s important that we ensure we have all of = the normative language somewhere other than Section 4, though.=C2=A0 How = about this right after =E2=80=9Cany valid alias for the user might also = be used.=E2=80=9D:

 

An alias is a URI that is different from the = =E2=80=9Csubject=E2=80=9D URI that identifies the same entity.=C2=A0 In = the above example, there is one =E2=80=9Chttp=E2=80=9D alias returned, = though there might have been more than one.

 

Paul

 

From:= = Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] =
Sent: Tuesday, November 20, 2012 8:57 AM
To: Paul = E. Jones; 'Dick Hardt'
Cc: webfinger@googlegroups.com; = apps-discuss@ietf.org
Subject: R: [apps-discuss] New = draft-ietf-appsawg-webfinger-03.txt

 

Hi paul,

 

Comments in r= ed w>

 

Da: Paul E. = Jones [mailto:paulej@packetizer.com] =
Inviato: marted=C3=AC 20 novembre 2012 5.55
A: Goix = Laurent Walter; 'Dick Hardt'
Cc: webfinger@googlegroups.com= ; apps-discuss@ietf.org
Ogg= etto: RE: [apps-discuss] New = draft-ietf-appsawg-webfinger-03.txt

 

Walter,

 

For the link relations=E2=80=A6 this gets tough.  I could = certainly replace:

http://webfinger.net/rel/p= rofile-page

with

http://example.com/rel/profi= le-page

 

However, the former is really used today.  I think we can be = fairly safe in assuming =E2=80=9Cvcard=E2=80=9D is going to exist one = day.  We can probably agree that =E2=80=9Cblog=E2=80=9D will = exist.  I could make that one change.  But, what about the = webfinger.net URIs?  Those are real, but there is nothing I can = reference.  Since they are URIs rels, it should be = expected.

 

w= > This is my feeling as well that URIs rels should be referenceable. = Anyway the =E2=80=9Cwebfinger.net=E2=80=9D ones are indeed used so they = can be kept in the current examples (my comment was more for future work = in having them registered to avoid this issue). Regarding simple tokens = mentioned as examples (vcard, blog) I do have some more doubts if they = are not registered yet and as such if we don=E2=80=99t replace them with = example URIs I would suggest to state explicitly that they are = fictitious.

 

For the text in section 3, I think you are referring to the bit about = IRIs?  I forgot who provided that text, but it has been there for a = while and I didn=E2=80=99t write it.  I, too, think it=E2=80=99s = unnecessary at this point, but=E2=80=A6 what is the preference of the = group?  (Especially whomever provided the text in the first = place.)

 

w= > I was referring to that part yes.

 

For 4.1, I really meant =E2=80=9Cany valid alias=E2=80=9D.  Not = all URIs for a user are aliases that will return the same content.  = In the follow-on sentence, I refer explicitly to the alias shown in the = example.

 

w= > I agree not all uris are aliases. My point was on clarifying that = all aliases need to be URIS J.= You may add at the end of that sentence =E2=80=9C(as long as it is a = URI)=E2=80=9D or something similar.

 

In 5.2, the =E2=80=9Cexpires=E2=80=9D element is supposed to come = first.  This is an error in RFC 6415.

 

w= > right, I double-checked the xrd spec.

w= alter

= 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 =C3=A8 = necessario.=

 

------=_NextPart_001_02D8_01CDC71C.D728A7F0-- ------=_NextPart_000_02D7_01CDC71C.D728A7F0 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_02D7_01CDC71C.D728A7F0-- From laurentwalter.goix@telecomitalia.it Tue Nov 20 09:49: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 5DAAC21F8609 for ; Tue, 20 Nov 2012 09:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.728 X-Spam-Level: X-Spam-Status: No, score=-0.728 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 I-fJPhst4H+J for ; Tue, 20 Nov 2012 09:49:43 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6B29621F8771 for ; Tue, 20 Nov 2012 09:49:42 -0800 (PST) Content-Type: multipart/mixed; boundary="_e2f7d689-98f6-4f1f-8ef9-1c7c99d4c9dc_" Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Tue, 20 Nov 2012 18:49:34 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 20 Nov 2012 18:49:33 +0100 From: Goix Laurent Walter To: "Paul E. Jones" , 'Dick Hardt' Date: Tue, 20 Nov 2012 18:49:25 +0100 Thread-Topic: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt Thread-Index: AQI/YWaFkAYvx4DQsUUjuXKAy/yifQJJ+dZ9Ajy5+20BY9p1VAJ+l/RsAmfvVTQB2jbl4gLBmsrkAatQWkoAfYviCQHZHmtTlnRNKZCAAAeDMA== Message-ID: References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> <024301cdc6db$3aed2550$b0c76ff0$@packetizer.com> <02d601cdc746$bffd2950$3ff77bf0$@packetizer.com> In-Reply-To: <02d601cdc746$bffd2950$3ff77bf0$@packetizer.com> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" Subject: [apps-discuss] R: New draft-ietf-appsawg-webfinger-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: Tue, 20 Nov 2012 17:49:44 -0000 --_e2f7d689-98f6-4f1f-8ef9-1c7c99d4c9dc_ Content-Type: multipart/related; boundary="_004_A09A9E0A4B9C654E8672D1DC003633AE53A5693E59GRFMBX704BA02_"; type="multipart/alternative" --_004_A09A9E0A4B9C654E8672D1DC003633AE53A5693E59GRFMBX704BA02_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A5693E59GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5693E59GRFMBX704BA02_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgdG8gYWxsIHN1Z2dlc3Rpb25zLiBNaW5vciBhZGRpdGlvbiBpcyB0byBhZGQgYSBwb2ludGVy IHRvIHRoZSBpYW5hIGxpbmsgcmVsIHJlZ2lzdHJ5IHVyaSBhcyBpbmZvcm1hdGl2ZSByZWZlcmVu Y2UuDQoNCkRhOiBQYXVsIEUuIEpvbmVzIFttYWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tXQ0K SW52aWF0bzogbWFydGVkw6wgMjAgbm92ZW1icmUgMjAxMiAxOC40NQ0KQTogR29peCBMYXVyZW50 IFdhbHRlcjsgJ0RpY2sgSGFyZHQnDQpDYzogd2ViZmluZ2VyQGdvb2dsZWdyb3Vwcy5jb207IGFw cHMtZGlzY3Vzc0BpZXRmLm9yZw0KT2dnZXR0bzogUkU6IFthcHBzLWRpc2N1c3NdIE5ldyBkcmFm dC1pZXRmLWFwcHNhd2ctd2ViZmluZ2VyLTAzLnR4dA0KDQpJZiB3ZSBjYW4gYWdyZWUgdG8gYWRk IOKAnHZjYXJk4oCdIGFuZCDigJxibG9n4oCdIHRvIHRoZSBkb2N1bWVudCBKYW1lcyBhbmQvb3Ig RGljayBhbmQvb3IgR29uemFsbyBhcmUgd29ya2luZyBvbiwgdGhlIHRoYXQgd291bGQgYmUgYmVz dC4gIEnigJlsbCBjaGFuZ2UgdGhlIElNQVAgYW5kIFNNVFAgc2VydmVyIG9uZXMgdG8gYmUgaHR0 cDovL2V4YW1wbGUubmV0L3JlbC9pbWFwLXNlcnZlciwgZm9yIGV4YW1wbGUuDQoNCknigJlsbCBy ZW1vdmUgdGhlIHNlY29uZCBwYXJhZ3JhcGggaW4gc2VjdGlvbiAzLiAgU2luY2Ugd2XigJlyZSBy ZW1vdmluZyB0aGF0IGFuZCB0aGVyZSBpcyBhbHJlYWR5IHNvbWUgZGlhbG9nIGluIHNlY3Rpb24g MiwgSSBwcm9wb3NlIHdlIGFkZCBvbmUgbW9yZSBzZW50ZW5jZSB0byB0aGUgZW5kIG9mIFNlY3Rp b24gMiB0aGF0IHNheXM6DQoNCldlYkZpbmdlciBhbHNvIHVzZXMgdGhlICJyZWwiIGF0dHJpYnV0 ZSwgd2hlcmUgdGhlICJyZWwiIHZhbHVlIGlzIGVpdGhlciBhIHNpbmdsZSBJQU5BLXJlZ2lzdGVy ZWQgbGluayByZWxhdGlvbiB0eXBlIG9yIGEgVVJJLg0KDQpJdCBpcyBzdGF0ZWQgaW4gc2VjdGlv biA1LjQgdGhhdCBhIGhvc3QgbWF5IHJldHVybiBvbmUgb3IgbW9yZSBVUklzIHRoYXQgc2VydmUg YXMgYWxpYXNlcy4gIEhvd2V2ZXIsIEnigJlsbCBhZGQgYW5vdGhlciBzZW50ZW5jZSBpbiBTZWN0 aW9uIDQuICBJdOKAmXMgaW1wb3J0YW50IHRoYXQgd2UgZW5zdXJlIHdlIGhhdmUgYWxsIG9mIHRo ZSBub3JtYXRpdmUgbGFuZ3VhZ2Ugc29tZXdoZXJlIG90aGVyIHRoYW4gU2VjdGlvbiA0LCB0aG91 Z2guICBIb3cgYWJvdXQgdGhpcyByaWdodCBhZnRlciDigJxhbnkgdmFsaWQgYWxpYXMgZm9yIHRo ZSB1c2VyIG1pZ2h0IGFsc28gYmUgdXNlZC7igJ06DQoNCkFuIGFsaWFzIGlzIGEgVVJJIHRoYXQg aXMgZGlmZmVyZW50IGZyb20gdGhlIOKAnHN1YmplY3TigJ0gVVJJIHRoYXQgaWRlbnRpZmllcyB0 aGUgc2FtZSBlbnRpdHkuICBJbiB0aGUgYWJvdmUgZXhhbXBsZSwgdGhlcmUgaXMgb25lIOKAnGh0 dHDigJ0gYWxpYXMgcmV0dXJuZWQsIHRob3VnaCB0aGVyZSBtaWdodCBoYXZlIGJlZW4gbW9yZSB0 aGFuIG9uZS4NCg0KUGF1bA0KDQpGcm9tOiBHb2l4IExhdXJlbnQgV2FsdGVyIFttYWlsdG86bGF1 cmVudHdhbHRlci5nb2l4QHRlbGVjb21pdGFsaWEuaXRdDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJl ciAyMCwgMjAxMiA4OjU3IEFNDQpUbzogUGF1bCBFLiBKb25lczsgJ0RpY2sgSGFyZHQnDQpDYzog d2ViZmluZ2VyQGdvb2dsZWdyb3Vwcy5jb207IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KU3ViamVj dDogUjogW2FwcHMtZGlzY3Vzc10gTmV3IGRyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXItMDMu dHh0DQoNCkhpIHBhdWwsDQoNCkNvbW1lbnRzIGluIHJlZCB3Pg0KDQpEYTogUGF1bCBFLiBKb25l cyBbbWFpbHRvOnBhdWxlakBwYWNrZXRpemVyLmNvbV0NCkludmlhdG86IG1hcnRlZMOsIDIwIG5v dmVtYnJlIDIwMTIgNS41NQ0KQTogR29peCBMYXVyZW50IFdhbHRlcjsgJ0RpY2sgSGFyZHQnDQpD Yzogd2ViZmluZ2VyQGdvb2dsZWdyb3Vwcy5jb208bWFpbHRvOndlYmZpbmdlckBnb29nbGVncm91 cHMuY29tPjsgYXBwcy1kaXNjdXNzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5v cmc+DQpPZ2dldHRvOiBSRTogW2FwcHMtZGlzY3Vzc10gTmV3IGRyYWZ0LWlldGYtYXBwc2F3Zy13 ZWJmaW5nZXItMDMudHh0DQoNCldhbHRlciwNCg0KRm9yIHRoZSBsaW5rIHJlbGF0aW9uc+KApiB0 aGlzIGdldHMgdG91Z2guICBJIGNvdWxkIGNlcnRhaW5seSByZXBsYWNlOg0KaHR0cDovL3dlYmZp bmdlci5uZXQvcmVsL3Byb2ZpbGUtcGFnZQ0Kd2l0aA0KaHR0cDovL2V4YW1wbGUuY29tL3JlbC9w cm9maWxlLXBhZ2UNCg0KSG93ZXZlciwgdGhlIGZvcm1lciBpcyByZWFsbHkgdXNlZCB0b2RheS4g IEkgdGhpbmsgd2UgY2FuIGJlIGZhaXJseSBzYWZlIGluIGFzc3VtaW5nIOKAnHZjYXJk4oCdIGlz IGdvaW5nIHRvIGV4aXN0IG9uZSBkYXkuICBXZSBjYW4gcHJvYmFibHkgYWdyZWUgdGhhdCDigJxi bG9n4oCdIHdpbGwgZXhpc3QuICBJIGNvdWxkIG1ha2UgdGhhdCBvbmUgY2hhbmdlLiAgQnV0LCB3 aGF0IGFib3V0IHRoZSB3ZWJmaW5nZXIubmV0IFVSSXM/ICBUaG9zZSBhcmUgcmVhbCwgYnV0IHRo ZXJlIGlzIG5vdGhpbmcgSSBjYW4gcmVmZXJlbmNlLiAgU2luY2UgdGhleSBhcmUgVVJJcyByZWxz LCBpdCBzaG91bGQgYmUgZXhwZWN0ZWQuDQoNCnc+IFRoaXMgaXMgbXkgZmVlbGluZyBhcyB3ZWxs IHRoYXQgVVJJcyByZWxzIHNob3VsZCBiZSByZWZlcmVuY2VhYmxlLiBBbnl3YXkgdGhlIOKAnHdl YmZpbmdlci5uZXTigJ0gb25lcyBhcmUgaW5kZWVkIHVzZWQgc28gdGhleSBjYW4gYmUga2VwdCBp biB0aGUgY3VycmVudCBleGFtcGxlcyAobXkgY29tbWVudCB3YXMgbW9yZSBmb3IgZnV0dXJlIHdv cmsgaW4gaGF2aW5nIHRoZW0gcmVnaXN0ZXJlZCB0byBhdm9pZCB0aGlzIGlzc3VlKS4gUmVnYXJk aW5nIHNpbXBsZSB0b2tlbnMgbWVudGlvbmVkIGFzIGV4YW1wbGVzICh2Y2FyZCwgYmxvZykgSSBk byBoYXZlIHNvbWUgbW9yZSBkb3VidHMgaWYgdGhleSBhcmUgbm90IHJlZ2lzdGVyZWQgeWV0IGFu ZCBhcyBzdWNoIGlmIHdlIGRvbuKAmXQgcmVwbGFjZSB0aGVtIHdpdGggZXhhbXBsZSBVUklzIEkg d291bGQgc3VnZ2VzdCB0byBzdGF0ZSBleHBsaWNpdGx5IHRoYXQgdGhleSBhcmUgZmljdGl0aW91 cy4NCg0KRm9yIHRoZSB0ZXh0IGluIHNlY3Rpb24gMywgSSB0aGluayB5b3UgYXJlIHJlZmVycmlu ZyB0byB0aGUgYml0IGFib3V0IElSSXM/ICBJIGZvcmdvdCB3aG8gcHJvdmlkZWQgdGhhdCB0ZXh0 LCBidXQgaXQgaGFzIGJlZW4gdGhlcmUgZm9yIGEgd2hpbGUgYW5kIEkgZGlkbuKAmXQgd3JpdGUg aXQuICBJLCB0b28sIHRoaW5rIGl04oCZcyB1bm5lY2Vzc2FyeSBhdCB0aGlzIHBvaW50LCBidXTi gKYgd2hhdCBpcyB0aGUgcHJlZmVyZW5jZSBvZiB0aGUgZ3JvdXA/ICAoRXNwZWNpYWxseSB3aG9t ZXZlciBwcm92aWRlZCB0aGUgdGV4dCBpbiB0aGUgZmlyc3QgcGxhY2UuKQ0KDQp3PiBJIHdhcyBy ZWZlcnJpbmcgdG8gdGhhdCBwYXJ0IHllcy4NCg0KRm9yIDQuMSwgSSByZWFsbHkgbWVhbnQg4oCc YW55IHZhbGlkIGFsaWFz4oCdLiAgTm90IGFsbCBVUklzIGZvciBhIHVzZXIgYXJlIGFsaWFzZXMg dGhhdCB3aWxsIHJldHVybiB0aGUgc2FtZSBjb250ZW50LiAgSW4gdGhlIGZvbGxvdy1vbiBzZW50 ZW5jZSwgSSByZWZlciBleHBsaWNpdGx5IHRvIHRoZSBhbGlhcyBzaG93biBpbiB0aGUgZXhhbXBs ZS4NCg0Kdz4gSSBhZ3JlZSBub3QgYWxsIHVyaXMgYXJlIGFsaWFzZXMuIE15IHBvaW50IHdhcyBv biBjbGFyaWZ5aW5nIHRoYXQgYWxsIGFsaWFzZXMgbmVlZCB0byBiZSBVUklTIOKYui4gWW91IG1h eSBhZGQgYXQgdGhlIGVuZCBvZiB0aGF0IHNlbnRlbmNlIOKAnChhcyBsb25nIGFzIGl0IGlzIGEg VVJJKeKAnSBvciBzb21ldGhpbmcgc2ltaWxhci4NCg0KSW4gNS4yLCB0aGUg4oCcZXhwaXJlc+KA nSBlbGVtZW50IGlzIHN1cHBvc2VkIHRvIGNvbWUgZmlyc3QuICBUaGlzIGlzIGFuIGVycm9yIGlu IFJGQyA2NDE1Lg0KDQp3PiByaWdodCwgSSBkb3VibGUtY2hlY2tlZCB0aGUgeHJkIHNwZWMuDQp3 YWx0ZXINClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0 aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNv cGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBk aSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3Jh IGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRl c2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRl bnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlz IGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRh aW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBv bmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBl bHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2 aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KW2NpZDppbWFnZTAwMS5n aWZAMDFDREM3NEYuQzM3MkQ5MDBdUmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1 ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3NhcmlvLg0KDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBp IHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNv bmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9u ZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8g cmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRv Y3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGlt bWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1 YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBp bnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5n LCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUt bWFpbCwgVGhhbmtzLg0KDQpbY2lkOjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzQFRJ LkRpc2NsYWltZXJdUmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWls IHNlIG5vbiDDqCBuZWNlc3NhcmlvLg0KDQo= --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5693E59GRFMBX704BA02_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxiYXNlIGhyZWY9Ingt bXNnOi8vMjUxMC8iPjwhLS1baWYgIW1zb10+DQo8c3R5bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoq IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVm YXVsdCNWTUwpO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT48c3R5bGU+DQo8IS0tDQogLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCiAvKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiVGVzdG8gZnVtZXR0byBDYXJhdHRlcmUiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1z b0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0 eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0 b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnNwYW4uVGVzdG9mdW1ldHRvQ2FyYXR0ZXJlDQoJe21zby1zdHlsZS1uYW1lOiJUZXN0byBm dW1ldHRvIENhcmF0dGVyZSI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJUZXN0byBmdW1ldHRvIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0KcC5CYWxsb29uVGV4dCwgbGkuQmFsbG9vblRleHQsIGRpdi5CYWxsb29uVGV4dA0KCXttc28t c3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IjsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0 ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4u U3RpbGVNZXNzYWdnaW9EaVBvc3RhRWxldHRyb25pY2EyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDt9DQpzcGFu LlN0aWxlTWVzc2FnZ2lvRGlQb3N0YUVsZXR0cm9uaWNhMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uU3RpbGVNZXNzYWdnaW9EaVBvc3RhRWxldHRyb25pY2EyNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5TdGlsZU1lc3NhZ2dpb0RpUG9zdGFFbGV0dHJvbmljYTI4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlN0aWxlTWVzc2FnZ2lvRGlQb3N0YUVs ZXR0cm9uaWNhMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQg Mi4wY20gMi4wY20gMi4wY207fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+ DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mIzQzOzEg dG8gYWxsIHN1Z2dlc3Rpb25zLiBNaW5vciBhZGRpdGlvbiBpcyB0byBhZGQgYSBwb2ludGVyIHRv IHRoZSBpYW5hIGxpbmsgcmVsIHJlZ2lzdHJ5IHVyaSBhcyBpbmZvcm1hdGl2ZSByZWZlcmVuY2Uu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iSVQiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRhOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iSVQiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBQYXVsIEUuIEpvbmVz IFttYWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tXQ0KPGJyPg0KPGI+SW52aWF0bzo8L2I+IG1h cnRlZMOsIDIwIG5vdmVtYnJlIDIwMTIgMTguNDU8YnI+DQo8Yj5BOjwvYj4gR29peCBMYXVyZW50 IFdhbHRlcjsgJ0RpY2sgSGFyZHQnPGJyPg0KPGI+Q2M6PC9iPiB3ZWJmaW5nZXJAZ29vZ2xlZ3Jv dXBzLmNvbTsgYXBwcy1kaXNjdXNzQGlldGYub3JnPGJyPg0KPGI+T2dnZXR0bzo8L2I+IFJFOiBb YXBwcy1kaXNjdXNzXSBOZXcgZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0wMy50eHQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SWYgd2UgY2FuIGFn cmVlIHRvIGFkZCDigJx2Y2FyZOKAnSBhbmQg4oCcYmxvZ+KAnSB0byB0aGUgZG9jdW1lbnQgSmFt ZXMgYW5kL29yIERpY2sgYW5kL29yIEdvbnphbG8gYXJlIHdvcmtpbmcgb24sIHRoZSB0aGF0IHdv dWxkIGJlIGJlc3QuJm5ic3A7IEnigJlsbCBjaGFuZ2UNCiB0aGUgSU1BUCBhbmQgU01UUCBzZXJ2 ZXIgb25lcyB0byBiZSA8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5uZXQvcmVsL2ltYXAtc2VydmVy Ij4NCmh0dHA6Ly9leGFtcGxlLm5ldC9yZWwvaW1hcC1zZXJ2ZXI8L2E+LCBmb3IgZXhhbXBsZS4m bmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5J4oCZbGwgcmVt b3ZlIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIHNlY3Rpb24gMy4mbmJzcDsgU2luY2Ugd2XigJly ZSByZW1vdmluZyB0aGF0IGFuZCB0aGVyZSBpcyBhbHJlYWR5IHNvbWUgZGlhbG9nIGluIHNlY3Rp b24gMiwgSSBwcm9wb3NlIHdlIGFkZCBvbmUNCiBtb3JlIHNlbnRlbmNlIHRvIHRoZSBlbmQgb2Yg U2VjdGlvbiAyIHRoYXQgc2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZWJGaW5nZXIgYWxzbyB1c2VzIHRoZSAmcXVv dDtyZWwmcXVvdDsgYXR0cmlidXRlLCB3aGVyZSB0aGUgJnF1b3Q7cmVsJnF1b3Q7IHZhbHVlIGlz IGVpdGhlciBhIHNpbmdsZSBJQU5BLXJlZ2lzdGVyZWQgbGluayByZWxhdGlvbiB0eXBlDQogb3Ig YSBVUkkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5JdCBpcyBzdGF0 ZWQgaW4gc2VjdGlvbiA1LjQgdGhhdCBhIGhvc3QgbWF5IHJldHVybiBvbmUgb3IgbW9yZSBVUklz IHRoYXQgc2VydmUgYXMgYWxpYXNlcy4mbmJzcDsgSG93ZXZlciwgSeKAmWxsIGFkZCBhbm90aGVy IHNlbnRlbmNlIGluIFNlY3Rpb24gNC4mbmJzcDsNCiBJdOKAmXMgaW1wb3J0YW50IHRoYXQgd2Ug ZW5zdXJlIHdlIGhhdmUgYWxsIG9mIHRoZSBub3JtYXRpdmUgbGFuZ3VhZ2Ugc29tZXdoZXJlIG90 aGVyIHRoYW4gU2VjdGlvbiA0LCB0aG91Z2guJm5ic3A7IEhvdyBhYm91dCB0aGlzIHJpZ2h0IGFm dGVyIOKAnGFueSB2YWxpZCBhbGlhcyBmb3IgdGhlIHVzZXIgbWlnaHQgYWxzbyBiZSB1c2VkLuKA nTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5BbiBhbGlhcyBpcyBhIFVSSSB0aGF0IGlzIGRpZmZlcmVudCBmcm9tIHRoZSDi gJxzdWJqZWN04oCdIFVSSSB0aGF0IGlkZW50aWZpZXMgdGhlIHNhbWUgZW50aXR5LiZuYnNwOyBJ biB0aGUgYWJvdmUgZXhhbXBsZSwgdGhlcmUNCiBpcyBvbmUg4oCcaHR0cOKAnSBhbGlhcyByZXR1 cm5lZCwgdGhvdWdoIHRoZXJlIG1pZ2h0IGhhdmUgYmVlbiBtb3JlIHRoYW4gb25lLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+UGF1bDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToNCiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBHb2l4IExhdXJlbnQgV2FsdGVyIFttYWlsdG86bGF1cmVudHdhbHRlci5n b2l4QHRlbGVjb21pdGFsaWEuaXRdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92ZW1i ZXIgMjAsIDIwMTIgODo1NyBBTTxicj4NCjxiPlRvOjwvYj4gUGF1bCBFLiBKb25lczsgJ0RpY2sg SGFyZHQnPGJyPg0KPGI+Q2M6PC9iPiB3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbTsgYXBwcy1k aXNjdXNzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFI6IFthcHBzLWRpc2N1c3NdIE5l dyBkcmFmdC1pZXRmLWFwcHNhd2ctd2ViZmluZ2VyLTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkhp IHBhdWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5Db21tZW50cyBp bg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsNCmZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpyZWQiPnJlZCB3Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5EYTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gUGF1bCBFLiBKb25lcyBbPGEgaHJlZj0ibWFpbHRvOnBhdWxlakBwYWNrZXRpemVy LmNvbSI+bWFpbHRvOnBhdWxlakBwYWNrZXRpemVyLmNvbTwvYT5dDQo8YnI+DQo8Yj5JbnZpYXRv OjwvYj4gbWFydGVkw6wgMjAgbm92ZW1icmUgMjAxMiA1LjU1PGJyPg0KPGI+QTo8L2I+IEdvaXgg TGF1cmVudCBXYWx0ZXI7ICdEaWNrIEhhcmR0Jzxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFp bHRvOndlYmZpbmdlckBnb29nbGVncm91cHMuY29tIj53ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNv bTwvYT47DQo8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnIj5hcHBzLWRpc2N1 c3NAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2dnZXR0bzo8L2I+IFJFOiBbYXBwcy1kaXNjdXNzXSBO ZXcgZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+V2FsdGVyLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Rm9yIHRoZSBsaW5rIHJlbGF0aW9uc+KApiB0aGlzIGdldHMg dG91Z2guJm5ic3A7IEkgY291bGQgY2VydGFpbmx5IHJlcGxhY2U6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly93ZWJmaW5nZXIubmV0 L3JlbC9wcm9maWxlLXBhZ2UiPmh0dHA6Ly93ZWJmaW5nZXIubmV0L3JlbC9wcm9maWxlLXBhZ2U8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPndpdGg8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDov L2V4YW1wbGUuY29tL3JlbC9wcm9maWxlLXBhZ2UiPmh0dHA6Ly9leGFtcGxlLmNvbS9yZWwvcHJv ZmlsZS1wYWdlPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SG93 ZXZlciwgdGhlIGZvcm1lciBpcyByZWFsbHkgdXNlZCB0b2RheS4mbmJzcDsgSSB0aGluayB3ZSBj YW4gYmUgZmFpcmx5IHNhZmUgaW4gYXNzdW1pbmcg4oCcdmNhcmTigJ0gaXMgZ29pbmcgdG8gZXhp c3Qgb25lIGRheS4mbmJzcDsgV2UgY2FuIHByb2JhYmx5IGFncmVlDQogdGhhdCDigJxibG9n4oCd IHdpbGwgZXhpc3QuJm5ic3A7IEkgY291bGQgbWFrZSB0aGF0IG9uZSBjaGFuZ2UuJm5ic3A7IEJ1 dCwgd2hhdCBhYm91dCB0aGUgd2ViZmluZ2VyLm5ldCBVUklzPyZuYnNwOyBUaG9zZSBhcmUgcmVh bCwgYnV0IHRoZXJlIGlzIG5vdGhpbmcgSSBjYW4gcmVmZXJlbmNlLiZuYnNwOyBTaW5jZSB0aGV5 IGFyZSBVUklzIHJlbHMsIGl0IHNob3VsZCBiZSBleHBlY3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOnJlZCI+dyZndDsgVGhpcyBpcyBteSBmZWVsaW5nIGFzIHdlbGwgdGhhdCBV UklzIHJlbHMgc2hvdWxkIGJlIHJlZmVyZW5jZWFibGUuIEFueXdheSB0aGUg4oCcd2ViZmluZ2Vy Lm5ldOKAnSBvbmVzIGFyZSBpbmRlZWQgdXNlZCBzbyB0aGV5IGNhbiBiZSBrZXB0IGluIHRoZQ0K IGN1cnJlbnQgZXhhbXBsZXMgKG15IGNvbW1lbnQgd2FzIG1vcmUgZm9yIGZ1dHVyZSB3b3JrIGlu IGhhdmluZyB0aGVtIHJlZ2lzdGVyZWQgdG8gYXZvaWQgdGhpcyBpc3N1ZSkuIFJlZ2FyZGluZyBz aW1wbGUgdG9rZW5zIG1lbnRpb25lZCBhcyBleGFtcGxlcyAodmNhcmQsIGJsb2cpIEkgZG8gaGF2 ZSBzb21lIG1vcmUgZG91YnRzIGlmIHRoZXkgYXJlIG5vdCByZWdpc3RlcmVkIHlldCBhbmQgYXMg c3VjaCBpZiB3ZSBkb27igJl0IHJlcGxhY2UgdGhlbQ0KIHdpdGggZXhhbXBsZSBVUklzIEkgd291 bGQgc3VnZ2VzdCB0byBzdGF0ZSBleHBsaWNpdGx5IHRoYXQgdGhleSBhcmUgZmljdGl0aW91cy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkZvciB0aGUgdGV4dCBpbiBz ZWN0aW9uIDMsIEkgdGhpbmsgeW91IGFyZSByZWZlcnJpbmcgdG8gdGhlIGJpdCBhYm91dCBJUklz PyZuYnNwOyBJIGZvcmdvdCB3aG8gcHJvdmlkZWQgdGhhdCB0ZXh0LCBidXQgaXQgaGFzIGJlZW4g dGhlcmUgZm9yIGEgd2hpbGUNCiBhbmQgSSBkaWRu4oCZdCB3cml0ZSBpdC4mbmJzcDsgSSwgdG9v LCB0aGluayBpdOKAmXMgdW5uZWNlc3NhcnkgYXQgdGhpcyBwb2ludCwgYnV04oCmIHdoYXQgaXMg dGhlIHByZWZlcmVuY2Ugb2YgdGhlIGdyb3VwPyAmbmJzcDsoRXNwZWNpYWxseSB3aG9tZXZlciBw cm92aWRlZCB0aGUgdGV4dCBpbiB0aGUgZmlyc3QgcGxhY2UuKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ow0KY29sb3I6cmVkIj53Jmd0OyBJIHdhcyByZWZlcnJpbmcgdG8gdGhhdCBwYXJ0IHllcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkZvciA0LjEsIEkgcmVhbGx5 IG1lYW50IOKAnGFueSB2YWxpZCBhbGlhc+KAnS4mbmJzcDsgTm90IGFsbCBVUklzIGZvciBhIHVz ZXIgYXJlIGFsaWFzZXMgdGhhdCB3aWxsIHJldHVybiB0aGUgc2FtZSBjb250ZW50LiZuYnNwOyBJ biB0aGUgZm9sbG93LW9uIHNlbnRlbmNlLA0KIEkgcmVmZXIgZXhwbGljaXRseSB0byB0aGUgYWxp YXMgc2hvd24gaW4gdGhlIGV4YW1wbGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpy ZWQiPncmZ3Q7IEkgYWdyZWUgbm90IGFsbCB1cmlzIGFyZSBhbGlhc2VzLiBNeSBwb2ludCB3YXMg b24gY2xhcmlmeWluZyB0aGF0IGFsbCBhbGlhc2VzIG5lZWQgdG8gYmUgVVJJUw0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5Oldp bmdkaW5ncztjb2xvcjpyZWQiPko8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6DQoxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+LiBZb3UgbWF5IGFkZCBhdCB0aGUgZW5kIG9mIHRoYXQg c2VudGVuY2Ug4oCcKGFzIGxvbmcgYXMgaXQgaXMgYSBVUkkp4oCdIG9yIHNvbWV0aGluZw0KIHNp bWlsYXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5JbiA1LjIsIHRo ZSDigJxleHBpcmVz4oCdIGVsZW1lbnQgaXMgc3VwcG9zZWQgdG8gY29tZSBmaXJzdC4mbmJzcDsg VGhpcyBpcyBhbiBlcnJvciBpbiBSRkMgNjQxNS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOnJlZCI+dyZndDsgcmlnaHQsIEkgZG91YmxlLWNoZWNrZWQgdGhlIHhyZCBzcGVjLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDo1LjI1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 cmVkIj53YWx0ZXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs cGFkZGluZz0iMCIgd2lkdGg9IjYwMCIgc3R5bGU9IndpZHRoOjQ1MC4wcHQiPg0KPHRib2R5Pg0K PHRyPg0KPHRkIHdpZHRoPSI1ODUiIHN0eWxlPSJ3aWR0aDo0MzguNzVwdDtwYWRkaW5nOi43NXB0 IC43NXB0IC43NXB0IC43NXB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBjbGFzcz0ibXNvbm9ybWFsMCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxs ZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNh dGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhDQogbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lIGRlcml2 YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9z YW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRv IHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRh IGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3Ry dXppb25lLA0KIEdyYXppZS4gPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsNCiAgY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgc3R5 bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gY2xhc3M9Im1zb25vcm1hbDAiPjxpPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhpcyBlLW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsIGFuZCBtYXkg Y29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2Vl KHMpDQogb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFu eWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMg YW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy48L3NwYW4+PC9p Pjwvc3Bhbj48c3BhbiBjbGFzcz0ibXNvbm9ybWFsMCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJjb2xvcjpibGFjayI+DQo8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQt YWxpZ246anVzdGlmeSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDsNCiAgZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjI2IiBoZWlnaHQ9IjQwIiBpZD0iX3gwMDAwX2kx MDI1IiBzcmM9ImNpZDppbWFnZTAwMS5naWZAMDFDREM3NEYuQzM3MkQ5MDAiIGFsdD0icmlzcGV0 dGEgbCdhbWJpZW50ZSI+UmlzcGV0dGENCiBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3Rh IG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCiAgY29sb3I6YmxhY2siPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N CjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPg0KPCEtLQ0Kc3Bhbi5HcmFtRSB7bXNvLXN0 eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5ZXM7fQ0KLS0+DQo8L3N0eWxlPg0KPHRhYmxlIHN0 eWxlPSJ3aWR0aDo2MDBweDsiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJ3aWR0aDo1ODVw eDsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFyaWFsOyBmb250LXNpemU6MTJweDsgY29sb3I6IzAw MDsgdGV4dC1hbGlnbjoganVzdGlmeSIgd2lkdGg9IjM5NSI+DQo8ZGl2IGFsaWduPSJqdXN0aWZ5 Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5OyBsaW5l LWhlaWdodDpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 VmVyZGFuYSI+UXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6 YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwg Y29waWEgbyBxdWFsc2lhc2kNCiBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2Vu emEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVh bG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBj b3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBt aXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCjwv c3Bhbj48L3NwYW4+PC9kaXY+DQo8cCBhbGlnbj0ianVzdGlmeSI+PHNwYW4gY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTsgbGluZS1oZWlnaHQ6bm9ybWFsIj48aT48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpWZXJk YW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj5UaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzPC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToNCiAg Ny41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1h bnNpLWxhbmd1YWdlOkVOLUdCIj4mbmJzcDs8c3BhbiBjbGFzcz0iR3JhbUUiPmlzPC9zcGFuPiZu YnNwOzwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6DQog IDcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPmNvbmZp ZGVudGlhbA0KIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVk IGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50 aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg YW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlcg0KIGJ5IHJldHVybiBlLW1haWws IFRoYW5rcy48L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0ibXNvLWFuc2ktbGFu Z3VhZ2U6RU4tR0IiPg0KPC9zcGFuPjwvc3Bhbj48L3A+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0Ow0KICBmb250LWZhbWlseTpWZXJkYW5hIj48aW1nIHNyYz0iY2lkOjAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzQFRJLkRpc2NsYWltZXIiIGFsdD0icmlzcGV0dGEgbCdh bWJpZW50ZSIgd2lkdGg9IjI2IiBoZWlnaHQ9IjQwIj5SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24g c3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uPC9zcGFuPjwvYj4NCjxw PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5693E59GRFMBX704BA02_-- --_004_A09A9E0A4B9C654E8672D1DC003633AE53A5693E59GRFMBX704BA02_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=677; creation-date="Tue, 20 Nov 2012 17:49:30 GMT"; modification-date="Tue, 20 Nov 2012 17:49:30 GMT" Content-ID: Content-Transfer-Encoding: base64 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= --_004_A09A9E0A4B9C654E8672D1DC003633AE53A5693E59GRFMBX704BA02_-- --_e2f7d689-98f6-4f1f-8ef9-1c7c99d4c9dc_ 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= --_e2f7d689-98f6-4f1f-8ef9-1c7c99d4c9dc_-- From paulej@packetizer.com Tue Nov 20 09:52: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 A32DD21F86D4 for ; Tue, 20 Nov 2012 09:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.525 X-Spam-Level: X-Spam-Status: No, score=-1.525 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] 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 aJZhD3thMr51 for ; Tue, 20 Nov 2012 09:52:29 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id EC8E621F86D9 for ; Tue, 20 Nov 2012 09:52:28 -0800 (PST) Received: from dyn-157.arid.us (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 qAKHqQai030726 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 20 Nov 2012 12:52:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353433947; bh=tE1+lptFCzQ66D4TC2Pn0rfuI0EwvvB7IsZXjUbMZ2s=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=OggtqvI8Zuso984rs7MeMISNAjg8G5pnIRBBUI2knx+OHFoHPQa+bbuNuXgRjd59k BNenvVuz4rj+jD7caZfVDjccksXHMx+Zj56VAs8HYQ4Lv1wR2Sk6z+I/jBc8kxQPAw ASZOwo4umiYrDJuYmx3alVqTAebwOua1n95DjLsI= User-Agent: K-9 Mail for Android In-Reply-To: References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> <025e01cdc6db$faf26720$f0d73560$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----TXD3IX3M7ZK7PSCJQWJ61GVOKI2UM0" From: "Paul E. Jones" Date: Tue, 20 Nov 2012 12:52:25 -0500 To: James M Snell , Goix Laurent Walter Message-ID: <7536cd9a-12b1-4edc-b1c1-89a83fe9dfce@email.android.com> Cc: "webfinger@googlegroups.com" , IETF Apps Discuss Subject: Re: [apps-discuss] Link rels 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, 20 Nov 2012 17:52:30 -0000 ------TXD3IX3M7ZK7PSCJQWJ61GVOKI2UM0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I agree if it's just a format change (ATOM vs. RSS), but I would hope we can agree that if "updates-from" is one of those typed of feeds, that it would not apply to a blog and that blog should be a different rel. Paul -------- Original Message -------- From: James M Snell Sent: Tue Nov 20 10:42:04 EST 2012 To: Goix Laurent Walter Cc: "Paul E. Jones" , Dick Hardt , "webfinger@googlegroups.com" , IETF Apps Discuss Subject: Re: [apps-discuss] Link rels On Tue, Nov 20, 2012 at 5:39 AM, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > +1 for narrow & unambiguous rels with clear semantics that guarantee > interop (btw I think we are deriving from the core webfinger discussion > here so I changed the subject)**** > > ** > Clear and unambiguous is good... overly specific is not. Remember that we have the media type attribute to help make things less ambiguous... the link rel itself should never be defined in terms of a single representation type (e.g. "updates-from" could point to any type of resource, not just an atom document). - James > ** > > The link rels proposed by james in the draft are meaningful (I do have > some doubts on about vs related, which is already registered). “avatar†> could be added there in case the draft can serve as basis for this activity. > **** > > ** ** > > For “updates-from†indeed these are specific to activity streams > represented in atom, and should not vary their meaning (besides a type > parameter which could allow for json as well): for this reason the > reference to activitystreams could be stronger imo. maybe “activities�*** > * > > ** ** > > walter**** > > ** ** > > *Da:* apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > *Per conto di *Paul E. Jones > *Inviato:* martedì 20 novembre 2012 6.01 > *A:* 'James M Snell'; 'Dick Hardt' > *Cc:* webfinger@googlegroups.com; 'IETF Apps Discuss' > *Oggetto:* Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt**** > > ** ** > > James,**** > > ** ** > > I think the “updates-from†was intended to be an ATOM feed, though I might > be wrong. In your example, you show a blog. But, at the same time we want > to define “blog†as its own rel.**** > > ** ** > > I think it’s important that we have a very narrow scope for any rel. I > don’t care what the values are, but we need to ensure there is no ambiguity > in what a given token means.**** > > ** ** > > Paul**** > > ** ** > > *From:* James M Snell [mailto:jasnell@gmail.com] > *Sent:* Monday, November 19, 2012 12:36 PM > *To:* Dick Hardt > *Cc:* Paul E. Jones; webfinger@googlegroups.com; IETF Apps Discuss > *Subject:* Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt**** > > ** ** > > Just a quick note on this... I already have the existing "Additional Link > Relations" draft [1] in progress (currently submitted as an independent > submission) that registers link relations such as "about", "type", > "terms-of-service", "privacy-policy" and "preview". It would be possible to > pull this draft back and add a few more link relation types to it if > necessary. We would just need to identify the set of new link rels and I > could very easily drop them in or write up a quick second document based on > the same simple template.**** > > ** ** > > [1] http://tools.ietf.org/html/draft-snell-additional-link-relations-06*** > * > > ** ** > > That said, the "about" link relation can be used to link to both > profile-page and vcard type resources... differentiated, of course, by the > media type of the linked resource. **** > > ** ** > > Also... We need to be careful not to get too specific with link relation > labels. The rel values themselves are intended to state the nature of the > relationship and not the type of resource it is. Having something like > {"rel":"updates","href":"http://example.org/my/blog","type":"text/html"} > should be generally preferable over something like {"rel":"blog","href":" > http://example.org/my/blog"}. **** > > ** ** > > - James**** > > ** ** > > On Sun, Nov 18, 2012 at 2:22 PM, Dick Hardt wrote:* > *** > > Hi Paul**** > > ** ** > > I agree it should be separate drafts. I'd be willing to edit if there is > interest. My interest in WebFinger is as a consumer much more than a > publisher - so I don't feel I am a domain expert.**** > > ** ** > > Is it possible to have meaningful examples with existing "rel" values, or > do we need to have some others defined to have meaningful examples?**** > > ** ** > > -- Dick**** > > ** ** > > On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" > wrote:**** > > ** ** > > Dick,**** > > **** > > These should be separate drafts. I agree “blog†is good, but there are > surely more. A lot of good ones are defined under webfinger.net, too.**** > > **** > > But I would really prefer to not slow down this draft with addition of > link relation values. If somebody (you?) wants to start a WebFinger Link > Relations document, I think it would be timely.**** > > **** > > Paul**** > > **** > > **** > > PEJ: They could. The challenge is that we have no other URI type defined > for this purpose. For the examples, we have a chicken and egg problem.*** > * > > **** > > Let's define some then! This is the one area that is vague and IMHO is a > barrier to adoption. What should the "rel" values be for items that I want > to publish? If we don't spec the common ones, we will end up with several > different identifiers for the same thing. Challenge of course is that > getting agreement on schema is always fun, but better to have some that > will be used that are not already defined.**** > > **** > > Need to add an IANA section for that of course.**** > > **** > > "blog" is a good one :)**** > > ** ** > > > _______________________________________________ > 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.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa > mail se non è necessario.* > > ------TXD3IX3M7ZK7PSCJQWJ61GVOKI2UM0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I agree if it's just a format change (ATOM vs. RSS), but I would hope we can agree that if "updates-from" is one of those typed of feeds, that it would not apply to a blog and that blog should be a different rel.

Paul

From: James M Snell <jasnell@gmail.com>
Sent: Tue Nov 20 10:42:04 EST 2012
To: Goix Laurent Walter <laurentwalter.goix@telecomitalia.it>
Cc: "Paul E. Jones" <paulej@packetizer.com>, Dick Hardt <dick.hardt@gmail.com>, "webfinger@googlegroups.com" <webfinger@googlegroups.com>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Link rels




On Tue, Nov 20, 2012 at 5:39 AM, Goix Laurent Walter <laurentwalter.goix@telecomitalia.it> wrote:

+1 for narrow & unambiguous rels with clear semantics that guarantee interop (btw I think we are deriving from the core webfinger discussion here so I changed the subject)

 


Clear and unambiguous is good... overly specific is not. Remember that we have the media type attribute to help make things less ambiguous... the link rel itself should never be defined in terms of a single representation type (e.g. "updates-from" could point to any type of resource, not just an atom document).

- James
 

The link rels proposed by james in the draft are meaningful (I do have some doubts on about vs related, which is already registered). “avatar†could be added there in case the draft can serve as basis for this activity.

 

For “updates-from†indeed these are specific to activity streams represented in atom, and should not vary their meaning (besides a type parameter which could allow for json as well): for this reason the reference to activitystreams could be stronger imo. maybe “activities�

 

walter

 

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di Paul E. Jones
Inviato: martedì 20 novembre 2012 6.01
A: 'James M Snell'; 'Dick Hardt'
Cc: webfinger@googlegroups.com; 'IETF Apps Discuss'
Oggetto: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

 

James,

 

I think the “updates-from†was intended to be an ATOM feed, though I might be wrong.  In your example, you show a blog.  But, at the same time we want to define “blog†as its own rel.

 

I think it’s important that we have a very narrow scope for any rel.  I don’t care what the values are, but we need to ensure there is no ambiguity in what a given token means.

 

Paul

 

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, November 19, 2012 12:36 PM
To: Dick Hardt
Cc: Paul E. Jones; webfinger@googlegroups.com; IETF Apps Discuss
Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

 

Just a quick note on this... I already have the existing "Additional Link Relations" draft [1] in progress (currently submitted as an independent submission) that registers link relations such as "about", "type", "terms-of-service", "privacy-policy" and "preview". It would be possible to pull this draft back and add a few more link relation types to it if necessary. We would just need to identify the set of new link rels and I could very easily drop them in or write up a quick second document based on the same simple template.

 

 

That said, the "about" link relation can be used to link to both profile-page and vcard type resources... differentiated, of course, by the media type of the linked resource. 

 

Also... We need to be careful not to get too specific with link relation labels. The rel values themselves are intended to state the nature of the relationship and not the type of resource it is. Having something like {"rel":"updates","href":"http://example.org/my/blog","type":"text/html"} should be generally preferable over something like {"rel":"blog","href":"http://example.org/my/blog"}. 

 

- James

 

On Sun, Nov 18, 2012 at 2:22 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hi Paul

 

I agree it should be separate drafts. I'd be willing to edit if there is interest. My interest in WebFinger is as a consumer much more than a publisher - so I don't feel I am a domain expert.

 

Is it possible to have meaningful examples with existing "rel" values, or do we need to have some others defined to have meaningful examples?

 

-- Dick

 

On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:

 

Dick,

 

These should be separate drafts.  I agree “blog†is good, but there are surely more.  A lot of good ones are defined under webfinger.net, too.

 

But I would really prefer to not slow down this draft with addition of link relation values.  If somebody (you?) wants to start a WebFinger Link Relations document, I think it would be timely.

 

Paul

 

 

PEJ: They could.  The challenge is that we have no other URI type defined for this purpose.  For the examples, we have a chicken and egg problem.

 

Let's define some then! This is the one area that is vague and IMHO is a barrier to adoption. What should the "rel" values be for items that I want to publish? If we don't spec the common ones, we will end up with several different identifiers for the same thing. Challenge of course is that getting agreement on schema is always fun, but better to have some that will be used that are not already defined.

 

Need to add an IANA section for that of course.

 

"blog" is a good one :)

 


_______________________________________________
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.

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è necessario.


------TXD3IX3M7ZK7PSCJQWJ61GVOKI2UM0-- From paulej@packetizer.com Tue Nov 20 10:01: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 B1E4421F87BA for ; Tue, 20 Nov 2012 10:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[AWL=-0.298, 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 NPNPsDBIRiiR for ; Tue, 20 Nov 2012 10:01:33 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8F21F86E5 for ; Tue, 20 Nov 2012 10:01:33 -0800 (PST) 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 qAKI1UV4031285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Nov 2012 13:01:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353434491; bh=meKz/RwfzeyYgKcX1nLNn1xXEvrfHfB2tZKzK73z4Po=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=srTzYhmc/7mBSf8chdaxnWXlQXfhHe2BsKqa0WYyQVveFKRmv0+sP9aeq0s4udbqA 6rcxrbke9jebG9J5f+HYvgTDxAq3F9ZXNfZMcBS3hYYhLEdm8WyfJBYBgL/IDt2jPu gJ5FmO9fAQyHIpCkCHNlGHX2Q1OcsJG3P8ajbSjY= From: "Paul E. Jones" To: "'Goix Laurent Walter'" , "'Dick Hardt'" References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> <024301cdc6db$3aed2550$b0c76ff0$@packetizer.com> <02d601cdc746$bffd2950$3ff77bf0$@packetizer.com> In-Reply-To: Date: Tue, 20 Nov 2012 13:01:41 -0500 Message-ID: <030901cdc749$18a5c6f0$49f154d0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_030A_01CDC71F.2FD22FF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI/YWaFkAYvx4DQsUUjuXKAy/yifQJJ+dZ9Ajy5+20BY9p1VAJ+l/RsAmfvVTQB2jbl4gLBmsrkAatQWkoAfYviCQHZHmtTArFrWPgCqXTcd5ZJgSxw Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Tue, 20 Nov 2012 18:01:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_030A_01CDC71F.2FD22FF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_030B_01CDC71F.2FD22FF0" ------=_NextPart_001_030B_01CDC71F.2FD22FF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable How do we do that? The registry location might move one day. I note we = don=E2=80=99t provide URLs to RFCs, likely for the same reason. =20 Paul =20 From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]=20 Sent: Tuesday, November 20, 2012 12:49 PM To: Paul E. Jones; 'Dick Hardt' Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Subject: R: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt =20 +1 to all suggestions. Minor addition is to add a pointer to the iana = link rel registry uri as informative reference. =20 Da: Paul E. Jones [mailto:paulej@packetizer.com]=20 Inviato: marted=C3=AC 20 novembre 2012 18.45 A: Goix Laurent Walter; 'Dick Hardt' Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Oggetto: RE: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt =20 If we can agree to add =E2=80=9Cvcard=E2=80=9D and = =E2=80=9Cblog=E2=80=9D to the document James and/or Dick and/or Gonzalo = are working on, the that would be best. I=E2=80=99ll change the IMAP = and SMTP server ones to be http://example.net/rel/imap-server, for = example. =20 =20 I=E2=80=99ll remove the second paragraph in section 3. Since = we=E2=80=99re removing that and there is already some dialog in section = 2, I propose we add one more sentence to the end of Section 2 that says: =20 WebFinger also uses the "rel" attribute, where the "rel" value is either = a single IANA-registered link relation type or a URI. =20 It is stated in section 5.4 that a host may return one or more URIs that = serve as aliases. However, I=E2=80=99ll add another sentence in Section = 4. It=E2=80=99s important that we ensure we have all of the normative = language somewhere other than Section 4, though. How about this right = after =E2=80=9Cany valid alias for the user might also be = used.=E2=80=9D: =20 An alias is a URI that is different from the =E2=80=9Csubject=E2=80=9D = URI that identifies the same entity. In the above example, there is one = =E2=80=9Chttp=E2=80=9D alias returned, though there might have been more = than one. =20 Paul =20 From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]=20 Sent: Tuesday, November 20, 2012 8:57 AM To: Paul E. Jones; 'Dick Hardt' Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Subject: R: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt =20 Hi paul, =20 Comments in red w> =20 Da: Paul E. Jones [mailto:paulej@packetizer.com]=20 Inviato: marted=C3=AC 20 novembre 2012 5.55 A: Goix Laurent Walter; 'Dick Hardt' Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Oggetto: RE: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt =20 Walter, =20 For the link relations=E2=80=A6 this gets tough. I could certainly = replace: http://webfinger.net/rel/profile-page with http://example.com/rel/profile-page =20 However, the former is really used today. I think we can be fairly safe = in assuming =E2=80=9Cvcard=E2=80=9D is going to exist one day. We can = probably agree that =E2=80=9Cblog=E2=80=9D will exist. I could make = that one change. But, what about the webfinger.net URIs? Those are = real, but there is nothing I can reference. Since they are URIs rels, = it should be expected. =20 w> This is my feeling as well that URIs rels should be referenceable. = Anyway the =E2=80=9Cwebfinger.net=E2=80=9D ones are indeed used so they = can be kept in the current examples (my comment was more for future work = in having them registered to avoid this issue). Regarding simple tokens = mentioned as examples (vcard, blog) I do have some more doubts if they = are not registered yet and as such if we don=E2=80=99t replace them with = example URIs I would suggest to state explicitly that they are = fictitious. =20 For the text in section 3, I think you are referring to the bit about = IRIs? I forgot who provided that text, but it has been there for a = while and I didn=E2=80=99t write it. I, too, think it=E2=80=99s = unnecessary at this point, but=E2=80=A6 what is the preference of the = group? (Especially whomever provided the text in the first place.) =20 w> I was referring to that part yes. =20 For 4.1, I really meant =E2=80=9Cany valid alias=E2=80=9D. Not all URIs = for a user are aliases that will return the same content. In the = follow-on sentence, I refer explicitly to the alias shown in the = example. =20 w> I agree not all uris are aliases. My point was on clarifying that all = aliases need to be URIS J. You may add at the end of that sentence = =E2=80=9C(as long as it is a URI)=E2=80=9D or something similar. =20 In 5.2, the =E2=80=9Cexpires=E2=80=9D element is supposed to come first. = This is an error in RFC 6415. =20 w> right, I double-checked the xrd spec. walter 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 = =C3=A8 necessario.=20 =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 = =C3=A8 necessario.=20 =20 ------=_NextPart_001_030B_01CDC71F.2FD22FF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

How do we do that?=C2=A0 The registry location might move one = day.=C2=A0 I note we don=E2=80=99t provide URLs to RFCs, likely for the = same reason.

 

Paul

 

From:= = Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] =
Sent: Tuesday, November 20, 2012 12:49 PM
To: Paul = E. Jones; 'Dick Hardt'
Cc: webfinger@googlegroups.com; = apps-discuss@ietf.org
Subject: R: [apps-discuss] New = draft-ietf-appsawg-webfinger-03.txt

 

+1 to all suggestions. Minor addition is to add a pointer to the iana = link rel registry uri as informative reference.

 

Da: Paul E. = Jones [mailto:paulej@packetizer.com] =
Inviato: marted=C3=AC 20 novembre 2012 18.45
A: = Goix Laurent Walter; 'Dick Hardt'
Cc: webfinger@googlegroups.com= ; apps-discuss@ietf.org
Ogg= etto: RE: [apps-discuss] New = draft-ietf-appsawg-webfinger-03.txt

 

If we can agree to add =E2=80=9Cvcard=E2=80=9D and = =E2=80=9Cblog=E2=80=9D to the document James and/or Dick and/or Gonzalo = are working on, the that would be best.  I=E2=80=99ll change the = IMAP and SMTP server ones to be http://example.net/rel/imap-s= erver, for example. 

 

I=E2=80=99ll remove the second paragraph in section 3.  Since = we=E2=80=99re removing that and there is already some dialog in section = 2, I propose we add one more sentence to the end of Section 2 that = says:

 

WebFinger also uses the "rel" attribute, where the = "rel" value is either a single IANA-registered link relation = type or a URI.

 

It is stated in section 5.4 that a host may return one or more URIs = that serve as aliases.  However, I=E2=80=99ll add another sentence = in Section 4.  It=E2=80=99s important that we ensure we have all of = the normative language somewhere other than Section 4, though.  How = about this right after =E2=80=9Cany valid alias for the user might also = be used.=E2=80=9D:

 

An alias is a URI that is different from the = =E2=80=9Csubject=E2=80=9D URI that identifies the same entity.  In = the above example, there is one =E2=80=9Chttp=E2=80=9D alias returned, = though there might have been more than one.

 

Paul

 

From:= = Goix Laurent Walter [mailto:laurentwalter.= goix@telecomitalia.it]
Sent: Tuesday, November 20, 2012 = 8:57 AM
To: Paul E. Jones; 'Dick Hardt'
Cc: webfinger@googlegroups.com= ; apps-discuss@ietf.org
Sub= ject: R: [apps-discuss] New = draft-ietf-appsawg-webfinger-03.txt

 

Hi paul,

 

Comments in r= ed w>

 

Da: Paul E. = Jones [mailto:paulej@packetizer.com] =
Inviato: marted=C3=AC 20 novembre 2012 5.55
A: Goix = Laurent Walter; 'Dick Hardt'
Cc: webfinger@googlegroups.com= ; apps-discuss@ietf.org
Ogg= etto: RE: [apps-discuss] New = draft-ietf-appsawg-webfinger-03.txt

 

Walter,

 

For the link relations=E2=80=A6 this gets tough.  I could = certainly replace:

http://webfinger.net/rel/p= rofile-page

with

http://example.com/rel/profi= le-page

 

However, the former is really used today.  I think we can be = fairly safe in assuming =E2=80=9Cvcard=E2=80=9D is going to exist one = day.  We can probably agree that =E2=80=9Cblog=E2=80=9D will = exist.  I could make that one change.  But, what about the = webfinger.net URIs?  Those are real, but there is nothing I can = reference.  Since they are URIs rels, it should be = expected.

 

w= > This is my feeling as well that URIs rels should be referenceable. = Anyway the =E2=80=9Cwebfinger.net=E2=80=9D ones are indeed used so they = can be kept in the current examples (my comment was more for future work = in having them registered to avoid this issue). Regarding simple tokens = mentioned as examples (vcard, blog) I do have some more doubts if they = are not registered yet and as such if we don=E2=80=99t replace them with = example URIs I would suggest to state explicitly that they are = fictitious.

 

For the text in section 3, I think you are referring to the bit about = IRIs?  I forgot who provided that text, but it has been there for a = while and I didn=E2=80=99t write it.  I, too, think it=E2=80=99s = unnecessary at this point, but=E2=80=A6 what is the preference of the = group?  (Especially whomever provided the text in the first = place.)

 

w= > I was referring to that part yes.

 

For 4.1, I really meant =E2=80=9Cany valid alias=E2=80=9D.  Not = all URIs for a user are aliases that will return the same content.  = In the follow-on sentence, I refer explicitly to the alias shown in the = example.

 

w= > I agree not all uris are aliases. My point was on clarifying that = all aliases need to be URIS J.= You may add at the end of that sentence =E2=80=9C(as long as it is a = URI)=E2=80=9D or something similar.

 

In 5.2, the =E2=80=9Cexpires=E2=80=9D element is supposed to come = first.  This is an error in RFC 6415.

 

w= > right, I double-checked the xrd spec.

w= alter

= 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 =C3=A8 = necessario.=

 

= 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 =C3=A8 = necessario.=

 

------=_NextPart_001_030B_01CDC71F.2FD22FF0-- ------=_NextPart_000_030A_01CDC71F.2FD22FF0 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_030A_01CDC71F.2FD22FF0-- From gsalguei@cisco.com Tue Nov 20 10:07: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 3F12621F8524 for ; Tue, 20 Nov 2012 10:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.178 X-Spam-Level: X-Spam-Status: No, score=-8.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 0YmFiSu64oap for ; Tue, 20 Nov 2012 10:07:40 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5C621F84FC for ; Tue, 20 Nov 2012 10:07:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6764; q=dns/txt; s=iport; t=1353434860; x=1354644460; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GYKeLX4PF43i6Tj1RDA1Y3wMvb8h7Luc91fygfKtMxI=; b=jV9+KQ6HyU9weUUOBzJSRMvemlLUbS8uV2OzUG02NlR1vufgCc7/IDap ZPUHD6KW7lk/14fqoM4qMXLTz6NajE139H5m1Qc6IN9qgvZgbsSIf9Y8D qsnYUbus0rz33N40APOwNFFWLMNfc0IccXUb72J1twTneGRb1z4n/zarS o=; X-Files: image001.gif : 677 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAM7Fq1CtJXHB/2dsb2JhbABFgkmDEL0BFnOCHwEBBAUgCAE2FRACAQgdAQEgBwIFEAEFFRQRAgQOBQYIh3+wFpBIjDWEFGEDjHaDKAGFX5BBgm8 X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="144519619" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 20 Nov 2012 18:07:40 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAKI7dUg012039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Nov 2012 18:07:39 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.108]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Tue, 20 Nov 2012 12:07:39 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "" Thread-Topic: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt Thread-Index: AQI/YWaFkAYvx4DQsUUjuXKAy/yifQJJ+dZ9Ajy5+20BY9p1VAJ+l/RsAmfvVTQB2jbl4gLBmsrkAatQWkoAfYviCQHZHmtTlnRNKZCAAAzU4A== Date: Tue, 20 Nov 2012 18:07:38 +0000 Message-ID: <42FE85FD-1A54-490C-8CC6-B2DE15F84FF6@cisco.com> References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> <024301cdc6db$3aed2550$b0c76ff0$@packetizer.com> , <02d601cdc746$bffd2950$3ff77bf0$@packetizer.com> In-Reply-To: <02d601cdc746$bffd2950$3ff77bf0$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/related; boundary="_004_42FE85FD1A54490C8CC6B2DE15F84FF6ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "webfinger@googlegroups.com" Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Tue, 20 Nov 2012 18:07:41 -0000 --_004_42FE85FD1A54490C8CC6B2DE15F84FF6ciscocom_ Content-Type: multipart/alternative; boundary="_000_42FE85FD1A54490C8CC6B2DE15F84FF6ciscocom_" --_000_42FE85FD1A54490C8CC6B2DE15F84FF6ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Nov 20, 2012, at 12:45 PM, "Paul E. Jones" > wrote: If we can agree to add =93vcard=94 and =93blog=94 to the document James and= /or Dick and/or Gonzalo are working on, the that would be best. We'll add those to the list for the draft Dick and I are working on for Web= finger rels. We'll be coming to the list soon with a base set that we can = get consensus on. Cheers, Gonzalo --_000_42FE85FD1A54490C8CC6B2DE15F84FF6ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

On Nov 20, 2012, at 12:45 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:

If we can agree to add = =93vcard=94 and =93blog=94 to the document James and/or Dick and/or Gonzalo= are working on, the that would be best. 


We'll add those to the list for the draft Dick and I are working on for Web= finger rels.  We'll be coming to the list soon with a base set that we= can get consensus on.

Cheers,

Gonzalo
--_000_42FE85FD1A54490C8CC6B2DE15F84FF6ciscocom_-- --_004_42FE85FD1A54490C8CC6B2DE15F84FF6ciscocom_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=677; creation-date="Tue, 20 Nov 2012 17:45:02 GMT"; modification-date="Tue, 20 Nov 2012 17:45:02 GMT" Content-ID: Content-Transfer-Encoding: base64 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= --_004_42FE85FD1A54490C8CC6B2DE15F84FF6ciscocom_-- From msk@blackops.org Tue Nov 20 18:37: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 5EDD721F8754; Tue, 20 Nov 2012 18:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_SUBJECT=1.762] 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 82IC+HGR03Cb; Tue, 20 Nov 2012 18:37:12 -0800 (PST) Received: from medusa.blackops.org (medusa.blackops.org [208.69.40.157]) by ietfa.amsl.com (Postfix) with ESMTP id 5A42421F8678; Tue, 20 Nov 2012 18:37:12 -0800 (PST) Received: from medusa.blackops.org (msk@localhost.blackops.org [127.0.0.1]) by medusa.blackops.org (8.14.5/8.14.5) with ESMTP id qAL2b7xY073602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2012 18:37:08 -0800 (PST) (envelope-from msk@medusa.blackops.org) X-SenderID: Sendmail Sender-ID Filter v1.0.0 medusa.blackops.org qAL2b7xY073602 Authentication-Results: medusa.blackops.org; sender-id=neutral header.from=superuser@gmail.com; spf=none smtp.mfrom=msk@medusa.blackops.org DKIM-Filter: OpenDKIM Filter v2.7.0 medusa.blackops.org qAL2b7xY073602 Received: (from msk@localhost) by medusa.blackops.org (8.14.5/8.14.2/Submit) id qAL2b6Wf073600; Tue, 20 Nov 2012 18:37:06 -0800 (PST) (envelope-from msk) Date: Tue, 20 Nov 2012 18:37:06 -0800 (PST) Message-Id: <201211210237.qAL2b6Wf073600@medusa.blackops.org> From: "Murray S. Kucherawy" To: apps-discuss@ietf.org, draft-ietf-imapmove-command.all@tools.ietf.org Cc: iesg@ietf.org 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: Wed, 21 Nov 2012 02:37:16 -0000 I have been selected as the Applications Area Directorate (appsdir) reviewer for this draft. (For background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-imapmove-command Title: The IMAP Move Extension Reviewer: Murray Kucherawy Review Date: November 20, 2012 IETF Last Call Date: (ends) November 21, 2012 IESG Telechat Date: November 29, 2012 SUMMARY: This draft is almost ready for publication as a Standards Track RFC, but has a few issues that should be considerered before it is advanced. As a participant, I support the publication of this work. MAJOR ISSUES: 1) Section 4: Shouldn't each of these referenced RFCs that define other IMAP extensions be officially updated by this one? (This may not be "major" but it seems to be the one point I have that's most likely to draw a DISCUSS.) MINOR ISSUES: 1) Section 3.2, suggest: OLD: This extends the first form of the UID command (see [RFC3501], Section 6.4.8) to add ... NEW: The first form of the UID command ([RFC3501], Section 6.4.8) is extended to add ... 2) Seciton 4.1: Are we worried here about non-normative "may" and "should"? 3) I am not experienced at IMAP, but it might be helpful to include in Section 3.3 an example of what it might look like if a request to move a set of messages resulted in some messages moved and some left in place. NITS: 1) Suggest mentioning that the intent of this work is to create an atomic move operation, just to be explicit. (I think what I'm suggesting is to use the word "atomic" in your intro text.) 2) s/COPY affect MOVE/COPY also affect MOVE/ 3) s/, however,/. However,/ 4) s/even with the/even when the/ From msk@blackops.org Tue Nov 20 18:39: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 4497C21F8773; Tue, 20 Nov 2012 18:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_SUBJECT=1.762] 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 yy8+bq2DNE27; Tue, 20 Nov 2012 18:39:21 -0800 (PST) Received: from medusa.blackops.org (medusa.blackops.org [208.69.40.157]) by ietfa.amsl.com (Postfix) with ESMTP id 2116921F8765; Tue, 20 Nov 2012 18:39:21 -0800 (PST) Received: from medusa.blackops.org (msk@localhost.blackops.org [127.0.0.1]) by medusa.blackops.org (8.14.5/8.14.5) with ESMTP id qAL2dDfn073633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2012 18:39:14 -0800 (PST) (envelope-from msk@medusa.blackops.org) X-SenderID: Sendmail Sender-ID Filter v1.0.0 medusa.blackops.org qAL2dDfn073633 Authentication-Results: medusa.blackops.org; sender-id=neutral header.from=superuser@gmail.com; spf=none smtp.mfrom=msk@medusa.blackops.org DKIM-Filter: OpenDKIM Filter v2.7.0 medusa.blackops.org qAL2dDfn073633 Received: (from msk@localhost) by medusa.blackops.org (8.14.5/8.14.2/Submit) id qAL2dD1N073632; Tue, 20 Nov 2012 18:39:13 -0800 (PST) (envelope-from msk) Date: Tue, 20 Nov 2012 18:39:13 -0800 (PST) Message-Id: <201211210239.qAL2dD1N073632@medusa.blackops.org> From: "Murray S. Kucherawy" To: apps-discuss@ietf.org, draft-ietf-imapmove-command.all@tools.ietf.org Cc: iesg@ietf.org Subject: [apps-discuss] AppsDir review of draft-ietf-imapmove-command 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, 21 Nov 2012 02:39:21 -0000 I have been selected as the Applications Area Directorate (appsdir) reviewer for this draft. (For background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-imapmove-command Title: The IMAP Move Extension Reviewer: Murray Kucherawy Review Date: November 20, 2012 IETF Last Call Date: (ends) November 21, 2012 IESG Telechat Date: November 29, 2012 SUMMARY: This draft is almost ready for publication as a Standards Track RFC, but has a few issues that should be considerered before it is advanced. As a participant, I support the publication of this work. MAJOR ISSUES: 1) Section 4: Shouldn't each of these referenced RFCs that define other IMAP extensions be officially updated by this one? (This may not be "major" but it seems to be the one point I have that's most likely to draw a DISCUSS.) MINOR ISSUES: 1) Section 3.2, suggest: OLD: This extends the first form of the UID command (see [RFC3501], Section 6.4.8) to add ... NEW: The first form of the UID command ([RFC3501], Section 6.4.8) is extended to add ... 2) Seciton 4.1: Are we worried here about non-normative "may" and "should"? 3) I am not experienced at IMAP, but it might be helpful to include in Section 3.3 an example of what it might look like if a request to move a set of messages resulted in some messages moved and some left in place. NITS: 1) Suggest mentioning that the intent of this work is to create an atomic move operation, just to be explicit. (I think what I'm suggesting is to use the word "atomic" in your intro text.) 2) s/COPY affect MOVE/COPY also affect MOVE/ 3) s/, however,/. However,/ 4) s/even with the/even when the/ From superuser@gmail.com Tue Nov 20 18:39: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 8A12A21F8759; Tue, 20 Nov 2012 18:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.152, 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 T-DAQZLOnkpS; Tue, 20 Nov 2012 18:39:39 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 56CAE21F8773; Tue, 20 Nov 2012 18:39:38 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so5501278lbk.31 for ; Tue, 20 Nov 2012 18:39:37 -0800 (PST) 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=bOirZAFRSw1NWdoXe+6UFVPW0tmpPPuKnqbVhsLz7mo=; b=H9Y/wz9ukq8uINS6Yzef8eb5uIaYeg9Aqerm8exlrMSg7zM9Gy3qWaRnEAYMYwxdeH bo2LgWJ8qhwZSSWnoc7cVD1zUn9s9CzggMbfXy/hnQXZTQSMgznncn2gtSGTTFQ0sAOc nWtfB8W3iSqY2iixYy+Soz8dN6mPfDPnj9LLJUkfjfFeVda/hdZ0cUz/944OEYydgGMv 7bkzLjTTMLq+y1kQ9r9ukty7HeEVt7E9ws5ANcnD8Pap+aShoTNrvIhRCrjdHBDBfmyx 0EK2GLF4udGPKb/i5MqWFOucpVCe3+koO05NEkO3/m4a1s0cVeXmUwfX34X8KtLxH48t NrVg== MIME-Version: 1.0 Received: by 10.152.111.68 with SMTP id ig4mr12089371lab.50.1353465577049; Tue, 20 Nov 2012 18:39:37 -0800 (PST) Received: by 10.112.80.234 with HTTP; Tue, 20 Nov 2012 18:39:36 -0800 (PST) In-Reply-To: <201211210237.qAL2b6Wf073600@medusa.blackops.org> References: <201211210237.qAL2b6Wf073600@medusa.blackops.org> Date: Tue, 20 Nov 2012 18:39:36 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss , draft-ietf-imapmove-command.all@tools.ietf.org Content-Type: multipart/alternative; boundary=f46d04083b51ef8eec04cef8428f Cc: The IESG Subject: Re: [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: Wed, 21 Nov 2012 02:39:45 -0000 --f46d04083b51ef8eec04cef8428f Content-Type: text/plain; charset=ISO-8859-1 Sorry, will re-send with a Subject: field so people can track the thread. On Tue, Nov 20, 2012 at 6:37 PM, Murray S. Kucherawy wrote: > I have been selected as the Applications Area Directorate (appsdir) > reviewer > for this draft. (For background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate > ). > > Please resolve these comments along with any other Last Call comments you > may receive. Please wait for direction from your document shepherd or AD > before posting a new version of the draft. > > Document: draft-ietf-imapmove-command > Title: The IMAP Move Extension > Reviewer: Murray Kucherawy > Review Date: November 20, 2012 > IETF Last Call Date: (ends) November 21, 2012 > IESG Telechat Date: November 29, 2012 > > SUMMARY: > > This draft is almost ready for publication as a Standards Track RFC, > but has a few issues that should be considerered before it is advanced. > > As a participant, I support the publication of this work. > > MAJOR ISSUES: > > 1) Section 4: Shouldn't each of these referenced RFCs that define other > IMAP extensions be officially updated by this one? (This may not be > "major" but it seems to be the one point I have that's most likely to > draw a DISCUSS.) > > MINOR ISSUES: > > 1) Section 3.2, suggest: > > OLD: > This extends the first form of the UID command (see [RFC3501], > Section 6.4.8) to add ... > > NEW: > The first form of the UID command ([RFC3501], Section 6.4.8) is > extended to add ... > > 2) Seciton 4.1: Are we worried here about non-normative "may" and > "should"? > > 3) I am not experienced at IMAP, but it might be helpful to include in > Section 3.3 an example of what it might look like if a request to move > a set of messages resulted in some messages moved and some left in > place. > > NITS: > > 1) Suggest mentioning that the intent of this work is to create an atomic > move operation, just to be explicit. (I think what I'm suggesting is to > use the word "atomic" in your intro text.) > > 2) s/COPY affect MOVE/COPY also affect MOVE/ > > 3) s/, however,/. However,/ > > 4) s/even with the/even when the/ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d04083b51ef8eec04cef8428f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, will re-send with a Subject: field so people can track the thread.


On Tue, Nov= 20, 2012 at 6:37 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
I have been selected as the Applications Are= a Directorate (appsdir) reviewer
for this draft. =A0(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. =A0Please wait for direction from your document shepherd or AD=
before posting a new version of the draft.

Document: draft-ietf-imapmove-command
Title: The IMAP Move Extension
Reviewer: Murray Kucherawy
Review Date: November 20, 2012
IETF Last Call Date: (ends) November 21, 2012
IESG Telechat Date: November 29, 2012

SUMMARY:

This draft is almost ready for publication as a Standards Track RFC,
but has a few issues that should be considerered before it is advanced.

As a participant, I support the publication of this work.

MAJOR ISSUES:

1) Section 4: Shouldn't each of these referenced RFCs that define other=
=A0 =A0IMAP extensions be officially updated by this one? =A0(This may not = be
=A0 =A0"major" but it seems to be the one point I have that's= most likely to
=A0 =A0draw a DISCUSS.)

MINOR ISSUES:

1) Section 3.2, suggest:

OLD:
=A0 This extends the first form of the UID command (see [RFC3501],
=A0 Section 6.4.8) to add ...

NEW:
=A0 The first form of the UID command ([RFC3501], Section 6.4.8) is
=A0 extended to add ...

2) Seciton 4.1: =A0Are we worried here about non-normative "may" = and "should"?

3) I am not experienced at IMAP, but it might be helpful to include in
=A0 =A0Section 3.3 an example of what it might look like if a request to mo= ve
=A0 =A0a set of messages resulted in some messages moved and some left in p= lace.

NITS:

1) Suggest mentioning that the intent of this work is to create an atomic move operation, just to be explicit. =A0(I think what I'm suggesting is= to
use the word "atomic" in your intro text.)

2) s/COPY affect MOVE/COPY also affect MOVE/

3) s/, however,/. =A0However,/

4) s/even with the/even when the/
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--f46d04083b51ef8eec04cef8428f-- From barryleiba@gmail.com Tue Nov 20 19:55: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 4C06021F849F; Tue, 20 Nov 2012 19:55:37 -0800 (PST) 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=[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 JfvzHGjjQZGf; Tue, 20 Nov 2012 19:55:36 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E77121F8475; Tue, 20 Nov 2012 19:55:35 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so7717221vbb.31 for ; Tue, 20 Nov 2012 19:55:35 -0800 (PST) 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=CGrsBqwkikX06OskaASr2QTPaGhrZN+EP+LOWSVm8JI=; b=aZBAZ8bstQVmC7wq6oDPw+tbWVJlXH5fXwNp7RzPHOCIUViaEqa8tUuwKLGXvpakJu WWvLgu96BltzDk1tKsLaDf4jlEtPW6gb7vOVKOMC8Dp0xiodO8xcivmi2PebRELYXxOQ TXs3i/TK8e41I7Sx2ipX0fKhAUfsDGz01E0WcviydUjVXXYRTHMXSnkLOi2lI7tS7zNF zzlQ2GJcYN9ajI0mV8WeZ0bPQh2FnIu7d0TitjqRATCFjm1devoVo6NvQoHlrAhZUud5 rjE6D3JtSye9DUW9/xtSQ2M1t6BWP1k6eXQWKrDJtxPDxNkUXpig376VY3d3jhXxLH6Z JdXg== MIME-Version: 1.0 Received: by 10.59.5.229 with SMTP id cp5mr25328138ved.32.1353470135070; Tue, 20 Nov 2012 19:55:35 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Tue, 20 Nov 2012 19:55:34 -0800 (PST) In-Reply-To: <201211210239.qAL2dD1N073632@medusa.blackops.org> References: <201211210239.qAL2dD1N073632@medusa.blackops.org> Date: Tue, 20 Nov 2012 22:55:34 -0500 X-Google-Sender-Auth: KU06Cx83LCj8UagzuuYjvaAiE7g Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-imapmove-command.all@tools.ietf.org, IESG , Apps Discuss Subject: Re: [apps-discuss] AppsDir review of draft-ietf-imapmove-command 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, 21 Nov 2012 03:55:37 -0000 > 1) Section 4: Shouldn't each of these referenced RFCs that define other > IMAP extensions be officially updated by this one? Why? This is an entirely optional extension, and the only reason to be pointed at this document is if you want to implement this. It doesn't make any updates to the other protocols (including to the IMAP base, so it doesn't update 3501 either). There's absolutely no reason for "updates". > 1) Section 3.2, suggest: > > OLD: > This extends the first form of the UID command (see [RFC3501], > Section 6.4.8) to add ... > > NEW: > The first form of the UID command ([RFC3501], Section 6.4.8) is > extended to add ... You suggest that we take a perfectly good active sentence and make it passive? Please explain why you *prefer* passive voice. (Or, perhaps, please explain why passive voice is preferred.) > 2) Seciton 4.1: Are we worried here about non-normative "may" and "should"? I'm not. I know Arnt is not. I think Ned is not. And no one in the working group mentioned it. I know there are those who are bothered by it, though. I'll leave it to the editors to decide whether they should be changed. > 3) I am not experienced at IMAP, but it might be helpful to include in > Section 3.3 an example of what it might look like if a request to move > a set of messages resulted in some messages moved and some left in place. Not a bad idea. Also left to the editors to decide. If we do that, we'll have to change the existing example so that it lists all the EXPUNGE messages, rather than saying "(more expunges)". It's also a little vague anyway, because the UID MOVE specifies a set of messages by UID, and the EXPUNGE responses return them as sequence numbers, so on reading the example it's not immediately obvious how they map. > 1) Suggest mentioning that the intent of this work is to create an atomic > move operation, just to be explicit. (I think what I'm suggesting is to > use the word "atomic" in your intro text.) No. That was discussed, and we specifically decided NOT to say that. The phrase "appears to the client as a single action" was chosen carefully; we didn't want to limit implementations to servers that could actually make it atomic. That's why there's SHOULD and SHOULD NOT in Section 3.3, rather than MUST and MUST NOT. > 2) s/COPY affect MOVE/COPY also affect MOVE/ I don't see this as a nit, and I don't personally prefer having "also" in there ("in the same way" is clear enough). But I don't care, so if the editors want to change it... or leave it for the RFC Editor's style. > 3) s/, however,/. However,/ Yes; either that or "; however,"... as it is, it's a comma splice. > 4) s/even with the/even when the/ The Gen-ART review found that one as well. Barry From superuser@gmail.com Tue Nov 20 20:30: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 4338721F872D; Tue, 20 Nov 2012 20:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.149, 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 ta9rjBI0FspC; Tue, 20 Nov 2012 20:30:49 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F194421F86FE; Tue, 20 Nov 2012 20:30:48 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so5452513lah.31 for ; Tue, 20 Nov 2012 20:30:47 -0800 (PST) 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=DnhUrpmF+gnOuTKqj+UsQn9thdfg/Jx1dxX7P9fzxxA=; b=CfanQronWvt5S3ww/xxIzg+eUOZTz/nofHSMpi+ZU3YCIPDhk3WPAy/7Nv/aAmyiB8 e+rxCobSjPq5nkSZbNDZUfZ2gMTVG+Akl67QepKcfUugWK8tswepKNrssaR/E0FZO4zG qEj0KqARaRKDLQ5UGPhq02H+iJVAQuk5ORYaZijehUd5HRsET/8rC9RkBLja2/OvjOQC gpJ2nXDluO1Kaok6lGPAw9H9mg+IaMJyXKUZRfbNrbMkTPZGqHzTAOdImJo8dUxyiuX5 JmJ3tU7DbIAst3w7DFSiEf2wB3tvqHk7eph5jbZ9Acr2oWJRyfpzjLqZw+mzdXpULv9X 6mrw== MIME-Version: 1.0 Received: by 10.152.104.107 with SMTP id gd11mr16366523lab.25.1353472247824; Tue, 20 Nov 2012 20:30:47 -0800 (PST) Received: by 10.112.80.234 with HTTP; Tue, 20 Nov 2012 20:30:47 -0800 (PST) In-Reply-To: References: <201211210239.qAL2dD1N073632@medusa.blackops.org> Date: Tue, 20 Nov 2012 20:30:47 -0800 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=f46d04088d118b801b04cef9d0bf Cc: draft-ietf-imapmove-command.all@tools.ietf.org, IESG , Apps Discuss Subject: Re: [apps-discuss] AppsDir review of draft-ietf-imapmove-command 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, 21 Nov 2012 04:30:50 -0000 --f46d04088d118b801b04cef9d0bf Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 20, 2012 at 7:55 PM, Barry Leiba wrote: > > 1) Section 4: Shouldn't each of these referenced RFCs that define other > > IMAP extensions be officially updated by this one? > > Why? This is an entirely optional extension, and the only reason to > be pointed at this document is if you want to implement this. It > doesn't make any updates to the other protocols (including to the IMAP > base, so it doesn't update 3501 either). There's absolutely no reason > for "updates". > Suppose I want to add one of those other extensions to a server or client that already has MOVE. It would be nice to know that, say, UIDPLUS has implications that relate to MOVE. I had thought that's the sort of reason we use "Updates". Terribly sorry if I'd gotten the wrong impression. > > 1) Section 3.2, suggest: > > > > OLD: > > This extends the first form of the UID command (see [RFC3501], > > Section 6.4.8) to add ... > > > > NEW: > > The first form of the UID command ([RFC3501], Section 6.4.8) is > > extended to add ... > > You suggest that we take a perfectly good active sentence and make it > passive? Please explain why you *prefer* passive voice. (Or, > perhaps, please explain why passive voice is preferred.) > It's been done to my own documents by ADs in the past, so I thought that was the preference. Again, terribly sorry. -MSK --f46d04088d118b801b04cef9d0bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 20, 2012 at 7:55 PM, Barry Leiba <barryleiba@computer.o= rg> wrote:
> 1) Section 4: Shouldn't each of these referenced= RFCs that define other
> =A0 =A0IMAP extensions be officially updated by this one?

Why? =A0This is an entirely optional extension, and the only reason t= o
be pointed at this document is if you want to implement this. =A0It
doesn't make any updates to the other protocols (including to the IMAP<= br> base, so it doesn't update 3501 either). =A0There's absolutely no r= eason
for "updates".

Suppose I want to add one= of those other extensions to a server or client that already has MOVE.=A0 = It would be nice to know that, say, UIDPLUS has implications that relate to= MOVE.

I had thought that's the sort of reason we use "Updates".= =A0 Terribly sorry if I'd gotten the wrong impression.


> 1) Section 3.2, suggest:
>
> OLD:
> =A0 This extends the first form of the UID command (see [RFC3501],
> =A0 Section 6.4.8) to add ...
>
> NEW:
> =A0 The first form of the UID command ([RFC3501], Section 6.4.8) is > =A0 extended to add ...

You suggest that we take a perfectly good active sentence and make it=
passive? =A0Please explain why you *prefer* passive voice. =A0(Or,
perhaps, please explain why passive voice is preferred.)

It's been done to my own documents by ADs in the past, so I thou= ght that was the preference.=A0 Again, terribly sorry.

-MSK
--f46d04088d118b801b04cef9d0bf-- From ietfc@btconnect.com Wed Nov 21 00:55: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 C0F7E21F8692 for ; Wed, 21 Nov 2012 00:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.633 X-Spam-Level: X-Spam-Status: No, score=-5.633 tagged_above=-999 required=5 tests=[AWL=0.966, 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 edH4nK1mTq-z for ; Wed, 21 Nov 2012 00:55:41 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id BD42321F8691 for ; Wed, 21 Nov 2012 00:55:40 -0800 (PST) Received: from mail62-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 21 Nov 2012 08:55:40 +0000 Received: from mail62-tx2 (localhost [127.0.0.1]) by mail62-tx2-R.bigfish.com (Postfix) with ESMTP id F11962E0142; Wed, 21 Nov 2012 08:55:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371Ic89bh542Mzz1de0h1202h1d1ah1d2ahzz8275ch1033IL177df4h17326ah8275bh8275dhz2dh2a8h5a9h668h839h93fhd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h304l1155h) Received: from mail62-tx2 (localhost.localdomain [127.0.0.1]) by mail62-tx2 (MessageSwitch) id 1353488138155140_30010; Wed, 21 Nov 2012 08:55:38 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.238]) by mail62-tx2.bigfish.com (Postfix) with ESMTP id 215022600C9; Wed, 21 Nov 2012 08:55:38 +0000 (UTC) Received: from DB3PRD0710HT003.eurprd07.prod.outlook.com (157.56.253.85) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 21 Nov 2012 08:55:35 +0000 Received: from AMSPRD0410HT001.eurprd04.prod.outlook.com (157.56.248.37) by pod51017.outlook.com (10.255.75.38) with Microsoft SMTP Server (TLS) id 14.16.239.5; Wed, 21 Nov 2012 08:55:27 +0000 Message-ID: <00be01cdc7c5$cd739040$4001a8c0@gateway.2wire.net> From: t.petch To: "Paul E. Jones" References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com><024301cdc6db$3aed2550$b0c76ff0$@packetizer.com><02d601cdc746$bffd2950$3ff77bf0$@packetizer.com> <030901cdc749$18a5c6f0$49f154d0$@packetizer.com> Date: Wed, 21 Nov 2012 08:54:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.37] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Wed, 21 Nov 2012 08:55:41 -0000 ----- Original Message ----- From: "Paul E. Jones" To: "'Goix Laurent Walter'" ; "'Dick Hardt'" Cc: ; Sent: Tuesday, November 20, 2012 6:01 PM Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt How do we do that? The registry location might move one day. I note we don=E2=80=99t provide URLs to RFCs, likely for the same reason. Paul I am sure you don't really mean how:-) but it is quite a common practice to include URLs to the IANA website as a quick awk will show. Tom Petch Paul From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] Sent: Tuesday, November 20, 2012 12:49 PM To: Paul E. Jones; 'Dick Hardt' Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Subject: R: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt +1 to all suggestions. Minor addition is to add a pointer to the iana link rel registry uri as informative reference. Da: Paul E. Jones [mailto:paulej@packetizer.com] Inviato: marted=C3=AC 20 novembre 2012 18.45 A: Goix Laurent Walter; 'Dick Hardt' Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Oggetto: RE: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt If we can agree to add =E2=80=9Cvcard=E2=80=9D and =E2=80=9Cblog=E2=80=9D= to the document James and/or Dick and/or Gonzalo are working on, the that would be best. I=E2=80=99ll= change the IMAP and SMTP server ones to be http://example.net/rel/imap-server, for example. I=E2=80=99ll remove the second paragraph in section 3. Since we=E2=80=99= re removing that and there is already some dialog in section 2, I propose we add one more sentence to the end of Section 2 that says: WebFinger also uses the "rel" attribute, where the "rel" value is either a single IANA-registered link relation type or a URI. It is stated in section 5.4 that a host may return one or more URIs that serve as aliases. However, I=E2=80=99ll add another sentence in Section = 4. It=E2=80=99 s important that we ensure we have all of the normative language somewhere other than Section 4, though. How about this right after =E2=80= =9Cany valid alias for the user might also be used.=E2=80=9D: An alias is a URI that is different from the =E2=80=9Csubject=E2=80=9D UR= I that identifies the same entity. In the above example, there is one =E2=80=9C= http=E2=80=9D alias returned, though there might have been more than one. Paul From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] Sent: Tuesday, November 20, 2012 8:57 AM To: Paul E. Jones; 'Dick Hardt' Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Subject: R: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt Hi paul, Comments in red w> Da: Paul E. Jones [mailto:paulej@packetizer.com] Inviato: marted=C3=AC 20 novembre 2012 5.55 A: Goix Laurent Walter; 'Dick Hardt' Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Oggetto: RE: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt Walter, For the link relations=E2=80=A6 this gets tough. I could certainly repla= ce: http://webfinger.net/rel/profile-page with http://example.com/rel/profile-page However, the former is really used today. I think we can be fairly safe in assuming =E2=80=9Cvcard=E2=80=9D is going to exist one day. We can pr= obably agree that =E2=80=9Cblog=E2=80=9D will exist. I could make that one change. B= ut, what about the webfinger.net URIs? Those are real, but there is nothing I can reference. Since they are URIs rels, it should be expected. w> This is my feeling as well that URIs rels should be referenceable. Anyway the =E2=80=9Cwebfinger.net=E2=80=9D ones are indeed used so they c= an be kept in the current examples (my comment was more for future work in having them registered to avoid this issue). Regarding simple tokens mentioned as examples (vcard, blog) I do have some more doubts if they are not registered yet and as such if we don=E2=80=99t replace them with example = URIs I would suggest to state explicitly that they are fictitious. For the text in section 3, I think you are referring to the bit about IRIs? I forgot who provided that text, but it has been there for a while and I didn=E2=80=99t write it. I, too, think it=E2=80=99s unnecess= ary at this point, but=E2=80=A6 what is the preference of the group? (Especially who= mever provided the text in the first place.) w> I was referring to that part yes. For 4.1, I really meant =E2=80=9Cany valid alias=E2=80=9D. Not all URIs = for a user are aliases that will return the same content. In the follow-on sentence, I refer explicitly to the alias shown in the example. w> I agree not all uris are aliases. My point was on clarifying that all aliases need to be URIS J. You may add at the end of that sentence =E2=80= =9C(as long as it is a URI)=E2=80=9D or something similar. In 5.2, the =E2=80=9Cexpires=E2=80=9D element is supposed to come first. = This is an error in RFC 6415. w> right, I double-checked the xrd spec. walter 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. rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non =C3=A8 necessario. 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. rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non =C3=A8 necessario. ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From yaojk@cnnic.cn Wed Nov 21 02:23: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 124DC21F8536 for ; Wed, 21 Nov 2012 02:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.639 X-Spam-Level: X-Spam-Status: No, score=-99.639 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, MIME_BASE64_TEXT=1.753, 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 XZeVBO8p3AsT for ; Wed, 21 Nov 2012 02:23:45 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 161B721F8534 for ; Wed, 21 Nov 2012 02:23:42 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 21 Nov 2012 18:23:35 +0800 Message-ID: <5369D6AD7E394063A33B0CAD00A80100@LENOVO47E041CF> From: "Jiankang YAO" To: , Date: Wed, 21 Nov 2012 18:23:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: [apps-discuss] APPSDIR review of draft-ietf-v6ops-icp-guidance-04 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, 21 Nov 2012 10:23:46 -0000 SSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIEFwcGxpY2F0aW9ucyBBcmVhIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIA0KZHJhZnQgKGZvciBiYWNrZ3JvdW5kIG9uIGFwcHNkaXIsIHBs ZWFzZSBzZWUgDQpodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL2FwcC90cmFjL3dpa2kv QXBwbGljYXRpb25zQXJlYURpcmVjdG9yYXRlICkuDQoNClBsZWFzZSByZXNvbHZlIHRoZXNlIGNv bW1lbnRzIGFsb25nIHdpdGggYW55IG90aGVyIGNvbW1lbnRzIHlvdSANCm1heSByZWNlaXZlLiAg DQpEb2N1bWVudDogZHJhZnQtaWV0Zi12Nm9wcy1pY3AtZ3VpZGFuY2UtMDQNClRpdGxlOiBJUHY2 IEd1aWRhbmNlIGZvciBJbnRlcm5ldCBDb250ZW50IGFuZCBBcHBsaWNhdGlvbiBTZXJ2aWNlIFBy b3ZpZGVycw0KUmV2aWV3ZXI6IEppYW5rYW5nIFlhbyANClJldmlldyBEYXRlOiAyMCBOb3YuIDIw MTIgDQpTdW1tYXJ5OiAgVGhpcyBkcmFmdCBpcyBhbG1vc3QgcmVhZHkgZm9yIHB1YmxpY2F0aW9u IGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLg0KDQpNYWpvciBJc3N1ZXM6IG5vbmUNCk1pbm9yIElz c3Vlczogbm9uZQ0KDQpOaXRzOiANCjEpVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBmb2xsb3cgdGhl IEtleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgW1JGQyAyMTE5XS4gRm9yIGV4YW1wbGUsIGFsbW9z dCBhbGwgIm1heSBvciBtdXN0ICIgIHVzZSBsb3dlciBjYXNlcy4NCg0K From barryleiba.mailing.lists@gmail.com Wed Nov 21 06:04: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 8C90321F86A0; Wed, 21 Nov 2012 06:04:29 -0800 (PST) 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=[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 9iqN-rusp37m; Wed, 21 Nov 2012 06:04:29 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 74E2121F8691; Wed, 21 Nov 2012 06:04:28 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so5960548lbk.31 for ; Wed, 21 Nov 2012 06:04:27 -0800 (PST) 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=TPJzlF+M6HBypDtbw/6rks/TAL7zPiyVGawGKyr+oVs=; b=iRVTFEU5/rN1Ar0qQeIaRs40I860RTOxXeaebO/LUSAlspb5X/FOJyEgPGPTZDvCVn ZunmHSCVUYyThuz2V2y7BCoIibMBGbxkZlnzs3EX+YxecnEkRDYGtuAqEP+cGWVp/HQb RyjQVejeKU/lDnSR4WnvsRw5VWuUW+NLqW7s7XGxe8KCXhiWRHv3vugThndQ7dBghaOH 7wjoprKxfABX4921jN98uVmjwUmshWWgwwmwxEpNylwmRdPkaX8y0mUmbfvEn4dajHVW bN+mxt4HSAEIXT+35n9N59GGCl3NEysZJantmTz1PmDRHB2guY4Fxzgq1aiLc/CmS5ko /PKA== MIME-Version: 1.0 Received: by 10.152.108.197 with SMTP id hm5mr18008259lab.45.1353506667017; Wed, 21 Nov 2012 06:04:27 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Wed, 21 Nov 2012 06:04:26 -0800 (PST) In-Reply-To: References: <201211210239.qAL2dD1N073632@medusa.blackops.org> Date: Wed, 21 Nov 2012 09:04:26 -0500 X-Google-Sender-Auth: wN6ACm8XHFz636ah2jiYMkJei-Q Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-imapmove-command.all@tools.ietf.org, IESG , Apps Discuss Subject: Re: [apps-discuss] AppsDir review of draft-ietf-imapmove-command 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, 21 Nov 2012 14:04:29 -0000 >> > 1) Section 4: Shouldn't each of these referenced RFCs that define other >> > IMAP extensions be officially updated by this one? >> >> Why? This is an entirely optional extension, and the only reason to >> be pointed at this document is if you want to implement this. It >> doesn't make any updates to the other protocols (including to the IMAP >> base, so it doesn't update 3501 either). There's absolutely no reason >> for "updates". > > Suppose I want to add one of those other extensions to a server or client > that already has MOVE. It would be nice to know that, say, UIDPLUS has > implications that relate to MOVE. > > I had thought that's the sort of reason we use "Updates". Terribly sorry if > I'd gotten the wrong impression. No reason to be terrible. The IESG is working on some guidance about using "updates", which we're not done with yet. I don't think this is going to fall into it. The basic reasons are (1) this document *actually* updates the other one (changes something in it), and (2) more generally, if you're implementing the old document, we absolutely want you to look at this one when you do. Your point is an interesting one. We could say that, well, you've implemented MOVE, so you know that you have to go check it again... but that's clearly not on for a number of reasons, and doesn't scale. On the other hand, if we used that logic for every combination of extensions, we'd have an "updates" spaghetti bowl that's so complicated that no one could sort it out. We'll have to consider that when we write the guidance. >> You suggest that we take a perfectly good active sentence and make it >> passive? Please explain why you *prefer* passive voice. (Or, >> perhaps, please explain why passive voice is preferred.) > > It's been done to my own documents by ADs in the past, so I thought that was > the preference. Again, terribly sorry. Interesting. What I've generally seen (and what I prefer) is a move *away* from passive voice, to make it clearer who has to do what (this specification says this, the server has to do that, the client is responsible for the other). Passive voice has its place, but it generally obfuscates (or at least downplays) who takes the action. Barry From barryleiba.mailing.lists@gmail.com Wed Nov 21 06: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 5326821F85C8 for ; Wed, 21 Nov 2012 06:09:29 -0800 (PST) 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=[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 BvjCmjlTIPCs for ; Wed, 21 Nov 2012 06:09:28 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1593521F85C2 for ; Wed, 21 Nov 2012 06:09:27 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so5868518lah.31 for ; Wed, 21 Nov 2012 06:09:27 -0800 (PST) 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 :content-transfer-encoding; bh=4KX7mORXwhrCo7GF8fLb1bOdpqgereLvEHPHWnWD9E0=; b=PC2cQWp2i1+i5mneg2N+itjjYUmESzdJ84PWxICzW0O1T3MeJX/pZYQ5ziZYzFrWih kPqiFv2mwjsdUUybf3oJSV3yINjKDyaLye6oO6+gwX6Fqa465G3vFWxP5Kh61JtFYddl Ub2+/ZzH9QsnG/S07Jh6/+KDbgGcKcBugvZkYGja0yEyOeWm/aNL5upMvrWq20vjyT0W HzUjMpWTRut5yMWNFDYShpZp8TqCj4t3gF3xERdM6ZZ76Sf4Gr0/xGVaEKqcRb+hp4sn H9AY9VWrVyMNwZcf/4HQ56CIQYdFmLYXz/msPM9yIj/ZhQtuAZIWHdWDVZYJLKiyUfuS 2FoQ== MIME-Version: 1.0 Received: by 10.152.111.166 with SMTP id ij6mr17973646lab.38.1353506966929; Wed, 21 Nov 2012 06:09:26 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Wed, 21 Nov 2012 06:09:26 -0800 (PST) In-Reply-To: <030901cdc749$18a5c6f0$49f154d0$@packetizer.com> References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> <024301cdc6db$3aed2550$b0c76ff0$@packetizer.com> <02d601cdc746$bffd2950$3ff77bf0$@packetizer.com> <030901cdc749$18a5c6f0$49f154d0$@packetizer.com> Date: Wed, 21 Nov 2012 09:09:26 -0500 X-Google-Sender-Auth: y13bC1K4CxwBK4z15CeRGdRIpF8 Message-ID: From: Barry Leiba To: "Paul E. Jones" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" , webfinger@googlegroups.com Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-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: Wed, 21 Nov 2012 14:09:29 -0000 >> +1 to all suggestions. Minor addition is to add a pointer to the iana >> link rel registry uri as informative reference. > > How do we do that? The registry location might move one day. I note > we don=92t provide URLs to RFCs, likely for the same reason. It's always a good idea to use the registry URL in an I-D, to be sure that everyone (including IANA) knows which registry you're talking about, and that there's no ambiguity. Whether the URL remains in the published RFC is a separate issue. When you include registry URLs, IANA prefers that you omit the final bit -- for link relations, use this: http://www.iana.org/assignments/link-relations/ ...and NOT this: http://www.iana.org/assignments/link-relations/link-relations.xml That way, if a registry is converted from HTML to XML or whatever (perhaps from XML to JSON in the future?), the link you use will not change. Barry, Apps AD From barryleiba.mailing.lists@gmail.com Wed Nov 21 09:46: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 6977921F84C0 for ; Wed, 21 Nov 2012 09:46:52 -0800 (PST) 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=[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 sYApgNL7-OaI for ; Wed, 21 Nov 2012 09:46:51 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8522D21F84BA for ; Wed, 21 Nov 2012 09:46:48 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so6155123lbk.31 for ; Wed, 21 Nov 2012 09:46:47 -0800 (PST) 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=jq0n/ms/jDPkP+xmnMFik50+Jt6dMFEs6zadjoMa0iQ=; b=MKM5Ktw/n2WIu3X3id07VjtZNEeD1jbYUFOpvrv54g68iap6N3IWxXEWTl4Yk4/NzC LH9INj3kHrK0qNG9bIWZOJptrxeoNW6t8y+4BIeXj2EcnJamBqIJuZQc1huVe686zH13 MWlfXCMf/irLfcDqdWjlc4q2TCGfsC6iHT9rmRPt00x2R6ed9oEPYaOIpG/1oJb9vGJq 5oczQ1DFUjDfRoILh3bEJvY0nDVmJvnYtVkoKlA9aEqrrlbTbKgRua5SWt4ZaMI2noU9 4y4y9yZKLOG8mJfqHU0QAQaS/GZ/bZhv2ZUCb5AfqLiPbIQxjCVwnOIM9K3U5XiNUUAa Oyrw== MIME-Version: 1.0 Received: by 10.152.105.68 with SMTP id gk4mr18303081lab.48.1353520007125; Wed, 21 Nov 2012 09:46:47 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Wed, 21 Nov 2012 09:46:46 -0800 (PST) In-Reply-To: <5369D6AD7E394063A33B0CAD00A80100@LENOVO47E041CF> References: <5369D6AD7E394063A33B0CAD00A80100@LENOVO47E041CF> Date: Wed, 21 Nov 2012 12:46:46 -0500 X-Google-Sender-Auth: -NXR0c7yzfD9pQEIp3BG86lzLng Message-ID: From: Barry Leiba To: Jiankang YAO Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" , draft-ietf-v6ops-icp-guidance.all@tools.ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-v6ops-icp-guidance-04 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, 21 Nov 2012 17:46:52 -0000 > Nits: > 1)This document does not follow the Key words for use in RFCs [RFC 2119]. > For example, almost all "may or must " use lower cases. But it's an Informational document, and makes no reference to 2119 at all, so that's fine -- not even a nit there. Barry From ned.freed@mrochek.com Wed Nov 21 11:39: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 9C9FE21F8881; Wed, 21 Nov 2012 11:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 HcQIBX8IdCBp; Wed, 21 Nov 2012 11:39:57 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id F030421F885A; Wed, 21 Nov 2012 11:39:56 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMVT5MRXM80023LN@mauve.mrochek.com>; Wed, 21 Nov 2012 11:34:54 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMGB2WUMLC00008S@mauve.mrochek.com>; Wed, 21 Nov 2012 11:34:51 -0800 (PST) Message-id: <01OMVT5L5UQS00008S@mauve.mrochek.com> Date: Wed, 21 Nov 2012 11:18:35 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 20 Nov 2012 22:55:34 -0500" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <201211210239.qAL2dD1N073632@medusa.blackops.org> To: Barry Leiba Cc: draft-ietf-imapmove-command.all@tools.ietf.org, IESG , Apps Discuss Subject: Re: [apps-discuss] AppsDir review of draft-ietf-imapmove-command 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, 21 Nov 2012 19:39:57 -0000 > > 1) Section 4: Shouldn't each of these referenced RFCs that define other > > IMAP extensions be officially updated by this one? > Why? This is an entirely optional extension, and the only reason to > be pointed at this document is if you want to implement this. It > doesn't make any updates to the other protocols (including to the IMAP > base, so it doesn't update 3501 either). There's absolutely no reason > for "updates". The whole "let's repeat the Updates:/Obsoletes: lines in the Abstract" business is more than enough for me; I'm not touching this one with a stick. > > 1) Section 3.2, suggest: > > > > OLD: > > This extends the first form of the UID command (see [RFC3501], > > Section 6.4.8) to add ... > > > > NEW: > > The first form of the UID command ([RFC3501], Section 6.4.8) is > > extended to add ... > You suggest that we take a perfectly good active sentence and make it > passive? Please explain why you *prefer* passive voice. (Or, > perhaps, please explain why passive voice is preferred.) I use passive voice too much as it is; I'm not inclined to use more. > > 2) Seciton 4.1: Are we worried here about non-normative "may" and "should"? > I'm not. I know Arnt is not. I think Ned is not. And no one in the > working group mentioned it. I had a huge argument with Dave Crocker about this. Suffice it to say I'm not on board with worrying about lower case "may" and "should". > I know there are those who are bothered by it, though. I'll leave it > to the editors to decide whether they should be changed. > > 3) I am not experienced at IMAP, but it might be helpful to include in > > Section 3.3 an example of what it might look like if a request to move > > a set of messages resulted in some messages moved and some left in place. > Not a bad idea. Also left to the editors to decide. If we do that, > we'll have to change the existing example so that it lists all the > EXPUNGE messages, rather than saying "(more expunges)". It's also a > little vague anyway, because the UID MOVE specifies a set of messages > by UID, and the EXPUNGE responses return them as sequence numbers, so > on reading the example it's not immediately obvious how they map. > > 1) Suggest mentioning that the intent of this work is to create an atomic > > move operation, just to be explicit. (I think what I'm suggesting is to > > use the word "atomic" in your intro text.) > No. That was discussed, and we specifically decided NOT to say that. > The phrase "appears to the client as a single action" was chosen > carefully; we didn't want to limit implementations to servers that > could actually make it atomic. That's why there's SHOULD and SHOULD > NOT in Section 3.3, rather than MUST and MUST NOT. Agreed on all points. > > 2) s/COPY affect MOVE/COPY also affect MOVE/ > I don't see this as a nit, and I don't personally prefer having "also" > in there ("in the same way" is clear enough). But I don't care, so if > the editors want to change it... or leave it for the RFC Editor's > style. I think we can leave it to the RFC Editor. I actually don't know which way they would go - I could just as easily see them removing an "also" we added. > > 3) s/, however,/. However,/ > Yes; either that or "; however,"... as it is, it's a comma splice. I slightly prefer the separate sentence, so that's the way I'll go. Ned From internet-drafts@ietf.org Wed Nov 21 19:55: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 182A621E8053; Wed, 21 Nov 2012 19:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 H9BsY7gXZrIw; Wed, 21 Nov 2012 19:55:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60B521E8083; Wed, 21 Nov 2012 19:55:08 -0800 (PST) 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.36 Message-ID: <20121122035508.27832.18432.idtracker@ietfa.amsl.com> Date: Wed, 21 Nov 2012 19:55:08 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-04.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, 22 Nov 2012 03:55:09 -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 : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-ietf-appsawg-webfinger-04.txt Pages : 17 Date : 2012-11-21 Abstract: This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paulej@packetizer.com Wed Nov 21 20:13: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 86D7621E8053 for ; Wed, 21 Nov 2012 20:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.393, 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 YfsbC5YuFlfi for ; Wed, 21 Nov 2012 20:13:48 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC9521E8085 for ; Wed, 21 Nov 2012 20:13:48 -0800 (PST) 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 qAM4DkXh025407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Nov 2012 23:13:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353557627; bh=Adqpvm/iHaySspZ/QSL/Kzm38Iae7rJC6VOnMKgU7l8=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=X9a/EwjYwB/tKsrQ7pMetDh1VZuURu6865o+vKz35ewCht6fZTpy2fnIARI/9QqPe PS6f2P80u30mkSD/t7bxfWqe3618mihmUNvg52UwCDFDaJCufIzdFeeXRWd8XBI23o +P1k+ZBIvZuJUSNH7E0YlulYrJ1ILPOE8tlH9GZE= From: "Paul E. Jones" To: , Date: Wed, 21 Nov 2012 23:13:56 -0500 Message-ID: <013e01cdc867$caf54230$60dfc690$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013F_01CDC83D.E2202490" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3IZUHlvzxVCcoNRf2fQF9+Sjr6pw== Content-Language: en-us Subject: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 22 Nov 2012 04:13:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013F_01CDC83D.E2202490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, I just posted a new draft that takes into consideration the input I received on -03 and adds the "webfinger" subdomain that was discussed on the list this past week. Specifically, here's what changed: . Mention in section 2 that WebFinger uses the "rel" attribute and provide a reference to the IANA registry for link relations . Deleted the second paragraph from section 3 that expands on link relations . Changed the link relation value for "blog" to be just the token "blog" . Corrected a syntax error in the example in 4.1 . Clarified in section 4.1 what is meant by a "valid alias" . Introduced a new section 4.2 that shows an example for OpenID Connect . Changed the rel types in 4.3 and 4.4 to be URI-based (on example.net) . Corrected syntax in 5.3 and added two clarifying sentences . Introduced a new section 5.5 that describes the "webfinger" subdomain . Changed the name of section 7 . Added language to section 8 to support section 5.5 . Added language to section 9 to support section 5.5 . Spells out Mike's name as he prefers it . Added a couple of informational references The new draft is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04 I think we're getting closer, though I know the "webfinger" subdomain might be a bit controversial. I'm on the fence on this one, myself. I can see the pros and cons of having it. I'd prefer to stay out of the debate, though. I'll put into the document whatever the group says to put into the documents :-) That said, I think Mike made a valid argument with respect to the fact that some domain owners have no ability to do anything more than insert an A record for a subdomain. I do want to highlight the fact that the current language says that if there is any response from a web server at the host, that means the host does have the capability of providing WF services and the "webfinger" subdomain should not be consulted. Thus, the webfinger subdomain would only be consulted if there is no web server running at the host at all. It's not a fallback for domain owners who have a web server, but just didn't install a WF server. For that case, they should use 3xx redirection for hosting the WF server elsewhere. Paul ------=_NextPart_000_013F_01CDC83D.E2202490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I just = posted a new draft that takes into consideration the input I received on = -03 and adds the “webfinger” subdomain that was discussed on = the list this past week.  Specifically, here’s what = changed:

·         = Mention in section 2 that WebFinger uses = the “rel” attribute and provide a reference to the IANA = registry for link relations

·         = Deleted the second paragraph from  = section 3 that expands on link relations

·         = Changed the link relation value for = “blog” to be just the token = “blog”

·         = Corrected a syntax error in the example = in 4.1

·         = Clarified in section 4.1 what is meant by = a “valid alias”

·         = Introduced a new section 4.2 that shows = an example for OpenID Connect

·         = Changed the rel types in 4.3 and 4.4 to = be URI-based (on example.net)

·         = Corrected syntax in 5.3 and added two = clarifying sentences

·         = Introduced a new section 5.5 that = describes the “webfinger” subdomain

·         = Changed the name of section = 7

·         = Added language to section 8 to support = section 5.5

·         = Added language to section 9 to support = section 5.5

·         = Spells out Mike’s name as he = prefers it

·         = Added a couple of informational = references

 

The new draft is here:

http:= //tools.ietf.org/html/draft-ietf-appsawg-webfinger-04

<= p class=3DMsoNormal> 

I think = we’re getting closer, though I know the “webfinger” = subdomain might be a bit controversial.  I’m on the fence on = this one, myself.  I can see the pros and cons of having it.  = I’d prefer to stay out of the debate, though.  I’ll put = into the document whatever the group says to put into the documents = :-)  That said, I think Mike made a valid argument with respect to = the fact that some domain owners have no ability to do anything more = than insert an A record for a subdomain.

 

I do want to = highlight the fact that the current language says that if there is any = response from a web server at the host, that means the host does have = the capability of providing WF services and the “webfinger” = subdomain should not be consulted.  Thus, the webfinger subdomain = would only be consulted if there is no web server running at the host at = all.  It’s not a fallback for domain owners who have a web = server, but just didn’t install a WF server.  For that case, = they should use 3xx redirection for hosting the WF server = elsewhere.

 

Paul

 

------=_NextPart_000_013F_01CDC83D.E2202490-- From brian.e.carpenter@gmail.com Thu Nov 22 00:14: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 B4B9A21F8724 for ; Thu, 22 Nov 2012 00:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.576 X-Spam-Level: X-Spam-Status: No, score=-101.576 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 UkzuzrwF3nQL for ; Thu, 22 Nov 2012 00:14:57 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 08DA021F8714 for ; Thu, 22 Nov 2012 00:14:56 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hm6so441875wib.13 for ; Thu, 22 Nov 2012 00:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=c9mcbq0W/zmDzf8kjdibuWcISv741nVsEt7OwenDDdI=; b=M7+lsh/iKjiI1mSqYHisaKA6sPCt1R1cU857WBUuFrBjf9+5Tao1Fo2vCmyePe+Zma Zqm1eXwKVvewDR/90qXTmQ3SlHRfPj0PRcoQOSI/LE7Unf/YQAhQMAY8rUsDk9/ckdEl RYsJGuRXSjEwDcjq0ZbeDUAXqhyYVBSCFYmNcmSHGCY6xKmE2swidoNVcVyHYE421F/T KEmbYGPFPD098Bzx9JrzhLQvrsBGZwHxim51XV7VdlcxgInDuyjm0hXXe1JSuhfQAoTm B7F8l8K4OU8mXq+dNRtukleDFm5c8mOuowWhD/BrMbHQdw6LCij+d+51nVQ3YFaGh7rK aGHA== Received: by 10.180.90.70 with SMTP id bu6mr3011497wib.20.1353572096134; Thu, 22 Nov 2012 00:14:56 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-157.as13285.net. [2.102.218.157]) by mx.google.com with ESMTPS id eu8sm2889437wib.1.2012.11.22.00.14.54 (version=SSLv3 cipher=OTHER); Thu, 22 Nov 2012 00:14:54 -0800 (PST) Message-ID: <50ADDF08.9000107@gmail.com> Date: Thu, 22 Nov 2012 08:15:04 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Barry Leiba References: <5369D6AD7E394063A33B0CAD00A80100@LENOVO47E041CF> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" , draft-ietf-v6ops-icp-guidance.all@tools.ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-v6ops-icp-guidance-04 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, 22 Nov 2012 08:14:57 -0000 Thanks Barry. The authors were not copied on the original review. Indeed, there is by intention no normative language in the draft. (Actually, use of RFC 2119 is not compulsory, even in standards and BCPs.) Regards Brian Carpenter On 21/11/2012 17:46, Barry Leiba wrote: >> Nits: >> 1)This document does not follow the Key words for use in RFCs [RFC 2119]. >> For example, almost all "may or must " use lower cases. > > But it's an Informational document, and makes no reference to 2119 at > all, so that's fine -- not even a nit there. > > Barry > From bradfitz@google.com Wed Nov 21 20:26: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 18ACF21E8084 for ; Wed, 21 Nov 2012 20:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.412, 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 Zje6FEI-WhVf for ; Wed, 21 Nov 2012 20:26:43 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 050BF21E8083 for ; Wed, 21 Nov 2012 20:26:42 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so8417065oag.31 for ; Wed, 21 Nov 2012 20:26:42 -0800 (PST) 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; bh=Oqne7FgNr6ZczmJ6jltVUf7SeLVvdXx+GULaMqaOasc=; b=JmyGFXtcJvcRvxleJj5j79GWe8qzr+IbEp4pF34erlaX0ndv1CcU1c8caCBTc4oH1S tRfBm2X4S5vlsjtIVukeeeiQAoY82v4tDoOQb+9agdB6B/S9/hj6+E/pGt6AIy1Ngmsc a4IEd8KoK83duPX1q3ctw6SqYg1buzjGufVl+5pLqPV2vpt1bFiHzkE94TsTYqMbu6oO ItCPa2kFOA7KJd+FsYavKmKmJ8QoOYMdQhw7BOWTZ0IA+bc7lxzaHJY7mvsn+OJMcmlj CFQMJMShTYyXhF6c3WDU0z3287eBLGoR4MY50lgOlu3o/3lQHQ60DPqKES6GKg1QQZGI Qalg== 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=Oqne7FgNr6ZczmJ6jltVUf7SeLVvdXx+GULaMqaOasc=; b=kFMwH4ftFmTzG0PvaRS1EGMFnUdVZiT50iRh58ujCZGek9U4ZEHy3r/RN59PCiybKG gfX+TWRmM1d/+oDYR8eqTJrzAVAW2ar4KCM+kAFZqrhuax8RSonJZ8LfOBRjEZf2cXFw RIPGjemYs8YY5w5V75weZ1NZlmScGRbfMpYh3rrXHQVdDbhwwf5Sy4N0L3OoQcaRsHeM 8aGEuz5d5nJ1YIjIAP+KS5WMntVwyHxYhxBPPGu1bi3iIob4LN5tSi2OAz2ONbEjB+FZ TJyKVd176wApX1c1Ku0BL2kfSGIqYwGzI0CvCTXRutOuwTACDoL6MwAE3qdrbtf/yE+c Q8wg== MIME-Version: 1.0 Received: by 10.182.38.69 with SMTP id e5mr18301274obk.79.1353558402526; Wed, 21 Nov 2012 20:26:42 -0800 (PST) Received: by 10.76.74.134 with HTTP; Wed, 21 Nov 2012 20:26:42 -0800 (PST) In-Reply-To: <013e01cdc867$caf54230$60dfc690$@packetizer.com> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> Date: Wed, 21 Nov 2012 20:26:42 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d04462f0ec3ef9a04cf0ddfbe X-Gm-Message-State: ALoCoQknPCsw2SG03J8HOnod9oyNY3glZe+EuatYZ6QPFZhVHAeoihdzcwzkNDeI6SgZJ5Sg+S505LbgTZm7QnOFE/ipK8iCSGqXRIKUn4+hFOD4Xo/pnDqEDFrQcpIuO9d5wUZs8g0AOliN4GOkVTyQ4Mek5X3+0jAZlQGg4fRVNBgPL66XxvZg5KKMARQWtq5WxwnmiIeH X-Mailman-Approved-At: Thu, 22 Nov 2012 10:50:31 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 22 Nov 2012 04:26:44 -0000 --f46d04462f0ec3ef9a04cf0ddfbe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The new TOC doesn't even have a section 5.5. Is that how you hide controversial stuff? :-) FWIW, I'm strongly opposed to the subdomain. It adds complexity. If you can't get your load balancing & routing act together, you don't get to play, sorry. If it's easy for the small guys, and I've seen it be easy for the medium guys, and multiple big guys have shown that it's possible, who's complaining? (rhetorical. I didn't see when this first appeared, and don't really want to know) I don't want incompetence and/or internal politics unnecessarily complicating a spec that is supposed to be simple for clients. If we all compromise, nobody wins. Actually I'll go a step further and be the dick here and say absolutely not. I'll fight for implementations that I write (and those of others whom I can influence) to NOT to do the second HTTP request (or, uh, 4th if you include https to http fallbacks on each hostname, ugh), rendering the webfinger subdomain very much not 1st tier and therefore unreliable. I already know it'll end up as a forgotten wart in the spec, like HTTP/1.1 trailers or pipelining. I mean seriously: the DNS, listening & routing aren't rocket science today and they weren't 10 years ago either. If you can't even get that right, what are the odds you can get webfinger right? This Thanksgiving I am thankful for Paul putting up with all of us. Happy turkeys, Brad On Wed, Nov 21, 2012 at 8:13 PM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > I just posted a new draft that takes into consideration the input I > received on -03 and adds the =E2=80=9Cwebfinger=E2=80=9D subdomain that w= as discussed on > the list this past week. Specifically, here=E2=80=99s what changed:**** > > **=C2=B7 **Mention in section 2 that WebFinger uses the =E2=80=9C= rel=E2=80=9D > attribute and provide a reference to the IANA registry for link relations= * > *** > > **=C2=B7 **Deleted the second paragraph from section 3 that expa= nds > on link relations**** > > **=C2=B7 **Changed the link relation value for =E2=80=9Cblog=E2= =80=9D to be just the > token =E2=80=9Cblog=E2=80=9D**** > > **=C2=B7 **Corrected a syntax error in the example in 4.1**** > > **=C2=B7 **Clarified in section 4.1 what is meant by a =E2=80=9Cv= alid alias=E2=80=9D*** > * > > **=C2=B7 **Introduced a new section 4.2 that shows an example for > OpenID Connect**** > > **=C2=B7 **Changed the rel types in 4.3 and 4.4 to be URI-based (= on > example.net)**** > > **=C2=B7 **Corrected syntax in 5.3 and added two clarifying sente= nces** > ** > > **=C2=B7 **Introduced a new section 5.5 that describes the =E2=80= =9Cwebfinger=E2=80=9D > subdomain**** > > **=C2=B7 **Changed the name of section 7**** > > **=C2=B7 **Added language to section 8 to support section 5.5**** > > **=C2=B7 **Added language to section 9 to support section 5.5**** > > **=C2=B7 **Spells out Mike=E2=80=99s name as he prefers it**** > > **=C2=B7 **Added a couple of informational references**** > > ** ** > > The new draft is here:**** > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04**** > > ** ** > > I think we=E2=80=99re getting closer, though I know the =E2=80=9Cwebfinge= r=E2=80=9D subdomain > might be a bit controversial. I=E2=80=99m on the fence on this one, myse= lf. I can > see the pros and cons of having it. I=E2=80=99d prefer to stay out of th= e debate, > though. I=E2=80=99ll put into the document whatever the group says to pu= t into the > documents :-) That said, I think Mike made a valid argument with respect > to the fact that some domain owners have no ability to do anything more > than insert an A record for a subdomain.**** > > ** ** > > I do want to highlight the fact that the current language says that if > there is any response from a web server at the host, that means the host > does have the capability of providing WF services and the =E2=80=9Cwebfin= ger=E2=80=9D > subdomain should not be consulted. Thus, the webfinger subdomain would > only be consulted if there is no web server running at the host at all. > It=E2=80=99s not a fallback for domain owners who have a web server, but = just > didn=E2=80=99t install a WF server. For that case, they should use 3xx r= edirection > for hosting the WF server elsewhere.**** > > ** ** > > Paul**** > > ** ** > --f46d04462f0ec3ef9a04cf0ddfbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
T= he new TOC doesn't even have a section 5.5. =C2=A0Is that how you hide = controversial stuff? =C2=A0:-)

FWIW, I'm strongly op= posed to the subdomain. =C2=A0It adds complexity. =C2=A0If you can't ge= t your load balancing & routing act together, you don't get to play= , sorry.

If it's easy for the small guys, and I've seen = it be easy for the medium guys, and multiple big guys have shown that it= 9;s possible, who's complaining? =C2=A0(rhetorical. I didn't see wh= en this first appeared, and don't really want to know)

I don't want=C2=A0incompetence=C2=A0and/or internal= politics unnecessarily complicating a spec that is supposed to be simple f= or clients.

If we all compromise, nobody wins. =C2= =A0Actually I'll go a step further and be the dick here and say absolut= ely not. =C2=A0I'll fight for implementations that I write (and those o= f others whom I can influence) to NOT to do the second HTTP request (or, uh= , 4th if you include https to http fallbacks on each hostname, ugh), render= ing the webfinger subdomain very much not 1st tier and therefore unreliable= . =C2=A0I already know it'll end up as a forgotten wart in the spec, li= ke HTTP/1.1 trailers or pipelining.

I mean seriously: the DNS, listening & routing aren= 't rocket science today and they weren't 10 years ago either. =C2= =A0If you can't even get that right, what are the odds you can get webf= inger right?

This Thanksgiving I am thankful for Paul putting up wit= h all of us.

Happy turkeys,
Brad


On We= d, Nov 21, 2012 at 8:13 PM, Paul E. Jones <paulej@packetizer.com&g= t; wrote:

Folks,

=C2=A0

I just posted a new draft that takes into considerat= ion the input I received on -03 and adds the =E2=80=9Cwebfinger=E2=80=9D su= bdomain that was discussed on the list this past week.=C2=A0 Specifically, = here=E2=80=99s what changed:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Mention in section 2 that WebFinge= r uses the =E2=80=9Crel=E2=80=9D attribute and provide a reference to the I= ANA registry for link relations

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Deleted the second paragraph from= =C2=A0 section 3 that expands on link relations

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Changed the link relation value fo= r =E2=80=9Cblog=E2=80=9D to be just the token =E2=80=9Cblog=E2=80=9D=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Corrected a syntax error in the ex= ample in 4.1

= =C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Clar= ified in section 4.1 what is meant by a =E2=80=9Cvalid alias=E2=80=9D

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Introduced a new section 4.2 that = shows an example for OpenID Connect

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Changed the rel types in 4.3 and 4= .4 to be URI-based (on exa= mple.net)

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Corrected syntax in 5.3 and added = two clarifying sentences

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= u>Introduced a new section 5.5 that describes the =E2=80=9Cwebfinger=E2= =80=9D subdomain

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Changed the name of section 7

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Added language to sect= ion 8 to support section 5.5

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Added language to section 9 to sup= port section 5.5

=C2=B7=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S= pells out Mike=E2=80=99s name as he prefers it

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Added a couple of informational re= ferences

=C2=A0

The new draft is here:

http://tools.ietf.org/html= /draft-ietf-appsawg-webfinger-04

=C2=A0

I thi= nk we=E2=80=99re getting closer, though I know the =E2=80=9Cwebfinger=E2=80= =9D subdomain might be a bit controversial.=C2=A0 I=E2=80=99m on the fence = on this one, myself.=C2=A0 I can see the pros and cons of having it.=C2=A0 = I=E2=80=99d prefer to stay out of the debate, though.=C2=A0 I=E2=80=99ll pu= t into the document whatever the group says to put into the documents :-)= =C2=A0 That said, I think Mike made a valid argument with respect to the fa= ct that some domain owners have no ability to do anything more than insert = an A record for a subdomain.

=C2=A0

I do = want to highlight the fact that the current language says that if there is = any response from a web server at the host, that means the host does have t= he capability of providing WF services and the =E2=80=9Cwebfinger=E2=80=9D = subdomain should not be consulted.=C2=A0 Thus, the webfinger subdomain woul= d only be consulted if there is no web server running at the host at all.= =C2=A0 It=E2=80=99s not a fallback for domain owners who have a web server,= but just didn=E2=80=99t install a WF server.=C2=A0 For that case, they sho= uld use 3xx redirection for hosting the WF server elsewhere.

=C2=A0

Paul

=C2=A0

=

--f46d04462f0ec3ef9a04cf0ddfbe-- From cweiske@cweiske.de Wed Nov 21 23:39: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 0A56A21F872D for ; Wed, 21 Nov 2012 23:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 CKlXXvpsVptQ for ; Wed, 21 Nov 2012 23:39:38 -0800 (PST) Received: from mail.cweiske.de (mail.cweiske.de [IPv6:2a01:488:66:1000:53a9:7c6:0:1]) by ietfa.amsl.com (Postfix) with ESMTP id 644EE21F850E for ; Wed, 21 Nov 2012 23:39:38 -0800 (PST) Received: by mail.cweiske.de (Postfix, from userid 65534) id C454C119104CB; Thu, 22 Nov 2012 08:39:36 +0100 (CET) Received: from cyberdyne (proxy.lpz.netresearch.de [85.232.25.153]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.cweiske.de (Postfix) with ESMTPSA id 9B57D119104C6; Thu, 22 Nov 2012 08:39:34 +0100 (CET) Date: Thu, 22 Nov 2012 08:39:32 +0100 From: Christian Weiske To: webfinger@googlegroups.com Message-ID: <20121122083932.5386bb5b@cyberdyne> In-Reply-To: References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 22 Nov 2012 10:50:50 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 22 Nov 2012 07:39:39 -0000 Hello Paul and Brad, > > **=C2=B7 **Introduced a new section 5.5 that describes the > > =E2=80=9Cwebfinger=E2=80=9D subdomain**** > FWIW, I'm strongly opposed to the subdomain. It adds complexity. If > you can't get your load balancing & routing act together, you don't > get to play, sorry. I am also opposed to the subdomain, although I don't know the arguments for it. It makes the spec again more complex. The reasons given in draft 04 are bogus; if there is no web server running on that domain (and shall not be), the http traffic can be routed to another server via iptables or whatnot. Load balancers exist for ages, so that's no reason either. Could someone point me to the messages that discussed this? I didn't find any in webfinger@googlegroups.com nor apps-discuss@ietf.org about that. --=20 Regards/Mit freundlichen Gr=C3=BC=C3=9Fen Christian Weiske -=3D Geeking around in the name of science since 1982 =3D- From masinter@adobe.com Thu Nov 22 18:17: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 2B17221F8488 for ; Thu, 22 Nov 2012 18:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.138 X-Spam-Level: X-Spam-Status: No, score=-104.138 tagged_above=-999 required=5 tests=[AWL=-2.961, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, 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 g6WEx4QX4DpV for ; Thu, 22 Nov 2012 18:17:00 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0055F21F847F for ; Thu, 22 Nov 2012 18:16:59 -0800 (PST) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUK7clHDAylsXa1E6f2g1WdrwTl00AkxQ@postini.com; Thu, 22 Nov 2012 18:17:00 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qAN2E11v029029; Thu, 22 Nov 2012 18:14:01 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qAN2GoNc016013; Thu, 22 Nov 2012 18:16:50 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Thu, 22 Nov 2012 18:16:50 -0800 From: Larry Masinter To: Goix Laurent Walter , "Paul E. Jones" , "'James M Snell'" , "'Dick Hardt'" Date: Thu, 22 Nov 2012 18:16:50 -0800 Thread-Topic: [apps-discuss] Link rels Thread-Index: AQI/YWaFkAYvx4DQsUUjuXKAy/yifQJJ+dZ9Ajy5+20BY9p1VAJ+l/RsAmfvVTQB2jbl4gLLVYb6lpM/odCAAI7WQIADi3yA Message-ID: References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> <025e01cdc6db$faf26720$f0d73560$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_C68CB012D9182D408CED7B884F441D4D1E37027B6Dnambxv01acorp_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "webfinger@googlegroups.com" , 'IETF Apps Discuss' Subject: Re: [apps-discuss] Link rels 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, 23 Nov 2012 02:17:04 -0000 --_004_C68CB012D9182D408CED7B884F441D4D1E37027B6Dnambxv01acorp_ Content-Type: multipart/alternative; boundary="_000_C68CB012D9182D408CED7B884F441D4D1E37027B6Dnambxv01acorp_" --_000_C68CB012D9182D408CED7B884F441D4D1E37027B6Dnambxv01acorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TmVnb3RpYXRpbmcgY29udHJvbGxlZCB2b2NhYnVsYXJpZXMgaXMgYSBkaWZmaWN1bHQgY291cnNl LiDigJxuYXJyb3figJ0sIOKAnHVuYW1iaWd1b3Vz4oCdLCDigJxjbGVhciBzZW1hbnRpY3PigJ0s IOKAnGd1YXJhbnRlZSBpbnRlcm9w4oCdIGFyZSBncmVhdCBhc3BpcmF0aW9ucywgYnV0IHVsdGlt YXRlbHkgaW1wb3NzaWJsZS4gQW1iaWd1aXR5IGlzIGludHJpbnNpYy4NCg0K4oCcbWluaW1pemUg YW1iaWd1aXR54oCdLCDigJx3ZWxsLWRvY3VtZW50ZWQgc2VtYW50aWNz4oCdIGFuZCDigJxwcm9t b3RlIGludGVyb3BlcmFiaWxpdHnigJ0gd291bGQgYmUgbW9yZSByZWFsaXN0aWMuDQoNCkFwcGxp Y2F0aW9ucyB3aWxsIHVzZSBsaW5rIHJlbGF0aW9ucywgYW5kIHNvbWUgYXBwbGljYXRpb25zIHdp bGwgYXBwbHkgc3BlY2lhbGl6ZWQgbWVhbmluZyB0byBhIGxpbmsgcmVsYXRpb24gdGhhdCBvdGhl ciBhcHBsaWNhdGlvbnMgd2lsbCBub3QuDQoNCuKAnFRoZSBsaW5rIHJlbGF0aW9uIHJlZ2lzdHJ5 IHNob3VsZCBiZSBtYWludGFpbmVkLCBzdWNoIHRoYXQgZG9jdW1lbnRhdGlvbiBmb3IgYXBwbGlj YXRpb25zIHRoYXQgcmVseSBvbiBwYXJ0aWN1bGFyIGxpbmsgcmVsYXRpb25zIGFyZSBlYXN5IHRv IGZpbmQgZnJvbSB0aGUgbGluayByZWxhdGlvbiByZWdpc3RyeeKAnS4NCg0KDQoNCkZyb206IGFw cHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHb2l4IExhdXJlbnQgV2FsdGVyDQpTZW50OiBUdWVzZGF5 LCBOb3ZlbWJlciAyMCwgMjAxMiA1OjM5IEFNDQpUbzogUGF1bCBFLiBKb25lczsgJ0phbWVzIE0g U25lbGwnOyAnRGljayBIYXJkdCcNCkNjOiB3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbTsgJ0lF VEYgQXBwcyBEaXNjdXNzJw0KU3ViamVjdDogW2FwcHMtZGlzY3Vzc10gTGluayByZWxzDQoNCisx IGZvciBuYXJyb3cgJiB1bmFtYmlndW91cyByZWxzIHdpdGggY2xlYXIgc2VtYW50aWNzIHRoYXQg Z3VhcmFudGVlIGludGVyb3AgKGJ0dyBJIHRoaW5rIHdlIGFyZSBkZXJpdmluZyBmcm9tIHRoZSBj b3JlIHdlYmZpbmdlciBkaXNjdXNzaW9uIGhlcmUgc28gSSBjaGFuZ2VkIHRoZSBzdWJqZWN0KQ0K DQpUaGUgbGluayByZWxzIHByb3Bvc2VkIGJ5IGphbWVzIGluIHRoZSBkcmFmdCBhcmUgbWVhbmlu Z2Z1bCAoSSBkbyBoYXZlIHNvbWUgZG91YnRzIG9uIGFib3V0IHZzIHJlbGF0ZWQsIHdoaWNoIGlz IGFscmVhZHkgcmVnaXN0ZXJlZCkuIOKAnGF2YXRhcuKAnSBjb3VsZCBiZSBhZGRlZCB0aGVyZSBp biBjYXNlIHRoZSBkcmFmdCBjYW4gc2VydmUgYXMgYmFzaXMgZm9yIHRoaXMgYWN0aXZpdHkuDQoN CkZvciDigJx1cGRhdGVzLWZyb23igJ0gaW5kZWVkIHRoZXNlIGFyZSBzcGVjaWZpYyB0byBhY3Rp dml0eSBzdHJlYW1zIHJlcHJlc2VudGVkIGluIGF0b20sIGFuZCBzaG91bGQgbm90IHZhcnkgdGhl aXIgbWVhbmluZyAoYmVzaWRlcyBhIHR5cGUgcGFyYW1ldGVyIHdoaWNoIGNvdWxkIGFsbG93IGZv ciBqc29uIGFzIHdlbGwpOiBmb3IgdGhpcyByZWFzb24gdGhlIHJlZmVyZW5jZSB0byBhY3Rpdml0 eXN0cmVhbXMgY291bGQgYmUgc3Ryb25nZXIgaW1vLiBtYXliZSDigJxhY3Rpdml0aWVz4oCdPw0K DQp3YWx0ZXINCg0KRGE6IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphcHBz LWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0Bp ZXRmLm9yZ10gUGVyIGNvbnRvIGRpIFBhdWwgRS4gSm9uZXMNCkludmlhdG86IG1hcnRlZMOsIDIw IG5vdmVtYnJlIDIwMTIgNi4wMQ0KQTogJ0phbWVzIE0gU25lbGwnOyAnRGljayBIYXJkdCcNCkNj OiB3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbTxtYWlsdG86d2ViZmluZ2VyQGdvb2dsZWdyb3Vw cy5jb20+OyAnSUVURiBBcHBzIERpc2N1c3MnDQpPZ2dldHRvOiBSZTogW2FwcHMtZGlzY3Vzc10g TmV3IGRyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXItMDMudHh0DQoNCkphbWVzLA0KDQpJIHRo aW5rIHRoZSDigJx1cGRhdGVzLWZyb23igJ0gd2FzIGludGVuZGVkIHRvIGJlIGFuIEFUT00gZmVl ZCwgdGhvdWdoIEkgbWlnaHQgYmUgd3JvbmcuICBJbiB5b3VyIGV4YW1wbGUsIHlvdSBzaG93IGEg YmxvZy4gIEJ1dCwgYXQgdGhlIHNhbWUgdGltZSB3ZSB3YW50IHRvIGRlZmluZSDigJxibG9n4oCd IGFzIGl0cyBvd24gcmVsLg0KDQpJIHRoaW5rIGl04oCZcyBpbXBvcnRhbnQgdGhhdCB3ZSBoYXZl IGEgdmVyeSBuYXJyb3cgc2NvcGUgZm9yIGFueSByZWwuICBJIGRvbuKAmXQgY2FyZSB3aGF0IHRo ZSB2YWx1ZXMgYXJlLCBidXQgd2UgbmVlZCB0byBlbnN1cmUgdGhlcmUgaXMgbm8gYW1iaWd1aXR5 IGluIHdoYXQgYSBnaXZlbiB0b2tlbiBtZWFucy4NCg0KUGF1bA0KDQpGcm9tOiBKYW1lcyBNIFNu ZWxsIFttYWlsdG86amFzbmVsbEBnbWFpbC5jb21dDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDE5 LCAyMDEyIDEyOjM2IFBNDQpUbzogRGljayBIYXJkdA0KQ2M6IFBhdWwgRS4gSm9uZXM7IHdlYmZp bmdlckBnb29nbGVncm91cHMuY29tPG1haWx0bzp3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbT47 IElFVEYgQXBwcyBEaXNjdXNzDQpTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gTmV3IGRyYWZ0 LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXItMDMudHh0DQoNCkp1c3QgYSBxdWljayBub3RlIG9uIHRo aXMuLi4gSSBhbHJlYWR5IGhhdmUgdGhlIGV4aXN0aW5nICJBZGRpdGlvbmFsIExpbmsgUmVsYXRp b25zIiBkcmFmdCBbMV0gaW4gcHJvZ3Jlc3MgKGN1cnJlbnRseSBzdWJtaXR0ZWQgYXMgYW4gaW5k ZXBlbmRlbnQgc3VibWlzc2lvbikgdGhhdCByZWdpc3RlcnMgbGluayByZWxhdGlvbnMgc3VjaCBh cyAiYWJvdXQiLCAidHlwZSIsICJ0ZXJtcy1vZi1zZXJ2aWNlIiwgInByaXZhY3ktcG9saWN5IiBh bmQgInByZXZpZXciLiBJdCB3b3VsZCBiZSBwb3NzaWJsZSB0byBwdWxsIHRoaXMgZHJhZnQgYmFj ayBhbmQgYWRkIGEgZmV3IG1vcmUgbGluayByZWxhdGlvbiB0eXBlcyB0byBpdCBpZiBuZWNlc3Nh cnkuIFdlIHdvdWxkIGp1c3QgbmVlZCB0byBpZGVudGlmeSB0aGUgc2V0IG9mIG5ldyBsaW5rIHJl bHMgYW5kIEkgY291bGQgdmVyeSBlYXNpbHkgZHJvcCB0aGVtIGluIG9yIHdyaXRlIHVwIGEgcXVp Y2sgc2Vjb25kIGRvY3VtZW50IGJhc2VkIG9uIHRoZSBzYW1lIHNpbXBsZSB0ZW1wbGF0ZS4NCg0K WzFdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNuZWxsLWFkZGl0aW9uYWwtbGlu ay1yZWxhdGlvbnMtMDYNCg0KVGhhdCBzYWlkLCB0aGUgImFib3V0IiBsaW5rIHJlbGF0aW9uIGNh biBiZSB1c2VkIHRvIGxpbmsgdG8gYm90aCBwcm9maWxlLXBhZ2UgYW5kIHZjYXJkIHR5cGUgcmVz b3VyY2VzLi4uIGRpZmZlcmVudGlhdGVkLCBvZiBjb3Vyc2UsIGJ5IHRoZSBtZWRpYSB0eXBlIG9m IHRoZSBsaW5rZWQgcmVzb3VyY2UuDQoNCkFsc28uLi4gV2UgbmVlZCB0byBiZSBjYXJlZnVsIG5v dCB0byBnZXQgdG9vIHNwZWNpZmljIHdpdGggbGluayByZWxhdGlvbiBsYWJlbHMuIFRoZSByZWwg dmFsdWVzIHRoZW1zZWx2ZXMgYXJlIGludGVuZGVkIHRvIHN0YXRlIHRoZSBuYXR1cmUgb2YgdGhl IHJlbGF0aW9uc2hpcCBhbmQgbm90IHRoZSB0eXBlIG9mIHJlc291cmNlIGl0IGlzLiBIYXZpbmcg c29tZXRoaW5nIGxpa2UgeyJyZWwiOiJ1cGRhdGVzIiwiaHJlZiI6Imh0dHA6Ly9leGFtcGxlLm9y Zy9teS9ibG9nIiwidHlwZSI6InRleHQvaHRtbCJ9IHNob3VsZCBiZSBnZW5lcmFsbHkgcHJlZmVy YWJsZSBvdmVyIHNvbWV0aGluZyBsaWtlIHsicmVsIjoiYmxvZyIsImhyZWYiOiJodHRwOi8vZXhh bXBsZS5vcmcvbXkvYmxvZyJ9Lg0KDQotIEphbWVzDQoNCk9uIFN1biwgTm92IDE4LCAyMDEyIGF0 IDI6MjIgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhh cmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KSGkgUGF1bA0KDQpJIGFncmVlIGl0IHNob3VsZCBiZSBz ZXBhcmF0ZSBkcmFmdHMuIEknZCBiZSB3aWxsaW5nIHRvIGVkaXQgaWYgdGhlcmUgaXMgaW50ZXJl c3QuIE15IGludGVyZXN0IGluIFdlYkZpbmdlciBpcyBhcyBhIGNvbnN1bWVyIG11Y2ggbW9yZSB0 aGFuIGEgcHVibGlzaGVyIC0gc28gSSBkb24ndCBmZWVsIEkgYW0gYSBkb21haW4gZXhwZXJ0Lg0K DQpJcyBpdCBwb3NzaWJsZSB0byBoYXZlIG1lYW5pbmdmdWwgZXhhbXBsZXMgd2l0aCBleGlzdGlu ZyAicmVsIiB2YWx1ZXMsIG9yIGRvIHdlIG5lZWQgdG8gaGF2ZSBzb21lIG90aGVycyBkZWZpbmVk IHRvIGhhdmUgbWVhbmluZ2Z1bCBleGFtcGxlcz8NCg0KLS0gRGljaw0KDQpPbiBOb3YgMTgsIDIw MTIsIGF0IDI6MDIgUE0sICJQYXVsIEUuIEpvbmVzIiA8cGF1bGVqQHBhY2tldGl6ZXIuY29tPG1h aWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20+PiB3cm90ZToNCg0KRGljaywNCg0KVGhlc2Ugc2hv dWxkIGJlIHNlcGFyYXRlIGRyYWZ0cy4gIEkgYWdyZWUg4oCcYmxvZ+KAnSBpcyBnb29kLCBidXQg dGhlcmUgYXJlIHN1cmVseSBtb3JlLiAgQSBsb3Qgb2YgZ29vZCBvbmVzIGFyZSBkZWZpbmVkIHVu ZGVyIHdlYmZpbmdlci5uZXQ8aHR0cDovL3dlYmZpbmdlci5uZXQ+LCB0b28uDQoNCkJ1dCBJIHdv dWxkIHJlYWxseSBwcmVmZXIgdG8gbm90IHNsb3cgZG93biB0aGlzIGRyYWZ0IHdpdGggYWRkaXRp b24gb2YgbGluayByZWxhdGlvbiB2YWx1ZXMuICBJZiBzb21lYm9keSAoeW91Pykgd2FudHMgdG8g c3RhcnQgYSBXZWJGaW5nZXIgTGluayBSZWxhdGlvbnMgZG9jdW1lbnQsIEkgdGhpbmsgaXQgd291 bGQgYmUgdGltZWx5Lg0KDQpQYXVsDQoNCg0KUEVKOiBUaGV5IGNvdWxkLiAgVGhlIGNoYWxsZW5n ZSBpcyB0aGF0IHdlIGhhdmUgbm8gb3RoZXIgVVJJIHR5cGUgZGVmaW5lZCBmb3IgdGhpcyBwdXJw b3NlLiAgRm9yIHRoZSBleGFtcGxlcywgd2UgaGF2ZSBhIGNoaWNrZW4gYW5kIGVnZyBwcm9ibGVt Lg0KDQpMZXQncyBkZWZpbmUgc29tZSB0aGVuISBUaGlzIGlzIHRoZSBvbmUgYXJlYSB0aGF0IGlz IHZhZ3VlIGFuZCBJTUhPIGlzIGEgYmFycmllciB0byBhZG9wdGlvbi4gV2hhdCBzaG91bGQgdGhl ICJyZWwiIHZhbHVlcyBiZSBmb3IgaXRlbXMgdGhhdCBJIHdhbnQgdG8gcHVibGlzaD8gSWYgd2Ug ZG9uJ3Qgc3BlYyB0aGUgY29tbW9uIG9uZXMsIHdlIHdpbGwgZW5kIHVwIHdpdGggc2V2ZXJhbCBk aWZmZXJlbnQgaWRlbnRpZmllcnMgZm9yIHRoZSBzYW1lIHRoaW5nLiBDaGFsbGVuZ2Ugb2YgY291 cnNlIGlzIHRoYXQgZ2V0dGluZyBhZ3JlZW1lbnQgb24gc2NoZW1hIGlzIGFsd2F5cyBmdW4sIGJ1 dCBiZXR0ZXIgdG8gaGF2ZSBzb21lIHRoYXQgd2lsbCBiZSB1c2VkIHRoYXQgYXJlIG5vdCBhbHJl YWR5IGRlZmluZWQuDQoNCk5lZWQgdG8gYWRkIGFuIElBTkEgc2VjdGlvbiBmb3IgdGhhdCBvZiBj b3Vyc2UuDQoNCiJibG9nIiBpcyBhIGdvb2Qgb25lIDopDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QN CmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCg0KUXVlc3Rv IG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1l bnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lh c2kgYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZv cm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNl dnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdh dGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92 dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQoNClRoaXMgZS1tYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWlu YXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRo b3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRl ciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQpbY2lkOmltYWdlMDAxLmdpZkAwMUNEQzhBNi4x REU5MkY0MF1SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ug bm9uIMOoIG5lY2Vzc2FyaW8uDQoNCg0K --_000_C68CB012D9182D408CED7B884F441D4D1E37027B6Dnambxv01acorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0 IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIjsNCglw YW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRp diBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+TmVnb3RpYXRpbmcgY29udHJvbGxlZCB2b2NhYnVsYXJpZXMgaXMgYSBkaWZmaWN1bHQg Y291cnNlLiDigJxuYXJyb3figJ0sIOKAnHVuYW1iaWd1b3Vz4oCdLCDigJxjbGVhciBzZW1hbnRp Y3PigJ0sIOKAnGd1YXJhbnRlZSBpbnRlcm9w4oCdIGFyZSBncmVhdCBhc3BpcmF0aW9ucywgYnV0 IHVsdGltYXRlbHkgaW1wb3NzaWJsZS4gQW1iaWd1aXR5IGlzIGludHJpbnNpYy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPuKAnG1pbmltaXplIGFtYmlndWl0eeKAnSwg4oCcd2VsbC1kb2N1bWVudGVkIHNl bWFudGljc+KAnSBhbmQg4oCccHJvbW90ZSBpbnRlcm9wZXJhYmlsaXR54oCdIHdvdWxkIGJlIG1v cmUgcmVhbGlzdGljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QXBwbGljYXRpb25zIHdpbGwgdXNlIGxp bmsgcmVsYXRpb25zLCBhbmQgc29tZSBhcHBsaWNhdGlvbnMgd2lsbCBhcHBseSBzcGVjaWFsaXpl ZCBtZWFuaW5nIHRvIGEgbGluayByZWxhdGlvbiB0aGF0IG90aGVyIGFwcGxpY2F0aW9ucyB3aWxs IG5vdC4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4g4oCcVGhlIGxpbmsgcmVsYXRpb24gcmVnaXN0cnkg c2hvdWxkIGJlIG1haW50YWluZWQsIHN1Y2ggdGhhdCBkb2N1bWVudGF0aW9uIGZvciBhcHBsaWNh dGlvbnMgdGhhdCByZWx5IG9uIHBhcnRpY3VsYXIgbGluayByZWxhdGlvbnMgYXJlIGVhc3kgdG8g ZmluZCBmcm9tIHRoZSBsaW5rIHJlbGF0aW9uIHJlZ2lzdHJ54oCdLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1h bD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBhcHBzLWRpc2N1c3MtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBC ZWhhbGYgT2YgPC9iPkdvaXggTGF1cmVudCBXYWx0ZXI8YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXks IE5vdmVtYmVyIDIwLCAyMDEyIDU6MzkgQU08YnI+PGI+VG86PC9iPiBQYXVsIEUuIEpvbmVzOyAn SmFtZXMgTSBTbmVsbCc7ICdEaWNrIEhhcmR0Jzxicj48Yj5DYzo8L2I+IHdlYmZpbmdlckBnb29n bGVncm91cHMuY29tOyAnSUVURiBBcHBzIERpc2N1c3MnPGJyPjxiPlN1YmplY3Q6PC9iPiBbYXBw cy1kaXNjdXNzXSBMaW5rIHJlbHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPisxIGZvciBuYXJyb3cgJmFtcDsgdW5hbWJpZ3VvdXMgcmVs cyB3aXRoIGNsZWFyIHNlbWFudGljcyB0aGF0IGd1YXJhbnRlZSBpbnRlcm9wIChidHcgSSB0aGlu ayB3ZSBhcmUgZGVyaXZpbmcgZnJvbSB0aGUgY29yZSB3ZWJmaW5nZXIgZGlzY3Vzc2lvbiBoZXJl IHNvIEkgY2hhbmdlZCB0aGUgc3ViamVjdCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBsaW5rIHJl bHMgcHJvcG9zZWQgYnkgamFtZXMgaW4gdGhlIGRyYWZ0IGFyZSBtZWFuaW5nZnVsIChJIGRvIGhh dmUgc29tZSBkb3VidHMgb24gYWJvdXQgdnMgcmVsYXRlZCwgd2hpY2ggaXMgYWxyZWFkeSByZWdp c3RlcmVkKS4g4oCcYXZhdGFy4oCdIGNvdWxkIGJlIGFkZGVkIHRoZXJlIGluIGNhc2UgdGhlIGRy YWZ0IGNhbiBzZXJ2ZSBhcyBiYXNpcyBmb3IgdGhpcyBhY3Rpdml0eS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkZvciDigJx1cGRhdGVzLWZyb23igJ0gaW5kZWVkIHRoZXNlIGFyZSBzcGVjaWZpYyB0byBh Y3Rpdml0eSBzdHJlYW1zIHJlcHJlc2VudGVkIGluIGF0b20sIGFuZCBzaG91bGQgbm90IHZhcnkg dGhlaXIgbWVhbmluZyAoYmVzaWRlcyBhIHR5cGUgcGFyYW1ldGVyIHdoaWNoIGNvdWxkIGFsbG93 IGZvciBqc29uIGFzIHdlbGwpOiBmb3IgdGhpcyByZWFzb24gdGhlIHJlZmVyZW5jZSB0byBhY3Rp dml0eXN0cmVhbXMgY291bGQgYmUgc3Ryb25nZXIgaW1vLiBtYXliZSDigJxhY3Rpdml0aWVz4oCd PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+d2FsdGVyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBs YW5nPUlUIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSIsInNh bnMtc2VyaWYiJz5EYTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9SVQgc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIiwic2Fucy1zZXJpZiInPiA8YSBocmVmPSJtYWls dG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmciPmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGll dGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3Jn Ij5tYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5QZXIgY29udG8g ZGkgPC9iPlBhdWwgRS4gSm9uZXM8YnI+PGI+SW52aWF0bzo8L2I+IG1hcnRlZMOsIDIwIG5vdmVt YnJlIDIwMTIgNi4wMTxicj48Yj5BOjwvYj4gJ0phbWVzIE0gU25lbGwnOyAnRGljayBIYXJkdCc8 YnI+PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86d2ViZmluZ2VyQGdvb2dsZWdyb3Vwcy5jb20i PndlYmZpbmdlckBnb29nbGVncm91cHMuY29tPC9hPjsgJ0lFVEYgQXBwcyBEaXNjdXNzJzxicj48 Yj5PZ2dldHRvOjwvYj4gUmU6IFthcHBzLWRpc2N1c3NdIE5ldyBkcmFmdC1pZXRmLWFwcHNhd2ct d2ViZmluZ2VyLTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1GUj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFtZXMsPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5JIHRoaW5rIHRoZSDigJx1cGRhdGVzLWZyb23igJ0gd2FzIGludGVuZGVkIHRvIGJl IGFuIEFUT00gZmVlZCwgdGhvdWdoIEkgbWlnaHQgYmUgd3JvbmcuJm5ic3A7IEluIHlvdXIgZXhh bXBsZSwgeW91IHNob3cgYSBibG9nLiZuYnNwOyBCdXQsIGF0IHRoZSBzYW1lIHRpbWUgd2Ugd2Fu dCB0byBkZWZpbmUg4oCcYmxvZ+KAnSBhcyBpdHMgb3duIHJlbC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PkkgdGhpbmsgaXTigJlzIGltcG9ydGFudCB0aGF0IHdlIGhhdmUgYSB2ZXJ5IG5hcnJvdyBzY29w ZSBmb3IgYW55IHJlbC4mbmJzcDsgSSBkb27igJl0IGNhcmUgd2hhdCB0aGUgdmFsdWVzIGFyZSwg YnV0IHdlIG5lZWQgdG8gZW5zdXJlIHRoZXJlIGlzIG5vIGFtYmlndWl0eSBpbiB3aGF0IGEgZ2l2 ZW4gdG9rZW4gbWVhbnMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QYXVsPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPiBKYW1lcyBNIFNuZWxsIFs8YSBocmVmPSJtYWlsdG86amFzbmVsbEBnbWFpbC5j b20iPm1haWx0bzpqYXNuZWxsQGdtYWlsLmNvbTwvYT5dIDxicj48Yj5TZW50OjwvYj4gTW9uZGF5 LCBOb3ZlbWJlciAxOSwgMjAxMiAxMjozNiBQTTxicj48Yj5Ubzo8L2I+IERpY2sgSGFyZHQ8YnI+ PGI+Q2M6PC9iPiBQYXVsIEUuIEpvbmVzOyA8YSBocmVmPSJtYWlsdG86d2ViZmluZ2VyQGdvb2ds ZWdyb3Vwcy5jb20iPndlYmZpbmdlckBnb29nbGVncm91cHMuY29tPC9hPjsgSUVURiBBcHBzIERp c2N1c3M8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbYXBwcy1kaXNjdXNzXSBOZXcgZHJhZnQtaWV0 Zi1hcHBzYXdnLXdlYmZpbmdlci0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+SnVzdCBhIHF1aWNr IG5vdGUgb24gdGhpcy4uLiBJIGFscmVhZHkgaGF2ZSB0aGUgZXhpc3RpbmcgJnF1b3Q7QWRkaXRp b25hbCBMaW5rIFJlbGF0aW9ucyZxdW90OyBkcmFmdCBbMV0gaW4gcHJvZ3Jlc3MgKGN1cnJlbnRs eSBzdWJtaXR0ZWQgYXMgYW4gaW5kZXBlbmRlbnQgc3VibWlzc2lvbikgdGhhdCByZWdpc3RlcnMg bGluayByZWxhdGlvbnMgc3VjaCBhcyAmcXVvdDthYm91dCZxdW90OywgJnF1b3Q7dHlwZSZxdW90 OywgJnF1b3Q7dGVybXMtb2Ytc2VydmljZSZxdW90OywgJnF1b3Q7cHJpdmFjeS1wb2xpY3kmcXVv dDsgYW5kICZxdW90O3ByZXZpZXcmcXVvdDsuIEl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIHB1bGwg dGhpcyBkcmFmdCBiYWNrIGFuZCBhZGQgYSBmZXcgbW9yZSBsaW5rIHJlbGF0aW9uIHR5cGVzIHRv IGl0IGlmIG5lY2Vzc2FyeS4gV2Ugd291bGQganVzdCBuZWVkIHRvIGlkZW50aWZ5IHRoZSBzZXQg b2YgbmV3IGxpbmsgcmVscyBhbmQgSSBjb3VsZCB2ZXJ5IGVhc2lseSBkcm9wIHRoZW0gaW4gb3Ig d3JpdGUgdXAgYSBxdWljayBzZWNvbmQgZG9jdW1lbnQgYmFzZWQgb24gdGhlIHNhbWUgc2ltcGxl IHRlbXBsYXRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc25lbGwtYWRkaXRpb25hbC1saW5rLXJlbGF0aW9u cy0wNiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc25lbGwtYWRkaXRpb25hbC1s aW5rLXJlbGF0aW9ucy0wNjwvYT48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlRoYXQgc2Fp ZCwgdGhlICZxdW90O2Fib3V0JnF1b3Q7IGxpbmsgcmVsYXRpb24gY2FuIGJlIHVzZWQgdG8gbGlu ayB0byBib3RoIHByb2ZpbGUtcGFnZSBhbmQgdmNhcmQgdHlwZSByZXNvdXJjZXMuLi4gZGlmZmVy ZW50aWF0ZWQsIG9mIGNvdXJzZSwgYnkgdGhlIG1lZGlhIHR5cGUgb2YgdGhlIGxpbmtlZCByZXNv dXJjZS4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkFsc28uLi4gV2UgbmVlZCB0 byBiZSBjYXJlZnVsIG5vdCB0byBnZXQgdG9vIHNwZWNpZmljIHdpdGggbGluayByZWxhdGlvbiBs YWJlbHMuIFRoZSByZWwgdmFsdWVzIHRoZW1zZWx2ZXMgYXJlIGludGVuZGVkIHRvIHN0YXRlIHRo ZSBuYXR1cmUgb2YgdGhlIHJlbGF0aW9uc2hpcCBhbmQgbm90IHRoZSB0eXBlIG9mIHJlc291cmNl IGl0IGlzLiBIYXZpbmcgc29tZXRoaW5nIGxpa2UgeyZxdW90O3JlbCZxdW90OzomcXVvdDt1cGRh dGVzJnF1b3Q7LCZxdW90O2hyZWYmcXVvdDs6JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUu b3JnL215L2Jsb2ciPmh0dHA6Ly9leGFtcGxlLm9yZy9teS9ibG9nPC9hPiZxdW90OywmcXVvdDt0 eXBlJnF1b3Q7OiZxdW90O3RleHQvaHRtbCZxdW90O30gc2hvdWxkIGJlIGdlbmVyYWxseSBwcmVm ZXJhYmxlIG92ZXIgc29tZXRoaW5nIGxpa2UmbmJzcDt7JnF1b3Q7cmVsJnF1b3Q7OiZxdW90O2Js b2cmcXVvdDssJnF1b3Q7aHJlZiZxdW90OzomcXVvdDs8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5v cmcvbXkvYmxvZyI+aHR0cDovL2V4YW1wbGUub3JnL215L2Jsb2c8L2E+JnF1b3Q7fS4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LSBKYW1lczxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90 dG9tOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ T24gU3VuLCBOb3YgMTgsIDIwMTIgYXQgMjoyMiBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5IaSBQYXVsPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBhZ3JlZSBpdCBz aG91bGQgYmUgc2VwYXJhdGUgZHJhZnRzLiBJJ2QgYmUgd2lsbGluZyB0byBlZGl0IGlmIHRoZXJl IGlzIGludGVyZXN0LiBNeSBpbnRlcmVzdCBpbiBXZWJGaW5nZXIgaXMgYXMgYSBjb25zdW1lciBt dWNoIG1vcmUgdGhhbiBhIHB1Ymxpc2hlciAtIHNvIEkgZG9uJ3QgZmVlbCBJIGFtIGEgZG9tYWlu IGV4cGVydC48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JcyBpdCBwb3Nz aWJsZSB0byBoYXZlIG1lYW5pbmdmdWwgZXhhbXBsZXMgd2l0aCBleGlzdGluZyAmcXVvdDtyZWwm cXVvdDsgdmFsdWVzLCBvciBkbyB3ZSBuZWVkIHRvIGhhdmUgc29tZSBvdGhlcnMgZGVmaW5lZCB0 byBoYXZlIG1lYW5pbmdmdWwgZXhhbXBsZXM/PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiM4ODg4ODgnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6Izg4ODg4OCc+LS0gRGljazxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBOb3YgMTgsIDIwMTIsIGF0IDI6MDIgUE0sICZxdW90O1Bh dWwgRS4gSm9uZXMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVsZWpAcGFja2V0aXplci5j b20iIHRhcmdldD0iX2JsYW5rIj5wYXVsZWpAcGFja2V0aXplci5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5EaWNrLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZXNlIHNob3VsZCBiZSBzZXBhcmF0ZSBkcmFmdHMuJm5i c3A7IEkgYWdyZWUg4oCcYmxvZ+KAnSBpcyBnb29kLCBidXQgdGhlcmUgYXJlIHN1cmVseSBtb3Jl LiZuYnNwOyBBIGxvdCBvZiBnb29kIG9uZXMgYXJlIGRlZmluZWQgdW5kZXImbmJzcDs8YSBocmVm PSJodHRwOi8vd2ViZmluZ2VyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSdjb2xv cjpwdXJwbGUnPndlYmZpbmdlci5uZXQ8L3NwYW4+PC9hPiwgdG9vLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkJ1dCBJIHdvdWxkIHJlYWxseSBwcmVmZXIgdG8gbm90 IHNsb3cgZG93biB0aGlzIGRyYWZ0IHdpdGggYWRkaXRpb24gb2YgbGluayByZWxhdGlvbiB2YWx1 ZXMuJm5ic3A7IElmIHNvbWVib2R5ICh5b3U/KSB3YW50cyB0byBzdGFydCBhIFdlYkZpbmdlciBM aW5rIFJlbGF0aW9ucyBkb2N1bWVudCwgSSB0aGluayBpdCB3b3VsZCBiZSB0aW1lbHkuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UGF1bDwvc3Bhbj48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQn PjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojOTUzNzM1Jz5QRUo6IFRoZXkgY291bGQuJm5ic3A7IFRoZSBj aGFsbGVuZ2UgaXMgdGhhdCB3ZSBoYXZlIG5vIG90aGVyIFVSSSB0eXBlIGRlZmluZWQgZm9yIHRo aXMgcHVycG9zZS4mbmJzcDsgRm9yIHRoZSBleGFtcGxlcywgd2UgaGF2ZSBhIGNoaWNrZW4gYW5k IGVnZyBwcm9ibGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rp dj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+TGV0J3MgZGVmaW5lIHNvbWUgdGhl biEgVGhpcyBpcyB0aGUgb25lIGFyZWEgdGhhdCBpcyB2YWd1ZSBhbmQgSU1ITyBpcyBhIGJhcnJp ZXIgdG8gYWRvcHRpb24uIFdoYXQgc2hvdWxkIHRoZSAmcXVvdDtyZWwmcXVvdDsgdmFsdWVzIGJl IGZvciBpdGVtcyB0aGF0IEkgd2FudCB0byBwdWJsaXNoPyBJZiB3ZSBkb24ndCBzcGVjIHRoZSBj b21tb24gb25lcywgd2Ugd2lsbCBlbmQgdXAgd2l0aCBzZXZlcmFsIGRpZmZlcmVudCBpZGVudGlm aWVycyBmb3IgdGhlIHNhbWUgdGhpbmcuIENoYWxsZW5nZSBvZiBjb3Vyc2UgaXMgdGhhdCBnZXR0 aW5nIGFncmVlbWVudCBvbiBzY2hlbWEgaXMgYWx3YXlzIGZ1biwgYnV0IGJldHRlciB0byBoYXZl IHNvbWUgdGhhdCB3aWxsIGJlIHVzZWQgdGhhdCBhcmUgbm90IGFscmVhZHkgZGVmaW5lZC48bzpw PjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNw OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ TmVlZCB0byBhZGQgYW4gSUFOQSBzZWN0aW9uIGZvciB0aGF0IG9mIGNvdXJzZS48bzpwPjwvbzpw PjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+JnF1b3Q7 YmxvZyZxdW90OyBpcyBhIGdvb2Qgb25lIDopPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWJvdHRvbToxMi4wcHQnPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj5hcHBzLWRpc2N1c3MgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1h aWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmciPmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT48YnI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1 c3MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2FwcHMtZGlzY3VzczwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PHRhYmxlIGNsYXNzPU1zb05v cm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9NjAwIHN0eWxlPSd3aWR0aDo2 LjI1aW4nPjx0cj48dGQgd2lkdGg9NTg1IHN0eWxlPSd3aWR0aDo0MzguNzVwdDtwYWRkaW5nOi43 NXB0IC43NXB0IC43NXB0IC43NXB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4 dC1hbGlnbjpqdXN0aWZ5Jz48c3BhbiBjbGFzcz1tc29ub3JtYWwwPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+UXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVz Y2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEg byBxdWFsc2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1 ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJi aWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1l bnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUg ZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuIDwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNh bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgc3R5 bGU9J3RleHQtYWxpZ246anVzdGlmeSc+PHNwYW4gY2xhc3M9bXNvbm9ybWFsMD48aT48c3BhbiBs YW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJz YW5zLXNlcmlmIjtjb2xvcjpibGFjayc+VGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50czwv c3Bhbj48L2k+PC9zcGFuPjxzcGFuIGNsYXNzPW1zb25vcm1hbDA+PGk+PHNwYW4gbGFuZz1FTi1H QiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2snPiZuYnNwO2lzJm5ic3A7PC9zcGFuPjwvaT48L3NwYW4+PHNwYW4gY2xh c3M9bXNvbm9ybWFsMD48aT48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Y29uZmlkZW50 aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0 aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9y IHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0 dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3Mu PC9zcGFuPjwvaT48L3NwYW4+PHNwYW4gY2xhc3M9bXNvbm9ybWFsMD48c3BhbiBsYW5nPUVOLUdC IHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlm Ijtjb2xvcjpibGFjayc+IDwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWFsaWduOmp1c3Rp ZnknPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEi LCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PGltZyBib3JkZXI9MCB3aWR0aD0yNiBoZWlnaHQ9 NDAgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJjaWQ6aW1hZ2UwMDEuZ2lmQDAxQ0RDOEE2LjFERTky RjQwIiBhbHQ9InJpc3BldHRhIGwnYW1iaWVudGUiPlJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBz dGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby48L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlm Ijtjb2xvcjpibGFjayc+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L3RkPjwvdHI+PC90YWJsZT48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5 PjwvaHRtbD4= --_000_C68CB012D9182D408CED7B884F441D4D1E37027B6Dnambxv01acorp_-- --_004_C68CB012D9182D408CED7B884F441D4D1E37027B6Dnambxv01acorp_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=677; creation-date="Fri, 23 Nov 2012 02:16:48 GMT"; modification-date="Fri, 23 Nov 2012 02:16:48 GMT" Content-ID: Content-Transfer-Encoding: base64 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= --_004_C68CB012D9182D408CED7B884F441D4D1E37027B6Dnambxv01acorp_-- From paulej@packetizer.com Thu Nov 22 19:52: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 1434121F8463 for ; Thu, 22 Nov 2012 19:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] 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 NXQ24ly8ZAbD for ; Thu, 22 Nov 2012 19:52:51 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7372D21F85B8 for ; Thu, 22 Nov 2012 19:52:51 -0800 (PST) Received: from [192.168.6.152] (ip-64-134-189-154.public.wayport.net [64.134.189.154]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qAN3qlS2021394 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 22 Nov 2012 22:52:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353642769; bh=Ip5ye9dEgg8bVjKtXQXfKEfR9okSjw3Qag09uFRBIxg=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=nFrcI+vgx7qGZOvxyFxzNiTdfoceeVXyOBHE8r/dcY3nc5Kip28EpuSfMuioe4ubU PNODRrvsJ+nMWqF0n0D5Q9LrlH9e61Ojjm4FWw1Fuu9NF1t9AaLf9Ejy+CiLV5VsTp iCUjx4521rqcHZFwB8OZyG55PIhbbvqoPvwsa9lM= User-Agent: Kaiten Mail In-Reply-To: References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----L7ZA7C7DMC57PHX424D5BKJU9AND0M" From: "Paul E. Jones" Date: Thu, 22 Nov 2012 22:52:45 -0500 To: Brad Fitzpatrick , webfinger@googlegroups.com Message-ID: <200c0271-9ff1-4b87-9bb7-d2ccf3aac9e8@email.android.com> Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 23 Nov 2012 03:52:56 -0000 ------L7ZA7C7DMC57PHX424D5BKJU9AND0M Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I have no idea why the TOC did not get updated, but I'm blaming Word for it. It certainly wasn't an attempt to hide anything. I'm keeping out of the debate on this one. I think Mike believes strongly that it's needed, so I'll let him make the case. I'll document whatever the group wants. Paul -------- Original Message -------- From: Brad Fitzpatrick Sent: Wed Nov 21 23:26:42 EST 2012 To: webfinger@googlegroups.com Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 The new TOC doesn't even have a section 5.5. Is that how you hide controversial stuff? :-) FWIW, I'm strongly opposed to the subdomain. It adds complexity. If you can't get your load balancing & routing act together, you don't get to play, sorry. If it's easy for the small guys, and I've seen it be easy for the medium guys, and multiple big guys have shown that it's possible, who's complaining? (rhetorical. I didn't see when this first appeared, and don't really want to know) I don't want incompetence and/or internal politics unnecessarily complicating a spec that is supposed to be simple for clients. If we all compromise, nobody wins. Actually I'll go a step further and be the dick here and say absolutely not. I'll fight for implementations that I write (and those of others whom I can influence) to NOT to do the second HTTP request (or, uh, 4th if you include https to http fallbacks on each hostname, ugh), rendering the webfinger subdomain very much not 1st tier and therefore unreliable. I already know it'll end up as a forgotten wart in the spec, like HTTP/1.1 trailers or pipelining. I mean seriously: the DNS, listening & routing aren't rocket science today and they weren't 10 years ago either. If you can't even get that right, what are the odds you can get webfinger right? This Thanksgiving I am thankful for Paul putting up with all of us. Happy turkeys, Brad On Wed, Nov 21, 2012 at 8:13 PM, Paul E. Jones wrote: > Folks,**** > > ** ** > > I just posted a new draft that takes into consideration the input I > received on -03 and adds the “webfinger†subdomain that was discussed on > the list this past week. Specifically, here’s what changed:**** > > **· **Mention in section 2 that WebFinger uses the “rel†> attribute and provide a reference to the IANA registry for link relations* > *** > > **· **Deleted the second paragraph from section 3 that expands > on link relations**** > > **· **Changed the link relation value for “blog†to be just the > token “blogâ€**** > > **· **Corrected a syntax error in the example in 4.1**** > > **· **Clarified in section 4.1 what is meant by a “valid aliasâ€*** > * > > **· **Introduced a new section 4.2 that shows an example for > OpenID Connect**** > > **· **Changed the rel types in 4.3 and 4.4 to be URI-based (on > example.net)**** > > **· **Corrected syntax in 5.3 and added two clarifying sentences** > ** > > **· **Introduced a new section 5.5 that describes the “webfinger†> subdomain**** > > **· **Changed the name of section 7**** > > **· **Added language to section 8 to support section 5.5**** > > **· **Added language to section 9 to support section 5.5**** > > **· **Spells out Mike’s name as he prefers it**** > > **· **Added a couple of informational references**** > > ** ** > > The new draft is here:**** > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04**** > > ** ** > > I think we’re getting closer, though I know the “webfinger†subdomain > might be a bit controversial. I’m on the fence on this one, myself. I can > see the pros and cons of having it. I’d prefer to stay out of the debate, > though. I’ll put into the document whatever the group says to put into the > documents :-) That said, I think Mike made a valid argument with respect > to the fact that some domain owners have no ability to do anything more > than insert an A record for a subdomain.**** > > ** ** > > I do want to highlight the fact that the current language says that if > there is any response from a web server at the host, that means the host > does have the capability of providing WF services and the “webfinger†> subdomain should not be consulted. Thus, the webfinger subdomain would > only be consulted if there is no web server running at the host at all. > It’s not a fallback for domain owners who have a web server, but just > didn’t install a WF server. For that case, they should use 3xx redirection > for hosting the WF server elsewhere.**** > > ** ** > > Paul**** > > ** ** > ------------------------------------------------------------------------ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------L7ZA7C7DMC57PHX424D5BKJU9AND0M Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I have no idea why the TOC did not get updated, but I'm blaming Word for it. It certainly wasn't an attempt to hide anything.

I'm keeping out of the debate on this one. I think Mike believes strongly that it's needed, so I'll let him make the case. I'll document whatever the group wants.

Paul



From: Brad Fitzpatrick <bradfitz@google.com>
Sent: Wed Nov 21 23:26:42 EST 2012
To: webfinger@googlegroups.com
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

The new TOC doesn't even have a section 5.5.  Is that how you hide controversial stuff?  :-)

FWIW, I'm strongly opposed to the subdomain.  It adds complexity.  If you can't get your load balancing & routing act together, you don't get to play, sorry.

If it's easy for the small guys, and I've seen it be easy for the medium guys, and multiple big guys have shown that it's possible, who's complaining?  (rhetorical. I didn't see when this first appeared, and don't really want to know)

I don't want incompetence and/or internal politics unnecessarily complicating a spec that is supposed to be simple for clients.

If we all compromise, nobody wins.  Actually I'll go a step further and be the dick here and say absolutely not.  I'll fight for implementations that I write (and those of others whom I can influence) to NOT to do the second HTTP request (or, uh, 4th if you include https to http fallbacks on each hostname, ugh), rendering the webfinger subdomain very much not 1st tier and therefore unreliable.  I already know it'll end up as a forgotten wart in the spec, like HTTP/1.1 trailers or pipelining.

I mean seriously: the DNS, listening & routing aren't rocket science today and they weren't 10 years ago either.  If you can't even get that right, what are the odds you can get webfinger right?

This Thanksgiving I am thankful for Paul putting up with all of us.

Happy turkeys,
Brad


On Wed, Nov 21, 2012 at 8:13 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

 

I just posted a new draft that takes into consideration the input I received on -03 and adds the “webfinger†subdomain that was discussed on the list this past week.  Specifically, here’s what changed:

·         Mention in section 2 that WebFinger uses the “rel†attribute and provide a reference to the IANA registry for link relations

·         Deleted the second paragraph from  section 3 that expands on link relations

·         Changed the link relation value for “blog†to be just the token “blogâ€

·         Corrected a syntax error in the example in 4.1

·         Clarified in section 4.1 what is meant by a “valid aliasâ€

·         Introduced a new section 4.2 that shows an example for OpenID Connect

·         Changed the rel types in 4.3 and 4.4 to be URI-based (on example.net)

·         Corrected syntax in 5.3 and added two clarifying sentences

·         Introduced a new section 5.5 that describes the “webfinger†subdomain

·         Changed the name of section 7

·         Added language to section 8 to support section 5.5

·         Added language to section 9 to support section 5.5

·         Spells out Mike’s name as he prefers it

·         Added a couple of informational references

 

The new draft is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04

 

I think we’re getting closer, though I know the “webfinger†subdomain might be a bit controversial.  I’m on the fence on this one, myself.  I can see the pros and cons of having it.  I’d prefer to stay out of the debate, though.  I’ll put into the document whatever the group says to put into the documents :-)  That said, I think Mike made a valid argument with respect to the fact that some domain owners have no ability to do anything more than insert an A record for a subdomain.

 

I do want to highlight the fact that the current language says that if there is any response from a web server at the host, that means the host does have the capability of providing WF services and the “webfinger†subdomain should not be consulted.  Thus, the webfinger subdomain would only be consulted if there is no web server running at the host at all.  It’s not a fallback for domain owners who have a web server, but just didn’t install a WF server.  For that case, they should use 3xx redirection for hosting the WF server elsewhere.

 

Paul

 



apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
------L7ZA7C7DMC57PHX424D5BKJU9AND0M-- From nickshanks@gmail.com Fri Nov 23 01:24: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 52C3221F8231 for ; Fri, 23 Nov 2012 01:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[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 bhr0gHqbcl45 for ; Fri, 23 Nov 2012 01:24:05 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F13A21F869C for ; Fri, 23 Nov 2012 01:24:05 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so333207wgb.13 for ; Fri, 23 Nov 2012 01:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=62Q92hW/pZZvnWM/PVdG4UxWMqU0xaBThBjfO8Q8m1Q=; b=qnkVhzoCCG8QBhvswkxKXlQYtXWwXn10q7slDKKG9eB0BMIo3Krr2ZOGtlCqOoZTZW eRaHDIcgkjm7y2TREoFFf0FCUF5bUHcTto8RwvXcXI5BcD6j5wMHbnVoEMF9m1CQRCtY NvMx/45R4hLM1W3or8sD/Un+UMe79OX2U5ZB52odGVdOYAhZsDlwGDzhV1aRQu1zUnyd h9726gDX1rx/g+yQIE3NvJijBE7F88UfcoNANvzezBGqtnbCOoJZ0BJBZ23zkGt2Q1kK MM4TU1iKA02NOqCm4AqFIoeidDkWk6HDXDYdiBLARiePJmeANt9wd0Gp8Vm+6xyBW9rA 5/Gw== Received: by 10.180.93.69 with SMTP id cs5mr5099725wib.3.1353662644506; Fri, 23 Nov 2012 01:24:04 -0800 (PST) Received: from [192.168.0.94] (host213-120-126-47.in-addr.btopenworld.com. [213.120.126.47]) by mx.google.com with ESMTPS id ec3sm7702040wib.10.2012.11.23.01.24.03 (version=SSLv3 cipher=OTHER); Fri, 23 Nov 2012 01:24:03 -0800 (PST) References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> Mime-Version: 1.0 (1.0) In-Reply-To: <013e01cdc867$caf54230$60dfc690$@packetizer.com> Content-Type: multipart/alternative; boundary=Apple-Mail-7EECE69E-D70F-4BAE-8BE1-189C1F61E8A2 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A403) From: Nicholas Shanks Date: Fri, 23 Nov 2012 09:24:02 +0000 To: "Paul E. Jones" X-Mailman-Approved-At: Fri, 23 Nov 2012 01:46:40 -0800 Cc: "" , "" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 23 Nov 2012 09:24:10 -0000 --Apple-Mail-7EECE69E-D70F-4BAE-8BE1-189C1F61E8A2 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable > The email client would take note of the "http://packetizer.com/rel/blog" l= ink relation in the above JRD Needs amending. I also don't see any need for the subdomain. =97 Nicholas. On 22 Nov 2012, at 04:13, "Paul E. Jones" wrote: > Folks, > =20 > I just posted a new draft that takes into consideration the input I receiv= ed on -03 and adds the =93webfinger=94 subdomain that was discussed on the l= ist this past week. Specifically, here=92s what changed: > =B7 Mention in section 2 that WebFinger uses the =93rel=94 attribu= te and provide a reference to the IANA registry for link relations > =B7 Deleted the second paragraph from section 3 that expands on l= ink relations > =B7 Changed the link relation value for =93blog=94 to be just the t= oken =93blog=94 > =B7 Corrected a syntax error in the example in 4.1 > =B7 Clarified in section 4.1 what is meant by a =93valid alias=94 > =B7 Introduced a new section 4.2 that shows an example for OpenID C= onnect > =B7 Changed the rel types in 4.3 and 4.4 to be URI-based (on examp= le.net) > =B7 Corrected syntax in 5.3 and added two clarifying sentences > =B7 Introduced a new section 5.5 that describes the =93webfinger=94= subdomain > =B7 Changed the name of section 7 > =B7 Added language to section 8 to support section 5.5 > =B7 Added language to section 9 to support section 5.5 > =B7 Spells out Mike=92s name as he prefers it > =B7 Added a couple of informational references > =20 > The new draft is here: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04 > =20 > I think we=92re getting closer, though I know the =93webfinger=94 subdomai= n might be a bit controversial. I=92m on the fence on this one, myself. I c= an see the pros and cons of having it. I=92d prefer to stay out of the deba= te, though. I=92ll put into the document whatever the group says to put int= o the documents :-) That said, I think Mike made a valid argument with resp= ect to the fact that some domain owners have no ability to do anything more t= han insert an A record for a subdomain. > =20 > I do want to highlight the fact that the current language says that if the= re is any response from a web server at the host, that means the host does h= ave the capability of providing WF services and the =93webfinger=94 subdomai= n should not be consulted. Thus, the webfinger subdomain would only be cons= ulted if there is no web server running at the host at all. It=92s not a fa= llback for domain owners who have a web server, but just didn=92t install a W= F server. For that case, they should use 3xx redirection for hosting the WF= server elsewhere. > =20 > Paul > =20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-7EECE69E-D70F-4BAE-8BE1-189C1F61E8A2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The email client would take note of the "http://packetizer.com/= rel/blog" lin= k relation in the above JRD

<= pre class=3D"newpage" style=3D"margin-top: 0px; margin-bottom: 0px; page-bre= ak-before: always; ">Needs amending. I also don't see any need for the subdomain.

=E2=80=94 Nicholas.


=

On 22 Nov 2012, at= 04:13, "Paul E. Jones" <paulej@= packetizer.com> wrote:

Folks,

 

I just posted a new draft that takes into consideration= the input I received on -03 and adds the =E2=80=9Cwebfinger=E2=80=9D subdom= ain that was discussed on the list this past week.  Specifically, here=E2= =80=99s what changed:

=C2=B7     &n= bsp;   Mention in section 2 tha= t WebFinger uses the =E2=80=9Crel=E2=80=9D attribute and provide a reference= to the IANA registry for link relations

=C2=B7  &= nbsp;      Delet= ed the second paragraph from  section 3 that expands on link relations<= o:p>

=C2=B7         Changed the link relation value for =E2=80=9Cb= log=E2=80=9D to be just the token =E2=80=9Cblog=E2=80=9D

=C2=B7         Corrected a syntax error in the example in 4.1

=C2=B7         Clarified in section 4.1 what is meant by a =E2=80=9Cvalid alias=E2= =80=9D

=C2=B7        = Introduced a new section 4.2 that shows a= n example for OpenID Connect

<= span style=3D"font-family:Symbol">=C2=B7    &= nbsp;    Changed the rel t= ypes in 4.3 and 4.4 to be URI-based (on examp= le.net)

=C2=B7       =   Corrected syntax in 5.3 and added t= wo clarifying sentences

=C2=B7     &= nbsp;   Introduced a new sectio= n 5.5 that describes the =E2=80=9Cwebfinger=E2=80=9D subdomain

=C2=B7         Changed the name of section 7

=C2=B7 &n= bsp;       = Added language to section 8 to support section 5.5

=C2=B7&nb= sp;        Added language to section 9 to support section 5.5

=C2=B7=C2=B7         Added a couple of informational references

 

The new draft is h= ere:

http://tools.ietf.org/html/draft-ietf-a= ppsawg-webfinger-04

 

I think we=E2=80=99re getting closer, though I k= now the =E2=80=9Cwebfinger=E2=80=9D subdomain might be a bit controversial.&= nbsp; I=E2=80=99m on the fence on this one, myself.  I can see the pros= and cons of having it.  I=E2=80=99d prefer to stay out of the debate, t= hough.  I=E2=80=99ll put into the document whatever the group says to p= ut into the documents :-)  That said, I think Mike made a valid argumen= t with respect to the fact that some domain owners have no ability to do any= thing more than insert an A record for a subdomain.

 

I do want to highlig= ht the fact that the current language says that if there is any response fro= m a web server at the host, that means the host does have the capability of p= roviding WF services and the =E2=80=9Cwebfinger=E2=80=9D subdomain should no= t be consulted.  Thus, the webfinger subdomain would only be consulted i= f there is no web server running at the host at all.  It=E2=80=99s not a= fallback for domain owners who have a web server, but just didn=E2=80=99t i= nstall a WF server.  For that case, they should use 3xx redirection for= hosting the WF server elsewhere.

=  

Paul

 

_____________________= __________________________
apps-discuss mailing list<= br>apps-discuss@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/apps-discuss
= --Apple-Mail-7EECE69E-D70F-4BAE-8BE1-189C1F61E8A2-- From ve7jtb@ve7jtb.com Fri Nov 23 05:22: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 0074921F8514 for ; Fri, 23 Nov 2012 05:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 gN2Nut6S7vAa for ; Fri, 23 Nov 2012 05:22:37 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A285F21F85DA for ; Fri, 23 Nov 2012 05:22:36 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so3137850eaa.31 for ; Fri, 23 Nov 2012 05:22:35 -0800 (PST) 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=yShXGrPrS1h2mXszKMt+PZHFNREgcde+7aP33CGc5y4=; b=Kz+F1Rdw9B5e0lEFMbckK9HUwuBdhDWWYjjHJdkYaBuP6OZexQcpvQY4HZbRl7J7kH x4poLD1CLZshjRRuyRMuSaLiCAjpA7P0kcozmPJHad5CW1cmW9CosrtFKXIeuGYG3DLh hmkwWauK7xD8mWDqjg7QZ8esd02Y0CbtwqBgsNc3DGeZU/yhHv27mhvfGviegxeGU+U4 lE+FZr98WkYXwx4bptLc6gtfIAPLcu5dyAmEYNS3Pj/Gf7gL6E1oGMhWiX7giDZGDpYe CDOojpo0LohFFuBgnuXCzYMsMa0fbnBZAn2fiONJbZ9PDFHPFeQYTjz4jgChsPuDIlm2 olHw== Received: by 10.14.203.2 with SMTP id e2mr13537223eeo.20.1353676955530; Fri, 23 Nov 2012 05:22:35 -0800 (PST) Received: from [192.168.49.75] ([212.202.102.202]) by mx.google.com with ESMTPS id e7sm13636191eep.1.2012.11.23.05.22.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Nov 2012 05:22:34 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9019F881-422B-4264-8680-4C051C8B57B9" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Fri, 23 Nov 2012 14:22:28 +0100 Message-Id: References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnizaSiJ5JNDnlfxATEtsXFmh7v2n9DLJn/BWz9nXfQpYV35cGF0imaHByw3HHsp24OXwKO Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 23 Nov 2012 13:22:50 -0000 --Apple-Mail=_9019F881-422B-4264-8680-4C051C8B57B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Brad, In openID Yadis discovery, your employer Google did a back door deal = with library authors including JainRain to modify there openID librays = to check with Google to see if a domain is being served by Google apps = for domains. This essentially allows Google to hijack domains not = served by Google apps if they were to become evil. The perhaps even larger problem is that a specific hack for Gooole apps = support disenfranchised other potential multi tenant services. I don't imagine that you are advocating for another google proprietary = solution that will be retrofitted into Web Finger. The functionality to support multi tenant in a standard way has come = from Google and some other larger IdP. I am not saying that the subdomain method (similar provisioning to a = apps customer creating mail.mydomain.com as a cname pointing to a = hosting provider as is done now.) is the perfect solution. However a lot of people have been trying to come up with a simple way = not to cut off millions of potential users. If you could ease off on the rhetoric and propose a better way to solve = this then people will be more than happy to consider it. My main concern is to not repeat what I consider to be a serious = security problem with openID 2 discovery introduced to support Google = Apps. Regards John B. On 2012-11-22, at 5:26 AM, Brad Fitzpatrick wrote: > The new TOC doesn't even have a section 5.5. Is that how you hide = controversial stuff? :-) >=20 > FWIW, I'm strongly opposed to the subdomain. It adds complexity. If = you can't get your load balancing & routing act together, you don't get = to play, sorry. >=20 > If it's easy for the small guys, and I've seen it be easy for the = medium guys, and multiple big guys have shown that it's possible, who's = complaining? (rhetorical. I didn't see when this first appeared, and = don't really want to know) >=20 > I don't want incompetence and/or internal politics unnecessarily = complicating a spec that is supposed to be simple for clients. >=20 > If we all compromise, nobody wins. Actually I'll go a step further = and be the dick here and say absolutely not. I'll fight for = implementations that I write (and those of others whom I can influence) = to NOT to do the second HTTP request (or, uh, 4th if you include https = to http fallbacks on each hostname, ugh), rendering the webfinger = subdomain very much not 1st tier and therefore unreliable. I already = know it'll end up as a forgotten wart in the spec, like HTTP/1.1 = trailers or pipelining. >=20 > I mean seriously: the DNS, listening & routing aren't rocket science = today and they weren't 10 years ago either. If you can't even get that = right, what are the odds you can get webfinger right? >=20 > This Thanksgiving I am thankful for Paul putting up with all of us. >=20 > Happy turkeys, > Brad >=20 >=20 > On Wed, Nov 21, 2012 at 8:13 PM, Paul E. Jones = wrote: > Folks, >=20 > =20 >=20 > I just posted a new draft that takes into consideration the input I = received on -03 and adds the =93webfinger=94 subdomain that was = discussed on the list this past week. Specifically, here=92s what = changed: >=20 > =B7 Mention in section 2 that WebFinger uses the =93rel=94 = attribute and provide a reference to the IANA registry for link = relations >=20 > =B7 Deleted the second paragraph from section 3 that expands = on link relations >=20 > =B7 Changed the link relation value for =93blog=94 to be just = the token =93blog=94 >=20 > =B7 Corrected a syntax error in the example in 4.1 >=20 > =B7 Clarified in section 4.1 what is meant by a =93valid = alias=94 >=20 > =B7 Introduced a new section 4.2 that shows an example for = OpenID Connect >=20 > =B7 Changed the rel types in 4.3 and 4.4 to be URI-based (on = example.net) >=20 > =B7 Corrected syntax in 5.3 and added two clarifying sentences >=20 > =B7 Introduced a new section 5.5 that describes the = =93webfinger=94 subdomain >=20 > =B7 Changed the name of section 7 >=20 > =B7 Added language to section 8 to support section 5.5 >=20 > =B7 Added language to section 9 to support section 5.5 >=20 > =B7 Spells out Mike=92s name as he prefers it >=20 > =B7 Added a couple of informational references >=20 > =20 >=20 > The new draft is here: >=20 > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04 >=20 > =20 >=20 > I think we=92re getting closer, though I know the =93webfinger=94 = subdomain might be a bit controversial. I=92m on the fence on this one, = myself. I can see the pros and cons of having it. I=92d prefer to stay = out of the debate, though. I=92ll put into the document whatever the = group says to put into the documents :-) That said, I think Mike made a = valid argument with respect to the fact that some domain owners have no = ability to do anything more than insert an A record for a subdomain. >=20 > =20 >=20 > I do want to highlight the fact that the current language says that if = there is any response from a web server at the host, that means the host = does have the capability of providing WF services and the =93webfinger=94 = subdomain should not be consulted. Thus, the webfinger subdomain would = only be consulted if there is no web server running at the host at all. = It=92s not a fallback for domain owners who have a web server, but just = didn=92t install a WF server. For that case, they should use 3xx = redirection for hosting the WF server elsewhere. >=20 > =20 >=20 > Paul >=20 > =20 >=20 >=20 --Apple-Mail=_9019F881-422B-4264-8680-4C051C8B57B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 mail.mydomain.com as a cname = pointing to a hosting provider as is done now.) is the perfect = solution.

However a lot of people have been = trying to come up with a simple way not to cut off millions of potential = users.

If you could ease off on the rhetoric = and propose a better way to solve this then people will be more than = happy to consider it.

My main concern is to not = repeat what I consider to be a serious security problem with openID 2 = discovery introduced to support Google = Apps.

Regards
John = B.

On 2012-11-22, at 5:26 AM, Brad Fitzpatrick = <bradfitz@google.com> = wrote:

The new TOC doesn't even have a section 5.5.  Is = that how you hide controversial stuff? =  :-)

FWIW, I'm strongly opposed to the = subdomain.  It adds complexity.  If you can't get your load = balancing & routing act together, you don't get to play, = sorry.

If it's easy for the small guys, and I've seen it be = easy for the medium guys, and multiple big guys have shown that it's = possible, who's complaining?  (rhetorical. I didn't see when this = first appeared, and don't really want to know)

I don't want incompetence and/or internal = politics unnecessarily complicating a spec that is supposed to be simple = for clients.

If we all compromise, nobody wins. =  Actually I'll go a step further and be the dick here and say = absolutely not.  I'll fight for implementations that I write (and = those of others whom I can influence) to NOT to do the second HTTP = request (or, uh, 4th if you include https to http fallbacks on each = hostname, ugh), rendering the webfinger subdomain very much not 1st tier = and therefore unreliable.  I already know it'll end up as a = forgotten wart in the spec, like HTTP/1.1 trailers or pipelining.

I mean seriously: the DNS, listening & routing = aren't rocket science today and they weren't 10 years ago either. =  If you can't even get that right, what are the odds you can get = webfinger right?

This Thanksgiving I am thankful for Paul putting up = with all of us.

Happy = turkeys,
Brad


On Wed, Nov 21, 2012 at 8:13 PM, Paul E. Jones = <paulej@packetizer.com> wrote:

Folks,

 

I = just posted a new draft that takes into consideration the input I = received on -03 and adds the =93webfinger=94 subdomain that was = discussed on the list this past week.  Specifically, here=92s what = changed:

=B7         = Mention in section 2 that WebFinger uses the = =93rel=94 attribute and provide a reference to the IANA registry for = link relations

=B7         = Deleted the second paragraph from  = section 3 that expands on link = relations

=B7         = Changed the link relation value for =93blog=94= to be just the token =93blog=94

=B7         = Corrected a syntax error in the example in = 4.1

=B7         = Clarified in section 4.1 what is meant by a = =93valid alias=94

=B7         = Introduced a new section 4.2 that shows an = example for OpenID Connect

=B7         = Changed the rel types in 4.3 and 4.4 to be = URI-based (on example.net)

=B7         = Corrected syntax in 5.3 and added two = clarifying sentences

=B7         = Introduced a new section 5.5 that describes = the =93webfinger=94 subdomain

=B7         = Changed the name of section = 7

=B7         = Added language to section 8 to support = section 5.5

=B7         = Added language to section 9 to support = section 5.5

=B7         = Spells out Mike=92s name as he prefers = it

=B7         = Added a couple of informational = references

 

The new draft is = here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-= 04

 

I think we=92re getting closer, though I know the = =93webfinger=94 subdomain might be a bit controversial.  I=92m on = the fence on this one, myself.  I can see the pros and cons of = having it.  I=92d prefer to stay out of the debate, though.  = I=92ll put into the document whatever the group says to put into the = documents :-)  That said, I think Mike made a valid argument with = respect to the fact that some domain owners have no ability to do = anything more than insert an A record for a = subdomain.

 

I do = want to highlight the fact that the current language says that if there = is any response from a web server at the host, that means the host does = have the capability of providing WF services and the =93webfinger=94 = subdomain should not be consulted.  Thus, the webfinger subdomain = would only be consulted if there is no web server running at the host at = all.  It=92s not a fallback for domain owners who have a web = server, but just didn=92t install a WF server.  For that case, they = should use 3xx redirection for hosting the WF server elsewhere.

 

Paul

 



= --Apple-Mail=_9019F881-422B-4264-8680-4C051C8B57B9-- From paulej@packetizer.com Fri Nov 23 06:52: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 9E44321F849E for ; Fri, 23 Nov 2012 06:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] 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 csvSVODa6mQI for ; Fri, 23 Nov 2012 06:52:22 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 14F0621F8446 for ; Fri, 23 Nov 2012 06:52:22 -0800 (PST) Received: from [10.62.53.234] (mobile-032-147-199-086.mycingular.net [32.147.199.86] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qANEqH01019287 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 23 Nov 2012 09:52:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353682340; bh=tFrA40uy/PgJj3PrsJ1O3DZsBtKuvBaLtQuPtfcc/bg=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=jukv39XfWu5GzVT4uyeA/2fiAGgcGWxbTD521n8hmKP3fzAlm/1QU31oFtJ48lqlH kEsiSbIarB3xduFlQXGyR2gjX7B/I7t8JCssRURStD+kOXmlWoCiZ/v69+0ufjZwf4 JsUE8kShkOpVafEEMxhdJO8H9zHkcXIQ9nI9uHgM= User-Agent: K-9 Mail for Android In-Reply-To: References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----PS0M76PONI0J70FOIN6YCBQ72QE2IS" From: "Paul E. Jones" Date: Fri, 23 Nov 2012 09:52:12 -0500 To: Nicholas Shanks Message-ID: Cc: "" , "" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 23 Nov 2012 14:52:26 -0000 ------PS0M76PONI0J70FOIN6YCBQ72QE2IS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I corrected that for -05. Thanks! Paul -------- Original Message -------- From: Nicholas Shanks Sent: Fri Nov 23 04:24:02 EST 2012 To: "Paul E. Jones" Cc: "" , "" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 > The email client would take note of the "http://packetizer.com/rel/blog" link relation in the above JRD Needs amending. I also don't see any need for the subdomain. — Nicholas. On 22 Nov 2012, at 04:13, "Paul E. Jones" wrote: > Folks, > > I just posted a new draft that takes into consideration the input I received on -03 and adds the “webfinger†subdomain that was discussed on the list this past week. Specifically, here’s what changed: > · Mention in section 2 that WebFinger uses the “rel†attribute and provide a reference to the IANA registry for link relations > · Deleted the second paragraph from section 3 that expands on link relations > · Changed the link relation value for “blog†to be just the token “blog†> · Corrected a syntax error in the example in 4.1 > · Clarified in section 4.1 what is meant by a “valid alias†> · Introduced a new section 4.2 that shows an example for OpenID Connect > · Changed the rel types in 4.3 and 4.4 to be URI-based (on example.net) > · Corrected syntax in 5.3 and added two clarifying sentences > · Introduced a new section 5.5 that describes the “webfinger†subdomain > · Changed the name of section 7 > · Added language to section 8 to support section 5.5 > · Added language to section 9 to support section 5.5 > · Spells out Mike’s name as he prefers it > · Added a couple of informational references > > The new draft is here: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04 > > I think we’re getting closer, though I know the “webfinger†subdomain might be a bit controversial. I’m on the fence on this one, myself. I can see the pros and cons of having it. I’d prefer to stay out of the debate, though. I’ll put into the document whatever the group says to put into the documents :-) That said, I think Mike made a valid argument with respect to the fact that some domain owners have no ability to do anything more than insert an A record for a subdomain. > > I do want to highlight the fact that the current language says that if there is any response from a web server at the host, that means the host does have the capability of providing WF services and the “webfinger†subdomain should not be consulted. Thus, the webfinger subdomain would only be consulted if there is no web server running at the host at all. It’s not a fallback for domain owners who have a web server, but just didn’t install a WF server. For that case, they should use 3xx redirection for hosting the WF server elsewhere. > > Paul > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss ------PS0M76PONI0J70FOIN6YCBQ72QE2IS Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I corrected that for -05. Thanks!

Paul

From: Nicholas Shanks <nickshanks@gmail.com>
Sent: Fri Nov 23 04:24:02 EST 2012
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: "<apps-discuss@ietf.org>" <apps-discuss@ietf.org>, "<webfinger@googlegroups.com>" <webfinger@googlegroups.com>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

The email client would take note of the "http://packetizer.com/rel/blog" link relation in the above JRD

Needs amending. I also don't see any need for the subdomain.

— Nicholas.



On 22 Nov 2012, at 04:13, "Paul E. Jones" <paulej@packetizer.com> wrote:

Folks,

 

I just posted a new draft that takes into consideration the input I received on -03 and adds the “webfinger†subdomain that was discussed on the list this past week.  Specifically, here’s what changed:

·         Mention in section 2 that WebFinger uses the “rel†attribute and provide a reference to the IANA registry for link relations

·         Deleted the second paragraph from  section 3 that expands on link relations

·         Changed the link relation value for “blog†to be just the token “blogâ€

·         Corrected a syntax error in the ex! ample in 4.1

·         Clarified in section 4.1 what is meant by a “valid aliasâ€

·         Introduced a new section 4.2 that shows an example for OpenID Connect

·         Changed the rel types in 4.3 and 4.4 to be URI-based (on example.net)

·         Corrected syntax in 5.3 and added two clarifying sentences

·         Introduced a new section 5.5 that describes the “webfinger†subdomain

·         Changed the name of section 7

·         Added language to section 8 to support section 5.5

·         Added language to section 9 to support section 5.5

·         Spells out Mike’s name as he prefers it

·         Added a couple of informational references

 

The new draft is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04

 

I think we’re getting closer, though I know the “webfinger†subdomain might be a bit controversial.  I’m on the fence on this one, myself.  I can see the pros and cons of having it.  I’d prefer to stay out of the debate, though.  I’ll put into the document whatever the group says to put into the documents :-)  That said, I think Mike made a valid argument with respect to the fact that some domain owners have no ability to do anything more than insert an A record for a subdomain.

 

I do want to highlight the fact that the current language says that if there is any response from a web server at the host, that means the host does have the capability of providing WF services and the “webfinger†subdomain should not be consulted.  Thus, the webfinger subdomain would only be consulted if there is no web server running at the host at all.  It’s not a fallback for domain owners who have a web server, but just didn’t install a WF server.  For that case, they should use 3xx redirection for hosting the WF server elsewhere.

 

Paul

 

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
------PS0M76PONI0J70FOIN6YCBQ72QE2IS-- From jasnell@gmail.com Fri Nov 23 08:51: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 4FCF421F8532 for ; Fri, 23 Nov 2012 08:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.79 X-Spam-Level: X-Spam-Status: No, score=-3.79 tagged_above=-999 required=5 tests=[AWL=-0.192, 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 R18v0dYZEkM1 for ; Fri, 23 Nov 2012 08:51:56 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5338A21F861E for ; Fri, 23 Nov 2012 08:51:56 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6734186ieb.31 for ; Fri, 23 Nov 2012 08:51:55 -0800 (PST) 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=1NHOtjTN28B+XO1YQ5J7TMrfIlfJ+9cbeLQK4f6P9B4=; b=H9fcluGUsCPibxwKIPkgZdgF+Y0zkS4KBjStjFnpV1DXpjdYuxDGO3to26C2gjzjQj YSDCSBzdlVOC/xzEwAODeid4BDJcF46lVG3j98yHZuRkxQKo/6jzm+6gtJcSqSWWuT1c j0Y4KEF6ogLIh6pTZ+mrhg46fIpcJR0rx+Bug7e4HgMHMkZUBu9t1JbcvNxU6iZGQwqb 99wtgWqF4C6DBzd4MsG5EvIFyZWbMOJBa3sR6IukhweKHMWOWAs2Equx6o49AEdt0Jv6 dcSgrOjyra4EayYzaKzADU+y0ZRWq9e9U+j3wvxHLXSg0MnX7L5s5ZeMyKsWtWD5d6N7 GU4g== Received: by 10.50.53.147 with SMTP id b19mr4069678igp.12.1353689515696; Fri, 23 Nov 2012 08:51:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.225 with HTTP; Fri, 23 Nov 2012 08:51:35 -0800 (PST) In-Reply-To: References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> From: James M Snell Date: Fri, 23 Nov 2012 08:51:35 -0800 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d04339c96b8232a04cf2c66cd Cc: Nicholas Shanks , "" , "" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 23 Nov 2012 16:51:58 -0000 --f46d04339c96b8232a04cf2c66cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable At this point, I'd have to say that I'm not entirely convinced that the subdomain option is useful either but I'd need to get some more direct implementation experience with this variation of the spec to say for certain. The one variation on this that I've been kicking around is the SRV option... e.g. _webfinger._http.example.com. 86400 IN SRV 0 5 80 example.org. Essentially allowing the example.com to point to example.org as the location of it's WebFinger services. Obviously there are issues with this approach as well but I would suspect that it's at least as viable as the subdomain approach (and arguably more flexible). That said, however, we could likely keep going around n around on possible viable solutions... at this point let's all just go write some code for a bit and really see which approach works best. - James On Fri, Nov 23, 2012 at 6:52 AM, Paul E. Jones wrote= : > I corrected that for -05. Thanks! > > Paul > > ------------------------------ > *From:* Nicholas Shanks > *Sent:* Fri Nov 23 04:24:02 EST 2012 > *To:* "Paul E. Jones" > *Cc:* "" , "< > webfinger@googlegroups.com>" > *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 > > The email client would take note of the "http://packetizer.com/rel/blog" > link relation in the above JRD > > > Needs amending. I also don't see any need for the subdomain. > > > =E2=80=94 Nicholas. > > > > On 22 Nov 2012, at 04:13, "Paul E. Jones" wrote: > > Folks, > > > > I just posted a new draft that takes into consideration the input I > received on -03 and adds the =E2=80=9Cwebfinger=E2=80=9D subdomain that w= as discussed on > the list this past week. Specifically, here=E2=80=99s what changed: > > =C2=B7 Mention in section 2 that WebFinger uses the =E2=80=9Crel= =E2=80=9D attribute > and provide a reference to the IANA registry for link relations > > =C2=B7 Deleted the second paragraph from section 3 that expands = on > link relations > > =C2=B7 Changed the link relation value for =E2=80=9Cblog=E2=80=9D= to be just the token > =E2=80=9Cblog=E2=80=9D > > =C2=B7 Corrected a syntax error in the ex! ample in 4.1 > > =C2=B7 Clarified in section 4.1 what is meant by a =E2=80=9Cvalid= alias=E2=80=9D > > =C2=B7 Introduced a new section 4.2 that shows an example for Ope= nID > Connect > > =C2=B7 Changed the rel types in 4.3 and 4.4 to be URI-based (on > example.net) > > =C2=B7 Corrected syntax in 5.3 and added two clarifying sentences > > =C2=B7 Introduced a new section 5.5 that describes the =E2=80=9Cw= ebfinger=E2=80=9D > subdomain > > =C2=B7 Changed the name of section 7 > > =C2=B7 Added language to section 8 to support section 5.5 > > =C2=B7 Added language to section 9 to support section 5.5 > > =C2=B7 Spells out Mike=E2=80=99s name as he prefers it > > =C2=B7 Added a couple of informational references > > > > The new draft is here: > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04 > > > > I think we=E2=80=99re getting closer, though I know the =E2=80=9Cwebfinge= r=E2=80=9D subdomain > might be a bit controversial. I=E2=80=99m on the fence on this one, myse= lf. I can > see the pros and cons of having it. I=E2=80=99d prefer to stay out of th= e debate, > though. I=E2=80=99ll put into the document whatever the group says to pu= t into the > documents :-) That said, I think Mike made a valid argument with respect > to the fact that some domain owners have no ability to do anything more > than insert an A record for a subdomain. > > > > I do want to highlight the fact that the current language says that if > there is any response from a web server at the host, that means the host > does have the capability of providing WF services and the =E2=80=9Cwebfin= ger=E2=80=9D > subdomain should not be consulted. Thus, the webfinger subdomain would > only be consulted if there is no web server running at the host at all. > It=E2=80=99s not a fallback for domain owners who have a web server, but = just > didn=E2=80=99t install a WF server. For that case, they should use 3xx r= edirection > for hosting the WF server elsewhere. > > > > Paul > > > > _______________________________________________ > 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 > > --f46d04339c96b8232a04cf2c66cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable At this point, I'd have to say tha= t I'm not entirely convinced that the subdomain option is useful either= but I'd need to get some more direct implementation experience with th= is variation of the spec to say for certain.

The one variation on t= his that I've been kicking around is the SRV option... e.g.

=C2=A0_webfinger._http.example.com. 86400 IN SRV 0 5 80 = example.org.

Essentially allowing the= example.com to point to example.org as the location of it's WebFinger servi= ces. Obviously there are issues with this approach as well but I would susp= ect that it's at least as viable as the subdomain approach (and arguabl= y more flexible). That said, however, we could likely keep going around n a= round on possible viable solutions... at this point let's all just go w= rite some code for a bit and really see which approach works best.

- James


On Fri, Nov 2= 3, 2012 at 6:52 AM, Paul E. Jones <paulej@packetizer.com> wrote:
I corrected that for = -05. Thanks!

Paul

From: Nicholas Shanks <nickshanks@gmail.com>
Sent: Fri Nov 23 04:24:02 EST 2012
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: "<apps-discuss@ietf.org>" <apps-discuss@ietf.org>, "<webfinger@google= groups.com>" <webfinger@googlegroups.com>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

The email client would take note of the "http://packetizer.com/rel/blog" link relation in the above JRD

Needs amending. I also don't s=
ee any need for the subdomain.

<=
/span>
=E2=80=94 Nicholas.



On 22 Nov 2012, at 04:13, "Paul E. Jones" <paulej@packetizer.com&= gt; wrote:

Folks,

=C2= =A0

I just posted a new draft that takes into con= sideration the input I received on -03 and adds the =E2=80=9Cwebfinger=E2= =80=9D subdomain that was discussed on the list this past week.=C2=A0 Speci= fically, here=E2=80=99s what changed:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Mention in section 2 that WebFinger uses = the =E2=80=9Crel=E2=80=9D attribute and provide a reference to the IANA reg= istry for link relations

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Deleted the second paragraph from=C2=A0 s= ection 3 that expands on link relations

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Changed the link relation value for =E2=80=9Cblog=E2= =80=9D to be just the token =E2=80=9Cblog=E2=80=9D

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Corrected a syntax error in the ex! ample in 4.1

=C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Clarified in sect= ion 4.1 what is meant by a =E2=80=9Cvalid alias=E2=80=9D

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Introduced a new section 4.2 that shows an e= xample for OpenID Connect

<= span>=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Changed the rel types in 4.3 and 4.4 to be URI-based (on example.net)

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Corrected syntax in 5.3 and added two cla= rifying sentences

=C2= =B7=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Introduced a new sec= tion 5.5 that describes the =E2=80=9Cwebfinger=E2=80=9D subdomain

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Changed the name of section 7

<= p>=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Added language to section 8 to support section 5.5=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Added language to section 9 to support section 5.5

=

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Spells out Mike=E2=80=99s name as he pref= ers it

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Added a couple of informational reference= s

=C2=A0

The new draft is here:

http:= //tools.ietf.org/html/draft-ietf-appsawg-webfinger-04

=C2=A0

I think we=E2=80=99re getting close= r, though I know the =E2=80=9Cwebfinger=E2=80=9D subdomain might be a bit c= ontroversial.=C2=A0 I=E2=80=99m on the fence on this one, myself.=C2=A0 I c= an see the pros and cons of having it.=C2=A0 I=E2=80=99d prefer to stay out= of the debate, though.=C2=A0 I=E2=80=99ll put into the document whatever t= he group says to put into the documents :-)=C2=A0 That said, I think Mike m= ade a valid argument with respect to the fact that some domain owners have = no ability to do anything more than insert an A record for a subdomain.

=C2=A0

I do = want to highlight the fact that the current language says that if there is = any response from a web server at the host, that means the host does have t= he capability of providing WF services and the =E2=80=9Cwebfinger=E2=80=9D subdomain should not be consulted.=C2=A0 Thus, = the webfinger subdomain would only be consulted if there is no web server r= unning at the host at all.=C2=A0 It=E2=80=99s not a fallback for domain own= ers who have a web server, but just didn=E2=80=99t install a WF server.=C2= =A0 For that case, they should use 3xx redirection for hosting the WF serve= r elsewhere.

=C2=A0

Paul<= /p>

=C2=A0

______________= _________________________________
apps-discuss mailing list
apps-discuss@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_bl= ank">https://www.ietf.org/mailman/listinfo/apps-discuss

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


--f46d04339c96b8232a04cf2c66cd-- From jasnell@gmail.com Fri Nov 23 08:57: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 1C8C421F8555 for ; Fri, 23 Nov 2012 08:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=-2.121, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 BKW1BElI3YBp for ; Fri, 23 Nov 2012 08:57:22 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3A321F850A for ; Fri, 23 Nov 2012 08:57:22 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6741202ieb.31 for ; Fri, 23 Nov 2012 08:57:21 -0800 (PST) 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=ETi5nB6Wf9BkYFhuG8lHym0/klAX6AArfzj9Vs1VZvg=; b=d11HCQ9EiXA2oPHS8wphbKx3XzecfNQ7Zibzaxd9zk8i3x9pm+AJDx2I3s6l7UQktC psw6q4NwWOb2XyuZ2cxJ3P2Z1FlRZcsuf/BJDH8rlGBcHkC3slz8CZ11SeP7ZXS/+bOI HWWdQB4eIgsb8I6osxvV4+1KfbEospDciriVnrPpvUcn7wkUtgUNl/r7E9N16EQ/NXv6 yAu1N7xcpi6wJGNPlc6pPBY1AK7l/N+jBI+tyH1iYTLwnfjwLFs8Oc9maYTT8Z0NIbQv XqESX07rq+SKELkwgfQW/sDHlm2jAEUCnBApCnpP8GowVxvAzY2UkfGqiasqIE+ECq7N RqxA== Received: by 10.42.180.10 with SMTP id bs10mr3530415icb.39.1353689841817; Fri, 23 Nov 2012 08:57:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.225 with HTTP; Fri, 23 Nov 2012 08:57:01 -0800 (PST) In-Reply-To: References: <0d9001cdc47a$98fb1b60$caf15220$@packetizer.com> <5C48FCFD-B45B-4CF5-A1C6-8333661468EB@gmail.com> <00bb01cdc5d5$50784e60$f168eb20$@packetizer.com> <81A5CAE7-66BF-4FBF-9DBD-42A371B36435@gmail.com> <00e101cdc5d8$70694f50$513bedf0$@packetizer.com> <67D3A4CB-3CDE-4CAC-BE22-0282A9277FD2@gmail.com> <025e01cdc6db$faf26720$f0d73560$@packetizer.com> From: James M Snell Date: Fri, 23 Nov 2012 08:57:01 -0800 Message-ID: To: Larry Masinter Content-Type: multipart/related; boundary=90e6ba6e8aee285a1604cf2c7a7c Cc: IETF Apps Discuss , "webfinger@googlegroups.com" Subject: Re: [apps-discuss] Link rels 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, 23 Nov 2012 16:57:24 -0000 --90e6ba6e8aee285a1604cf2c7a7c Content-Type: multipart/alternative; boundary=90e6ba6e8aee285a1404cf2c7a7b --90e6ba6e8aee285a1404cf2c7a7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Nov 22, 2012 at 6:16 PM, Larry Masinter wrote: > Negotiating controlled vocabularies is a difficult course. =E2=80=9Cnarro= w=E2=80=9D, > =E2=80=9Cunambiguous=E2=80=9D, =E2=80=9Cclear semantics=E2=80=9D, =E2=80= =9Cguarantee interop=E2=80=9D are great > aspirations, but ultimately impossible. Ambiguity is intrinsic.**** > > ** ** > > =E2=80=9Cminimize ambiguity=E2=80=9D, =E2=80=9Cwell-documented semantics= =E2=80=9D and =E2=80=9Cpromote > interoperability=E2=80=9D would be more realistic.**** > > ** ** > > Applications will use link relations, and some applications will apply > specialized meaning to a link relation that other applications will not. = * > *** > > ** > Agreed... what I'm going for more here is modeling "good behavior". Applications have the option of using registered link relations or extension link relations. If a link rel needs to be very specific to a particular kind of resource, then we should encourage applications to use extension link rels in the form of absolute URIs. Obviously this isn't something that can be strictly enforced but we can, at the very least, set a good example. - James > ** > > =E2=80=9CThe link relation registry should be maintained, such that docum= entation > for applications that rely on particular link relations are easy to find > from the link relation registry=E2=80=9D.**** > > ** ** > > ** ** > > ** ** > > *From:* apps-discuss-bounces@ietf.org [mailto: > apps-discuss-bounces@ietf.org] *On Behalf Of *Goix Laurent Walter > *Sent:* Tuesday, November 20, 2012 5:39 AM > *To:* Paul E. Jones; 'James M Snell'; 'Dick Hardt' > > *Cc:* webfinger@googlegroups.com; 'IETF Apps Discuss' > *Subject:* [apps-discuss] Link rels**** > > ** ** > > +1 for narrow & unambiguous rels with clear semantics that guarantee > interop (btw I think we are deriving from the core webfinger discussion > here so I changed the subject)**** > > ** ** > > The link rels proposed by james in the draft are meaningful (I do have > some doubts on about vs related, which is already registered). =E2=80=9Ca= vatar=E2=80=9D > could be added there in case the draft can serve as basis for this activi= ty. > **** > > ** ** > > For =E2=80=9Cupdates-from=E2=80=9D indeed these are specific to activity = streams > represented in atom, and should not vary their meaning (besides a type > parameter which could allow for json as well): for this reason the > reference to activitystreams could be stronger imo. maybe =E2=80=9Cactivi= ties=E2=80=9D?*** > * > > ** ** > > walter**** > > ** ** > > *Da:* apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] > *Per conto di *Paul E. Jones > *Inviato:* marted=C3=AC 20 novembre 2012 6.01 > *A:* 'James M Snell'; 'Dick Hardt' > *Cc:* webfinger@googlegroups.com; 'IETF Apps Discuss' > *Oggetto:* Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt**** > > ** ** > > James,**** > > ** ** > > I think the =E2=80=9Cupdates-from=E2=80=9D was intended to be an ATOM fee= d, though I might > be wrong. In your example, you show a blog. But, at the same time we wa= nt > to define =E2=80=9Cblog=E2=80=9D as its own rel.**** > > ** ** > > I think it=E2=80=99s important that we have a very narrow scope for any r= el. I > don=E2=80=99t care what the values are, but we need to ensure there is no= ambiguity > in what a given token means.**** > > ** ** > > Paul**** > > ** ** > > *From:* James M Snell [mailto:jasnell@gmail.com ] > *Sent:* Monday, November 19, 2012 12:36 PM > *To:* Dick Hardt > *Cc:* Paul E. Jones; webfinger@googlegroups.com; IETF Apps Discuss > *Subject:* Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt**** > > ** ** > > Just a quick note on this... I already have the existing "Additional Link > Relations" draft [1] in progress (currently submitted as an independent > submission) that registers link relations such as "about", "type", > "terms-of-service", "privacy-policy" and "preview". It would be possible = to > pull this draft back and add a few more link relation types to it if > necessary. We would just need to identify the set of new link rels and I > could very easily drop them in or write up a quick second document based = on > the same simple template.**** > > ** ** > > [1] http://tools.ietf.org/html/draft-snell-additional-link-relations-06**= * > * > > ** ** > > That said, the "about" link relation can be used to link to both > profile-page and vcard type resources... differentiated, of course, by th= e > media type of the linked resource. **** > > ** ** > > Also... We need to be careful not to get too specific with link relation > labels. The rel values themselves are intended to state the nature of the > relationship and not the type of resource it is. Having something like > {"rel":"updates","href":"http://example.org/my/blog","type":"text/html"} > should be generally preferable over something like {"rel":"blog","href":" > http://example.org/my/blog"}. **** > > ** ** > > - James**** > > ** ** > > On Sun, Nov 18, 2012 at 2:22 PM, Dick Hardt wrote:= * > *** > > Hi Paul**** > > ** ** > > I agree it should be separate drafts. I'd be willing to edit if there is > interest. My interest in WebFinger is as a consumer much more than a > publisher - so I don't feel I am a domain expert.**** > > ** ** > > Is it possible to have meaningful examples with existing "rel" values, or > do we need to have some others defined to have meaningful examples?**** > > ** ** > > -- Dick**** > > ** ** > > On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" > wrote:**** > > ** ** > > Dick,**** > > **** > > These should be separate drafts. I agree =E2=80=9Cblog=E2=80=9D is good,= but there are > surely more. A lot of good ones are defined under webfinger.net, too.***= * > > **** > > But I would really prefer to not slow down this draft with addition of > link relation values. If somebody (you?) wants to start a WebFinger Link > Relations document, I think it would be timely.**** > > **** > > Paul**** > > **** > > **** > > PEJ: They could. The challenge is that we have no other URI type defined > for this purpose. For the examples, we have a chicken and egg problem.**= * > * > > **** > > Let's define some then! This is the one area that is vague and IMHO is a > barrier to adoption. What should the "rel" values be for items that I wan= t > to publish? If we don't spec the common ones, we will end up with several > different identifiers for the same thing. Challenge of course is that > getting agreement on schema is always fun, but better to have some that > will be used that are not already defined.**** > > **** > > Need to add an IANA section for that of course.**** > > **** > > "blog" is a good one :)**** > > ** ** > > > _______________________________________________ > 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.* **** > > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa > mail se non =C3=A8 necessario.* **** > > ** ** > --90e6ba6e8aee285a1404cf2c7a7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
--90e6ba6e8aee285a1404cf2c7a7b-- --90e6ba6e8aee285a1604cf2c7a7c Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 2cb4c033252f0291_0.1 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= --90e6ba6e8aee285a1604cf2c7a7c-- From william_john_mills@yahoo.com Fri Nov 23 08:58: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 6818221F855A for ; Fri, 23 Nov 2012 08:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.088 X-Spam-Level: X-Spam-Status: No, score=-17.088 tagged_above=-999 required=5 tests=[AWL=0.510, 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 i5XXEbpL-4uS for ; Fri, 23 Nov 2012 08:58:30 -0800 (PST) Received: from nm24-vm3.bullet.mail.ne1.yahoo.com (nm24-vm3.bullet.mail.ne1.yahoo.com [98.138.91.154]) by ietfa.amsl.com (Postfix) with ESMTP id 07DC321F8559 for ; Fri, 23 Nov 2012 08:58:29 -0800 (PST) Received: from [98.138.226.180] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 16:58:25 -0000 Received: from [98.138.89.193] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 16:58:25 -0000 Received: from [127.0.0.1] by omp1051.mail.ne1.yahoo.com with NNFMP; 23 Nov 2012 16:58:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 381247.85873.bm@omp1051.mail.ne1.yahoo.com Received: (qmail 56904 invoked by uid 60001); 23 Nov 2012 16:58:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353689904; bh=Qsu6xoqymVJVlFRx1k9jfWE+4MZKwuefALoFnzQdrY8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=U6nzGjPQISpkg1xc7196hi79kOI4Zz33NimAzvIQBswNp+HWBLHoPnqtgb0H+uCB/1nWhaglE/uw9se23xzXrBd1CTdJtZv4gBH96nuVZYGvs2/2wx6HOQzmk5eT2qojLue0t6rDa2b9EixKppWDQl7KUaM1F0RdrpOTqNEbcac= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LTJeDMpmBZk701nBUGdtvJjgPV8bRUiB53ZgHhCinszoR/DMLI+7CxzuKFLsjhI1dopJy0MbcWUiMAJWAfTkqCVrXDZ9r9hgPrrDuksEsBDvU/ufu6Wl/J7CRlP/e0jfMj/5413tbydI1ZioHsViqFzQdHZVH2crgdfqtiPeffc=; X-YMail-OSG: wWdGoZAVM1meLUSW6AwN8SRs1k2fdzrEOcU_FHMTtqoBnce qV6pRvGHWL4qeML9T8S5OiNQtreRlJJWwdIl._cyTD7LsF56RhNuTjPEGv6K Nvq1I7mJOGlBKS3eP5WX0mrg.jp.MOErUWLJ15d2mMZz8ofcTgrt8F7XkO6J CVJLwc88jS5UaVF1XdnD8Otpadl_VtevNkPOhuOO6581JEjL4t.QpbW0LKpx tDhs0QFUJimOg524_NRtRRAbvtruoEpifpo7rnomA2vFG73bhXUJjcyXRaSU n86cBsBW61Q5Ar1OO.1amGY4_oG1wFIAqLUrfN2gPux85IWLKx699sShtycR _AcNzYWfgBuU2gglqSoEYW8i8DgFpctSx7NMEIhu7c5lNWgdNAUhv5.aAvIM QFFKhoJE0S1GVu_H7OzBGAava7.dnWXZX.Pv_9kM_fuPg7ouOh9lZBcEqaUU u_pDh6iijxToQkOSU9lDxBNTx1Fwnl2UF8EljglwjjXk6fwV5aSir6PQnFkd P8_pXXGdMalLJB7.zuzeX0tr0euFbRhNgVpTmL5aN_UOsrOF8Co5gWITiwzy e7747PXcrlhQ_kCtf4n2EJ5J3MOCmddBfWFFPPH91iBHWhfA5lwtkahRypNh lTC9erwbRlgEITj4hOr6yRRtMsiCif8rhjBq5uuBwjgbJeyUVsdUjpY0Bylm FoaWv2xE.hQElW9OarHGdbTe8LO0- Received: from [99.31.212.42] by web31807.mail.mud.yahoo.com via HTTP; Fri, 23 Nov 2012 08:58:24 PST X-Rocket-MIMEInfo: 001.001, U1JWIHJlY29yZHMgaGF2ZSBzZXZlcmFsIHByb2JsZW1zLCB0d28gYXJlOsKgIHRoZXkgYXJlIG5vdCB3aWRlbHkgZW5vdWdoIGFkb3B0ZWQgYW5kIG1hbnkgaG9zdGluZyBwcm92aWRlcnMgZG9uJ3Qgc3VwcG9ydCB0aGVtLCBhbmQgSlMgKGFuZCBvdGhlciBicm93c2VyIGJhc2VkIHNvbHV0aW9ucykgY2FuJ3QgbG9vayB0aGVtIHVwIHNvIHdlJ2QgbmVlZCBuZXcgY29kZSByb2xsZWQgb3V0IGluIGJyb3dzZXJzIHRvIG1ha2UgdGhlbSB1c2VmdWwuCgpTUlYgcmVjb3JkcyBhcmUgYSBncmVhdCBzb2x1dGlvbiABMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.127.475 References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> Message-ID: <1353689904.51388.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Fri, 23 Nov 2012 08:58:24 -0800 (PST) From: William Mills To: James M Snell , "Paul E. Jones" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-1105780149-1353689904=:51388" Cc: Nicholas Shanks , "" , "" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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: Fri, 23 Nov 2012 16:58:31 -0000 ---125733401-1105780149-1353689904=:51388 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable SRV records have several problems, two are:=C2=A0 they are not widely enoug= h adopted and many hosting providers don't support them, and JS (and other = browser based solutions) can't look them up so we'd need new code rolled ou= t in browsers to make them useful.=0A=0ASRV records are a great solution in= tellectually, but not practically at this time.=0A=0A-bill=0A=0A=0A=0A=0A= =0A>________________________________=0A> From: James M Snell =0A>To: Paul E. Jones =0A>Cc: Nicholas Shanks = ; "" ; "" =0A>Sent: Frida= y, November 23, 2012 8:51 AM=0A>Subject: Re: [apps-discuss] draft-ietf-apps= awg-webfinger-04=0A> =0A>=0A>At this point, I'd have to say that I'm not en= tirely convinced that the subdomain option is useful either but I'd need to= get some more direct implementation experience with this variation of the = spec to say for certain.=0A>=0A>=0A>The one variation on this that I've bee= n kicking around is the SRV option... e.g.=0A>=0A>=0A>=C2=A0_webfinger._htt= p.example.com. 86400 IN SRV 0 5 80 example.org.=0A>=0A>=0A>Essentially allo= wing the example.com to point to example.org as the location of it's WebFin= ger services. Obviously there are issues with this approach as well but I w= ould suspect that it's at least as viable as the subdomain approach (and ar= guably more flexible). That said, however, we could likely keep going aroun= d n around on possible viable solutions... at this point let's all just go = write some code for a bit and really see which approach works best.=0A>=0A>= =0A>- James=0A>=0A>=0A>=0A>On Fri, Nov 23, 2012 at 6:52 AM, Paul E. Jones <= paulej@packetizer.com> wrote:=0A>=0A>I corrected that for -05. Thanks!=0A>>= =0A>>Paul=0A>>=0A>>=0A>>=0A>>________________________________=0A>> From: Ni= cholas Shanks =0A>>Sent: Fri Nov 23 04:24:02 EST 2012= =0A>>To: "Paul E. Jones" =0A>>Cc: "" , "" =0A>>Subject: Re: [apps-discuss] draft-ietf-appsawg-webfin= ger-04=0A>>=0A>>=0A>>=0A>>The email client would take note of the "http://p= acketizer.com/rel/blog" link relation in the above JRD=0A>>=0A>>=0A>>Needs = amending. I also don't see any need for the subdomain.=0A>>=0A>>=E2=80=94 N= icholas.=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>On 22 Nov 2012, at 04:13, "Paul E. Jo= nes" wrote:=0A>>=0A>>=0A>>Folks,=0A>>>=C2=A0=0A>>>I= just posted a new draft that takes into consideration the input I received= on -03 and adds the =E2=80=9Cwebfinger=E2=80=9D subdomain that was discuss= ed on the list this past week.=C2=A0 Specifically, here=E2=80=99s what chan= ged:=0A>>>=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mention in= section 2 that WebFinger uses the =E2=80=9Crel=E2=80=9D attribute and prov= ide a reference to the IANA registry for link relations=0A>>>=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Deleted the second paragraph fro= m=C2=A0 section 3 that expands on link relations=0A>>>=C2=B7=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Changed the link relation value for =E2= =80=9Cblog=E2=80=9D to be just the token =E2=80=9Cblog=E2=80=9D=0A>>>=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Corrected a syntax error i= n the ex! ample in=0A4.1=0A>>>=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Clarified in section 4.1 what is meant by a =E2=80=9Cvalid alias= =E2=80=9D=0A>>>=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Intro= duced a new section 4.2 that shows an example for OpenID Connect=0A>>>=C2= =B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Changed the rel types i= n 4.3 and 4.4 to be URI-based (on example.net)=0A>>>=C2=B7=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Corrected syntax in 5.3 and added two cla= rifying sentences=0A>>>=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Introduced a new section 5.5 that describes the =E2=80=9Cwebfinger=E2= =80=9D subdomain=0A>>>=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Changed the name of section 7=0A>>>=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Added language to section 8 to support section 5.5=0A>>>= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Added language to se= ction 9 to support section 5.5=0A>>>=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Spells out Mike=E2=80=99s name as he prefers it=0A>>>=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Added a couple of informat= ional references=0A>>>=C2=A0=0A>>>The new draft is here:=0A>>>http://tools.= ietf.org/html/draft-ietf-appsawg-webfinger-04=0A>>>=C2=A0=0A>>>I think we= =E2=80=99re getting closer, though I know the =E2=80=9Cwebfinger=E2=80=9D s= ubdomain might be a bit controversial.=C2=A0 I=E2=80=99m on the fence on th= is one, myself.=C2=A0 I can see the pros and cons of having it.=C2=A0 I=E2= =80=99d prefer to stay out of the debate, though.=C2=A0 I=E2=80=99ll put in= to the document whatever the group says to put into the documents :-)=C2=A0= That said, I think Mike made a valid argument with respect to the fact tha= t some domain owners have no ability to do anything more than insert an A r= ecord for a subdomain.=0A>>>=C2=A0=0A>>>I do want to highlight the fact tha= t the current language says that if there is any response from a web server= at the host, that means the host does have the capability of providing WF = services and the=0A=E2=80=9Cwebfinger=E2=80=9D subdomain should not be cons= ulted.=C2=A0 Thus, the webfinger subdomain would only be consulted if there= is no web server running at the host at all.=C2=A0 It=E2=80=99s not a fall= back for domain owners who have a web server, but just didn=E2=80=99t insta= ll a WF server.=C2=A0 For that case, they should use 3xx redirection for ho= sting the WF server elsewhere.=0A>>>=C2=A0=0A>>>Paul=0A>>>=C2=A0=0A>>______= _________________________________________=0A>>>apps-discuss mailing list=0A= >>>apps-discuss@ietf.org=0A>>>https://www.ietf.org/mailman/listinfo/apps-di= scuss=0A>>>=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>=0A>_________________________________= ______________=0A>apps-discuss mailing list=0A>apps-discuss@ietf.org=0A>htt= ps://www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A> ---125733401-1105780149-1353689904=:51388 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
SRV recor= ds have several problems, two are:  they are not widely enough adopted= and many hosting providers don't support them, and JS (and other browser b= ased solutions) can't look them up so we'd need new code rolled out in brow= sers to make them useful.

SRV records are a great solution intellect= ually, but not practically at this time.

-bill


From: Ja= mes M Snell <jasnell@gmail.com>
To: Paul E. Jones <paulej@packetizer.com>
Cc: Nicholas Shanks <nickshanks@gmail.com= >; "<webfinger@googlegroups.com>" <webfinger@googlegroups.com&g= t;; "<apps-discuss@ietf.org>" <apps-discuss@ietf.org>
<= span style=3D"font-weight: bold;">Sent: Friday, November 23, 201= 2 8:51 AM
Subject: Re:= [apps-discuss] draft-ietf-appsawg-webfinger-04

At this point, I= 'd have to say that I'm not entirely convinced that the subdomain option is= useful either but I'd need to get some more direct implementation experien= ce with this variation of the spec to say for certain.
=0A=0A
The one variation on this= that I've been kicking around is the SRV option... e.g.
<= font face=3D"courier new, monospace">
 _webfinger._http.example= .com. 86400 IN SRV 0 5 80 example.org.
=0A=0A

Essentially allowing the example.com to point to example.org as the location of it's WebFinger services. Obviously= there are issues with this approach as well but I would suspect that it's = at least as viable as the subdomain approach (and arguably more flexible). = That said, however, we could likely keep going around n around on possible = viable solutions... at this point let's all just go write some code for a b= it and really see which approach works best.
=0A=0A
=
- James
=0A=0A


On Fri, Nov 23,= 2012 at 6:52 AM, Paul E. Jones <paulej@packetizer.com> wrote:
=0A=0A<= blockquote class=3D"yiv1004874702gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex;">
I corrected that for = -05. Thanks!
=0A
=0APaul

=0A
=0AFrom: Nicholas Shanks <nickshanks@gmail.com>
=0ASent: Fri Nov 23 04:24:0= 2 EST 2012
=0ATo: "Paul E. Jones" <paulej@packetizer.com>
=0ACc: "<apps-discuss@ietf.org>" <apps-discuss@ietf.org>, "<<= a rel=3D"nofollow" ymailto=3D"mailto:webfinger@googlegroups.com" target=3D"= _blank" href=3D"mailto:webfinger@googlegroups.com">webfinger@googlegroups.c= om>" <webfing= er@googlegroups.com>
=0A=0A=0ASubject: Re: [apps-discuss] = draft-ietf-appsawg-webfinger-04
=0A
= =0A
=0A
The email client = would take note of the=0A "http://packetizer.com/rel/blog" link relation in the above JRD
=0A
Needs amending. I also don't see any need for the subdomain.<=
/span>
=0A=0A
<=
font face=3D"Helvetica">
=E2=80=94 Nicholas.


=0A=0A

On 22 Nov 2012, at 04:13, "Paul E. Jones" <paulej@packetizer.com> wrote:

<= /div>
=0A=0A
Folks,
 
I just posted a new draft that takes= into consideration the input I received on -03 and adds the =E2=80=9Cwebfi= nger=E2=80=9D subdomain that was discussed on the list this past week. = ; Specifically, here=E2=80=99s what changed:
=0A=0A
=C2=B7  &= nbsp;      Mention in section= 2 that WebFinger uses the =E2=80=9Crel=E2=80=9D attribute and provide a re= ference to the IANA registry for link relations
=0A=0A
=C2=B7 &nbs= p;       Deleted the sec= ond paragraph from  section 3 that expands on link relations
=0A=0A=C2=B7         Changed the link relation value for =E2=80=9Cblog=E2=80=9D to be just th= e token =E2=80=9Cblog=E2=80=9D
=C2=B7    &nb= sp;    Corrected a syntax error in the = ex!=0A ample in=0A4.1
=C2=B7 &nbs= p;       Clarified in se= ction 4.1 what is meant by a =E2=80=9Cvalid alias=E2=80=9D
=0A=0A=
=C2=B7         = Introduced a new section 4.2 that shows an example for OpenID Connec= t
=C2=B7 &nb= sp;       Changed the re= l types in 4.3 and 4.4 to be URI-based (on example.net)
=0A=0A
=C2=B7 =         Corrected s= yntax in 5.3 and added two clarifying sentences
=C2=B7  &nbs= p;      Introduced a new sect= ion 5.5 that describes the =E2=80=9Cwebfinger=E2=80=9D subdomain
=0A= =0A
=C2=B7         Changed the name of section 7
=C2=B7     =     Added language to section 8 to supp= ort section 5.5
=0A=0A
= =C2=B7       = ; =0AAdded language to section 9 to support secti= on 5.5
=C2=B7         <= /span>Spells out Mike=E2=80=99s name as he prefers it
=0A=0A=C2=B7         Ad= ded a couple of informational references
 
=0A=0AThe new draft is here:
http://tools.ietf.o= rg/html/draft-ietf-appsawg-webfinger-04
=0A=0A
 
I think we=E2=80=99re getting closer, though I know the =E2=80=9Cwebfin= ger=E2=80=9D subdomain might be a bit controversial.  I=E2=80=99m on t= he fence on this one, myself.  I can see the pros and cons of having i= t.  I=E2=80=99d prefer to stay out of the debate, though.  I=E2= =80=99ll put into the document whatever the group says to put into the docu= ments :-)  That said, I think Mike made a valid argument with respect = to the fact that some domain owners have no ability to do anything more tha= n insert an A record for a subdomain.
=0A=0A
 
I do want to highlight the fact that the curre= nt language says that if there is any response from a web server at the hos= t, that means the host does have the capability of providing WF services an= d the=0A=E2=80=9Cwebfinger=E2=80=9D subdomain should not be consulted. = ; Thus, the webfinger subdomain would only be consulted if there is no web = server running at the host at all.  It=E2=80=99s not a fallback for do= main owners who have a web server, but just didn=E2=80=99t install a WF ser= ver.  For that case, they should use 3xx redirection for hosting the W= F server elsewhere.
=0A=0A
 
Paul
 
_____________= __________________________________
=0A=0Aapps-discuss maili= ng list
apps-disc= uss@ietf.org
https://www.ietf.or= g/mailman/listinfo/apps-discuss
=0A=0A

_______________________________________________
=0Aapp= s-discuss mailing list
=0Aapps= -discuss@ietf.org
=0Ahttps://www.ietf.org/mai= lman/listinfo/apps-discuss
=0A

=0A
_______________________________________________
apps-discuss mai= ling list
apps-discuss@ietf.org
https://www.ietf.org= /mailman/listinfo/apps-discuss


<= /div> ---125733401-1105780149-1353689904=:51388-- From internet-drafts@ietf.org Fri Nov 23 11:12: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 255BB21F8501; Fri, 23 Nov 2012 11:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 zLJcw78g7h1T; Fri, 23 Nov 2012 11:12:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D6321F84D2; Fri, 23 Nov 2012 11:11:40 -0800 (PST) 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.36 Message-ID: <20121123191140.16564.9991.idtracker@ietfa.amsl.com> Date: Fri, 23 Nov 2012 11:11:40 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-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, 23 Nov 2012 19:12:03 -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 : XML Media Types Author(s) : Chris Lilley MURATA Makoto Alexey Melnikov Henry S. Thompson Filename : draft-ietf-appsawg-xml-mediatypes-00.txt Pages : 35 Date : 2012-11-23 Abstract: This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. Major differences from [RFC3023] are alignment of charset handling for text/xml and text/xml-external-parsed-entity with application/ xml, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, mention of the XPointer Registry, and updating of many references. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Jones@microsoft.com Fri Nov 23 13:20: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 0533721F862C for ; Fri, 23 Nov 2012 13:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.968 X-Spam-Level: X-Spam-Status: No, score=-2.968 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 6CgKtHKalGtD for ; Fri, 23 Nov 2012 13:19:59 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 2727221F8629 for ; Fri, 23 Nov 2012 13:19:59 -0800 (PST) Received: from mail228-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Fri, 23 Nov 2012 21:19:58 +0000 Received: from mail228-ch1 (localhost [127.0.0.1]) by mail228-ch1-R.bigfish.com (Postfix) with ESMTP id 342278C0067; Fri, 23 Nov 2012 21:19:58 +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: -20 X-BigFish: VS-20(zz98dI9371I936eIc85fh148cIzz1de0h1202h1d1ah1d2ahzz8275ch1033IL177df4h17326ah8275bh8275dh18c673hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h15d0l1155h) Received-SPF: pass (mail228-ch1: 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 mail228-ch1 (localhost.localdomain [127.0.0.1]) by mail228-ch1 (MessageSwitch) id 1353705595837997_9875; Fri, 23 Nov 2012 21:19:55 +0000 (UTC) Received: from CH1EHSMHS020.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail228-ch1.bigfish.com (Postfix) with ESMTP id CA82220054; Fri, 23 Nov 2012 21:19:55 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 23 Nov 2012 21:19:55 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Fri, 23 Nov 2012 21:19:54 +0000 From: Mike Jones To: John Bradley , "webfinger@googlegroups.com" Thread-Topic: [apps-discuss] draft-ietf-appsawg-webfinger-04 Thread-Index: Ac3IZUHlvzxVCcoNRf2fQF9+Sjr6pwABFCwAAEUAuwAAD9pk4A== Date: Fri, 23 Nov 2012 21:19:53 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943668FD18F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943668FD18FTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 23 Nov 2012 21:20:04 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943668FD18FTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for writing this, John. It's important for people to understand tha= t this is a real problem - not a theoretical problem - and that the consequ= ences of not solving the problem in a practically implementable standards-b= ased manner could once again be deployment of a vendor-specific solution th= at locks out other participants. I'll be the first to say that I don't architecturally love the domain prefi= x solution. I described it in http://tools.ietf.org/html/draft-jones-simpl= e-web-discovery-04 and applaud Paul for including it in http://tools.ietf.o= rg/html/draft-ietf-appsawg-webfinger-04 because it will generate concrete d= iscussion on the best practical solutions to the problem. If people propos= e an alternative solution that is implementable on all modern Web developme= nt platforms today and usable in all existing web hosting environments that= has better properties than the domain prefix solution, I'd be great with t= hat. But as it is, we have at least one workable solution to the problem. By modern web development platforms, I would include at least all of JavaSc= ript, Ruby, PHP, Python, node.js, Java, .NET, Windows, OS X, iOS, Android, = and Windows Phone. While people have discussed the limitations of JavaScri= pt with respect to SRV records, any solution needs to work for all these en= vironments (and possibly more). Best wishes, -- Mike From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of John Bradley Sent: Friday, November 23, 2012 5:22 AM To: webfinger@googlegroups.com Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 Brad, In openID Yadis discovery, your employer Google did a back door deal with l= ibrary authors including JainRain to modify there openID librays to check = with Google to see if a domain is being served by Google apps for domains. = This essentially allows Google to hijack domains not served by Google apps= if they were to become evil. The perhaps even larger problem is that a specific hack for Gooole apps sup= port disenfranchised other potential multi tenant services. I don't imagine that you are advocating for another google proprietary solu= tion that will be retrofitted into Web Finger. The functionality to support multi tenant in a standard way has come from G= oogle and some other larger IdP. I am not saying that the subdomain method (similar provisioning to a apps c= ustomer creating mail.mydomain.com as a cname poi= nting to a hosting provider as is done now.) is the perfect solution. However a lot of people have been trying to come up with a simple way not t= o cut off millions of potential users. If you could ease off on the rhetoric and propose a better way to solve thi= s then people will be more than happy to consider it. My main concern is to not repeat what I consider to be a serious security p= roblem with openID 2 discovery introduced to support Google Apps. Regards John B. On 2012-11-22, at 5:26 AM, Brad Fitzpatrick > wrote: The new TOC doesn't even have a section 5.5. Is that how you hide controve= rsial stuff? :-) FWIW, I'm strongly opposed to the subdomain. It adds complexity. If you c= an't get your load balancing & routing act together, you don't get to play,= sorry. If it's easy for the small guys, and I've seen it be easy for the medium gu= ys, and multiple big guys have shown that it's possible, who's complaining?= (rhetorical. I didn't see when this first appeared, and don't really want= to know) I don't want incompetence and/or internal politics unnecessarily complicati= ng a spec that is supposed to be simple for clients. If we all compromise, nobody wins. Actually I'll go a step further and be = the dick here and say absolutely not. I'll fight for implementations that = I write (and those of others whom I can influence) to NOT to do the second = HTTP request (or, uh, 4th if you include https to http fallbacks on each ho= stname, ugh), rendering the webfinger subdomain very much not 1st tier and = therefore unreliable. I already know it'll end up as a forgotten wart in t= he spec, like HTTP/1.1 trailers or pipelining. I mean seriously: the DNS, listening & routing aren't rocket science today = and they weren't 10 years ago either. If you can't even get that right, wh= at are the odds you can get webfinger right? This Thanksgiving I am thankful for Paul putting up with all of us. Happy turkeys, Brad On Wed, Nov 21, 2012 at 8:13 PM, Paul E. Jones > wrote: Folks, I just posted a new draft that takes into consideration the input I receive= d on -03 and adds the "webfinger" subdomain that was discussed on the list = this past week. Specifically, here's what changed: * Mention in section 2 that WebFinger uses the "rel" attribute and = provide a reference to the IANA registry for link relations * Deleted the second paragraph from section 3 that expands on link= relations * Changed the link relation value for "blog" to be just the token "= blog" * Corrected a syntax error in the example in 4.1 * Clarified in section 4.1 what is meant by a "valid alias" * Introduced a new section 4.2 that shows an example for OpenID Con= nect * Changed the rel types in 4.3 and 4.4 to be URI-based (on example.= net) * Corrected syntax in 5.3 and added two clarifying sentences * Introduced a new section 5.5 that describes the "webfinger" subdo= main * Changed the name of section 7 * Added language to section 8 to support section 5.5 * Added language to section 9 to support section 5.5 * Spells out Mike's name as he prefers it * Added a couple of informational references The new draft is here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04 I think we're getting closer, though I know the "webfinger" subdomain might= be a bit controversial. I'm on the fence on this one, myself. I can see = the pros and cons of having it. I'd prefer to stay out of the debate, thou= gh. I'll put into the document whatever the group says to put into the doc= uments :-) That said, I think Mike made a valid argument with respect to t= he fact that some domain owners have no ability to do anything more than in= sert an A record for a subdomain. I do want to highlight the fact that the current language says that if ther= e is any response from a web server at the host, that means the host does h= ave the capability of providing WF services and the "webfinger" subdomain s= hould not be consulted. Thus, the webfinger subdomain would only be consul= ted if there is no web server running at the host at all. It's not a fallb= ack for domain owners who have a web server, but just didn't install a WF s= erver. For that case, they should use 3xx redirection for hosting the WF s= erver elsewhere. Paul --_000_4E1F6AAD24975D4BA5B1680429673943668FD18FTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for writing this, = John.  It’s important for people to understand that this is a re= al problem – not a theoretical problem – and that the consequen= ces of not solving the problem in a practically implementable standards-based = manner could once again be deployment of a vendor-specific solution that lo= cks out other participants.

 <= /p>

I’ll be the first t= o say that I don’t architecturally love the domain prefix solution.&n= bsp; I described it in = http://tools.ietf.org/html/draft-jones-simple-web-discovery-04 and appl= aud Paul for including it in http= ://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04 because it will = generate concrete discussion on the best practical solutions to the problem= .  If people propose an alternative solution that is implementable on all modern Web development platforms tod= ay and usable in all existing web hosting environments that has better prop= erties than the domain prefix solution, I’d be great with that. = But as it is, we have at least one workable solution to the problem.

 <= /p>

By modern web development= platforms, I would include at least all of JavaScript, Ruby, PHP, Python, = node.js, Java, .NET, Windows, OS X, iOS, Android, and Windows Phone.  While people have discussed the limitations of JavaScript wit= h respect to SRV records, any solution needs to work for all these environm= ents (and possibly more).

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Best wishes,

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

 <= /p>

From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley
Sent: Friday, November 23, 2012 5:22 AM
To: webfinger@googlegroups.com
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

 

Brad,

 

In openID Yadis discovery, your employer Google did = a back door deal with library authors including JainRain to modify there op= enID  librays to check with Google to see if a domain is being served = by Google apps for domains.  This essentially allows Google to hijack domains not served by Google apps if they were to = become evil.

 

The perhaps even larger problem is that a specific h= ack for Gooole apps support disenfranchised other potential multi tenant se= rvices.

 

I don't imagine that you are advocating for another = google proprietary solution that will be retrofitted into Web Finger.<= /o:p>

 

The functionality to support multi tenant in a stand= ard way has come from Google and some other larger IdP.

 

I am not saying that the subdomain method (similar p= rovisioning to a apps customer creating mail.mydomain.com as a cname point= ing to a hosting provider as is done now.) is the perfect solution.

 

However a lot of people have been trying to come up = with a simple way not to cut off millions of potential users.

 

If you could ease off on the rhetoric and propose a = better way to solve this then people will be more than happy to consider it= .

 

My main concern is to not repeat what I consider to = be a serious security problem with openID 2 discovery introduced to support= Google Apps.

 

Regards

John B.

 

On 2012-11-22, at 5:26 AM, Brad Fitzpatrick <bradfitz@google.com> wrote:<= /o:p>



The new TOC doesn't even have a section 5= .5.  Is that how you hide controversial stuff?  :-)

 

FWIW, I'm strongly opposed to the subdoma= in.  It adds complexity.  If you can't get your load balancing &a= mp; routing act together, you don't get to play, sorry.

 

If it's easy for the small guys, and I've= seen it be easy for the medium guys, and multiple big guys have shown that= it's possible, who's complaining?  (rhetorical. I didn't see when this first appeared, and don't really want to know)

 

I don't want incompetence and/o= r internal politics unnecessarily complicating a spec that is supposed to b= e simple for clients.

 

If we all compromise, nobody wins.  = Actually I'll go a step further and be the dick here and say absolutely not= .  I'll fight for implementations that I write (and those of others whom I can influence) to NOT to do the second HTTP request (or, uh,= 4th if you include https to http fallbacks on each hostname, ugh), renderi= ng the webfinger subdomain very much not 1st tier and therefore unreliable.=  I already know it'll end up as a forgotten wart in the spec, like HTTP/1.1 trailers or pipelining.

 

I mean seriously: the DNS, listening &= ; routing aren't rocket science today and they weren't 10 years ago either.=  If you can't even get that right, what are the odds you can get webfinger right?

 

This Thanksgiving I am thankful for Paul = putting up with all of us.

 

Happy turkeys,

Brad

 

 

On Wed, Nov 21, 2012 at 8:13 PM, Paul E. = Jones <paulej= @packetizer.com> wrote:

Folks,

 

I just posted a new draft that takes into consideration the input = I received on -03 and adds the “webfinger” subdomain that was d= iscussed on the list this past week.  Specifically, here’s what changed:

·         Mention in section 2 that WebFinger uses the “rel&#= 8221; attribute and provide a reference to the IANA registry for link relat= ions

·         Deleted the second paragraph from  section 3 that ex= pands on link relations

·         Changed the link relation value for “blog” to= be just the token “blog”

·         Corrected a syntax error in the example in 4.1=

·         Clarified in section 4.1 what is meant by a “valid = alias”

·         Introduced a new section 4.2 that shows an example for Op= enID Connect

·         Changed the rel types in 4.3 and 4.4 to be URI-based (on example.net)

·         Corrected syntax in 5.3 and added two clarifying sentence= s

·         Introduced a new section 5.5 that describes the “we= bfinger” subdomain

·         Changed the name of section 7

·         Added language to section 8 to support section 5.5

·         Added language to section 9 to support section 5.5

·         Spells out Mike’s name as he prefers it<= /span>

·         Added a couple of informational references

 

The new draft is here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfin= ger-04

 

I think we’re getting closer, though I know the “webfi= nger” subdomain might be a bit controversial.  I’m on the = fence on this one, myself.  I can see the pros and cons of having it.  I’d prefer to stay out of the debate, though.  I̵= 7;ll put into the document whatever the group says to put into the document= s :-)  That said, I think Mike made a valid argument with respect to t= he fact that some domain owners have no ability to do anything more than insert an A record for a subdomain.

 

I do want to highlight the fact that the current language says tha= t if there is any response from a web server at the host, that means the ho= st does have the capability of providing WF services and the “webfinger” subdomain should not be consul= ted.  Thus, the webfinger subdomain would only be consulted if there i= s no web server running at the host at all.  It’s not a fallback= for domain owners who have a web server, but just didn’t install a WF server.  For that case, they should use 3xx redirection for host= ing the WF server elsewhere.

 

Paul

 

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943668FD18FTK5EX14MBXC283r_-- From dick.hardt@gmail.com Fri Nov 23 14:19: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 4710921F84DE for ; Fri, 23 Nov 2012 14:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.793 X-Spam-Level: X-Spam-Status: No, score=-3.793 tagged_above=-999 required=5 tests=[AWL=-0.195, 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 vM0oXzjKYgwY for ; Fri, 23 Nov 2012 14:19:11 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74A2F21F84D2 for ; Fri, 23 Nov 2012 14:19:11 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so1311437dae.31 for ; Fri, 23 Nov 2012 14:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=qRAq0kaMxDAfdraUO7GeRS3Ks6FRPHg48Pw8Eq5BoWY=; b=mYlMf+ckGygscASvUVYR8DYRNhiSsRXhnTjQeNN8fS+Q6ZcrsIazevJV3401FyxD50 kNlYG0sN0oOGMla8gcA4s3IizGJG2RvTop5/W5YspFnhgcdcSxUUTHeDMjF+XS+joiBy JAKmnSO/jqVJA4c+XgVUxSRgaq3jqUghYalE7auXBH6GVkF4vO4EIwKbGjejidloIKDX bFuILaYQ717vG5krFsueHUS21Xlu7mq1x2BxIxta0Q/XWAg+SF3FNeXXWcmF/8F6ahCf 1ATYfnUAUcPdVBbRWOvx2QL3pBabvpju0M9ZJxtzd98zUaO4zeWyxU9LQXaCSLJLi5sd VSGA== Received: by 10.66.73.227 with SMTP id o3mr13471458pav.78.1353709150990; Fri, 23 Nov 2012 14:19:10 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id un16sm4397114pbc.47.2012.11.23.14.19.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Nov 2012 14:19:10 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_91366DA6-BE00-4FF9-BCA0-7C0A2B39B66F" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Fri, 23 Nov 2012 14:19:07 -0800 Message-Id: References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943668FD18F@TK5EX14MBXC283.redmond.corp.microsoft.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 23 Nov 2012 22:19:12 -0000 --Apple-Mail=_91366DA6-BE00-4FF9-BCA0-7C0A2B39B66F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Brad The problem was not discussed on the list. The relevant part of the SWD = document is below Myself, I would like to be pointed to real world examples as I don't = appreciate the issue yet. -- Dick 2.1. "simple-web-discovery" Subdomain It may be difficult or impossible for some domains wanting to support SWD requests to make an SWD server available for their domain at the path "/.well-known/simple-web-discovery". For instance, in the case of hosted domains, no web server may be running on the domain host at all. For that reason, SWD servers for a domain MAY be located on a specific subdomain of that domain: "simple-web-discovery". For example, the SWD server for the domain "example.com" MAY be located at the URI "https://simple-web-discovery.example.com/.well-known/simp le-web-discovery". Jones & Goland Expires May 9, 2013 [Page 4] =20 Internet-Draft Simple Web Discovery (SWD) November 2012 SWD clients MUST first attempt to make an SWD request to the domain's "/.well-known/simple-web-discovery" endpoint, and then if that fails, they MUST then attempt to make the request to the SWD endpoint at the "simple-web-discovery" subdomain for the domain. On Nov 23, 2012, at 2:09 PM, Brad Fitzpatrick = wrote: > On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones = wrote: > Thanks for writing this, John. It=92s important for people to = understand that this is a real problem =96 not a theoretical problem =96 = and that the consequences of not solving the problem in a practically = implementable standards-based manner could once again be deployment of a = vendor-specific solution that locks out other participants. >=20 >=20 > What's the problem? >=20 > I missed some emails, if there were any about this. Is there = discussion happening on a mailing list other than apps-discuss and/or = webfinger@googlegroups.com? >=20 > We already have the /.well-known/ thing, so why do we need a = well-known subdomain? >=20 > The way I see it is: >=20 > a) If you're aren't running a webserver on the hostname =3D> run one, = and respond to /.well-known/webfinger > b) If you are running a webserver on the hostname =3D> respond to = /.well-known/webfinger >=20 > We need to make things easier for clients, not easier for servers. = There will many more clients than servers, so it needs to be hard to get = wrong, if we want people to do the right thing. >=20 > Let's imagine that the "webfinger" subdomain goes into the spec, but = no major webfinger server uses it. So now we have 99% of webfinger = client applications (many in JavaScript) only implementing the base case = and ignoring the subdomain lookup, because it always works as far as = they're concerned. Now new servers have no choice but to respond at = host.com/.well-known/webfinger because most clients won't work = otherwise. That's where I fear this is all heading: because of a = misguided desired to make things easier for some hypothetical server = authors, we then make things complicated for everybody, even though we = gain nothing. >=20 > When you have more clients than servers, I think it's important to = make things simple for clients. >=20 --Apple-Mail=_91366DA6-BE00-4FF9-BCA0-7C0A2B39B66F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Brad

The problem was not discussed on the = list. The relevant part of the SWD document is = below

Myself, I would like to be pointed to = real world examples as I don't appreciate the issue = yet.

-- Dick

2.1.  =
"simple-web-discovery" Subdomain


   It may be difficult or impossible for some domains wanting to support
   SWD requests to make an SWD server available for their domain at the
   path "/.well-known/simple-web-discovery".  For instance, in the case
   of hosted domains, no web server may be running on the domain host at
   all.

   For that reason, SWD servers for a domain MAY be located on a
   specific subdomain of that domain: "simple-web-discovery".  For
   example, the SWD server for the domain "example.com" MAY be located
   at the URI "https:/=
/simple-web-discovery.example.com/.well-known/simp
   le-web-discovery".



Jones & =
Goland             Expires May 9, 2013                  [Page 4]

 
Internet-Draft =
        Simple Web Discovery (SWD)          November 2012


   SWD clients MUST first attempt to make an SWD request to the domain's
   "/.well-known/simple-web-discovery" endpoint, and then if that fails,
   they MUST then attempt to make the request to the SWD endpoint at the
   "simple-web-discovery" subdomain for the =
domain.



=
On Nov 23, 2012, at 2:09 PM, Brad Fitzpatrick <bradfitz@google.com> = wrote:

On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for writing this, John.  It=92s = important for people to understand that this is a real problem =96 not a = theoretical problem =96 and that the consequences of not solving the problem in a practically implementable = standards-based manner could once again be deployment of a = vendor-specific solution that locks out other = participants.


What's the problem?

I missed some = emails, if there were any about this.  Is there discussion = happening on a mailing list other than apps-discuss and/or webfinger@googlegroups.com?=

We already have the /.well-known/ thing, so why do = we need a well-known subdomain?

The way I see = it is:

a) If you're aren't running a webserver = on the hostname =3D> run one, and respond to = /.well-known/webfinger
b) If you are running a webserver on the hostname =3D> respond = to /.well-known/webfinger

We need to make = things easier for clients, not easier for servers.  There will many = more clients than servers, so it needs to be hard to get wrong, if we = want people to do the right thing.

Let's imagine that the "webfinger" subdomain goes = into the spec, but no major webfinger server uses it.  So now we = have 99% of webfinger client applications (many in JavaScript) only = implementing the base case and ignoring the subdomain lookup, because it = always works as far as they're concerned.  Now new servers have no = choice but to respond at host.com/.well-known/webfin= ger because most clients won't work otherwise.  That's where I = fear this is all heading:  because of a misguided desired to make = things easier for some hypothetical server authors, we then make things = complicated for everybody, even though we gain nothing.

When you have more clients than servers, I think = it's important to make things simple for = clients.


= --Apple-Mail=_91366DA6-BE00-4FF9-BCA0-7C0A2B39B66F-- From romeda@gmail.com Fri Nov 23 14:39: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 4B04121F8543 for ; Fri, 23 Nov 2012 14:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.491 X-Spam-Level: X-Spam-Status: No, score=-103.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, 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 6g2GptXQv+80 for ; Fri, 23 Nov 2012 14:39:25 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD3E21F84DB for ; Fri, 23 Nov 2012 14:39:25 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so4712279pad.31 for ; Fri, 23 Nov 2012 14:39:25 -0800 (PST) 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=40RvXnXYyzdqRngkbEsDGeajwmKRgpBaY9+3uBGF0ks=; b=kDG/+C4hWXn1lSJiEsfweXJlIVz5IpQEi2zLRW7oKNX5GL52XtMA9UFgcLALo8XEXj eHQJXr1JapiXf7mzmXXNm94AmmpNEsZ9pothvi7yrvNuJ18MbZTo9KalfiLCz0Zpyc31 0ZkvyrHu4YM6vLWq94Fat73oa07peQBzQUvBChg0UhAg0Z0L6UevGCKpM8aPdoQ1Q83+ W7d17KYpRp9dNAu8gS3jbla1QKujrjWfmqCyylG5/on1MZPhY/gwfMJY7VaJTV42gRcV BI0xKXoPsqqhQ0RqUiXW6d3A/9dNQWeTi4OHe0bRp1KCgdc8v0b0/ThjvywkXjppfGIt Lxzg== Received: by 10.68.219.164 with SMTP id pp4mr17654918pbc.72.1353710364956; Fri, 23 Nov 2012 14:39:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.67.2.101 with HTTP; Fri, 23 Nov 2012 14:39:04 -0800 (PST) In-Reply-To: References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943668FD18F@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Blaine Cook Date: Fri, 23 Nov 2012 22:39:04 +0000 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8ff24a376e997a04cf31418d Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 23 Nov 2012 22:39:26 -0000 --e89a8ff24a376e997a04cf31418d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to this new draft, and +1 to Brad's comments on the draft =E2=80=93 I, t= oo, think the subdomain introduces unnecessary complexity on the client in deference to seemingly unspecified servers that can't (apparently) run web servers. b. On 23 November 2012 22:31, Brad Fitzpatrick wrote: > Okay, glad I didn't miss anything. Section 2.1 of SWD doesn't explain the > problem: for some reason, running a webserver "may be difficult or > impossible", so it pushes complexity to clients instead. > > > On Fri, Nov 23, 2012 at 2:19 PM, Dick Hardt wrote: > >> Hi Brad >> >> The problem was not discussed on the list. The relevant part of the SWD >> document is below >> >> Myself, I would like to be pointed to real world examples as I don't >> appreciate the issue yet. >> >> -- Dick >> >> >> 2.1 . "simple-web-discovery" Subdomain >> >> >> It may be difficult or impossible for some domains wanting to support >> SWD requests to make an SWD server available for their domain at the >> path "/.well-known/simple-web-discovery". For instance, in the case >> of hosted domains, no web server may be running on the domain host at >> all. >> >> For that reason, SWD servers for a domain MAY be located on a >> specific subdomain of that domain: "simple-web-discovery". For >> example, the SWD server for the domain "example.com" MAY be located >> at the URI "https://simple-web-discovery.example.com/.well-known/simp >> le-web-discovery". >> >> >> Jones & Goland Expires May 9, 2013 [Page 4] >> >> Internet-Draft Simple Web Discovery (SWD) November 2012 >> >> >> SWD clients MUST first attempt to make an SWD request to the domain's >> "/.well-known/simple-web-discovery" endpoint, and then if that fails, >> they MUST then attempt to make the request to the SWD endpoint at the >> "simple-web-discovery" subdomain for the domain. >> >> >> >> >> On Nov 23, 2012, at 2:09 PM, Brad Fitzpatrick >> wrote: >> >> On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones wrote: >> >>> Thanks for writing this, John. It=E2=80=99s important for people to >>> understand that this is a real problem =E2=80=93 not a theoretical prob= lem =E2=80=93 and >>> that the consequences of not solving the problem in a practically >>> implementable standards-based manner could once again be deployment of = a >>> vendor-specific solution that locks out other participants. >>> >> >> What's the problem? >> >> I missed some emails, if there were any about this. Is there discussion >> happening on a mailing list other than apps-discuss and/or >> webfinger@googlegroups.com? >> >> We already have the /.well-known/ thing, so why do we need a well-known >> subdomain? >> >> The way I see it is: >> >> a) If you're aren't running a webserver on the hostname =3D> run one, an= d >> respond to /.well-known/webfinger >> b) If you are running a webserver on the hostname =3D> respond to >> /.well-known/webfinger >> >> We need to make things easier for clients, not easier for servers. Ther= e >> will many more clients than servers, so it needs to be hard to get wrong= , >> if we want people to do the right thing. >> >> Let's imagine that the "webfinger" subdomain goes into the spec, but no >> major webfinger server uses it. So now we have 99% of webfinger client >> applications (many in JavaScript) only implementing the base case and >> ignoring the subdomain lookup, because it always works as far as they're >> concerned. Now new servers have no choice but to respond at >> host.com/.well-known/webfinger because most clients won't work >> otherwise. That's where I fear this is all heading: because of a >> misguided desired to make things easier for some hypothetical server >> authors, we then make things complicated for everybody, even though we g= ain >> nothing. >> >> When you have more clients than servers, I think it's important to make >> things simple for clients. >> >> >> > --e89a8ff24a376e997a04cf31418d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to this new draft, and +1 to Brad's comments on the draft =E2=80=93 = I, too, think the subdomain introduces unnecessary complexity on the client= in deference to seemingly unspecified servers that can't (apparently) = run web servers.

b.


On 23 November 2012 22:31, Brad Fitzpatrick <bradf= itz@google.com> wrote:
Okay, glad I didn't miss anything. Section 2.1= of SWD doesn't explain the problem: for some reason, running a webserv= er "may be difficult or impossible", so it pushes complexity to c= lients instead.=C2=A0


On Fri, Nov 23, 2012 at 2:19 P= M, Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Brad

The problem = was not discussed on the list.=C2=A0The relevant part of the SWD document i= s below

Myself, I would like to be pointed to real= world examples as I don't appreciate the issue yet.

-- Dick




2.1.  "simple-web-disc=
overy" Subdomain





   It may be difficult or impossible for some domains wanting to support
   SWD requests to make an SWD server available for their domain at the
   path "/.well-known/simple-web-discovery".  For instance, in th=
e case
   of hosted domains, no web server may be running on the domain host at
   all.

   For that reason, SWD servers for a domain MAY be located on a
   specific subdomain of that domain: "simple-web-discovery".  Fo=
r
   example, the SWD server for the domain "example.com" MAY be located
   at the URI "https://simple-web-discovery.example.com/.=
well-known/simp
   le-web-discovery".



Jones & Goland             Expir=
es May 9, 2013                  [Page 4]

 
Internet-Draft         Simple Web Di=
scovery (SWD)          November 2012


   SWD clients MUST first attempt to make an SWD request to the domain'=
s
   "/.well-known/simple-web-discovery" endpoint, and then if that=
 fails,
   they MUST then attempt to make the request to the SWD endpoint at the
   "simple-web-discovery" subdomain for the domain.


On Nov = 23, 2012, at 2:09 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:

On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for writing t= his, John.=C2=A0 It=E2=80=99s important for people to understand that this = is a real problem =E2=80=93 not a theoretical problem =E2=80=93 and that th= e consequences of not solving the problem in a practically implementable standards-based = manner could once again be deployment of a vendor-specific solution that lo= cks out other participants.


What's the problem?

I missed some e= mails, if there were any about this. =C2=A0Is there discussion happening on= a mailing list other than=C2=A0apps-discuss and/or webfinger@googlegroups.com?

We already have the /.well-known/ thing, so why do we n= eed a well-known subdomain?

The way I see it is:

a) If you're aren't running a webserver on = the hostname =3D> run one, and respond to /.well-known/webfinger
b) If you are running a webserver on the hostname =3D> respond to /= .well-known/webfinger

We need to make things easie= r for clients, not easier for servers. =C2=A0There will many more clients t= han servers, so it needs to be hard to get wrong, if we want people to do t= he right thing.

Let's imagine that the "webfinger" subdom= ain goes into the spec, but no major webfinger server uses it. =C2=A0So now= we have 99% of webfinger client applications (many in JavaScript) only imp= lementing the base case and ignoring the subdomain lookup, because it alway= s works as far as they're concerned. =C2=A0Now new servers have no choi= ce but to respond at host.com/.well-known/webfinger because most clients won&#= 39;t work otherwise. =C2=A0That's where I fear this is all heading: =C2= =A0because of a misguided desired to make things easier for some hypothetic= al server authors, we then make things complicated for everybody, even thou= gh we gain nothing.

When you have more clients than servers, I think it'= ;s important to make things simple for clients.

<= /div>



--e89a8ff24a376e997a04cf31418d-- From tbray@textuality.com Fri Nov 23 17:34: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 9938B21F85AB for ; Fri, 23 Nov 2012 17:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.646, 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 zRAxLcwvUNGd for ; Fri, 23 Nov 2012 17:34:08 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3723321F8583 for ; Fri, 23 Nov 2012 17:34:08 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so10279939obb.31 for ; Fri, 23 Nov 2012 17:34:07 -0800 (PST) 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=VYO8EoxysWTO4zUAdLgSxjbeMzkoHWnOBREDlxV4Szc=; b=T/OlrtroLCHMNbJnAIIQ6xKxtwLAiajY86qGYA8wwIx1eth1f51oPKj2CTo0x/3fMN xul7yrVgxdKSvg2jcKJ/fRqZLX1mgaHebtLw09Da0M614pRTZLqhrI4KNK5sHQJqSRY9 U7t+c5xz4VsplB6uNGvoa6peUYxXCfVXFYT5jhsiBES19mDwn+T5XWc0RCqbcQedZvag Bq2BdpV81U+iAVwQ2Vs0pgRy76l6ydtHTc4Pq+rw8V4jxYqBdtGw0NoK+qs9ofPpwJG6 dl43R3VDW75kw9oau8/+CjrVSZjxemffLtqumW11Shfsi0jzGMIgS+6wi2u1ymTP7Of9 7glA== MIME-Version: 1.0 Received: by 10.60.10.133 with SMTP id i5mr4125464oeb.24.1353720846913; Fri, 23 Nov 2012 17:34:06 -0800 (PST) Received: by 10.76.12.134 with HTTP; Fri, 23 Nov 2012 17:34:06 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <013e01cdc867$caf54230$60dfc690$@packetizer.com> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> Date: Fri, 23 Nov 2012 17:34:06 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkd1ceSjwpVmNTfHEKUXfcFSxaLF5SF7F89cep+V5vXLSWKISqSAvaB1WCDSoe80sus+bw8 Cc: webfinger@googlegroups.com, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 24 Nov 2012 01:34:09 -0000 Notes on draft-ietf-appsawg-webfinger-04.txt Sorry for coming late to the party. This the first webfinger draft that I=92ve ever read, and I=92m almost completely ignorant of the history. Having said that, sometimes a history-free pair of eyes looking at something can add value. [1. Introduction. ] Suggest shortening up, omitting the history, losing the whole first para and beginning the second =93Webfinger uses the HTTP protocol to retrieve a structured document containing link relations that describe people or other entities on the Internet. For a person... [para 2] =93direct human consumption (e.g., looking up someone=92s phone number), or...=94 [4. Example use of WebFinger] Tighten up 1st sentence: =93This section shows a few sample uses of Webfinger.=94 [4.1 Locating a User's Blog] What is the benefit of the =93aliases=94 field? What is the benefit of the =93acct=94 URI scheme? Couldn=92t =93mailto:=94= have been used in this case? [4.2 Identity Provider Discovery...] Since the =93rel=94 parameter is optional and you can=92t count on it, providing it is strictly a client-suggested optimization? Feels quite likely to be premature, to me. In particular, I=92m thinking of my own small-scale domains like textuality.com and tbray.org, which have a single-digit number of accounts. I could drop static JRD files into a small number of files with names like /.well-known/webfinger?resource=3Dmailto:tbray@textuality.com and do webfinger very cheaply. The existence of the =93rel=94 parameter means I can=92t solve this problem statically. [4.4 Retrieving Device Information] I have to say this feels fanciful. Any time an example requires inventing a new URI scheme, I suggest that=92s a symptom of trying too hard. [5.1, first para] I hate to be pedantic, but when you say =93parameter=94, you=92re talking about the &-separated name-value pairs in the =93query=94 [RFC3986] part of a URI. Fine enough, and it=92s a common usage, but I don=92t actually know where it's defined (not in 3986) so either we need to find a definition and link to it, or invest a paragraph in saying what you mean [5.1] =93WebFinger servers MUST return JRD documents as the default representation...=94 What does =93default=94 mean? Are we saying that servers MUST return JRD? If so, say so. [5.1] Last two paragraphs are perhaps superfluous? Since it=92s HTTP, don=92t you get this for free? [5.2] =93Any array elements within the "links" array are presented by the server in order of preference.=94 Huh? Don't understand. [5.2] =93The "template" element is forbidden=93? Huh? The spec doesn=92t define any semantic for this element. You probably need a policy on unknown fields. For example: (a) =93Software must ignore any fields found in the JRD which are not specified here=94 (a.k.a. MUST_IGNORE) (b) =93It is forbidden for any elements not specified here to appear in a JRD=93 (a.k.a. maximally brittle) The special processing for =93template=94 is just weird. If it=92s require= d for some good reason, give the reason. [5.2] The fact that =93titles=94 is allowed but has no specified semantics is troublesome. Explain or remove? [5.2] The fact there is no discussion of what you might use =93properties=94 for, nor any discussion of its structure, is troublesome. Do we have actual users of this? Explain or remove? [5.3] =93The purpose of the "rel" parameter is to return a subset of resource's link relations. It is not intended to reduce the work=94 Could this be motivated a bit? Why would you want a subset, aside from reducing the work? [5.3] The restated example doesn=92t really add value here, I think. How the =93rel=94 parameter works is simple enough. [5.4] Two problems: First, this section fails to convince me that the =93acct=94 scheme is worth the effort. Second, the section could simply say that the URI used to identify the entity being queried is not tied to any scheme; the arm-waving about the hypothetical wonderfulnesss of =93acct:=94 is a waste of space. Then having done that, the section could be replaced by a one-line note in section 5.1 [5.5] Really? Do we have any hard data that convinces us that there=92s an interesting class of organizations that (a) want to offer WebFinger and (b) can=92t access their root and (c) can easily set up a subdomain? [6] =93Enterprise=94?! What does that word mean? Also there=92s a contradiction between the sentence saying you have to use =93*=94 and the next paragraph saying something more restrictive is OK. Might it be better to just say =93WebFinger may not be usable from code running in browsers due to Origin policies; therefore, the use of CORS headers is required. The header =93Access-Control-Allow-Origin: * =94 will maximize usability; certain organizations may wish to control access to WebFinger with a more restrictive Access-Control-Allow-Origin value. [7. Access Control] This section could be dropped, or replaced with a short paragraph noting that since WebFinger is based on HTTP, implementors will need to deal with the possibility that the origin server may impose access control policies or simply refuse access. [8.] This section could be dropped. This is an HTTP-based service and we can assume that implementors should be prepared to handle HTTP-standard redirect semantics. The caution about not redirecting to a /.well-known somewhere else seems of questionable value, since I might actually want to have a common webfinger which returns the same values for any X whether it's X@example.com, X@example.net, or whatever, and I could do that efficiently by having a /.well-known on one of them and redirecting to it from the others. On Wed, Nov 21, 2012 at 8:13 PM, Paul E. Jones wrot= e: > Folks, > > > > I just posted a new draft that takes into consideration the input I recei= ved > on -03 and adds the =93webfinger=94 subdomain that was discussed on the l= ist > this past week. Specifically, here=92s what changed: > > =B7 Mention in section 2 that WebFinger uses the =93rel=94 attrib= ute and > provide a reference to the IANA registry for link relations > > =B7 Deleted the second paragraph from section 3 that expands on = link > relations > > =B7 Changed the link relation value for =93blog=94 to be just the= token > =93blog=94 > > =B7 Corrected a syntax error in the example in 4.1 > > =B7 Clarified in section 4.1 what is meant by a =93valid alias=94 > > =B7 Introduced a new section 4.2 that shows an example for OpenID > Connect > > =B7 Changed the rel types in 4.3 and 4.4 to be URI-based (on > example.net) > > =B7 Corrected syntax in 5.3 and added two clarifying sentences > > =B7 Introduced a new section 5.5 that describes the =93webfinger= =94 > subdomain > > =B7 Changed the name of section 7 > > =B7 Added language to section 8 to support section 5.5 > > =B7 Added language to section 9 to support section 5.5 > > =B7 Spells out Mike=92s name as he prefers it > > =B7 Added a couple of informational references > > > > The new draft is here: > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04 > > > > I think we=92re getting closer, though I know the =93webfinger=94 subdoma= in might > be a bit controversial. I=92m on the fence on this one, myself. I can s= ee > the pros and cons of having it. I=92d prefer to stay out of the debate, > though. I=92ll put into the document whatever the group says to put into= the > documents :-) That said, I think Mike made a valid argument with respect= to > the fact that some domain owners have no ability to do anything more than > insert an A record for a subdomain. > > > > I do want to highlight the fact that the current language says that if th= ere > is any response from a web server at the host, that means the host does h= ave > the capability of providing WF services and the =93webfinger=94 subdomain= should > not be consulted. Thus, the webfinger subdomain would only be consulted = if > there is no web server running at the host at all. It=92s not a fallback= for > domain owners who have a web server, but just didn=92t install a WF serve= r. > For that case, they should use 3xx redirection for hosting the WF server > elsewhere. > > > > Paul > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From tbray@textuality.com Fri Nov 23 22:32: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 9222D21F8443 for ; Fri, 23 Nov 2012 22:32:51 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WPes0imkTVg for ; Fri, 23 Nov 2012 22:32:49 -0800 (PST) Received: from mail-yh0-f64.google.com (mail-yh0-f64.google.com [209.85.213.64]) by ietfa.amsl.com (Postfix) with ESMTP id BAE7121F86AB for ; Fri, 23 Nov 2012 22:32:49 -0800 (PST) Received: by mail-yh0-f64.google.com with SMTP id n12so1456692yhn.19 for ; Fri, 23 Nov 2012 22:32:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-google-doc-id:x-google-web-client:date:from:to:cc:message-id :in-reply-to:references:subject:mime-version:content-type :x-google-token:x-google-ip:x-gm-message-state; bh=eM+mf86CU3SJCpsqTgX9lNdYuJ2EsD7XGAxGRDPWN34=; b=oOgxwVExnSLv+EGXQ0r/knE1N6Op0EM/W/eqdvazPJA6eZ+aVM2syEhWKBSETv672A VlihnEzpzxIcYNJeI2sIZD7GOB7QTGrhWE4idsLa2ZycTh2IZnc65T9ISoek9cBtBTGc whiNCM8dqXBL3mAWsjcTi+YynM6WZdsOLdWZ/IOJk5w4RuenBmwUPuY2sJNwrbntE2q5 huFdYwPhK5c9a70DxXIFKLSR5lIRrYjRQdviwK0rNSBfKtPFv3meb1S80miu6aoNhmQJ gmHvoapPqcLlDNkqJhQef20gp2xoTQbSSnTvgXNrHz4Yq6mXHJcwseYfycx5YScKYY/0 7M5w== Received: by 10.50.12.169 with SMTP id z9mr1453905igb.1.1353738768115; Fri, 23 Nov 2012 22:32:48 -0800 (PST) X-Google-Doc-Id: af1b6c6f01e215c4 X-Google-Web-Client: true Date: Fri, 23 Nov 2012 22:32:47 -0800 (PST) From: Tim Bray To: webfinger@googlegroups.com Message-Id: <3c86d465-fb09-416a-aa11-7ac7af1fd3fa@googlegroups.com> In-Reply-To: <013e01cdc867$caf54230$60dfc690$@packetizer.com> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_193_15684827.1353738767484" X-Google-Token: EI_UwYUFPk6CHYXeQyo0 X-Google-IP: 24.84.235.32 X-Gm-Message-State: ALoCoQmEudjVoxzeXIbOI+hMA5OLGF95hi4FvazOV8TRCNG5Lb6OH+W3AnfJIgOhsc2vE2GXD+Dv Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 24 Nov 2012 06:32:51 -0000 ------=_Part_193_15684827.1353738767484 Content-Type: multipart/alternative; boundary="----=_Part_194_11284163.1353738767484" ------=_Part_194_11284163.1353738767484 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oops, I replied to this but hadn=E2=80=99t bothered to join the mailing lis= t first,=20 so it bounced. Here it is again: Notes on draft-ietf-appsawg-webfinger-04.txt Sorry for coming late to the party. This the first webfinger draft that=20 I=E2=80=99ve ever read, and I=E2=80=99m almost completely ignorant of the h= istory. Having=20 said that, sometimes a history-free pair of eyes looking at something can= =20 add value. [1. Introduction. ] Suggest shortening up, omitting the history, losing the whole first para=20 and beginning the second =E2=80=9CWebfinger uses the HTTP protocol to retri= eve a=20 structured document containing link relations that describe people or other= =20 entities on the Internet. For a person... [para 2] =E2=80=9Cdirect human consumption (e.g., looking up someone=E2=80= =99s phone=20 number), or...=E2=80=9D [4. Example use of WebFinger] Tighten up 1st sentence: =E2=80=9CThis sectio= n shows=20 a few sample uses of Webfinger.=E2=80=9D [4.1 Locating a User's Blog] What is the benefit of the =E2=80=9Caliases=E2= =80=9D field? What is the benefit of the =E2=80=9Cacct=E2=80=9D URI scheme? Couldn=E2=80= =99t =E2=80=9Cmailto:=E2=80=9D have been=20 used in this case? [4.2 Identity Provider Discovery...] Since the =E2=80=9Crel=E2=80=9D parameter is optional and you can=E2=80=99t= count on it, providing=20 it is strictly a client-suggested optimization? Feels quite likely to be= =20 premature, to me. In particular, I=E2=80=99m thinking of my own small-scale domains like=20 textuality.com and tbray.org, which have a single-digit number of accounts.= =20 I could drop static JRD files into a small number of files with names like= =20 /.well-known/webfinger?resource=3Dmailto:tbray@textuality.com and do=20 webfinger very cheaply. The existence of the =E2=80=9Crel=E2=80=9D paramete= r means I can=E2=80=99t=20 solve this problem statically. [4.4 Retrieving Device Information] I have to say this feels fanciful. Any time an example requires inventing a= =20 new URI scheme, I suggest that=E2=80=99s a symptom of trying too hard. [5.1, first para] I hate to be pedantic, but when you say =E2=80=9Cparameter=E2=80=9D, you=E2= =80=99re talking about=20 the &-separated name-value pairs in the =E2=80=9Cquery=E2=80=9D [RFC3986] p= art of a URI.=20 Fine enough, and it=E2=80=99s a common usage, but I don=E2=80=99t actually= know where it's=20 defined (not in 3986) so either we need to find a definition and link to=20 it, or invest a paragraph in saying what you mean [5.1] =E2=80=9CWebFinger servers MUST return JRD documents as the default= =20 representation...=E2=80=9D What does =E2=80=9Cdefault=E2=80=9D mean? Are w= e saying that servers=20 MUST return JRD? If so, say so. [5.1] Last two paragraphs are perhaps superfluous? Since it=E2=80=99s HTTP= , don=E2=80=99t=20 you get this for free? [5.2] =E2=80=9CAny array elements within the "links" array are presented by= the=20 server in order of preference.=E2=80=9D Huh? Don't understand. [5.2] =E2=80=9CThe "template" element is forbidden=E2=80=9C? Huh? The spe= c doesn=E2=80=99t define=20 any semantic for this element. You probably need a policy on unknown=20 fields. For example: (a) =E2=80=9CSoftware must ignore any fields found in the JRD which are not= =20 specified here=E2=80=9D (a.k.a. MUST_IGNORE) (b) =E2=80=9CIt is forbidden for any elements not specified here to appear = in a=20 JRD=E2=80=9C (a.k.a. maximally brittle) The special processing for =E2=80=9Ctemplate=E2=80=9D is just weird. If it= =E2=80=99s required for=20 some good reason, give the reason. [5.2] The fact that =E2=80=9Ctitles=E2=80=9D is allowed but has no specifie= d semantics is=20 troublesome. Explain or remove? [5.2] The fact there is no discussion of what you might use =E2=80=9Cproper= ties=E2=80=9D=20 for, nor any discussion of its structure, is troublesome. Do we have=20 actual users of this? Explain or remove? [5.3] =E2=80=9CThe purpose of the "rel" parameter is to return a subset of= =20 resource's link relations. It is not intended to reduce the work=E2=80=9D = Could=20 this be motivated a bit? Why would you want a subset, aside from reducing= =20 the work? [5.3] The restated example doesn=E2=80=99t really add value here, I think. = How the=20 =E2=80=9Crel=E2=80=9D parameter works is simple enough. [5.4] Two problems: First, this section fails to convince me that the=20 =E2=80=9Cacct=E2=80=9D scheme is worth the effort. Second, the section coul= d simply say=20 that the URI used to identify the entity being queried is not tied to any= =20 scheme; the arm-waving about the hypothetical wonderfulnesss of =E2=80=9Cacct:=E2=80=9D is a waste of space. Then having done that, the se= ction could be=20 replaced by a one-line note in section 5.1 [5.5] Really? Do we have any hard data that convinces us that there=E2=80= =99s an=20 interesting class of organizations that (a) want to offer WebFinger and (b) can=E2=80=99t access their root and (c) can easily set up a subdoma= in? [6] =E2=80=9CEnterprise=E2=80=9D?! What does that word mean? Also there=E2= =80=99s a contradiction=20 between the sentence saying you have to use =E2=80=9C*=E2=80=9D and the nex= t paragraph=20 saying something more restrictive is OK. Might it be better to just say=20 =E2=80=9CWebFinger may not be usable from code running in browsers due to Origin policies; therefore, the use of CORS headers is=20 required. The header =E2=80=9CAccess-Control-Allow-Origin: * =E2=80=9D will= maximize usability; certain organizations may wish to control access to WebFinger=20 with a more restrictive Access-Control-Allow-Origin value. [7. Access Control] This section could be dropped, or replaced with a short= =20 paragraph noting that since WebFinger is based on HTTP, implementors will= =20 need to deal with the possibility that the origin server may impose access= =20 control policies or simply refuse access. [8.] This section could be dropped. This is an HTTP-based service and we= =20 can assume that implementors should be prepared to handle HTTP-standard redirect semantics. The caution about not redirecting to a= =20 /.well-known somewhere else seems of questionable value, since I might=20 actually want to have a common webfinger which returns the same values for= =20 any X whether it's X@example.com, X@example.net, or whatever, and I could= =20 do that efficiently by having a /.well-known on one of them and redirecting= =20 to it from the others. ------=_Part_194_11284163.1353738767484 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Oops, I replied to this but hadn=E2=80=99t bothered to join the mailing lis= t first, so it bounced.  Here it is again:

Notes on draft-ietf-= appsawg-webfinger-04.txt

Sorry for coming late to the party. This the first webfinger draft that I= =E2=80=99ve ever read, and I=E2=80=99m almost completely ignorant of the hi= story.  Having said that, sometimes a history-free pair of eyes lookin= g at something can add value.

[1. Introduction. ]

Suggest shortening up, omitting the history, losing the whole first para an= d beginning the second =E2=80=9CWebfinger uses the HTTP protocol to retriev= e a structured document containing link relations that describe people or o= ther entities on the Internet. For a person...

[para 2]  =E2=80=9Cdirect human consumption (e.g., looking up someone= =E2=80=99s phone number), or...=E2=80=9D

[4. Example use of WebFinger] Tighten up 1st sentence: =E2=80=9CThis sectio= n shows a few sample uses of Webfinger.=E2=80=9D

[4.1 Locating a User's Blog] What is the benefit of the =E2=80=9Caliases=E2= =80=9D field?

What is the benefit of the =E2=80=9Cacct=E2=80=9D URI scheme?  Couldn= =E2=80=99t =E2=80=9Cmailto:=E2=80=9D have been used in this case?

[4.2 Identity Provider Discovery...]

Since the =E2=80=9Crel=E2=80=9D parameter is optional and you can=E2=80=99t= count on it, providing it is strictly a client-suggested optimization? &nb= sp;Feels quite likely to be premature, to me.

In particular, I=E2=80=99m thinking of my own small-scale domains like textuality.com and tbray.org, which have a sing= le-digit number of accounts.  I could drop static JRD files into a sma= ll number of files with names like /.well-known/webfinger?resource=3Dm= ailto:tbray@textuality.com= and do webfinger very cheaply. The existence of the =E2=80=9Crel=E2=80=9D = parameter means I can=E2=80=99t solve this problem statically.

[4.4 Retrieving Device Information]

I have to say this feels fanciful. Any time an example requires inventing a= new URI scheme, I suggest that=E2=80=99s a symptom of trying too hard.

[5.1, first para]

I hate to be pedantic, but when you say =E2=80=9Cparameter=E2=80=9D, you=E2= =80=99re talking about the &-separated name-value pairs in the =E2=80= =9Cquery=E2=80=9D [RFC3986] part of a URI.  Fine enough, and it=E2=80= =99s a common usage, but I don=E2=80=99t actually know where it's defined (= not in 3986) so either we need to find a definition and link to it, or inve= st a paragraph in saying what you mean

[5.1] =E2=80=9CWebFinger servers MUST return JRD documents as the default r= epresentation...=E2=80=9D What does =E2=80=9Cdefault=E2=80=9D mean?  A= re we saying that servers MUST return JRD?  If so, say so.

[5.1] Last two paragraphs are perhaps superfluous?  Since it=E2=80=99s= HTTP, don=E2=80=99t you get this for free?

[5.2] =E2=80=9CAny array elements within the "links" array are presented by= the server in order of preference.=E2=80=9D  Huh? Don't understand.
[5.2] =E2=80=9CThe "template" element is forbidden=E2=80=9C?  Huh? &nb= sp;The spec doesn=E2=80=99t define any semantic for this element. You proba= bly need a  policy on unknown fields. For example:
(a) =E2=80=9CSoftware must ignore any fields found in the JRD which are not= specified here=E2=80=9D (a.k.a. MUST_IGNORE)
(b) =E2=80=9CIt is forbidden for any elements not specified here to appear = in a JRD=E2=80=9C (a.k.a. maximally brittle)
The special processing for =E2=80=9Ctemplate=E2=80=9D is just weird.  = If it=E2=80=99s required for some good reason, give the reason.

[5.2] The fact that =E2=80=9Ctitles=E2=80=9D is allowed but has no specifie= d semantics is troublesome.  Explain or remove?
[5.2] The fact there is no discussion of what you might use =E2=80=9Cproper= ties=E2=80=9D for, nor any discussion of its structure, is troublesome.&nbs= p; Do we have actual users of this?  Explain or remove?

[5.3] =E2=80=9CThe purpose of the "rel" parameter is to return a subset of = resource's link relations.  It is not intended to reduce the work=E2= =80=9D Could this be motivated a bit?  Why would you want a subset, as= ide from reducing the work?

[5.3] The restated example doesn=E2=80=99t really add value here, I think. = How the =E2=80=9Crel=E2=80=9D parameter works is simple enough.

[5.4] Two problems: First, this section fails to convince me that the =E2= =80=9Cacct=E2=80=9D scheme is worth the effort. Second, the section could s= imply say that the URI used to identify the entity being queried is not tie= d to any scheme; the arm-waving about the hypothetical wonderfulnesss of =E2=80=9Cacct:=E2=80=9D is a waste of space.  Then having done that, t= he section could be replaced by a one-line note in section 5.1

[5.5] Really?  Do we have any hard data that convinces us that there= =E2=80=99s an interesting class of organizations that (a) want to offer Web= Finger
and (b) can=E2=80=99t access their root and (c) can easily set up a subdoma= in?

[6] =E2=80=9CEnterprise=E2=80=9D?! What does that word mean?  Also the= re=E2=80=99s a contradiction between the sentence saying you have to use = =E2=80=9C*=E2=80=9D and the next paragraph saying something more restrictiv= e is OK.  Might it be better to just say =E2=80=9CWebFinger may not be= usable from code running in
browsers due to Origin policies; therefore, the use of CORS headers is requ= ired. The header =E2=80=9CAccess-Control-Allow-Origin: * =E2=80=9D will max= imize
usability; certain organizations may wish to control access to WebFinger wi= th a more restrictive Access-Control-Allow-Origin value.

[7. Access Control] This section could be dropped, or replaced with a short= paragraph noting that since WebFinger is based on HTTP,  implementors= will need to deal with the possibility that the origin server may impose a= ccess control policies or simply refuse access.

[8.]  This section could be dropped.  This is an HTTP-based servi= ce and we can assume that implementors should be prepared to handle
HTTP-standard redirect semantics.  The caution about not redirecting t= o a /.well-known somewhere else seems of questionable value, since I might = actually want to have a common webfinger which returns the same values for = any X whether it's X@example.com, X@example.net, or whatever, and I could do= that efficiently by having a /.well-known on one of them and redirecting t= o it from the others.

------=_Part_194_11284163.1353738767484-- ------=_Part_193_15684827.1353738767484-- From paulej@packetizer.com Fri Nov 23 23:13: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 9A5FB21F86A7 for ; Fri, 23 Nov 2012 23:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] 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 d-PM0u6azg1V for ; Fri, 23 Nov 2012 23:13:23 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 44BA821F848B for ; Fri, 23 Nov 2012 23:13:23 -0800 (PST) Received: from dhcp50-94-17-151.hil-elikyhx.atl.wayport.net (dhcp50-94-17-151.hil-elikyhx.atl.wayport.net [50.94.17.151]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qAO7DHHB030368 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 24 Nov 2012 02:13:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353741200; bh=ZKU0rJjhLNB7v9JWeK0XTn3RpzbXt2qSmUdUtGfRA4E=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=syoVbZ3hT/D+OBHtZaoc/iX9Kk5kGSuKDywvLeiM03pvrD+3Q+KdameP8n7lLnHNt VsFrbTTcSpfFf6dIBlVjnD7D49FyejRukBnZCh5brGZjLVIGzFm/8RvBbFxOirfnDn Bfw5M5mewyFCtQiAq0kyGUcna9I+B0ZjkEha+M/8= User-Agent: Kaiten Mail In-Reply-To: <50AFF5F4.8030605@openlinksw.com> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943668FD18F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50AFF5F4.8030605@openlinksw.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----7C1F9S0NTKOH31EOULADHZ71HXZWZV" From: "Paul E. Jones" Date: Sat, 24 Nov 2012 02:13:16 -0500 To: webfinger@googlegroups.com, Kingsley Idehen Message-ID: <2a1fa9d1-83ad-41db-a928-7a946cfc05f3@email.android.com> Cc: Brad Fitzpatrick , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 24 Nov 2012 07:13:24 -0000 ------7C1F9S0NTKOH31EOULADHZ71HXZWZV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit You can always redirect requests elsewhere, but if we don't have fixed resource locations, it makes discovery a challenge. Paul -------- Original Message -------- From: Kingsley Idehen Sent: Fri Nov 23 17:17:24 EST 2012 To: webfinger@googlegroups.com Cc: Brad Fitzpatrick , John Bradley , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 On 11/23/12 5:09 PM, Brad Fitzpatrick wrote: > On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones > > wrote: > > Thanks for writing this, John. It’s important for people to > understand that this is a real problem – not a theoretical problem > – and that the consequences of not solving the problem in a > practically implementable standards-based manner could once again > be deployment of a vendor-specific solution that locks out other > participants. > > > What's the problem? > > I missed some emails, if there were any about this. Is there > discussion happening on a mailing list other than apps-discuss and/or > webfinger@googlegroups.com ? > > We already have the /.well-known/ thing, so why do we need a > well-known subdomain? > > The way I see it is: > > a) If you're aren't running a webserver on the hostname => run one, > and respond to /.well-known/webfinger > b) If you are running a webserver on the hostname => respond to > /.well-known/webfinger > > We need to make things easier for clients, not easier for servers. > There will many more clients than servers, so it needs to be hard to > get wrong, if we want people to do the right thing. > > Let's imagine that the "webfinger" subdomain goes into the spec, but > no major webfinger server uses it. So now we have 99% of webfinger > client applications (many in JavaScript) only implementing the base > case and ignoring the subdomain lookup, because it always works as far > as they're concerned. Now new servers have no choice but to respond > at host.com/.well-known/webfinger > because most clients won't > work otherwise. That's where I fear this is all heading: because of > a misguided desired to make things easier for some hypothetical server > authors, we then make things complicated for everybody, even though we > gain nothing. > > When you have more clients than servers, I think it's important to > make things simple for clients. > All, A late in the game request. Is there any chance of > and/or > instead of just > or > ? Goal: to be able to deploy a Webfinger accessible profile document via the likes of Dropbox, GoogleDrive, Microsoft SkyDrive, Box.NET, Wuala, Amazon S3 buckets etc.. Basically, removing the HTTP server ownership and admin requirement by moving scope to a document path rather than a host. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen ------7C1F9S0NTKOH31EOULADHZ71HXZWZV Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

You can always redirect requests elsewhere, but if we don't have fixed resource locations, it makes discovery a challenge.

Paul



From: Kingsley Idehen <kidehen@openlinksw.com>
Sent: Fri Nov 23 17:17:24 EST 2012
To: webfinger@googlegroups.com
Cc: Brad Fitzpatrick <bradfitz@google.com>, John Bradley <ve7jtb@ve7jtb.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

On 11/23/12 5:09 PM, Brad Fitzpatrick wrote:
On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for writing this, John.  It’s important for people to understand that this is a real problem – not a theoretical problem – and that the consequences of not solving the problem in a practically implementable standards-based manner could once again be deployment of a vendor-specific solution that locks out other participants.


What's the problem?

I missed some emails, if there were any about this.  Is there discussion happening on a mailing list other than apps-discuss and/or webfinger@googlegroups.com?

We already have the /.well-known/ thing, so why do we need a well-known subdomain?

The way I see it is:

a) If you're aren't running a webserver on the hostname => run one, and respond to /.well-known/webfinger
b) If you are running a webserver on the hostname => respond to /.well-known/webfinger

We need to make things easier for clients, not easier for servers.  There will many more clients than servers, so it needs to be hard to get wrong, if we want people to do the right thing.

Let's imagine that the "webfinger" subdomain goes into the spec, but no major webfinger server uses it.  So now we have 99% of webfinger client applications (many in JavaScript) only implementing the base case and ignoring the subdomain lookup, because it always works as far as they're concerned.  Now new servers have no choice but to respond at host.com/.well-known/webfinger because most clients won't work otherwise.  That's where I fear this is all heading:  because of a misguided desired to make things easier for some hypothetical server authors, we then make things complicated for everybody, even though we gain nothing.

When you have more clients than servers, I think it's important to make things simple for clients.


All,

A late in the game request. Is there any chance of <host.com/.well-known/{path}/webfinger> and/or <host.com/{path}/.well-known/webfinger> instead of just <host.com/.well-known/webfinger> or <host.com/.well-known/webfinger> ?

Goal: to be able to deploy a Webfinger accessible profile document via the likes of Dropbox, GoogleDrive, Microsoft SkyDrive, Box.NET, Wuala, Amazon S3 buckets etc.. Basically, removing the HTTP server ownership and admin requirement by moving scope to a document path rather than a host. 

-- 

Regards,

Kingsley Idehen       
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
------7C1F9S0NTKOH31EOULADHZ71HXZWZV-- From masinter@adobe.com Sat Nov 24 07:01:55 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 A230721F8553 for ; Sat, 24 Nov 2012 07:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.149 X-Spam-Level: X-Spam-Status: No, score=-104.149 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_20=-0.74, J_CHICKENPOX_46=0.6, 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 HQKmrJWaZsiX for ; Sat, 24 Nov 2012 07:01:54 -0800 (PST) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 52A2521F8538 for ; Sat, 24 Nov 2012 07:01:53 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKULDhXTBPBGxvNQVeB6AmqjwhR7Wh1wwU@postini.com; Sat, 24 Nov 2012 07:01:54 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qAOF1mHP022396; Sat, 24 Nov 2012 07:01:48 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id qAOF1lXL013482; Sat, 24 Nov 2012 07:01:47 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Sat, 24 Nov 2012 07:01:46 -0800 From: Larry Masinter To: "draft-salgueiro-vcarddav-kind-device-03.all@tools.ietf.org" , "apps-discuss@ietf.org" Date: Sat, 24 Nov 2012 07:01:43 -0800 Thread-Topic: APPSDIR review of draft-salgueiro-vcarddav-kind-device-03 Thread-Index: Ac3KUAhYq9eIL7SnSXeFfwzyjicEBg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [apps-discuss] APPSDIR review of draft-salgueiro-vcarddav-kind-device-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: Sat, 24 Nov 2012 15:01:55 -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/ar= ea/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other comments you may receiv= e. Please wait for direction from your document shepherd or AD before post= ing a new version of the draft. Document: draft-salgueiro-vcarddav-kind-device-03 Title: vCard KIND:device Reviewer: Larry Masinter=20 Review Date: 24 Nov 2012=20 Summary: The document is almost ready for publication as a Proposed Standar= d. Some clarification and design rationale would be quite helpful. Major Issues: none Minor Issues/Nits: =20 I had trouble between "Minor issues" or "Nits" for many of these, so I put = them together. I don't feel strongly about any of them, if the authors are = confident that anyone steeped in vCard and LDAP wouldn't have the same issu= es. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 1. use cases (definitely NIT) > use cases for device vCards have emerged Are these documented somewhere else? A few more examples would be helpful.= =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D 2. LDAP / X.521 alignment, nature of devices (NIT) > In this context, the concept of a device is constrained to computing > devices and thus is distinct from purely mechanical devices such as > elevators, electric generators, etc. that cannot communicate in any > way over a network. Why not allow mechanical devices such as elevators, electric generators, or= gas and electric meters? Wouldn't compatibility with LDAP be useful? Is there a need to distinguish between network elements (routers) and appli= ances and light switches?=20 Between physical objects and virtual objects that do not have a distinct ph= ysical location? > Although it might be desirable to define a more fine-grained taxonomy > of devices (e.g., a KIND of "device" with a subtype of "router" or=20 > "computer"), such a taxonomy is out of scope for this document "out of scope" is a convenient but frustrating label for "we decided not to= do it". As a spec author/editor it's great; for a reader it isn't so grea= t. Some more elaboration "There were no compelling use cases for such a dis= tinction, and advantages to not making distinctions where some use cases st= raddled the categories." (if that's a reason) might be more satisfactory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3. Devices "containing" vCards, normative language around it (MINOR) " A device MAY contain..." The "contain" relationship is unspecified. How are these vCards discovered = and accessed in a "device"? I can see saying that a device "has" one or mo= re vCards and being explicit that discovery and access are unspecified? If = a 2D barcode is affixed to the device and used to retrieve the vCards assoc= iated with it, is that in scope? =20 My concern is over the normative language "MAY" for a relationship that is = unspecified. > When a device contains vCards other than its KIND:device vCard, those > vCards MUST be linked together with RELATED (see the definition of > the RELATED organizational property in Section 6.6.6 of [RFC6350]). Since 'contain' is unspecified, the scope of this advice (and thus the MUST= requirement) is unclear. Even if you define "contain", isn't this a SHOULD= ? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D 4. Use of RELATED for devices (NIT) The values for RELATED in RFC 6350=20 =20 "contact" / "acquaintance" / "friend" / "met" / "co-worker" / "colleague" / "co-resident" / "neighbor" / "child" / "parent" / "sibling" / "spouse" / "kin" / "muse" / "crush" / "date" / "sweetheart" / "me" / "agent" / "emergency" don't seem to match device relationships (robot love?). Perhaps some more e= xamples of RELATED use or advice here would help? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5. Example unexplained (MINOR) Section 4, the Example is not explained! Lots of the example is mysterious = to me. Please annotate the example with a description of what it means and = why. From masinter@adobe.com Sat Nov 24 07:12: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 0AF2D21F8567 for ; Sat, 24 Nov 2012 07:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.577 X-Spam-Level: X-Spam-Status: No, score=-103.577 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, 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 VIeTTD0DJTXC for ; Sat, 24 Nov 2012 07:12:14 -0800 (PST) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id C3F8721F854A for ; Sat, 24 Nov 2012 07:12:08 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKULDjyGxoa3OZBA2Lu33c24w+Z9Kl/xFR@postini.com; Sat, 24 Nov 2012 07:12:13 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qAOFC7HP022625; Sat, 24 Nov 2012 07:12:07 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id qAOFC6XL014673; Sat, 24 Nov 2012 07:12:06 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Sat, 24 Nov 2012 07:12:05 -0800 From: Larry Masinter To: "apps-discuss@ietf.org" , "draft-salgueiro-vcarddav-kind-device.all@tools.ietf.org" Date: Sat, 24 Nov 2012 07:12:02 -0800 Thread-Topic: APPSDIR review of draft-salgueiro-vcarddav-kind-device-03 Thread-Index: Ac3KUAhYq9eIL7SnSXeFfwzyjicEBgABXUtA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [apps-discuss] APPSDIR review of draft-salgueiro-vcarddav-kind-device-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: Sat, 24 Nov 2012 15:12:19 -0000 (resend) I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see http://trac.tools.ietf.org/ar= ea/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other comments you may receiv= e. Please wait for direction from your document shepherd or AD before post= ing a new version of the draft. Document: draft-salgueiro-vcarddav-kind-device-03 Title: vCard KIND:device Reviewer: Larry Masinter=20 Review Date: 24 Nov 2012=20 Summary: The document is almost ready for publication as a Proposed Standar= d. Some clarification and design rationale would be quite helpful. Major Issues: none Minor Issues/Nits: =20 I had trouble between "Minor issues" or "Nits" for many of these, so I put = them together. I don't feel strongly about any of them, if the authors are = confident that anyone steeped in vCard and LDAP wouldn't have the same issu= es. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 1. use cases (definitely NIT) > use cases for device vCards have emerged Are these documented somewhere else? A few more examples would be helpful.= =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D 2. LDAP / X.521 alignment, nature of devices (NIT) > In this context, the concept of a device is constrained to computing > devices and thus is distinct from purely mechanical devices such as > elevators, electric generators, etc. that cannot communicate in any > way over a network. Why not allow mechanical devices such as elevators, electric generators, or= gas and electric meters? Wouldn't compatibility with LDAP be useful? Is there a need to distinguish between network elements (routers) and appli= ances and light switches?=20 Between physical objects and virtual objects that do not have a distinct ph= ysical location? > Although it might be desirable to define a more fine-grained taxonomy > of devices (e.g., a KIND of "device" with a subtype of "router" or=20 > "computer"), such a taxonomy is out of scope for this document "out of scope" is a convenient but frustrating label for "we decided not to= do it". As a spec author/editor it's great; for a reader it isn't so grea= t. Some more elaboration "There were no compelling use cases for such a dis= tinction, and advantages to not making distinctions where some use cases st= raddled the categories." (if that's a reason) might be more satisfactory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3. Devices "containing" vCards, normative language around it (MINOR) " A device MAY contain..." The "contain" relationship is unspecified. How are these vCards discovered = and accessed in a "device"? I can see saying that a device "has" one or mo= re vCards and being explicit that discovery and access are unspecified? If = a 2D barcode is affixed to the device and used to retrieve the vCards assoc= iated with it, is that in scope? =20 My concern is over the normative language "MAY" for a relationship that is = unspecified. > When a device contains vCards other than its KIND:device vCard, those > vCards MUST be linked together with RELATED (see the definition of > the RELATED organizational property in Section 6.6.6 of [RFC6350]). Since 'contain' is unspecified, the scope of this advice (and thus the MUST= requirement) is unclear. Even if you define "contain", isn't this a SHOULD= ? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D 4. Use of RELATED for devices (NIT) The values for RELATED in RFC 6350=20 =20 "contact" / "acquaintance" / "friend" / "met" / "co-worker" / "colleague" / "co-resident" / "neighbor" / "child" / "parent" / "sibling" / "spouse" / "kin" / "muse" / "crush" / "date" / "sweetheart" / "me" / "agent" / "emergency" don't seem to match device relationships (robot love?). Perhaps some more e= xamples of RELATED use or advice here would help? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5. Example unexplained (MINOR) Section 4, the Example is not explained! Lots of the example is mysterious = to me. Please annotate the example with a description of what it means and = why. From bradfitz@google.com Fri Nov 23 14:09: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 38A2221F843F for ; Fri, 23 Nov 2012 14:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.380, 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 U+CCvDoE485K for ; Fri, 23 Nov 2012 14:09:13 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED32A21F8432 for ; Fri, 23 Nov 2012 14:09:12 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so10143211oag.31 for ; Fri, 23 Nov 2012 14:09:12 -0800 (PST) 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; bh=NGRIHw9kk6brSQI2pVhcJllUUWTTihMX8QznZlhTFSI=; b=iJp1BKpI+tjWm7DAaO/kVI1dcwxzypN0cYnJLwI0btK1ZYcRaeMPOZWaLHpLwlusKV GH+wyc02PIXeqyeUepD5uoR9elp7pILYQbX7lM+ptdVuPieUxsfnzXGftE+OuVONc9K9 g7f7rNck6hW9TJ+dfyAL8HYQ7keHUufQM9l3ZybrX9zvtFfgXTos8zfSo1F9GXLxV93b tSHxIiui8gHxzUvQhPffdB43q/qpBXyDX6XS04RlJcq5GVRE9LZOzQNQq3ogF7w5Orfe g5vi58tvXAPaOVclKmkEsW5Uh2GxwHwbfwW1dZkXayv0BJMwQ5JarupJWQrS4naYVOFk pbaA== 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=NGRIHw9kk6brSQI2pVhcJllUUWTTihMX8QznZlhTFSI=; b=RORl6z/OvWIxjnRlAXQ7q8EXOKouV7K6spOzc3eBwwj9RDcESD6ljsnyRjcfuBbVpu DIqLSW9rktWkusktBdD7TVLSR7IXrPfpqUqGTge09roXQDY3EDn/GczarTBCVmp0u7oi 9pWLzg3fqDbBGcWqw4QWfrB+Um3TzQyV3lTzDy0HfziB18fxsPvf4HehlfQ+HH7Ey6Wb 1aq4iajoJkaUMDQUvWAZzhe96jefR7ECcZjpCoyE7SoLFRMndOUvEJVtxmj3+dOP+TwK gIS1+COBjWosHy9C06cYQoQ4XWreJ5Z6KC9H8m7wH4J0yDvKIsZlZ43TV99PfGZWe0yH M78w== MIME-Version: 1.0 Received: by 10.60.6.170 with SMTP id c10mr3847329oea.82.1353708552113; Fri, 23 Nov 2012 14:09:12 -0800 (PST) Received: by 10.76.74.134 with HTTP; Fri, 23 Nov 2012 14:09:11 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668FD18F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943668FD18F@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 23 Nov 2012 14:09:11 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8fb1ff7460cea004cf30d5ca X-Gm-Message-State: ALoCoQmpNsFIsf00uCHMxA2fCLX+u4ii9UMGljHBY4j2GqR1/xfgcrfUX3/L4AFE/XQIhAcv8Ij/q3CS6P1v/MTfOLTrmU8dxofnpBeEI/HlAt3Xnfye7dfA6zd42IumstrFrUftBMb7kUhOFW0q/n4M9XfF1Kii7tPAoVr2CtgXgMSexmokM5PxS0tewGxvOtCj+m2/rL0i X-Mailman-Approved-At: Sat, 24 Nov 2012 08:15:02 -0800 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 23 Nov 2012 22:09:14 -0000 --e89a8fb1ff7460cea004cf30d5ca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones wr= ote: > Thanks for writing this, John. It=E2=80=99s important for people to und= erstand > that this is a real problem =E2=80=93 not a theoretical problem =E2=80=93= and that the > consequences of not solving the problem in a practically implementable > standards-based manner could once again be deployment of a vendor-specifi= c > solution that locks out other participants. > What's the problem? I missed some emails, if there were any about this. Is there discussion happening on a mailing list other than apps-discuss and/or webfinger@googlegroups.com? We already have the /.well-known/ thing, so why do we need a well-known subdomain? The way I see it is: a) If you're aren't running a webserver on the hostname =3D> run one, and respond to /.well-known/webfinger b) If you are running a webserver on the hostname =3D> respond to /.well-known/webfinger We need to make things easier for clients, not easier for servers. There will many more clients than servers, so it needs to be hard to get wrong, if we want people to do the right thing. Let's imagine that the "webfinger" subdomain goes into the spec, but no major webfinger server uses it. So now we have 99% of webfinger client applications (many in JavaScript) only implementing the base case and ignoring the subdomain lookup, because it always works as far as they're concerned. Now new servers have no choice but to respond at host.com/.well-known/webfinger because most clients won't work otherwise. That's where I fear this is all heading: because of a misguided desired to make things easier for some hypothetical server authors, we then make things complicated for everybody, even though we gain nothing. When you have more clients than servers, I think it's important to make things simple for clients. --e89a8fb1ff7460cea004cf30d5ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Fri, Nov 23, 2012 at 1:19 PM, Mike Jones <Michael.Jones@micros= oft.com> wrote:

Thanks for writing this, = John.=C2=A0 It=E2=80=99s important for people to understand that this is a = real problem =E2=80=93 not a theoretical problem =E2=80=93 and that the con= sequences of not solving the problem in a practically implementable standards-based = manner could once again be deployment of a vendor-specific solution that lo= cks out other participants.


What's the problem?

I missed some e= mails, if there were any about this. =C2=A0Is there discussion happening on= a mailing list other than=C2=A0apps-discuss and/or webfinger@googlegroups.com?

We already have the /.well-known/ thing, so why do we n= eed a well-known subdomain?

The way I see it is:

a) If you're aren't running a webserver on = the hostname =3D> run one, and respond to /.well-known/webfinger
b) If you are running a webserver on the hostname =3D> respond to /= .well-known/webfinger

We need to make things easie= r for clients, not easier for servers. =C2=A0There will many more clients t= han servers, so it needs to be hard to get wrong, if we want people to do t= he right thing.

Let's imagine that the "webfinger" subdom= ain goes into the spec, but no major webfinger server uses it. =C2=A0So now= we have 99% of webfinger client applications (many in JavaScript) only imp= lementing the base case and ignoring the subdomain lookup, because it alway= s works as far as they're concerned. =C2=A0Now new servers have no choi= ce but to respond at host= .com/.well-known/webfinger because most clients won't work otherwis= e. =C2=A0That's where I fear this is all heading: =C2=A0because of a mi= sguided desired to make things easier for some hypothetical server authors,= we then make things complicated for everybody, even though we gain nothing= .

When you have more clients than servers, I think it'= ;s important to make things simple for clients.

<= /div> --e89a8fb1ff7460cea004cf30d5ca-- From bradfitz@google.com Fri Nov 23 14:31: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 5284421F8578 for ; Fri, 23 Nov 2012 14:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=0.353, 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 SMA512RzOTcO for ; Fri, 23 Nov 2012 14:31:25 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 332B321F8577 for ; Fri, 23 Nov 2012 14:31:25 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so10203598obb.31 for ; Fri, 23 Nov 2012 14:31:24 -0800 (PST) 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; bh=fTJZvaeK2HXJVPuGAUJgnTrVgJQerJOy/So4KAogljM=; b=pavpRewiUZocqvib0L1qTtnPK1qgzSmRHrRDEzC1UrwExVbTqa8nhCQV6sNyRv0lgt +GqwhEC4j9gnaBjjcZ8jZmL+Zs7cv2R8jh7BmBNf/DJ8Ihs8qKyoZJViuFLn8Pho1YgM sjO1Q26KivNgHIz+JIrA8FR27XC3ctBaIRXd+XnuIywVKhvMvA1flLEYgONMPn2P75Uc K08qL3hpov0UC+mSJa5DSLmx/NazIffteJI+t4lqU4r1H/qR+Vywt4spIZ2NdoO5iS/t 40AV93MmGaUAkvV86M/A4B/n3jZZEMy+4G129R3jmF21tuwBE7YOtn5GDpsPS4xKkt2i xJ1Q== 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=fTJZvaeK2HXJVPuGAUJgnTrVgJQerJOy/So4KAogljM=; b=ef+nE2mQocIEefgcDoYdP4GRKkw7jtmBxsVTqX9AReEQ+7fW77o3/xsDAYiu/NCryN H4aAK2OlZc0QfW828njSy0bh6HNTeFBsCoueVp28eihpG+c2FMdX5EkhgLXnIQLLx37y vxg9BovHrCMIwUTS/NIZGA7V/nIVF2UpjBstZjdgHa6N2JMLOo7FvCB+pEuEYZyZXjjj LiVZu0m4Fv7A2KqH0yxRhDsUPjQfxtTT3wTfRSx3CWgd/4BuQqD/I4ICzYmZECIZbC8L 00UyqVXDEyiAmMlELkf7rM4tFzDdIBU5CenamkVoZy+GzcxRWToNOKBSLprXkS0Ks8qn OLwA== MIME-Version: 1.0 Received: by 10.182.109.36 with SMTP id hp4mr3974501obb.86.1353709884556; Fri, 23 Nov 2012 14:31:24 -0800 (PST) Received: by 10.76.74.134 with HTTP; Fri, 23 Nov 2012 14:31:24 -0800 (PST) In-Reply-To: References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943668FD18F@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 23 Nov 2012 14:31:24 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d0444eafbcc459b04cf312498 X-Gm-Message-State: ALoCoQm/0PvqJC48g1vXYea78b6vAraQBr+odZfjKUiCzWK1tN9SuXEsjkDnqntZwuQqIkvwgaOOSD7fyisPa+Qe9iMEQh6mZPqPrrNmCkgEn2rQCqyrdrtxw3iOGB1EcusJaxroeNBs2mPjkj+F3TYhN1pv/q+lKgNW3Yr/CVO2YS+THu3FzR1k62VHgHyVviRzSLOsrFpI X-Mailman-Approved-At: Sat, 24 Nov 2012 08:15:20 -0800 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 23 Nov 2012 22:31:26 -0000 --f46d0444eafbcc459b04cf312498 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Okay, glad I didn't miss anything. Section 2.1 of SWD doesn't explain the problem: for some reason, running a webserver "may be difficult or impossible", so it pushes complexity to clients instead. On Fri, Nov 23, 2012 at 2:19 PM, Dick Hardt wrote: > Hi Brad > > The problem was not discussed on the list. The relevant part of the SWD > document is below > > Myself, I would like to be pointed to real world examples as I don't > appreciate the issue yet. > > -- Dick > > 2.1 . "simple-web-discovery" Subdomain > > It may be difficult or impossible for some domains wanting to support > SWD requests to make an SWD server available for their domain at the > path "/.well-known/simple-web-discovery". For instance, in the case > of hosted domains, no web server may be running on the domain host at > all. > > For that reason, SWD servers for a domain MAY be located on a > specific subdomain of that domain: "simple-web-discovery". For > example, the SWD server for the domain "example.com" MAY be located > at the URI "https://simple-web-discovery.example.com/.well-known/simp > le-web-discovery". > > > Jones & Goland Expires May 9, 2013 [Page 4] > > = Internet-Draft Simple Web Discovery (SWD) November 2012 > > > SWD clients MUST first attempt to make an SWD request to the domain's > "/.well-known/simple-web-discovery" endpoint, and then if that fails, > they MUST then attempt to make the request to the SWD endpoint at the > "simple-web-discovery" subdomain for the domain. > > > > > On Nov 23, 2012, at 2:09 PM, Brad Fitzpatrick wrote= : > > On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones = wrote: > >> Thanks for writing this, John. It=E2=80=99s important for people to un= derstand >> that this is a real problem =E2=80=93 not a theoretical problem =E2=80= =93 and that the >> consequences of not solving the problem in a practically implementable >> standards-based manner could once again be deployment of a vendor-specif= ic >> solution that locks out other participants. >> > > What's the problem? > > I missed some emails, if there were any about this. Is there discussion > happening on a mailing list other than apps-discuss and/or > webfinger@googlegroups.com? > > We already have the /.well-known/ thing, so why do we need a well-known > subdomain? > > The way I see it is: > > a) If you're aren't running a webserver on the hostname =3D> run one, and > respond to /.well-known/webfinger > b) If you are running a webserver on the hostname =3D> respond to > /.well-known/webfinger > > We need to make things easier for clients, not easier for servers. There > will many more clients than servers, so it needs to be hard to get wrong, > if we want people to do the right thing. > > Let's imagine that the "webfinger" subdomain goes into the spec, but no > major webfinger server uses it. So now we have 99% of webfinger client > applications (many in JavaScript) only implementing the base case and > ignoring the subdomain lookup, because it always works as far as they're > concerned. Now new servers have no choice but to respond at > host.com/.well-known/webfinger because most clients won't work otherwise. > That's where I fear this is all heading: because of a misguided desired > to make things easier for some hypothetical server authors, we then make > things complicated for everybody, even though we gain nothing. > > When you have more clients than servers, I think it's important to make > things simple for clients. > > > --f46d0444eafbcc459b04cf312498 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= kay, glad I didn't miss anything. Section 2.1 of SWD doesn't explai= n the problem: for some reason, running a webserver "may be difficult = or impossible", so it pushes complexity to clients instead.=C2=A0


On Fri, Nov 23, 2012 at 2:19 P= M, Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Brad

The problem = was not discussed on the list.=C2=A0The relevant part of the SWD document i= s below

Myself, I would like to be pointed to real= world examples as I don't appreciate the issue yet.

-- Dick


2.1.  "simple-web-discovery" Subdo=
main



   It may be difficult or impossible for some domains wanting to support
   SWD requests to make an SWD server available for their domain at the
   path "/.well-known/simple-web-discovery".  For instance, in th=
e case
   of hosted domains, no web server may be running on the domain host at
   all.

   For that reason, SWD servers for a domain MAY be located on a
   specific subdomain of that domain: "simple-web-discovery".  Fo=
r
   example, the SWD server for the domain "example.com" MAY be located
   at the URI "https://simple-web-discovery.example.com/.=
well-known/simp
   le-web-discovery".



Jones & Goland             Expir=
es May 9, 2013                  [Page 4]

 
Internet-Draft         Simple Web Di=
scovery (SWD)          November 2012


   SWD clients MUST first attempt to make an SWD request to the domain'=
s
   "/.well-known/simple-web-discovery" endpoint, and then if that=
 fails,
   they MUST then attempt to make the request to the SWD endpoint at the
   "simple-web-discovery" subdomain for the domain.


On Nov 23, 2012, at 2:09 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:
On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for writing t= his, John.=C2=A0 It=E2=80=99s important for people to understand that this = is a real problem =E2=80=93 not a theoretical problem =E2=80=93 and that th= e consequences of not solving the problem in a practically implementable standards-based = manner could once again be deployment of a vendor-specific solution that lo= cks out other participants.


What's the problem?

I missed some e= mails, if there were any about this. =C2=A0Is there discussion happening on= a mailing list other than=C2=A0apps-discuss and/or webfinger@googlegroups.com?

We already have the /.well-known/ thing, so why do we n= eed a well-known subdomain?

The way I see it is:

a) If you're aren't running a webserver on = the hostname =3D> run one, and respond to /.well-known/webfinger
b) If you are running a webserver on the hostname =3D> respond to /= .well-known/webfinger

We need to make things easie= r for clients, not easier for servers. =C2=A0There will many more clients t= han servers, so it needs to be hard to get wrong, if we want people to do t= he right thing.

Let's imagine that the "webfinger" subdom= ain goes into the spec, but no major webfinger server uses it. =C2=A0So now= we have 99% of webfinger client applications (many in JavaScript) only imp= lementing the base case and ignoring the subdomain lookup, because it alway= s works as far as they're concerned. =C2=A0Now new servers have no choi= ce but to respond at host.com/.well-known/webfinger because most clients won&#= 39;t work otherwise. =C2=A0That's where I fear this is all heading: =C2= =A0because of a misguided desired to make things easier for some hypothetic= al server authors, we then make things complicated for everybody, even thou= gh we gain nothing.

When you have more clients than servers, I think it'= ;s important to make things simple for clients.

<= /div>


--f46d0444eafbcc459b04cf312498-- From paulej@packetizer.com Sat Nov 24 08: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 29F2221F84F3 for ; Sat, 24 Nov 2012 08:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] 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 HewTjr5ra+zj for ; Sat, 24 Nov 2012 08:21:41 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D7CFC21F84DC for ; Sat, 24 Nov 2012 08:21:40 -0800 (PST) Received: from [10.62.53.234] (mobile-032-147-199-086.mycingular.net [32.147.199.86] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qAOGLY33022043 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 24 Nov 2012 11:21:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353774099; bh=38zfqcN+K9nDNpkcjanwyCweBCqFSsNQ2xf3QWlXeC8=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=FsLw6P3H4AMfLRRG2V39eqZgMmkB2Uf7BDhc8fqcoQCC5v2fNQrrw73GxKP6SK/Xn qKgG3dkC69tmv5xVxmBr35H1oqtmEyHfYAvTajtAVMau+fhNnMKvwwhtKXDfLzIjKB FCn9LufPEVCDjAxxA6vh3OlJZ0rt1jfbHZYkS768= User-Agent: K-9 Mail for Android In-Reply-To: <50B0F066.5030509@openlinksw.com> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943668FD18F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50AFF5F4.8030605@openlinksw.com> <2a1fa9d1-83ad-41db-a928-7a946cfc05f3@email.android.com> <50B0F066.5030509@openlinksw.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----U084QMF07W4GA180E3COQ38LDGDZCA" From: "Paul E. Jones" Date: Sat, 24 Nov 2012 11:21:31 -0500 To: webfinger@googlegroups.com, Kingsley Idehen Message-ID: Cc: Brad Fitzpatrick , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 24 Nov 2012 16:21:42 -0000 ------U084QMF07W4GA180E3COQ38LDGDZCA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I don't understand how this would work. Suppose I write a client that wants to look up information on a given user. Using the well-known location, the client code is fairly simple. If we use different paths, we'd need a discovery mechanism for the path, no? Paul -------- Original Message -------- From: Kingsley Idehen Sent: Sat Nov 24 11:05:58 EST 2012 To: webfinger@googlegroups.com Cc: "Paul E. Jones" , Brad Fitzpatrick , John Bradley , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 On 11/24/12 2:13 AM, Paul E. Jones wrote: > > You can always redirect requests elsewhere, but if we don't have fixed > resource locations, it makes discovery a challenge. > > _Paul_ > __ Yes, but I am seeking a way to alleviate the following challenges for end-users seeking to exploit Webfinger: 1. domain ownership 2. domain name server admin privileges 3. web server admin privileges. Right now, Webfinger scopes everything to the "host" in a Web realm that is really scoped to documents (Web 1.0 and 2.0) and named entities (Web 3.0 via Linked Data). Is it too costly to add "paths" to Webfinger bearing in mind the granularity this option provides i.e., rather being aimed at service providers (who control domain name and web servers) it also serves the needs of profile document owners and individuals that seek full control over their digital identities. The upside of this non disruptive tweak is massive. Kingsley > > > ------------------------------------------------------------------------ > *From:* Kingsley Idehen > *Sent:* Fri Nov 23 17:17:24 EST 2012 > *To:* webfinger@googlegroups.com > *Cc:* Brad Fitzpatrick , John Bradley > , "apps-discuss@ietf.org" > *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 > > On 11/23/12 5:09 PM, Brad Fitzpatrick wrote: >> On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones >> > wrote: >> >> Thanks for writing this, John. It’s important for people to >> understand that this is a real problem – not a theoretical >> problem – and that the consequences of not solving the problem in >> a practically implementable standards-based manner could once >> again be deployment of a vendor-specific solution that locks out >> other participants. >> >> >> What's the problem? >> >> I missed some emails, if there were any about this. Is there >> discussion happening on a mailing list other than apps-discuss and/or >> webfinger@googlegroups.com ? >> >> We already have the /.well-known/ thing, so why do we need a >> well-known subdomain? >> >> The way I see it is: >> >> a) If you're aren't running a webserver on the hostname => run one, >> and respond to /.well-known/webfinger >> b) If you are running a webserver on the hostname => respond to >> /.well-known/webfinger >> >> We need to make things easier for clients, not easier for servers. >> There will many more clients than servers, so it needs to be hard to >> get wrong, if we want people to do the right thing. >> >> Let's imagine that the "webfinger" subdomain goes into the spec, but >> no major webfinger server uses it. So now we have 99% of webfinger >> client applications (many in JavaScript) only implementing the base >> case and ignoring the subdomain lookup, because it always works as >> far as they're concerned. Now new servers have no choice but to >> respond at host.com/.well-known/webfinger >> because most clients won't >> work otherwise. That's where I fear this is all heading: because of >> a misguided desired to make things easier for some hypothetical >> server authors, we then make things complicated for everybody, even >> though we gain nothing. >> >> When you have more clients than servers, I think it's important to >> make things simple for clients. >> > > All, > > A late in the game request. Is there any chance of > > and/or > > instead of just > > or > > ? > > Goal: to be able to deploy a Webfinger accessible profile document via > the likes of Dropbox, GoogleDrive, Microsoft SkyDrive, Box.NET, Wuala, > Amazon S3 buckets etc.. Basically, removing the HTTP server ownership > and admin requirement by moving scope to a document path rather than a > host. > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web:http://www.openlinksw.com > Personal Weblog:http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile:https://plus.google.com/112399767740508618350/about > LinkedIn Profile:http://www.linkedin.com/in/kidehen > > > > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen ------U084QMF07W4GA180E3COQ38LDGDZCA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I don't understand how this would work. Suppose I write a client that wants to look up information on a given user. Using the well-known location, the client code is fairly simple. If we use different paths, we'd need a discovery mechanism for the path, no?

Paul

From: Kingsley Idehen <kidehen@openlinksw.com>
Sent: Sat Nov 24 11:05:58 EST 2012
To: webfinger@googlegroups.com
Cc: "Paul E. Jones" <paulej@packetizer.com>, Brad Fitzpatrick <bradfitz@google.com>, John Bradley <ve7jtb@ve7jtb.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

On 11/24/12 2:13 AM, Paul E. Jones wrote:

You can always redirect requests elsewhere, but if we don't have fixed resource locations, it makes discovery a challenge.

Paul


Yes, but I am seeking a way to alleviate the following challenges for end-users seeking to exploit Webfinger:

1. domain ownership
2. domain name server admin privileges
3. web server admin privileges.

Right now, Webfinger scopes everything to the "host" in a Web realm that is really scoped to documents (Web 1.0 and 2.0) and named entities (Web 3.0 via Linked Data).

Is it too costly to add "paths" to Webfinger bearing in mind the granularity this option provides i.e., rather being aimed at service providers (who control domain name and web servers) it also serves the needs of profile document owners and individuals that seek full control over their digital identities.

The upside of this non disruptive tweak is massive.

Kingsley



From: Kingsley Idehen <kidehen@openlinksw.com>
Sent: Fri Nov 23 17:17:24 EST 2012
To: webfinger@googlegroups.com
Cc: Brad Fitzpatrick <bradfitz@google.com>, John Bradley <ve7jtb@ve7jtb.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

On 11/23/12 5:09 PM, Brad Fitzpatrick wrote:
On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for writing this, John.  It’s important for people to understand that this is a real problem – not a theoretical problem – and that the consequences of not solving the problem in a practically implementable standards-based manner could once again be deployment of a vendor-specific solution that locks out other participants.


What's the problem?

I missed some emails, if there were any about this.  Is there discussion happening on a mailing list other than apps-discuss and/or webfinger@googlegroups.com?

We already have the /.well-known/ thing, so why do we need a well-known subdomain?

The way I see it is:

a) If you're aren't running a webserver on the hostname => run one, and respond to /.well-known/webfinger
b) If you are running a webserver on the hostname => respond to /.well-known/webfinger

We need to make things easier for clients, not easier for servers.  There will many more clients than servers, so it needs to be hard to get wrong, if we want people to do the right thing.

Let's imagine that the "webfinger" subdomain goes into the spec, but no major webfinger server uses it.  So now we have 99% of webfinger client applications (many in JavaScript) only implementing the base case and ignoring the subdomain lookup, because it always works as far as they're concerned.  Now new servers have no choice but to respond at host.com/.well-known/webfinger because most clients won't work otherwise.  That's where I fear this is all heading:  because of a misguided desired to make things easier for some hypothetical server authors, we then make things complicated for everybody, even though we gain nothing.

When you have more clients than servers, I think it's important to make things simple for clients.


All,

A late in the game request. Is there any chance of <host.com/.well-known/{path}/webfinger> and/or <host.com/{path}/.well-known/webfinger> instead of just <host.com/.well-known/webfinger> or <host.com/.well-known/webfinger> ?

Goal: to be able to deploy a Webfinger accessible profile document via the likes of Dropbox, GoogleDrive, Microsoft SkyDrive, Box.NET, Wuala, Amazon S3 buckets etc.. Basically, removing the HTTP server ownership and admin requirement by moving scope to a document path rather than a host. 

-- 

Regards,

Kingsley Idehen       
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen







-- 

Regards,

Kingsley Idehen       
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
------U084QMF07W4GA180E3COQ38LDGDZCA-- From mmn@hethane.se Sat Nov 24 09:10: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 1EC5421F858E for ; Sat, 24 Nov 2012 09:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_SE=0.35] 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 FnnYvkgaUpNU for ; Sat, 24 Nov 2012 09:10:18 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id 29A3021F858C for ; Sat, 24 Nov 2012 09:10:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sat, 24 Nov 2012 18:10:13 +0100 From: Mikael Nordfeldth To: In-Reply-To: References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> Message-ID: <5adcc27caa0ebeebe886329a572a8f86@hethane.se> X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 24 Nov 2012 17:10:19 -0000 23.11.2012 17:51 skrev James M Snell: > The one variation on this that I've been kicking around is the SRV > option... e.g. > > _webfinger._http.example.com. 86400 IN SRV 0 5 80 example.org. IIRC Patrik Fältström has been proposing this idea as well and I too believe it is a great solution. However arguably not something that can be implemented reliably in many DNS clients in use today. (also, shouldn't it be _webfinger._tcp.example.com. with https/http implied for the service type?) Either way a DNS resolution would solve all issues the subdomain attempts to solve and also allow for a lot more flexibility in service lookup (such as service port and third-party domain name). The subdomain solution is suboptimal and anyone who can setup such a subdomain on a _redundant_ webserver (vhosting is vulnerable to the same routing/hardware issues) would also be able to do proper load balancing and other service redundancy for the hostname's /.well-known/webfinger -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se +46705657637 From paf@frobbit.se Sat Nov 24 16:23: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 D388B21F8568 for ; Sat, 24 Nov 2012 16:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 yt7646gkt0-A for ; Sat, 24 Nov 2012 16:23:11 -0800 (PST) Received: from srv01.frobbit.se (ns2.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id ED39821F8505 for ; Sat, 24 Nov 2012 16:23:10 -0800 (PST) Received: from [192.168.1.40] (frobbit.cust.teleservice.net [85.30.128.225]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 492EA179612CF; Sun, 25 Nov 2012 01:23:08 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <5adcc27caa0ebeebe886329a572a8f86@hethane.se> Date: Sun, 25 Nov 2012 01:23:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4553F589-ED2E-4A36-A51F-0E224030EF68@frobbit.se> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <5adcc27caa0ebeebe886329a572a8f86@hethane.se> To: Mikael Nordfeldth X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 00:23:12 -0000 On 24 nov 2012, at 18:10, Mikael Nordfeldth wrote: > However arguably not something that can be implemented reliably in = many DNS clients in use today. The reason why I rise this over and over again is that YES, I do know = that dns hosting providers do not support SRV, and yes, I do know that = Java Script and other things do not support SRV. But, to me I have heard this for so many years (>10) that it seems weird = that people still complain about it and say they must do overrides in = higher layers in the protocol stack than fix the very very few places = where SRV is not supported. I.e. how many places do SRV support have to be added compared with the = number of implementations that have to implement whatever is to = implement the work around the lack of support for SRV? And, regarding for example dns hosting providers, if you want SRV, why = do you not search for a dns hosting provider that support SRV instead of = "just" using the closest/cheapest/whatever than looking for one that do = support SRV? Unless one do not search for one, the market economy forces = that drives innovation and our economy as a whole does not work very = well. So, to conclude, yes, I do know SRV is not supported in some key systems = out there. And even worse with other newer resource record types. I am just surprised people do use these "bugs" as arguments still. I.e. SRV was first specified in RFC 2052, released in october 1996. I = mean, for how long time is it ok to claim it is a "new thing" that = people have not implemented it, and when will people require it? 1996 is now 16 years go! I mean, whats the problem? About time to implement it, or? Patrik From marc.blanchet@viagenie.ca Sat Nov 24 17: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 8382621F8594 for ; Sat, 24 Nov 2012 17:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.245 X-Spam-Level: X-Spam-Status: No, score=-102.245 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 KT0uWkGG5kx1 for ; Sat, 24 Nov 2012 17:17:57 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBE721F8550 for ; Sat, 24 Nov 2012 17:17:57 -0800 (PST) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5E3274679D; Sat, 24 Nov 2012 20:17:55 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_26C3A7EA-1972-4BDF-A427-ADB9A8D75849" From: Marc Blanchet In-Reply-To: <4553F589-ED2E-4A36-A51F-0E224030EF68@frobbit.se> Date: Sat, 24 Nov 2012 20:17:54 -0500 Message-Id: References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <5adcc27caa0ebeebe886329a572a8f86@hethane.se> <4553F589-ED2E-4A36-A51F-0E224030EF68@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1283) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 01:17:57 -0000 --Apple-Mail=_26C3A7EA-1972-4BDF-A427-ADB9A8D75849 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-11-24 =E0 19:23, Patrik F=E4ltstr=F6m a =E9crit : > On 24 nov 2012, at 18:10, Mikael Nordfeldth wrote: >=20 > I.e. SRV was first specified in RFC 2052, released in october 1996. I = mean, for how long time is it ok to claim it is a "new thing" that = people have not implemented it, and when will people require it? >=20 > 1996 is now 16 years go! >=20 > I mean, whats the problem? >=20 > About time to implement it, or? well, it is implemented and heavily in use for 80% of the tablet market, = 33% of smartphone market and 15% of the laptop market. ;-) Marc. >=20 > Patrik >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_26C3A7EA-1972-4BDF-A427-ADB9A8D75849 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 24 nov 2012, at 18:10, Mikael = Nordfeldth <mmn@hethane.se> = wrote:

I.e. SRV was first specified in RFC 2052, = released in october 1996. I mean, for how long time is it ok to claim it = is a "new thing" that people have not implemented it, and when will = people require it?

1996 is now 16 years go!

I mean, whats = the problem?

About time to implement it, = or?

well, it is implemented = and heavily in use for 80% of the tablet market, 33% of smartphone = market and 15% of the laptop = market.

;-)

Marc.
<= br>

=   Patrik

_______________________________________________<= br>apps-discuss mailing list
apps-discuss@ietf.org
https:/= /www.ietf.org/mailman/listinfo/apps-discuss
= --Apple-Mail=_26C3A7EA-1972-4BDF-A427-ADB9A8D75849-- From johnl@iecc.com Sat Nov 24 18:00: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 0096321F8570 for ; Sat, 24 Nov 2012 18:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.128 X-Spam-Level: X-Spam-Status: No, score=-105.128 tagged_above=-999 required=5 tests=[AWL=-4.388, BAYES_20=-0.74, 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 LuOh38YuM04R for ; Sat, 24 Nov 2012 18:00:17 -0800 (PST) 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 2EC8921F8550 for ; Sat, 24 Nov 2012 18:00:16 -0800 (PST) Received: (qmail 80541 invoked from network); 25 Nov 2012 02:00:14 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Nov 2012 02:00:14 -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=50b17bae.xn--btvx9d.k1211; i=johnl@user.iecc.com; bh=Oggxu4smYefcuxr58isbW5WbIduOxrJYCxKDTTAFj0Q=; b=QJBUCWMRMQF7nzfBM1vDSAWJl0d4VD+2dKOwXNFgasIgRLqKS3k+ZwgCR2nKsiDUvHPB2tNi4jpzcgmx2VLbdU0YpXKIDOZQtPsPcCIRbxMH99IJrUxT42RwgQhrqtCblitn7hiywXH5UzrOHAVJpKi04+2kr//tVwf4BlcbXU0= 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=50b17bae.xn--btvx9d.k1211; olt=johnl@user.iecc.com; bh=Oggxu4smYefcuxr58isbW5WbIduOxrJYCxKDTTAFj0Q=; b=SLe/TEzpEKMQxckBCXsx5nsIX1wxehwV6YbxJsZpc1dDijgQMYqaWPzoRHk+acwaxPY7GME+Y/vgK2julkB5ByXrPWreVlmNyiH82dmM7GkAc17kjORDm8qCpLphGxe3LsQX//KzkKjL9xaY7mSgobswhPey85+RFMgeuSZqkN8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Nov 2012 01:59:51 -0000 Message-ID: <20121125015951.68809.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <4553F589-ED2E-4A36-A51F-0E224030EF68@frobbit.se> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 02:00:18 -0000 >I.e. how many places do SRV support have to be added compared with the >number of implementations that have to implement whatever is to >implement the work around the lack of support for SRV? In practice, just one, in Javascript. If there were demand for SRV records, DNS providers would figure out how to handle them, just like they did for TXT records when SPF and DKIM became popular. The problem isn't a technical one, it's a social one. Even compared to the rest of the IETF, the DNS crowd has remarkably poor social skills. I think it would be dandy if one could do SRV lookups from Javascript, since it would make a bunch of other service discovery problems easier, such as the ones we're looking at in WEIRDS (with arguments not unlike the ones here.) But if after 16 years, the people who maintain Javascript are unpersuaded that would be worth tneir time to add SRV lookups, it's not because they are stupid. (We can discuss all the ways the DNS crowd shoot themselves in the foot somewhere else.) >I am just surprised people do use these "bugs" as arguments still. >1996 is now 16 years go! >I mean, whats the problem? >About time to implement it, or? Well, OK. LOC is also 16 years old, and GPOS is 18 years old. So what? R's, John PS: I agree with all of Brad's arguments why a well known URL is the least bad option. From paul.hoffman@vpnc.org Sat Nov 24 18:01: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 7F97A21F8475 for ; Sat, 24 Nov 2012 18:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 ajYQiL8D7-UY for ; Sat, 24 Nov 2012 18:01:31 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A0C8321F8447 for ; Sat, 24 Nov 2012 18:01:31 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAP1pPOJ063847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 24 Nov 2012 18:51:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Sat, 24 Nov 2012 17:51:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7AF3E47A-ECCE-4530-BF9E-786845BC1278@vpnc.org> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <5adcc27caa0ebeebe886329a572a8f86@hethane.se> <4553F589-ED2E-4A36-A51F-0E224030EF68@frobbit.se> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1499) Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 02:01:32 -0000 On Nov 24, 2012, at 5:17 PM, Marc Blanchet = wrote: > Le 2012-11-24 =E0 19:23, Patrik F=E4ltstr=F6m a =E9crit : >> On 24 nov 2012, at 18:10, Mikael Nordfeldth wrote: >>=20 >> I.e. SRV was first specified in RFC 2052, released in october 1996. I = mean, for how long time is it ok to claim it is a "new thing" that = people have not implemented it, and when will people require it? >>=20 >> 1996 is now 16 years go! >>=20 >> I mean, whats the problem? >>=20 >> About time to implement it, or? >=20 > well, it is implemented and heavily in use for 80% of the tablet = market, 33% of smartphone market and 15% of the laptop market. ...but 0% of the JavaScript market. JavaScript in browsers, *by design*, = has no ability to send requests other than HTTP. There is no equivalent = of gethostbyname(), much less getsomednsrrtype(). If you want JavaScript to be a general-purpose language with the ability = open TCP/UDP sockets at will, that's fine, but that would invoke a very = different security model for JavaScript. --Paul Hoffman= From jasnell@gmail.com Sat Nov 24 19:08: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 2762621F8550 for ; Sat, 24 Nov 2012 19:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.689 X-Spam-Level: X-Spam-Status: No, score=-3.689 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 Y4T-QGFH4eY1 for ; Sat, 24 Nov 2012 19:08:50 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7C521F854E for ; Sat, 24 Nov 2012 19:08:50 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so8063439ieb.31 for ; Sat, 24 Nov 2012 19:08:49 -0800 (PST) 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=g9AiqkpY1dGLAE2xEXZWXkAOcz3lF6hriXXKdujctG8=; b=loYemPCXlGL7DcGMlQqEMRS5otVp8K90bcj4M7fNWmc/6jMVlC8u6iYw6UeNBWSm3P 5rHh8t6WZxzzWLK0mnlQGw+1N+qd1uiGnqSPAemQeKyd9CLfON1Zmq+lu3+l6zYAfpsU jUhRW8nSnu4No2CyCm4/45uZUEqShwhPeSaJb+IOUULET2Xk4Llke4DS0xXoK962HK7f Cxt0CxD50qKxS6BaQRdq+HCQFB4gaKvpcwuGMB3t/W5povBlDNh4wgbw+YBQ4LV3AEs2 jibhYvRgFhQ9D5xnUqREnvZefD18bbhUOLIqfEYlLoktg4TdEkf7ZdB3odpywp6LyfGr liLg== Received: by 10.50.53.147 with SMTP id b19mr7533633igp.12.1353812929685; Sat, 24 Nov 2012 19:08:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.225 with HTTP; Sat, 24 Nov 2012 19:08:29 -0800 (PST) In-Reply-To: <7AF3E47A-ECCE-4530-BF9E-786845BC1278@vpnc.org> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <5adcc27caa0ebeebe886329a572a8f86@hethane.se> <4553F589-ED2E-4A36-A51F-0E224030EF68@frobbit.se> <7AF3E47A-ECCE-4530-BF9E-786845BC1278@vpnc.org> From: James M Snell Date: Sat, 24 Nov 2012 19:08:29 -0800 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d04339c96c429a304cf4922b8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 03:08:51 -0000 --f46d04339c96c429a304cf4922b8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Nov 24, 2012 at 5:51 PM, Paul Hoffman wrote= : > On Nov 24, 2012, at 5:17 PM, Marc Blanchet > wrote: > > > Le 2012-11-24 =C3=A0 19:23, Patrik F=C3=A4ltstr=C3=B6m a =C3=A9crit : > >> On 24 nov 2012, at 18:10, Mikael Nordfeldth wrote: > >> > >> I.e. SRV was first specified in RFC 2052, released in october 1996. I > mean, for how long time is it ok to claim it is a "new thing" that people > have not implemented it, and when will people require it? > >> > >> 1996 is now 16 years go! > >> > >> I mean, whats the problem? > >> > >> About time to implement it, or? > > > > well, it is implemented and heavily in use for 80% of the tablet market= , > 33% of smartphone market and 15% of the laptop market. > > ...but 0% of the JavaScript market. JavaScript in browsers, *by design*, > has no ability to send requests other than HTTP. There is no equivalent o= f > gethostbyname(), much less getsomednsrrtype(). > > Indeed... that does not necessarily mean the browser could not provide indirect mechanisms for sending such requests. A simple name lookup api with an implementation managed by the browser could prove to be quite useful for a range of problems. It does come down to demand, however. The browser vendors are not going to implement support for anything that there is not an obvious demand for. WebFinger, by itself, would not be enough to drive such demand, I think, but there are other efforts that might (such as http/2). - James > If you want JavaScript to be a general-purpose language with the ability > open TCP/UDP sockets at will, that's fine, but that would invoke a very > different security model for JavaScript. > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d04339c96c429a304cf4922b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Sat, Nov 24, 2012 at 5:51 PM, Paul Ho= ffman <paul.hoffman@vpnc.org> wrote:
On Nov 24, 2012, at 5:17 P= M, Marc Blanchet <marc.blan= chet@viagenie.ca> wrote:

> Le 2012-11-24 =C3=A0 19:23, Patrik F=C3=A4ltstr=C3=B6m a =C3=A9crit :<= br> >> On 24 nov 2012, at 18:10, Mikael Nordfeldth <mmn@hethane.se> wrote:
>>
>> I.e. SRV was first specified in RFC 2052, released in october 1996= . I mean, for how long time is it ok to claim it is a "new thing"= that people have not implemented it, and when will people require it?
>>
>> 1996 is now 16 years go!
>>
>> I mean, whats the problem?
>>
>> About time to implement it, or?
>
> well, it is implemented and heavily in use for 80% of the tablet marke= t, 33% of smartphone market and 15% of the laptop market.

...but 0% of the JavaScript market. JavaScript in browsers, *by desig= n*, has no ability to send requests other than HTTP. There is no equivalent= of gethostbyname(), much less getsomednsrrtype().


Indeed... that does not necessarily me= an the browser could not provide indirect mechanisms for sending such reque= sts. A simple name lookup api with an implementation managed by the browser= could prove to be quite useful for a range of problems. It does come down = to demand, however. The browser vendors are not going to implement support = for anything that there is not an obvious demand for. WebFinger, by itself,= would not be enough to drive such demand, I think, but there are other eff= orts that might (such as http/2).

- James
=C2=A0
If you want JavaScript to be a general-purpose language with the ability op= en TCP/UDP sockets at will, that's fine, but that would invoke a very d= ifferent security model for JavaScript.

--Paul Hoffman
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--f46d04339c96c429a304cf4922b8-- From johnl@iecc.com Sat Nov 24 20:04: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 045B921F852A for ; Sat, 24 Nov 2012 20:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.906 X-Spam-Level: X-Spam-Status: No, score=-105.906 tagged_above=-999 required=5 tests=[AWL=-3.307, 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 C-PFES6yP7zx for ; Sat, 24 Nov 2012 20:04:02 -0800 (PST) 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 5957721F854E for ; Sat, 24 Nov 2012 20:04:02 -0800 (PST) Received: (qmail 5112 invoked from network); 25 Nov 2012 04:04:00 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Nov 2012 04:04:00 -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=50b198b0.xn--i8sz2z.k1211; i=johnl@user.iecc.com; bh=9ovNOr1HimQsF/L+xwREXAKyx2GBi/H0iKDHxxgqcV8=; b=Namqn0ve2B/Mn90ie9SKAWUnHyXbCrFbBWZ27BJDtshM4S8UQoIHpmAvZUten+iFUOvtbXwq+dlIBq7Mv9WkeOezIDIl/khe5jnyHoqm6OoaOHaFvP9bGHLjH4i/7CPYs1y7pH25jIASh6GtTHplZjjPokSQrGZHPfypVtK4bHw= 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=50b198b0.xn--i8sz2z.k1211; olt=johnl@user.iecc.com; bh=9ovNOr1HimQsF/L+xwREXAKyx2GBi/H0iKDHxxgqcV8=; b=JlT90Hvv73NMUJbStibWvy5cChTsOiOBXKp4lhlYz5XpOB7V265tO9VKASzyU4EqKB92JJrW0sZXe7uWL4o5f0lXFX1w2RGFf7pkBe4sd+HBao1GSFzw12ZgwR98HkNPwHt1xO4MMV8+xPtQUh+lkQVAaJ+aTFY43TaVrdvJhM8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Nov 2012 04:03:37 -0000 Message-ID: <20121125040337.72910.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Javascript and SRV, was draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 04:04:04 -0000 >> ...but 0% of the JavaScript market. JavaScript in browsers, *by design*, >> has no ability to send requests other than HTTP. There is no equivalent of >> gethostbyname(), much less getsomednsrrtype(). >> >Indeed... that does not necessarily mean the browser could not provide >indirect mechanisms for sending such requests. ... Note those words *by design*. Javascript has a security model which, as far as I can tell, the people complaining that it doesn't do SRV don't realize that they don't understand. It is not a bug that Javascript scripts running in browsers can't go randomly opening ports and devices. It may be the case that it's possible to add SRV lookups and not break the security model, although it's not obvious to me how that interacts with the same-origin rule. Poking around on the net, I don't see anyone who's written anything about that. It'd be a good place to start if one were serious. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From ajs@anvilwalrusden.com Sat Nov 24 20:04: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 C930A21F857C for ; Sat, 24 Nov 2012 20:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.794 X-Spam-Level: X-Spam-Status: No, score=-0.794 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 cg0seb+37fXR for ; Sat, 24 Nov 2012 20:04:53 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 62A4021F852A for ; Sat, 24 Nov 2012 20:04:53 -0800 (PST) Received: from mx1.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 E96FB8A031 for ; Sun, 25 Nov 2012 04:04:51 +0000 (UTC) Date: Sat, 24 Nov 2012 23:04:50 -0500 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20121125040449.GC58516@mx1.yitter.info> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <5adcc27caa0ebeebe886329a572a8f86@hethane.se> <4553F589-ED2E-4A36-A51F-0E224030EF68@frobbit.se> <7AF3E47A-ECCE-4530-BF9E-786845BC1278@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7AF3E47A-ECCE-4530-BF9E-786845BC1278@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 04:04:53 -0000 On Sat, Nov 24, 2012 at 05:51:25PM -0800, Paul Hoffman wrote: > If you want JavaScript to be a general-purpose language with the > ability open TCP/UDP sockets at will, that's fine, but that would > invoke a very different security model for JavaScript. But at bottom, what the current discussion says is, "We want JavaScript to be a full-force application writing language, but we don't want all the crap that comes with that in our language, so we want to add these three warts to the Internet instead." As a personal disposition, I'm not opposed to warts where the virus is dug in. But this really is a basic architectural question for the Area: do we even have a way of thinking coherently about the kinds of applications that are written with deliberately-hobbled languages, but that are widely deployed and broadly useful? The debate on this topic seems to say, "No." Maybe that's our problem. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From jasnell@gmail.com Sat Nov 24 20:11: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 7F34D21F8534 for ; Sat, 24 Nov 2012 20:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.685 X-Spam-Level: X-Spam-Status: No, score=-3.685 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 fHq6UIF1E6-e for ; Sat, 24 Nov 2012 20:11:52 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 61A0D21F84F3 for ; Sat, 24 Nov 2012 20:11:52 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so8089452ieb.31 for ; Sat, 24 Nov 2012 20:11:51 -0800 (PST) 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=5lPuuuCN4Vd9I0dzgha1j1Glvw87JgJvpFCJc8lRZRM=; b=ub96RgeyfxlGBxo13wbiFKH0zVelXJDpBW7ZbvbTep+TphJ1GiXtX3HS8D4ksZEJha hbeQIYkdu6CNrxMI4bUr3D1Lp1RuKwHPmzizGG21HY57DD10xaB5eYA2ubaiq/pznvhr i5CGaOjSEtVFHMHO88JcR0XmvwrSY7buVxfcsR+UHj7G8Xr24CWrzv+mYMUqdZokpq5u GKs5mt1DL/fgr4kz+l8bXXqLm7N7cv4fKo6Rcigep93Tjswk8WTDZLTwpoF1FhXCjqEB /YxGxbe1Yu39bWeDCnei9KRocxdYH+HJiPL7hu0608VeEukp91nxQCKIr2wL/n3p9NVN 8YBg== Received: by 10.50.222.233 with SMTP id qp9mr7551620igc.61.1353816711550; Sat, 24 Nov 2012 20:11:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.225 with HTTP; Sat, 24 Nov 2012 20:11:31 -0800 (PST) In-Reply-To: <20121125040337.72910.qmail@joyce.lan> References: <20121125040337.72910.qmail@joyce.lan> From: James M Snell Date: Sat, 24 Nov 2012 20:11:31 -0800 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=14dae93406d72ed8a604cf4a0448 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Javascript and SRV, was draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 04:11:53 -0000 --14dae93406d72ed8a604cf4a0448 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 24, 2012 at 8:03 PM, John Levine wrote: > >> ...but 0% of the JavaScript market. JavaScript in browsers, *by design*, > >> has no ability to send requests other than HTTP. There is no equivalent > of > >> gethostbyname(), much less getsomednsrrtype(). > >> > >Indeed... that does not necessarily mean the browser could not provide > >indirect mechanisms for sending such requests. ... > > Note those words *by design*. Javascript has a security model which, > as far as I can tell, the people complaining that it doesn't do SRV > don't realize that they don't understand. It is not a bug that > Javascript scripts running in browsers can't go randomly opening ports > and devices. > > It may be the case that it's possible to add SRV lookups and not break > the security model, although it's not obvious to me how that interacts > with the same-origin rule. Poking around on the net, I don't see > anyone who's written anything about that. It'd be a good place to start > if one were serious. > > > The short version is that javascript should, in no way, be allowed to work with raw ports within the browser. However, the browser is already doing DNS lookups... a fairly simple API can be provided to allow javascript to tap into that mechanism... something along the lines of.. var nq = new NameQuery(".example.org",[NameQuery.SRV,NameQuery.CNAME], callback) Where the browser takes care of the details of interacting with the dns and just passes the results off to the javascript. This allows the browser to Do The Right Thing when it comes to managing security while giving the javascript code access to the basic details. Seems simple enough. - James > > -- > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. http://jl.ly > --14dae93406d72ed8a604cf4a0448 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Sat, Nov 24, 2012 at 8:03 PM, John Le= vine <johnl@taugh.com> wrote:
>> ...but 0% of the JavaScript market.= JavaScript in browsers, *by design*,
>> has no ability to send requests other than HTTP. There is no equiv= alent of
>> gethostbyname(), much less getsomednsrrtype().
>>
>Indeed... that does not necessarily mean the browser could not provide<= br> >indirect mechanisms for sending such requests. ...

Note those words *by design*. =C2=A0Javascript has a security model which,<= br> as far as I can tell, the people complaining that it doesn't do SRV
don't realize that they don't understand. =C2=A0It is not a bug tha= t
Javascript scripts running in browsers can't go randomly opening ports<= br> and devices.

It may be the case that it's possible to add SRV lookups and not break<= br> the security model, although it's not obvious to me how that interacts<= br> with the same-origin rule. =C2=A0Poking around on the net, I don't see<= br> anyone who's written anything about that. =C2=A0It'd be a good plac= e to start
if one were serious.



The short version is tha= t javascript should, in no way, be allowed to work with raw ports within th= e browser. However, the browser is already doing DNS lookups... a fairly si= mple API can be provided to allow javascript to tap into that mechanism... = something along the lines of..

=C2=A0 var nq =3D new NameQuery(".example.org",[NameQuery.SRV,NameQuery.CNAME], callb= ack)

Where the browser takes care of the details o= f interacting with the dns and just passes the results off to the javascrip= t. This allows the browser to Do The Right Thing when it comes to managing = security while giving the javascript code access to the basic details.

Seems simple enough.

- James
=C2=A0
=
--
Regards,
John Levine, johnl@iecc.com, Primary = Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

--14dae93406d72ed8a604cf4a0448-- From johnl@iecc.com Sat Nov 24 20:31: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 4EEE821F84D0 for ; Sat, 24 Nov 2012 20:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[AWL=-3.197, 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 H93MJ4d2aYPz for ; Sat, 24 Nov 2012 20:31:08 -0800 (PST) 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 05DB421F84C5 for ; Sat, 24 Nov 2012 20:31:01 -0800 (PST) Received: (qmail 10389 invoked from network); 25 Nov 2012 04:31:00 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Nov 2012 04:31:00 -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=50b19f04.xn--btvx9d.k1211; i=johnl@user.iecc.com; bh=/9lQknTXv/tuppMt2VB0Sgi78GtbzVxcH+DzwD1oYEI=; b=hdlikXG7LhSijkEQeWWk8EsGbqrf1b4Og+MegvlDSx3h7gWA1BaZQvpzxu61W4O0CA+W8PiM+6Phga4ALXTiY55jVo2crgmRel8K5zKV/uS7l8Ig0eqhzkg5oDx2dFv/QzyCg0vw/K0v0b1qPKa+ovULM5SpScXyghRTaBStGmQ= 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=50b19f04.xn--btvx9d.k1211; olt=johnl@user.iecc.com; bh=/9lQknTXv/tuppMt2VB0Sgi78GtbzVxcH+DzwD1oYEI=; b=h4g9l6a8tc2FEWWftACyBsUE3kvfucmaH/pFhzh/MaPM60VWyb2UsTtBoMsXrhEVCzQ4DSGhwmAYiUpvf62bN6+QoXKmnbkTnf/mOQ5fpjJecdDX2ujn3sjKcZcp7mIzJVbZSvv+OBd/qM+gAn9qG/EAX9W32euZcX1ZrwT4J5c= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Nov 2012 04:30:37 -0000 Message-ID: <20121125043037.73961.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Javascript and SRV, was draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 04:31:09 -0000 > var nq = new NameQuery(".example.org",[NameQuery.SRV,NameQuery.CNAME], >callback) > >Where the browser takes care of the details of interacting with the dns and >just passes the results off to the javascript. This allows the browser to >Do The Right Thing when it comes to managing security while giving the >javascript code access to the basic details. > >Seems simple enough. Hi. How does this work with the same origin rule? From jasnell@gmail.com Sat Nov 24 20:37: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 8BA3221F84DA for ; Sat, 24 Nov 2012 20:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.682 X-Spam-Level: X-Spam-Status: No, score=-3.682 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 i8aTgTWBG3kk for ; Sat, 24 Nov 2012 20:37:09 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB2E921F84D1 for ; Sat, 24 Nov 2012 20:37:08 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so7911482iaf.31 for ; Sat, 24 Nov 2012 20:37:08 -0800 (PST) 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=wzUde3rA+H3RexMSrIphU2oAqIak9dgmtHaewMIpTmE=; b=N84R4TetISmjg/yfgEYyejakY+2If5FlnxKNRvi9xnmBGH1Fdb19RQm5Qm2DY00iSE xu3l+I04mdV0++6LVxppNDi+XgOukyj9cjg+64oRGhPiDa8bguX4UFTLJKK0RMenO+xN Zzj5MlTGCcaMvtfGEkgafZn0J1I1MTr0qPGsafcqOxEKciwAgZGhf4waEZc7a280g9FQ xHzJpWDb2LQwQdRWhneKQFVXgFSeFgelUpIl2VALc/t7o7u/zTzDpL/k3mV97NdNM24c iuIF5T3tkCA+cD9eLvDH7oY4DjHhe0ZSZwJvcdLe9ikrEgbQEOXLHXf97eDsWMrzkBrC lDhw== Received: by 10.42.63.145 with SMTP id c17mr6893253ici.22.1353818228615; Sat, 24 Nov 2012 20:37:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.225 with HTTP; Sat, 24 Nov 2012 20:36:48 -0800 (PST) In-Reply-To: <20121125043037.73961.qmail@joyce.lan> References: <20121125043037.73961.qmail@joyce.lan> From: James M Snell Date: Sat, 24 Nov 2012 20:36:48 -0800 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=90e6ba3fcd879b6be204cf4a5e3c Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Javascript and SRV, was draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 04:37:09 -0000 --90e6ba3fcd879b6be204cf4a5e3c Content-Type: text/plain; charset=UTF-8 Generally, the same origin rule would not apply. When some piece of javascript uses the API, it's basically just asking the browser to do some additional dns resolution using the same dns server it uses for it's own resolution. The javascript does not gain access to anything more than what the browser does. What the javascript gets back is just some basic information about the name records, nothing more. The same origin rule does not come into play until the script attempts to put that information to use via ajax calls, etc. - James On Sat, Nov 24, 2012 at 8:30 PM, John Levine wrote: > > var nq = new NameQuery(".example.org",[NameQuery.SRV,NameQuery.CNAME], > >callback) > > > >Where the browser takes care of the details of interacting with the dns > and > >just passes the results off to the javascript. This allows the browser to > >Do The Right Thing when it comes to managing security while giving the > >javascript code access to the basic details. > > > >Seems simple enough. > > Hi. How does this work with the same origin rule? > > --90e6ba3fcd879b6be204cf4a5e3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Generally, the same origin rule would = not apply. When some piece of javascript uses the API, it's basically j= ust asking the browser to do some additional dns resolution using the same = dns server it uses for it's own resolution. The javascript does not gai= n access to anything more than what the browser does. What the javascript g= ets back is just some basic information about the name records, nothing mor= e. The same origin rule does not come into play until the script attempts t= o put that information to use via ajax calls, etc.=C2=A0

- James

On Sat, Nov 24, 2012 at 8:30 PM, John Levine <jo= hnl@taugh.com> wrote:
> =C2=A0var nq =3D new = NameQuery(".example.o= rg",[NameQuery.SRV,NameQuery.CNAME],
>callback)
>
>Where the browser takes care of the details of interacting with the dns= and
>just passes the results off to the javascript. This allows the browser = to
>Do The Right Thing when it comes to managing security while giving the<= br> >javascript code access to the basic details.
>
>Seems simple enough.

Hi. =C2=A0How does this work with the same origin rule?


--90e6ba3fcd879b6be204cf4a5e3c-- From johnl@taugh.com Sat Nov 24 20:49: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 B2CB621F84F0 for ; Sat, 24 Nov 2012 20:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, NO_RELAYS=-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 WkU0a5vWa7jq for ; Sat, 24 Nov 2012 20:49:19 -0800 (PST) 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 B519C21F84DE for ; Sat, 24 Nov 2012 20:49:18 -0800 (PST) Received: (qmail 13775 invoked from network); 25 Nov 2012 04:49:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=35ce.50b1a34b.k1211; bh=58jseyR9lxmAc2my9O+md4LfZP6GQ38FBDTQvohUxY8=; b=Azms4HN14UKlLLwFIn6bm7cpyl2ipxTBn7uYLayqZa9TQ7Om/YVzQ8pX4jPYWJLjja3EQcErnLX7TrKCJ6AXCDCkKlM4+bFZbzUfQ/7//Io/p5CAquCYiy6N7WRypdEOR2nxtoxLZXqH3TivMvK5XgIaxrFUf40T77dx29wxhsI= 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=35ce.50b1a34b.k1211; bh=58jseyR9lxmAc2my9O+md4LfZP6GQ38FBDTQvohUxY8=; b=uyFT/bZ1Df4Z3LQ8o20NWzN9+3BUyqCEwFuoYB10jGv2YKNGzO2htVrts4dvJ9/llnOaYh3sLoog8w26jS99Xr1ky5hBmID7trrRWy8UfGER9PZtTLYQhzKjPoIeLO+wY1Llw8SWNpMbxsXiXkfAWe07P6PwJ7Rjw/Yhg5Tpbas= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 25 Nov 2012 04:48:53 -0000 Date: 24 Nov 2012 23:49:15 -0500 Message-ID: From: "John R Levine" To: "James M Snell" In-Reply-To: References: <20121125043037.73961.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: IETF Apps Discuss Subject: Re: [apps-discuss] Javascript and SRV, was draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 04:49:19 -0000 > Generally, the same origin rule would not apply. When some piece of > javascript uses the API, it's basically just asking the browser to do some > additional dns resolution using the same dns server it uses for it's own > resolution. The javascript does not gain access to anything more than what > the browser does. What the javascript gets back is just some basic > information about the name records, nothing more. The same origin rule does > not come into play until the script attempts to put that information to use > via ajax calls, etc. Well, OK. You do a SRV lookup, you get a host name and a port number, which are probably not the host name and port number your script came from. Keeping in mind the same origin rule, what do you do with it? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From paulej@packetizer.com Sat Nov 24 22:23:08 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 879E121F84CA for ; Sat, 24 Nov 2012 22:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] 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 hN4r3so5wbGa for ; Sat, 24 Nov 2012 22:23:06 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8729221F8480 for ; Sat, 24 Nov 2012 22:23:06 -0800 (PST) Received: from [192.168.6.152] (ip-64-134-189-154.public.wayport.net [64.134.189.154]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qAP6N18f028215 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 25 Nov 2012 01:23:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353824584; bh=A6L6xelwkcoxQ906MLujAw59Nkx9uxlRl21YlI6olgs=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=fDW9mw7v37+irpNIvYwsOWR+7HSq94YwWyWGqiAHi25R1fpzad2zibsGXAN7m43tk /KApgaPSqBQPPyt9ulqbijZsT/7GlqXmeylemGvBF22/B/OnzjqzL71THFGiytuShL L160+s3Pdvz2HgFY2olnR5iKotpGEp+az8Oo/16c= User-Agent: Kaiten Mail In-Reply-To: <50B120D8.3020207@openlinksw.com> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943668FD18F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50AFF5F4.8030605@openlinksw.com> <2a1fa9d1-83ad-41db-a928-7a946cfc05f3@email.android.com> <50B0F066.5030509@openlinksw.com> <50B120D8.3020207@openlinksw.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----JUND7QYGDX6C442LAHLCX3BM4P8C9G" From: "Paul E. Jones" Date: Sun, 25 Nov 2012 01:23:00 -0500 To: Kingsley Idehen Message-ID: Cc: Brad Fitzpatrick , webfinger@googlegroups.com, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 06:23:08 -0000 ------JUND7QYGDX6C442LAHLCX3BM4P8C9G Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Kingsley, The question you ask, I would ask. How do you publish WebFinger documents in a nontypical place and expect them to be found? As few comments/questions... * Note that we only have the webfinger resource now and there is no .json part * Why could you not publish information at Dropbox or elsewhere as and provide a pointer to it via your WebFinger account? * Why wouldn't Dropbox or others provide WebFinger service? If they did, you could use the as acct link relation to then point from one account to another Paul -------- Original Message -------- From: Kingsley Idehen Sent: Sat Nov 24 14:32:40 EST 2012 To: "Paul E. Jones" Cc: webfinger@googlegroups.com, Brad Fitzpatrick , John Bradley , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 On 11/24/12 11:21 AM, Paul E. Jones wrote: > I don't understand how this would work. Suppose I write a client that > wants to look up information on a given user. Using the well-known > location, the client code is fairly simple. If we use different paths, > we'd need a discovery mechanism for the path, no? Scenario: I am an end-user with an account with a web file service provider. The service provider allows me to save files to a drive which are then Web accessible via URLs. I stumble across Webfinger and I decide I want to publish my profile data by leveraging the combined prowess of of an acct: scheme URI and a URL that denotes my profile document. How do I achieve the above if I don't have the ability to create any of the following: 1. > or 2. > . Imagine if all I had to do was create: 1. > or 2. > . I can then make either of the above discoverable by sharing these URLs via my G+, LinkedIn, Twitter etc.. provided home pages, ditto my blog home pages, and even my personal Web site home page etc.. All of this is achieved without me knowing anything about: 1. DNS server config 2. Web server config -- including redirects. I believe Webfinger fundamentally seeks to solve two critical problems for profile document authors: 1. self denotation via acct: scheme URIs 2. association self denotation with a self curated profile document -- so the acct: scheme URI basically resolves to a profile document. Right now, Webfinger is only addressing the needs of service providers whereas it could also add granularity that enables individuals exploit the protocol, especially with the prevalence of storage oriented services from the likes of: Dropbox, Amazon S3, Google Drive, Microsoft Skydrive, Box.NET, Wuala, and many others. All an end-user has to do is mount one of those services and simply save their xml or json based profile document to the Web. Webfinger application developers end up with a much richer and denser Web of Webfinger accessible profile documents, just like that :-) Kingsley > > Paul > > ------------------------------------------------------------------------ > *From:* Kingsley Idehen > *Sent:* Sat Nov 24 11:05:58 EST 2012 > *To:* webfinger@googlegroups.com > *Cc:* "Paul E. Jones" , Brad Fitzpatrick > , John Bradley , > "apps-discuss@ietf.org" > *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 > > On 11/24/12 2:13 AM, Paul E. Jones wrote: >> >> You can always redirect requests elsewhere, but if we don't have >> fixed resource locations, it makes discovery a challenge. >> >> _Paul_ >> > > Yes, but I am seeking a way to alleviate the following challenges for > end-users seeking to exploit Webfinger: > > 1. domain ownership > 2. domain name server admin privileges > 3. web server admin privileges. > > Right now, Webfinger scopes everything to the "host" in a Web realm > that is really scoped to documents (Web 1.0 and 2.0) and named > entities (Web 3.0 via Linked Data). > > Is it too costly to add "paths" to Webfinger bearing in mind the > granularity this option provides i.e., rather being aimed at service > providers (who control domain name and web servers) it also serves the > needs of profile document owners and individuals that seek full > control over their digital identities. > > The upside of this non disruptive tweak is massive. > > Kingsley > >> >> >> ------------------------------------------------------------------------ >> *From:* Kingsley Idehen >> *Sent:* Fri Nov 23 17:17:24 EST 2012 >> *To:* webfinger@googlegroups.com >> *Cc:* Brad Fitzpatrick , John Bradley >> , "apps-discuss@ietf.org" >> *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 >> >> On 11/23/12 5:09 PM, Brad Fitzpatrick wrote: >>> On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones >>> > >>> wrote: >>> >>> Thanks for writing this, John. It’s important for people to >>> understand that this is a real problem – not a theoretical >>> problem – and that the consequences of not solving the problem >>> in a practically implementable standards-based manner could once >>> again be deployment of a vendor-specific solution that locks out >>> other participants. >>> >>> >>> What's the problem? >>> >>> I missed some emails, if there were any about this. Is there >>> discussion happening on a mailing list other than apps-discuss >>> and/or webfinger@googlegroups.com ? >>> >>> We already have the /.well-known/ thing, so why do we need a >>> well-known subdomain? >>> >>> The way I see it is: >>> >>> a) If you're aren't running a webserver on the hostname => run one, >>> and respond to /.well-known/webfinger >>> b) If you are running a webserver on the hostname => respond to >>> /.well-known/webfinger >>> >>> We need to make things easier for clients, not easier for servers. >>> There will many more clients than servers, so it needs to be hard >>> to get wrong, if we want people to do the right thing. >>> >>> Let's imagine that the "webfinger" subdomain goes into the spec, but >>> no major webfinger server uses it. So now we have 99% of webfinger >>> client applications (many in JavaScript) only implementing the base >>> case and ignoring the subdomain lookup, because it always works as >>> far as they're concerned. Now new servers have no choice but to >>> respond at host.com/.well-known/webfinger >>> because most clients won't >>> work otherwise. That's where I fear this is all heading: because >>> of a misguided desired to make things easier for some hypothetical >>> server authors, we then make things complicated for everybody, even >>> though we gain nothing. >>> >>> When you have more clients than servers, I think it's important to >>> make things simple for clients. >>> >> >> All, >> >> A late in the game request. Is there any chance of >> > > and/or >> > > instead of just >> > > or >> > > ? >> >> Goal: to be able to deploy a Webfinger accessible profile document >> via the likes of Dropbox, GoogleDrive, Microsoft SkyDrive, Box.NET, >> Wuala, Amazon S3 buckets etc.. Basically, removing the HTTP server >> ownership and admin requirement by moving scope to a document path >> rather than a host. >> >> -- >> >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Company Web:http://www.openlinksw.com >> Personal Weblog:http://www.openlinksw.com/blog/~kidehen >> Twitter/Identi.ca handle: @kidehen >> Google+ Profile:https://plus.google.com/112399767740508618350/about >> LinkedIn Profile:http://www.linkedin.com/in/kidehen >> >> >> >> > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web:http://www.openlinksw.com > Personal Weblog:http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile:https://plus.google.com/112399767740508618350/about > LinkedIn Profile:http://www.linkedin.com/in/kidehen > > > > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen ------JUND7QYGDX6C442LAHLCX3BM4P8C9G Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Kingsley,

The question you ask, I would ask. How do you publish WebFinger documents in a nontypical place and expect them to be found?

As few comments/questions...
* Note that we only have the webfinger resource now and there is no .json part
* Why could you not publish information at Dropbox or elsewhere as and provide a pointer to it via your WebFinger account?
* Why wouldn't Dropbox or others provide WebFinger service? If they did, you could use the as acct link relation to then point from one account to another

Paul



From: Kingsley Idehen <kidehen@openlinksw.com>
Sent: Sat Nov 24 14:32:40 EST 2012
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: webfinger@googlegroups.com, Brad Fitzpatrick <bradfitz@google.com>, John Bradley <ve7jtb@ve7jtb.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

On 11/24/12 11:21 AM, Paul E. Jones wrote:
I don't understand how this would work. Suppose I write a client that wants to look up information on a given user. Using the well-known location, the client code is fairly simple. If we use different paths, we'd need a discovery mechanism for the path, no?

Scenario:

I am an end-user with an account with a web file service provider. The service provider allows me to save files to a drive which are then Web accessible via URLs. I stumble across Webfinger and I decide I want to publish my profile data by leveraging the combined prowess of of an acct: scheme URI and a URL that denotes my profile document.

How do I achieve the above if I don't have the ability to create any of the following:

1. <http://dropbox.com/.well-known/webfinger> or
2. <http://dropbox.com/.well-known/webfinger.json> .

Imagine if all I had to do was create:

1. <http://dropbox.com/.well-known/{my-dropbox-collection}/webfinger> or
2. <http://dropbox.com/.well-known/{my-dropbox-collection}/webfinger.json> .

I can then make either of the above discoverable by sharing these URLs via my G+, LinkedIn, Twitter etc.. provided home pages, ditto my blog home pages, and even my personal Web site home page etc.. All of this is achieved without me knowing anything about:

1. DNS server config
2. Web server config -- including redirects.

I believe Webfinger fundamentally seeks to solve two critical problems for profile document authors:

1. self denotation via acct: scheme URIs
2. association self denotation with a self curated profile document -- so the acct: scheme URI basically resolves to a profile document.

Right now, Webfinger is only addressing the needs of service providers whereas it could also add granularity that enables individuals exploit the protocol, especially with the prevalence of storage oriented services from the likes of: Dropbox, Amazon S3, Google Drive, Microsoft Skydrive, Box.NET, Wuala, and many others. All an end-user has to do is mount one of those services and simply save their xml or json based profile document to the Web.

Webfinger application developers end up with a much richer and denser Web of Webfinger accessible profile documents, just like that :-)


Kingsley


Paul

From: Kingsley Idehen <kidehen@openlinksw.com>
Sent: Sat Nov 24 11:05:58 EST 2012
To: webfinger@googlegroups.com
Cc: "Paul E. Jones" <paulej@packetizer.com>, Brad Fitzpatrick <bradfitz@google.com>, John Bradley <ve7jtb@ve7jtb.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

On 11/24/12 2:13 AM, Paul E. Jones wrote:

You can always redirect requests elsewhere, but if we don't have fixed resource locations, it makes discovery a challenge.

Paul


Yes, but I am seeking a way to alleviate the following challenges for end-users seeking to exploit Webfinger:

1. domain ownership
2. domain name server admin privileges
3. web server admin privileges.

Right now, Webfinger scopes everything to the "host" in a Web realm that is really scoped to documents (Web 1.0 and 2.0) and named entities (Web 3.0 via Linked Data).

Is it too costly to add "paths" to Webfinger bearing in mind the granularity this option provides i.e., rather being aimed at service providers (who control domain name and web servers) it also serves the needs of profile document owners and individuals that seek full control over their digital identities.

The upside of this non disruptive tweak is massive.

Kingsley



From: Kingsley Idehen <kidehen@openlinksw.com>
Sent: Fri Nov 23 17:17:24 EST 2012
To: webfinger@googlegroups.com
Cc: Brad Fitzpatrick <bradfitz@google.com>, John Bradley <ve7jtb@ve7jtb.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

On 11/23/12 5:09 PM, Brad Fitzpatrick wrote:
On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for writing this, John.  It’s important for people to understand that this is a real problem – not a theoretical problem – and that the consequences of not solving the problem in a practically implementable standards-based manner could once again be deployment of a vendor-specific solution that locks out other participants.


What's the problem?

I missed some emails, if there were any about this.  Is there discussion happening on a mailing list other than apps-discuss and/or webfinger@googlegroups.com?

We already have the /.well-known/ thing, so why do we need a well-known subdomain?

The way I see it is:

a) If you're aren't running a webserver on the hostname => run one, and respond to /.well-known/webfinger
b) If you are running a webserver on the hostname => respond to /.well-known/webfinger

We need to make things easier for clients, not easier for servers.  There will many more clients than servers, so it needs to be hard to get wrong, if we want people to do the right thing.

Let's imagine that the "webfinger" subdomain goes into the spec, but no major webfinger server uses it.  So now we have 99% of webfinger client applications (many in JavaScript) only implementing the base case and ignoring the subdomain lookup, because it always works as far as they're concerned.  Now new servers have no choice but to respond at host.com/.well-known/webfinger because most clients won't work otherwise.  That's where I fear this is all heading:  because of a misguided desired to make things easier for some hypothetical server authors, we then make things complicated for everybody, even though we gain nothing.

When you have more clients than servers, I think it's important to make things simple for clients.


All,

A late in the game request. Is there any chance of <host.com/.well-known/{path}/webfinger> and/or <host.com/{path}/.well-known/webfinger> instead of just <host.com/.well-known/webfinger> or <host.com/.well-known/webfinger> ?

Goal: to be able to deploy a Webfinger accessible profile document via the likes of Dropbox, GoogleDrive, Microsoft SkyDrive, Box.NET, Wuala, Amazon S3 buckets etc.. Basically, removing the HTTP server ownership and admin requirement by moving scope to a document path rather than a host. 

-- 

Regards,

Kingsley Idehen       
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen







-- 

Regards,

Kingsley Idehen       
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen







-- 

Regards,

Kingsley Idehen       
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
------JUND7QYGDX6C442LAHLCX3BM4P8C9G-- From paf@frobbit.se Sat Nov 24 23:45: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 02BCA21F8468 for ; Sat, 24 Nov 2012 23:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.372, 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 8aSzaRg6OxR4 for ; Sat, 24 Nov 2012 23:45:58 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 2271421F8461 for ; Sat, 24 Nov 2012 23:45:58 -0800 (PST) Received: from [192.168.1.40] (frobbit.cust.teleservice.net [85.30.128.225]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 1893617961E0F; Sun, 25 Nov 2012 08:45:50 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <7AF3E47A-ECCE-4530-BF9E-786845BC1278@vpnc.org> Date: Sun, 25 Nov 2012 08:45:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <66039A1A-10A8-4207-B4D5-F5309D8288A1@frobbit.se> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <5adcc27caa0ebeebe886329a572a8f86@hethane.se> <4553F589-ED2E-4A36-A51F-0E224030EF68@frobbit.se> <7AF3E47A-ECCE-4530-BF9E-786845BC1278@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 07:45:59 -0000 On 25 nov 2012, at 02:51, Paul Hoffman wrote: > ...but 0% of the JavaScript market. JavaScript in browsers, *by = design*, has no ability to send requests other than HTTP. There is no = equivalent of gethostbyname(), much less getsomednsrrtype(). >=20 > If you want JavaScript to be a general-purpose language with the = ability open TCP/UDP sockets at will, that's fine, but that would invoke = a very different security model for JavaScript. Maybe that is a sign that JavaScript should only be used for plain old = "web" and not do other kind of transactions like trying to send IP = packets over HTTP etc. I.e. if the design is to not do anything else than "fetch web pages", = then maybe that is where it should stop. On the other hand, if one with JavaScript want to do A and B and C = (which I hear here in this discussion) maybe something should be changed = in JavaScript. So that for example it can do WebFinger (including using = SRV records -- which btw I think JavaScript should use for "normal web = page fetching" as well). Patrik From paf@frobbit.se Sun Nov 25 02:52:55 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 BEDBC21F84D8 for ; Sun, 25 Nov 2012 02:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 5qibrcXyiDWn for ; Sun, 25 Nov 2012 02:52:55 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7C121F84D7 for ; Sun, 25 Nov 2012 02:52:54 -0800 (PST) Received: from [192.168.1.40] (frobbit.cust.teleservice.net [85.30.128.225]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id C822A179644BE; Sun, 25 Nov 2012 11:52:52 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20121125015951.68809.qmail@joyce.lan> Date: Sun, 25 Nov 2012 11:52:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <464D7FE4-33F2-4039-8B44-AE1BF50E422F@frobbit.se> References: <20121125015951.68809.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 10:52:55 -0000 On 25 nov 2012, at 02:59, "John Levine" wrote: > I think it would be dandy if one could do SRV lookups from Javascript, > since it would make a bunch of other service discovery problems > easier, such as the ones we're looking at in WEIRDS (with arguments > not unlike the ones here.) But if after 16 years, the people who > maintain Javascript are unpersuaded that would be worth tneir time to > add SRV lookups, it's not because they are stupid. Who has to do that persuasion? Is it not the users of JavaScript that want a more powerful "http = lookup" function that should ensure the call in JavaScript that is used = do not only A+AAAA lookup but also SRV? I.e. is it not part of an initiative like this, that want some service = discovery, to ensure JavaScript is doing The Right Thing? I do not think the programmer that writes JavaScript stuff should be = able to do SRV lookups or access sockets directly. The programmer should = still "only" fetch whatever data they want. It is JavaScript that should be changed. Is there anyone reading this thread that is involved in JS evolution? Patrik From romeda@gmail.com Sun Nov 25 03:33: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 7F2B121F85A9 for ; Sun, 25 Nov 2012 03:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, 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 jE8+jQQPxugt for ; Sun, 25 Nov 2012 03:33:02 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E05F21F85A5 for ; Sun, 25 Nov 2012 03:33:02 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so5252222pad.31 for ; Sun, 25 Nov 2012 03:33:00 -0800 (PST) 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=CFPtMOlK/elKunQZjpgQjT4zeOyxfq6GoCDWfu0+8z8=; b=I3HBEZIA6ig7QH0s0P47weIMYpj1kJjHWSUv2m8s0hPt9pm2gHLvPS8t+f8IVmMfkW 4COaONPXyO7Jrh0OWaMKCEPAylCrmboOO2PQzATOWkoEyZmwDbcClyxGWiv3WTMl/WYE /t/meQJEJUBdr0lDRsQLT/DEQenXHyOtfsvicGnDW7Da6u875Zm/is06h+3SyIJb7Jcy FBNO/iLMgvSpXuiCo1LHN4mapmT4W6XvEI4anFG/8Djqu9u49AnhWRjJUEuqaoNzzhnS EocT09zZFJs4vXurVGcQdfAfyi/2C9Bq1TkaItuMcYBZExCsSUlla1S5IoOWnT5SxVfT htlQ== Received: by 10.68.137.131 with SMTP id qi3mr28669556pbb.114.1353843179923; Sun, 25 Nov 2012 03:32:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.67.2.101 with HTTP; Sun, 25 Nov 2012 03:32:39 -0800 (PST) In-Reply-To: <3c86d465-fb09-416a-aa11-7ac7af1fd3fa@googlegroups.com> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <3c86d465-fb09-416a-aa11-7ac7af1fd3fa@googlegroups.com> From: Blaine Cook Date: Sun, 25 Nov 2012 11:32:39 +0000 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=047d7b2e4864d2270c04cf502d25 Cc: webfinger@googlegroups.com, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 11:33:04 -0000 --047d7b2e4864d2270c04cf502d25 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to everything Tim says here, especially the implications of the rel parameter on static hosting environments. I think Tim's suggestion that for very small domains, just listing out each user as a static file is a great / simple alternative to the host-meta template redirect that I've been advocating for. b. On 24 November 2012 06:32, Tim Bray wrote: > Oops, I replied to this but hadn=E2=80=99t bothered to join the mailing l= ist > first, so it bounced. Here it is again: > > Notes on draft-ietf-appsawg-webfinger-04.txt > > Sorry for coming late to the party. This the first webfinger draft that > I=E2=80=99ve ever read, and I=E2=80=99m almost completely ignorant of the= history. Having > said that, sometimes a history-free pair of eyes looking at something can > add value. > > [1. Introduction. ] > > Suggest shortening up, omitting the history, losing the whole first para > and beginning the second =E2=80=9CWebfinger uses the HTTP protocol to ret= rieve a > structured document containing link relations that describe people or oth= er > entities on the Internet. For a person... > > [para 2] =E2=80=9Cdirect human consumption (e.g., looking up someone=E2= =80=99s phone > number), or...=E2=80=9D > > [4. Example use of WebFinger] Tighten up 1st sentence: =E2=80=9CThis sect= ion shows > a few sample uses of Webfinger.=E2=80=9D > > [4.1 Locating a User's Blog] What is the benefit of the =E2=80=9Caliases= =E2=80=9D field? > > What is the benefit of the =E2=80=9Cacct=E2=80=9D URI scheme? Couldn=E2= =80=99t =E2=80=9Cmailto:=E2=80=9D have > been used in this case? > > [4.2 Identity Provider Discovery...] > > Since the =E2=80=9Crel=E2=80=9D parameter is optional and you can=E2=80= =99t count on it, providing > it is strictly a client-suggested optimization? Feels quite likely to be > premature, to me. > > In particular, I=E2=80=99m thinking of my own small-scale domains like > textuality.com and tbray.org, which have a single-digit number of > accounts. I could drop static JRD files into a small number of files wit= h > names like /.well-known/webfinger?**resource=3Dmailto:tbray@**textuality.= comand do webfinger very cheaply. The existence of th= e =E2=80=9Crel=E2=80=9D parameter means I > can=E2=80=99t solve this problem statically. > > [4.4 Retrieving Device Information] > > I have to say this feels fanciful. Any time an example requires inventing > a new URI scheme, I suggest that=E2=80=99s a symptom of trying too hard. > > [5.1, first para] > > I hate to be pedantic, but when you say =E2=80=9Cparameter=E2=80=9D, you= =E2=80=99re talking about > the &-separated name-value pairs in the =E2=80=9Cquery=E2=80=9D [RFC3986]= part of a URI. > Fine enough, and it=E2=80=99s a common usage, but I don=E2=80=99t actual= ly know where it's > defined (not in 3986) so either we need to find a definition and link to > it, or invest a paragraph in saying what you mean > > [5.1] =E2=80=9CWebFinger servers MUST return JRD documents as the default > representation...=E2=80=9D What does =E2=80=9Cdefault=E2=80=9D mean? Are= we saying that servers > MUST return JRD? If so, say so. > > [5.1] Last two paragraphs are perhaps superfluous? Since it=E2=80=99s HT= TP, don=E2=80=99t > you get this for free? > > [5.2] =E2=80=9CAny array elements within the "links" array are presented = by the > server in order of preference.=E2=80=9D Huh? Don't understand. > > [5.2] =E2=80=9CThe "template" element is forbidden=E2=80=9C? Huh? The s= pec doesn=E2=80=99t > define any semantic for this element. You probably need a policy on > unknown fields. For example: > (a) =E2=80=9CSoftware must ignore any fields found in the JRD which are n= ot > specified here=E2=80=9D (a.k.a. MUST_IGNORE) > (b) =E2=80=9CIt is forbidden for any elements not specified here to appea= r in a > JRD=E2=80=9C (a.k.a. maximally brittle) > The special processing for =E2=80=9Ctemplate=E2=80=9D is just weird. If = it=E2=80=99s required for > some good reason, give the reason. > > [5.2] The fact that =E2=80=9Ctitles=E2=80=9D is allowed but has no specif= ied semantics is > troublesome. Explain or remove? > [5.2] The fact there is no discussion of what you might use =E2=80=9Cprop= erties=E2=80=9D > for, nor any discussion of its structure, is troublesome. Do we have > actual users of this? Explain or remove? > > [5.3] =E2=80=9CThe purpose of the "rel" parameter is to return a subset o= f > resource's link relations. It is not intended to reduce the work=E2=80= =9D Could > this be motivated a bit? Why would you want a subset, aside from reducin= g > the work? > > [5.3] The restated example doesn=E2=80=99t really add value here, I think= . How the > =E2=80=9Crel=E2=80=9D parameter works is simple enough. > > [5.4] Two problems: First, this section fails to convince me that the > =E2=80=9Cacct=E2=80=9D scheme is worth the effort. Second, the section co= uld simply say > that the URI used to identify the entity being queried is not tied to any > scheme; the arm-waving about the hypothetical wonderfulnesss of > =E2=80=9Cacct:=E2=80=9D is a waste of space. Then having done that, the = section could be > replaced by a one-line note in section 5.1 > > [5.5] Really? Do we have any hard data that convinces us that there=E2= =80=99s an > interesting class of organizations that (a) want to offer WebFinger > and (b) can=E2=80=99t access their root and (c) can easily set up a subdo= main? > > [6] =E2=80=9CEnterprise=E2=80=9D?! What does that word mean? Also there= =E2=80=99s a contradiction > between the sentence saying you have to use =E2=80=9C*=E2=80=9D and the n= ext paragraph > saying something more restrictive is OK. Might it be better to just say > =E2=80=9CWebFinger may not be usable from code running in > browsers due to Origin policies; therefore, the use of CORS headers is > required. The header =E2=80=9CAccess-Control-Allow-Origin: * =E2=80=9D wi= ll maximize > usability; certain organizations may wish to control access to WebFinger > with a more restrictive Access-Control-Allow-Origin value. > > [7. Access Control] This section could be dropped, or replaced with a > short paragraph noting that since WebFinger is based on HTTP, implemento= rs > will need to deal with the possibility that the origin server may impose > access control policies or simply refuse access. > > [8.] This section could be dropped. This is an HTTP-based service and w= e > can assume that implementors should be prepared to handle > HTTP-standard redirect semantics. The caution about not redirecting to a > /.well-known somewhere else seems of questionable value, since I might > actually want to have a common webfinger which returns the same values fo= r > any X whether it's X@example.com, X@example.net, or whatever, and I could > do that efficiently by having a /.well-known on one of them and redirecti= ng > to it from the others. > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --047d7b2e4864d2270c04cf502d25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to everything Tim says here, especially the implications of the rel para= meter on static hosting environments. I think Tim's suggestion that for= very small domains, just listing out each user as a static file is a great= / simple alternative to the host-meta template redirect that I've been= advocating for.

b.


On 24 November 2012 06:32, Tim Bray <tbray@textuality.com= > wrote:
Oops, I replied to this but hadn=E2=80=99t b= othered to join the mailing list first, so it bounced.=C2=A0 Here it is aga= in:

Notes on draft-ietf-appsawg-webfinger-04.txt

Sorry for coming late to the party. This the first webfinger draft that I= =E2=80=99ve ever read, and I=E2=80=99m almost completely ignorant of the hi= story. =C2=A0Having said that, sometimes a history-free pair of eyes lookin= g at something can add value.

[1. Introduction. ]

Suggest shortening up, omitting the history, losing the whole first para an= d beginning the second =E2=80=9CWebfinger uses the HTTP protocol to retriev= e a structured document containing link relations that describe people or o= ther entities on the Internet. For a person...

[para 2] =C2=A0=E2=80=9Cdirect human consumption (e.g., looking up someone= =E2=80=99s phone number), or...=E2=80=9D

[4. Example use of WebFinger] Tighten up 1st sentence: =E2=80=9CThis sectio= n shows a few sample uses of Webfinger.=E2=80=9D

[4.1 Locating a User's Blog] What is the benefit of the =E2=80=9Caliase= s=E2=80=9D field?

What is the benefit of the =E2=80=9Cacct=E2=80=9D URI scheme? =C2=A0Couldn= =E2=80=99t =E2=80=9Cmailto:=E2=80=9D have been used in this case?

[4.2 Identity Provider Discovery...]

Since the =E2=80=9Crel=E2=80=9D parameter is optional and you can=E2=80=99t= count on it, providing it is strictly a client-suggested optimization? =C2= =A0Feels quite likely to be premature, to me.

In particular, I=E2=80=99m thinking of my own small-scale domains like textuality.com and tbray.org, which have a sing= le-digit number of accounts. =C2=A0I could drop static JRD files into a sma= ll number of files with names like /.well-known/webfinger?resource= =3Dmailto:tbray@<= u>textuality.com and do webfinger very cheaply. The existence of th= e =E2=80=9Crel=E2=80=9D parameter means I can=E2=80=99t solve this problem = statically.

[4.4 Retrieving Device Information]

I have to say this feels fanciful. Any time an example requires inventing a= new URI scheme, I suggest that=E2=80=99s a symptom of trying too hard.

[5.1, first para]

I hate to be pedantic, but when you say =E2=80=9Cparameter=E2=80=9D, you=E2= =80=99re talking about the &-separated name-value pairs in the =E2=80= =9Cquery=E2=80=9D [RFC3986] part of a URI. =C2=A0Fine enough, and it=E2=80= =99s a common usage, but I don=E2=80=99t actually know where it's defin= ed (not in 3986) so either we need to find a definition and link to it, or = invest a paragraph in saying what you mean

[5.1] =E2=80=9CWebFinger servers MUST return JRD documents as the default r= epresentation...=E2=80=9D What does =E2=80=9Cdefault=E2=80=9D mean? =C2=A0A= re we saying that servers MUST return JRD? =C2=A0If so, say so.

[5.1] Last two paragraphs are perhaps superfluous? =C2=A0Since it=E2=80=99s= HTTP, don=E2=80=99t you get this for free?

[5.2] =E2=80=9CAny array elements within the "links" array are pr= esented by the server in order of preference.=E2=80=9D =C2=A0Huh? Don't= understand.

[5.2] =E2=80=9CThe "template" element is forbidden=E2=80=9C? =C2= =A0Huh? =C2=A0The spec doesn=E2=80=99t define any semantic for this element= . You probably need a =C2=A0policy on unknown fields. For example:
(a) =E2=80=9CSoftware must ignore any fields found in the JRD which are not= specified here=E2=80=9D (a.k.a. MUST_IGNORE)
(b) =E2=80=9CIt is forbidden for any elements not specified here to appear = in a JRD=E2=80=9C (a.k.a. maximally brittle)
The special processing for =E2=80=9Ctemplate=E2=80=9D is just weird. =C2=A0= If it=E2=80=99s required for some good reason, give the reason.

[5.2] The fact that =E2=80=9Ctitles=E2=80=9D is allowed but has no specifie= d semantics is troublesome. =C2=A0Explain or remove?
[5.2] The fact there is no discussion of what you might use =E2=80=9Cproper= ties=E2=80=9D for, nor any discussion of its structure, is troublesome.=C2= =A0 Do we have actual users of this? =C2=A0Explain or remove?

[5.3] =E2=80=9CThe purpose of the "rel" parameter is to return a = subset of resource's link relations. =C2=A0It is not intended to reduce= the work=E2=80=9D Could this be motivated a bit? =C2=A0Why would you want = a subset, aside from reducing the work?

[5.3] The restated example doesn=E2=80=99t really add value here, I think. = How the =E2=80=9Crel=E2=80=9D parameter works is simple enough.

[5.4] Two problems: First, this section fails to convince me that the =E2= =80=9Cacct=E2=80=9D scheme is worth the effort. Second, the section could s= imply say that the URI used to identify the entity being queried is not tie= d to any scheme; the arm-waving about the hypothetical wonderfulnesss of =E2=80=9Cacct:=E2=80=9D is a waste of space. =C2=A0Then having done that, t= he section could be replaced by a one-line note in section 5.1

[5.5] Really? =C2=A0Do we have any hard data that convinces us that there= =E2=80=99s an interesting class of organizations that (a) want to offer Web= Finger
and (b) can=E2=80=99t access their root and (c) can easily set up a subdoma= in?

[6] =E2=80=9CEnterprise=E2=80=9D?! What does that word mean? =C2=A0Also the= re=E2=80=99s a contradiction between the sentence saying you have to use = =E2=80=9C*=E2=80=9D and the next paragraph saying something more restrictiv= e is OK. =C2=A0Might it be better to just say =E2=80=9CWebFinger may not be= usable from code running in
browsers due to Origin policies; therefore, the use of CORS headers is requ= ired. The header =E2=80=9CAccess-Control-Allow-Origin: * =E2=80=9D will max= imize
usability; certain organizations may wish to control access to WebFinger wi= th a more restrictive Access-Control-Allow-Origin value.

[7. Access Control] This section could be dropped, or replaced with a short= paragraph noting that since WebFinger is based on HTTP,=C2=A0 implementors= will need to deal with the possibility that the origin server may impose a= ccess control policies or simply refuse access.

[8.] =C2=A0This section could be dropped. =C2=A0This is an HTTP-based servi= ce and we can assume that implementors should be prepared to handle
HTTP-standard redirect semantics. =C2=A0The caution about not redirecting t= o a /.well-known somewhere else seems of questionable value, since I might = actually want to have a common webfinger which returns the same values for = any X whether it's X= @example.com, X@exam= ple.net, or whatever, and I could do that efficiently by having a /.wel= l-known on one of them and redirecting to it from the others.


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


--047d7b2e4864d2270c04cf502d25-- From GK@ninebynine.org Sun Nov 25 06:59: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 DDCA721F8563; Sun, 25 Nov 2012 06:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.213 X-Spam-Level: X-Spam-Status: No, score=-5.213 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_20=-0.74, 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 w4MVfXc7C1uO; Sun, 25 Nov 2012 06:59:17 -0800 (PST) Received: from relay8.mail.ox.ac.uk (relay8.mail.ox.ac.uk [129.67.1.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9D69221F855C; Sun, 25 Nov 2012 06:59:17 -0800 (PST) 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 1Tcdfw-0007rR-RC; Sun, 25 Nov 2012 14:59:16 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Tcdfw-0004nM-3j; Sun, 25 Nov 2012 14:59:16 +0000 Message-ID: <50B2095C.2000501@ninebynine.org> Date: Sun, 25 Nov 2012 12:04:44 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "uri-review@ietf.org" , "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] XMPP jabber: URI scheme not registered? 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, 25 Nov 2012 14:59:19 -0000 I've just been digging around the XMPP specs, and I notive they make reference to required namespaces of the form "jabber:client" and "jabber:server" (cf. http://tools.ietf.org/html/rfc3920#section-11.2, esp sect 11.2.2). Examples in sections 8 and 9 of that spec reinforce the indication that jabber: is being used as a URI scheme (rather than a namespace prefix). But looking at http://www.iana.org/assignments/uri-schemes.html I'm not seeing any mention of jabber:. Assuming I'm reading this right... it's probably unfortunate that that this use of jabber: has come about (like dav: before it?) but I guess it's now entrenched and should at least be registered? #g -- From paul.hoffman@vpnc.org Sun Nov 25 07:24: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 457A221F85D0 for ; Sun, 25 Nov 2012 07:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 cdk1-kn98ulr for ; Sun, 25 Nov 2012 07:24:43 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A1DF721F85CD for ; Sun, 25 Nov 2012 07:24:43 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAPFOgnN081876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 25 Nov 2012 08:24:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <20121125040449.GC58516@mx1.yitter.info> Date: Sun, 25 Nov 2012 07:24:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2628F062-2686-4ED6-B1EF-BEA61AFBF8DE@vpnc.org> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <5adcc27caa0ebeebe886329a572a8f86@hethane.se> <4553F589-ED2E-4A36-A51F-0E224030EF68@frobbit.se> <7AF3E47A-ECCE-4530-BF9E-786845BC1278@vpnc.org> <20121125040449.GC58516@mx1.yitter.info> To: "apps-discuss@ietf.org Discuss" X-Mailer: Apple Mail (2.1499) Subject: [apps-discuss] Does / Should the IETF support JavaScript as a programming platform? 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, 25 Nov 2012 15:24:44 -0000 On Nov 24, 2012, at 8:04 PM, Andrew Sullivan = wrote: > On Sat, Nov 24, 2012 at 05:51:25PM -0800, Paul Hoffman wrote: >=20 >> If you want JavaScript to be a general-purpose language with the >> ability open TCP/UDP sockets at will, that's fine, but that would >> invoke a very different security model for JavaScript. >=20 > But at bottom, what the current discussion says is, "We want > JavaScript to be a full-force application writing language, but we > don't want all the crap that comes with that in our language, so we > want to add these three warts to the Internet instead." >=20 > As a personal disposition, I'm not opposed to warts where the virus is > dug in. But this really is a basic architectural question for the > Area: do we even have a way of thinking coherently about the kinds of > applications that are written with deliberately-hobbled languages, but > that are widely deployed and broadly useful? The debate on this topic > seems to say, "No." Maybe that's our problem. Excellent summary. Your conclusion of "no" seems correct, as does "Maybe = that's our problem". --Paul Hoffman= From johnl@iecc.com Sun Nov 25 08:02: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 557BF21F8465 for ; Sun, 25 Nov 2012 08:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.693 X-Spam-Level: X-Spam-Status: No, score=-105.693 tagged_above=-999 required=5 tests=[AWL=-3.094, 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 iTPRW-1XCUDh for ; Sun, 25 Nov 2012 08:02:24 -0800 (PST) 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 CCA3C21F85C9 for ; Sun, 25 Nov 2012 08:02:23 -0800 (PST) Received: (qmail 55874 invoked from network); 25 Nov 2012 16:02:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Nov 2012 16:02:21 -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=50b2410d.xn--btvx9d.k1211; i=johnl@user.iecc.com; bh=ev/SnnmI5pvMQUBZ18OceqyCleit92f9pj56XRpkkvw=; b=uNeMsGZpUCo/P5a+mMLsQhXAdBTxb6YAa9jsEOzM05yYuUo0d6zFKH+N5e9VVjmPX8NvDsNCNBPID+L+031xCTCYqbbw8uLy9vwSPw8C2nZQOVQnLyTTAQyG5HtWAQALq1NpGJTiF7yAffAvSmR4QSSGr/ou0cAkwTxWxPz4RqY= 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=50b2410d.xn--btvx9d.k1211; olt=johnl@user.iecc.com; bh=ev/SnnmI5pvMQUBZ18OceqyCleit92f9pj56XRpkkvw=; b=qgbiKSWEv9vxoDSllDaHaq2BxnKV0j0zZS/Ne2UfR9vNzbfWJ2XNYzj8pAC8Bae3cxmJJeK1WGE80U/xXbZz+Mik3C8UObMWYY8P9kv5iKSIO+wWHfel83aPRM1x+m4pLZP5SSBhgSukIceM1Tv7AUpK4YzHNtUshmVPa2+Hloo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Nov 2012 16:01:59 -0000 Message-ID: <20121125160159.99343.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 16:02:25 -0000 >How do I achieve the above if I don't have the ability to create any of >the following: > >1. > or >2. > . The answer is to persuade your provider to support webfinger URLs, or to find a better provider. No matter what discovery scheme we decide on, there will be some existing providers that can't support it without changing something. Adding permanent warts to a design to work around a few individual providers' current limitations is never a good idea. From bradfitz@google.com Sat Nov 24 12:06: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 32A2821F8538 for ; Sat, 24 Nov 2012 12:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.647 X-Spam-Level: X-Spam-Status: No, score=-102.647 tagged_above=-999 required=5 tests=[AWL=0.329, 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 SB4Geenf0aVu for ; Sat, 24 Nov 2012 12:06:51 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCA8C21F8534 for ; Sat, 24 Nov 2012 12:06:50 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so10734956obb.31 for ; Sat, 24 Nov 2012 12:06:50 -0800 (PST) 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; bh=wofrKzawq81rO7FI7VZM7R2fqFvQGiW47AdTm4zkqb8=; b=RHl8jUxUdNAJSjpSKI2fK87PGaQga/TF1Lw6lGz01bKIDgHmpS8JRoplrFcwNUnRLR yiF2abzJ1G7fjI0k8haIpKfX0iSEPQ9HEPR0xuHf/SG0oONLQ0WXWtmtOTQBbFBBTl8K ZXkM1rTRdb5Mki1kXMy0gNp/oL4NFmP7v2B+6L7AFZWgguwIS+LbUuwzTOnNOTIN4/2u Do8ws558zIv3jEDa9+k2isJVzR4KU4Ogt+h+gWCa0ZAMJwVHsHQD7dciR2vC3S6XYnH/ wpwRXxV8A8q8nKCpz7R8nfAIsiTQ0eXDHDnnyCivtMrRuOPpUxmCSwp5aCbyBaM5qmPx dBWg== 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=wofrKzawq81rO7FI7VZM7R2fqFvQGiW47AdTm4zkqb8=; b=OYQsDQuooHp1zmcPKb2rbCnCYe8i8DbBUcrtQQnV6/ca/1cP5kIb11gbXqwu9A+9hP U+HpsvxcjQb76sJRUnfvQqTAtoEv3EL8fdkiryvZYMLsQk2qhaKBMaXStVuIXg67bCTv K4sDWask9uyq1HemWQc8FQ/LWMqTDijPd8HDeHU92r/ix1OjWPCNu90+mcwsbgmdmDHR q6bp+QHnWjVTCqDweWwRMmKv3/SxRidm1L454+FVMJKawWWHorcQdclSVUAzLnHM5J5k YQh88wTKf9z29vi6oT2OYUPHNsdgb58HGLGvtsEv/nvHZxVSJutYhBSCHuvewV31RX9C +MnA== MIME-Version: 1.0 Received: by 10.60.26.165 with SMTP id m5mr5994855oeg.4.1353787610116; Sat, 24 Nov 2012 12:06:50 -0800 (PST) Received: by 10.76.74.134 with HTTP; Sat, 24 Nov 2012 12:06:49 -0800 (PST) In-Reply-To: <50B120D8.3020207@openlinksw.com> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943668FD18F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50AFF5F4.8030605@openlinksw.com> <2a1fa9d1-83ad-41db-a928-7a946cfc05f3@email.android.com> <50B0F066.5030509@openlinksw.com> <50B120D8.3020207@openlinksw.com> Date: Sat, 24 Nov 2012 12:06:49 -0800 Message-ID: From: Brad Fitzpatrick To: Kingsley Idehen Content-Type: multipart/alternative; boundary=e89a8ff1c5cc9a309204cf433d80 X-Gm-Message-State: ALoCoQnFL2djvKJX4c1p4bgESAzKdj3mtejEyKTBsiIj68uA5TmQ7MedENilXRckxBDbHIbsTGdBFzIFcNHvwy2IAqztL1Ydp4t/nzrp5BJeZc/jJuAEktMABSz4TT+eyGoGEej/wq7uxYLYzdRKkZ1p9EI834rDv8Ns9QFTufA5bKgg/0okiF1VEVlrXh3lsDbnWbuEwO5a X-Mailman-Approved-At: Sun, 25 Nov 2012 08:23:45 -0800 Cc: webfinger@googlegroups.com, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 24 Nov 2012 20:06:53 -0000 --e89a8ff1c5cc9a309204cf433d80 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kingsley, WebFinger aims to solve exactly one problem: -- given a string that looks like "user@host.com" (which may not be an email address), -- find a metadata document for that user. When Paul kindly told you that your proposal makes "discovery" more difficult, he was asking how you meant to solve WebFinger's singular function with your path-including scheme. i.e. what are the steps to go from "user@host.com" to the final URL? It's clear that you want to host something on Dropbox, but I'm not sure it'll ever be your WebFinger document, not without Dropbox's cooperation. If you actually want to be in control of your identity, you really want your own domain name. - Brad On Sat, Nov 24, 2012 at 11:32 AM, Kingsley Idehen w= rote: > On 11/24/12 11:21 AM, Paul E. Jones wrote: > > I don't understand how this would work. Suppose I write a client that > wants to look up information on a given user. Using the well-known > location, the client code is fairly simple. If we use different paths, we= 'd > need a discovery mechanism for the path, no? > > > Scenario: > > I am an end-user with an account with a web file service provider. The > service provider allows me to save files to a drive which are then Web > accessible via URLs. I stumble across Webfinger and I decide I want to > publish my profile data by leveraging the combined prowess of of an acct: > scheme URI and a URL that denotes my profile document. > > How do I achieve the above if I don't have the ability to create any of > the following: > > 1. > > or > 2. > > . > > Imagine if all I had to do was create: > > 1. > > or > 2. > > . > > I can then make either of the above discoverable by sharing these URLs vi= a > my G+, LinkedIn, Twitter etc.. provided home pages, ditto my blog home > pages, and even my personal Web site home page etc.. All of this is > achieved without me knowing anything about: > > 1. DNS server config > 2. Web server config -- including redirects. > > I believe Webfinger fundamentally seeks to solve two critical problems fo= r > profile document authors: > > 1. self denotation via acct: scheme URIs > 2. association self denotation with a self curated profile document -- so > the acct: scheme URI basically resolves to a profile document. > > Right now, Webfinger is only addressing the needs of service providers > whereas it could also add granularity that enables individuals exploit th= e > protocol, especially with the prevalence of storage oriented services fro= m > the likes of: Dropbox, Amazon S3, Google Drive, Microsoft Skydrive, > Box.NET, Wuala, and many others. All an end-user has to do is mount one o= f > those services and simply save their xml or json based profile document t= o > the Web. > > Webfinger application developers end up with a much richer and denser Web > of Webfinger accessible profile documents, just like that :-) > > > Kingsley > > > Paul > > ------------------------------ > *From:* Kingsley Idehen > *Sent:* Sat Nov 24 11:05:58 EST 2012 > *To:* webfinger@googlegroups.com > *Cc:* "Paul E. Jones" , > Brad Fitzpatrick , John > Bradley , "apps-discuss@ietf.org"<= apps-discuss@ietf.org> > > *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 > > On 11/24/12 2:13 AM, Paul E. Jones wrote: > > You can always redirect requests elsewhere, but if we don't have fixed > resource locations, it makes discovery a challenge. > > *Paul* > > > Yes, but I am seeking a way to alleviate the following challenges for > end-users seeking to exploit Webfinger: > > 1. domain ownership > 2. domain name server admin privileges > 3. web server admin privileges. > > Right now, Webfinger scopes everything to the "host" in a Web realm that > is really scoped to documents (Web 1.0 and 2.0) and named entities (Web 3= .0 > via Linked Data). > > Is it too costly to add "paths" to Webfinger bearing in mind the > granularity this option provides i.e., rather being aimed at service > providers (who control domain name and web servers) it also serves the > needs of profile document owners and individuals that seek full control > over their digital identities. > > The upside of this non disruptive tweak is massive. > > Kingsley > > > > ------------------------------ > *From:* Kingsley Idehen > *Sent:* Fri Nov 23 17:17:24 EST 2012 > *To:* webfinger@googlegroups.com > *Cc:* Brad Fitzpatrick , John > Bradley , "apps-discuss@ietf.org"<= apps-discuss@ietf.org> > > *Subject:* Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 > > On 11/23/12 5:09 PM, Brad Fitzpatrick wrote: > > On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones = wrote: > >> Thanks for writing this, John. It=E2=80=99s important for people to un= derstand >> that this is a real problem =E2=80=93 not a theoretical problem =E2=80= =93 and that the >> consequences of not solving the problem in a practically implementable >> standards-based manner could once again be deployment of a vendor-specif= ic >> solution that locks out other participants. >> > > What's the problem? > > I missed some emails, if there were any about this. Is there discussion > happening on a mailing list other than apps-discuss and/or > webfinger@googlegroups.com? > > We already have the /.well-known/ thing, so why do we need a well-known > subdomain? > > The way I see it is: > > a) If you're aren't running a webserver on the hostname =3D> run one, an= d > respond to /.well-known/webfinger > b) If you are running a webserver on the hostname =3D> respond to > /.well-known/webfinger > > We need to make things easier for clients, not easier for servers. > There will many more clients than servers, so it needs to be hard to get > wrong, if we want people to do the right thing. > > Let's imagine that the "webfinger" subdomain goes into the spec, but no > major webfinger server uses it. So now we have 99% of webfinger client > applications (many in JavaScript) only implementing the base case and > ignoring the subdomain lookup, because it always works as far as they're > concerned. Now new servers have no choice but to respond at > host.com/.well-known/webfinger because most clients won't work otherwise. > That's where I fear this is all heading: because of a misguided desired > to make things easier for some hypothetical server authors, we then make > things complicated for everybody, even though we gain nothing. > > When you have more clients than servers, I think it's important to make > things simple for clients. > > > All, > > A late in the game request. Is there any chance of < > host.com/.well-known/{path}/webfinger> > and/or > > instead of just or < > host.com/.well-known/webfinger> ? > > Goal: to be able to deploy a Webfinger accessible profile document via th= e > likes of Dropbox, GoogleDrive, Microsoft SkyDrive, Box.NET, Wuala, Amazon > S3 buckets etc.. Basically, removing the HTTP server ownership and admin > requirement by moving scope to a document path rather than a host. > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > > > -- > > Regards, > > Kingsley Idehen=09 > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > --e89a8ff1c5cc9a309204cf433d80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
K= ingsley,

WebFinger aims to solve exactly one problem:

=C2=A0 -- given a string that looks like "user@host.com" (which may not be an em= ail address),
=C2=A0 -- find a metadata document for that user.

=
When Paul kindly told you that your proposal makes "discovery&quo= t; more difficult, he was asking how you meant to solve WebFinger's sin= gular function with your path-including scheme. =C2=A0i.e. what are the ste= ps to go from "user@host.com"= ; to the final URL?

It's clear that you want to host something on Dropb= ox, but I'm not sure it'll ever be your WebFinger document, not wit= hout Dropbox's cooperation. =C2=A0If you actually want to be in control= of your identity, you really want your own domain name.

- Brad


On Sat, Nov 24, 2012 at 11:32 AM, Kingsley Idehen <kidehen@op= enlinksw.com> wrote:
=20 =20 =20
On 11/24/12 11:21 AM, Paul E. Jones wrote:
=20 =20 I don't understand how this would work. Suppose I write a client that wants to look up information on a given user. Using the well-known location, the client code is fairly simple. If we use different paths, we'd need a discovery mechanism for the path, no= ?

Scenario:

I am an end-user with an account with a web file service provider. The service provider allows me to save files to a drive which are then Web accessible via URLs. I stumble across Webfinger and I decide I want to publish my profile data by leveraging the combined prowess of of an acct: scheme URI and a URL that denotes my profile document.

How do I achieve the above if I don't have the ability to create an= y of the following:

1. <http://dropbox.com/.well-known/webfinger> or
2. <http://dropbox.com/.well-known/webfinger.json> .

Imagine if all I had to do was create:

1. <http://dropbox.com/.well-known/{my-dropbox-collection}/webfinger>= ; or
2. <http://dropbox.com/.well-known/{my-dropbox-collection}/webfinger.json> .

I can then make either of the above discoverable by sharing these URLs via my G+, LinkedIn, Twitter etc.. provided home pages, ditto my blog home pages, and even my personal Web site home page etc.. All of this is achieved without me knowing anything about:

1. DNS server config
2. Web server config -- including redirects.

I believe Webfinger fundamentally seeks to solve two critical problems for profile document authors:

1. self denotation via acct: scheme URIs
2. association self denotation with a self curated profile document -- so the acct: scheme URI basically resolves to a profile document.

Right now, Webfinger is only addressing the needs of service providers whereas it could also add granularity that enables individuals exploit the protocol, especially with the prevalence of storage oriented services from the likes of: Dropbox, Amazon S3, Google Drive, Microsoft Skydrive, Box.NET, Wuala, and many others. All an end-user has to do is mount one of those services and simply save their xml or json based profile document to the Web.

Webfinger application developers end up with a much richer and denser Web of Webfinger accessible profile documents, just like that :-)


Kingsley


Paul

From: Kingsley Idehen <kidehen@openlinksw.com>
Sent: Sat Nov 24 11:05:58 EST 2012
To: webfinger@googlegroups.com
Cc: "Paul E. Jones" <paulej@packetizer.com>, Brad Fitzpatrick <bradfitz@google.com>, John Bradley <ve7jtb@v= e7jtb.com>, "apps-discuss@ietf.org" <apps= -discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

On 11/24/12 2:13 AM, Paul E. Jones wrote:

You can always redirect requests elsewhere, but if we don't have fixed resource locations, it makes discovery a challenge.

Paul


Yes, but I am seeking a way to alleviate the following challenges for end-users seeking to exploit Webfinger:

1. domain ownership
2. domain name server admin privileges
3. web server admin privileges.

Right now, Webfinger scopes everything to the "host" in a W= eb realm that is really scoped to documents (Web 1.0 and 2.0) and named entities (Web 3.0 via Linked Data).

Is it too costly to add "paths" to Webfinger bearing in min= d the granularity this option provides i.e., rather being aimed at service providers (who control domain name and web servers) it also serves the needs of profile document owners and individuals that seek full control over their digital identities.

The upside of this non disruptive tweak is massive.

Kingsley



From= : Kingsley Idehen <kidehen@openlinksw.com>
Sent: Fri Nov 23 17:17:24 EST 2012
To: webfinger@googlegroups.com
Cc: Brad Fitzpatrick <bradfitz@google.com>, John Bradley <ve7jtb@ve7jtb.com>, "= apps-discuss@ietf.org" <ap= ps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

On 11/23/12 5:09 PM, Brad Fitzpatrick wrote:
On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thank= s for writing this, John.=C2=A0 It=E2=80=99s importan= t for people to understand that this is a real problem =E2=80=93 not a theoretical problem =E2=80=93 and t= hat the consequences of not solving the problem in a practically implementable standards-based manner could once again be deployment of a vendor-specific solution that locks out other participants.


What's the problem?

I missed some emails, if there were any about this. =C2=A0Is there discussion happening on a mailing list other than=C2=A0apps-discuss and/or webfinger@googlegroups.com?

We already have the /.well-known/ thing, so why do we need a well-known subdomain?

The way I see it is:

a) If you're aren't running a webserver on the hostname =3D> run one, and respond to /.well-known/webfinger
b) If you are running a webserver on the hostname =3D> respond to /.well-known/webfinger

We need to make things easier for clients, not easier for servers. =C2=A0There will many more clients than server= s, so it needs to be hard to get wrong, if we want people to do the right thing.

Let's imagine that the "webfinger" subdoma= in goes into the spec, but no major webfinger server uses it. =C2=A0So now we have 99% of webfinger client applications (many in JavaScript) only implementing the base case and ignoring the subdomain lookup, because it always works as far as they're concerned. =C2=A0Now new servers have= no choice but to respond at host.com/.well-known/webfinger because most clients won't work otherwise. =C2=A0That&#= 39;s where I fear this is all heading: =C2=A0because of a misguided desired to make things easier for some hypothetical server authors, we then make things complicated for everybody, even though we gain nothing.

When you have more clients than servers, I think it'= s important to make things simple for clients.


All,

A late in the game request. Is there any chance of <host.com/.well-know= n/{path}/webfinger> and/or <host.com/{path}/.well-known/webfinger> instead of just <host.com/.well-known/webfinger> or <host.com/.well-known/webfinger> ?

Goal: to be able to deploy a Webfinger accessible profile document via the likes of Dropbox, GoogleDrive, Microsoft SkyDrive, Box.NET, Wuala, Amazon S3 buckets etc.. Basically, removing the HTTP server ownership and admin requirement by moving scope to a document path rather than a host. 

--=20

Regards,

Kingsley Idehen      =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http:/=
/www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about=

LinkedIn Profile: http://www.linkedin.com/in/kidehen







--=20

Regards,

Kingsley Idehen      =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http:/=
/www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about=

LinkedIn Profile: http://www.linkedin.com/in/kidehen







--=20

Regards,

Kingsley Idehen	     =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http:/=
/www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about=

LinkedIn Profile: http://www.linkedin.com/in/kidehen

--e89a8ff1c5cc9a309204cf433d80-- From johnl@iecc.com Sun Nov 25 08:32: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 208BE21F8599 for ; Sun, 25 Nov 2012 08:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.596 X-Spam-Level: X-Spam-Status: No, score=-105.596 tagged_above=-999 required=5 tests=[AWL=-2.997, 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 JliXKLRtYfyH for ; Sun, 25 Nov 2012 08:32:24 -0800 (PST) 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 402B321F8588 for ; Sun, 25 Nov 2012 08:32:24 -0800 (PST) Received: (qmail 62682 invoked from network); 25 Nov 2012 16:32:23 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Nov 2012 16:32:23 -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=50b24817.xn--30v786c.k1211; i=johnl@user.iecc.com; bh=6tNOlNRRZ40Ky37Bqr+JZ1zGq8cprQFONq8MjNLST8E=; b=zRYofDw2uM8iTjG4hTA9klxlMVdOMQmKZujwkWi+gP5NMqnKVdRC3j6h68caiCmwVCqnCkerpMdqwYzp56uMDMM875QcKatTqvy6AYKTwrzprV7o4ctuoW1C+hlrHOLFkTx7bqLRNXpSNNycOdxv48ZMjLvozSO1asYgFTc/Sro= 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=50b24817.xn--30v786c.k1211; olt=johnl@user.iecc.com; bh=6tNOlNRRZ40Ky37Bqr+JZ1zGq8cprQFONq8MjNLST8E=; b=n5pZR3BXdm6VPwSn6Fm/yNg+fREpgqfx5glZ50dvx+QKWXaKclPezAqQ2TdF8H+j4c+pqwXxh9sgoObLHE6u/uXiHRyNzVGcf3WEk1hfglgWnnCUSoMa3XNPL4Vh5BGY2uvg0Syqn5OczRf2X2O473wPiQaJhyTXT/OqLMRichQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Nov 2012 16:32:00 -0000 Message-ID: <20121125163200.407.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <464D7FE4-33F2-4039-8B44-AE1BF50E422F@frobbit.se> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] SRV and service discovery, draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 16:32:25 -0000 >> not unlike the ones here.) But if after 16 years, the people who >> maintain Javascript are unpersuaded that would be worth tneir time to >> add SRV lookups, it's not because they are stupid. > >Who has to do that persuasion? People who think doing SRV lookups is a good idea. You, perhaps. >I.e. is it not part of an initiative like this, that want some service >discovery, to ensure JavaScript is doing The Right Thing? Presumably, but arguments that end at "add SRV to Javascript" are not productive. It is not clear to me even at what level it would be appropriate to do SRV lookups. One possibility might be new builtin JS functions, although I don't understand at this point how that would interact with the single origin rule. Another possibility is a new URL scheme, along the lines of draft-jennings-http-srv, or more generally like this: srv[s]://example.com:foo/bar does a SRV looksup of _foo._tcp.example.com and turns the request into http[s]://:/bar (Add hand waving about what to do with the priority and weight if there are multiple answers, along the lines of what it already does with multiple A or AAAA answers.) If people think this is a good idea, they sould write it up and try implementing it in some of the open source browsers that people use. Or else stop kvetching. R's, John From jasnell@gmail.com Sun Nov 25 09:11: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 8E9C621F85D4 for ; Sun, 25 Nov 2012 09:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[AWL=-0.081, 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 KBitlZFQHNwG for ; Sun, 25 Nov 2012 09:11:48 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C8E8721F85AA for ; Sun, 25 Nov 2012 09:11:48 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so8146142iaf.31 for ; Sun, 25 Nov 2012 09:11:48 -0800 (PST) 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=5vdH5+9F8j7yguD3vEgpZOAwX9CAQP/QOUhe4MfM2cc=; b=Q9RD0UQaSeRTKgFBDpit4oAW0gU1HJNUEBUbqv+PiG62CfI+yTTxXXFXKmFNl5JChf hAPQlAWJ22K7lWLgoKBzr4vGKsP+2kiq9D9dtBphtftIhcSAoFB8jGhT+/3yNJ8aBB3M Wwc2862e/EMbxF7VrHKaZKPFVmAVCOXF94gcCxYoIo6kjAXNeSffMgp2kcIbaT9FdpAK 9LOQaWgKnmUKXaO2NxYdLXWQWwYbBmJhWWUBe58CNKKQQA+quY6mmXqcNxlwkftI5vFD R9ohS0SwYwakiMTTOz5cNJX1qjatc6c28PPxAg1doXK++SEBi1SMpwucaa4DjTJ4rtJe McwQ== Received: by 10.50.160.165 with SMTP id xl5mr8934104igb.54.1353863508160; Sun, 25 Nov 2012 09:11:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.225 with HTTP; Sun, 25 Nov 2012 09:11:27 -0800 (PST) In-Reply-To: <20121125163200.407.qmail@joyce.lan> References: <464D7FE4-33F2-4039-8B44-AE1BF50E422F@frobbit.se> <20121125163200.407.qmail@joyce.lan> From: James M Snell Date: Sun, 25 Nov 2012 09:11:27 -0800 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=14dae9340efd7a703304cf54e9a8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] SRV and service discovery, draft-ietf-appsawg-webfinger-04 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, 25 Nov 2012 17:11:49 -0000 --14dae9340efd7a703304cf54e9a8 Content-Type: text/plain; charset=UTF-8 On Sun, Nov 25, 2012 at 8:32 AM, John Levine wrote: > >> not unlike the ones here.) But if after 16 years, the people who > >> maintain Javascript are unpersuaded that would be worth tneir time to > >> add SRV lookups, it's not because they are stupid. > > > >Who has to do that persuasion? > > People who think doing SRV lookups is a good idea. You, perhaps. > > >I.e. is it not part of an initiative like this, that want some service > >discovery, to ensure JavaScript is doing The Right Thing? > > Presumably, but arguments that end at "add SRV to Javascript" are not > productive. > > It is not clear to me even at what level it would be appropriate to do > SRV lookups. One possibility might be new builtin JS functions, > although I don't understand at this point how that would interact with > the single origin rule. > > Again, it doesn't interact at all with the same origin policy. The SRV record information would be used to construct urls that contain the appropriate domain and port. How those urls are then put to use is a separate matter entirely..it's only at that point where things like the same origin policy come into play. It would be handled no differently than any other url used in the javascript code. - James > Another possibility is a new URL scheme, along the lines > of draft-jennings-http-srv, or more generally like this: > > srv[s]://example.com:foo/bar > > does a SRV looksup of > > _foo._tcp.example.com > > and turns the request into > > http[s]://:/bar > > (Add hand waving about what to do with the priority and weight if > there are multiple answers, along the lines of what it already does > with multiple A or AAAA answers.) > > If people think this is a good idea, they sould write it up and try > implementing it in some of the open source browsers that people use. > Or else stop kvetching. > > R's, > John > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --14dae9340efd7a703304cf54e9a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Nov 25, 2= 012 at 8:32 AM, John Levine <johnl@taugh.com> wrote:
>> not unlike the ones here.) =C2=A0But if after 16 years, the people= who
>> maintain Javascript are unpersuaded that would be worth tneir time= to
>> add SRV lookups, it's not because they are stupid.
>
>Who has to do that persuasion?

People who think doing SRV lookups is a good idea. =C2=A0You, perhaps.

>I.e. is it not part of an initiative like this, that want some service<= br> >discovery, to ensure JavaScript is doing The Right Thing?

Presumably, but arguments that end at "add SRV to Javascript" are= not
productive.

It is not clear to me even at what level it would be appropriate to do
SRV lookups. =C2=A0One possibility might be new builtin JS functions,
although I don't understand at this point how that would interact with<= br> the single origin rule.


Again, it doesn't interact at all = with the same origin policy. The SRV record information would be used to co= nstruct urls that contain the appropriate domain and port. How those urls a= re then put to use is a separate matter entirely..it's only at that poi= nt where things like the same origin policy come into play. It would be han= dled no differently than any other url used in the javascript code.=C2=A0

- James
=C2=A0
Another possibility is a new URL scheme, along the lines
of draft-jennings-http-srv, or more generally like this:

=C2=A0 srv[s]://example.com:foo/bar

does a SRV looksup of

=C2=A0 _foo._tcp.examp= le.com

and turns the request into

=C2=A0 http[s]://<target>:<port>/bar

(Add hand waving about what to do with the priority and weight if
there are multiple answers, along the lines of what it already does
with multiple A or AAAA answers.)

If people think this is a good idea, they sould write it up and try
implementing it in some of the open source browsers that people use.
Or else stop kvetching.

R's,
John
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--14dae9340efd7a703304cf54e9a8-- From william_john_mills@yahoo.com Sun Nov 25 09:21: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 615A721F84F0 for ; Sun, 25 Nov 2012 09:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.124 X-Spam-Level: X-Spam-Status: No, score=-17.124 tagged_above=-999 required=5 tests=[AWL=0.474, 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 QR+c4Kr8Accq for ; Sun, 25 Nov 2012 09:21:11 -0800 (PST) Received: from nm13-vm2.bullet.mail.ne1.yahoo.com (nm13-vm2.bullet.mail.ne1.yahoo.com [98.138.91.89]) by ietfa.amsl.com (Postfix) with ESMTP id 891CC21F8460 for ; Sun, 25 Nov 2012 09:21:11 -0800 (PST) Received: from [98.138.90.54] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 25 Nov 2012 17:21:01 -0000 Received: from [98.138.89.163] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 25 Nov 2012 17:21:01 -0000 Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP; 25 Nov 2012 17:21:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 951041.88252.bm@omp1019.mail.ne1.yahoo.com Received: (qmail 45486 invoked by uid 60001); 25 Nov 2012 17:21:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353864061; bh=QEM5vOa1lk30bRp1j4YKWywFVldjtQKctMkjeCrpbtk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Sn9aUlkQsZLQ3B2huKDpeZxaROuUbxpjh4BqI1Cee0x0srRs6gmPd42D6cF8JuVo+Z5UVnqLgmAz4WdXxnm7gV4KNJTCY3uvy45vB6dEpE4odSQ04hIQf/j2ycywPtwSEVTWL5+JneCOAbFe+wpPxfDuclHEXD+pdKzZsxGX2CM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=aMXmrJjAzSd303wSaZ77Hm9/5ZAkQip/E5mpQ6zNlqlyFMXElxV8gaZtPSXGrtKUIe+jDq0IrUIREZ7PA5UpnTpNBiwYNf/0r2Pp4KRSYEv8XLf5AIQ5Y0+sAv0yjFKnaDRYw6Bq2WH47zNCcoMeXBrf5FhIrhW7pPajeXv+vqQ=; X-YMail-OSG: omduOOoVM1mNSF.G7HqkVBpcF6WTFc7pQSS39mqhO4VnQ.v t0Vrw__fQF_xT0Zi60hL6qrcuNejuYYAetstbqO_L.hV8nIyrBqUwiJll0Fe nUUZSJZLGnypgJVWkSdk0D3LMWXfgxS3gqKkcfsTZWOA5G6SYuO5ms_.oj4O nJUhFVtK6vyRJ0W7iiAq9_MF4lUd6RJtH.jHr24elz2qz9NgZgsaRq.DrlH0 uc9k9NB3eU4WcQrnZ5M4EUqrV.OvKGLkj1ASWSbirv9wpJVoNhgGNCj68hoK gvxsrWGiTgMEPHbOp.6LF9Z7yd1MeUS9dKZOQVUYTxQcF0FrAFwMbDx.DB8Y jymUXX93pWYxUG4gTC0gjVFbNpKKPzuTCax0HCR0bShgFGhMLmj_vGc70kMg YLXMEB_sPTYLBxpQoa6FK2_9S0uRnCkyTq50vl4DB898ENy21q4kyTqEm7MF UVLI7aG0di9g1IecqMWjHAiFDAw4KxUpAyAkMgjjPCrWti4OeokqRGmNBRer 35jwhqofCpz.8AtH9TVXAs8i5BwVI0Zs- Received: from [99.31.212.42] by web31802.mail.mud.yahoo.com via HTTP; Sun, 25 Nov 2012 09:21:01 PST X-Rocket-MIMEInfo: 001.001, VGhlIHdheSB0byBzb2x2ZSB0aGlzIGZvciBKUyBpbiBteSBvcGluaW9uIGlzIHRvIHdyYXAgdGhpcyBpbnRvIHRoZSBYSFRUUCBoYW5kbGVyIGFuZCBoYXZlIHRoYXQgdGhpbmcgdW5kZXJzdGFuZCB3Zjogb3IgYWNjdDogc2NoZWVtcyBhbmQgZG8gdGhlIFNSViBsb29rdXAgaW5zaWRlIHRoYXQgdGhpbmcuwqAgSG93IHRoYXQgd291bGQgd29yayByaWdodCB3aXRoIHNhbWUgb3JpZ2luIGlzIHN0aWxsIGFuIGV4Y2VsbGVudCBxdWVzdGlvbi4KCgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18BMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.127.475 References: <464D7FE4-33F2-4039-8B44-AE1BF50E422F@frobbit.se> <20121125163200.407.qmail@joyce.lan> Message-ID: <1353864061.44981.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Sun, 25 Nov 2012 09:21:01 -0800 (PST) From: William Mills To: John Levine , "apps-discuss@ietf.org" In-Reply-To: <20121125163200.407.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-1998010289-1353864061=:44981" Subject: Re: [apps-discuss] SRV and service discovery, draft-ietf-appsawg-webfinger-04 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: Sun, 25 Nov 2012 17:21:12 -0000 ---1036955950-1998010289-1353864061=:44981 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The way to solve this for JS in my opinion is to wrap this into the XHTTP h= andler and have that thing understand wf: or acct: scheems and do the SRV l= ookup inside that thing.=A0 How that would work right with same origin is s= till an excellent question.=0A=0A=0A=0A=0A=0A>_____________________________= ___=0A> From: John Levine =0A>To: apps-discuss@ietf.org = =0A>Sent: Sunday, November 25, 2012 8:32 AM=0A>Subject: Re: [apps-discuss] = SRV and service discovery, draft-ietf-appsawg-webfinger-04=0A> =0A>>> not u= nlike the ones here.)=A0 But if after 16 years, the people who=0A>>> mainta= in Javascript are unpersuaded that would be worth tneir time to=0A>>> add S= RV lookups, it's not because they are stupid.=0A>>=0A>>Who has to do that p= ersuasion?=0A>=0A>People who think doing SRV lookups is a good idea.=A0 You= , perhaps.=0A>=0A>>I.e. is it not part of an initiative like this, that wan= t some service=0A>>discovery, to ensure JavaScript is doing The Right Thing= ?=0A>=0A>Presumably, but arguments that end at "add SRV to Javascript" are = not=0A>productive.=0A>=0A>It is not clear to me even at what level it would= be appropriate to do=0A>SRV lookups.=A0 One possibility might be new built= in JS functions,=0A>although I don't understand at this point how that woul= d interact with=0A>the single origin rule.=A0 =0A>=0A>Another possibility i= s a new URL scheme, along the lines=0A>of draft-jennings-http-srv, or more = generally like this:=0A>=0A>=A0 srv[s]://example.com:foo/bar =0A>=0A>does a= SRV looksup of =0A>=0A>=A0 _foo._tcp.example.com=0A>=0A>and turns the requ= est into=0A>=0A>=A0 http[s]://:/bar=0A>=0A>(Add hand waving a= bout what to do with the priority and weight if=0A>there are multiple answe= rs, along the lines of what it already does=0A>with multiple A or AAAA answ= ers.)=0A>=0A>If people think this is a good idea, they sould write it up an= d try=0A>implementing it in some of the open source browsers that people us= e.=0A>Or else stop kvetching.=0A>=0A>R's,=0A>John=0A>______________________= _________________________=0A>apps-discuss mailing list=0A>apps-discuss@ietf= .org=0A>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A> ---1036955950-1998010289-1353864061=:44981 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The way t= o solve this for JS in my opinion is to wrap this into the XHTTP handler an= d have that thing understand wf: or acct: scheems and do the SRV lookup ins= ide that thing.  How that would work right with same origin is still a= n excellent question.


From: John Levine <johnl@taugh.com>=
To: apps-discuss@ietf= .org
Sent: Sunday, November 25= , 2012 8:32 AM
Subject: Re: [apps-discuss] SRV and service discovery, draft-ietf-appsawg-webfinge= r-04

>> not unlike the ones here.)  But i= f after 16 years, the people who
>> maintain Javascript are unpers= uaded that would be worth tneir time to
>> add SRV lookups, it's n= ot because they are stupid.
>
>Who has to do that persuasion?
People who think doing SRV lookups is a good idea.  You, perhaps= .

>I.e. is it not part of an initiative like this, that want some= service
>discovery, to ensure JavaScript is doing The Right Thing?
Presumably, but arguments that end at "add SRV to Javascript" are not=
productive.

It is not clear to me even at what level it would be= appropriate to do
SRV lookups.  One possibility might be new builtin JS functions,
although I don't understand at this point how tha= t would interact with
the single origin rule. 

Another poss= ibility is a new URL scheme, along the lines
of draft-jennings-http-srv,= or more generally like this:

  srv[s]://example.com:foo/bar
does a SRV looksup of

  _foo._tcp.example.com

and= turns the request into

  http[s]://<target>:<port>= /bar

(Add hand waving about what to do with the priority and weight = if
there are multiple answers, along the lines of what it already doeswith multiple A or AAAA answers.)

If people think this is a good i= dea, they sould write it up and try
implementing it in some of the open = source browsers that people use.
Or else stop kvetching.

R's,
= John
_______________________________________________
apps-discuss mai= ling list
apps-discuss@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/apps-discuss


---1036955950-1998010289-1353864061=:44981-- From GK@ninebynine.org Sun Nov 25 15:37: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 4562821F868F for ; Sun, 25 Nov 2012 15:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.575, 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 gMh6CYhfdQKI for ; Sun, 25 Nov 2012 15:37:15 -0800 (PST) Received: from relay9.mail.ox.ac.uk (relay9.mail.ox.ac.uk [163.1.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 968B721F868E for ; Sun, 25 Nov 2012 15:37:13 -0800 (PST) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay9.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TcllA-0005oq-UG for apps-discuss@ietf.org; Sun, 25 Nov 2012 23:37:12 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Tcll9-0001D1-3D for apps-discuss@ietf.org; Sun, 25 Nov 2012 23:37:12 +0000 Message-ID: <50B2AB46.6050008@ninebynine.org> Date: Sun, 25 Nov 2012 23:35:34 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org Discuss" References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <5adcc27caa0ebeebe886329a572a8f86@hethane.se> <4553F589-ED2E-4A36-A51F-0E224030EF68@frobbit.se> <7AF3E47A-ECCE-4530-BF9E-786845BC1278@vpnc.org> <20121125040449.GC58516@mx1.yitter.info> <2628F062-2686-4ED6-B1EF-BEA61AFBF8DE@vpnc.org> In-Reply-To: <2628F062-2686-4ED6-B1EF-BEA61AFBF8DE@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Subject: Re: [apps-discuss] Does / Should the IETF support JavaScript as a programming platform? 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, 25 Nov 2012 23:37:16 -0000 On 25/11/2012 15:24, Paul Hoffman wrote: > On Nov 24, 2012, at 8:04 PM, Andrew Sullivan wrote: > >> On Sat, Nov 24, 2012 at 05:51:25PM -0800, Paul Hoffman wrote: >> >>> If you want JavaScript to be a general-purpose language with the >>> ability open TCP/UDP sockets at will, that's fine, but that would >>> invoke a very different security model for JavaScript. >> >> But at bottom, what the current discussion says is, "We want >> JavaScript to be a full-force application writing language, but we >> don't want all the crap that comes with that in our language, so we >> want to add these three warts to the Internet instead." >> >> As a personal disposition, I'm not opposed to warts where the virus is >> dug in. But this really is a basic architectural question for the >> Area: do we even have a way of thinking coherently about the kinds of >> applications that are written with deliberately-hobbled languages, but >> that are widely deployed and broadly useful? The debate on this topic >> seems to say, "No." Maybe that's our problem. > > Excellent summary. Your conclusion of "no" seems correct, as does "Maybe that's our problem". What I've read of this discussion hasn't addressed the consideration that for Javascript *in browser*, a typical user doesn't get to choose what programs are run on their machine. It's not Javascript the language that's the problem, but the way that code is delivered and executed. (This does not, of itself, argue against supporting, say, DNS SRV lookups, but access to any such capability has to be approached somewhat conservatively compared with most other programming platforms for Internet access.) #g -- From duerst@it.aoyama.ac.jp Sun Nov 25 16:47: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 9747D21F8695 for ; Sun, 25 Nov 2012 16:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.191 X-Spam-Level: X-Spam-Status: No, score=-97.191 tagged_above=-999 required=5 tests=[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 FTVMmSy1FUUm for ; Sun, 25 Nov 2012 16:47:37 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 32F3121F8692 for ; Sun, 25 Nov 2012 16:47:33 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id qAQ0lLMl010018 for ; Mon, 26 Nov 2012 09:47:21 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 24a5_4018_d6675576_3762_11e2_945d_001d096c566a; Mon, 26 Nov 2012 09:47:20 +0900 Received: from [IPv6:::1] ([133.2.210.1]:37694) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 26 Nov 2012 09:47:22 +0900 Message-ID: <50B2BC18.6030104@it.aoyama.ac.jp> Date: Mon, 26 Nov 2012 09:47:20 +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: Graham Klyne References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <5adcc27caa0ebeebe886329a572a8f86@hethane.se> <4553F589-ED2E-4A36-A51F-0E224030EF68@frobbit.se> <7AF3E47A-ECCE-4530-BF9E-786845BC1278@vpnc.org> <20121125040449.GC58516@mx1.yitter.info> <2628F062-2686-4ED6-B1EF-BEA61AFBF8DE@vpnc.org> <50B2AB46.6050008@ninebynine.org> In-Reply-To: <50B2AB46.6050008@ninebynine.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Does / Should the IETF support *browser-side* JavaScript as a programming platform? 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, 26 Nov 2012 00:47:38 -0000 On 2012/11/26 8:35, Graham Klyne wrote: > What I've read of this discussion hasn't addressed the consideration > that for Javascript *in browser*, a typical user doesn't get to choose > what programs are run on their machine. It's not Javascript the language > that's the problem, but the way that code is delivered and executed. > > (This does not, of itself, argue against supporting, say, DNS SRV > lookups, but access to any such capability has to be approached somewhat > conservatively compared with most other programming platforms for > Internet access.) Yes indeed. Server-side JavaScript isn't an issue at all. There are many server-side JavaScript implementations (see e.g. http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaScript_solutions), and checking the most well-known of them, it has DNS support (see http://nodejs.org/api/dns.html; I'm not a DNS expert and so can't judge whether these functions are adequate for our problem or not). The problem is *browser-side* JavaScript. I have fixed that in the subject. As it currently stands, any web page can execute any JavaScript code from any source. Here is a hopefully somewhat realistic example of what might happen when allowing DNS access from brwser-side JavaScript: Employee A at company B visits web site C over lunch. Web site C includes (or points to) JavaScript that scans company B's DNS system to figure out its structure and detect potential weak points. This information is sent back to C without A noticing. As a result, information about B (e.g. internal structure, new but as of yet secret products,...) and its network infrastructure may leak to C. Regards, Martin. From duerst@it.aoyama.ac.jp Sun Nov 25 17:05: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 CE13A21F8671 for ; Sun, 25 Nov 2012 17:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.191 X-Spam-Level: X-Spam-Status: No, score=-97.191 tagged_above=-999 required=5 tests=[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 DvF68Op84WC7 for ; Sun, 25 Nov 2012 17:05:38 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id D11AF21F8668 for ; Sun, 25 Nov 2012 17:05:37 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id qAQ15O1n022441 for ; Mon, 26 Nov 2012 10:05:28 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 7f0a_5417_5bb424be_3765_11e2_84fd_001d096c5782; Mon, 26 Nov 2012 10:05:24 +0900 Received: from [IPv6:::1] ([133.2.210.1]:52137) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 26 Nov 2012 10:05:24 +0900 Message-ID: <50B2C053.7000900@it.aoyama.ac.jp> Date: Mon, 26 Nov 2012 10:05:23 +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: William Mills References: <464D7FE4-33F2-4039-8B44-AE1BF50E422F@frobbit.se> <20121125163200.407.qmail@joyce.lan> <1353864061.44981.YahooMailNeo@web31802.mail.mud.yahoo.com> In-Reply-To: <1353864061.44981.YahooMailNeo@web31802.mail.mud.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: John Levine , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] SRV and service discovery, draft-ietf-appsawg-webfinger-04 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, 26 Nov 2012 01:05:38 -0000 On 2012/11/26 2:21, William Mills wrote: > The way to solve this for JS in my opinion is to wrap this into the XHTTP handler and have that thing understand wf: or acct: scheems and do the SRV lookup inside that thing. How that would work right with same origin is still an excellent question. Yes. Assume the user has used some authentication to access some webfinger data in the past. Then a third-party web page tries to access the corresponding acct: URI/IRI and gets the data and sends it to the third-party web server. That would be bad. What would be okay is that the user activates (clicks on) an acct: link, and the webfinger information is shown as a separate "page" (or whatever the implementation things is best to show the information) independent of the page the link was on. That's what currently happens with any kind of link, from http: to mailto:. It might also be okay, under same-origin restrictions, to get acct: data from the same origin as the web-page. But that of course has to be carefully evaluated for security risks. Especially for multi-hosting sites, it may not be a good idea. Regards, Martin. From hallam@gmail.com Sun Nov 25 19:57: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 8B23121F8431 for ; Sun, 25 Nov 2012 19:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[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 N43mLPr6CFu3 for ; Sun, 25 Nov 2012 19:57:53 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5C221F842F for ; Sun, 25 Nov 2012 19:57:46 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so11460216obb.31 for ; Sun, 25 Nov 2012 19:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=oXFtZ9TYPC99YZ6hXfeZ/tN/9wXH+5bH7rPXrefOPpk=; b=hbBdzZtSNrPMkvYBlg/ou9531FO7qNptSBL6dVi1dAM37GDjRs2Tfh1jLF+KVezNlz vSUECjSl9JHsvhGCQocqZTk1XRIrfXZuvXEJny3lJBSnRpGVl+huEdSxqRBUS5P9cMeJ hSAyIqc4JIV4oO2rGFFkqaTW/bHkFgzShiVnJvrcU3WDyjVIQyrBtR7nczm9zS92zXlb jip9ZDmTOMh7uXszF79RdWN5bOdegShrYk9J3im8o59GRRKleuAGIXFQBncBtaZi/mJ7 A4RXd2pqjuxFUBdU+bzGDSND1Eu6YMIflMn2Ic59XqZri3wy5j7yhVbNpeWy7XT57oHV /1og== MIME-Version: 1.0 Received: by 10.182.240.109 with SMTP id vz13mr8082636obc.81.1353902266126; Sun, 25 Nov 2012 19:57:46 -0800 (PST) Received: by 10.76.19.43 with HTTP; Sun, 25 Nov 2012 19:57:45 -0800 (PST) In-Reply-To: <20121125163200.407.qmail@joyce.lan> References: <464D7FE4-33F2-4039-8B44-AE1BF50E422F@frobbit.se> <20121125163200.407.qmail@joyce.lan> Date: Sun, 25 Nov 2012 22:57:45 -0500 Message-ID: From: Phillip Hallam-Baker To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=14dae93a1581a210af04cf5def11 Subject: Re: [apps-discuss] SRV and service discovery, draft-ietf-appsawg-webfinger-04 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, 26 Nov 2012 03:57:58 -0000 --14dae93a1581a210af04cf5def11 Content-Type: text/plain; charset=ISO-8859-1 Lets take a step back, what is the appropriate level of abstraction for Javascript client service discovery? I don't think we want a Jscript client to be aware of the transport protocol if at all possible. The application layer should be properly abstracted away from the transport layer. Even if the only network is TCP/IP, the application layer should still be properly abstracted. We are pretty much wedged into IP indefinitely but changing the TCP part is feasible. And limitations of JScript should not be an obstacle to doing the right thing. So I don't think we want to have a full DNS stack in there. But that does not mean we should be limited to nothing more than A-records. Instead I would like a JScript call of the form 'open me a connection to the service X at DNS name Y using the Z discovery mechanism. 'Use SRV' would be one option, 'Use A/AAAA' would be another. But the call should also allow the application to just leave that to the platform to make the best choice. I can't see the justification for complaining about 'warts'. The IETF should have addressed discovery more systematically a long time back. Well known ports are not a viable mechanism any longer. The fault here is on the IETF side for not giving clear and workable guidance a decade ago. That said, I do agree that JScript is an abominable creation. Since I turned it off by default four weeks ago my Web browsing experience has improved dramatically. Pop up ads are gone completely. So are the more incompetent and idiotic site hacks. Sites that used to load slowly now load much faster. I turn scripting on on a case by case basis. --14dae93a1581a210af04cf5def11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lets take a step back, what is the appropriate level of abstraction for Jav= ascript client service discovery?

I don't think we want a Jscript client to be aware = of the transport protocol if at all possible. The application layer should = be properly abstracted away from the transport layer. Even if the only netw= ork is TCP/IP, the application layer should still be properly abstracted.

We are pretty much wedged into IP indefinitely but chan= ging the TCP part is feasible. And limitations of JScript should not be an = obstacle to doing the right thing.

So I don't = think we want to have a full DNS stack in there. But that does not mean we = should be limited to nothing more than A-records.


Instead I would like a JScript call of t= he form 'open me a connection to the service X at DNS name Y using the = Z discovery mechanism.

'Use SRV' would be = one option, 'Use A/AAAA' would be another. But the call should also= allow the application to just leave that to the platform to make the best = choice.


I can't see the justification for co= mplaining about 'warts'. The IETF should have addressed discovery m= ore systematically a long time back. Well known ports are not a viable mech= anism any longer. The fault here is on the IETF side for not giving clear a= nd workable guidance a decade ago.

That said, I do agree that JScript is an abominable cre= ation. Since I turned it off by default four weeks ago my Web browsing expe= rience has improved dramatically. Pop up ads are gone completely. So are th= e more incompetent and idiotic site hacks. Sites that used to load slowly n= ow load much faster. I turn scripting on on a case by case basis.

--14dae93a1581a210af04cf5def11-- From alexey.melnikov@isode.com Mon Nov 26 04:32: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 D746A21F8569 for ; Mon, 26 Nov 2012 04:32:30 -0800 (PST) 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 0cW9uiY0ihF3 for ; Mon, 26 Nov 2012 04:32:29 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id CDA4C21F8564 for ; Mon, 26 Nov 2012 04:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1353933148; d=isode.com; s=selector; i=@isode.com; bh=aQHMXZGNOi4QkUyrKPf9tEO4sP5vtQhobkPQDzW2rJA=; 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=PSxl4vw4ESORNJX8IBfJpryUoN4TJpkacJgD6A1tlXWwTAQQRA0+hMVkS8SxydMK7ftvt1 k1lSDmV1zjGlpA2JEfTwDsVw/caQIBJk5r0otR44JwQG3B67VT9yKsKeyKNjyG/P0JrU6E 2oh85soOhgSwoiAUm6JT+mSMdb+wH9w=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 26 Nov 2012 12:32:27 +0000 Message-ID: <50B36197.2090507@isode.com> Date: Mon, 26 Nov 2012 12:33:27 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: draft-ietf-sipcore-sip-websocket-06.all@tools.ietf.org, "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] APPSDIR review of draft-ietf-sipcore-sip-websocket-06 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, 26 Nov 2012 12:32:31 -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 comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sipcore-sip-websocket-06 Title: The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) Reviewer: Alexey Melnikov Review Date: 26 November 2012 Summary: The document is ready for publication as a Proposed Standard, with nits. Major Issues: none Minor Issues/Nits: In 5.1: if Content-Length is specified, it has to match the message size used to send the corresponding SIP request/response. I think it would help to specify that if they don't match than that is an error condition. In 5.2.2: should "wss" also be registered? In 5.2.3: this reminds me of the HTTP Forwarded header field draft (draft-ietf-appsawg-http-forwarded-10). It might be worth checking if any privacy considerations from it are applicable to this document. Also, if a Received header field is added, what should be the transport identifier be? In 5.2.4: the MAY seems wrong, this is already an extension. The whole section doesn't seem to be needed. RFC 2617 is a normative reference, IMHO, as it is used in a statement using an RFC 2119 keyword. From ylafon@w3.org Mon Nov 26 06:56: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 222EC21F8452; Mon, 26 Nov 2012 06:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, 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 6ZsZWde227ym; Mon, 26 Nov 2012 06:56:45 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 786D421F843F; Mon, 26 Nov 2012 06:56:45 -0800 (PST) Received: from ylafon by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1Td070-0005OG-GL; Mon, 26 Nov 2012 09:56:42 -0500 Date: Mon, 26 Nov 2012 09:56:42 -0500 (EST) From: Yves Lafon To: apps-discuss@ietf.org, draft-ietf-6man-uri-zoneid@tools.ietf.org Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: appsdir@ietf.org, iesg@ietf.org Subject: [apps-discuss] Review of draft-ietf-6man-uri-zoneid-05 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, 26 Nov 2012 14:56:46 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-6man-uri-zoneid-05 Title: IPv6 Zone Identifiers in Address Literals and Uniform Resource=20 Identifiers Reviewer: Yves Lafon Review Date: 26 November 2012 IETF Last Call Date: 2012-11-23 Summary: The document is almost ready to progress, but some clarifications= =20 are needed on two points explicited below. In section 3: << This document implies that all browsers should recognise a ZoneID preceded by an escaped "%". In the spirit of "be liberal with what you accept", we also recommend that URI parsers accept bare "%" signs (i.e., a "%" not followed by two valid hexadecimal characters). This makes it easy for a user to copy and paste a string such as "fe80::a%en1" from the output of a "ping" command and have it work. >> Does it mean that such URIs can be present in an HTML document or that=20 they MAY allow bare "%" signs when the URI is pasted in the address bar?=20 (Those are two different use cases, and browsers may have different code=20 paths for both). In section 4: It says << An HTTP server or proxy MUST ignore any ZoneID attached to an incoming URI, as it only has local significance at the sending host. >> A proxy can be considered as a sending host, so does it mean that a the=20 receiving end MUST strip all ZoneID before processing the request? (and it= =20 would be a significant change to implementations), or could this be=20 resolved by mandating Web browser to strip ZoneID prior to sending the=20 request as it is only significant for the sending host and as it is the=20 implementation that needs to be updated to recognize the new syntax? --=20 Baroula que barouleras, au ti=E9u toujou t'entourneras. ~~Yves From ve7jtb@ve7jtb.com Mon Nov 26 07:18: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 9DECB21F8554 for ; Mon, 26 Nov 2012 07:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 qcip4xsFvq87 for ; Mon, 26 Nov 2012 07:18:45 -0800 (PST) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C38E21F855C for ; Mon, 26 Nov 2012 07:18:45 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id 56so2132143yhq.31 for ; Mon, 26 Nov 2012 07:18:44 -0800 (PST) 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=AS//Yb+Y4wNvLenOrfeVQ2OrYHGY7WH306WZyXgz9J8=; b=VVgnwxuIjpFMWMXLDn37MbJ9KEE+3y1kNLgHu/Yr1AZEyTHE1KyNlX//BLbnwk95Rq NYhr+C5XZ4EDV1sb4N1oNZrk2IZ28D3QiGHmAJ912oLM+z+AXSZlEqVj5sULPMFIHJyd nGM/9DNMv+Ciw4cvgRQJmOxFd0+RXAkqZq6Ert/Svakbo7GavEMouXr3vqlEDEuT7H7e tIV4uewr/oD0teamwndmbpMpnXseqsgg8FJHa2fDzayJLpPY7sW//JGYGGRH7/7Rc0pB gaQ99qDiLyJTrApT72N/uUKQ3wQ7Q7LbtebtNlyQG6ALoXVEchYHItxBsAnHJ5T92wyP yhGQ== Received: by 10.101.180.1 with SMTP id h1mr3319325anp.25.1353943124301; Mon, 26 Nov 2012 07:18:44 -0800 (PST) Received: from [192.168.1.211] (190-20-23-36.baf.movistar.cl. [190.20.23.36]) by mx.google.com with ESMTPS id h37sm13970301anm.10.2012.11.26.07.18.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 07:18:43 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FC358318-19F1-4D31-8797-F0911677C081" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Mon, 26 Nov 2012 12:18:25 -0300 Message-Id: <78955AC5-7111-45B3-880E-5DD61A94BCDD@ve7jtb.com> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943668FD18F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50AFF5F4.8030605@openlinksw.com> <2a1fa9d1-83ad-41db-a928-7a946cfc05f3@email.android.com> <50B0F066.5030509@openlinksw.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQk2LX+pY22w0W+CDDuFS6K/OUvzazLLWA9CvxIaL1VQw/9/Qg88LOxC3GuFVxIKKL+SoOU8 Cc: Brad Fitzpatrick , Kingsley Idehen , webfinger@googlegroups.com, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 26 Nov 2012 15:18:47 -0000 --Apple-Mail=_FC358318-19F1-4D31-8797-F0911677C081 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I don't get it ether where is this path coming from? John B. On 2012-11-24, at 1:21 PM, "Paul E. Jones" = wrote: > I don't understand how this would work. Suppose I write a client that = wants to look up information on a given user. Using the well-known = location, the client code is fairly simple. If we use different paths, = we'd need a discovery mechanism for the path, no? >=20 > Paul >=20 > From: Kingsley Idehen > Sent: Sat Nov 24 11:05:58 EST 2012 > To: webfinger@googlegroups.com > Cc: "Paul E. Jones" , Brad Fitzpatrick = , John Bradley , = "apps-discuss@ietf.org" > Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 >=20 > On 11/24/12 2:13 AM, Paul E. Jones wrote: >> You can always redirect requests elsewhere, but if we don't have = fixed resource locations, it makes discovery a challenge. >>=20 >> Paul >>=20 >=20 > Yes, but I am seeking a way to alleviate the following challenges for = end-users seeking to exploit Webfinger: >=20 > 1. domain ownership > 2. domain name server admin privileges > 3. web server admin privileges. >=20 > Right now, Webfinger scopes everything to the "host" in a Web realm = that is really scoped to documents (Web 1.0 and 2.0) and named entities = (Web 3.0 via Linked Data).=20 >=20 > Is it too costly to add "paths" to Webfinger bearing in mind the = granularity this option provides i.e., rather being aimed at service = providers (who control domain name and web servers) it also serves the = needs of profile document owners and individuals that seek full control = over their digital identities.=20 >=20 > The upside of this non disruptive tweak is massive.=20 >=20 > Kingsley=20 >=20 >>=20 >>=20 >> From: Kingsley Idehen >> Sent: Fri Nov 23 17:17:24 EST 2012 >> To: webfinger@googlegroups.com >> Cc: Brad Fitzpatrick , John Bradley = , "apps-discuss@ietf.org" >> Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 >>=20 >> On 11/23/12 5:09 PM, Brad Fitzpatrick wrote: >>> On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones = wrote: >>> Thanks for writing this, John. It=92s important for people to = understand that this is a real problem =96 not a theoretical problem =96 = and that the consequences of not solving the problem in a practically = implementable standards-based manner could once again be deployment of a = vendor-specific solution that locks out other participants. >>>=20 >>>=20 >>> What's the problem? >>>=20 >>> I missed some emails, if there were any about this. Is there = discussion happening on a mailing list other than apps-discuss and/or = webfinger@googlegroups.com? >>>=20 >>> We already have the /.well-known/ thing, so why do we need a = well-known subdomain? >>>=20 >>> The way I see it is: >>>=20 >>> a) If you're aren't running a webserver on the hostname =3D> run = one, and respond to /.well-known/webfinger >>> b) If you are running a webserver on the hostname =3D> respond to = /.well-known/webfinger >>>=20 >>> We need to make things easier for clients, not easier for servers. = There will many more clients than servers, so it needs to be hard to get = wrong, if we want people to do the right thing. >>>=20 >>> Let's imagine that the "webfinger" subdomain goes into the spec, but = no major webfinger server uses it. So now we have 99% of webfinger = client applications (many in JavaScript) only implementing the base case = and ignoring the subdomain lookup, because it always works as far as = they're concerned. Now new servers have no choice but to respond at = host.com/.well-known/webfinger because most clients won't work = otherwise. That's where I fear this is all heading: because of a = misguided desired to make things easier for some hypothetical server = authors, we then make things complicated for everybody, even though we = gain nothing. >>>=20 >>> When you have more clients than servers, I think it's important to = make things simple for clients. >>>=20 >>=20 >> All, >>=20 >> A late in the game request. Is there any chance of = and/or = instead of just = or ?=20= >>=20 >> Goal: to be able to deploy a Webfinger accessible profile document = via the likes of Dropbox, GoogleDrive, Microsoft SkyDrive, Box.NET, = Wuala, Amazon S3 buckets etc.. Basically, removing the HTTP server = ownership and admin requirement by moving scope to a document path = rather than a host.=20 >>=20 >> --=20 >>=20 >> Regards, >>=20 >> Kingsley Idehen =20 >> Founder & CEO=20 >> OpenLink Software =20 >> Company Web: http://www.openlinksw.com >> Personal Weblog: http://www.openlinksw.com/blog/~kidehen >> Twitter/Identi.ca handle: @kidehen >> Google+ Profile: https://plus.google.com/112399767740508618350/about >> LinkedIn Profile: http://www.linkedin.com/in/kidehen >>=20 >>=20 >>=20 >>=20 >=20 >=20 > --=20 >=20 > Regards, >=20 > Kingsley Idehen =20 > Founder & CEO=20 > OpenLink Software =20 > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen >=20 >=20 >=20 >=20 --Apple-Mail=_FC358318-19F1-4D31-8797-F0911677C081 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = don't get it ether where is this path coming = from?

John B.
On 2012-11-24, at 1:21 PM, = "Paul E. Jones" <paulej@packetizer.com> = wrote:

I = don't understand how this would work. Suppose I write a client that = wants to look up information on a given user. Using the well-known = location, the client code is fairly simple. If we use different paths, = we'd need a discovery mechanism for the path, no?

Paul

From: Kingsley Idehen <kidehen@openlinksw.com>
Sent: Sat Nov 24 11:05:58 EST 2012
To: webfinger@googlegroups.com<= br> Cc: "Paul E. Jones" <paulej@packetizer.com>, = Brad Fitzpatrick <bradfitz@google.com>, John = Bradley <ve7jtb@ve7jtb.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

=20 =20 =20 =20
On 11/24/12 2:13 AM, Paul E. Jones wrote:

You can always redirect requests elsewhere, = but if we don't have fixed resource locations, it makes discovery a challenge.

Paul


Yes, but I am seeking a way to alleviate the following challenges for end-users seeking to exploit Webfinger:

1. domain ownership
2. domain name server admin privileges
3. web server admin privileges.

Right now, Webfinger scopes everything to the "host" in a Web realm that is really scoped to documents (Web 1.0 and 2.0) and named entities (Web 3.0 via Linked Data).

Is it too costly to add "paths" to Webfinger bearing in mind the granularity this option provides i.e., rather being aimed at service providers (who control domain name and web servers) it also serves the needs of profile document owners and individuals that seek full control over their digital identities.

The upside of this non disruptive tweak is massive.

Kingsley



From: Kingsley Idehen <kidehen@openlinksw.com><= br> Sent: Fri Nov 23 17:17:24 EST 2012
To: webfinger@googlegroups.com<= br> Cc: Brad Fitzpatrick <bradfitz@google.com>, = John Bradley <ve7jtb@ve7jtb.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04

On 11/23/12 5:09 PM, Brad = Fitzpatrick wrote:
On Fri, Nov 23, 2012 at 1:19 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

Thanks for writing this, John.  It=92s important for = people to understand that this is a real problem =96 not = a theoretical problem =96 and that the consequences = of not solving the problem in a practically implementable standards-based manner could once again be deployment of a vendor-specific solution that locks out other participants.


What's the problem?

I missed some emails, if there were any about this. =  Is there discussion happening on a mailing list other than apps-discuss and/or webfinger@googlegroups.com?=

We already have the /.well-known/ thing, so why do we need a well-known subdomain?

The way I see it is:

a) If you're aren't running a webserver on the hostname =3D> run one, and respond to = /.well-known/webfinger
b) If you are running a webserver on the hostname =3D>= respond to /.well-known/webfinger

We need to make things easier for clients, not easier for servers.  There will many more clients than = servers, so it needs to be hard to get wrong, if we want people to do the right thing.

Let's imagine that the "webfinger" subdomain goes into the spec, but no major webfinger server uses it.  So = now we have 99% of webfinger client applications (many in JavaScript) only implementing the base case and ignoring the subdomain lookup, because it always works as far as they're concerned.  Now new servers have no choice = but to respond at host.com/.well-known/webfin= ger because most clients won't work otherwise.  That's = where I fear this is all heading:  because of a misguided = desired to make things easier for some hypothetical server authors, we then make things complicated for everybody, even though we gain nothing.

When you have more clients than servers, I think it's important to make things simple for clients.


All,

A late in the game request. Is there any chance of <host.com/.well-known/{path}= /webfinger> and/or <host.com/{path}/.well-known= /webfinger> instead of just <host.com/.well-known/webfin= ger> or <host.com/.well-known/webfin= ger> ?

Goal: to be able to deploy a Webfinger accessible profile document via the likes of Dropbox, GoogleDrive, Microsoft SkyDrive, Box.NET, Wuala, Amazon S3 buckets = etc.. Basically, removing the HTTP server ownership and admin requirement by moving scope to a document path rather than a host. 

--=20

Regards,

Kingsley Idehen      =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.c=
om/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.=
google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kid=
ehen







--=20

Regards,

Kingsley Idehen      =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com=
/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.=
google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kid=
ehen
=20

= --Apple-Mail=_FC358318-19F1-4D31-8797-F0911677C081-- From nico@cryptonector.com Mon Nov 26 07:48: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 C9CB521F85C6 for ; Mon, 26 Nov 2012 07:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 opedtFhmY3CQ for ; Mon, 26 Nov 2012 07:48:09 -0800 (PST) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB3421F85A6 for ; Mon, 26 Nov 2012 07:48:09 -0800 (PST) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 078817E406F for ; Mon, 26 Nov 2012 07:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=BTPvkfPpeCVEcIpOBZYk sTHpEF8=; b=MkX5J6NsUdRjMxJm8bXnjeWsUOpq7NO3mZRBjxZa26/Fh5tIla05 s04l2g9Jc2hL1cZZcIP5KYTu28vupHgud02UPfKuY1kjEe5c8NkRfkafG424dqBI FCbpBO87YAuCv+7lpCFPAI+3yO8kppwr8Op0JjJSsXBaIso1nBcgJpI= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id E71447E4065 for ; Mon, 26 Nov 2012 07:48:08 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so7908181pbc.31 for ; Mon, 26 Nov 2012 07:48:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.143.129 with SMTP id se1mr39288654pbb.67.1353944888287; Mon, 26 Nov 2012 07:48:08 -0800 (PST) Received: by 10.68.128.234 with HTTP; Mon, 26 Nov 2012 07:48:08 -0800 (PST) In-Reply-To: <20121125040449.GC58516@mx1.yitter.info> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <5adcc27caa0ebeebe886329a572a8f86@hethane.se> <4553F589-ED2E-4A36-A51F-0E224030EF68@frobbit.se> <7AF3E47A-ECCE-4530-BF9E-786845BC1278@vpnc.org> <20121125040449.GC58516@mx1.yitter.info> Date: Mon, 26 Nov 2012 09:48:08 -0600 Message-ID: From: Nico Williams To: Andrew Sullivan Content-Type: text/plain; charset=UTF-8 Cc: Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 26 Nov 2012 15:48:09 -0000 On Sat, Nov 24, 2012 at 10:04 PM, Andrew Sullivan wrote: > On Sat, Nov 24, 2012 at 05:51:25PM -0800, Paul Hoffman wrote: > >> If you want JavaScript to be a general-purpose language with the >> ability open TCP/UDP sockets at will, that's fine, but that would >> invoke a very different security model for JavaScript. > > But at bottom, what the current discussion says is, "We want > JavaScript to be a full-force application writing language, but we > don't want all the crap that comes with that in our language, so we > want to add these three warts to the Internet instead." > > As a personal disposition, I'm not opposed to warts where the virus is > dug in. But this really is a basic architectural question for the > Area: do we even have a way of thinking coherently about the kinds of > applications that are written with deliberately-hobbled languages, but > that are widely deployed and broadly useful? The debate on this topic > seems to say, "No." Maybe that's our problem. Whatever else may be hiding in this I-D, service discovery is not a wart. Indeed, proper service discovery is sorely missing. The nice thing about XHR is that the implementation can hide all sorts of details and still apply same-origin policies. Any service discovery functionality to be implemented in JS will have to fit into XHR, so that the implementation of it does all the work. This means that service discovery must either be new options to XHR or a new URI scheme. The rest is details. Nico -- From stpeter@stpeter.im Mon Nov 26 08:03: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 431AA21F8668; Mon, 26 Nov 2012 08:03:52 -0800 (PST) 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 AnBbgTi-+nhe; Mon, 26 Nov 2012 08:03:51 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA8A21F85C7; Mon, 26 Nov 2012 08:03:51 -0800 (PST) Received: from [10.129.24.67] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C7F8C40092; Mon, 26 Nov 2012 09:08:40 -0700 (MST) Message-ID: <50B38AAA.5030908@stpeter.im> Date: Mon, 26 Nov 2012 08:28:42 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Graham Klyne References: <50B2095C.2000501@ninebynine.org> In-Reply-To: <50B2095C.2000501@ninebynine.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "uri-review@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 26 Nov 2012 16:03:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/25/12 5:04 AM, Graham Klyne wrote: > I've just been digging around the XMPP specs, and I notive they > make reference to required namespaces of the form "jabber:client" > and "jabber:server" (cf. > http://tools.ietf.org/html/rfc3920#section-11.2, esp sect 11.2.2). > > Examples in sections 8 and 9 of that spec reinforce the indication > that jabber: is being used as a URI scheme (rather than a namespace > prefix). The 'jabber:' string was used in the earliest days of the jabberd server project when the core developers didn't really understand XML namespaces (which were quite new at the time). It is not a URI scheme, just a mistake. :) > But looking at http://www.iana.org/assignments/uri-schemes.html I'm > not seeing any mention of jabber:. > > Assuming I'm reading this right... it's probably unfortunate that > that this use of jabber: has come about (like dav: before it?) but > I guess it's now entrenched and should at least be registered? I have never registered it and I hesitate to do so now because I think it would cause more confusion than it's worth. We do have the 'xmpp:' URI scheme for pointing to JabberIDs. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCziqkACgkQNL8k5A2w/vwWLACeK92mGiyENuSi36azX09h2NxH 7RAAnjAYU89bIFoJec0qh9DxPBq0GgYa =PBrH -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Nov 26 08:03: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 854E821F86B3 for ; Mon, 26 Nov 2012 08:03:57 -0800 (PST) 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 gBG3S6hBvW55 for ; Mon, 26 Nov 2012 08:03:57 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D87D721F86B2 for ; Mon, 26 Nov 2012 08:03:56 -0800 (PST) Received: from [10.129.24.67] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9819F4012A; Mon, 26 Nov 2012 09:08:46 -0700 (MST) Message-ID: <50B38E8D.2010600@stpeter.im> Date: Mon, 26 Nov 2012 08:45:17 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tim Bray References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> <3c86d465-fb09-416a-aa11-7ac7af1fd3fa@googlegroups.com> In-Reply-To: <3c86d465-fb09-416a-aa11-7ac7af1fd3fa@googlegroups.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 26 Nov 2012 16:03:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/23/12 11:32 PM, Tim Bray wrote: > [5.4] Two problems: First, this section fails to convince me that > the “acct†scheme is worth the effort. Presumably that's a job for draft-ietf-appsawg-acct-uri. > Second, the section could simply say that the URI used to identify > the entity being queried is not tied to any scheme; the arm-waving > about the hypothetical wonderfulnesss of “acct:†is a waste of > space. Then having done that, the section could be replaced by a > one-line note in section 5.1 +1 Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCzjo0ACgkQNL8k5A2w/vwJGQCeMPGyVQqxMnWjRzrnYwe4tWe6 W5QAnjMNVcICNE7Rkbhw11FDnvgoKCuo =+y59 -----END PGP SIGNATURE----- From michael.scharf@alcatel-lucent.com Sun Nov 25 14:22: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 5B4CE21F8666; Sun, 25 Nov 2012 14:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 tApkn8qMGHY8; Sun, 25 Nov 2012 14:22:33 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 257C721F855C; Sun, 25 Nov 2012 14:22:32 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qAPMLqeS016078 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 25 Nov 2012 23:22:18 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sun, 25 Nov 2012 23:22:09 +0100 From: "Scharf, Michael (Michael)" To: Claudio Allocchio , "apps-discuss@ietf.org" Date: Sun, 25 Nov 2012 23:22:09 +0100 Thread-Topic: APPSDIR review of draft-ietf-mptcp-api-06 Thread-Index: Ac3DidNmE4sgeaXrT7C4XxAZKQ70KwHzY8Bb Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B2@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <6.2.5.6.2.20121115153136.0a4db440@elandnews.com> In-Reply-To: <6.2.5.6.2.20121115153136.0a4db440@elandnews.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 X-Mailman-Approved-At: Mon, 26 Nov 2012 08:09:53 -0800 Cc: "draft-ietf-mptcp-api.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-mptcp-api-06 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, 25 Nov 2012 22:22:34 -0000 Claudio, Thanks for your feedback! Please find my comments below, marked by [MSC]. Michael ________________________________________ Von: Claudio Allocchio [Claudio.Allocchio@garr.it] Gesendet: Freitag, 16. November 2012 00:32 An: apps-discuss@ietf.org Cc: draft-ietf-mptcp-api.all@tools.ietf.org; iesg@ietf.org Betreff: APPSDIR review of draft-ietf-mptcp-api-06 Hello all, I have been selected as the Applications Area Directorate co-reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mptcp-api-06 Title: MPTCP Application Interface Considerations Reviewer: Claudio Allocchio Review Date: November 15th 2012 IETF Last Call Date: n/a IESG Telechat Date: November 15th2012 Summary: Given the arelady given comments on the apps-discuss ML on many parts of this informaiton documents (and I agree with them) I focused my review on the effects that MPTCP can have on esisting applications and deployment. I think the doument is anyhow very well written and ready for publication. However there a few minor issues that shall be fixed. Major Issues: none. Minor Issues: 3.1.2. Delay "Since burstiness is commonplace on the Internet today, it is unlikely that applications will suffer from such an impact on the traffic profile, but application authors may wish to consider this in future development." well, even it is true the burstiness is common on most of the Internet, this is not the case in many other circumstances, and there are, maybe a few, applications which do expect the jitter to be low and the packet delivery rate to be stable to work correctly (being the developer of one of them... "LOLA - Low latency A/V system" I did expericend already a number of cases where MPTCP did a disaster work just because of its presence on multiple parallel 10G links). Thus I would at least be not to optimistic in the above sentence. It is just not for future work. I just suggest changing it reportig that "this might be a problem" instead of "it is unlikely". [MSC] I don't know the details of the measurement you refer to, but it is c= ertainly important to distinguish between the protocol in general and the b= ehavior of an implementation, which is possibly work-in-progress. I do agre= e that if a specific application does not need the additional bandwidth by = multipath and if it is very latency sensitive, the use of MPTCP could be wo= rse than use of standard TCP, in particular if the sender's scheduler is no= t optimal. At least in theory, in such an application-limited scenario it w= ould make sense if the MPTCP scheduler mainly used the subflow with smalles= t delay, i. e., jitter should be similar to a single-path TCP connection. W= ith a reasonable scheduler in the sender, I think that the scenario you men= tion is indeed "unlikely". Anyway, I think that the scenario you describe r= efers to a mostly controlled environment without congestion etc. In the gen= eral Internet, an application does have to deal with jitter etc. In the same 3.1.2 section, again there are some application (already now) they deeply rely for correct functiong on an accurate estimate of RTT (for example those dealing with audio echo cancellation, or those triggering large scale instrumentation synchronization (for example EVLBI radio telescopes). Thus it not just "new" applications, but what my happen to existing applications shall be mentioned. [MSC] I agree that such applications exist, and we therefore have put a war= ning sign in the draft that MPTCP may not be their first choice. But, again= , I think that an application can only strongly rely on stable RTT etc. in = a controlled environment. I am not sure what a better wording would be. in 3.2.1: "An MPTCP implementation can learn the rate of MPTCP connection attempt successes or failures to particular hosts or networks, and on particular interfaces, and could therefore learn heuristics of when and when not to use MPTCP." Well... are we sure this is a good suggestion? If it is a suggestion, then, what happens when network condition changes dynamically (for example because an application running as a client on a mobile host is moving about?) [MSC] Well, mobility can break all heuristics. This is a problem for many T= CP extensions, and this omment is thus not specific to MPTCP. We could add = some statement that such heuristics can always fail. I don't think that we = can specify such heuristics. A.2. MPTCP Usage Scenarios and Application Requirements There are also application which requires bulk data traffic (in the range 1G and above) AND anre higly interactive, thus ask for low latency and jitter. What should be the choice in this (already existing) case? SOm guidance should be added also for them. [MSC] This is the appendix. The section already mentions more or less that = applications may require "High bandwidth", "Low latency and jitter stabilit= y", and "High reliability" in parallel. REQ8 somehow tries to address this.= But it would be premature to nail down this problem further - apparently, = there is no consensus in the working group on how to address such questions= . Thus, I don't think that we should significantly extend the appendix on t= hat. Nits: 3.1. Performance Impact --> Effects on Performanc 5.2. "This can be implicit in many cases, since MPTCP must BE disabled by the use of binding to a specific address. ^^^" [MSC] Thanks! ---------------------------------------------------------------------------= --- Claudio Allocchio G A R R Claudio.Allocchio@garr= .it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=3DClaudio; S=3DAlloc= chio; fax: +39 040 3758565 Research Network P=3Dgarr; A=3Dgarr; C= =3Dit; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca= From brian.e.carpenter@gmail.com Mon Nov 26 08:19: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 3CF7A21F862E; Mon, 26 Nov 2012 08:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 hpt3v7y6gzQ9; Mon, 26 Nov 2012 08:19:19 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C17221F8567; Mon, 26 Nov 2012 08:19:12 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so7147209eek.31 for ; Mon, 26 Nov 2012 08:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l0RMlPxHJIZ1/pfwsofLWyAVxLxGzeZ10Cg690edR+Y=; b=IRMbz7cXkpjF/ghFEmHm9AU4tD1YXHQ3XXjkxLQ8KzPx4OMuAMdKpWv1pBbkAHfeDj 2JeGTW4/XIbMJ/jj9SgSZOs+rr1ATtXSco6fE0RnTmYSHpSbM5klRxv606HrwMmmYcwI RsCD/koMdMT75buz1Rl1MCBChFZad/3eVziIJBUD9icj7sFLv5Zt/sR9sMuGI77YPyn4 AvbftPrpogtLrdSKEWM3aynETF1D48HPlN+dpJBHdVUGJYEEL0Ne8PjVgWCkrqW9I9w5 wHm86K9mWZ01Jsy3gK6nu4J/m8YASjbKH8BLB4ZICDlCQsRH3p1hbS6LIjc8IIW5aW3j fA7g== Received: by 10.14.176.68 with SMTP id a44mr47585425eem.1.1353946751669; Mon, 26 Nov 2012 08:19:11 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-115.as13285.net. [2.102.218.115]) by mx.google.com with ESMTPS id a45sm34391733eep.16.2012.11.26.08.19.09 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2012 08:19:10 -0800 (PST) Message-ID: <50B3967F.7040205@gmail.com> Date: Mon, 26 Nov 2012 16:19:11 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Yves Lafon References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-uri-zoneid@tools.ietf.org, appsdir@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-6man-uri-zoneid-05 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, 26 Nov 2012 16:19:20 -0000 Yves, On 26/11/2012 14:56, Yves Lafon 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 before posting a new version of the draft. > > Document: draft-ietf-6man-uri-zoneid-05 > Title: IPv6 Zone Identifiers in Address Literals and Uniform Resource > Identifiers > Reviewer: Yves Lafon > Review Date: 26 November 2012 > IETF Last Call Date: 2012-11-23 > > Summary: The document is almost ready to progress, but some > clarifications are needed on two points explicited below. > > In section 3: > << > This document implies that all browsers should recognise a ZoneID > preceded by an escaped "%". In the spirit of "be liberal with what > you accept", we also recommend that URI parsers accept bare "%" signs > (i.e., a "%" not followed by two valid hexadecimal characters). This > makes it easy for a user to copy and paste a string such as > "fe80::a%en1" from the output of a "ping" command and have it work. >>> > > Does it mean that such URIs can be present in an HTML document or that > they MAY allow bare "%" signs when the URI is pasted in the address bar? > (Those are two different use cases, and browsers may have different code > paths for both). This is exactly why I suggested in the "New URL Standard..." thread on the IETF list that we need a formal distinction between URI syntax and the permitted "syntax" for user input strings. Without that distinction, we are obliged to specify them both as if they were the same thing. I really don't know how to capture this in the current draft. Since we do say that URIs with ZoneIDs are meaningless outside the originating host, that would mean they shouldn't be included in HTML documents IMHO. But I think somebody needs to rewrite RFC 3986. > In section 4: > It says > << > An HTTP server or proxy MUST ignore any ZoneID attached to an > incoming URI, as it only has local significance at the sending host. >>> > > A proxy can be considered as a sending host, so does it mean that a the > receiving end MUST strip all ZoneID before processing the request? (and > it would be a significant change to implementations), or could this be > resolved by mandating Web browser to strip ZoneID prior to sending the > request as it is only significant for the sending host and as it is the > implementation that needs to be updated to recognize the new syntax? IMHO it would be safest if the sending host strips it. We could certainly suggest that. However, as the draft is on the IESG agenda this week, we won't update it until we get all the IESG comments. Thanks Brian From barryleiba@gmail.com Mon Nov 26 08:33: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 97FD521F85D5; Mon, 26 Nov 2012 08:33:03 -0800 (PST) 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=[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 0cErGRWvX6bQ; Mon, 26 Nov 2012 08:33:03 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B646F21F85C2; Mon, 26 Nov 2012 08:33:02 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so10341065vcb.31 for ; Mon, 26 Nov 2012 08:33:02 -0800 (PST) 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=ClFkuLQodXxpn3DWhmFGXh9y2S8lJMBsYM3laMGastU=; b=LIUKu9yXfMRi1YwCjZ5RqURMrGoD8V1whVQ9+9zw41BW5dkO6/klyyp0g2lf8mhpZx iTbW0StVOuIa0pD1yNssXra/Kp0IAQvZc1V/he7ciPcoXVRcRua9Vad+CMo/F8cGPN0a V95ypX9vTNkmyHQuCzeLcF9Iiuf0bSuO5Tgb9Qs5cItvnh4HixHkSIoo67XWR0huRQy1 mYf32A/rl3FAMamzRfL+uJJWZay7KTBZYbF+N1BGQTJMAE0RrQC9daZlv7sdhJ9u1Aeo 0K+yzVcTPHo55d/I1p6iIz6mtO6G1ymbne1qWkIOwcABXs/2Dn4sqbR3dODlLZ3oa/bR yeXQ== MIME-Version: 1.0 Received: by 10.220.238.148 with SMTP id ks20mr20136711vcb.5.1353947582199; Mon, 26 Nov 2012 08:33:02 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Mon, 26 Nov 2012 08:33:01 -0800 (PST) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B2@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <6.2.5.6.2.20121115153136.0a4db440@elandnews.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399B2@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Date: Mon, 26 Nov 2012 11:33:01 -0500 X-Google-Sender-Auth: cOGThqnOqH2AdzGbuu14CuHaOWI Message-ID: From: Barry Leiba To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" , "draft-ietf-mptcp-api.all@tools.ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-mptcp-api-06 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, 26 Nov 2012 16:33:03 -0000 >> 3.1.2. Delay >> >> Since burstiness is commonplace on the Internet >> today, it is unlikely that applications will suffer from such an >> impact on the traffic profile, but application authors may wish to >> consider this in future development. >> >> well, even it is true the burstiness is common on most of the >> Internet, this is not the case in many other circumstances, and there >> are, maybe a few, applications which do expect the jitter to be low >> and the packet delivery rate to be stable to work correctly (being >> the developer of one of them... "LOLA - Low latency A/V system" I did >> expericend already a number of cases where MPTCP did a disaster work >> just because of its presence on multiple parallel 10G links). Thus I >> would at least be not to optimistic in the above sentence. It is just >> not for future work. I just suggest changing it reportig that "this >> might be a problem" instead of "it is unlikely". > > [MSC] I don't know the details of the measurement you refer to, but it is > certainly important to distinguish between the protocol in general and the > behavior of an implementation, which is possibly work-in-progress. I do > agree that if a specific application does not need the additional bandwidth > by multipath and if it is very latency sensitive, the use of MPTCP could be > worse than use of standard TCP, in particular if the sender's scheduler is > not optimal. At least in theory, in such an application-limited scenario it > would make sense if the MPTCP scheduler mainly used the subflow with > smallest delay, i. e., jitter should be similar to a single-path TCP connection. > With a reasonable scheduler in the sender, I think that the scenario you > mention is indeed "unlikely". Anyway, I think that the scenario you describe > refers to a mostly controlled environment without congestion etc. In the > general Internet, an application does have to deal with jitter etc. ...etc... This and the related discussions seem to highlight that this document really has two pieces: 1. Considerations for using MPTCP with various applications and types of applications, independent of the API. 2. Definition of a basic API, and considerations specific to the API. It's possible (likely, maybe) that these should have been separate documents. I'm not sure whether it's too late to tease them apart, but I see some significant value in a document that just lays out (1) by itself. The discussion above fits into that: there's nothing about this that has anything to do with the API; it's considerations of whether MPTCP is, in general, advantageous, detrimental, or neutral for any particular application use case... and that's important. It becomes something of a problem when this document has some, but insufficient, discussion about this, as in this case. It's easy to say that applications in general have to deal with burstiness on the Internet, so adding a bit more probably won't hurt... but, as Claudio points out, that might not be true for all application types, and further discussion of this is warranted. The oversimplified statement might be OK for this document, or it might be problematic if it's taken as a valid statement to apply to all Internet applications. And there are other points in this document that fall into this category. What should we do about that? I've looked at the other MPTCP documents, and we have a very cursory section in RFC 6182 (MPTCP Architecture), "6.1 Interactions with Applications". Should there be another document that goes into more detail about application considerations for MPTCP? And what do we do with those issues in this document in the meantime? Leave them as they are? Pull them out altogether? Change them to indicate that more work needs to be done on application considerations? Barry, Applications AD From julian.reschke@gmx.de Mon Nov 26 08:37: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 9B09921F855B for ; Mon, 26 Nov 2012 08:37:57 -0800 (PST) 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 ozS7X4dI7iBu for ; Mon, 26 Nov 2012 08:37:57 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 764BD21F8554 for ; Mon, 26 Nov 2012 08:37:56 -0800 (PST) Received: (qmail invoked by alias); 26 Nov 2012 16:37:55 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp033) with SMTP; 26 Nov 2012 17:37:55 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+WZMlDXl6WvHlc5z8FoawD8tPfwprmBZDHZDOj4s 4sVBLfpwUzK3sl Message-ID: <50B39AE0.4010607@gmx.de> Date: Mon, 26 Nov 2012 17:37:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <50B2095C.2000501@ninebynine.org> <50B38AAA.5030908@stpeter.im> In-Reply-To: <50B38AAA.5030908@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "uri-review@ietf.org" , Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 26 Nov 2012 16:37:57 -0000 On 2012-11-26 16:28, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/25/12 5:04 AM, Graham Klyne wrote: >> I've just been digging around the XMPP specs, and I notive they >> make reference to required namespaces of the form "jabber:client" >> and "jabber:server" (cf. >> http://tools.ietf.org/html/rfc3920#section-11.2, esp sect 11.2.2). >> >> Examples in sections 8 and 9 of that spec reinforce the indication >> that jabber: is being used as a URI scheme (rather than a namespace >> prefix). > > The 'jabber:' string was used in the earliest days of the jabberd > server project when the core developers didn't really understand XML > namespaces (which were quite new at the time). It is not a URI scheme, > just a mistake. :) > >> But looking at http://www.iana.org/assignments/uri-schemes.html I'm >> not seeing any mention of jabber:. >> >> Assuming I'm reading this right... it's probably unfortunate that >> that this use of jabber: has come about (like dav: before it?) but >> I guess it's now entrenched and should at least be registered? > > I have never registered it and I hesitate to do so now because I think > it would cause more confusion than it's worth. We do have the 'xmpp:' > URI scheme for pointing to JabberIDs. > ... I think it would still be good to have it in the registry, and have the documentation explain what's going on. I believe the "DAV:" scheme was created for the same purpose, and we have documented that in . Best regards, Julian From stpeter@stpeter.im Mon Nov 26 08:39: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 9E77C21F8540; Mon, 26 Nov 2012 08:39:25 -0800 (PST) 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 FVaQ4a6TpPeH; Mon, 26 Nov 2012 08:39:25 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B7D6221F8542; Mon, 26 Nov 2012 08:39:23 -0800 (PST) Received: from [10.129.24.67] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 986BB40126; Mon, 26 Nov 2012 09:44:13 -0700 (MST) Message-ID: <50B39B3A.2000801@stpeter.im> Date: Mon, 26 Nov 2012 09:39:22 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Graham Klyne References: <50B2095C.2000501@ninebynine.org> <50B38AAA.5030908@stpeter.im> In-Reply-To: <50B38AAA.5030908@stpeter.im> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "uri-review@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 26 Nov 2012 16:39:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/26/12 8:28 AM, Peter Saint-Andre wrote: > On 11/25/12 5:04 AM, Graham Klyne wrote: >> I've just been digging around the XMPP specs, and I notive they >> make reference to required namespaces of the form >> "jabber:client" and "jabber:server" (cf. >> http://tools.ietf.org/html/rfc3920#section-11.2, esp sect >> 11.2.2). > >> Examples in sections 8 and 9 of that spec reinforce the >> indication that jabber: is being used as a URI scheme (rather >> than a namespace prefix). > > The 'jabber:' string was used in the earliest days of the jabberd > server project when the core developers didn't really understand > XML namespaces (which were quite new at the time). It is not a URI > scheme, just a mistake. :) > >> But looking at http://www.iana.org/assignments/uri-schemes.html >> I'm not seeing any mention of jabber:. > >> Assuming I'm reading this right... it's probably unfortunate >> that that this use of jabber: has come about (like dav: before >> it?) but I guess it's now entrenched and should at least be >> registered? > > I have never registered it and I hesitate to do so now because I > think it would cause more confusion than it's worth. We do have the > 'xmpp:' URI scheme for pointing to JabberIDs. Alexey pointed out to me offlist that these old 'jabber:*' strings are used in URI slots (as XML namespaces), so we probably do need to register this "scheme". Sigh. I'll take care of that. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCzmzoACgkQNL8k5A2w/vwiSQCfa/AVXURwBcl7dPE1Rxbh0/NL zVgAoNiG9UM66AcMl/J5NtdHu3iufc1A =5+Wh -----END PGP SIGNATURE----- From barryleiba.mailing.lists@gmail.com Mon Nov 26 09:00: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 9819A21F8460; Mon, 26 Nov 2012 09:00:25 -0800 (PST) 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=[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 ZwhWB6jtemZU; Mon, 26 Nov 2012 09:00:25 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 685A921F86D2; Mon, 26 Nov 2012 09:00:23 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so4167317eaa.31 for ; Mon, 26 Nov 2012 09:00:22 -0800 (PST) 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=ODUETJxyeaDn9BpGQbVxKPTjnUlit+3BXBLQpcQTY0Q=; b=otiP1y+swYjulrr44CHe2IU2VkV6n+bfJ9pE8h9SefcFqy//i3eGAX7sEA3wbSpJ+T gt9iux8688wBDzwglLZauO3yGtymTOQGMLM1kPHk1sFVW6gzxvEXTVVVwcsMrilAlsEV HCz3KPeCmc16JRDFLQbXzrP3dgMLxwjA2kCWGhfV9hVZorSFVPR8sJFUnAji05VwlB49 thQn9OJ9JyK0ySwKWKnysDtdZ+MmS/puthgEyfnnYnd5OepD8MdNUquJLFfQcVWUYXzW Vlrh7W6Vy7PwWpd8WONxOBUtRF+oFIcZjA77GxWaVMRGfgijm7+8BgGr1kDruMYzCAev SYEA== MIME-Version: 1.0 Received: by 10.14.179.69 with SMTP id g45mr47511195eem.42.1353949222324; Mon, 26 Nov 2012 09:00:22 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.14.100.202 with HTTP; Mon, 26 Nov 2012 09:00:22 -0800 (PST) In-Reply-To: <50B3967F.7040205@gmail.com> References: <50B3967F.7040205@gmail.com> Date: Mon, 26 Nov 2012 12:00:22 -0500 X-Google-Sender-Auth: CduW589RYRssA7KjeETzT_sljM0 Message-ID: From: Barry Leiba To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-6man-uri-zoneid@tools.ietf.org, "appsdir@ietf.org" , IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-ietf-6man-uri-zoneid-05 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, 26 Nov 2012 17:00:25 -0000 >> << >> This document implies that all browsers should recognise a ZoneID >> preceded by an escaped "%". In the spirit of "be liberal with what >> you accept", we also recommend that URI parsers accept bare "%" signs >> (i.e., a "%" not followed by two valid hexadecimal characters). This >> makes it easy for a user to copy and paste a string such as >> "fe80::a%en1" from the output of a "ping" command and have it work. >>>> >> >> Does it mean that such URIs can be present in an HTML document or that >> they MAY allow bare "%" signs when the URI is pasted in the address bar? >> (Those are two different use cases, and browsers may have different code >> paths for both). > > This is exactly why I suggested in the "New URL Standard..." thread > on the IETF list that we need a formal distinction between URI syntax > and the permitted "syntax" for user input strings. Without that > distinction, we are obliged to specify them both as if they were > the same thing. I really don't know how to capture this in the current > draft. Perhaps it could be captured with something like this added to the quoted paragraph?: Such bare "%" signs are for user interface convenience, and must be turned into properly escaped characters ("%25" encodes "%" in URIs) before the URI is used in any protocol. > Since we do say that URIs with ZoneIDs are meaningless outside the > originating host, that would mean they shouldn't be included in HTML > documents IMHO. But I think somebody needs to rewrite RFC 3986. There's been some noise about that, both within and without the IETF. Barry From stpeter@stpeter.im Mon Nov 26 10:50: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 E3C2D21F8621; Mon, 26 Nov 2012 10:50:22 -0800 (PST) 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 2xPqMNbGr7VW; Mon, 26 Nov 2012 10:50:22 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 027C521F8613; Mon, 26 Nov 2012 10:50:22 -0800 (PST) Received: from [10.129.24.67] (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C750640092; Mon, 26 Nov 2012 11:55:11 -0700 (MST) Message-ID: <50B3B9EC.6010007@stpeter.im> Date: Mon, 26 Nov 2012 11:50:20 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Julian Reschke References: <50B2095C.2000501@ninebynine.org> <50B38AAA.5030908@stpeter.im> <50B39AE0.4010607@gmx.de> In-Reply-To: <50B39AE0.4010607@gmx.de> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "uri-review@ietf.org" , Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 26 Nov 2012 18:50:26 -0000 On 11/26/12 9:37 AM, Julian Reschke wrote: > On 2012-11-26 16:28, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 11/25/12 5:04 AM, Graham Klyne wrote: >>> I've just been digging around the XMPP specs, and I notive they >>> make reference to required namespaces of the form "jabber:client" >>> and "jabber:server" (cf. >>> http://tools.ietf.org/html/rfc3920#section-11.2, esp sect 11.2.2). >>> >>> Examples in sections 8 and 9 of that spec reinforce the indication >>> that jabber: is being used as a URI scheme (rather than a namespace >>> prefix). >> >> The 'jabber:' string was used in the earliest days of the jabberd >> server project when the core developers didn't really understand XML >> namespaces (which were quite new at the time). It is not a URI scheme, >> just a mistake. :) >> >>> But looking at http://www.iana.org/assignments/uri-schemes.html I'm >>> not seeing any mention of jabber:. >>> >>> Assuming I'm reading this right... it's probably unfortunate that >>> that this use of jabber: has come about (like dav: before it?) but >>> I guess it's now entrenched and should at least be registered? >> >> I have never registered it and I hesitate to do so now because I think >> it would cause more confusion than it's worth. We do have the 'xmpp:' >> URI scheme for pointing to JabberIDs. >> ... > > I think it would still be good to have it in the registry, and have the > documentation explain what's going on. > > I believe the "DAV:" scheme was created for the same purpose, and we > have documented that in > . Thanks for the pointer. And yes, as with "DAV:", the "jabber:" prefix was defined before standard best practices emerged for XML namespaces... Peter -- Peter Saint-Andre https://stpeter.im/ From GK@ninebynine.org Mon Nov 26 10:54: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 7BF4A21F852D; Mon, 26 Nov 2012 10:54:59 -0800 (PST) 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 NUzbYiLUCstQ; Mon, 26 Nov 2012 10:54:58 -0800 (PST) Received: from relay3.mail.ox.ac.uk (relay3.mail.ox.ac.uk [163.1.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1975121F8449; Mon, 26 Nov 2012 10:54:56 -0800 (PST) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay3.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1Td3pW-0007nX-Au; Mon, 26 Nov 2012 18:54:54 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Td3pW-0001fv-3J; Mon, 26 Nov 2012 18:54:54 +0000 Message-ID: <50B3A184.9080100@ninebynine.org> Date: Mon, 26 Nov 2012 17:06:12 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <50B2095C.2000501@ninebynine.org> <50B38AAA.5030908@stpeter.im> In-Reply-To: <50B38AAA.5030908@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: "uri-review@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 26 Nov 2012 18:54:59 -0000 Peter, I take your points, but... As I read the XMPP spec, a string "jabber:client" or "jabber:server" is used in a context where a URI is required (i.e. an xmlns attribute). Hence in this usage, "jabber:" *is* a URI scheme name. (Consider - if someone introduced a genuine jabber: scheme, then wanted to use it for XML namespaces in an XMPP stream, they could run into problems.) It's very similar to the way @dav:@ is used by WebDAV, and that *is* registered as a URI scheme. To the extent that the registry aims to document actual usage, I think registration is appropriate, probably linked with some verbiage that makes it clear this is a historical "accident" rather than intended for general use. #g -- On 26/11/2012 15:28, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/25/12 5:04 AM, Graham Klyne wrote: >> I've just been digging around the XMPP specs, and I notive they >> make reference to required namespaces of the form "jabber:client" >> and "jabber:server" (cf. >> http://tools.ietf.org/html/rfc3920#section-11.2, esp sect 11.2.2). >> >> Examples in sections 8 and 9 of that spec reinforce the indication >> that jabber: is being used as a URI scheme (rather than a namespace >> prefix). > > The 'jabber:' string was used in the earliest days of the jabberd > server project when the core developers didn't really understand XML > namespaces (which were quite new at the time). It is not a URI scheme, > just a mistake. :) > >> But looking at http://www.iana.org/assignments/uri-schemes.html I'm >> not seeing any mention of jabber:. >> >> Assuming I'm reading this right... it's probably unfortunate that >> that this use of jabber: has come about (like dav: before it?) but >> I guess it's now entrenched and should at least be registered? > > I have never registered it and I hesitate to do so now because I think > it would cause more confusion than it's worth. We do have the 'xmpp:' > URI scheme for pointing to JabberIDs. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iEYEARECAAYFAlCziqkACgkQNL8k5A2w/vwWLACeK92mGiyENuSi36azX09h2NxH > 7RAAnjAYU89bIFoJec0qh9DxPBq0GgYa > =PBrH > -----END PGP SIGNATURE----- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From krisnye@gmail.com Mon Nov 26 11:31: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 9B93C21F849A for ; Mon, 26 Nov 2012 11:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.335 X-Spam-Level: * X-Spam-Status: No, score=1.335 tagged_above=-999 required=5 tests=[AWL=2.181, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.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 DS+oLoMoOKSN for ; Mon, 26 Nov 2012 11:31:19 -0800 (PST) Received: from joe.nabble.com (216-139-250-139.aus.us.siteprotect.com [216.139.250.139]) by ietfa.amsl.com (Postfix) with ESMTP id BB83E21F845E for ; Mon, 26 Nov 2012 11:31:19 -0800 (PST) Received: from tom.nabble.com ([192.168.236.105]) by joe.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Td4Ok-0005kl-R2 for apps-discuss@ietf.org; Mon, 26 Nov 2012 11:31:18 -0800 Date: Mon, 26 Nov 2012 11:31:18 -0800 (PST) From: krisnye To: apps-discuss@ietf.org Message-ID: <1353958278810-347543.post@n7.nabble.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Updated JSON Merge Patch... 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, 26 Nov 2012 19:32:05 -0000 I independently developed an almost identical solution for simple patches about a year ago. The only difference is that I do not special case null. It is treated like any other json value. I use 'undefined' to indicate removal of a value. There are some advantages and disadvantages to this. The disadvantage is obviously that undefined is not a valid json value. The main advantage is that EVERY valid json document now becomes a valid merge patch object that will create itself if applied to a null object. It is also useful because we really need to set a null value on some properties sometimes. We cannot do it if null is special cased. For instance, I want to be able to patch more than just raw json objects. I should be able to patch ANY javascript object. If the javascript object has a getter/setter defined on a property, then deleting that property does nothing (and returns false). If I want the property value to be null, I must be able to actually set null on it. Also, you should really note the merge-patch advantage of being inherently idempotent when compared to JSONPatch which is not inherently idempotent (but can be made so with use of test op). I would also recommend noting that you can patch a patch and the operation is *mostly* associative. -- View this message in context: http://ietf.10.n7.nabble.com/apps-discuss-Updated-JSON-Merge-Patch-tp340197p347543.html Sent from the IETF - Discuss mailing list archive at Nabble.com. From ve7jtb@ve7jtb.com Mon Nov 26 12:23: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 8050821F85D0 for ; Mon, 26 Nov 2012 12:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, SARE_MILLIONSOF=0.315] 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 1wUF2iPT5dTr for ; Mon, 26 Nov 2012 12:23:56 -0800 (PST) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADA4521F85D4 for ; Mon, 26 Nov 2012 12:23:56 -0800 (PST) Received: by mail-gh0-f172.google.com with SMTP id z22so1091245ghb.31 for ; Mon, 26 Nov 2012 12:23:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=KvxpWJYB2tNLgmT4MiFOfpAKk3fuG8wvS14Yo+3c/S0=; b=XwEDsNmVW1SE0SGhQIMlFr4ffQ7FaYtwx/q/ueoCYT0SuK8Ax5DPWdwt+hoa1vuLlf en8JHDz1wSwvjDSmKi+iSXJsR3WngJ9oURBpkYv3qr6kAzWusZsudhbuCBMhwjg/nWAw ehJs6Edt7K4nTm7GjaSuE71GoZt9vQF7Y76YnYiDoHIfKVicbUJjYzUlMNLOGregYUVO Gq12SZvE58fawX3Z++asohlWUYgcYiUs47QpTlV2c3rPCNc1MPictoWscpXaubr6+gfm I6OXjTyoLXa7/lloPF4Lshm1rqiiCAQDEAlYiLy9eKPNrNcxCUOpoQmDjZ+6CgoUn9wj LGnw== Received: by 10.101.50.11 with SMTP id c11mr3698240ank.5.1353961436179; Mon, 26 Nov 2012 12:23:56 -0800 (PST) Received: from [192.168.1.43] (190-20-23-36.baf.movistar.cl. [190.20.23.36]) by mx.google.com with ESMTPS id k63sm16257119yhj.20.2012.11.26.12.23.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 12:23:55 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_0E6E539C-DC62-44DA-937B-597C385F65B3" From: John Bradley In-Reply-To: Date: Mon, 26 Nov 2012 17:23:14 -0300 Message-Id: References: To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnBuRH2FANdVzpQIzTXVrJRgYWvy1X88/l0+7pHEMpmTj5BNcQMksZys7ENVps4KuNHK4Ok Cc: Tim Bray , apps-discuss@ietf.org Subject: Re: [apps-discuss] webfinger goals & whether we care about $5/month hosting 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, 26 Nov 2012 20:23:57 -0000 --Apple-Mail=_0E6E539C-DC62-44DA-937B-597C385F65B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brad, I think a Google blog post in Oct of 2011 put the number of Apps for = domains customers (all types) at 4 Million Businesses and 40 Million = users. Without allowing for growth if that is 50% of the hosting market that is = 80Million users. I am not personally associated with any of these but it seems like a = significant user population especially as these users represent a = growing consumer segment of SaaS services. openID Connect ignoring this user group seems like a disservice. Due to concerns over phishing, if Connect uses WF it will need to be = over TLS. =20 Telling companies that they need to change web hosting companies so that = Google or Sales force can provide Identity services seems like a hard = sell. One problem with using WF is that it puts web hosting people in charge = of something that is used for security infrastructure. My father who is a redneck also runs a multi million dollar business, = with over 500 employes and is increasingly relying on outsourced SaaS, = and that requires Federated identity of some sort to do well. The business is parking lots(not making it up) so there web site is not = seen as mission critical. Where email and perhaps SalesForce arguably = are. How do we help these millions of businesses? =20 Perhaps saying nothing can be done for them until we have new WF enabled = providers who can link discovery to the email and other identity = services is an option. I think WF needs to decide if this is an important use case and if it is = what is the best way to solve the problem that real users can deal with. Regards John B. On 2012-11-26, at 4:56 PM, Brad Fitzpatrick wrote: > One of the reasons WebFinger development has moved so slowly (while = proprietary silos continue to grow) is that we as a community have no = focus, no deadlines, no decision makers, and no clear goals even. >=20 > After seeing conflicting opinions both on lists and off-list, I'd like = to discuss one goal (or non-goal) here: >=20 > Does WebFinger care about people on "$5/month" static domain hosting = plans? >=20 > As one person asked off-list, "How do we solve this for my Father (a = redneck luddite if you have ever met him)?" >=20 > Personally, I think we should not care about this group. These = theoretical "rednecks" won't run their own webfinger servers, and we = shouldn't care. Most users will use a service provider for their = webfinger, and anybody that has their own domain name and really wants = to be in charge of their own identity will be able to own their root and = be able to serve dynamic content from it (and for LESS than "$5/month"). = And if webfinger becomes successful enough for these tech "luddites" = (who already pay for their own domain name?) to want WebFinger, the = market will adapt: these static hosting providers can provide webfinger = access for them, mapping to static files under the user's control. >=20 > Opinions? >=20 > Regardless, can we lay out the assumptions & goals in the spec, so = people understand what webfinger aims to both solve and to NOT solve? >=20 --Apple-Mail=_0E6E539C-DC62-44DA-937B-597C385F65B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii bradfitz@google.com> = wrote:

One of the reasons WebFinger development has moved so = slowly (while proprietary silos continue to grow) is that we as a = community have no focus, no deadlines, no decision makers, and no clear = goals even.

After seeing conflicting opinions both on lists and = off-list, I'd like to discuss one goal (or non-goal) = here:

Does WebFinger care about people on = "$5/month" static domain hosting plans?

As one person asked off-list, "How do we solve this for = my Father (a redneck luddite if you have ever met = him)?"

Personally, I think we should not care = about this group.  These theoretical "rednecks" won't run = their own webfinger servers, and we shouldn't care.  Most users = will use a service provider for their webfinger, and anybody that has = their own domain name and really wants to be in charge of their own = identity will be able to own their root and be able to serve dynamic = content from it (and for LESS than "$5/month").  And if webfinger = becomes successful enough for these tech "luddites" (who already pay for = their own domain name?) to want WebFinger, the market will adapt: these = static hosting providers can provide webfinger access for them, mapping = to static files under the user's control.

Opinions?

Regardless, can we lay = out the assumptions & goals in the spec, so people understand what = webfinger aims to both solve and to NOT solve?


= --Apple-Mail=_0E6E539C-DC62-44DA-937B-597C385F65B3-- From jhildebr@cisco.com Mon Nov 26 12:24: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 7F86D21F8600 for ; Mon, 26 Nov 2012 12:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 L2nAwZAar6d3 for ; Mon, 26 Nov 2012 12:24:32 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C4C9221F85EE for ; Mon, 26 Nov 2012 12:24:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1897; q=dns/txt; s=iport; t=1353961473; x=1355171073; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9JzCX6M07XS9Vt2LZ8E80O8CZ0l2nxR7M6AlQ6809Ro=; b=WBVdvixnsH6+Nv7vNO2OIM7xMFIWm3Z6a5wbW6chR+R9o46OyfrmO695 dQxG7EvFQKxxsTkSf0gNtdDbkVpHPy+dy2oLZ33BE1HIQMH0p+anc1g3j t9ynbiuDaE8p975XmUfyiNCNOR154wfqab98hPiVZcCuGuLcKDzLvoUqC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJLPs1CtJXG+/2dsb2JhbABEwCQWc4IeAQEBAwE6MgoDEgEIIhRCJQIEAQ0FCId/BsBokBdhA5cdjyiCb4Id X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146346151" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 26 Nov 2012 20:24:32 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAQKOWSo007021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Nov 2012 20:24:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.236]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Mon, 26 Nov 2012 14:24:31 -0600 From: "Joe Hildebrand (jhildebr)" To: John R Levine , James M Snell Thread-Topic: [apps-discuss] Javascript and SRV, was draft-ietf-appsawg-webfinger-04 Thread-Index: AQHNysg9jJpVWTl7gEGGYCsONtC665f8gdaA Date: Mon, 26 Nov 2012 20:24:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.129.24.84] Content-Type: text/plain; charset="us-ascii" Content-ID: <5AB5927BB8923B459F567FF8D1AEF449@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Javascript and SRV, was draft-ietf-appsawg-webfinger-04 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, 26 Nov 2012 20:24:33 -0000 On 11/24/12 9:49 PM, "John R Levine" wrote: >> Generally, the same origin rule would not apply. When some piece of >> javascript uses the API, it's basically just asking the browser to do >>some >> additional dns resolution using the same dns server it uses for it's own >> resolution. The javascript does not gain access to anything more than >>what >> the browser does. What the javascript gets back is just some basic >> information about the name records, nothing more. The same origin rule >>does >> not come into play until the script attempts to put that information to >>use >> via ajax calls, etc. > >Well, OK. You do a SRV lookup, you get a host name and a port number, >which are probably not the host name and port number your script came >from. Keeping in mind the same origin rule, what do you do with it? AFAIK, JavaScript does not get access to the results of the A/AAAA query before a page is loaded today. Imagine the following scenario: - User A on Network N requests page P - P contains an attacker's JavaScript - N is using split DNS; queries on that network return different results than queries externally, presumably for perceived security reasons - Without some same origin rules, P now has access to sensitive information - For example, the server behind P does reverse-DNS lookup on the source IP address for the initial request, guesses a domain for A, let's say "example.com", then passes that information to the JavaScript in P using AJAX - P now does SRV queries for _ldap._tcp.example.com, and starts attacking your internal, poorly-secured LDAP server using CORS AJAX/WebSocket requests. I'm not sure it's possible to describe other DNS queries as being same-origin to P; by definition, they're liable to be different for names or ports, or you would already know the answer. --=20 Joe Hildebrand From jhildebr@cisco.com Mon Nov 26 12:27: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 3601621F860A; Mon, 26 Nov 2012 12:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 6Ob1EFvxkkG0; Mon, 26 Nov 2012 12:27:55 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 496E521F8619; Mon, 26 Nov 2012 12:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2315; q=dns/txt; s=iport; t=1353961675; x=1355171275; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=E6PfVRxviFiI6fWicdnVSF0aa+hKDF3AVZr5OkLLA1U=; b=A3zXshaWaSbjUn2PQ6wEhDIWhTIXRVf5P7wI7bql9NIcXE/Pm7y0tSEx 5Kd13iIdWTtzFoxzwRCO08lENrWVc+9BE6NxFelcZFsb+GbMy9w0K3V/7 fpICsxVj3kNsdaa20KbWIQGVNodeJOjL0OyY0mosuyzqqVPewCYk9oMSa s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAI3Qs1CtJV2a/2dsb2JhbABEwCQWc4IeAQEBBAEBATc0CxIBCBgKFDcLJQIEAQ0FCAGIBAzAW5AXYQOXHY8ogm+CHQ X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="143350997" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 26 Nov 2012 20:27:53 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAQKRrPJ003283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Nov 2012 20:27:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.236]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Mon, 26 Nov 2012 14:27:53 -0600 From: "Joe Hildebrand (jhildebr)" To: Peter Saint-Andre , Julian Reschke , "xmpp@ietf.org" Thread-Topic: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? Thread-Index: AQHNzBSCfRYVe/3F6Uu1oZkj94/60w== Date: Mon, 26 Nov 2012 20:27:52 +0000 Message-ID: In-Reply-To: <50B3B9EC.6010007@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.129.24.84] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "uri-review@ietf.org" , Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 26 Nov 2012 20:27:56 -0000 Looping the XMPP wg list. If we register it, let's make sure that registration says "DO NOT USE IN THE FUTURE". On 11/26/12 11:50 AM, "Peter Saint-Andre" wrote: >On 11/26/12 9:37 AM, Julian Reschke wrote: >> On 2012-11-26 16:28, Peter Saint-Andre wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 11/25/12 5:04 AM, Graham Klyne wrote: >>>> I've just been digging around the XMPP specs, and I notive they >>>> make reference to required namespaces of the form "jabber:client" >>>> and "jabber:server" (cf. >>>> http://tools.ietf.org/html/rfc3920#section-11.2, esp sect 11.2.2). >>>> >>>> Examples in sections 8 and 9 of that spec reinforce the indication >>>> that jabber: is being used as a URI scheme (rather than a namespace >>>> prefix). >>> >>> The 'jabber:' string was used in the earliest days of the jabberd >>> server project when the core developers didn't really understand XML >>> namespaces (which were quite new at the time). It is not a URI scheme, >>> just a mistake. :) >>> >>>> But looking at http://www.iana.org/assignments/uri-schemes.html I'm >>>> not seeing any mention of jabber:. >>>> >>>> Assuming I'm reading this right... it's probably unfortunate that >>>> that this use of jabber: has come about (like dav: before it?) but >>>> I guess it's now entrenched and should at least be registered? >>> >>> I have never registered it and I hesitate to do so now because I think >>> it would cause more confusion than it's worth. We do have the 'xmpp:' >>> URI scheme for pointing to JabberIDs. >>> ... >>=20 >> I think it would still be good to have it in the registry, and have the >> documentation explain what's going on. >>=20 >> I believe the "DAV:" scheme was created for the same purpose, and we >> have documented that in >> . > >Thanks for the pointer. And yes, as with "DAV:", the "jabber:" prefix >was defined before standard best practices emerged for XML namespaces... > >Peter > >--=20 >Peter Saint-Andre >https://stpeter.im/ > > >_______________________________________________ >apps-discuss mailing list >apps-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 Joe Hildebrand From stpeter@stpeter.im Mon Nov 26 12:30: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 5FFA721F8651; Mon, 26 Nov 2012 12:30:01 -0800 (PST) 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 tZ4yksbn12JM; Mon, 26 Nov 2012 12:30:00 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CF67221F863B; Mon, 26 Nov 2012 12:30:00 -0800 (PST) Received: from [10.129.24.67] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CD4DB40092; Mon, 26 Nov 2012 13:34:50 -0700 (MST) Message-ID: <50B3D146.3080506@stpeter.im> Date: Mon, 26 Nov 2012 13:29:58 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "uri-review@ietf.org" , Graham Klyne , "apps-discuss@ietf.org" , "xmpp@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 26 Nov 2012 20:30:01 -0000 Agreed. We would register it immediately as historical. http://tools.ietf.org/html/rfc4395#section-4 On 11/26/12 1:27 PM, Joe Hildebrand (jhildebr) wrote: > Looping the XMPP wg list. If we register it, let's make sure that > registration says "DO NOT USE IN THE FUTURE". > > On 11/26/12 11:50 AM, "Peter Saint-Andre" wrote: > >> On 11/26/12 9:37 AM, Julian Reschke wrote: >>> On 2012-11-26 16:28, Peter Saint-Andre wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 11/25/12 5:04 AM, Graham Klyne wrote: >>>>> I've just been digging around the XMPP specs, and I notive they >>>>> make reference to required namespaces of the form "jabber:client" >>>>> and "jabber:server" (cf. >>>>> http://tools.ietf.org/html/rfc3920#section-11.2, esp sect 11.2.2). >>>>> >>>>> Examples in sections 8 and 9 of that spec reinforce the indication >>>>> that jabber: is being used as a URI scheme (rather than a namespace >>>>> prefix). >>>> >>>> The 'jabber:' string was used in the earliest days of the jabberd >>>> server project when the core developers didn't really understand XML >>>> namespaces (which were quite new at the time). It is not a URI scheme, >>>> just a mistake. :) >>>> >>>>> But looking at http://www.iana.org/assignments/uri-schemes.html I'm >>>>> not seeing any mention of jabber:. >>>>> >>>>> Assuming I'm reading this right... it's probably unfortunate that >>>>> that this use of jabber: has come about (like dav: before it?) but >>>>> I guess it's now entrenched and should at least be registered? >>>> >>>> I have never registered it and I hesitate to do so now because I think >>>> it would cause more confusion than it's worth. We do have the 'xmpp:' >>>> URI scheme for pointing to JabberIDs. >>>> ... >>> >>> I think it would still be good to have it in the registry, and have the >>> documentation explain what's going on. >>> >>> I believe the "DAV:" scheme was created for the same purpose, and we >>> have documented that in >>> . >> >> Thanks for the pointer. And yes, as with "DAV:", the "jabber:" prefix >> was defined before standard best practices emerged for XML namespaces... >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss From jhildebr@cisco.com Mon Nov 26 12:30: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 36A8921F8653 for ; Mon, 26 Nov 2012 12:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 44d0Q5SdNrIh for ; Mon, 26 Nov 2012 12:30:28 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBF321F8659 for ; Mon, 26 Nov 2012 12:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=647; q=dns/txt; s=iport; t=1353961828; x=1355171428; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/+9+tJ4A7qitKt4eHTJTts0bkk3IrazRmtTCRB/wDP0=; b=d5hKILTE06ZjDpKpzDlOSAjst6f0KUZlBd5UnneV0VX12VqS0simYjNq PKM/iLhSj7sts7ySaHLfhF3KRctAwxRQXE4GIAsHPBU1YV5HfDg4wYx/W 3GU72aOIfurRBRl8vBewFZl8nPwl3ifEqW6mqAmQ+o3ZMn2cHtpkDFwWa E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAPrPs1CtJV2Z/2dsb2JhbABEDoVTukMWc4IgAQR5EgEIIhk9JQIEAQ0FCIgFwGqQF2EDiCmeHIIyPYId X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146349985" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 26 Nov 2012 20:30:28 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAQKUSUI001063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Nov 2012 20:30:28 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.236]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Mon, 26 Nov 2012 14:30:27 -0600 From: "Joe Hildebrand (jhildebr)" To: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdFwi?= , "Graham Klyne" Thread-Topic: [apps-discuss] Does / Should the IETF support *browser-side* JavaScript as a programming platform? Thread-Index: AQHNy2+lhXViXqgCTkueMPfgL0vsopf8gi+A Date: Mon, 26 Nov 2012 20:30:27 +0000 Message-ID: In-Reply-To: <50B2BC18.6030104@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.129.24.84] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Does / Should the IETF support *browser-side* JavaScript as a programming platform? 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, 26 Nov 2012 20:30:29 -0000 On 11/25/12 5:47 PM, ""Martin J. D=FCrst"" wrote: >Employee A at company B visits web site C over lunch. Web site C >includes (or points to) JavaScript that scans company B's DNS system to >figure out its structure and detect potential weak points. This >information is sent back to C without A noticing. As a result, >information about B (e.g. internal structure, new but as of yet secret >products,...) and its network infrastructure may leak to C. Sorry, I replied without having read this whole thread (since the subject changed). My example is effectively the same as Martin's. --=20 Joe Hildebrand From jasnell@gmail.com Mon Nov 26 12:42: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 0C39721F86EA for ; Mon, 26 Nov 2012 12:42:19 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niA-1TgRShHv for ; Mon, 26 Nov 2012 12:42:18 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 61E9121F86E4 for ; Mon, 26 Nov 2012 12:42:18 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so12652358oag.31 for ; Mon, 26 Nov 2012 12:42:18 -0800 (PST) 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=WyBkEvD2C58ROwG+H3VP12csqXdX1Dx88aHN7BkLAXg=; b=yvSiD6WB9LjomGSqB37PBo+n2XHQzJPfuNx2JmuZPsru5wm7EW8K7mK4A09g627rln g1fiofBi8YuOcPiQpiT/iv7MoWMA8ML9ZQ9nOvU8SyY2gTMP/JRKzCOXqJ65Vt0wD8XN gk9in0CKrGbVSO/cjrS83FFFPufTSUtYFBLHJwG7xSHCVE2G6YEABzeU862/fO1iiBeA v9V0r/xfWl/4Ror9P01ai+HbzuyG4a+vL6NVejupbsEegnpsNI2KELBaB+D7maO2OqvH 3vqJ00hSKje6zdXdrEdktGCX3ZymbeTpSPtekD5s5/6WQATeS2+T+R2ZaxYmMPAlHgb3 3Lpg== Received: by 10.60.30.167 with SMTP id t7mr10449350oeh.44.1353962537999; Mon, 26 Nov 2012 12:42:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.68.37 with HTTP; Mon, 26 Nov 2012 12:41:56 -0800 (PST) In-Reply-To: References: <50B2BC18.6030104@it.aoyama.ac.jp> From: James M Snell Date: Mon, 26 Nov 2012 12:41:56 -0800 Message-ID: To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=e89a8ff1c7c61dded404cf6bf8e9 Cc: Graham Klyne , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Does / Should the IETF support *browser-side* JavaScript as a programming platform? 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, 26 Nov 2012 20:42:19 -0000 --e89a8ff1c7c61dded404cf6bf8e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This case definitely points to why raw sockets or an "unmanaged" dns client mechanism for javascript would definitely not be desirable. To mitigate this case, a "name query" api could be limited to allow only queries for the current domain and it's subdomains. That is, if I'm loading a page from "example.org", then doing a name query for "_webfinger._tcp.example.org." would be acceptable but "_webfinger._tcp.example.com" would not. - James On Mon, Nov 26, 2012 at 12:30 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 11/25/12 5:47 PM, ""Martin J. D=C3=BCrst"" wr= ote: > > >Employee A at company B visits web site C over lunch. Web site C > >includes (or points to) JavaScript that scans company B's DNS system to > >figure out its structure and detect potential weak points. This > >information is sent back to C without A noticing. As a result, > >information about B (e.g. internal structure, new but as of yet secret > >products,...) and its network infrastructure may leak to C. > > Sorry, I replied without having read this whole thread (since the subject > changed). My example is effectively the same as Martin's. > > -- > Joe Hildebrand > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --e89a8ff1c7c61dded404cf6bf8e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This case definitely points to why ra= w sockets or an "unmanaged" dns client mechanism for javascript w= ould definitely not be desirable. To mitigate this case, a "name query= " api could be limited to allow only queries for the current domain an= d it's subdomains. That is, if I'm loading a page from "example.org", then doing a name query for= "_webfinger._tcp.example.org.&= quot; would be acceptable but "_webfinger._tcp.example.com" would not.=C2=A0

- James

<= br>
On Mon, Nov 26, 2012 at 12:30 PM, Joe Hildebr= and (jhildebr) <jhildebr@cisco.com> wrote:
On 11/25/12 5:47 PM, "= ;"Martin J. D=C3=BCrst"" <duerst@it.aoyama.ac.jp> wrote:

>Employee A at company B visits web site C over lunch. Web site C
>includes (or points to) JavaScript that scans company B's DNS syste= m to
>figure out its structure and detect potential weak points. This
>information is sent back to C without A noticing. As a result,
>information about B (e.g. internal structure, new but as of yet secret<= br> >products,...) and its network infrastructure may leak to C.

Sorry, I replied without having read this whole thread (since the sub= ject
changed). =C2=A0My example is effectively the same as Martin's.

--
Joe Hildebrand



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

--e89a8ff1c7c61dded404cf6bf8e9-- From joe.gregorio@gmail.com Mon Nov 26 12:45: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 7A58221F86FA for ; Mon, 26 Nov 2012 12:45:05 -0800 (PST) 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 fS+PZ9ix5Y0P for ; Mon, 26 Nov 2012 12:45:04 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B11621F8742 for ; Mon, 26 Nov 2012 12:45:04 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so7311665eek.31 for ; Mon, 26 Nov 2012 12:45:03 -0800 (PST) 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=8mUiXDUNAEl4M1u2SXexdYCf/tzP3w4h9CV95xHTyYk=; b=RmWoi4gJ/uDK25v+ZNLDS3BmZ7hdxteHEy1FyTUUrK4ZLgodegpIijWxUO4JPYaxp1 64dTL/3mCFcHqfhs5ziLGxZHaPanxMuHJOIvNS4rZlU+TufkGY9/7siVsKnlGpcI2JNg vyNxDmNDWNeKeo6SXLzeXfWy8FLv6aQdPIDqYm0lWAPCxL9rfu4xzxVPKY9qp4XeDnwO E/ZhdhRZeFoGEjfvjjx24n86ROMsC2ZfXURi+wtmAA+x5ZhMxUT4cPA2ItsSpXn5D0aK D6Wmw0R4u98Ib7Cae88v62bKFU91lk8r3GzVgD4gQNfvdK8C3TPRpobPNPJJ7bM6gpe6 8+AA== MIME-Version: 1.0 Received: by 10.14.216.70 with SMTP id f46mr49773336eep.12.1353962703302; Mon, 26 Nov 2012 12:45:03 -0800 (PST) Sender: joe.gregorio@gmail.com Received: by 10.223.158.137 with HTTP; Mon, 26 Nov 2012 12:45:03 -0800 (PST) In-Reply-To: References: Date: Mon, 26 Nov 2012 15:45:03 -0500 X-Google-Sender-Auth: 8gERkHoEH4ovKO-YgogT-_sb570 Message-ID: From: Joe Gregorio To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=047d7b603c1ef8323104cf6c0102 Cc: Tim Bray , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] webfinger goals & whether we care about $5/month hosting 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, 26 Nov 2012 20:45:05 -0000 --047d7b603c1ef8323104cf6c0102 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 26, 2012 at 2:56 PM, Brad Fitzpatrick wrote: > One of the reasons WebFinger development has moved so slowly (while > proprietary silos continue to grow) is that we as a community have no > focus, no deadlines, no decision makers, and no clear goals even. > > After seeing conflicting opinions both on lists and off-list, I'd like to > discuss one goal (or non-goal) here: > > Does WebFinger care about people on "$5/month" static domain hosting plans? > I don't think I'd phrase it as harshly as "don't care", but I do think it's a huge mistake to let the existence of such accounts limit WebFinger. Also, isn't serving a 302 a static operation? -joe > > As one person asked off-list, "How do we solve this for my Father (a > redneck luddite if you have ever met him)?" > > Personally, I think we should not care about this group. > These theoretical "rednecks" won't run their own webfinger servers, and we > shouldn't care. Most users will use a service provider for their > webfinger, and anybody that has their own domain name and really wants to > be in charge of their own identity will be able to own their root and be > able to serve dynamic content from it (and for LESS than "$5/month"). And > if webfinger becomes successful enough for these tech "luddites" (who > already pay for their own domain name?) to want WebFinger, the market will > adapt: these static hosting providers can provide webfinger access for > them, mapping to static files under the user's control. > > Opinions? > > Regardless, can we lay out the assumptions & goals in the spec, so people > understand what webfinger aims to both solve and to NOT solve? > > -- Joe Gregorio http://bitworking.org --047d7b603c1ef8323104cf6c0102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, N= ov 26, 2012 at 2:56 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:
One of the reasons WebFinger development has moved= so slowly (while proprietary silos continue to grow) is that we as a commu= nity have no focus, no deadlines, no decision makers, and no clear goals ev= en.

After seeing conflicting opinions both on lists and off-list= , I'd like to discuss one goal (or non-goal) here:

=
Does WebFinger care about people on "$5/month"=A0static doma= in hosting plans?

I don't think I'd phra= se it as harshly as "don't care", but I do think it's a h= uge mistake to let the existence of such
accounts limit WebFinger= .

Also, isn't serving a 302 a static operation?
=

=A0 -joe
=A0

As one person asked off-list, "How do we solve this for= my Father (a redneck luddite if you have ever met him)?"
Personally, I think we should not care about this group. =A0Th= ese=A0theoretical=A0"rednecks" won't run their own webfinger = servers, and we shouldn't care. =A0Most users will use a service provid= er for their webfinger, and anybody that has their own domain name and real= ly wants to be in charge of their own identity will be able to own their ro= ot and be able to serve dynamic content from it (and for LESS than "$5= /month"). =A0And if webfinger becomes successful enough for these tech= "luddites" (who already pay for their own domain name?) to want = WebFinger, the market will adapt: these static hosting providers can provid= e webfinger access for them, mapping to static files under the user's c= ontrol.

Opinions?

Regardless, can we lay out = the assumptions & goals in the spec, so people understand what webfinge= r aims to both solve and to NOT solve?




--
Joe Gregorio= =A0 =A0 =A0 =A0 http://bitworking.org=
--047d7b603c1ef8323104cf6c0102-- From ve7jtb@ve7jtb.com Mon Nov 26 12:52: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 7904D21F8546 for ; Mon, 26 Nov 2012 12:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.808 X-Spam-Level: X-Spam-Status: No, score=-2.808 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 BiBoV38LNtTC for ; Mon, 26 Nov 2012 12:52:02 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B821121F852A for ; Mon, 26 Nov 2012 12:52:02 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id m14so1778432yen.31 for ; Mon, 26 Nov 2012 12:52:02 -0800 (PST) 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=7qFwH1HPV/zy3f6HT/QEnI8XskRnONydZ00oNkAaWsA=; b=V0uRMNDGQL4bn2tGUE9K3xwbyLyFtilU5VvlATl44u01gVvQ9HQmFN9hhe3MTZ155A 5Q84IxjARSa7dgwLNd4hw4n7zkhV5z5Dnvve+2MtFYD57Ww0mFbwM0tM7Tfnzxs2TeQn GAU8dianl0QjjgyCvLtlGll/ZTUbsjS0+7rghEMmmlrG8h+X1HgzN0H9XLodtealOx6A prx6ZdGOkAwo0fdsYUtxhKRI/qT5QrMfOe8iwMlZoA7G+Dp7EZSNmkXlg8DYytnwzdCX 9T81wASqN+flg1C5gxPNp7VGk1Z9J6AfBM6Q7eiFF18OV1U7zHbYgKFpSdbseLY9gQMf kXWg== Received: by 10.236.93.16 with SMTP id k16mr13179949yhf.51.1353963122235; Mon, 26 Nov 2012 12:52:02 -0800 (PST) Received: from [192.168.1.211] (190-20-23-36.baf.movistar.cl. [190.20.23.36]) by mx.google.com with ESMTPS id n20sm14805819anl.19.2012.11.26.12.51.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 12:52:01 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5EB8C6D0-2C5D-4373-84D9-54C7F61B4D4C" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Mon, 26 Nov 2012 17:51:50 -0300 Message-Id: <29EF7945-2BA2-432E-962B-AEDBE8B295C4@ve7jtb.com> References: <50B2BC18.6030104@it.aoyama.ac.jp> To: James M Snell X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlJnNxTJaI//WJjXyaU16fgs7MLoCUunJ3avmVok3Iu80b/wMwxVucB3MNI2keQLqX7BkHZ Cc: Graham Klyne , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Does / Should the IETF support *browser-side* JavaScript as a programming platform? 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, 26 Nov 2012 20:52:03 -0000 --Apple-Mail=_5EB8C6D0-2C5D-4373-84D9-54C7F61B4D4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 That would largely kill the main use of WF to get information about = people in other domains. It is not an easy problem to solve. We looked at all sorts of DNS based = solutions in openID Connect but none of them were practical. John B. On 2012-11-26, at 5:41 PM, James M Snell wrote: > This case definitely points to why raw sockets or an "unmanaged" dns = client mechanism for javascript would definitely not be desirable. To = mitigate this case, a "name query" api could be limited to allow only = queries for the current domain and it's subdomains. That is, if I'm = loading a page from "example.org", then doing a name query for = "_webfinger._tcp.example.org." would be acceptable but = "_webfinger._tcp.example.com" would not.=20 >=20 > - James >=20 >=20 > On Mon, Nov 26, 2012 at 12:30 PM, Joe Hildebrand (jhildebr) = wrote: > On 11/25/12 5:47 PM, ""Martin J. D=FCrst"" = wrote: >=20 > >Employee A at company B visits web site C over lunch. Web site C > >includes (or points to) JavaScript that scans company B's DNS system = to > >figure out its structure and detect potential weak points. This > >information is sent back to C without A noticing. As a result, > >information about B (e.g. internal structure, new but as of yet = secret > >products,...) and its network infrastructure may leak to C. >=20 > Sorry, I replied without having read this whole thread (since the = subject > changed). My example is effectively the same as Martin's. >=20 > -- > Joe Hildebrand >=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=_5EB8C6D0-2C5D-4373-84D9-54C7F61B4D4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 That = would largely kill the main use of WF to get information about people in = other domains.

It is not an easy problem to solve. =  We looked at all sorts of DNS based solutions in openID Connect = but none of them were practical.

John = B.
On 2012-11-26, at 5:41 PM, James M Snell <jasnell@gmail.com> = wrote:

This case definitely = points to why raw sockets or an "unmanaged" dns client mechanism for = javascript would definitely not be desirable. To mitigate this case, a = "name query" api could be limited to allow only queries for the current = domain and it's subdomains. That is, if I'm loading a page from "example.org", then doing a name query = for "_webfinger._tcp.example.org."= would be acceptable but "_webfinger._tcp.example.com" would = not. 

- James


On Mon, Nov 26, = 2012 at 12:30 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
On = 11/25/12 5:47 PM, ""Martin J. D=FCrst"" <duerst@it.aoyama.ac.jp> = wrote:

>Employee A at company B visits web site C over lunch. Web site C
>includes (or points to) JavaScript that scans company B's DNS system = to
>figure out its structure and detect potential weak points. This
>information is sent back to C without A noticing. As a result,
>information about B (e.g. internal structure, new but as of yet = secret
>products,...) and its network infrastructure may leak to C.

Sorry, I replied without having read this whole thread (since the = subject
changed).  My example is effectively the same as Martin's.

--
Joe Hildebrand



_______________________________________________
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=_5EB8C6D0-2C5D-4373-84D9-54C7F61B4D4C-- From salvatore.loreto@ericsson.com Mon Nov 26 12:55: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 6630621F8704 for ; Mon, 26 Nov 2012 12:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 C-VXMibWvfi2 for ; Mon, 26 Nov 2012 12:55:21 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7A54B21F85DD for ; Mon, 26 Nov 2012 12:55:19 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-cc-50b3d736537d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 96.99.06323.637D3B05; Mon, 26 Nov 2012 21:55:18 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 26 Nov 2012 21:55:18 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4DD94236D; Mon, 26 Nov 2012 22:55:18 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 428B753BFA; Mon, 26 Nov 2012 22:55:17 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AD21B53BF7; Mon, 26 Nov 2012 22:55:16 +0200 (EET) Message-ID: <50B3D735.1060109@ericsson.com> Date: Mon, 26 Nov 2012 21:55:17 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , draft-ietf-ppsp-problem-statement@tools.ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvja7Z9c0BBpsbTSxWv1zBZnHl0gkW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvj1L8m9oITrBW7t21laWC8wNLFyMkhIWAi 8X/PZkYIW0ziwr31bF2MXBxCAicZJY5fbGeGcDYwSlxc/IMJwtnFKHGm/xEzSIuQwFpGif6j rhCJbYwSy5rWsIEkeAW0JU5uPgZWxCKgKtH1shVsB5uAmcTzh1vA4qICsRJbL12GqheUODnz CdhNIgIZEn/OQNwnLGAv0fVoPlg9s4CtxIU511kgbHmJ7W/nMEPcrSZx9dwmqIO0JHrPdjJN YBSahWTsLCTts5C0L2BkXsXInpuYmZNebr6JERiwB7f8NtjBuOm+2CFGaQ4WJXFePdX9/kIC 6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYMz2L8lQK0hd9vb7pRrP5zcY/Tzm9v3W/Wiq9JbV/ 4ee4V1ILwvcxXLauvrn2BEPa3ngP6+O89hsWt97cXc8Qw7Rp/v5Zfx4v2fbQtlcg8pxsz9vz vuv3Hu73FeKMdJK1PLBrucJ0ptkijyotyo+YigRlttTckLr8a6bBwdgeC/V9DZYPJ3nYKLEU ZyQaajEXFScCAE0X9G0mAgAA Subject: [apps-discuss] APPSDIR review of draft-ietf-ppsp-problem-statement-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: Mon, 26 Nov 2012 20:55:21 -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 comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ppsp-problem-statement-11 Title: Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP) Reviewer: Salvatore Loreto Review Date: 26 November 2012 Summary: The document is ready for publication as a Proposed Standard. Major Issues: none Minor Issues/Nits: none From hallam@gmail.com Mon Nov 26 13:08: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 1A36821F8588 for ; Mon, 26 Nov 2012 13:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=0.650, 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 mQffGS32NuNJ for ; Mon, 26 Nov 2012 13:08:58 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1D0321F84F2 for ; Mon, 26 Nov 2012 13:08:57 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so12700076oag.31 for ; Mon, 26 Nov 2012 13:08:57 -0800 (PST) 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=SeOSUESbhDdK7ZvapjiorLpcH61X1h28h0WY7+Mc2+Q=; b=rMjdeU7of1xIzy9GlxIJ/xfAMEDRHWpP3kPjkRz2PahCTY3zu4dgoZ1RMLU1SiuWEa M+PppOINeGCS08HJPiqCTpmmbgsUdI07eSPlTG4W7XsIZoO7W2PN7kasDjbyWuNTR+bS t5TzWIsRyD7HUJhU212+MwjHqHTXoBdhBxjJqK/xJEloYlqnJGrevr4IYjBY2K67HIXa 7HgTCZTknBZlE4wBteLDeTmJS4j2ZCKGBN2/Y8g7sV8C3ABb5ZfRZhlbY/aTdfAH0UoH 7KvT6idPzP2E3TkRmGEmcr2hkvGV2nlGNOGh6WaZEzNn15COvNbzgptc1yJp1wejiel6 YghQ== MIME-Version: 1.0 Received: by 10.60.26.38 with SMTP id i6mr10259455oeg.23.1353964137339; Mon, 26 Nov 2012 13:08:57 -0800 (PST) Received: by 10.76.19.43 with HTTP; Mon, 26 Nov 2012 13:08:56 -0800 (PST) In-Reply-To: <29EF7945-2BA2-432E-962B-AEDBE8B295C4@ve7jtb.com> References: <50B2BC18.6030104@it.aoyama.ac.jp> <29EF7945-2BA2-432E-962B-AEDBE8B295C4@ve7jtb.com> Date: Mon, 26 Nov 2012 16:08:56 -0500 Message-ID: From: Phillip Hallam-Baker To: John Bradley Content-Type: multipart/alternative; boundary=e89a8fb2007c71dddc04cf6c5759 Cc: Graham Klyne , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Does / Should the IETF support *browser-side* JavaScript as a programming platform? 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, 26 Nov 2012 21:08:59 -0000 --e89a8fb2007c71dddc04cf6c5759 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well maybe a scheme such as WebFinger is just not suitable as an application that downloads from a Web Page and then just runs without any user intervention. I don't see any particular problem with JScript using SRV rather than A records to bind TCP sockets. I do see a big problem with JScript being able to make a query to what is likely to be a private service on the user's behalf No, the fact that some people think of Web Finger as being strictly public information does not mean that the information about myself that I am willing to reveal to Alice is the same as the information I am willing to reveal to Bob. For example, I might be looking to have an affair with Alice and so I have included my private Skype account so that she can call me. This is information that I do not want her husband (Bob) to know for obvious reasons. Even if you decide to dumb down Web finger so that it is only delivering public data you cannot expect us to dumb down the rest of the Web to match. The fundamental problem here is that Web Finger is precisely the type of capability that makes JScript a very very bad idea. On Mon, Nov 26, 2012 at 3:51 PM, John Bradley wrote: > That would largely kill the main use of WF to get information about peopl= e > in other domains. > > It is not an easy problem to solve. We looked at all sorts of DNS based > solutions in openID Connect but none of them were practical. > > John B. > > On 2012-11-26, at 5:41 PM, James M Snell wrote: > > This case definitely points to why raw sockets or an "unmanaged" dns > client mechanism for javascript would definitely not be desirable. To > mitigate this case, a "name query" api could be limited to allow only > queries for the current domain and it's subdomains. That is, if I'm loadi= ng > a page from "example.org", then doing a name query for "_webfinger._ > tcp.example.org." would be acceptable but "_webfinger._tcp.example.com" > would not. > > - James > > > On Mon, Nov 26, 2012 at 12:30 PM, Joe Hildebrand (jhildebr) < > jhildebr@cisco.com> wrote: > >> On 11/25/12 5:47 PM, ""Martin J. D=FCrst"" wrot= e: >> >> >Employee A at company B visits web site C over lunch. Web site C >> >includes (or points to) JavaScript that scans company B's DNS system to >> >figure out its structure and detect potential weak points. This >> >information is sent back to C without A noticing. As a result, >> >information about B (e.g. internal structure, new but as of yet secret >> >products,...) and its network infrastructure may leak to C. >> >> Sorry, I replied without having read this whole thread (since the subjec= t >> changed). My example is effectively the same as Martin's. >> >> -- >> Joe Hildebrand >> >> >> >> _______________________________________________ >> 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 Website: http://hallambaker.com/ --e89a8fb2007c71dddc04cf6c5759 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well maybe a scheme such as WebFinger is just not suitable as an applicatio= n that downloads from a Web Page and then just runs without any user interv= ention.=A0

I don't see any particular problem with J= Script using SRV rather than A records to bind TCP sockets.=A0

I do see a big problem with JScript being able to make = a query to what is likely to be a private service on the user's behalf= =A0


No, the fact that some people t= hink of Web Finger as being strictly public information does not mean that = the information about myself that I am willing to reveal to Alice is the sa= me as the information I am willing to reveal to Bob.=A0

For example, I might be looking to have an affair with = Alice and so I have included my private Skype account so that she can call = me. This is information that I do not want her husband (Bob) to know for ob= vious reasons.

Even if you decide to dumb down Web finger so that it i= s =A0only delivering public data you cannot expect us to dumb down the rest= of the Web to match.=A0


The fundam= ental problem here is that Web Finger is precisely the type of capability t= hat makes JScript a very very bad idea.


On Mon, Nov 26, 2012 at 3:51 PM, Jo= hn Bradley <ve7jtb@ve7jtb.com> wrote:
That would largely kill the main use of= WF to get information about people in other domains.

It= is not an easy problem to solve. =A0We looked at all sorts of DNS based so= lutions in openID Connect but none of them were practical.

John B.

On 2012-11-26, at 5:41 P= M, James M Snell <jasnell@gmail.com> wrote:

This case definitely points to why ra= w sockets or an "unmanaged" dns client mechanism for javascript w= ould definitely not be desirable. To mitigate this case, a "name query= " api could be limited to allow only queries for the current domain an= d it's subdomains. That is, if I'm loading a page from "example.org", then doi= ng a name query for "_webfinger._tcp.example.org." would be acceptable but "_= webfinger._tcp.exampl= e.com" would not.=A0

- James

<= br>
On Mon, Nov 26, 2012 at 12:30 PM, Joe Hildebr= and (jhildebr) <jhildebr@cisco.com> wrote:
On 11/25/12 5:47 PM, ""Martin= J. D=FCrst"" <duerst@it.aoyama.ac.jp> wrote:

>Employee A at company B visits web site C over lunch. Web site C
>includes (or points to) JavaScript that scans company B's DNS syste= m to
>figure out its structure and detect potential weak points. This
>information is sent back to C without A noticing. As a result,
>information about B (e.g. internal structure, new but as of yet secret<= br> >products,...) and its network infrastructure may leak to C.

Sorry, I replied without having read this whole thread (since the sub= ject
changed). =A0My example is effectively the same as Martin's.

--
Joe Hildebrand



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

_______________________________________________
apps-discuss mailing lis= t
apps-discus= s@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /a>


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




--
Website:= http://hallambaker.c= om/

--e89a8fb2007c71dddc04cf6c5759-- From romeda@gmail.com Mon Nov 26 13:31: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 1624321F84FE for ; Mon, 26 Nov 2012 13:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 e3P1jUy5LA2B for ; Mon, 26 Nov 2012 13:31:32 -0800 (PST) Received: from mail-vb0-f64.google.com (mail-vb0-f64.google.com [209.85.212.64]) by ietfa.amsl.com (Postfix) with ESMTP id ED9EA21F8768 for ; Mon, 26 Nov 2012 13:31:31 -0800 (PST) Received: by mail-vb0-f64.google.com with SMTP id fq11so5203599vbb.19 for ; Mon, 26 Nov 2012 13:31:31 -0800 (PST) Received: by 10.49.18.231 with SMTP id z7mr2685306qed.25.1353965491243; Mon, 26 Nov 2012 13:31:31 -0800 (PST) X-Google-Doc-Id: 9a9b5d44724bb3bf X-Google-Web-Client: true Date: Mon, 26 Nov 2012 13:31:30 -0800 (PST) From: Blaine Cook To: webfinger@googlegroups.com Message-Id: <78d9b278-883d-4646-96c3-2e04ade48582@googlegroups.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_792_32639959.1353965490814" X-Google-Token: ELK_z4UFhYMb6Z9PRSQ0 X-Google-IP: 81.147.30.160 Cc: Tim Bray , apps-discuss@ietf.org Subject: Re: [apps-discuss] webfinger goals & whether we care about $5/month hosting 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, 26 Nov 2012 21:31:33 -0000 ------=_Part_792_32639959.1353965490814 Content-Type: multipart/alternative; boundary="----=_Part_793_31937357.1353965490814" ------=_Part_793_31937357.1353965490814 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Agreed, re: goals. There are a lot of self-hosted domains out there. I'd suspect that a lot of corporate domains are just haphazardly managed by someone more-or-less competent. For personal domains, there will be a bunch at wordpress.com (or on some provider but effectively managed by wordpress), and others all over the place. My goals for webfinger are as follows: 1. That it be easy to have any given domain to support webfinger. 2. That delegating service (and revoking that delegation) for a given domain is possible, as this will be (by far) the most common deployment mode. 3. That updates to profile information be available immediately, or as near-to-immediate as possible. 4. That it be easy to write client software for webfinger. Ideally, this means that a bespoke webfinger lookup is doable as a few lines of JS/Python/PHP/Ruby/Java without using a library, but that a more full-featured client library isn't more than a few hundred lines. b. On Monday, November 26, 2012 7:56:43 PM UTC, Brad Fitzpatrick wrote: > > One of the reasons WebFinger development has moved so slowly (while > proprietary silos continue to grow) is that we as a community have no > focus, no deadlines, no decision makers, and no clear goals even. > > After seeing conflicting opinions both on lists and off-list, I'd like to > discuss one goal (or non-goal) here: > > Does WebFinger care about people on "$5/month" static domain hosting plans? > > As one person asked off-list, "How do we solve this for my Father (a > redneck luddite if you have ever met him)?" > > Personally, I think we should not care about this group. > These theoretical "rednecks" won't run their own webfinger servers, and we > shouldn't care. Most users will use a service provider for their > webfinger, and anybody that has their own domain name and really wants to > be in charge of their own identity will be able to own their root and be > able to serve dynamic content from it (and for LESS than "$5/month"). And > if webfinger becomes successful enough for these tech "luddites" (who > already pay for their own domain name?) to want WebFinger, the market will > adapt: these static hosting providers can provide webfinger access for > them, mapping to static files under the user's control. > > Opinions? > > Regardless, can we lay out the assumptions & goals in the spec, so people > understand what webfinger aims to both solve and to NOT solve? > > ------=_Part_793_31937357.1353965490814 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Agreed, re: goals.

There are a lot of self-hosted domain= s out there. I'd suspect that a lot of corporate domains are just haphazard= ly managed by someone more-or-less competent. For personal domains, there w= ill be a bunch at wordpress.com (or on some provider but effectively manage= d by wordpress), and others all over the place.

My= goals for webfinger are as follows:

1. That it be= easy to have any given domain to support webfinger.
2. That dele= gating service (and revoking that delegation) for a given domain = is possible, as this will be (by far) the most common deployment mode.
3. That updates to profile information be available immediately, or a= s near-to-immediate as possible.
4. That it be easy to write clie= nt software for webfinger. Ideally, this means that a bespoke webfinger loo= kup is doable as a few lines of JS/Python/PHP/Ruby/Java without using a lib= rary, but that a more full-featured client library isn't more than a few hu= ndred lines.

b.

On Monday, November = 26, 2012 7:56:43 PM UTC, Brad Fitzpatrick wrote:
One of the reasons WebFinger development has moved so slowly (w= hile proprietary silos continue to grow) is that we as a community have no = focus, no deadlines, no decision makers, and no clear goals even.

After seeing conflicting opinions both on lists and off-list= , I'd like to discuss one goal (or non-goal) here:

Does WebFinger care about people on "$5/month" static domain hosting = plans?

As one person asked off-list, "How do we solve this for my F= ather (a redneck luddite if you have ever met him)?"

Personally, I think we should not care about this group.  These&nbs= p;theoretical "rednecks" won't run their own webfinger servers, and we= shouldn't care.  Most users will use a service provider for their web= finger, and anybody that has their own domain name and really wants to be i= n charge of their own identity will be able to own their root and be able t= o serve dynamic content from it (and for LESS than "$5/month").  And i= f webfinger becomes successful enough for these tech "luddites" (who alread= y pay for their own domain name?) to want WebFinger, the market will adapt:= these static hosting providers can provide webfinger access for them, mapp= ing to static files under the user's control.

Opinions?

Regardless, can we lay out = the assumptions & goals in the spec, so people understand what webfinge= r aims to both solve and to NOT solve?

------=_Part_793_31937357.1353965490814-- ------=_Part_792_32639959.1353965490814-- From GK@ninebynine.org Mon Nov 26 14:48: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 8D7AF21F8548; Mon, 26 Nov 2012 14:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 EegiHdPCYsML; Mon, 26 Nov 2012 14:48:39 -0800 (PST) Received: from relay1.mail.ox.ac.uk (relay1.mail.ox.ac.uk [129.67.1.165]) by ietfa.amsl.com (Postfix) with ESMTP id 729C521F8542; Mon, 26 Nov 2012 14:48:39 -0800 (PST) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay1.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1Td7Tf-00049F-5E; Mon, 26 Nov 2012 22:48:35 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Td7Tf-0005Ko-0d; Mon, 26 Nov 2012 22:48:35 +0000 Message-ID: <50B3F104.6010305@ninebynine.org> Date: Mon, 26 Nov 2012 22:45:24 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <50B3D146.3080506@stpeter.im> In-Reply-To: <50B3D146.3080506@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Julian Reschke , "uri-review@ietf.org" , "xmpp@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 26 Nov 2012 22:48:40 -0000 On 26/11/2012 20:29, Peter Saint-Andre wrote: > Agreed. We would register it immediately as historical. Is this strictly true? After all, doesn't XMPP still require use of jabber:client or jabber:server as namespaces for stanzas in XMPP streams? My original email cited an out-of-date RFC, but I did check back later: [[ Definition of XML Stanza: An XML stanza is the basic unit of meaning in XMPP. A stanza is a first-level element (at depth=1 of the stream) whose element name is "message", "presence", or "iq" and whose qualifying namespace is 'jabber:client' or 'jabber:server'. ]] -- http://tools.ietf.org/html/rfc6120#section-4.1 In light of this, my take is that jabber: is a current but very limited URI scheme, defining just two URIs (jabber:server and jabber:client) for use in XMPP streams. No other URIs or uses for this scheme are sanctioned. #g -- > http://tools.ietf.org/html/rfc4395#section-4 > > On 11/26/12 1:27 PM, Joe Hildebrand (jhildebr) wrote: >> Looping the XMPP wg list. If we register it, let's make sure that >> registration says "DO NOT USE IN THE FUTURE". >> >> On 11/26/12 11:50 AM, "Peter Saint-Andre" wrote: >> >>> On 11/26/12 9:37 AM, Julian Reschke wrote: >>>> On 2012-11-26 16:28, Peter Saint-Andre wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> On 11/25/12 5:04 AM, Graham Klyne wrote: >>>>>> I've just been digging around the XMPP specs, and I notive they >>>>>> make reference to required namespaces of the form "jabber:client" >>>>>> and "jabber:server" (cf. >>>>>> http://tools.ietf.org/html/rfc3920#section-11.2, esp sect 11.2.2). >>>>>> >>>>>> Examples in sections 8 and 9 of that spec reinforce the indication >>>>>> that jabber: is being used as a URI scheme (rather than a namespace >>>>>> prefix). >>>>> >>>>> The 'jabber:' string was used in the earliest days of the jabberd >>>>> server project when the core developers didn't really understand XML >>>>> namespaces (which were quite new at the time). It is not a URI scheme, >>>>> just a mistake. :) >>>>> >>>>>> But looking at http://www.iana.org/assignments/uri-schemes.html I'm >>>>>> not seeing any mention of jabber:. >>>>>> >>>>>> Assuming I'm reading this right... it's probably unfortunate that >>>>>> that this use of jabber: has come about (like dav: before it?) but >>>>>> I guess it's now entrenched and should at least be registered? >>>>> >>>>> I have never registered it and I hesitate to do so now because I think >>>>> it would cause more confusion than it's worth. We do have the 'xmpp:' >>>>> URI scheme for pointing to JabberIDs. >>>>> ... >>>> >>>> I think it would still be good to have it in the registry, and have the >>>> documentation explain what's going on. >>>> >>>> I believe the "DAV:" scheme was created for the same purpose, and we >>>> have documented that in >>>> . >>> >>> Thanks for the pointer. And yes, as with "DAV:", the "jabber:" prefix >>> was defined before standard best practices emerged for XML namespaces... >>> >>> Peter >>> >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss > From stpeter@stpeter.im Mon Nov 26 14:56: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 87D2221F8447; Mon, 26 Nov 2012 14:56:39 -0800 (PST) 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_66=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 uXlxVDYq7OXg; Mon, 26 Nov 2012 14:56:38 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 867EB21F878A; Mon, 26 Nov 2012 14:56:38 -0800 (PST) Received: from [10.129.24.67] (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A0C4340092; Mon, 26 Nov 2012 16:01:28 -0700 (MST) Message-ID: <50B3F3A4.2060002@stpeter.im> Date: Mon, 26 Nov 2012 15:56:36 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Graham Klyne References: <50B3D146.3080506@stpeter.im> <50B3F104.6010305@ninebynine.org> In-Reply-To: <50B3F104.6010305@ninebynine.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "uri-review@ietf.org" , "xmpp@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 26 Nov 2012 22:56:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/26/12 3:45 PM, Graham Klyne wrote: > On 26/11/2012 20:29, Peter Saint-Andre wrote: >> Agreed. We would register it immediately as historical. > > Is this strictly true? After all, doesn't XMPP still require use > of jabber:client or jabber:server as namespaces for stanzas in XMPP > streams? RFC 4395 says: In some circumstances, it is appropriate to note a URI scheme that was once in use or registered but for whatever reason is no longer in common use or the use is not recommended. I definitely think that 'jabber:' is not recommended. Various XML namespaces with the 'jabber:' "scheme" are still in wide use, but we have not minted any such namespaces since 1999 or 2000. > My original email cited an out-of-date RFC, but I did check back > later: [[ Definition of XML Stanza: An XML stanza is the basic > unit of meaning in XMPP. A stanza is a first-level element (at > depth=1 of the stream) whose element name is "message", "presence", > or "iq" and whose qualifying namespace is 'jabber:client' or > 'jabber:server'. ]] -- > http://tools.ietf.org/html/rfc6120#section-4.1 > > In light of this, my take is that jabber: is a current but very > limited URI scheme, defining just two URIs (jabber:server and > jabber:client) for use in XMPP streams. No other URIs or uses for > this scheme are sanctioned. Actually there are more namespaces than just those two (we minted about twenty of them in the early days of XMPP before we realized the error of our ways). A full list can be found at http://xmpp.org/registrar/namespaces.html -- but we haven't minted any new ones in a long time and we're not about to start doing so again. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCz86QACgkQNL8k5A2w/vw3MQCg6UjFltp87J9ZfDbVD6/++S4i yqEAoKbjXUHPvAvVatJh8B9p4n1VB4lW =Imzk -----END PGP SIGNATURE----- From gsalguei@cisco.com Mon Nov 26 15:30: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 66F4921F84DC for ; Mon, 26 Nov 2012 15:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, 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 LpK1IhD4ejRj for ; Mon, 26 Nov 2012 15:30:00 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 3A75821F8475 for ; Mon, 26 Nov 2012 15:30:00 -0800 (PST) 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 qAQNTxTf018371 for ; Mon, 26 Nov 2012 18:29:59 -0500 (EST) Received: from dhcp-10-150-54-57.cisco.com (dhcp-10-150-54-57.cisco.com [10.150.54.57]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAQNTxLT006547; Mon, 26 Nov 2012 18:29:59 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: Date: Mon, 26 Nov 2012 18:29:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <371E2D51-0282-4655-8796-8B7318CC7C38@cisco.com> References: To: Larry Masinter X-Mailer: Apple Mail (2.1283) Cc: draft-salgueiro-vcarddav-kind-device.all@tools.ietf.org, Pete Resnick , General discussion of application-layer protocols Subject: Re: [apps-discuss] APPSDIR review of draft-salgueiro-vcarddav-kind-device-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: Mon, 26 Nov 2012 23:30:01 -0000 Larry -=20 Thanks for the detailed review. We have posted a new version of the = document addressing these nits and the diffs can be found here: http://www.ietf.org/rfcdiff?url2=3Ddraft-salgueiro-vcarddav-kind-device-04= Some comments inline... On Nov 24, 2012, at 10:12 AM, Larry Masinter wrote: > (resend) > 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 = ). >=20 > Please resolve these comments along with any other comments you may = receive. Please wait for direction from your document shepherd or AD = before posting a new version of the draft. >=20 > Document: draft-salgueiro-vcarddav-kind-device-03 > Title: vCard KIND:device > Reviewer: Larry Masinter=20 > Review Date: 24 Nov 2012=20 > Summary: The document is almost ready for publication as a Proposed = Standard. Some clarification and design rationale would be quite = helpful. >=20 > Major Issues: none > Minor Issues/Nits: =20 >=20 > I had trouble between "Minor issues" or "Nits" for many of these, so I = put them together. I don't feel strongly about any of them, if the = authors are confident that anyone steeped in vCard and LDAP wouldn't = have the same issues. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > 1. use cases (definitely NIT) >> use cases for device vCards have emerged > Are these documented somewhere else? A few more examples would be = helpful.=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D While this is more of a high-level registration draft and others will = follow detailing specific use cases, we did add some clarifying text = related to the motivating use-cases for this registration. >=20 > 2. LDAP / X.521 alignment, nature of devices (NIT) >=20 >> In this context, the concept of a device is constrained to computing >> devices and thus is distinct from purely mechanical devices such as >> elevators, electric generators, etc. that cannot communicate in any >> way over a network. >=20 > Why not allow mechanical devices such as elevators, electric = generators, or gas and electric meters? This was a line in the sand that came out of discussions on the mailing = list around intended scope. We have tried to be clear here about what is = in and what is out-of-scope. We did add a bit of text refining the = scope based on your comment. > Wouldn't compatibility with LDAP be useful? We're using the LDAP definition of 'device' as a base and refining that = based on mailing list conversations. For example, we're including = virtual devices but omitting mechanical devices that are not naturally = networked.=20 >=20 > Is there a need to distinguish between network elements (routers) and = appliances and light switches?=20 No, not in this context. We want to keep KIND:device generic such that = we don't distinguish between a router vCard and a network sensor or a = light switch.=20 > Between physical objects and virtual objects that do not have a = distinct physical location? Again, both are valid and we don't want to distinguish between the two.=20= >=20 >> Although it might be desirable to define a more fine-grained = taxonomy >> of devices (e.g., a KIND of "device" with a subtype of "router" or=20= >> "computer"), such a taxonomy is out of scope for this document >=20 > "out of scope" is a convenient but frustrating label for "we decided = not to do it". As a spec author/editor it's great; for a reader it = isn't so great. Some more elaboration "There were no compelling use = cases for such a distinction, and advantages to not making distinctions = where some use cases straddled the categories." (if that's a reason) = might be more satisfactory. I absolutely get your point but the intent here was simply to properly = position this document as purely a simple registration document = (paralleling RFC 6473) and not one that dives into detail on specific = use-cases. As I mentioned, other documents expounding on specific use = cases and their related taxonomy are sure to follow (though I obviously = don't want to make reference to such potential outcomes). >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 3. Devices "containing" vCards, normative language around it (MINOR) >=20 > " A device MAY contain..." > The "contain" relationship is unspecified. How are these vCards = discovered and accessed in a "device"? I can see saying that a device = "has" one or more vCards and being explicit that discovery and access = are unspecified? If a 2D barcode is affixed to the device and used to = retrieve the vCards associated with it, is that in scope? =20 > My concern is over the normative language "MAY" for a relationship = that is unspecified. >=20 >=20 >> When a device contains vCards other than its KIND:device vCard, those >> vCards MUST be linked together with RELATED (see the definition of >> the RELATED organizational property in Section 6.6.6 of [RFC6350]). >=20 > Since 'contain' is unspecified, the scope of this advice (and thus the = MUST requirement) is unclear. Even if you define "contain", isn't this a = SHOULD? I see your point. Text was amended to reflect address this feedback. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > 4. Use of RELATED for devices (NIT) >=20 > The values for RELATED in RFC 6350=20 >=20 > "contact" / "acquaintance" / "friend" / "met" > / "co-worker" / "colleague" / "co-resident" > / "neighbor" / "child" / "parent" > / "sibling" / "spouse" / "kin" / "muse" > / "crush" / "date" / "sweetheart" / "me" > / "agent" / "emergency" >=20 > don't seem to match device relationships (robot love?). Perhaps some = more examples of RELATED use or advice here would help? The example included in this draft uses a value of "contact" and other = values such as parent, child, etc. could be used as well. My preference = is to not go down the rat hole of providing guidance on the usage of = RELATED within this registration draft. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > 5. Example unexplained (MINOR) >=20 > Section 4, the Example is not explained! Lots of the example is = mysterious to me. Please annotate the example with a description of what = it means and why. Text was updated to address this. Cheers, Gonzalo >=20 >=20 From evan@status.net Mon Nov 26 17:12: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 CBFDC21F861D for ; Mon, 26 Nov 2012 17:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 rmEs8XNXid5y for ; Mon, 26 Nov 2012 17:12:36 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id BCAD521F8616 for ; Mon, 26 Nov 2012 17:12:32 -0800 (PST) Received: from [192.168.0.109] (modemcable218.194-202-24.mc.videotron.ca [24.202.194.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 5ECBE8D4240 for ; Tue, 27 Nov 2012 01:24:38 +0000 (UTC) Message-ID: <50B41376.4090709@status.net> Date: Mon, 26 Nov 2012 20:12:22 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080809020602090808060004" Subject: Re: [apps-discuss] webfinger goals & whether we care about $5/month hosting 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, 27 Nov 2012 01:12:37 -0000 This is a cryptographically signed message in MIME format. --------------ms080809020602090808060004 Content-Type: multipart/alternative; boundary="------------050800030803050005010205" This is a multi-part message in MIME format. --------------050800030803050005010205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable So, I'm trying to get a handle on this situation. Here's what I'm hearing= : * some organizations delegate the Web hosting of their domain to a SaaS provider. * Those organizations may want to implement Webfinger for e.g. OpenID Connect. * Their Web hosting provider may not allow mapping the /.well-known/webfinger endpoint to some other processor or even a redirect. * The organization may still have control of the domain and may be able to map the "webfinger" hostname to another Web server (or another SaaS provider). It's an interesting case, but... there are a lot of "mights" and=20 "maybes" in this. As a client developer, I don't want to look in 4 places for the=20 Webfinger document: * https://domain.example/.well-known/webfinger * http://domain.example/.well-known/webfinger * https://webfinger.domain.example/.well-known/webfinger * http://webfinger.domain.example/.well-known/webfinger =2E..and then fall back to RFC 6415 if none of these work: * https://domain.example/.well-known/host-meta * http://domain.example/.well-known/host-meta * https://domain.example/.well-known/host-meta.json * http://domain.example/.well-known/host-meta.json Which is another 2-5 requests (since we have to get the linked LRDD=20 document on a successful hit), for a total of 4-8 requests for=20 non-implementing domains -- by far, right now, our mainline case. I think it makes sense to worry about people who want to implement, but=20 can't, once we actually have a widespread network of implementers. Until = then, I believe the YAGNI=20 principle applie= s. -Evan --------------050800030803050005010205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So, I'm trying to get a handle on this= situation. Here's what I'm hearing:
  • some organizations delegate the Web hosting of their domain to a SaaS provider.
  • Those organizations may want to implement Webfinger for e.g. OpenID Connect.
  • Their Web hosting provider may not allow mapping the /.well-known/webfinger endpoint to some other processor or even a redirect.
  • The organization may still have control of the domain and may be able to map the "webfinger" hostname to another Web server (or another SaaS provider).
It's an interesting case, but... there are a lot of "mights" and "maybes" in this.

As a client developer, I don't want to look in 4 places for the Webfinger document:
...and then fall back to RFC 6415 if none of these work:
Which is another 2-5 requests (since we have to get the linked LRDD document on a successful hit), for a total of 4-8 requests for non-implementing domains -- by far, right now, our mainline case.

I think it makes sense to worry about people who want to implement, but can't, once we actually have a widespread network of implementers. Until then, I believe the Y= AGNI principle applies.

-Evan
--------------050800030803050005010205-- --------------ms080809020602090808060004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQTCC BUswggQzoAMCAQICEEuui3coSgPxeBmm1kzS1rswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjExMjEwMDAwMDBaFw0xMzExMjEyMzU5NTlaMIIBDjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FdmFuIFByb2Ry b21vdTEcMBoGCSqGSIb3DQEJARYNZXZhbkBlMTRuLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAORmFCsNPJqt5UyhR02QZdZdUxvxQcPqu4jsZ6OEHSN5B+fUGFp87FLq 4PJZwfIu1Cv4QItq4AmIvVJi8AbrbBBNN45jzZvPNFCA7lvihd47aviNpfOdm0mx3YYfH+aU 4W5oXdSrCaIqWwAjxUnYWaJljCXi7kd9t4zL9mnl+W+IKw3L5sT2CWZpapAmCI+xO41PhLEJ hyBWrQKgSwjINgJgoEVOhVien2v5pe3FxWGDRuS3UWiRHFPg+ZjmQIvmR6KJ5l3esRl7y1L2 QbNGlSC92LAW1MXDSo5T0WCypZs93NFBvcfsOcdWVBS+1p1gycpGtkDio5Itgqv2IzBA8c0C AwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9p bmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAPaHFMHt2vp6k7gmYqDdvn1upM2aJ2sVX4ybGJME97Hrg /axsoTmtY69LtfTNHqOJAbjXgaqABXp9f+p1JqzI5Nkaac2rWDx2BFGUdUuQKeIzyiAPJ0Ou wWNBThLS/tTUuipWx2V0jIJzPRP0gZuxBi6JQydnLsWEMZeup5jC8QhXCSPu1aaJ08SbdYCD xYSpHUoPkpOxm7A/Vx4xN24edU0TvmH+xvXPMo3NgPNs+Qsjt2Tugg2O6XngESdsE/X9+JMC aDRyDaC1oUe8TytFkOJvJ2AplXVwr5h3pI3IoDoq1EX86MZjf3QiloN2Qn0ELsIRcPkQZPeM +O2qklmEJTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4g LSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQ dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAw MDAwMFoXDTE5MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJ bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBf DUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY31 3DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGD P3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbE sq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOC ArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNp Z24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwIC MB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0 cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4E FgQUeUdhCEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0G CSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGT gc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw8 4J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFY m77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpI DmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoO f8GCMYIE+TCCBPUCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQS66LdyhKA/F4GabWTNLWuzAJBgUrDgMCGgUA oIIC2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMjcw MTEyMjJaMCMGCSqGSIb3DQEJBDEWBBR5wJaPdfQt5JpCS4TqlNuYrpaDEDBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzMCEEuui3coSgPxeBmm1kzS1rswggEFBgsqhkiG9w0BCRAC CzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBLrot3KEoD8XgZptZM0ta7MA0GCSqGSIb3DQEBAQUABIIBALHK 2QeKHaKWyxXCR2yMULWHV9TVuLPWhnxpg65Cxu74/EzCiONr5OREPd/M0MK1y1gieac+GRaR CpJUWBYlT+hC9T0Qd53AbisT7CQYCef3hxuv00M8YbaYgU+OXzx9IhjkLTCa4hRRPkt0o8no 2v86bqjjAGokHbD/ePzP6UvdLFNjC6XHA68oP4p0TeIAA3SIRpd+biM1cSvQaaw0COWLmm4U gZfBJ50zounMwrFn6oUfZMgLLxSDOD36T3hcl0LARH2OyN5WFrpIXLrcGCqrmDqouseRGDXt Zh7TODBMKOG6frP0PyJc08MIEoiyYqzYmDuCPmLdp2r2uMAh/GsAAAAAAAA= --------------ms080809020602090808060004-- From jasnell@gmail.com Mon Nov 26 17:20: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 2BF5221F8427 for ; Mon, 26 Nov 2012 17:20:28 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2K-XNllPnyt for ; Mon, 26 Nov 2012 17:20:26 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B5A4821F84D3 for ; Mon, 26 Nov 2012 17:20:26 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so10839409ieb.31 for ; Mon, 26 Nov 2012 17:20:26 -0800 (PST) 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=GfLRLkDROUgA2iefO7mEKa8+DiG0q6W26s0YBC0gfEc=; b=XLuLFkTy78GySk8mxuTV1/YzVOOmiPZSik+bzBOqlOEd3E1/wrtqDWSmyPn+EqfewQ 80RPyxYlfpCUCIKdvq+BG+ECg6lkE9d29nongkLxJ6wcOK5qCe2ls20KDf6OFtLPmMpt L6NnCAeozGrgRBNULRxSfye+M/lCeiSlGplG9OikRcoD6iYcMwNCG2PwedpGhiXNIdn1 SC1oLCrW4KiV0vw9Gt3gDzvsxO3ijbJ/XclTocQmmS9Ompo2rlvA4TgHd7qQ19331Rgw C2D/MDgmU61Juf2RCe34X3rZTIOalBvMStqiZEpiMYeEw30CVt14bXwibMUtM+N8CBZb epLA== Received: by 10.50.187.165 with SMTP id ft5mr16401834igc.12.1353979226253; Mon, 26 Nov 2012 17:20:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.225 with HTTP; Mon, 26 Nov 2012 17:20:05 -0800 (PST) In-Reply-To: <50B41376.4090709@status.net> References: <50B41376.4090709@status.net> From: James M Snell Date: Mon, 26 Nov 2012 17:20:05 -0800 Message-ID: To: Evan Prodromou Content-Type: multipart/alternative; boundary=14dae9341027d0689204cf6fda67 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] webfinger goals & whether we care about $5/month hosting 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, 27 Nov 2012 01:20:28 -0000 --14dae9341027d0689204cf6fda67 Content-Type: text/plain; charset=UTF-8 +1.. it's getting quite a bit complicated here overall... lots of what ifs, maybes, mights, etc and very little hard evidence one way or the other. Personally, I'm -1 on the subdomain notion. It just adds an unnecessary headache. - James --14dae9341027d0689204cf6fda67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1.. it's getting quite a bit comp= licated here overall... lots of what ifs, maybes, mights, etc and very litt= le hard evidence one way or the other. Personally, I'm -1 on the subdom= ain notion. It just adds an unnecessary headache.

- James
--14dae9341027d0689204cf6fda67-- From stpeter@stpeter.im Mon Nov 26 17:47: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 14D5621F8548 for ; Mon, 26 Nov 2012 17:47:21 -0800 (PST) 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 2MgCuekirDtc for ; Mon, 26 Nov 2012 17:47:20 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1690721F84DE for ; Mon, 26 Nov 2012 17:47:20 -0800 (PST) Received: from [192.168.1.4] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 13A2F40092; Mon, 26 Nov 2012 18:52:08 -0700 (MST) Message-ID: <50B41BA5.5090809@stpeter.im> Date: Mon, 26 Nov 2012 18:47:17 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: James M Snell References: <50B41376.4090709@status.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] webfinger goals & whether we care about $5/month hosting 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, 27 Nov 2012 01:47:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/26/12 6:20 PM, James M Snell wrote: > +1.. it's getting quite a bit complicated here overall... lots of > what ifs, maybes, mights, etc and very little hard evidence one way > or the other. Personally, I'm -1 on the subdomain notion. It just > adds an unnecessary headache. Agreed. Let's try to keep it simple (hey, this is just supposed to be finger for the web, right?). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC0G6UACgkQNL8k5A2w/vw1WwCfYHRtdv1Wjd0/n/89IoZR4G60 InMAn3Nisn+QaiYcYTvTnY61GqkWLvCK =IQt6 -----END PGP SIGNATURE----- From mnot@mnot.net Mon Nov 26 17:51: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 05D5721F84DD for ; Mon, 26 Nov 2012 17:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.577 X-Spam-Level: X-Spam-Status: No, score=-105.577 tagged_above=-999 required=5 tests=[AWL=-2.978, 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 0M1viIlNPTnF for ; Mon, 26 Nov 2012 17:51:14 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC3E21F842C for ; Mon, 26 Nov 2012 17:51:14 -0800 (PST) Received: from [192.168.1.75] (unknown [118.209.244.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 04F21509BA; Mon, 26 Nov 2012 20:51:12 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Tue, 27 Nov 2012 12:51:09 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20121115152250.09ffa450@elandnews.com> <7B79A6AC-B355-4828-9DBE-2AA99A0DC498@mnot.net> To: Henry S. Thompson X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Appsdir review of draft-ietf-appsawg-json-patch-06 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, 27 Nov 2012 01:51:16 -0000 Hi Henry, I think this is now clearer, thanks to the latest round of editing. It = currently says: > When the operation is applied, the target location MUST > reference one of: >=20 > [...] >=20 > A member to add to an existing object - whereupon = the > supplied value is added to that object at the = indicated > location. If the member already exists, it is = replaced > by the specified value. Cheers, On 19/11/2012, at 9:10 PM, Henry S. Thompson wrote: > Mark Nottingham writes: >=20 >> It does, but that isn't the intent, and I think many people would = find that result extremely surprising. >>=20 >> The result of ex 1 should be: >>=20 >> [ { "key": "apples", "status": "ripe", "count": 3 }, >> { "key": "apples", "status": "green", "count": 4 } ] >>=20 >> I.e., array references are zero-based, and members are replaced, not = repeated, when added to. >=20 > Sorry for the array-base error, which just confuses things, but the > 'add' text nowhere says that 'add' =3D=3D 'replace' for existing = members, > and surely that's not obvious, given that 'add' very definitely does > _not_ =3D=3D 'replace' for existing array members. . . >=20 > OTOH, I was just arguing for consistency, _not_ because I believe that > constructing documents with multiple same-name object member settings > was a good thing, so I'm happy if you clarify in 'add' that this does > _not_ happen, and then we're back to a clean state if 'move' and > 'copy' are defined in terms of 'add'. >=20 > ht > --=20 > Henry S. Thompson, School of Informatics, University of = Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 = 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is = forged spam] -- Mark Nottingham http://www.mnot.net/ From melvincarvalho@gmail.com Mon Nov 26 18:24: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 C818321F8641 for ; Mon, 26 Nov 2012 18:24:59 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCB--OPKnUU4 for ; Mon, 26 Nov 2012 18:24:59 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14E8521F862A for ; Mon, 26 Nov 2012 18:24:59 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so9360236iaf.31 for ; Mon, 26 Nov 2012 18:24:58 -0800 (PST) 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=h7SUOfUo6wRg5Mbak0MjyYMXMQIcr5CrmpSGysIVrlE=; b=RwuZoz9PmS3kFKGi8UN/fntKJc294t7MKaCoCPQEqnv4sKtu9N9MAX4c42DRnyfR/E lAL0udDtk3TOlyyKEn4iPKhohL6W60l8CLJZ+bYRy/Y3CyoJbdR79AI/Jloxaxd1Lo/o xhP42H00F4avZwqMOQ0wFwGCJoUcAUY/Qm6f1ozcXd7Tjaz/i7Bib1w2P2VhItb97fAo Ny7uf5KLRoRYTThmzVye8D3/xXF16ZGu7AtrYMtiqcwPCvsTOuZ4xh2ggdTR5/nVSpjm C91X2QjnIFO3nqoqVdc8BbLAZ5jOo20U8C59W0juqFJvJwO4KOBJAgpsUjtXp2InWAAB 2ldw== MIME-Version: 1.0 Received: by 10.50.108.145 with SMTP id hk17mr14109864igb.51.1353983098636; Mon, 26 Nov 2012 18:24:58 -0800 (PST) Received: by 10.42.61.203 with HTTP; Mon, 26 Nov 2012 18:24:57 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Nov 2012 03:24:57 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d0402a9f3a0495404cf70c1eb Cc: Tim Bray , apps-discuss@ietf.org Subject: Re: [apps-discuss] webfinger goals & whether we care about $5/month hosting 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, 27 Nov 2012 02:24:59 -0000 --f46d0402a9f3a0495404cf70c1eb Content-Type: text/plain; charset=ISO-8859-1 On 26 November 2012 20:56, Brad Fitzpatrick wrote: > One of the reasons WebFinger development has moved so slowly (while > proprietary silos continue to grow) is that we as a community have no > focus, no deadlines, no decision makers, and no clear goals even. > > After seeing conflicting opinions both on lists and off-list, I'd like to > discuss one goal (or non-goal) here: > > Does WebFinger care about people on "$5/month" static domain hosting plans? > > As one person asked off-list, "How do we solve this for my Father (a > redneck luddite if you have ever met him)?" > > Personally, I think we should not care about this group. > These theoretical "rednecks" won't run their own webfinger servers, and we > shouldn't care. Most users will use a service provider for their > webfinger, and anybody that has their own domain name and really wants to > be in charge of their own identity will be able to own their root and be > able to serve dynamic content from it (and for LESS than "$5/month"). And > if webfinger becomes successful enough for these tech "luddites" (who > already pay for their own domain name?) to want WebFinger, the market will > adapt: these static hosting providers can provide webfinger access for > them, mapping to static files under the user's control. > > Opinions? > Agree with this sentiment. The scope of webfinger has expanded since the original concept. However, I'm not sure that cutting out the 'host your own' webfinger, is the first thing to cut out. That may exclude projects such as freedombox from participating. There are other areas that can be cut, imho, and the ietf process has a good reputation in this area. > > Regardless, can we lay out the assumptions & goals in the spec, so people > understand what webfinger aims to both solve and to NOT solve? > > --f46d0402a9f3a0495404cf70c1eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 26 November 2012 20:56, Brad Fitzpatr= ick <bradfitz@google.com> wrote:
One of= the reasons WebFinger development has moved so slowly (while proprietary s= ilos continue to grow) is that we as a community have no focus, no deadline= s, no decision makers, and no clear goals even.

After seeing conflicting opinions both on lists and off-list= , I'd like to discuss one goal (or non-goal) here:

=
Does WebFinger care about people on "$5/month"=A0static doma= in hosting plans?

As one person asked off-list, "How do we solve this for= my Father (a redneck luddite if you have ever met him)?"
Personally, I think we should not care about this group. =A0Th= ese=A0theoretical=A0"rednecks" won't run their own webfinger = servers, and we shouldn't care. =A0Most users will use a service provid= er for their webfinger, and anybody that has their own domain name and real= ly wants to be in charge of their own identity will be able to own their ro= ot and be able to serve dynamic content from it (and for LESS than "$5= /month"). =A0And if webfinger becomes successful enough for these tech= "luddites" (who already pay for their own domain name?) to want = WebFinger, the market will adapt: these static hosting providers can provid= e webfinger access for them, mapping to static files under the user's c= ontrol.

Opinions?

Agree wi= th this sentiment.=A0 The scope of webfinger has expanded since the origina= l concept.

However, I'm not sure that cutting out the 'host = your own' webfinger, is the first thing to cut out.=A0 That may exclude= projects such as freedombox from participating.

There are other areas that can be cut, imho, and the ietf process has a= good reputation in this area.
=A0
<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:10pt">

Regardless, can we lay out the assumptions & goals = in the spec, so people understand what webfinger aims to both solve and to = NOT solve?


--f46d0402a9f3a0495404cf70c1eb-- From nico@cryptonector.com Mon Nov 26 18:26: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 2AA6E21F8665 for ; Mon, 26 Nov 2012 18:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 hwQHYOJINijK for ; Mon, 26 Nov 2012 18:26:13 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id A405621F8641 for ; Mon, 26 Nov 2012 18:26:13 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 5225E1F0085 for ; Mon, 26 Nov 2012 18:26:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=rLrtCHF8gbWQFimz9rK2 GS5czn0=; b=Lr7dFUtov1gpdbeYzMdX7KVuynv5p0UdFCpw48ARTnkS9hW4koDq EAAh3DUEaNtimOOGBoNRa8JyNdEUZgrj0fZDIXOy0n7DMIvpVpxuS90467GWbvZy S5jKuwSflk3C+BteJbhRQCmecpsHEJGE6sZX/0FnKBOnrimrDiEPoBo= Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 2AE6C1F0084 for ; Mon, 26 Nov 2012 18:26:13 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so2406873dae.31 for ; Mon, 26 Nov 2012 18:26:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.231.97 with SMTP id tf1mr43096066pbc.149.1353983172758; Mon, 26 Nov 2012 18:26:12 -0800 (PST) Received: by 10.68.128.234 with HTTP; Mon, 26 Nov 2012 18:26:12 -0800 (PST) In-Reply-To: References: <50B41376.4090709@status.net> Date: Mon, 26 Nov 2012 20:26:12 -0600 Message-ID: From: Nico Williams To: James M Snell Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] webfinger goals & whether we care about $5/month hosting 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, 27 Nov 2012 02:26:14 -0000 On Mon, Nov 26, 2012 at 7:20 PM, James M Snell wrote: > +1.. it's getting quite a bit complicated here overall... lots of what ifs, > maybes, mights, etc and very little hard evidence one way or the other. > Personally, I'm -1 on the subdomain notion. It just adds an unnecessary > headache. Agreed. I want one simple thing using service discovery (SRV RRs, say) and at most one simple fallback (say, subdomain), preferably no fallback. From mnot@mnot.net Mon Nov 26 18:29: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 DECC021F8698 for ; Mon, 26 Nov 2012 18:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.84 X-Spam-Level: X-Spam-Status: No, score=-103.84 tagged_above=-999 required=5 tests=[AWL=-2.730, BAYES_05=-1.11, 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 PlYtlj3nzMMc for ; Mon, 26 Nov 2012 18:29:34 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6EF21F8670 for ; Mon, 26 Nov 2012 18:29:34 -0800 (PST) Received: from [192.168.1.75] (unknown [118.209.244.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 398E2509B5 for ; Mon, 26 Nov 2012 21:29:32 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9337072E-061E-402C-A9E0-F77E8BE1A409@mnot.net> Date: Tue, 27 Nov 2012 13:29:29 +1100 To: Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [apps-discuss] JSON-Patch and XSRF 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, 27 Nov 2012 02:29:35 -0000 One thing to note about the format we've chosen for JSON-Patch -- at the = top level, it's an array, which has some security implications, = according to = . Practically speaking, this means that people shouldn't make Patch files = containing sensitive information available through GET on Web servers, = even if they're protected by some form of authentication. Is it sufficient to note this in Security Considerations, or do people = want to change the format? Regards, -- Mark Nottingham http://www.mnot.net/ From GK@ninebynine.org Tue Nov 27 08:05: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 F368721F8479; Tue, 27 Nov 2012 08:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 z+jS7tQmyScn; Tue, 27 Nov 2012 08:05:29 -0800 (PST) Received: from relay1.mail.ox.ac.uk (relay1.mail.ox.ac.uk [129.67.1.165]) by ietfa.amsl.com (Postfix) with ESMTP id D7D1021F846B; Tue, 27 Nov 2012 08:05:25 -0800 (PST) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay1.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TdNf0-0007vf-3h; Tue, 27 Nov 2012 16:05:22 +0000 Received: from zoo-dhcp16.zoo.ox.ac.uk ([129.67.26.221]) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TdNez-0007gI-9E; Tue, 27 Nov 2012 16:05:22 +0000 Message-ID: <50B4E168.5010300@ninebynine.org> Date: Tue, 27 Nov 2012 15:51:04 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <50B3D146.3080506@stpeter.im> <50B3F104.6010305@ninebynine.org> <50B3F3A4.2060002@stpeter.im> In-Reply-To: <50B3F3A4.2060002@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Julian Reschke , "uri-review@ietf.org" , "xmpp@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 27 Nov 2012 16:05:31 -0000 Peter, To be clear about this, are you saying that the apparent requirement in RFC6120 to use namespace jabber:server or jabber:client for "message", "presence" or "iq" stanzas no longer applies? If I were implementing XMPP based on what I read here, I would think that these namespaces *are* required, which suggests a problem with the XMPP spec. (I noticed the other namespaces, but since they all seemed to be urn: URIs I ignored them for this discussion.) #g -- On 26/11/2012 22:56, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/26/12 3:45 PM, Graham Klyne wrote: >> On 26/11/2012 20:29, Peter Saint-Andre wrote: >>> Agreed. We would register it immediately as historical. >> >> Is this strictly true? After all, doesn't XMPP still require use >> of jabber:client or jabber:server as namespaces for stanzas in XMPP >> streams? > > RFC 4395 says: > > In some circumstances, it is appropriate to note a URI scheme that > was once in use or registered but for whatever reason is no longer in > common use or the use is not recommended. > > I definitely think that 'jabber:' is not recommended. Various XML > namespaces with the 'jabber:' "scheme" are still in wide use, but we > have not minted any such namespaces since 1999 or 2000. > >> My original email cited an out-of-date RFC, but I did check back >> later: [[ Definition of XML Stanza: An XML stanza is the basic >> unit of meaning in XMPP. A stanza is a first-level element (at >> depth=1 of the stream) whose element name is "message", "presence", >> or "iq" and whose qualifying namespace is 'jabber:client' or >> 'jabber:server'. ]] -- >> http://tools.ietf.org/html/rfc6120#section-4.1 >> >> In light of this, my take is that jabber: is a current but very >> limited URI scheme, defining just two URIs (jabber:server and >> jabber:client) for use in XMPP streams. No other URIs or uses for >> this scheme are sanctioned. > > Actually there are more namespaces than just those two (we minted > about twenty of them in the early days of XMPP before we realized the > error of our ways). A full list can be found at > http://xmpp.org/registrar/namespaces.html -- but we haven't minted any > new ones in a long time and we're not about to start doing so again. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iEYEARECAAYFAlCz86QACgkQNL8k5A2w/vw3MQCg6UjFltp87J9ZfDbVD6/++S4i > yqEAoKbjXUHPvAvVatJh8B9p4n1VB4lW > =Imzk > -----END PGP SIGNATURE----- > From stpeter@stpeter.im Tue Nov 27 08:12: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 308F221F85FF; Tue, 27 Nov 2012 08:12:44 -0800 (PST) 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_66=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 zpun8rJeTNE5; Tue, 27 Nov 2012 08:12:43 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B4A6021F8562; Tue, 27 Nov 2012 08:12:43 -0800 (PST) Received: from [192.168.1.4] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B44C640092; Tue, 27 Nov 2012 09:17:36 -0700 (MST) Message-ID: <50B4E67A.80502@stpeter.im> Date: Tue, 27 Nov 2012 09:12:42 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Graham Klyne References: <50B3D146.3080506@stpeter.im> <50B3F104.6010305@ninebynine.org> <50B3F3A4.2060002@stpeter.im> <50B4E168.5010300@ninebynine.org> In-Reply-To: <50B4E168.5010300@ninebynine.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "uri-review@ietf.org" , "xmpp@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 27 Nov 2012 16:12:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/27/12 8:51 AM, Graham Klyne wrote: > Peter, > > To be clear about this, are you saying that the apparent > requirement in RFC6120 to use namespace jabber:server or > jabber:client for "message", "presence" or "iq" stanzas no longer > applies? If I were implementing XMPP based on what I read here, I > would think that these namespaces *are* required, which suggests a > problem with the XMPP spec. Yes, jabber:client and jabber:server are required by RFC 6120 (and RFC 6121 requires support for jabber:iq:roster). > (I noticed the other namespaces, but since they all seemed to be > urn: URIs I ignored them for this discussion.) Other old namespaces currently in use are jabber:iq:last, jabber:x:conference, jabber:iq:private, jabber:iq:version, jabber:iq:register, jabber:iq:rpc, jabber:iq:oob, jabber:component:accept, jabber:component:connect, jabber:iq:privacy, and jabber:x:data. After we deprecated the jabber:* form and before we started using URN-based namespaces (see RFC 4854), we also used HTTP URIs at the jabber.org domain. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC05noACgkQNL8k5A2w/vwl6wCeP7BmC00OhDOk+GjSCH4a4j+w DrsAoNNhzKk3GYYZH+pXovEUqxbSz94u =dbH4 -----END PGP SIGNATURE----- From bradfitz@google.com Mon Nov 26 11: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 C226221F8524 for ; Mon, 26 Nov 2012 11:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.562 X-Spam-Level: X-Spam-Status: No, score=-100.562 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 ML-NNi0qKi0F for ; Mon, 26 Nov 2012 11:56:43 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29A2821F851E for ; Mon, 26 Nov 2012 11:56:43 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so12577349oag.31 for ; Mon, 26 Nov 2012 11:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=wtzju4+jwtFirXrSoInzXWc4TJMt1LQR54dWXJ9Kbds=; b=NOKrVf0wrxt1uPchPq6RaVSu2vmX0OuKvXEEVPyOon6J1xYJQYwgEPA4ugXMwW98KZ DjWYmqbiq/gaqPnZfghbJR/FbemdC9JeZo27FSYx7u+aw34Yf+etb1CA8SAFP1Xo1Rw/ +36VynDAI8de6/TXgKzm9J/WyXmHEDTzUgsdnz4i2Lnb992jkmOVC+Bphk9ld8d62FXn KOK3+z0DlBerUGEQCuEB+CqRiPs8c9a9feZFwL2nQsMXQUdgAG/amJKSJYQzIIE7PbUT KWbwa4aAyQdoXeaGKML2wCleUt+xn6PKv38IIoeooUcimWpAlt4Wc3DI1RObS4K69Mvw etOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=wtzju4+jwtFirXrSoInzXWc4TJMt1LQR54dWXJ9Kbds=; b=oWNyOvtazXz6HBqWSs7/l7qONvaJWvk9nmE+O/WdjkOAacMf0BVaKLf/amA/jgPtVQ Vv+JMWkxCUPur7GA4QkvABKZoBAwgrGjR9KWVrKPaMs+lCSy+DeXezS/MUO/S9TfknTp zCiNT6Q7SPo3NVKukCkr88CuTOk7uAq1Y+LarNuOfVUhsSvfAtaHscRuvLu02e9AGIx0 Z/x5D4DWCEAfGilkEszwTKVQz8wkZhvyoAm50ZlmjjZAIcjVf9TmPzS7qKYkQFEJ9DI5 W3cl3ppR8NNQnHRTCFx8fST0tL7akgcHUrfGCrJCZMM94soMJV0Anr8ZHjPvoxdfVvXw lyaQ== MIME-Version: 1.0 Received: by 10.60.23.137 with SMTP id m9mr10548234oef.61.1353959802740; Mon, 26 Nov 2012 11:56:42 -0800 (PST) Received: by 10.76.74.134 with HTTP; Mon, 26 Nov 2012 11:56:42 -0800 (PST) Date: Mon, 26 Nov 2012 11:56:42 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com, apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb206ca151eb504cf6b55fc X-Gm-Message-State: ALoCoQkpJ3BxVjL0UMARoCEmlNrCIGy+vZCsmuOoIE4tvWgwgHoFLaQpZRFtfYv1DKUNNqd3y7szjYnPJpIpd7EKeWGxw967wOgMHDHgijZ7jrfvxbXebJBKS3jwW4oLcLiFmSltp8wcbtzpFir+vOmz7knA0EiuRpoXrBnxV0d18j3j9ROdUL1mY9QHV30BmhrRgavnEeL8 X-Mailman-Approved-At: Tue, 27 Nov 2012 08:20:04 -0800 Cc: Tim Bray Subject: [apps-discuss] webfinger goals & whether we care about $5/month hosting 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, 26 Nov 2012 19:56:43 -0000 --e89a8fb206ca151eb504cf6b55fc Content-Type: text/plain; charset=UTF-8 One of the reasons WebFinger development has moved so slowly (while proprietary silos continue to grow) is that we as a community have no focus, no deadlines, no decision makers, and no clear goals even. After seeing conflicting opinions both on lists and off-list, I'd like to discuss one goal (or non-goal) here: Does WebFinger care about people on "$5/month" static domain hosting plans? As one person asked off-list, "How do we solve this for my Father (a redneck luddite if you have ever met him)?" Personally, I think we should not care about this group. These theoretical "rednecks" won't run their own webfinger servers, and we shouldn't care. Most users will use a service provider for their webfinger, and anybody that has their own domain name and really wants to be in charge of their own identity will be able to own their root and be able to serve dynamic content from it (and for LESS than "$5/month"). And if webfinger becomes successful enough for these tech "luddites" (who already pay for their own domain name?) to want WebFinger, the market will adapt: these static hosting providers can provide webfinger access for them, mapping to static files under the user's control. Opinions? Regardless, can we lay out the assumptions & goals in the spec, so people understand what webfinger aims to both solve and to NOT solve? --e89a8fb206ca151eb504cf6b55fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= ne of the reasons WebFinger development has moved so slowly (while propriet= ary silos continue to grow) is that we as a community have no focus, no dea= dlines, no decision makers, and no clear goals even.

After seeing conflicting opinions both on lists and off-list= , I'd like to discuss one goal (or non-goal) here:

=
Does WebFinger care about people on "$5/month"=C2=A0static d= omain hosting plans?

As one person asked off-list, "How do we solve this for= my Father (a redneck luddite if you have ever met him)?"
Personally, I think we should not care about this group. =C2= =A0These=C2=A0theoretical=C2=A0"rednecks" won't run their own= webfinger servers, and we shouldn't care. =C2=A0Most users will use a = service provider for their webfinger, and anybody that has their own domain= name and really wants to be in charge of their own identity will be able t= o own their root and be able to serve dynamic content from it (and for LESS= than "$5/month"). =C2=A0And if webfinger becomes successful enou= gh for these tech "luddites" (who already pay for their own domai= n name?) to want WebFinger, the market will adapt: these static hosting pro= viders can provide webfinger access for them, mapping to static files under= the user's control.

Opinions?

Regardless, can we lay out = the assumptions & goals in the spec, so people understand what webfinge= r aims to both solve and to NOT solve?

--e89a8fb206ca151eb504cf6b55fc-- From nick@silverbucket.net Mon Nov 26 12:19: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 6AAC821F851B for ; Mon, 26 Nov 2012 12:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 OrU3e4xVHrWH for ; Mon, 26 Nov 2012 12:19:00 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 963FD21F84FF for ; Mon, 26 Nov 2012 12:18:59 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so9530894lah.31 for ; Mon, 26 Nov 2012 12:18:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=WQp8UG1JbaNGiPuk/Ygb0O4lX3OtYq2Q5NaEafGRG3g=; b=RpQvPkJEM7ILocYXMGP9SmaAChh63Dqbd+GdxAVhCNZeycPXBXcSr/iv3+/IRmSA39 K9nLOPzljbCS7By2RQcc4AkT0gQBxv5M5Tgr/J8VbV6TUg7qY9nhzHYO6MI6ACEZ5Qdb SS+MD7S/+3qQ+DPLMxgzqgZGo+jTBgmXNfbjw68vyXHXNBqhd+oVwyX0M4oWOdxWiq8l dXJWgJHMa9Cyf/9rPA9SBrgyQrqGoDpTYVjMIQvpPgWfPL5YWFOG36knNvohHriq+Izw x7gBM+ZA0gavVyJ0dcCKwxrFREUUh/PuhZT+gk8HwO1RgB0uBy97u29izOkOEFNxKLI7 gVaw== Received: by 10.112.25.161 with SMTP id d1mr5642068lbg.118.1353961138345; Mon, 26 Nov 2012 12:18:58 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id jk8sm5910454lab.7.2012.11.26.12.18.57 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2012 12:18:57 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so9530877lah.31 for ; Mon, 26 Nov 2012 12:18:57 -0800 (PST) Received: by 10.112.17.129 with SMTP id o1mr5598660lbd.54.1353961137137; Mon, 26 Nov 2012 12:18:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Mon, 26 Nov 2012 12:18:26 -0800 (PST) In-Reply-To: References: From: Nick Jennings Date: Mon, 26 Nov 2012 21:18:26 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmoIJcV4jN5+R1CalDjG478SUmiXBeRbzm0OWnV656Vu8Gm/F9HHo5g3LSUDSs7adNiKDl+ X-Mailman-Approved-At: Tue, 27 Nov 2012 08:20:04 -0800 Cc: Tim Bray , apps-discuss@ietf.org Subject: Re: [apps-discuss] webfinger goals & whether we care about $5/month hosting 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, 26 Nov 2012 20:20:45 -0000 +1 totally agree here. If WebFinger catches on, the market will adapt to allow our Dads to join in on all the fun. (In the meantime they still have their email provider, gmail/outlook/yahoo etc.) On Mon, Nov 26, 2012 at 8:56 PM, Brad Fitzpatrick wrote: > One of the reasons WebFinger development has moved so slowly (while > proprietary silos continue to grow) is that we as a community have no focus, > no deadlines, no decision makers, and no clear goals even. > > After seeing conflicting opinions both on lists and off-list, I'd like to > discuss one goal (or non-goal) here: > > Does WebFinger care about people on "$5/month" static domain hosting plans? > > As one person asked off-list, "How do we solve this for my Father (a redneck > luddite if you have ever met him)?" > > Personally, I think we should not care about this group. These theoretical > "rednecks" won't run their own webfinger servers, and we shouldn't care. > Most users will use a service provider for their webfinger, and anybody that > has their own domain name and really wants to be in charge of their own > identity will be able to own their root and be able to serve dynamic content > from it (and for LESS than "$5/month"). And if webfinger becomes successful > enough for these tech "luddites" (who already pay for their own domain > name?) to want WebFinger, the market will adapt: these static hosting > providers can provide webfinger access for them, mapping to static files > under the user's control. > > Opinions? > > Regardless, can we lay out the assumptions & goals in the spec, so people > understand what webfinger aims to both solve and to NOT solve? > From bradfitz@google.com Mon Nov 26 12:47: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 C5D8421F86CA for ; Mon, 26 Nov 2012 12:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.769 X-Spam-Level: X-Spam-Status: No, score=-101.769 tagged_above=-999 required=5 tests=[AWL=1.207, 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 wc8HKGq8RDPv for ; Mon, 26 Nov 2012 12:47:51 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 31BB921F84D7 for ; Mon, 26 Nov 2012 12:47:51 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so12661507oag.31 for ; Mon, 26 Nov 2012 12:47:50 -0800 (PST) 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; bh=Vv/23C+7tgUzEl6FEu2nyN0MPcK6Iqg131FkHXMrF1o=; b=jcBsLwj7M7sohtbHEml5Mb8GLUOo7YJOl+V6x5ARwFyqv+s0qiGaLHrBOPkQHt4wba Nk56FlkLkg62b9hFcIzagJS4LU1gQnEaH2AQV4+nLXH0fP5ugzwp5hO8bXU1VF5WHjo/ FeSfuClVMHcgNIhO3C8I9id6cFsAWgaNRxYBGE+L/OZXWrLlUso/E9dL9FRzl+0vKvbC CikDuitQTW8SguoC4sDBEIvHNGoDHrp8PDP5eL8U5MG/7qguw9Y3AlzkbLt2II/AnCBA W4x8eSOxETR/+QtRPJicl/SEUw6khYhDySwzOALFSI0XbHqOU0pDvRYzcBUkZE8vkqaf rlgw== 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=Vv/23C+7tgUzEl6FEu2nyN0MPcK6Iqg131FkHXMrF1o=; b=LIbRdz/oz7yMATmvBminm2fNRuALbjnMgZ/knkkXIFTawcSKprUdb6b6TH5oLW+BYd HpaIA40yS56DcFWhMhf3HluNToIxhQE/UjatOu6D3nX+077ZTIBfamRWfHQ2HkkWNXPS RBTggWuoxu+WZ2ofJEDNRZEQ7iWOEERRPqG+kNbTJuDnYejvMBDiiesarOBQcefdp691 hrvA9YHgd6ZQc8PDDYVYAztlsVQRdhQfm2UibApsys93UmYrQ2B1KrqalnZz5a0Y/IKP kBFIcaDAXCXN4ErzcNgvRmQkW2Qvzljgjxav5PY/jXrZEcrv5A9yB/38/y+o4ukA4njN ah5w== MIME-Version: 1.0 Received: by 10.60.26.165 with SMTP id m5mr10687983oeg.4.1353962870588; Mon, 26 Nov 2012 12:47:50 -0800 (PST) Received: by 10.76.74.134 with HTTP; Mon, 26 Nov 2012 12:47:50 -0800 (PST) In-Reply-To: References: Date: Mon, 26 Nov 2012 12:47:50 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8ff1c5ccf0c3c204cf6c0b07 X-Gm-Message-State: ALoCoQnk2517oTRbio7ojCd27+n3VRUMS4VyRhlzt4jFXVi3FUXeXSSUx6ye+ofoEWMHVV28byeU8IoGeIg/v5wE8MCmZL7QrS6twY61MY+zpWAaoQmaZckn/sip/aOPThO9jcp1Q3bITsRyjyvJQps5JzNsjqRmhIyTJ55uZ+o5ifg57UyrHXtFi/rbBPK9pyFXCxB4Zjhg X-Mailman-Approved-At: Tue, 27 Nov 2012 08:20:04 -0800 Cc: Tim Bray , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] webfinger goals & whether we care about $5/month hosting 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, 26 Nov 2012 20:47:52 -0000 --e89a8ff1c5ccf0c3c204cf6c0b07 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 26, 2012 at 12:45 PM, Joe Gregorio wrote: > > > > On Mon, Nov 26, 2012 at 2:56 PM, Brad Fitzpatrick wrote: > >> One of the reasons WebFinger development has moved so slowly (while >> proprietary silos continue to grow) is that we as a community have no >> focus, no deadlines, no decision makers, and no clear goals even. >> >> After seeing conflicting opinions both on lists and off-list, I'd like to >> discuss one goal (or non-goal) here: >> >> Does WebFinger care about people on "$5/month" static domain hosting >> plans? >> > > I don't think I'd phrase it as harshly as "don't care", but I do think > it's a huge mistake to let the existence of such > accounts limit WebFinger. > I actually think caring could be actively harmful: if caring about a tiny hypothetical userbase takes a simple spec and turns it into a complicated spec (with, say: too many optional pieces for client & server to implement, more crypto, etc), that could hinder adoption more than it helps. --e89a8ff1c5ccf0c3c204cf6c0b07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Mon, Nov 26, 2012 at 12:45 PM, Joe Gregorio <joe@bitworking.org>= wrote:



On Mon, = Nov 26, 2012 at 2:56 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:
One of the reasons WebFinger development has moved= so slowly (while proprietary silos continue to grow) is that we as a commu= nity have no focus, no deadlines, no decision makers, and no clear goals ev= en.

After seeing conflicting opinions both on lists and off-list= , I'd like to discuss one goal (or non-goal) here:

=
Does WebFinger care about people on "$5/month"=C2=A0static d= omain hosting plans?

I don't think I'= d phrase it as harshly as "don't care", but I do think it'= ;s a huge mistake to let the existence of such
accounts limit Web= Finger.

I actually think caring could = be actively harmful: =C2=A0if caring about a tiny hypothetical userbase tak= es a simple spec and turns it into a complicated spec (with, say: too many = optional pieces for client & server to implement, more crypto, etc), th= at could hinder adoption more than it helps.

--e89a8ff1c5ccf0c3c204cf6c0b07-- From zhangyunfei@chinamobile.com Mon Nov 26 17:58: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 B3C8221F868C for ; Mon, 26 Nov 2012 17:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.623 X-Spam-Level: X-Spam-Status: No, score=-98.623 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, 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 RLbNFgOFTMiz for ; Mon, 26 Nov 2012 17:58:45 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A6F5B21F8652 for ; Mon, 26 Nov 2012 17:58:39 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 48823E5CC; Tue, 27 Nov 2012 09:58:36 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 40466E4F3; Tue, 27 Nov 2012 09:58:36 +0800 (CST) Received: from zyf-PC ([10.2.53.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012112709583476-3068 ; Tue, 27 Nov 2012 09:58:34 +0800 Date: Tue, 27 Nov 2012 09:58:24 +0800 From: zhangyunfei To: "Salvatore Loreto" , "apps-discuss@ietf.org" , draft-ietf-ppsp-problem-statement References: <50B3D735.1060109@ericsson.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012112709582478527660@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-27 09:58:34, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-27 09:58:35, Serialize complete at 2012-11-27 09:58:35 Content-Type: multipart/alternative; boundary="----=_001_NextPart201082026500_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19396.003 X-TM-AS-Result: No--24.679-7.0-31-10 X-imss-scan-details: No--24.679-7.0-31-10;No--24.679-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No X-Mailman-Approved-At: Tue, 27 Nov 2012 08:20:04 -0800 Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-ppsp-problem-statement-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 01:58:45 -0000 This is a multi-part message in MIME format. ------=_001_NextPart201082026500_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="iso-8859-1" VGhhbmtzIFNhbHZhdG9yZSBmb3IgcmV2aWV3aW5nIHRoZSBkb2N1bWVudC4NCg0KQlINCll1bmZl aQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBTYWx2YXRvcmUgTG9yZXRvDQpEYXRlOiAy MDEyLTExLTI3IDA0OjU1DQpUbzogYXBwcy1kaXNjdXNzQGlldGYub3JnOyBkcmFmdC1pZXRmLXBw c3AtcHJvYmxlbS1zdGF0ZW1lbnQNClN1YmplY3Q6IEFQUFNESVIgcmV2aWV3IG9mIGRyYWZ0LWll dGYtcHBzcC1wcm9ibGVtLXN0YXRlbWVudC0xMQ0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhl IEFwcGxpY2F0aW9ucyBBcmVhIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciANCnRoaXMgZHJhZnQg KA0KZm9yIGJhY2tncm91bmQgb24gYXBwc2RpciwgcGxlYXNlIHNlZSANCmh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvYXBwL3RyYWMvd2lraS9BcHBsaWNhdGlvbnNBcmVhRGlyZWN0b3Jh dGUgKS4gDQoNCg0KUGxlYXNlIHJlc29sdmUgdGhlc2UgY29tbWVudHMgYWxvbmcgd2l0aCBhbnkg b3RoZXIgY29tbWVudHMgeW91ICBtYXkgDQpyZWNlaXZlLg0KUGxlYXNlIHdhaXQgZm9yIGRpcmVj dGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgc2hlcGhlcmQgb3IgQUQgYmVmb3JlIA0KcG9zdGluZyBh IG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtcHBzcC1w cm9ibGVtLXN0YXRlbWVudC0xMQ0KVGl0bGU6IFByb2JsZW0gU3RhdGVtZW50IGFuZCBSZXF1aXJl bWVudHMgb2YgUGVlci10by1QZWVyIFN0cmVhbWluZyANClByb3RvY29sIChQUFNQKQ0KUmV2aWV3 ZXI6IFNhbHZhdG9yZSBMb3JldG8NClJldmlldyBEYXRlOiAyNiBOb3ZlbWJlciAyMDEyDQpTdW1t YXJ5OiBUaGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFzIGEgUHJvcG9zZWQg U3RhbmRhcmQuDQoNCk1ham9yIElzc3Vlczogbm9uZQ0KTWlub3IgSXNzdWVzL05pdHM6IG5vbmU= ------=_001_NextPart201082026500_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
Thanks Salvatore for reviewing the document.
 
BR
Yunfei
 
zhangyunfei
 
Date: 2012-11-27 04:55
To: apps-discuss@ietf.org; draft-iet= f-ppsp-problem-statement
Subject: APPSDIR review of=20 draft-ietf-ppsp-problem-statement-11
I have been selected as the Application= s Area Directorate reviewer for 
this draft (
for background on appsdir, please see <= /DIV>
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirecto= rate ). 
 
 
Please resolve these comments along with&nbs= p;any other comments you  may 
receive.
Please wait for direction from your doc= ument shepherd or AD before 
posting a new version of the draft.
 
Document: draft-ietf-ppsp-problem-statement-11
Title: Problem Statement and Requirements of=  Peer-to-Peer Streaming 
Protocol (PPSP)
Reviewer: Salvatore Loreto
Review Date: 26 November 2012
Summary: The document is ready for publ= ication as a Proposed Standard.
 
Major Issues: none
Minor Issues/Nits: none
------=_001_NextPart201082026500_=------ From GK@ninebynine.org Tue Nov 27 08:36: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 DD98621F8534; Tue, 27 Nov 2012 08:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 jZeBAszvXwG3; Tue, 27 Nov 2012 08:36:06 -0800 (PST) Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by ietfa.amsl.com (Postfix) with ESMTP id 14B8D21F842C; Tue, 27 Nov 2012 08:36:06 -0800 (PST) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TdO8g-0006SQ-28; Tue, 27 Nov 2012 16:36:02 +0000 Received: from zoo-dhcp16.zoo.ox.ac.uk ([129.67.26.221]) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TdO8g-0001uz-1F; Tue, 27 Nov 2012 16:36:02 +0000 Message-ID: <50B4EBA9.8030700@ninebynine.org> Date: Tue, 27 Nov 2012 16:34:49 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <50B3D146.3080506@stpeter.im> <50B3F104.6010305@ninebynine.org> <50B3F3A4.2060002@stpeter.im> <50B4E168.5010300@ninebynine.org> <50B4E67A.80502@stpeter.im> In-Reply-To: <50B4E67A.80502@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Julian Reschke , "uri-review@ietf.org" , "xmpp@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 27 Nov 2012 16:36:08 -0000 On 27/11/2012 16:12, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/27/12 8:51 AM, Graham Klyne wrote: >> Peter, >> >> To be clear about this, are you saying that the apparent >> requirement in RFC6120 to use namespace jabber:server or >> jabber:client for "message", "presence" or "iq" stanzas no longer >> applies? If I were implementing XMPP based on what I read here, I >> would think that these namespaces *are* required, which suggests a >> problem with the XMPP spec. > > Yes, jabber:client and jabber:server are required by RFC 6120 (and RFC > 6121 requires support for jabber:iq:roster). OK, that's what I originally thought. In which case, I think the text from RFC 4395 that you cited does not apply, since use of these jabber: URIs is still required (and others as you note below). I think the appropriate course would be to register the URI scheme, maybe list the URIs in use for this scheme, and add a note that no more jabber: URIs should be minted. #g -- >> (I noticed the other namespaces, but since they all seemed to be >> urn: URIs I ignored them for this discussion.) > > Other old namespaces currently in use are jabber:iq:last, > jabber:x:conference, jabber:iq:private, jabber:iq:version, > jabber:iq:register, jabber:iq:rpc, jabber:iq:oob, > jabber:component:accept, jabber:component:connect, jabber:iq:privacy, > and jabber:x:data. From jhildebr@cisco.com Tue Nov 27 09:04: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 CDAD221F851F; Tue, 27 Nov 2012 09:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 Hp4533JtP2KM; Tue, 27 Nov 2012 09:04:26 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1596221F846B; Tue, 27 Nov 2012 09:04:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=949; q=dns/txt; s=iport; t=1354035866; x=1355245466; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GcosaTb200+aHMcRMxh+d2wOtno8JZEBZW99OF5Vky4=; b=giQt5P8VteGJMqO1SQRUmqyrPoxxldgIRu+XnrTguwh25YrycyVdtqqH TVXyyg81P6On/yLuAf6MdKBpenz4C19layQ94RpeayOCqeJPUZbp10Qb1 gMG2jnkqnwxAaNvgzSxCn/SX3UgSDXQrq6qrTuLrgM09AjTQg8IY2Dcrn o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAHvxtFCtJV2a/2dsb2JhbABFhWK6PIEJgh4BAQEDATo/EgEIDhQUQiUCBAENBQiHfwawRpBLkBphA6ZFgnCCIA X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146745122" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 27 Nov 2012 17:04:25 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qARH4P2v004539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 17:04:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.236]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 11:04:25 -0600 From: "Joe Hildebrand (jhildebr)" To: Graham Klyne , Peter Saint-Andre Thread-Topic: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? Thread-Index: AQHNzLkD4QLcs/TdaESDPBgLU8DDkJf+PzEAgAAGLoD//5LogA== Date: Tue, 27 Nov 2012 17:04:24 +0000 Message-ID: In-Reply-To: <50B4EBA9.8030700@ninebynine.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.129.24.84] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Julian Reschke , "uri-review@ietf.org" , "apps-discuss@ietf.org" , "xmpp@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 27 Nov 2012 17:04:26 -0000 On 11/27/12 9:34 AM, "Graham Klyne" wrote: >> Yes, jabber:client and jabber:server are required by RFC 6120 (and RFC >> 6121 requires support for jabber:iq:roster). > >OK, that's what I originally thought. In which case, I think the text >from RFC=20 >4395 that you cited does not apply, since use of these jabber: URIs is >still=20 >required (and others as you note below). > >I think the appropriate course would be to register the URI scheme, maybe >list=20 >the URIs in use for this scheme, and add a note that no more jabber: URIs >should=20 >be minted. (as individual) As long as the registry has a policy of "Closed" or similar, I don't really care what status the doc has. Let's not bog down. (as XMPP co-chair) This isn't on our charter at the moment, so whoever wants to write an individual draft first should just pick a status, and that will probably stick. --=20 Joe Hildebrand From stpeter@stpeter.im Tue Nov 27 09:05: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 0E7F121F846A; Tue, 27 Nov 2012 09:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_66=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 oMnWJ1jgNBmI; Tue, 27 Nov 2012 09:05:53 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D040721F85EF; Tue, 27 Nov 2012 09:05:52 -0800 (PST) Received: from [192.168.1.4] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4C7BA40092; Tue, 27 Nov 2012 10:10:46 -0700 (MST) Message-ID: <50B4F2F0.3050406@stpeter.im> Date: Tue, 27 Nov 2012 10:05:52 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "uri-review@ietf.org" , Graham Klyne , "apps-discuss@ietf.org" , "xmpp@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 27 Nov 2012 17:05:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/27/12 10:04 AM, Joe Hildebrand (jhildebr) wrote: > On 11/27/12 9:34 AM, "Graham Klyne" wrote: > >>> Yes, jabber:client and jabber:server are required by RFC 6120 >>> (and RFC 6121 requires support for jabber:iq:roster). >> >> OK, that's what I originally thought. In which case, I think the >> text from RFC 4395 that you cited does not apply, since use of >> these jabber: URIs is still required (and others as you note >> below). >> >> I think the appropriate course would be to register the URI >> scheme, maybe list the URIs in use for this scheme, and add a >> note that no more jabber: URIs should be minted. > > (as individual) > > As long as the registry has a policy of "Closed" or similar, I > don't really care what status the doc has. Let's not bog down. > > (as XMPP co-chair) > > This isn't on our charter at the moment, so whoever wants to write > an individual draft first should just pick a status, and that will > probably stick. I think it can be an informational I-D outside any WG, and will find time to bang that out before the end of the year. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC08vAACgkQNL8k5A2w/vwOcQCeJ8C2wtz74nbUX3N8/K4rl1y6 XVQAoK/MHyRz8Sfx4FmHag/xGHcw7tdh =lR0y -----END PGP SIGNATURE----- From julian.reschke@gmx.de Tue Nov 27 09:15: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 E0BFE21F8436 for ; Tue, 27 Nov 2012 09:15:59 -0800 (PST) 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 ZhQ63CVZGopo for ; Tue, 27 Nov 2012 09:15:59 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id C4E8A21F8201 for ; Tue, 27 Nov 2012 09:15:58 -0800 (PST) Received: (qmail invoked by alias); 27 Nov 2012 17:15:57 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp001) with SMTP; 27 Nov 2012 18:15:57 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+zfYllUCOz4UXeGUAnD4TwRExDu2Qx+0+nN6SBfX En1iupur3Pj/v/ Message-ID: <50B4F54A.1040705@gmx.de> Date: Tue, 27 Nov 2012 18:15:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mark Nottingham References: <9337072E-061E-402C-A9E0-F77E8BE1A409@mnot.net> In-Reply-To: <9337072E-061E-402C-A9E0-F77E8BE1A409@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and XSRF 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, 27 Nov 2012 17:16:00 -0000 On 2012-11-27 03:29, Mark Nottingham wrote: > One thing to note about the format we've chosen for JSON-Patch -- at the top level, it's an array, which has some security implications, according to . > > Practically speaking, this means that people shouldn't make Patch files containing sensitive information available through GET on Web servers, even if they're protected by some form of authentication. > > Is it sufficient to note this in Security Considerations, or do people want to change the format? > ... ...like sticking the array into a container; or going back to the old format? From barryleiba.mailing.lists@gmail.com Tue Nov 27 09:45: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 0F08021F85CE; Tue, 27 Nov 2012 09:45:37 -0800 (PST) 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=[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 b3BWW9RwdLed; Tue, 27 Nov 2012 09:45:36 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87FBC21F8574; Tue, 27 Nov 2012 09:45:35 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so10589870lbk.31 for ; Tue, 27 Nov 2012 09:45:34 -0800 (PST) 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=cm88pxTI4MDHe1V4ytp8PzmalPUpCOmUJXHTBPBqr8A=; b=YDHJBBFQtLMu9mCeU67aiogvf8t+Siy8C+kNBy6iyB8HJOYkDmXuaGmIdI5jvQcOQD vsTgMGrb10loqJwpIB0HjG96yQrPa+enLkysVi/LU7m0w2VnNddxqhMC/K5zGJ50/rkJ W6kSBW2wl/jbTyLM3SyNA1dxhxksKdO++g5iEEx2Dzbok/2t7ZtJtAGdBWBKyk7XSphE XNpQjTdVpogGx/iJUDa7Xw31tpo65k1eeG4Nhlu5OfPC2ccpy5Co2icrJPSgQwMeSmZn SNBf1pslVi5iM5N5xS0lROY98db9myU8uuhELvuLyaokCgqoOjrH1ml1AGGTQZbSJ80G L3vg== MIME-Version: 1.0 Received: by 10.152.108.197 with SMTP id hm5mr15459860lab.45.1354038334474; Tue, 27 Nov 2012 09:45:34 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Tue, 27 Nov 2012 09:45:34 -0800 (PST) In-Reply-To: <50B4F2F0.3050406@stpeter.im> References: <50B4F2F0.3050406@stpeter.im> Date: Tue, 27 Nov 2012 12:45:34 -0500 X-Google-Sender-Auth: QrYshb6ZGVa-CBY3r4wZ2ECblxM Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" , Julian Reschke , Graham Klyne , "xmpp@ietf.org" , "uri-review@ietf.org" Subject: Re: [apps-discuss] [Uri-review] XMPP jabber: URI scheme not registered? 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, 27 Nov 2012 17:45:37 -0000 >> This isn't on our charter at the moment, so whoever wants to write >> an individual draft first should just pick a status, and that will >> probably stick. > > I think it can be an informational I-D outside any WG, and will find > time to bang that out before the end of the year. Independent Stream, even.... Barry From paulej@packetizer.com Tue Nov 27 11:23: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 78CE321F85FE for ; Tue, 27 Nov 2012 11:23:50 -0800 (PST) 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=[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 znp7BGe2k09A for ; Tue, 27 Nov 2012 11:23:49 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2584621F85CC for ; Tue, 27 Nov 2012 11:23:49 -0800 (PST) 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 qARJNkRr009073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Nov 2012 14:23:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354044227; bh=FZn/XtkYzpUf8fniF1Mlenj5njdT7wfVseEiB5mprQ4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Q9p75qQBdgWpQStfm6COcyvISVeFGsu2pgxDxE4TsMiq6/t2ODPez108bi6KbgE37 XG3vRrPgPK9D+qwF0P5YUJqcTMo2DA/WFmHVsztUhmvg++4FotfKqEuBrBuXFxrGA2 QID6lCQeYMkeckRlNCfDCq8IsYdmfn2t4mDbqT1Q= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" , , References: In-Reply-To: Date: Tue, 27 Nov 2012 14:24:08 -0500 Message-ID: <051e01cdccd4$c652ca60$52f85f20$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_051F_01CDCCAA.DD7DACC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH0Su7XyMj7GAy/R/pdY9fIo4OwGpexC/Pg Content-Language: en-us Subject: Re: [apps-discuss] webfinger goals & whether we care about $5/month hosting 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, 27 Nov 2012 19:23:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_051F_01CDCCAA.DD7DACC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Brad, et al, =20 I=E2=80=99ll tell you right now that I think the deadline is past and we = need to get this done :) =20 Not to be taking sides on the =E2=80=9Cwebfinger=E2=80=9D subdomain = issue, but I use hosting services that cost $1/mo and some approaching = $100/mo. I manage one account that is the more typical $6.95/mo. In = every instance, there is a web server and I have the ability to insert a = 3xx redirection to a different location if I want. =20 Are there services out there that cannot allow customers to redirect = requests using 3xx or insert an A record for the root of their domain? = I=E2=80=99ll also add that the DNS management can be entirely separate = from the hosting provider. I can use my registrar (Go Daddy), my = hosting provider, or companies like dyn to provide DNS services. Thus, = if I did not run my own web server, I could map A for example.com to = point to my WF service provider (who would likely provide other = services). =20 If any of the above simply cannot work, we need some other mechanism. = What I don=E2=80=99t know, obviously, is =E2=80=9Cwhat I don=E2=80=99t = know.=E2=80=9D Are there truly domain owners who would not either be = able to do 3xx or assign their domain=E2=80=99s A record? =20 Paul =20 From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Brad Fitzpatrick Sent: Monday, November 26, 2012 2:57 PM To: webfinger@googlegroups.com; apps-discuss@ietf.org Cc: Tim Bray Subject: [apps-discuss] webfinger goals & whether we care about $5/month = hosting =20 One of the reasons WebFinger development has moved so slowly (while = proprietary silos continue to grow) is that we as a community have no = focus, no deadlines, no decision makers, and no clear goals even. =20 After seeing conflicting opinions both on lists and off-list, I'd like = to discuss one goal (or non-goal) here: =20 Does WebFinger care about people on "$5/month" static domain hosting = plans? As one person asked off-list, "How do we solve this for my Father (a = redneck luddite if you have ever met him)?" =20 Personally, I think we should not care about this group. These = theoretical "rednecks" won't run their own webfinger servers, and we = shouldn't care. Most users will use a service provider for their = webfinger, and anybody that has their own domain name and really wants = to be in charge of their own identity will be able to own their root and = be able to serve dynamic content from it (and for LESS than "$5/month"). = And if webfinger becomes successful enough for these tech "luddites" = (who already pay for their own domain name?) to want WebFinger, the = market will adapt: these static hosting providers can provide webfinger = access for them, mapping to static files under the user's control. =20 Opinions? Regardless, can we lay out the assumptions & goals in the spec, so = people understand what webfinger aims to both solve and to NOT solve? ------=_NextPart_000_051F_01CDCCAA.DD7DACC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Brad, et al,

 

I=E2=80=99ll tell you right now that I think the deadline is past and = we need to get this done :)

 

Not to be taking sides on the =E2=80=9Cwebfinger=E2=80=9D subdomain = issue, but I use hosting services that cost $1/mo and some approaching = $100/mo. =C2=A0I manage one account that is the more typical = $6.95/mo.=C2=A0 In every instance, there is a web server and I have the = ability to insert a 3xx redirection to a different location if I = want.

 

Are there services out there that cannot allow customers to = redirect requests using 3xx or insert an A record for the root of = their domain?=C2=A0 I=E2=80=99ll also add that the DNS management can be = entirely separate from the hosting provider.=C2=A0 I can use my = registrar (Go Daddy), my hosting provider, or companies like dyn to = provide DNS services.=C2=A0 Thus, if I did not run my own web server, I = could map A for example.com to point to my WF service provider (who = would likely provide other services).

 

If any of the above simply cannot work, we need some other = mechanism.=C2=A0 What I don=E2=80=99t know, obviously, is =E2=80=9Cwhat = I don=E2=80=99t know.=E2=80=9D Are there truly domain owners who would = not either be able to do 3xx or assign their domain=E2=80=99s A = record?

 

Paul

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Brad Fitzpatrick
Sent: Monday, November = 26, 2012 2:57 PM
To: webfinger@googlegroups.com; = apps-discuss@ietf.org
Cc: Tim Bray
Subject: = [apps-discuss] webfinger goals & whether we care about $5/month = hosting

 

One of the = reasons WebFinger development has moved so slowly (while proprietary = silos continue to grow) is that we as a community have no focus, no = deadlines, no decision makers, and no clear goals = even.

 

After seeing = conflicting opinions both on lists and off-list, I'd like to discuss one = goal (or non-goal) here:

 

Does = WebFinger care about people on "$5/month" static domain = hosting plans?

As one = person asked off-list, "How do we solve this for my Father (a = redneck luddite if you have ever met = him)?"

 

Personally, = I think we should not care about this group. =  These theoretical "rednecks" won't run their = own webfinger servers, and we shouldn't care.  Most users will use = a service provider for their webfinger, and anybody that has their own = domain name and really wants to be in charge of their own identity will = be able to own their root and be able to serve dynamic content from it = (and for LESS than "$5/month").  And if webfinger becomes = successful enough for these tech "luddites" (who already pay = for their own domain name?) to want WebFinger, the market will adapt: = these static hosting providers can provide webfinger access for them, = mapping to static files under the user's = control.

 

Opinions?

Regardless, = can we lay out the assumptions & goals in the spec, so people = understand what webfinger aims to both solve and to NOT = solve?

------=_NextPart_000_051F_01CDCCAA.DD7DACC0-- From nico@cryptonector.com Tue Nov 27 11:48: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 1C78C21F86B8 for ; Tue, 27 Nov 2012 11:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 mzJ3xjavO5Aw for ; Tue, 27 Nov 2012 11:48:52 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9081221F86B5 for ; Tue, 27 Nov 2012 11:48:52 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 240D4B8072 for ; Tue, 27 Nov 2012 11:48:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=9vC2MqUacrGanPYDx87Z tunPq1w=; b=UgF69YgK6oG2UE83HTjpZXxMaZct1hMtkeWnapkxtl5ylRq9mp0a l6YtQxFWbhM0jx/HRh92mhadutVqrerQAtXHDUqX6Xam1nT1AY8DNfszg9Z2nyBY +r2+XXeJSYvzqi1albc6LND3u/ygmFRvm7brFVhRq0oDDZfqz4gZ8oo= Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 09D83B806B for ; Tue, 27 Nov 2012 11:48:51 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so2779171dae.31 for ; Tue, 27 Nov 2012 11:48:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.239.104 with SMTP id vr8mr51264997pbc.59.1354045731142; Tue, 27 Nov 2012 11:48:51 -0800 (PST) Received: by 10.68.128.234 with HTTP; Tue, 27 Nov 2012 11:48:51 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Nov 2012 13:48:51 -0600 Message-ID: From: Nico Williams To: Nick Jennings Content-Type: text/plain; charset=UTF-8 Cc: Tim Bray , webfinger@googlegroups.com, Apps Discuss Subject: Re: [apps-discuss] webfinger goals & whether we care about $5/month hosting 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, 27 Nov 2012 19:48:53 -0000 On Mon, Nov 26, 2012 at 2:18 PM, Nick Jennings wrote: > +1 totally agree here. > > If WebFinger catches on, the market will adapt to allow our Dads to > join in on all the fun. (In the meantime they still have their email > provider, gmail/outlook/yahoo etc.) Right, if WF is a killer app then providers will support it very quickly. We shouldn't focus on provider complexity then; we should focus on client complexity instead. IMO there should be one discovery scheme: either as options to XHR modifying how http(s) URL servers are resolved, or as a new URI scheme that involves service discovery. Nico -- From tbray@textuality.com Tue Nov 27 12:06: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 09C5A21F877B for ; Tue, 27 Nov 2012 12:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 X+a0zsEDX6jl for ; Tue, 27 Nov 2012 12:06:34 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id E13BD21F8746 for ; Tue, 27 Nov 2012 12:06:26 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so14071344oag.31 for ; Tue, 27 Nov 2012 12:06:26 -0800 (PST) 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=R9T1Ddqj9JJbeaFrFIIH8PBU/sGDOQwakzSTFNmM/qM=; b=J8Pz5eOpLWlXgIdAvCIQZbCIcYFInYjX4NwKuyVAZbWEwaCbYiYW4FaLE3gDOQp9K9 ZIUufu5lG34azcdtl/amlm7o1TSq9VFhjQrqGrzODG0Nppb9FH8HScKwOnL08om48Uhg XgANrRE/+eUj8sIwgRVvJm0bnokhaf3+5G3/sDlBbjjFqBEwK2o4i8uwlmUATcHNp11C ZlZxsIxGOrF5cFzYq92zBqQuDxt3KW9w8pAbFoiwDcYzc5D2LXZ9h4s52vFeRS9u/VVz ozr6vNh869mWT1+adEbvNnCic3PCKQ9ezo1OTGrU5VYNH8fHv5aVnMgIl3HPq+vTp1Uu hW3A== MIME-Version: 1.0 Received: by 10.60.5.231 with SMTP id v7mr7447392oev.62.1354046786155; Tue, 27 Nov 2012 12:06:26 -0800 (PST) Received: by 10.76.12.134 with HTTP; Tue, 27 Nov 2012 12:06:26 -0800 (PST) X-Originating-IP: [24.84.208.217] In-Reply-To: References: Date: Tue, 27 Nov 2012 12:06:26 -0800 Message-ID: From: Tim Bray To: Nico Williams Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmqIbOZTppxUd37MkVlmLE6IP9iuRCq37DOygZifLLGTm/lczndqRhGkcIFpGLi4EBGZ5+b Cc: Tim Bray , Nick Jennings , webfinger@googlegroups.com, Apps Discuss Subject: Re: [apps-discuss] webfinger goals & whether we care about $5/month hosting 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, 27 Nov 2012 20:06:37 -0000 OK, I checked around with the Googlers who are supposed to care about this stuff, and there=92s nobody here who=92s willing to go to bat any more for = the subdomain idea. So if anyone really wants to keep section 5.5, now would be a good time to speak up. -Tim On Tue, Nov 27, 2012 at 11:48 AM, Nico Williams wro= te: > On Mon, Nov 26, 2012 at 2:18 PM, Nick Jennings wr= ote: >> +1 totally agree here. >> >> If WebFinger catches on, the market will adapt to allow our Dads to >> join in on all the fun. (In the meantime they still have their email >> provider, gmail/outlook/yahoo etc.) > > Right, if WF is a killer app then providers will support it very > quickly. We shouldn't focus on provider complexity then; we should > focus on client complexity instead. IMO there should be one discovery > scheme: either as options to XHR modifying how http(s) URL servers are > resolved, or as a new URI scheme that involves service discovery. > > Nico > -- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From pbryan@anode.ca Tue Nov 27 13:33: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 67EAB21F84D7 for ; Tue, 27 Nov 2012 13:33:58 -0800 (PST) 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=[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 gtCwSDFtnIAs for ; Tue, 27 Nov 2012 13:33:56 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAD421F84DC for ; Tue, 27 Nov 2012 13:33:56 -0800 (PST) Received: from [10.126.22.61] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 498D9645A; Tue, 27 Nov 2012 21:33:55 +0000 (UTC) From: "Paul C. Bryan" To: Mark Nottingham In-Reply-To: <9337072E-061E-402C-A9E0-F77E8BE1A409@mnot.net> References: <9337072E-061E-402C-A9E0-F77E8BE1A409@mnot.net> Content-Type: multipart/alternative; boundary="=-td70NMq6cIzSrcKuyxcC" Date: Tue, 27 Nov 2012 13:33:50 -0800 Message-ID: <1354052030.5145.1.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and XSRF 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, 27 Nov 2012 21:33:58 -0000 --=-td70NMq6cIzSrcKuyxcC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit IMO, it is sufficient to note this in the security considerations. Paul On Tue, 2012-11-27 at 13:29 +1100, Mark Nottingham wrote: > One thing to note about the format we've chosen for JSON-Patch -- at the top level, it's an array, which has some security implications, according to . > > Practically speaking, this means that people shouldn't make Patch files containing sensitive information available through GET on Web servers, even if they're protected by some form of authentication. > > Is it sufficient to note this in Security Considerations, or do people want to change the format? > > Regards, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-td70NMq6cIzSrcKuyxcC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit IMO, it is sufficient to note this in the security considerations.

Paul

On Tue, 2012-11-27 at 13:29 +1100, Mark Nottingham wrote: 
One thing to note about the format we've chosen for JSON-Patch -- at the top level, it's an array, which has some security implications, according to <http://haacked.com/archive/2009/06/24/json-hijacking.aspx>.

Practically speaking, this means that people shouldn't make Patch files containing sensitive information available through GET on Web servers, even if they're protected by some form of authentication.

Is it sufficient to note this in Security Considerations, or do people want to change the format?

Regards,

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



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

--=-td70NMq6cIzSrcKuyxcC-- From mnot@mnot.net Tue Nov 27 13:35: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 2F73321F84DC for ; Tue, 27 Nov 2012 13:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.127 X-Spam-Level: X-Spam-Status: No, score=-105.127 tagged_above=-999 required=5 tests=[AWL=-2.528, 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 GZLf9umiScbj for ; Tue, 27 Nov 2012 13:35:02 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id A454921F84D7 for ; Tue, 27 Nov 2012 13:35:02 -0800 (PST) Received: from [192.168.1.75] (unknown [118.209.244.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1E1AE509BA; Tue, 27 Nov 2012 16:34:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <1354052030.5145.1.camel@pbryan-wsl.internal.salesforce.com> Date: Wed, 28 Nov 2012 08:34:55 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5799DE00-0109-4A04-83B3-63CBA10F4387@mnot.net> References: <9337072E-061E-402C-A9E0-F77E8BE1A409@mnot.net> <1354052030.5145.1.camel@pbryan-wsl.internal.salesforce.com> To: "Paul C. Bryan" X-Mailer: Apple Mail (2.1499) Cc: Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and XSRF 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, 27 Nov 2012 21:35:03 -0000 I tend to agree. On 28/11/2012, at 8:33 AM, "Paul C. Bryan" wrote: > IMO, it is sufficient to note this in the security considerations. >=20 > Paul >=20 > On Tue, 2012-11-27 at 13:29 +1100, Mark Nottingham wrote: >> One thing to note about the format we've chosen for JSON-Patch -- at = the top level, it's an array, which has some security implications, = according to > >. >>=20 >> Practically speaking, this means that people shouldn't make Patch = files containing sensitive information available through GET on Web = servers, even if they're protected by some form of authentication. >>=20 >> Is it sufficient to note this in Security Considerations, or do = people want to change the format? >>=20 >> Regards, >>=20 >> -- >> Mark Nottingham =20 >> http://www.mnot.net/ >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >>=20 >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 -- Mark Nottingham http://www.mnot.net/ From pbryan@anode.ca Tue Nov 27 13:40: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 5CB8521F84DF for ; Tue, 27 Nov 2012 13:40:50 -0800 (PST) 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=[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 R7lYL8cda4IS for ; Tue, 27 Nov 2012 13:40:49 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7855521F84DC for ; Tue, 27 Nov 2012 13:40:49 -0800 (PST) Received: from [10.126.22.61] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 7BCC7645A; Tue, 27 Nov 2012 21:40:48 +0000 (UTC) From: "Paul C. Bryan" To: Julian Reschke In-Reply-To: <50B4F54A.1040705@gmx.de> References: <9337072E-061E-402C-A9E0-F77E8BE1A409@mnot.net> <50B4F54A.1040705@gmx.de> Content-Type: multipart/alternative; boundary="=-60QMrE7ZCQubf3A+xbZI" Date: Tue, 27 Nov 2012 13:40:47 -0800 Message-ID: <1354052447.5145.5.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and XSRF 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, 27 Nov 2012 21:40:50 -0000 --=-60QMrE7ZCQubf3A+xbZI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit In the first draft[1], it was wrapped in a { "patches": [ ... ] } object. This was considered needlessly verbose at the time, leading to the stripping of the object to have the raw array we have today. Paul [1] http://tools.ietf.org/html/draft-pbryan-json-patch-00 On Tue, 2012-11-27 at 18:15 +0100, Julian Reschke wrote: > On 2012-11-27 03:29, Mark Nottingham wrote: > > One thing to note about the format we've chosen for JSON-Patch -- at the top level, it's an array, which has some security implications, according to . > > > > Practically speaking, this means that people shouldn't make Patch files containing sensitive information available through GET on Web servers, even if they're protected by some form of authentication. > > > > Is it sufficient to note this in Security Considerations, or do people want to change the format? > > ... > > ...like sticking the array into a container; or going back to the old > format? > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-60QMrE7ZCQubf3A+xbZI Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit In the first draft[1], it was wrapped in a { "patches": [ ... ] } object. This was considered needlessly verbose at the time, leading to the stripping of the object to have the raw array we have today.

Paul

[1] http://tools.ietf.org/html/draft-pbryan-json-patch-00

On Tue, 2012-11-27 at 18:15 +0100, Julian Reschke wrote: 
On 2012-11-27 03:29, Mark Nottingham wrote:
> One thing to note about the format we've chosen for JSON-Patch -- at the top level, it's an array, which has some security implications, according to <http://haacked.com/archive/2009/06/24/json-hijacking.aspx>.
>
> Practically speaking, this means that people shouldn't make Patch files containing sensitive information available through GET on Web servers, even if they're protected by some form of authentication.
>
> Is it sufficient to note this in Security Considerations, or do people want to change the format?
> ...

...like sticking the array into a container; or going back to the old 
format?
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--=-60QMrE7ZCQubf3A+xbZI-- From nico@cryptonector.com Tue Nov 27 14:45: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 7540621F8456 for ; Tue, 27 Nov 2012 14:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 qZIvP0ZSwWGR for ; Tue, 27 Nov 2012 14:45:58 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id C592521F8452 for ; Tue, 27 Nov 2012 14:45:57 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id BC1391E05D for ; Tue, 27 Nov 2012 14:45:56 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 8E1481E05C for ; Tue, 27 Nov 2012 14:45:56 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id un15so9945187pbc.22 for ; Tue, 27 Nov 2012 14:45:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.83.68 with SMTP id o4mr53090672pby.25.1354056355987; Tue, 27 Nov 2012 14:45:55 -0800 (PST) Received: by 10.68.128.234 with HTTP; Tue, 27 Nov 2012 14:45:55 -0800 (PST) In-Reply-To: <1354052447.5145.5.camel@pbryan-wsl.internal.salesforce.com> References: <9337072E-061E-402C-A9E0-F77E8BE1A409@mnot.net> <50B4F54A.1040705@gmx.de> <1354052447.5145.5.camel@pbryan-wsl.internal.salesforce.com> Date: Tue, 27 Nov 2012 16:45:55 -0600 Message-ID: From: Nico Williams To: "Paul C. Bryan" Content-Type: text/plain; charset=UTF-8 Cc: Julian Reschke , Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and XSRF 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, 27 Nov 2012 22:46:00 -0000 On Tue, Nov 27, 2012 at 3:40 PM, Paul C. Bryan wrote: > In the first draft[1], it was wrapped in a { "patches": [ ... ] } object. > This was considered needlessly verbose at the time, leading to the stripping > of the object to have the raw array we have today. Sounds like premature optimization. HTTP is already fairly wasteful. Now for this optimization we get a rather scary-looking security consideration. I'd rather fix the spec to not have this problem, but I understand that it may well be too late. Nico -- From mnot@mnot.net Tue Nov 27 14:51: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 7F8B821F8457 for ; Tue, 27 Nov 2012 14:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.875 X-Spam-Level: X-Spam-Status: No, score=-104.875 tagged_above=-999 required=5 tests=[AWL=-2.276, 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 g68SWXncVTMt for ; Tue, 27 Nov 2012 14:51:08 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id A788E21F8202 for ; Tue, 27 Nov 2012 14:51:04 -0800 (PST) Received: from [192.168.1.75] (unknown [118.209.244.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5792F509B5; Tue, 27 Nov 2012 17:51:01 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Wed, 28 Nov 2012 09:50:57 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <09D9DD31-8764-4B13-9A2E-8061671710A3@mnot.net> References: <9337072E-061E-402C-A9E0-F77E8BE1A409@mnot.net> <50B4F54A.1040705@gmx.de> <1354052447.5145.5.camel@pbryan-wsl.internal.salesforce.com> To: Nico Williams X-Mailer: Apple Mail (2.1499) Cc: Julian Reschke , Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and XSRF 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, 27 Nov 2012 22:51:09 -0000 I've added this to Security Considerations: > Because Web browsers can be coerced into loading an = arbitrary > JSON document whose root is an array, JSON Patch documents > containing sensitive information SHOULD NOT be exposed on = a Web > server (i.e., made available by HTTP GET), even if access = is > authenticated. I think this is adequate, as long as we agree that it'll be uncommon to = need to expose JSON Patch files via HTTP GET. If there is a significant = use case where this is necessary, we should change the format. Regards, On 28/11/2012, at 9:45 AM, Nico Williams wrote: > On Tue, Nov 27, 2012 at 3:40 PM, Paul C. Bryan = wrote: >> In the first draft[1], it was wrapped in a { "patches": [ ... ] } = object. >> This was considered needlessly verbose at the time, leading to the = stripping >> of the object to have the raw array we have today. >=20 > Sounds like premature optimization. HTTP is already fairly wasteful. > Now for this optimization we get a rather scary-looking security > consideration. I'd rather fix the spec to not have this problem, but > I understand that it may well be too late. >=20 > Nico > -- -- Mark Nottingham http://www.mnot.net/ From jasnell@gmail.com Tue Nov 27 15:28: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 9A4431F0C5F for ; Tue, 27 Nov 2012 15:28:00 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAKYqXC9uQXb for ; Tue, 27 Nov 2012 15:27:59 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2D52E21F8557 for ; Tue, 27 Nov 2012 15:27:57 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id l10so17375883oag.22 for ; Tue, 27 Nov 2012 15:27:56 -0800 (PST) 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=CYFZ5xviE3LGIE9KQz/AXQaq8FwNG/tfxRUwh9pE2v4=; b=wPzpVMgu8KtKdpcmHWqCFG4MVNrnyhjV3jUyNFDfkAhSkHqL64xjVtj6ASOsWGF0F7 XdY2JSU7Snisto8FzPJ45jA85DOoY04w7RYRFNwXG+Ff8/6dJFgx8Ocsfi1xOsGWef6h U1nbCv7zjsTBx6f/25myHSW5zVm5RJjJGEwNIDRigvKvD+q1CBHbwWjgy6gmqGkQEEr8 cwxVCS3WXDg+cL4vIG7w1jCJAKZS4UxiJ7zFOPdcRSCkXhIYwUA1AxnCjo4K8dRC1PUs dQRT6p7FnO4K5owARRODMmuue5kAD9UKZc/YawSu8PEaaaqOUXY51SN08mV4IB7nugrh q0/g== Received: by 10.60.172.71 with SMTP id ba7mr8624001oec.50.1354058876520; Tue, 27 Nov 2012 15:27:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.68.37 with HTTP; Tue, 27 Nov 2012 15:27:36 -0800 (PST) In-Reply-To: <09D9DD31-8764-4B13-9A2E-8061671710A3@mnot.net> References: <9337072E-061E-402C-A9E0-F77E8BE1A409@mnot.net> <50B4F54A.1040705@gmx.de> <1354052447.5145.5.camel@pbryan-wsl.internal.salesforce.com> <09D9DD31-8764-4B13-9A2E-8061671710A3@mnot.net> From: James M Snell Date: Tue, 27 Nov 2012 15:27:36 -0800 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=bcaec54c525257092504cf8266cc Cc: Julian Reschke , Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and XSRF 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, 27 Nov 2012 23:28:01 -0000 --bcaec54c525257092504cf8266cc Content-Type: text/plain; charset=UTF-8 Hmm... Right off hand I can think of one use case in particular... albeit one that is entirely hypothetical for me. If, for instance, someone wanted to have an atompub-type collection of patch documents, or expose pending patch documents via a queue of sorts with a RESTful interface. I'm not building such apps so I'm not going to say either of these are critical but they are interesting cases nonetheless. - James On Tue, Nov 27, 2012 at 2:50 PM, Mark Nottingham wrote: > I've added this to Security Considerations: > > > Because Web browsers can be coerced into loading an arbitrary > > JSON document whose root is an array, JSON Patch documents > > containing sensitive information SHOULD NOT be exposed on a > Web > > server (i.e., made available by HTTP GET), even if access is > > authenticated. > > I think this is adequate, as long as we agree that it'll be uncommon to > need to expose JSON Patch files via HTTP GET. If there is a significant use > case where this is necessary, we should change the format. > > Regards, > > > > On 28/11/2012, at 9:45 AM, Nico Williams wrote: > > > On Tue, Nov 27, 2012 at 3:40 PM, Paul C. Bryan wrote: > >> In the first draft[1], it was wrapped in a { "patches": [ ... ] } > object. > >> This was considered needlessly verbose at the time, leading to the > stripping > >> of the object to have the raw array we have today. > > > > Sounds like premature optimization. HTTP is already fairly wasteful. > > Now for this optimization we get a rather scary-looking security > > consideration. I'd rather fix the spec to not have this problem, but > > I understand that it may well be too late. > > > > Nico > > -- > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --bcaec54c525257092504cf8266cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hmm... Right off hand I can think of o= ne use case in particular... albeit one that is entirely hypothetical for m= e. If, for instance, someone wanted to have an atompub-type collection of p= atch documents, or expose pending patch documents via a queue of sorts with= a RESTful interface. I'm not building such apps so I'm not going t= o say either of these are critical but they are interesting cases nonethele= ss.

- James

On Tue, Nov 27, 2012 at 2:50 PM, Mark Nottingha= m <= mnot@mnot.net> wrote:
I've added this to Security Consideratio= ns:

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Because Web browsers can be = coerced into loading an arbitrary
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 JSON document whose root is = an array, JSON Patch documents
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 containing sensitive informa= tion SHOULD NOT be exposed on a Web
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 server (i.e., made available= by HTTP GET), even if access is
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 authenticated.

I think this is adequate, as long as we agree that it'll be uncommon to= need to expose JSON Patch files via HTTP GET. If there is a significant us= e case where this is necessary, we should change the format.

Regards,



On 28/11/2012, at 9:45 AM, Nico Williams <nico@cryptonector.com> wrote:

> On Tue, Nov 27, 2012 at 3:40 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
>> In the first draft[1], it was wrapped in a { "patches": = [ ... ] } object.
>> This was considered needlessly verbose at the time, leading to the= stripping
>> of the object to have the raw array we have today.
>
> Sounds like premature optimization. =C2=A0HTTP is already fairly waste= ful.
> Now for this optimization we get a rather scary-looking security
> consideration. =C2=A0I'd rather fix the spec to not have this prob= lem, but
> I understand that it may well be too late.
>
> Nico
> --

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



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

--bcaec54c525257092504cf8266cc-- From James.H.Manger@team.telstra.com Tue Nov 27 16:08: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 930AF21E803A for ; Tue, 27 Nov 2012 16:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 Ta0PS-bJJAGF for ; Tue, 27 Nov 2012 16:08:58 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2F321E8030 for ; Tue, 27 Nov 2012 16:08:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,330,1352034000"; d="scan'208,217";a="103680574" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 28 Nov 2012 11:08:55 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="100639642" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcbni.tcif.telstra.com.au with ESMTP; 28 Nov 2012 11:08:55 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Wed, 28 Nov 2012 11:08:55 +1100 From: "Manger, James H" To: Mark Nottingham , Nico Williams Date: Wed, 28 Nov 2012 11:08:54 +1100 Thread-Topic: [apps-discuss] JSON-Patch and XSRF Thread-Index: Ac3M8bfEGCwgeke3T5GOncPXpYq3pgAADgYw Message-ID: <255B9BB34FB7D647A506DC292726F6E1150252BB74@WSMSG3153V.srv.dir.telstra.com> References: <9337072E-061E-402C-A9E0-F77E8BE1A409@mnot.net> <50B4F54A.1040705@gmx.de> <1354052447.5145.5.camel@pbryan-wsl.internal.salesforce.com> <09D9DD31-8764-4B13-9A2E-8061671710A3@mnot.net> In-Reply-To: <09D9DD31-8764-4B13-9A2E-8061671710A3@mnot.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Julian Reschke , Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and XSRF 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, 28 Nov 2012 00:08:59 -0000 QSBiZXR0ZXIgcGxhY2UgZm9yIHRoaXMgd291bGQgYnkgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zIHNlY3Rpb24gb2YgKGFuIHVwZGF0ZWQpIFJGQyA0NjI3IEpTT04uDQoNClRoYXQgIkpTT04g aGlqYWNraW5nIiBhcnRpY2xlIGlzIGZyb20gMi41IHllYXJzIGFnbyA8aHR0cDovL2hhYWNrZWQu Y29tL2FyY2hpdmUvMjAwOS8wNi8yNC9qc29uLWhpamFja2luZy5hc3B4Pi4gVGhlcmUgaXMgYSBk ZWNlbnQgY2hhbmNlIGl0IGRvZXNuJ3Qgd29yayBpbiBjdXJyZW50IGJyb3dzZXJzLiBJdCBtYXkg YWxzbyBiZSBmaXhlZCBpbiBFY21hU2NyaXB0NS4NCg0KV2l0aCBhIHZlcnkgcXVpY2sgdHJ5IEkg Y291bGRuJ3QgZ2V0IHRoZSBhdHRhY2sgdG8gd29yayBpbiBGaXJlZm94ICh3aGljaCBhcHBhcmVu dGx5IGV4cGxpY2l0bHkgZml4ZWQgaXQpIG9yIENocm9tZSBvciBJRSAod2hpY2ggYXBwYXJlbnRs eSBuZXZlciBzdXBwb3J0ZWQgdGhlIGZlYXR1cmVzIHRoYXQgdGhlIGJ1ZyBleHBsb2l0cykuDQoN CkkgZGlkIG5vdGljZSwgdGhvdWdoLCB0aGF0IGFsbCAzIGJyb3dzZXJzIHNpbGVudGx5IGFjY2Vw dGVkIGEgSlNPTiBhcnJheSBhcyBKYXZhU2NyaXB0LCB3aGlsZSBhbGwgMyBkaXNwbGF5ZWQgYW4g ZXJyb3IgbWVzc2FnZSAob24gdGhlaXIgZGVidWdnaW5nIGNvbnNvbGVzKSB3aGVuIHRyeWluZyB0 byBpbnRlcnByZXQgYSBKU09OIG9iamVjdCBhcyBKYXZhU2NyaXB0LiBUaGF0IGlzIGFsbW9zdCBz dWZmaWNpZW50IHRvIHNjYXJlIG1lIG9mZiB1c2luZyBhIHRvcC1sZXZlbCBKU09OIGFycmF5LCBz aW5jZSBhbiBhcnJheSB2YWx1ZSBhcHBlYXJzIHRvIG1ha2UgaXQgaW50byB0aGUgYnJvd3NlciBl eGVjdXRpb24gZW52aXJvbm1lbnQgYW5kIHlvdSBoYXZlIHRvIGhvcGUgaXQgY2Fubm90IGJlIGV4 dHJhY3RlZC4NCg0KDQpJIGRvbid0IHRoaW5rIHRoZSBwcm9wb3NlZCBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyB0ZXh0IGlzIGEgZ29vZCBhcHByb2FjaC4gSWYgdG8gYmUgc2FmZSB3aXRoIHVwLXRv LWRhdGUgYnJvd3NlcnMsIGEgc2VydmVyIHJlYWxseSAiU0hPVUxEIE5PVCBhbGxvdyAoYXV0aGVu dGljYXRlZCkgR0VUIHJlcXVlc3RzIHRvIHJldHVybiBhIEpTT04gYXJyYXkgd2l0aCBub24tcHVi bGljIGRhdGEiIHRoZW4gSSB0aGluayB3ZSBkbyAodmVyeSByZWdyZXR0YWJseSkgbmVlZCB0byBj aGFuZ2UgdGhlIGZvcm1hdCAtLSBhbmQgcHJvYmFibHkgYSBidW5jaCBvZiBvdGhlciBKU09OIGZv cm1hdHMgYXMgd2VsbC4gTm90IGFsbG93aW5nIHNlcnZlcnMgdG8gc2FmZWx5IHB1Ymxpc2ggSlNP Ti1QYXRjaCB2YWx1ZXMgaXMgdG9vIGhpZ2ggYSBidXJkZW4uDQoNCk9uIHRoZSBvdGhlciBoYW5k LCBpZiB0aGlzIGhpamFja2luZyBpcyBubyBsb25nZXIgYW4gaXNzdWUgd2l0aCB1cC10by1kYXRl IGJyb3dzZXJzLCB0aGVuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHRleHQgbm90aW5nIHRoYXQg YSBKU09OIGFycmF5IGlzIGEgdmFsaWQgKHRob3VnaCBwb2ludGxlc3MpIEphdmFTY3JpcHQgUHJv Z3JhbSBjb3VsZCBiZSBpbmNsdWRlZC4gVGhpcyBpcyByZWFsbHkgYSB3YXJuaW5nIHRvIEphdmFT Y3JpcHQgZW5naW5lIGRldmVsb3BlcnMgdG8gYmUgY2FyZWZ1bC4gVGhpcyBpcyBteSBwcmVmZXJy ZWQgcmVzdWx0Lg0KDQoNCkNhbiBhbnlvbmUgd2l0aCBtb3JlIEphdmFTY3JpcHQgbW9qbyBjb25m aXJtIHRoYXQgPHNjcmlwdCBzcmM9ImFycmF5Lmpzb24iPiBubyBsb25nZXIgZXhwb3NlcyB0aGUg ZGF0YSB0byBvdGhlciBzY3JpcHQgb24gdGhlIHBhZ2U/DQoNCi0tDQpKYW1lcyBNYW5nZXINCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy0NCj4gYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIE1hcmsgTm90dGluZ2hhbQ0KPiBTZW50OiBXZWRuZXNkYXksIDI4IE5vdmVtYmVy IDIwMTIgOTo1MSBBTQ0KPiBUbzogTmljbyBXaWxsaWFtcw0KPiBDYzogSnVsaWFuIFJlc2Noa2U7 IEFwcHMgRGlzY3Vzcw0KPiBTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gSlNPTi1QYXRjaCBh bmQgWFNSRg0KPiANCj4gSSd2ZSBhZGRlZCB0aGlzIHRvIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z Og0KPiANCj4gPiAgICAgICAgQmVjYXVzZSBXZWIgYnJvd3NlcnMgY2FuIGJlIGNvZXJjZWQgaW50 byBsb2FkaW5nIGFuIGFyYml0cmFyeQ0KPiA+ICAgICAgICBKU09OIGRvY3VtZW50IHdob3NlIHJv b3QgaXMgYW4gYXJyYXksIEpTT04gUGF0Y2ggZG9jdW1lbnRzDQo+ID4gICAgICAgIGNvbnRhaW5p bmcgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIFNIT1VMRCBOT1QgYmUgZXhwb3NlZCBvbiBhIFdlYg0K PiA+ICAgICAgICBzZXJ2ZXIgKGkuZS4sIG1hZGUgYXZhaWxhYmxlIGJ5IEhUVFAgR0VUKSwgZXZl biBpZiBhY2Nlc3MgaXMNCj4gPiAgICAgICAgYXV0aGVudGljYXRlZC4NCj4gDQo+IEkgdGhpbmsg dGhpcyBpcyBhZGVxdWF0ZSwgYXMgbG9uZyBhcyB3ZSBhZ3JlZSB0aGF0IGl0J2xsIGJlIHVuY29t bW9uIHRvDQo+IG5lZWQgdG8gZXhwb3NlIEpTT04gUGF0Y2ggZmlsZXMgdmlhIEhUVFAgR0VULiBJ ZiB0aGVyZSBpcyBhIHNpZ25pZmljYW50DQo+IHVzZSBjYXNlIHdoZXJlIHRoaXMgaXMgbmVjZXNz YXJ5LCB3ZSBzaG91bGQgY2hhbmdlIHRoZSBmb3JtYXQuDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4g DQo+IA0KPiBPbiAyOC8xMS8yMDEyLCBhdCA5OjQ1IEFNLCBOaWNvIFdpbGxpYW1zIDxuaWNvQGNy eXB0b25lY3Rvci5jb20+IHdyb3RlOg0KPiANCj4gPiBPbiBUdWUsIE5vdiAyNywgMjAxMiBhdCAz OjQwIFBNLCBQYXVsIEMuIEJyeWFuIDxwYnJ5YW5AYW5vZGUuY2E+DQo+IHdyb3RlOg0KPiA+PiBJ biB0aGUgZmlyc3QgZHJhZnRbMV0sIGl0IHdhcyB3cmFwcGVkIGluIGEgeyAicGF0Y2hlcyI6IFsg Li4uIF0gfQ0KPiBvYmplY3QuDQo+ID4+IFRoaXMgd2FzIGNvbnNpZGVyZWQgbmVlZGxlc3NseSB2 ZXJib3NlIGF0IHRoZSB0aW1lLCBsZWFkaW5nIHRvIHRoZQ0KPiA+PiBzdHJpcHBpbmcgb2YgdGhl IG9iamVjdCB0byBoYXZlIHRoZSByYXcgYXJyYXkgd2UgaGF2ZSB0b2RheS4NCj4gPg0KPiA+IFNv dW5kcyBsaWtlIHByZW1hdHVyZSBvcHRpbWl6YXRpb24uICBIVFRQIGlzIGFscmVhZHkgZmFpcmx5 IHdhc3RlZnVsLg0KPiA+IE5vdyBmb3IgdGhpcyBvcHRpbWl6YXRpb24gd2UgZ2V0IGEgcmF0aGVy IHNjYXJ5LWxvb2tpbmcgc2VjdXJpdHkNCj4gPiBjb25zaWRlcmF0aW9uLiAgSSdkIHJhdGhlciBm aXggdGhlIHNwZWMgdG8gbm90IGhhdmUgdGhpcyBwcm9ibGVtLCBidXQNCj4gPiBJIHVuZGVyc3Rh bmQgdGhhdCBpdCBtYXkgd2VsbCBiZSB0b28gbGF0ZS4NCj4gPg0KPiA+IE5pY28NCj4gPiAtLQ0K PiANCj4gLS0NCj4gTWFyayBOb3R0aW5naGFtICAgaHR0cDovL3d3dy5tbm90Lm5ldC8NCj4gDQo+ IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdA0KPiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCg== From Michael.Jones@microsoft.com Tue Nov 27 16:12: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 3206921F866F for ; Tue, 27 Nov 2012 16:12:38 -0800 (PST) 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 uluKPAnWzuyI for ; Tue, 27 Nov 2012 16:12:36 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 95F4921F8650 for ; Tue, 27 Nov 2012 16:12:36 -0800 (PST) Received: from mail163-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 28 Nov 2012 00:12:36 +0000 Received: from mail163-tx2 (localhost [127.0.0.1]) by mail163-tx2-R.bigfish.com (Postfix) with ESMTP id F188E1E0179; Wed, 28 Nov 2012 00:12:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VS-25(zz98dI9371Id6eah542M1432I4015Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h) Received-SPF: pass (mail163-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=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail163-tx2 (localhost.localdomain [127.0.0.1]) by mail163-tx2 (MessageSwitch) id 1354061553842972_15182; Wed, 28 Nov 2012 00:12:33 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.242]) by mail163-tx2.bigfish.com (Postfix) with ESMTP id BEE4722004D; Wed, 28 Nov 2012 00:12:33 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 28 Nov 2012 00:12:33 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Wed, 28 Nov 2012 00:12:32 +0000 From: Mike Jones To: Tim Bray , "Paul E. Jones" Thread-Topic: [apps-discuss] draft-ietf-appsawg-webfinger-04 Thread-Index: Ac3IZUHlvzxVCcoNRf2fQF9+Sjr6pwBfojYAAMQytxA= Date: Wed, 28 Nov 2012 00:12:31 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436690502B@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <013e01cdc867$caf54230$60dfc690$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 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, 28 Nov 2012 00:12:38 -0000 Thanks, Tim, for this fresh read. I wanted to write and specifically agree= with a number of them and comment on a few. In fact, I agree with all of = them, other than where noted. My comments are interspersed below, prefixed= by "Mike>". Thanks, -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Tim Bray Sent: Friday, November 23, 2012 5:34 PM To: Paul E. Jones Cc: webfinger@googlegroups.com; apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-webfinger-04 Notes on draft-ietf-appsawg-webfinger-04.txt Sorry for coming late to the party. This the first webfinger draft that I'v= e ever read, and I'm almost completely ignorant of the history. Having sai= d that, sometimes a history-free pair of eyes looking at something can add = value. [1. Introduction. ] Suggest shortening up, omitting the history, losing the whole first para an= d beginning the second "Webfinger uses the HTTP protocol to retrieve a stru= ctured document containing link relations that describe people or other ent= ities on the Internet. For a person... Mike> Agreed - less is more here [para 2] "direct human consumption (e.g., looking up someone's phone numbe= r), or..." [4. Example use of WebFinger] Tighten up 1st sentence: "This section shows = a few sample uses of Webfinger." [4.1 Locating a User's Blog] What is the benefit of the "aliases" field? Mike> Expanding on this, I don't understand the need for either the "aliase= s" or "properties" parameters. I'd omit them. Keep "links", "rel", "type"= , and "href". (This was discussed on yesterday's OpenID Connect call, and = Tim and others felt that the WebFinger spec should define the meanings of t= he fields used. Yes, this would mean copying some text from the XRD spec, = but then at least the WebFinger spec could be read in a self-contained fash= ion. And yes, this is a change of position for me. :-) ) What is the benefit of the "acct" URI scheme? Couldn't "mailto:" have been= used in this case? Mike> I'm OK with keeping the acct: usage, provided that the acct: URI sche= me makes timely progress. I value the conceptual distinction from mailto:,= since acct:selfissued@twitter.com is a legitimate account identifier, but = not an e-mail address. (Tim, see http://tools.ietf.org/html/draft-ietf-app= sawg-acct-uri-01, if you haven't already.) [4.2 Identity Provider Discovery...] Since the "rel" parameter is optional and you can't count on it, providing = it is strictly a client-suggested optimization? Feels quite likely to be p= remature, to me. Mike> I disagree with this comment. "rel" is valuable to narrow down what= 's returned in the case that you know what you're looking for (which you us= ually do!). I do think, though that this sentence needs to be added after = the one about support being "OPTIONAL, but RECOMMENDED": "Should the serve= r not support the "rel" parameter, it MUST ignore it and process the reques= t as if any "rel" parameter values were not present." That way it's clear = that clients are free to safely use it even when servers may not support it= . In particular, I'm thinking of my own small-scale domains like textuality.c= om and tbray.org, which have a single-digit number of accounts. I could dr= op static JRD files into a small number of files with names like /.well-kno= wn/webfinger?resource=3Dmailto:tbray@textuality.com and do webfinger very c= heaply. The existence of the "rel" parameter means I can't solve this probl= em statically. [4.4 Retrieving Device Information] I have to say this feels fanciful. Any time an example requires inventing a= new URI scheme, I suggest that's a symptom of trying too hard. [5.1, first para] I hate to be pedantic, but when you say "parameter", you're talking about t= he &-separated name-value pairs in the "query" [RFC3986] part of a URI. Fi= ne enough, and it's a common usage, but I don't actually know where it's de= fined (not in 3986) so either we need to find a definition and link to it, = or invest a paragraph in saying what you mean [5.1] "WebFinger servers MUST return JRD documents as the default represent= ation..." What does "default" mean? Are we saying that servers MUST return= JRD? If so, say so. Mike> Agreed. Delete the words "as the default representation". [5.1] Last two paragraphs are perhaps superfluous? Since it's HTTP, don't = you get this for free? Mike> I think these paragraphs are possibly valuable to implementers, even= if superfluous. Maybe reference 2616 in the first one as well and change = "MAY" to "can" in the second, making it clear that this is not new normativ= e text, but simply an implementation remark. [5.2] "Any array elements within the "links" array are presented by the ser= ver in order of preference." Huh? Don't understand. [5.2] "The "template" element is forbidden"? Huh? The spec doesn't define= any semantic for this element. You probably need a policy on unknown fields. For example: (a) "Software must ignore any fields found in the JRD which are not specifi= ed here" (a.k.a. MUST_IGNORE) (b) "It is forbidden for any elements not specified here to appear in a JRD= " (a.k.a. maximally brittle) The special processing for "template" is just = weird. If it's required for some good reason, give the reason. [5.2] The fact that "titles" is allowed but has no specified semantics is t= roublesome. Explain or remove? [5.2] The fact there is no discussion of what you might use "properties" fo= r, nor any discussion of its structure, is troublesome. Do we have actual users of this? Explain or remove? [5.3] "The purpose of the "rel" parameter is to return a subset of resource= 's link relations. It is not intended to reduce the work" Could this be motivated a bit? Why would you want a subset, aside from red= ucing the work? Mike> Reducing bandwidth and latency is one reason. Discovery is likely to= be in the critical path of some user interface display actions, so latency= matters. [5.3] The restated example doesn't really add value here, I think. How the = "rel" parameter works is simple enough. [5.4] Two problems: First, this section fails to convince me that the "acct= " scheme is worth the effort. Second, the section could simply say that the= URI used to identify the entity being queried is not tied to any scheme; t= he arm-waving about the hypothetical wonderfulnesss of "acct:" is a waste o= f space. Then having done that, the section could be replaced by a one-lin= e note in section 5.1 Mike> I'd leave the acct: text, pending the disposition of http://tools.ie= tf.org/html/draft-ietf-appsawg-acct-uri-01 hopefully becoming clear soon. [5.5] Really? Do we have any hard data that convinces us that there's an i= nteresting class of organizations that (a) want to offer WebFinger and (b) = can't access their root and (c) can easily set up a subdomain? Mike> Per private threads with Google, who first identified this need for = OpenID 2.0 several years ago, apparently Google is willing to back off on t= his requirement (per Tim's note earlier today). [6] "Enterprise"?! What does that word mean? Also there's a contradiction = between the sentence saying you have to use "*" and the next paragraph sayi= ng something more restrictive is OK. Might it be better to just say "WebFi= nger may not be usable from code running in browsers due to Origin policies= ; therefore, the use of CORS headers is required. The header "Access-Contro= l-Allow-Origin: * " will maximize usability; certain organizations may wish= to control access to WebFinger with a more restrictive Access-Control-Allo= w-Origin value. [7. Access Control] This section could be dropped, or replaced with a short paragraph noting th= at since WebFinger is based on HTTP, implementors will need to deal with th= e possibility that the origin server may impose access control policies or = simply refuse access. Mike> Agree that this could be tightened, but I disagree that it should be= dropped. This was added a few drafts ago to counter the perceptions that = everything served by WebFinger must be public. [8.] This section could be dropped. This is an HTTP-based service and we = can assume that implementors should be prepared to handle HTTP-standard red= irect semantics. Mike> I'd start by trying to replace this with a few tightly written sente= nces about standard HTTP redirect semantics applying. The caution about not redirecting to a /.well-known somewhere else seems of= questionable value, since I might actually want to have a common webfinger= which returns the same values for any X whether it's X@example.com, X@exam= ple.net, or whatever, and I could do that efficiently by having a /.well-kn= own on one of them and redirecting to it from the others. >Mike> I agree that the caution about where the service URL should point i= s misguided and should be deleted. On Wed, Nov 21, 2012 at 8:13 PM, Paul E. Jones wrot= e: > Folks, > > > > I just posted a new draft that takes into consideration the input I=20 > received on -03 and adds the "webfinger" subdomain that was discussed=20 > on the list this past week. Specifically, here's what changed: > > * Mention in section 2 that WebFinger uses the "rel" attribute an= d > provide a reference to the IANA registry for link relations > > * Deleted the second paragraph from section 3 that expands on li= nk > relations > > * Changed the link relation value for "blog" to be just the token > "blog" > > * Corrected a syntax error in the example in 4.1 > > * Clarified in section 4.1 what is meant by a "valid alias" > > * Introduced a new section 4.2 that shows an example for OpenID > Connect > > * Changed the rel types in 4.3 and 4.4 to be URI-based (on > example.net) > > * Corrected syntax in 5.3 and added two clarifying sentences > > * Introduced a new section 5.5 that describes the "webfinger" > subdomain > > * Changed the name of section 7 > > * Added language to section 8 to support section 5.5 > > * Added language to section 9 to support section 5.5 > > * Spells out Mike's name as he prefers it > > * Added a couple of informational references > > > > The new draft is here: > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-04 > > > > I think we're getting closer, though I know the "webfinger" subdomain=20 > might be a bit controversial. I'm on the fence on this one, myself. =20 > I can see the pros and cons of having it. I'd prefer to stay out of=20 > the debate, though. I'll put into the document whatever the group=20 > says to put into the documents :-) That said, I think Mike made a=20 > valid argument with respect to the fact that some domain owners have=20 > no ability to do anything more than insert an A record for a subdomain. > > > > I do want to highlight the fact that the current language says that if=20 > there is any response from a web server at the host, that means the=20 > host does have the capability of providing WF services and the=20 > "webfinger" subdomain should not be consulted. Thus, the webfinger=20 > subdomain would only be consulted if there is no web server running at=20 > the host at all. It's not a fallback for domain owners who have a web se= rver, but just didn't install a WF server. > For that case, they should use 3xx redirection for hosting the WF=20 > server elsewhere. > > > > Paul > > > > > _______________________________________________ > 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 James.H.Manger@team.telstra.com Tue Nov 27 16:59: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 9786421F8794 for ; Tue, 27 Nov 2012 16:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 0+SMMBRIEUZH for ; Tue, 27 Nov 2012 16:59:02 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id C02B721F8793 for ; Tue, 27 Nov 2012 16:59:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,331,1352034000"; d="scan'208";a="105260896" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 28 Nov 2012 11:58:58 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="99568096" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcbvi.tcif.telstra.com.au with ESMTP; 28 Nov 2012 11:58:58 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Wed, 28 Nov 2012 11:58:58 +1100 From: "Manger, James H" To: Apps Discuss Date: Wed, 28 Nov 2012 11:58:56 +1100 Thread-Topic: [apps-discuss] JSON-Patch and XSRF Thread-Index: Ac3M8bfEGCwgeke3T5GOncPXpYq3pgAADgYwAAOkwQA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1150252BCFB@WSMSG3153V.srv.dir.telstra.com> References: <9337072E-061E-402C-A9E0-F77E8BE1A409@mnot.net> <50B4F54A.1040705@gmx.de> <1354052447.5145.5.camel@pbryan-wsl.internal.salesforce.com> <09D9DD31-8764-4B13-9A2E-8061671710A3@mnot.net> <255B9BB34FB7D647A506DC292726F6E1150252BB74@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150252BB74@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] JSON-Patch and XSRF 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, 28 Nov 2012 00:59:02 -0000 Q3VyaW91c2x5LCBhIEpTT04gb2JqZWN0IHRoYXQgZm9yZ2V0cyB0byBxdW90ZSBhIG5hbWUgY2Fu IGJlIGEgdmFsaWQgSmF2YVNjcmlwdCBwcm9ncmFtLg0KICB7IGlkOlsyLDMsNSw3LDExXSB9DQoN ClRoaXMgaXMgbm90IHZhbGlkIEpTT04gKGl0IHNob3VsZCBiZSB7ICJpZCI6WzIsMyw1LDcsMTFd IH0pLCBidXQgSSB3b3VsZG4ndCBiZSBzdXJwcmlzZWQgaWYgbWFueSBKU09OIHBhcnNlcnMgd2Vy ZSBsZW5pZW50IGluIGFjY2VwdGluZyBuYW1lcyB3aXRob3V0IHF1b3Rlcy4gV2hlbiB0cmVhdGVk IGFzIGEgSmF2YVNjcmlwdCBwcm9ncmFtIHRoZSB1bnF1b3RlZCBuYW1lIGlzIHBhcnNlZCBhcyBh IGxhYmVsIGFuZCB0aGUgcmVzdWx0IGlzIGFzIHZ1bG5lcmFibGUgYXMgYSByYXcgSlNPTiBhcnJh eSB0byAiaGlqYWNraW5nIi4gQ2hhbmdpbmcgZm9ybWF0cyBmcm9tIGFuIGFycmF5IHRvIGFuIG9i amVjdCBtaWdodCBub3QgYnV5IHF1aXRlIGFzIG11Y2ggc2FmZXR5IGFzIGhvcGVkLg0KDQotLQ0K SmFtZXMgTWFuZ2VyDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBh cHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy0NCj4gYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hbmdlciwgSmFtZXMgSA0KPiBTZW50OiBXZWRu ZXNkYXksIDI4IE5vdmVtYmVyIDIwMTIgMTE6MDkgQU0NCj4gVG86IE1hcmsgTm90dGluZ2hhbTsg TmljbyBXaWxsaWFtcw0KPiBDYzogSnVsaWFuIFJlc2Noa2U7IEFwcHMgRGlzY3Vzcw0KPiBTdWJq ZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gSlNPTi1QYXRjaCBhbmQgWFNSRg0KPiANCuKApg0KPiBJ IGRpZCBub3RpY2UsIHRob3VnaCwgdGhhdCBhbGwgMyBicm93c2VycyBzaWxlbnRseSBhY2NlcHRl ZCBhIEpTT04NCj4gYXJyYXkgYXMgSmF2YVNjcmlwdCwgd2hpbGUgYWxsIDMgZGlzcGxheWVkIGFu IGVycm9yIG1lc3NhZ2UgKG9uIHRoZWlyDQo+IGRlYnVnZ2luZyBjb25zb2xlcykgd2hlbiB0cnlp bmcgdG8gaW50ZXJwcmV0IGEgSlNPTiBvYmplY3QgYXMNCj4gSmF2YVNjcmlwdC4gVGhhdCBpcyBh bG1vc3Qgc3VmZmljaWVudCB0byBzY2FyZSBtZSBvZmYgdXNpbmcgYSB0b3AtbGV2ZWwNCj4gSlNP TiBhcnJheSwgc2luY2UgYW4gYXJyYXkgdmFsdWUgYXBwZWFycyB0byBtYWtlIGl0IGludG8gdGhl IGJyb3dzZXINCj4gZXhlY3V0aW9uIGVudmlyb25tZW50IGFuZCB5b3UgaGF2ZSB0byBob3BlIGl0 IGNhbm5vdCBiZSBleHRyYWN0ZWQuDQo+IA0KPiANCj4gSSBkb24ndCB0aGluayB0aGUgcHJvcG9z ZWQgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgdGV4dCBpcyBhIGdvb2QNCj4gYXBwcm9hY2guIElm IHRvIGJlIHNhZmUgd2l0aCB1cC10by1kYXRlIGJyb3dzZXJzLCBhIHNlcnZlciByZWFsbHkNCj4g IlNIT1VMRCBOT1QgYWxsb3cgKGF1dGhlbnRpY2F0ZWQpIEdFVCByZXF1ZXN0cyB0byByZXR1cm4g YSBKU09OIGFycmF5DQo+IHdpdGggbm9uLXB1YmxpYyBkYXRhIiB0aGVuIEkgdGhpbmsgd2UgZG8g KHZlcnkgcmVncmV0dGFibHkpIG5lZWQgdG8NCj4gY2hhbmdlIHRoZSBmb3JtYXQgLS0gYW5kIHBy b2JhYmx5IGEgYnVuY2ggb2Ygb3RoZXIgSlNPTiBmb3JtYXRzIGFzDQo+IHdlbGwuIE5vdCBhbGxv d2luZyBzZXJ2ZXJzIHRvIHNhZmVseSBwdWJsaXNoIEpTT04tUGF0Y2ggdmFsdWVzIGlzIHRvbw0K PiBoaWdoIGEgYnVyZGVuLg0KPiANCj4gT24gdGhlIG90aGVyIGhhbmQsIGlmIHRoaXMgaGlqYWNr aW5nIGlzIG5vIGxvbmdlciBhbiBpc3N1ZSB3aXRoIHVwLXRvLQ0KPiBkYXRlIGJyb3dzZXJzLCB0 aGVuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHRleHQgbm90aW5nIHRoYXQgYSBKU09ODQo+IGFy cmF5IGlzIGEgdmFsaWQgKHRob3VnaCBwb2ludGxlc3MpIEphdmFTY3JpcHQgUHJvZ3JhbSBjb3Vs ZCBiZQ0KPiBpbmNsdWRlZC4gVGhpcyBpcyByZWFsbHkgYSB3YXJuaW5nIHRvIEphdmFTY3JpcHQg ZW5naW5lIGRldmVsb3BlcnMgdG8NCj4gYmUgY2FyZWZ1bC4gVGhpcyBpcyBteSBwcmVmZXJyZWQg cmVzdWx0Lg0KPiANCj4gDQo+IENhbiBhbnlvbmUgd2l0aCBtb3JlIEphdmFTY3JpcHQgbW9qbyBj b25maXJtIHRoYXQgPHNjcmlwdA0KPiBzcmM9ImFycmF5Lmpzb24iPiBubyBsb25nZXIgZXhwb3Nl cyB0aGUgZGF0YSB0byBvdGhlciBzY3JpcHQgb24gdGhlDQo+IHBhZ2U/DQo+IA0KPiAtLQ0KPiBK YW1lcyBNYW5nZXINCg== From pbryan@anode.ca Tue Nov 27 17:10: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 4727021F84C4 for ; Tue, 27 Nov 2012 17:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] 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 OMmFKzqLzwX2 for ; Tue, 27 Nov 2012 17:10:55 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 38CF821F84BC for ; Tue, 27 Nov 2012 17:10:55 -0800 (PST) Received: from [10.27.5.153] (unknown [64.79.144.7]) by maple.anode.ca (Postfix) with ESMTPSA id 262FF6450; Wed, 28 Nov 2012 01:10:52 +0000 (UTC) Message-ID: <1354065050.3059.7.camel@polyglot> From: "Paul C. Bryan" To: "Manger, James H" Date: Tue, 27 Nov 2012 17:10:50 -0800 In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150252BCFB@WSMSG3153V.srv.dir.telstra.com> References: <9337072E-061E-402C-A9E0-F77E8BE1A409@mnot.net> <50B4F54A.1040705@gmx.de> <1354052447.5145.5.camel@pbryan-wsl.internal.salesforce.com> <09D9DD31-8764-4B13-9A2E-8061671710A3@mnot.net> <255B9BB34FB7D647A506DC292726F6E1150252BB74@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1150252BCFB@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="=-exb3BIX8j1LYmcgqMXj/" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Cc: Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and XSRF 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, 28 Nov 2012 01:10:57 -0000 --=-exb3BIX8j1LYmcgqMXj/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit I'm reticent to address what is clearly a security concern with browser implementations by modifying our specification with the proposed object-instead-of-array workaround. The JSON Patch specification doesn't address how the patch document is processed, save for mentioning that it's intended at least to support HTTP PATCH, which is not susceptible to the outlined CSRF attack. If this attack can be demonstrated with modern browsers, I think it's probably worthy of mention under security considerations. Paul On Wed, 2012-11-28 at 11:58 +1100, Manger, James H wrote: > Curiously, a JSON object that forgets to quote a name can be a valid JavaScript program. > { id:[2,3,5,7,11] } > > This is not valid JSON (it should be { "id":[2,3,5,7,11] }), but I wouldn't be surprised if many JSON parsers were lenient in accepting names without quotes. When treated as a JavaScript program the unquoted name is parsed as a label and the result is as vulnerable as a raw JSON array to "hijacking". Changing formats from an array to an object might not buy quite as much safety as hoped. > > -- > James Manger > > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of Manger, James H > > Sent: Wednesday, 28 November 2012 11:09 AM > > To: Mark Nottingham; Nico Williams > > Cc: Julian Reschke; Apps Discuss > > Subject: Re: [apps-discuss] JSON-Patch and XSRF > > > … > > I did notice, though, that all 3 browsers silently accepted a JSON > > array as JavaScript, while all 3 displayed an error message (on their > > debugging consoles) when trying to interpret a JSON object as > > JavaScript. That is almost sufficient to scare me off using a top-level > > JSON array, since an array value appears to make it into the browser > > execution environment and you have to hope it cannot be extracted. > > > > > > I don't think the proposed Security Considerations text is a good > > approach. If to be safe with up-to-date browsers, a server really > > "SHOULD NOT allow (authenticated) GET requests to return a JSON array > > with non-public data" then I think we do (very regrettably) need to > > change the format -- and probably a bunch of other JSON formats as > > well. Not allowing servers to safely publish JSON-Patch values is too > > high a burden. > > > > On the other hand, if this hijacking is no longer an issue with up-to- > > date browsers, then Security Considerations text noting that a JSON > > array is a valid (though pointless) JavaScript Program could be > > included. This is really a warning to JavaScript engine developers to > > be careful. This is my preferred result. > > > > > > Can anyone with more JavaScript mojo confirm that
=

On Thu, Nov 22, 2012 at 6:16 PM, Larry M= asinter <masinter@adobe.com> wrote:

Negotiating c= ontrolled vocabularies is a difficult course. =E2=80=9Cnarrow=E2=80=9D, =E2= =80=9Cunambiguous=E2=80=9D, =E2=80=9Cclear semantics=E2=80=9D, =E2=80=9Cgua= rantee interop=E2=80=9D are great aspirations, but ultimately impossible. A= mbiguity is intrinsic.

=C2=A0

=E2=80=9Cminimize a= mbiguity=E2=80=9D, =E2=80=9Cwell-documented semantics=E2=80=9D and =E2=80= =9Cpromote interoperability=E2=80=9D would be more realistic.=

=C2=A0

Applications will u= se link relations, and some applications will apply specialized meaning to = a link relation that other applications will not.

=C2=A0

<= /div>

Agreed... what I'm going fo= r more here is modeling "good behavior". Applications have the op= tion of using registered link relations or extension link relations. If a l= ink rel needs to be very specific to a particular kind of resource, then we= should encourage applications to use extension link rels in the form of ab= solute URIs. Obviously this isn't something that can be strictly enforc= ed but we can, at the very least, set a good example.=C2=A0

- James
=C2=A0

=E2=80=9CThe link relati= on registry should be maintained, such that documentation for applications = that rely on particular link relations are easy to find from the link relat= ion registry=E2=80=9D.

=C2=A0

=C2=A0

=C2=A0

From: ap= ps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Be= half Of Goix Laurent Walter
Sent: Tuesday, November 20, 2012 5:39 AM
To: Paul E. Jones= ; 'James M Snell'; 'Dick Hardt'


Cc: webfinger@googlegroups.com; 'IETF Apps Discuss'
Subject: [apps-discuss] Link rels

=C2=A0

<= p class=3D"MsoNormal">+1 for narrow & unambi= guous rels with clear semantics that guarantee interop (btw I think we are = deriving from the core webfinger discussion here so I changed the subject)<= u>

=C2=A0

The link rels propo= sed by james in the draft are meaningful (I do have some doubts on about vs= related, which is already registered). =E2=80=9Cavatar=E2=80=9D could be a= dded there in case the draft can serve as basis for this activity.

=C2=A0

For =E2=80=9Cupdate= s-from=E2=80=9D indeed these are specific to activity streams represented i= n atom, and should not vary their meaning (besides a type parameter which c= ould allow for json as well): for this reason the reference to activitystre= ams could be stronger imo. maybe =E2=80=9Cactivities=E2=80=9D?

=C2=A0

walter

=C2=A0

Da: apps-discuss-= bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di Paul E. Jones
Inviato: marted=C3=AC 20 novembre 2012 6.01
A: 'James = M Snell'; 'Dick Hardt'
Cc: webfinger@googlegroups.com; '= IETF Apps Discuss'
Oggetto: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt<= u>

=C2=A0

James,

=C2=A0

I think the =E2=80= =9Cupdates-from=E2=80=9D was intended to be an ATOM feed, though I might be= wrong.=C2=A0 In your example, you show a blog.=C2=A0 But, at the same time= we want to define =E2=80=9Cblog=E2=80=9D as its own rel.

=C2=A0

I think it=E2=80=99= s important that we have a very narrow scope for any rel.=C2=A0 I don=E2=80= =99t care what the values are, but we need to ensure there is no ambiguity = in what a given token means.

=C2=A0

Paul<= /span>

=C2=A0

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, November 19, 2012 12:36 PM
To: Dick HardtCc: Paul E. Jones; webfinger@googlegroups.com; IETF Apps Discuss
Sub= ject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt=

=C2=A0

Just a quick not= e on this... I already have the existing "Additional Link Relations&qu= ot; draft [1] in progress (currently submitted as an independent submission= ) that registers link relations such as "about", "type"= , "terms-of-service", "privacy-policy" and "previe= w". It would be possible to pull this draft back and add a few more li= nk relation types to it if necessary. We would just need to identify the se= t of new link rels and I could very easily drop them in or write up a quick= second document based on the same simple template.

=C2=A0

=C2=A0

That s= aid, the "about" link relation can be used to link to both profil= e-page and vcard type resources... differentiated, of course, by the media = type of the linked resource.=C2=A0

=C2=A0

Also..= . We need to be careful not to get too specific with link relation labels. = The rel values themselves are intended to state the nature of the relations= hip and not the type of resource it is. Having something like {"rel&qu= ot;:"updates","href":"http://example.org/my/blog","typ= e":"text/html"} should be generally preferable over somethin= g like=C2=A0{"rel":"blog","href":"http://example.org/my/bl= og"}.=C2=A0

=C2=A0

- James

=C2=A0

On Sun, Nov 18, 2012 at 2:22 PM, Dick Hardt <dick.hardt@gmail.com> wrote:=

Hi Paul

=C2=A0

I agree it = should be separate drafts. I'd be willing to edit if there is interest.= My interest in WebFinger is as a consumer much more than a publisher - so = I don't feel I am a domain expert.

=C2=A0

Is it possible to have meaningful examples with existing &= quot;rel" values, or do we need to have some others defined to have me= aningful examples?

=C2= =A0

-- Dick

=C2=A0

On Nov 18, 2012, at 2:02 PM, "Paul E.= Jones" <paulej@packetizer.com> wrote:

=C2=A0

Dick,

=C2=A0

These should b= e separate drafts.=C2=A0 I agree =E2=80=9Cblog=E2=80=9D is good, but there = are surely more.=C2=A0 A lot of good ones are defined under=C2=A0webfi= nger.net, too.

=C2=A0<= u>

But I would really prefer to not slow down this draft with addition of l= ink relation values.=C2=A0 If somebody (you?) wants to start a WebFinger Li= nk Relations document, I think it would be timely.

=C2=A0<= u>

Paul

=C2=A0<= u>

=C2=A0

=

PEJ: They= could.=C2=A0 The challenge is that we have no other URI type defined for t= his purpose.=C2=A0 For the examples, we have a chicken and egg problem.

=C2=A0

Let's define some th= en! This is the one area that is vague and IMHO is a barrier to adoption. W= hat should the "rel" values be for items that I want to publish? = If we don't spec the common ones, we will end up with several different= identifiers for the same thing. Challenge of course is that getting agreem= ent on schema is always fun, but better to have some that will be used that= are not already defined.

=C2=A0

=

Need to add an IANA section for that= of course.

= =C2=A0

"blog" is a good one= :)

=C2=A0


_______________________________________________
apps-discuss mailing= list
apps-di= scuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-disc= uss

=C2=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=C2=A0is=C2=A0confidential and may contain privileged information intended for the ad= dressee(s) only. Dissemination, copying, printing or use by anybody else is= unauthorised. If you are not the intended recipient, please delete this me= ssage and any attachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta l'ambiente. Non stampare = questa mail se non =C3=A8 necessario. =

=C2=A0




On 5 November 2012 13:44, Paul E. Jones = <paulej@packe= tizer.com> wrote:
FYI

From: Mike Jones <Michael.Jones@microsoft.com>
Sent: Mon Nov 05 07:55:14 EST 2012
To: "Paul E. Jones" <paulej@packetizer.com>
Subject: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments<= br>

Paul, could you do me a favor and forward this = note to the apps-discuss list so people have context on why I updated SWD?= =C2=A0 For some reason, the list doesn=E2=80=99t appear to be accepting my message.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Thanks,

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

=C2=A0

From: Mike Jones
Sent: Sunday, November 04, 2012 9:21 PM
To: apps-= discuss@ietf.org
Subject: Simple Web Discovery (SWD) Enabling Hosted Deployments

=C2=A0

I= =E2=80=99ve updated the Simple Web Discovery (SWD) specification to incorporate = a means of performing discovery on domains for which it may not be possible= to create a .well-known endpoint.=C2=A0 This can often be the case for hosted domains, where it is common for e-mail to be provided = but no web server.=C2=A0 This solution was developed in discussions by the OpenID Connect= working group.

=C2=A0

Th= is draft is being published now to facilitate discussions of the need to en= able discovery for hosted domains and possible solutions for doing so at th= e IETF Applications Area working group meeting at I= ETF 85 in Atlanta.

=C2=A0

Th= e updated specification is available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 http://tools.ietf.org/html/dr= aft-jones-simple-web-discovery-04

=C2=A0

Ch= anges made were:

=C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Specified that the SWD server for a dom= ain may be located at the simple-web-discovery subdomain of the domain and t= hat SWD clients must first try the endpoint at the domain and then the endpoint at the subdomain.

=C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Removed the SWD_service_redirect response, since redirection c= an be accomplished by pointing the simple-web-discovery subdomain to a different loca= tion than the domain's host.

=C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Removed mailto: from examples in favor of bare e-mail addr= ess syntax.

=C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Specified that SWD servers may also be = run on ports other than 443, provided they use TLS on those ports.

=C2=A0

An= HTML formatted version is available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 http://self-issued.inf= o/docs/draft-jones-simple-web-discovery-04.html

=C2=A0

(T= his notice was also posted to http://self-= issued.info/?p=3D891.)

=C2=A0

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

=C2=A0


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