From internet-drafts@ietf.org Sun Apr 1 00:30: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 AFCE621F8646; Sun, 1 Apr 2012 00:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.757 X-Spam-Level: X-Spam-Status: No, score=-99.757 tagged_above=-999 required=5 tests=[AWL=0.243, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgNb00HNpkzT; Sun, 1 Apr 2012 00:30:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FAA21F8636; Sun, 1 Apr 2012 00:30:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120401073018.14425.57767.idtracker@ietfa.amsl.com> Date: Sun, 01 Apr 2012 00:30:18 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-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: Sun, 01 Apr 2012 07:30:19 -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 Worki= ng Group of the IETF. Title : Media Type Specifications and Registration Procedures Author(s) : Ned Freed John C. Klensin Tony Hansen Filename : draft-ietf-appsawg-media-type-regs-04.txt Pages : 30 Date : 2012-04-01 This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-04.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-04.txt From vesely@tana.it Sun Apr 1 03:28: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 9BAB921F8685 for ; Sun, 1 Apr 2012 03:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEPN28XXSB69 for ; Sun, 1 Apr 2012 03:28:07 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0F72521F864F for ; Sun, 1 Apr 2012 03:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1333276083; bh=GFd9QWCv/M47uQTn6zfpZdzAy/Tkf6mNOs/xnMbu/DM=; l=1503; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=QKKaVG10PPPMiu9cW9A6ZIP+z/4DkNunbec3WNmEiO5U4Qs3+5YjCZZJrEOAdsfc/ XR5Oj2FtlDgrb9sltHUI69CHZtAS466I8qzeD+Obb90adAofavGFbCcLyy6Ix0SXhc Gwcot0qXTOq/rJiqtbabOrx5s60nT5fbLU48KPoc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 01 Apr 2012 12:28:03 +0200 id 00000000005DC039.000000004F782DB3.00007C14 Message-ID: <4F782DB3.7050509@tana.it> Date: Sun, 01 Apr 2012 12:28:03 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> <4F72F5C0.70106@tana.it> <024101cd0d30$06d70ac0$14852040$@packetizer.com> <4F744E1D.6080101@tana.it> <041d01cd0e3b$7d9d1bc0$78d75340$@packetizer.com> <4F757D47.8060704@tana.it> <04f101cd0e9f$67616f00$36244d00$@packetizer.com> In-Reply-To: <04f101cd0e9f$67616f00$36244d00$@packetizer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] What auth server supplies email addresses? Was webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Apr 2012 10:28:08 -0000 On 30/Mar/12 20:03, Paul E. Jones wrote: > What you describe sounds a bit like JWT: > http://openid.net/specs/draft-jones-json-web-token-07.html > > Or, it might be OpenID Connect, which uses JWT. (What you describe is not > in OpenID 2.0.) Aha, thanks. So JWT is how the claim is (supposed to be) transferred to the RP, correct? I'm trying to make sense of a presentation of anonymous claims that Blaine Cook gave on last Thursday (with the drive-in-France example). Is it not specified or implemented, yet? >> -----Original Message----- >> From: Alessandro Vesely [mailto:vesely@tana.it] >> >> I may be conflating webfinger, openid, browserid, webid, and some other >> protocols of that sort. At any rate, it was said that a functionality >> relevant to some of those is to certify a generic claim, for example >> whether someone is legally allowed to drive a lorry in France. The user >> would indicate the kind-of-claim (driving license) and a trusted certifier >> (the French motoring authority) without revealing his/her identity. The >> relaying party would then let the user login at the certifier's site in >> order to eventually obtain the certificate. >> >> By the same logic, given that example.com should be universally trusted >> for email addresses that end with "@example.com", its server would be able >> to provide a certified, anonymous email address (opaque@example.com) to a >> shop, on behalf of a customer who wishes to protect his/her main address. From sm@elandsys.com Sun Apr 1 10:13: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 03FB521F896F for ; Sun, 1 Apr 2012 10:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhfybFW5Q0-i for ; Sun, 1 Apr 2012 10:13:50 -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 DCB8A21F8974 for ; Sun, 1 Apr 2012 10:13:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.107]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q31HDWP4009119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Apr 2012 10:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1333300425; i=@elandsys.com; bh=MMUf63e2zlqV18/ddDzQY8cN10RKL2Ig1nzK+uUGxvY=; h=Date:To:From:Subject:Cc; b=ZKb5AarI1TyrldKsVxy7IKjylvE0clgvqHqJ4m7UIB14HDY/CDbvTYBbiyVrxQNAx mtW+15JbLXwTS7VhunyknIXIuJPk41hZX48yod66wSrfktEP3sdRKbRsaMow3j7Sxb 8kmw1uiJlnAImtz/IGh6i2DBRiJQKLDcLfH7C5gs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1333300425; i=@elandsys.com; bh=MMUf63e2zlqV18/ddDzQY8cN10RKL2Ig1nzK+uUGxvY=; h=Date:To:From:Subject:Cc; b=AS0/RLKYWAJGzrZGh2gv3lw/k//qhz4X4s5Oj4rL2bimXx+9cFiOLbaIgCNnb8bcm MRupKJJphjqD31ykKv31rEqarhXDwS+XqyrE1++0AAw2XTSGL5XsC/JOTt6CdzDsAm 1g4RTdWnABc0QT88rkB9DTc12eNt39cHuMC7a9mY= Message-Id: <6.2.5.6.2.20120401082255.06327008@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 01 Apr 2012 09:26:02 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] Apps Area Directorate Report for March 2012 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 17:13:53 -0000 The Applications Area Directorate provides=20 semi-formal reviews of Internet-Drafts as a way=20 to improve the quality of IETF=20 specifications. The directorate consists of the=20 Working Group Chairs of the Applications Area and=20 recognized experts in the Applications Area. The following reviews were performed in March 2012: Reviewer I-D Mark Nottingham draft-ietf-pkix-cmp-transport-protocols-16 Vijay K. Gurbani draft-ietf-mediactrl-6231-iana-00 Ted Hardie draft-ietf-intarea-ipv4-id-update-04 William J. Mills draft-ietf-appswg-xdash-03 Eliot Lear draft-desruisseaux-caldav-sched-11 Claudio Allocchio draft-ietf-mediactrl-mrb-12 Joseph Yee draft-moonesamy-rfc2369bis-04 Jiankang Yao draft-ietf-dnsext-dnssec-registry-fixes-08 Martin D=FCrst draft-moonesamy-rfc2919bis-04 Lisa Dusseault draft-ietf-opsawg-management-stds-05 Glenn Parsons draft-marf-spf-reporting-08 Aaron Stone draft-ietf-marf-dkim-reporting-15 D. Crocker draft-ietf-decade-reqs-05 D. Crocker draft-ietf-decade-problem-statement-05 Claudio Allocchio draft-melnikov-smtp-priority-09 Henry S. Thompson draft-ietf-appsawg-xdash-04 Murray S. Kucherawy draft-ietf-dane-protocol-18 Pending reviews are listed at= http://trac.tools.ietf.org/area/app/trac/report/1 Lisa Dusseault stepped down from the Applications=20 Area Directorate. I would like to thank Lisa for=20 serving on the Review Team and Directorate over=20 the last three years and for sharing her=20 expertise and experience as ex-Applications Area Director. John Klensin is retiring from the Applications=20 Area Directorate. John will continue to serve on=20 the Directorate as AppsDir Emeritus. Regards, S. Moonesamy On behalf of the Applications Area Directorate http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From paulej@packetizer.com Sun Apr 1 10:40: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 9586421F884B for ; Sun, 1 Apr 2012 10:40:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQkYc9jUyTfw for ; Sun, 1 Apr 2012 10:40:51 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C71DC21F8848 for ; Sun, 1 Apr 2012 10:40:51 -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 q31HenB0004840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Apr 2012 13:40:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333302050; bh=dhNnLVE0OpCi0LZYHfN6hdCCQUa4TdxJbiTOSMQVPfA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=cpBm6kuXiY7dcZrhaHQ72ArMXCGCS2h+o8LZq5QDEmCcfjQsksZnCC3aJ3jh/H4uE TMueMB85EdfIhvJCcP2HvMZi68DB1mI91Kd/eBu9Ceg159WO6aUeaeDZVjyJXY5n8a yWLT1YlZ/u5PRkZjzsGlwYhs79Xs9+BOeGjmJcTU= From: "Paul E. Jones" To: "'Alessandro Vesely'" , References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> <4F72F5C0.70106@tana.it> <024101cd0d30$06d70ac0$14852040$@packetizer.com> <4F744E1D.6080101@tana.it> <041d01cd0e3b$7d9d1bc0$78d75340$@packetizer.com> <4F757D47.8060704@tana.it> <04f101cd0e9f$67616f00$36244d00$@packetizer.com> <4F782DB3.7050509@tana.it> In-Reply-To: <4F782DB3.7050509@tana.it> Date: Sun, 1 Apr 2012 13:40:50 -0400 Message-ID: <00a301cd102e$94d61310$be823930$@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: AQEg174HJISLlkWDD0VVkXSpmVuZQwKMareXAWwgTx8BwaaRJQGG5wouAU3B5AYBuFTkWgIDrH2CAm7QUeQCPbK1PwHttm20Akw553QBo30rsQFSEdX1ANEHVMWXFu5pEA== Content-Language: en-us Cc: 'Blaine Cook' Subject: Re: [apps-discuss] What auth server supplies email addresses? Was webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Apr 2012 17:40:52 -0000 I don't know.. I wasn't there. Blaine? Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of Alessandro Vesely > Sent: Sunday, April 01, 2012 6:28 AM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] What auth server supplies email addresses? Was > webfinger discussion > > On 30/Mar/12 20:03, Paul E. Jones wrote: > > What you describe sounds a bit like JWT: > > http://openid.net/specs/draft-jones-json-web-token-07.html > > > > Or, it might be OpenID Connect, which uses JWT. (What you describe is > > not in OpenID 2.0.) > > Aha, thanks. So JWT is how the claim is (supposed to be) transferred to > the RP, correct? I'm trying to make sense of a presentation of anonymous > claims that Blaine Cook gave on last Thursday (with the drive-in-France > example). Is it not specified or implemented, yet? > > >> -----Original Message----- > >> From: Alessandro Vesely [mailto:vesely@tana.it] > >> > >> I may be conflating webfinger, openid, browserid, webid, and some > >> other protocols of that sort. At any rate, it was said that a > >> functionality relevant to some of those is to certify a generic > >> claim, for example whether someone is legally allowed to drive a > >> lorry in France. The user would indicate the kind-of-claim (driving > >> license) and a trusted certifier (the French motoring authority) > >> without revealing his/her identity. The relaying party would then > >> let the user login at the certifier's site in order to eventually > obtain the certificate. > >> > >> By the same logic, given that example.com should be universally > >> trusted for email addresses that end with "@example.com", its server > >> would be able to provide a certified, anonymous email address > >> (opaque@example.com) to a shop, on behalf of a customer who wishes to > protect his/her main address. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From duerst@it.aoyama.ac.jp Sun Apr 1 20:11: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 E0D5021F85A1 for ; Sun, 1 Apr 2012 20:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.537 X-Spam-Level: X-Spam-Status: No, score=-96.537 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2PO322XeyLL for ; Sun, 1 Apr 2012 20:11:15 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id C72E011E80A3 for ; Sun, 1 Apr 2012 20:11:08 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q323Awkh014652 for ; Mon, 2 Apr 2012 12:10:58 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 72a4_5c6f_780caece_7c71_11e1_8497_001d096c566a; Mon, 02 Apr 2012 12:10:57 +0900 Received: from [IPv6:::1] ([133.2.210.1]:42876) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Apr 2012 12:11:01 +0900 Message-ID: <4F7918C0.9020204@it.aoyama.ac.jp> Date: Mon, 02 Apr 2012 12:10:56 +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: John C Klensin Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] Fwd: I-D Action: draft-klensin-ftpext-typeu-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 03:11:16 -0000 Hello John, others, Because there was a new version, I took a look, and I have a few comments that I don't want to withhold. *For my main comment, please see the end of this mail.* The history section should be relegated to an appendix or removed. [I enjoyed reading [RFC0373]; it's very interesting to compare to what we have now. It's not completely possible for me to judge how much of it was visionary at the time, and how much common sense, maybe in other circles than the ARPAnet]. "So, with allowances for those line termination problems -- which have been a large issue in many cases -- Image ("binary") and ASCII transfers were almost equivalent and the TYPE command became less-used." I'm not a frequent user of FTP anymore, but I think this observation is correct. I therefore strongly wonder why we would need this new TYPE. For more, please see below. "several variations on UTF-16 (possibly with surrogate pairs)": This is highly misleading. UTF-16 always includes the potential for surrogate pairs, by definition. [Of course, many actual data files don't include them, but that doesn't have to be called out.] The thing that doesn't allow surrogate pairs is called USC-2 (ISO-10646-UCS-2 in http://www.iana.org/assignments/character-sets). "When those files are transferred to another system with Image type, the result may be completely uninterpretable on the target system." This is of course possible, in particular for executables and the like. But I think there is much less variety in formats, and much more versatility in tools, so this is less an issue than it was, and even if it continues to be an issue, it's not something that can be solved with a simple type. "by sending the data in a stream conformant to the Net-Unicode format specified in Section 3." This is confusing, because Net-Unicode is defined in RFC 5198, not in section 3. Can probably be fixed with a small wording change. "This section specifies a profile of Net-Unicode [RFC5198] for use with FTP TYPE U." In German, there's a saying "Meister, die Arbeit is fertig, soll ich sie gleich flicken." (Master, I completed my work, can I start to fix it?) It's used when something is created as broken. It may not be the case for Net-Unicode, but a sentence like the above just exudes the feeling that the original definition may be broken to me, sorry. MAIN COMMENT STARTS HERE "Unicode characters must be transmitted in UTF-8 [RFC3629] as specified for Net-Unicode." This brings me to my main point, which is that the proposal isn't really implementable. It assumes that, like in the old days, there is a single textual encoding per computer. This worked very well at a time when some computers were using (7-bit) US-ASCII, and others were using the basic version of EBCDIC (for those who might not know, there are lots of EBCDIC variants including double-byte variants for East Asia). "However, migration to Unicode has reintroduced many of the old issues. When Unicode is used inside a system, it can be used with several different encodings (e.g., UTF-8 and several variations on UTF-16 (possibly with surrogate pairs), different assumptions about normalization (see "Terminology for Use in Internationalization" [i18n-terms] for more discussion) and even new variations on line termination conventions. When those files are transferred to another system with Image type, the result may be completely uninterpretable on the target system." This mostly has it wrong. The issue of many different character encodings has been around for a long time before Unicode. FTP hasn't done anything about this, and apparently has been fine (mostly because applications and users know how to deal with the problem: If you see garbage on screen, try another application or use another setting). Unicode is helping in that it greatly *reduces* variation, but in the meantime, it adds variation because it leads to a net increase of character encodings (even if there were only one encoding form of Unicode). The fact that Unicode can come in different encoding forms and other variations can definitely be annoying, but a new TYPE is not a solution. Why? Because it's not like in the old days that one maker's products would use one encoding, and another would use another. There's overall probably more UTF-16, and more of the LE variety, on a Windows System than on a Linux or Mac system, but there's a lot of UTF-8 on all of them, and there's usually also quite a bit of legacy data (e.g. Shift_JIS or EUC-JP on a Japanese system) and on average, the OS doesn't have a clue about the encoding of the file. Applications make guesses, and they often get it right. An FTP implementation could make guesses, but the problem is that the guess is too early; if it is wrong, then it we get weird double encodings. That's different from a text editor making a guess; the user can try other encodings from a menu until the stuff is right, and the binary data isn't messed up. The situation is even worse for normalization, in the sense that no OS has any clue about whether files are normalized or not. The line ending issue is not as hopeless, in that it's easy to write a filter that converts all line endings e.g. to CRLF, even including the (quite rare in actual use) new Unicode ones. So the draft might make marginal sense if limited to line-ending issues for UTF-8 only. But then again, because that's an easy problem, there are lots of applications out there that deal with this already, including any serious text editor. So overall, I don't think the Apps WG should spend time with this, unless we hear loud voices from actual FTP implementers that tell us that this is needed and will be implementable in a way that solves actual problems. Regards, Martin. From msk@cloudmark.com Sun Apr 1 22:08:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE88011E80B2 for ; Sun, 1 Apr 2012 22:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.273 X-Spam-Level: X-Spam-Status: No, score=-103.273 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CRWXRAZ-g44 for ; Sun, 1 Apr 2012 22:08:15 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDB411E80A3 for ; Sun, 1 Apr 2012 22:08:15 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Sun, 1 Apr 2012 22:08:14 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: WGLC on draft-ietf-appsawg-media-type-regs Thread-Index: Ac0QjpwXS/k4kzTsSYSQ+Pgexg+sug== Date: Mon, 2 Apr 2012 05:08:13 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C4828@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280C4828exchmbx901corpclo_" MIME-Version: 1.0 Subject: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 05:08:16 -0000 --_000_9452079D1A51524AA5749AD23E0039280C4828exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This message serves as the beginning of Working Group Last Call on draft-ie= tf-appsawg-media-type-regs, to end on Friday, April 13th. Please review th= e document and provide any feedback to the authors directly or to apps-disc= uss@ietf.org. The datatracker page for the document: https://datatracker.ietf.org/doc/dra= ft-ietf-appsawg-media-type-regs/ -MSK, APPSAWG co-chair --_000_9452079D1A51524AA5749AD23E0039280C4828exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This message serves as the beginning of Working Grou= p Last Call on draft-ietf-appsawg-media-type-regs, to end on Friday, April = 13th.  Please review the document and provide any feedback = to the authors directly or to apps-discuss@ietf.org.

 

The datatracker page for the document: https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/

 

-MSK, APPSAWG co-chair

 

--_000_9452079D1A51524AA5749AD23E0039280C4828exchmbx901corpclo_-- From yusuke.doi@toshiba.co.jp Mon Apr 2 00:45: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 71C5121F8874 for ; Mon, 2 Apr 2012 00:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.09 X-Spam-Level: X-Spam-Status: No, score=-8.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyTZcKGTBVvL for ; Mon, 2 Apr 2012 00:45:11 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEC921F887B for ; Mon, 2 Apr 2012 00:45:11 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q327j9xP027126 for ; Mon, 2 Apr 2012 16:45:09 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q327j9UU021940 for apps-discuss@ietf.org; Mon, 2 Apr 2012 16:45:09 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id SAA21938; Mon, 2 Apr 2012 16:45:09 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q327j93o014425 for ; Mon, 2 Apr 2012 16:45:09 +0900 (JST) Received: by toshiba.co.jp id q327j8ZO014723; Mon, 2 Apr 2012 16:45:08 +0900 (JST) Message-Id: <201204020745.q327j8ZO014723@toshiba.co.jp> Date: Mon, 02 Apr 2012 16:45:08 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Mark Nottingham References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <0885CE0D-11A3-4396-9443-37B4FF8D36C9@mnot.net> In-Reply-To: <0885CE0D-11A3-4396-9443-37B4FF8D36C9@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 07:45:12 -0000 Dear Mark, I have a following use case. As EXI is expected to be used in constrained environments, we want to make it as short as possible. With application+exi content-type, we can make sure the field is under the application's convention; schemaId '1' may mean the version 1 of a schema for the application, and so on. In other words, this kind of content-type definition (application + encoding) can imply the format of schemaId field used in the application. And this helps 'option/encoding negotiation' of EXI. Regards, Yusuke On 2012年03月31日 19:55, Mark Nottingham wrote: > What's the use case here? Content negotiation, or something else? > > Regards, > > > On 29/03/2012, at 10:52 PM, Zach Shelby wrote: > >> I have posted a new version of the +exi registration draft. This version improves the Interoperability considerations of the registration requirements and further clarifies when this suffix may be used, as per the feedback on the list from Carine and others. >> >> http://www.ietf.org/id/draft-shelby-exi-registration-01.txt >> >> Regards, >> Zach >> >> Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Date: March 29, 2012 10:47:32 PM GMT+02:00 >>> To: zach@sensinode.com >>> Subject: New Version Notification for draft-shelby-exi-registration-01.txt >>> >>> A new version of I-D, draft-shelby-exi-registration-01.txt has been successfully submitted by Zach Shelby and posted to the IETF repository. >>> >>> Filename: draft-shelby-exi-registration >>> Revision: 01 >>> Title: The +exi Media Type Suffix >>> Creation date: 2012-03-29 >>> WG ID: Individual Submission >>> Number of pages: 5 >>> >>> Abstract: >>> Efficient XML Interchange (EXI) is an XML representation technique >>> specified by the W3C to provie a binary alternative to the standard >>> text XML representation. This document defines a new Structure >>> Syntax Suffix"+exi" for use in a specific class of protocols, where >>> "exi" content-type encoding or the generic"application/exi" Media >>> Type are not applicable. >>> >>> >>> >>> >>> The IETF Secretariat >> >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >> Mobile: +358 40 7796297 >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham > http://www.mnot.net/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From lhotka@nic.cz Mon Apr 2 04:49: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 4414C21F896A for ; Mon, 2 Apr 2012 04:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yk8OXYJqPfKU for ; Mon, 2 Apr 2012 04:49:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 178B021F8963 for ; Mon, 2 Apr 2012 04:49:49 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id BDE801403AB for ; Mon, 2 Apr 2012 13:49:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333367387; bh=Mi335o4ILUL/Od+26aMFtAJpaheinan7QvP+vWwJ2Po=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=I6MUSiQbD17JCHXm9kBS7pg4qNxvT4pem+k3rF1puLhiJJ20CkX7+2qcG8gpVRM8K iyPt2yhbYFi5/gMTkHruAFUYQmg4NeaAhRaNLfMbo+x8mcjLpwokctTZQZZwW91KWk liacxMN+ytU/Zyxnx0hOSIoX7vSHnlEXVbs+Sqj4= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2012 13:49:47 +0200 References: <20120402111722.9761.30651.idtracker@ietfa.amsl.com> To: apps-discuss@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [apps-discuss] Fwd: New Version Notification for draft-lhotka-yang-json-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 11:49:50 -0000 Hi, this I-D is an attempt (a first step, really) to enable use of JSON in = the NETCONF/YANG context, e.g., for a RESTful API. Potentially, it also allows for using YANG to model JSON data in = general. Comments will be appreciated. Lada Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-lhotka-yang-json-00.txt > Date: April 2, 2012 1:17:22 PM GMT+02:00 > To: lhotka@nic.cz >=20 > A new version of I-D, draft-lhotka-yang-json-00.txt has been = successfully submitted by Ladislav Lhotka and posted to the IETF = repository. >=20 > Filename: draft-lhotka-yang-json > Revision: 00 > Title: Modeling JSON Text with YANG > Creation date: 2012-04-02 > WG ID: Individual Submission > Number of pages: 12 >=20 > Abstract: > This document defines rules for mapping data models expressed in = YANG > to JSON text. It does so by specifying a procedure for translating > the subset of YANG-compatible XML documents to JSON text, and vice > versa. >=20 >=20 >=20 >=20 > The IETF Secretariat -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From carine@jay.w3.org Mon Apr 2 05:45: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 56AC621F8532 for ; Mon, 2 Apr 2012 05:45:24 -0700 (PDT) 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_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XITCyoqhz0oN for ; Mon, 2 Apr 2012 05:45:23 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8C821F8513 for ; Mon, 2 Apr 2012 05:45:23 -0700 (PDT) Received: from carine by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1SEgdO-00072l-5P; Mon, 02 Apr 2012 08:45:22 -0400 Date: Mon, 2 Apr 2012 08:45:22 -0400 From: Carine Bournez To: Zach Shelby Message-ID: <20120402124522.GX16698@jay.w3.org> References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 12:45:24 -0000 On Thu, Mar 29, 2012 at 10:52:06PM +0200, Zach Shelby wrote: > I have posted a new version of the +exi registration draft. This version improves the Interoperability considerations of the registration requirements and further clarifies when this suffix may be used, as per the feedback on the list from Carine and others. > > http://www.ietf.org/id/draft-shelby-exi-registration-01.txt Hi, Thanks for this new version. I still think that this proposal is too restrictive. As you say in section 2, you want to "use EXI as a native encoding (without the use of XML as an interemediate) in Schema-informed mode, and the base Media Type together with the SchemaID indicates to the protocol the Schema that was used to produce the EXI grammar as described in Section 4." I don't think this will be necessarily the case for all the foo+exi media types that you can think of. Carsten pointed out in the earlier discussion that your use case is for constrained devices, and I understand the choice of schema-informed, strict, and shortest schemaID possible, but the original discussion about proposing a +exi suffix was not restricted to such use cases. A consequence of relaxing these constraints in section 2 is that section 4 would have MAYs everywhere instead of those MUSTs: << Interoperability considerations: The registration of a Media Type using this suffix MUST describe how to determine the XML Schema that is used to encode/decode a payload identified by that Media Type. In particular this description defines how to determine the Schema used to encode a payload using the SchemaID option of the EXI header. The format of the identifier to be used in the SchemaID, a reference to where the corresponding Schema is defined, and a description of how future versions of such Schemas will be handled MUST be included. A default Schema version in the absence of the SchemaID field MAY be defined. >> Other points than schemaID would also need to be mentioned (I thought I had commented on that earlier as well). It will be fine to specify a number of constraints when you define and register a given foo+exi media type, but for the +exi suffix generic description, I'd just list interop key points without specific restrictions. -- Carine Bournez -+- W3C Europe From ylafon@w3.org Mon Apr 2 06:30: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 1B52F21F84FA; Mon, 2 Apr 2012 06:30:40 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf1pPjhwKeC8; Mon, 2 Apr 2012 06:30:39 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF2021F84F7; Mon, 2 Apr 2012 06:30:39 -0700 (PDT) Received: from ylafon by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1SEhL8-0001Nx-3a; Mon, 02 Apr 2012 09:30:34 -0400 Date: Mon, 2 Apr 2012 09:30:34 -0400 (EDT) From: Yves Lafon To: apps-discuss@ietf.org, draft-ietf-mile-sci.all@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: mile@ietf.org Subject: [apps-discuss] Review of draft-ietf-mile-sci-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: Mon, 02 Apr 2012 13:30:40 -0000 All, I have been selected as the Applications Area Directorate reviewer for=20 this draft (for background on appsdir, please see [1]). Document: draft-ietf-mile-sci-02 Title: IODEF-extension to support structured cybersecurity information Reviewer: Yves Lafon Review Date: April 2, 2012 Review Summary: This draft is almost ready for publication, small=20 important issues needs to be addressed or clarified before publication. Document Summary: The document define a 'wrapper' document to present in a common format=20 different cybersecurity report formats. Major Issues: There are two issues. * In the normative reference section, there are reference to many document= =20 where the licensing information is not clear, like [CAPEC]. It would be=20 good to clarify the license information of the documents linked in the=20 normative section. * The schema provided is invalid, this line needs to be fixed based on=20 intent: Both issues are major issues as they need being fixed, but I consider them= =20 easy to fix. Minor Issue: In the definition of 'AttackPattern' class, the restriction in the prose=20 (4.3.1) is not expressed in the schema. << AttackPatternID: OPTIONAL. STRING. An identifier of an attack pattern to be reported. This attribute SHOULD be used whenever such identifier is available, but could be omitted if no such one is available. In this case, either RawData or Reference elements, or both of them, MUST be provided. >> Same issue with 'Platform', 'Vulnerability', 'Weakness', 'EventReport',=20 'Verification'... Also the other MUST-level requirement of ensuring consistency of the value= =20 might be tested using a schematron schema, that could be a useful addition= =20 if the goal of the schema is to provice automated verification. In the example, the foreign namespaces definition also include links to=20 schemas, it might be better to remove those and keep in the main schema=20 the list of possible namespaces (and their schemas), ie: keep the schema=20 referring to other schema for people requiring schema validation, and=20 remove verbosity in instances (it should affect only the definition of=20 XMLDATA). The downside being that the main schema needs to be updated=20 when the list in 4.1 is updated (and schema link should be in the list in= =20 4.1). HTH, [1] --=20 Baroula que barouleras, au ti=E9u toujou t'entourneras. ~~Yves From vesely@tana.it Mon Apr 2 06: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 AD0D421F84F7 for ; Mon, 2 Apr 2012 06:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClIgl74jrAr0 for ; Mon, 2 Apr 2012 06:33:03 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAC121F84F1 for ; Mon, 2 Apr 2012 06:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1333373581; bh=onKNlj7bfcryaao6Oc0TDmT/VVSDl3H6zxKBbW8sGSE=; l=4682; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=HUIrSRopwdeTlqlm7Ck+ZjI2E93qdIahFUbWKbP96ULoVFsUzbdXtO8+gDHVouViT +eDlFTuit4JELI2ftvHBJU0mZ+mzFHJMoVt6hoj0PH66CbRmASL8MMrkPbLXWHWkys Ds9x5Ntwgb6X+e4zGV/kNKRQwe+QNmZU8auL1K4c= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 02 Apr 2012 15:33:01 +0200 id 00000000005DC03F.000000004F79AA8D.0000154B Message-ID: <4F79AA8C.8080908@tana.it> Date: Mon, 02 Apr 2012 15:33:00 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Blaine Cook References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> <4F72F5C0.70106@tana.it> <024101cd0d30$06d70ac0$14852040$@packetizer.com> <4F744E1D.6080101@tana.it> <041d01cd0e3b$7d9d1bc0$78d75340$@packetizer.com> <4F757D47.8060704@tana.it> <04f101cd0e9f$67616f00$36244d00$@packetizer.com> <4F782DB3.7050509@tana.it> <00a301cd102e$94d61310$be823930$@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] What auth server supplies email addresses? Was webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Apr 2012 13:33:04 -0000 Hi Blaine, On 02/Apr/12 11:52, Blaine Cook wrote: > > Basically, the breakdown is this: > > Discovery: > > a. email (and URI, but ignore that) based: webfinger / swd > b. for auth protocols: the proposed oauth discovery draft, the > mechanism that browserid uses, openid 2.0's current discovery > > Anonymous Claims: > > I gather that the google folks and others have figured out a way to do > the anonymous-claims (I don't know the formal cryptoterm for that) > with OAuth, but here's my take with browserID in a nutshell: > > The current BrowserID spec has a javascript API like: > > navigator.id.get( [email], callback ) > > which will produce a JWT assertion, signed by domain(email) (or a > trusted 3rd party), that proves that the bearer owns the email > address. > > This can be generalised, of course, to be something (theoretical) like this: So by "(theoretical)" you mean it may be eventually specified/ implemented but currently nothing like that exist, correct? > navigator.claim.get( claimType, [desired claim-value-or-something], callback ) > > for example, > > navigator.claim.get( licensedToDrive, 'fr', function (claim) { > console.log(claim) } ) > > which would provide a JWT signed by some-random-authority that asserts > whether or not the person sitting at the browser is allowed to drive > in France. The client would then verify that the assertion was signed > by the stated issuer AND that the client TRUSTS the issuer (e.g., if > the assertion is signed by gov.uk, then most companies in the UK would > trust the assertion, but many in the United States (or Iran) would > not). > > Does that make sense? For that to work, the claim provider either has to be obtained from a standardized list of claims, or can be passed as an argument by the caller, who may get it from the user. For example, assuming that any EU country can issue driving licenses valid in France, you'd need the user to tell where she got her license from. My opaque@example.com example is similar. Or it could have a shorter generalization, like navigator.id.get( "@example.com", myCallback ); where the user interacts with the server to specify what kind of address alias (opaque, official role, name+folder@, name.surname@, etc.) she wants to be returned to the RP, assuming her server supports such capabilities. Would shops use any of those? > On 1 April 2012 18:40, Paul E. Jones wrote: >> I don't know.. I wasn't there. >> >> Blaine? >> >> Paul >> >>> -----Original Message----- >>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] >>> On Behalf Of Alessandro Vesely >>> Sent: Sunday, April 01, 2012 6:28 AM >>> To: apps-discuss@ietf.org >>> Subject: Re: [apps-discuss] What auth server supplies email addresses? Was >>> webfinger discussion >>> >>> On 30/Mar/12 20:03, Paul E. Jones wrote: >>> > What you describe sounds a bit like JWT: >>> > http://openid.net/specs/draft-jones-json-web-token-07.html >>> > >>> > Or, it might be OpenID Connect, which uses JWT. (What you describe is >>> > not in OpenID 2.0.) >>> >>> Aha, thanks. So JWT is how the claim is (supposed to be) transferred to >>> the RP, correct? I'm trying to make sense of a presentation of anonymous >>> claims that Blaine Cook gave on last Thursday (with the drive-in-France >>> example). Is it not specified or implemented, yet? >>> >>> >> -----Original Message----- >>> >> From: Alessandro Vesely [mailto:vesely@tana.it] >>> >> >>> >> I may be conflating webfinger, openid, browserid, webid, and some >>> >> other protocols of that sort. At any rate, it was said that a >>> >> functionality relevant to some of those is to certify a generic >>> >> claim, for example whether someone is legally allowed to drive a >>> >> lorry in France. The user would indicate the kind-of-claim (driving >>> >> license) and a trusted certifier (the French motoring authority) >>> >> without revealing his/her identity. The relaying party would then >>> >> let the user login at the certifier's site in order to eventually >>> >> obtain the certificate. >>> >> >>> >> By the same logic, given that example.com should be universally >>> >> trusted for email addresses that end with "@example.com", its server >>> >> would be able to provide a certified, anonymous email address >>> >> (opaque@example.com) to a shop, on behalf of a customer who wishes to >>> >> protect his/her main address. >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >> From mnot@mnot.net Mon Apr 2 08:08: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 27FA721F85FF for ; Mon, 2 Apr 2012 08:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWlQnLksJ2JA for ; Mon, 2 Apr 2012 08:08:40 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9BE21F85EF for ; Mon, 2 Apr 2012 08:08:33 -0700 (PDT) Received: from [10.4.80.59] (unknown [74.205.24.231]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 33E2750A64; Mon, 2 Apr 2012 11:08:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Mark Nottingham In-Reply-To: <201204020745.q327j8Rr014728@toshiba.co.jp> Date: Mon, 2 Apr 2012 11:08:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <0885CE0D-11A3-4396-9443-37B4FF8D36C9@mnot.net> <201204020745.q327j8Rr014728@toshiba.co.jp> To: Yusuke DOI X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:08:41 -0000 Potentially exploding the number of XML media types defined across the = Web and in e-mail to save a few bytes in *one* use case seems like a = poor trade-off to me.=20 On 02/04/2012, at 3:45 AM, Yusuke DOI wrote: > Dear Mark, >=20 > I have a following use case. >=20 > As EXI is expected to be used in constrained environments, we want to = make it as short as possible. With application+exi content-type, we can = make sure the field is under the application's convention; schemaId '1' = may mean the version 1 of a schema for the application, and so on. >=20 > In other words, this kind of content-type definition (application + = encoding) can imply the format of schemaId field used in the = application. And this helps 'option/encoding negotiation' of EXI. >=20 > Regards, >=20 > Yusuke >=20 >=20 > On 2012=E5=B9=B403=E6=9C=8831=E6=97=A5 19:55, Mark Nottingham wrote: >> What's the use case here? Content negotiation, or something else? >>=20 >> Regards, >>=20 >>=20 >> On 29/03/2012, at 10:52 PM, Zach Shelby wrote: >>=20 >>> I have posted a new version of the +exi registration draft. This = version improves the Interoperability considerations of the registration = requirements and further clarifies when this suffix may be used, as per = the feedback on the list from Carine and others. >>>=20 >>> http://www.ietf.org/id/draft-shelby-exi-registration-01.txt >>>=20 >>> Regards, >>> Zach >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Date: March 29, 2012 10:47:32 PM GMT+02:00 >>>> To: zach@sensinode.com >>>> Subject: New Version Notification for = draft-shelby-exi-registration-01.txt >>>>=20 >>>> A new version of I-D, draft-shelby-exi-registration-01.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >>>>=20 >>>> Filename: draft-shelby-exi-registration >>>> Revision: 01 >>>> Title: The +exi Media Type Suffix >>>> Creation date: 2012-03-29 >>>> WG ID: Individual Submission >>>> Number of pages: 5 >>>>=20 >>>> Abstract: >>>> Efficient XML Interchange (EXI) is an XML representation technique >>>> specified by the W3C to provie a binary alternative to the = standard >>>> text XML representation. This document defines a new Structure >>>> Syntax Suffix"+exi" for use in a specific class of = protocols, where >>>> "exi" content-type encoding or the = generic"application/exi" Media >>>> Type are not applicable. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>=20 >>> -- >>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>> http://www.sensinode.com >>> http://zachshelby.org - My blog "On the Internet of Things" >>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >>> Mobile: +358 40 7796297 >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> -- >> Mark Nottingham >> http://www.mnot.net/ >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 -- Mark Nottingham http://www.mnot.net/ From paulej@packetizer.com Mon Apr 2 08:49:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5371E21F8598 for ; Mon, 2 Apr 2012 08:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zojFuFz2J3Q for ; Mon, 2 Apr 2012 08:49:29 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4C38F21F8581 for ; Mon, 2 Apr 2012 08:49:29 -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 q32FnRT8001679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2012 11:49:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333381768; bh=D2pkAKHaJt4GFS5Hh8/heSeV1Gas8ZXX1zlOWyJL4RQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=eAyhV+5B5/ePMJnt2nslP6ecyLPzuRLpZ6GWFMRoMDE0dbJ4T5pcH9S0QX8J8I/3i LGmKXkIyGXvHQ1ndBtj4M1KTq7BRzDH7p4AWkA0JAvqkKZ61UqQMUuQ+TtuyUuxCGI 34ACr68icP8xet/ghSKDjXNfgThO4rqHMTjUEzfk= From: "Paul E. Jones" To: "'Mark Nottingham'" , "'Yusuke DOI'" References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <0885CE0D-11A3-4396-9443-37B4FF8D36C9@mnot.net> <201204020745.q327j8Rr014728@toshiba.co.jp> In-Reply-To: Date: Mon, 2 Apr 2012 11:49:31 -0400 Message-ID: <019201cd10e8$31dfa590$959ef0b0$@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: AQHL9HRV4G3PYvCPotxdOqsWB3r+MQHK0bg/AvzcHRECblFyQgGDFSt/lkQbEMA= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:49:30 -0000 Folks, I've monitored part of this thread, though admittedly I've not read = every message. So, I apologize if I'm beating a dead horse here. I've noted that nearly every time that JSON is employed the associated = media type is application/json. In fact, I cannot recall having seen = any standards with application/whatever+json. So, does this suggest = that the level of granularity is not needed? Since EXI is a binary representation of XML, why give it a different = media type? To add to Mark's concern, there are a number of different = binary XML formats. Should we create a different media type (and use = the + notation) for all of them? Then we have nxm different "new" media = types. It was asked before why "Content-Coding" is not used. I recognize that = converting to EXI is different than producing a lossless compression, = since the EXI cannot be converted back to ASCII without the schema in = hand. Nonetheless, I would assume a sender would not send EXI unless it = knew the recipient could deal with it. In any case, I am of the mind that all of the +xml definitions is = unfortunate and we ought to try to find a solution that does not = exasperate the problem. To that end, we should try to understand why = application/json has been sufficient for most uses. Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of Mark Nottingham > Sent: Monday, April 02, 2012 11:08 AM > To: Yusuke DOI > Cc: apps-discuss@ietf.org application-layer protocols > Subject: Re: [apps-discuss] New Version Notification for = draft-shelby-exi- > registration-01.txt >=20 > Potentially exploding the number of XML media types defined across the = Web > and in e-mail to save a few bytes in *one* use case seems like a poor > trade-off to me. >=20 >=20 > On 02/04/2012, at 3:45 AM, Yusuke DOI wrote: >=20 > > Dear Mark, > > > > I have a following use case. > > > > As EXI is expected to be used in constrained environments, we want = to > make it as short as possible. With application+exi content-type, we = can > make sure the field is under the application's convention; schemaId = '1' > may mean the version 1 of a schema for the application, and so on. > > > > In other words, this kind of content-type definition (application + > encoding) can imply the format of schemaId field used in the = application. > And this helps 'option/encoding negotiation' of EXI. > > > > Regards, > > > > Yusuke > > > > > > On 2012=E5=B9=B403=E6=9C=8831=E6=97=A5 19:55, Mark Nottingham wrote: > >> What's the use case here? Content negotiation, or something else? > >> > >> Regards, > >> > >> > >> On 29/03/2012, at 10:52 PM, Zach Shelby wrote: > >> > >>> I have posted a new version of the +exi registration draft. This > version improves the Interoperability considerations of the = registration > requirements and further clarifies when this suffix may be used, as = per > the feedback on the list from Carine and others. > >>> > >>> http://www.ietf.org/id/draft-shelby-exi-registration-01.txt > >>> > >>> Regards, > >>> Zach > >>> > >>> Begin forwarded message: > >>> > >>>> From: internet-drafts@ietf.org > >>>> Date: March 29, 2012 10:47:32 PM GMT+02:00 > >>>> To: zach@sensinode.com > >>>> Subject: New Version Notification for > >>>> draft-shelby-exi-registration-01.txt > >>>> > >>>> A new version of I-D, draft-shelby-exi-registration-01.txt has = been > successfully submitted by Zach Shelby and posted to the IETF = repository. > >>>> > >>>> Filename: draft-shelby-exi-registration > >>>> Revision: 01 > >>>> Title: The +exi Media Type Suffix > >>>> Creation date: 2012-03-29 > >>>> WG ID: Individual Submission > >>>> Number of pages: 5 > >>>> > >>>> Abstract: > >>>> Efficient XML Interchange (EXI) is an XML representation = technique > >>>> specified by the W3C to provie a binary alternative to the = standard > >>>> text XML representation. This document defines a new Structure > >>>> Syntax Suffix"+exi" for use in a specific class of > >>>> protocols, where "exi" content-type encoding or the > >>>> generic"application/exi" Media Type are not = applicable. > >>>> > >>>> > >>>> > >>>> > >>>> The IETF Secretariat > >>> > >>> -- > >>> Zach Shelby, Chief Nerd, Sensinode Ltd. > >>> http://www.sensinode.com > >>> http://zachshelby.org - My blog "On the Internet of Things" > >>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" > >>> Mobile: +358 40 7796297 > >>> > >>> _______________________________________________ > >>> apps-discuss mailing list > >>> apps-discuss@ietf.org > >>> https://www.ietf.org/mailman/listinfo/apps-discuss > >> > >> -- > >> Mark Nottingham > >> http://www.mnot.net/ > >> > >> > >> > >> > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > >=20 > -- > Mark Nottingham > http://www.mnot.net/ >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From takeshi_takahashi@nict.go.jp Mon Apr 2 19:50: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 978DE21F8769; Mon, 2 Apr 2012 19:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.755 X-Spam-Level: X-Spam-Status: No, score=-0.755 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, J_CHICKENPOX_111=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5PokqkLhRpk; Mon, 2 Apr 2012 19:50:09 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id C20CF21F8767; Mon, 2 Apr 2012 19:50:08 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q332o3bx005042; Tue, 3 Apr 2012 11:50:03 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q332o3Af007310; Tue, 3 Apr 2012 11:50:03 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id q332o3v4007303; Tue, 3 Apr 2012 11:50:03 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 232331608B; Tue, 3 Apr 2012 11:50:03 +0900 (JST) Received: from takeVAIO2 (unknown [133.243.119.6]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 1CD3B16003; Tue, 3 Apr 2012 11:50:03 +0900 (JST) From: "Takeshi Takahashi" To: "'Yves Lafon'" , , References: In-Reply-To: Date: Tue, 3 Apr 2012 11:50:02 +0900 Message-ID: <00c601cd1144$77565f90$66031eb0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGXb20xT+3R8pLmZ4LMaTVwjZ7Jb5bzqVlQ Content-Language: ja X-Mailman-Approved-At: Tue, 03 Apr 2012 11:19:19 -0700 Cc: mile@ietf.org Subject: Re: [apps-discuss] [mile] Review of draft-ietf-mile-sci-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: Tue, 03 Apr 2012 02:50:09 -0000 Thank you very much, Yves, for your kind review. I appreciate that very much. Let me modify the draft to handle the issues you kindly pointed out = along with the other issues raised at the Paris meeting. Kind Regards, Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of > Yves Lafon > Sent: Monday, April 02, 2012 10:31 PM > To: apps-discuss@ietf.org; draft-ietf-mile-sci.all@tools.ietf.org > Cc: mile@ietf.org > Subject: [mile] Review of draft-ietf-mile-sci-02. >=20 > All, > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see [1]). >=20 > Document: draft-ietf-mile-sci-02 > Title: IODEF-extension to support structured cybersecurity information > Reviewer: Yves Lafon > Review Date: April 2, 2012 >=20 > Review Summary: This draft is almost ready for publication, small > important issues needs to be addressed or clarified before = publication. >=20 > Document Summary: > The document define a 'wrapper' document to present in a common format > different cybersecurity report formats. >=20 > Major Issues: >=20 > There are two issues. > * In the normative reference section, there are reference to many = document > where the licensing information is not clear, like [CAPEC]. It would = be > good to clarify the license information of the documents linked in the > normative section. >=20 > * The schema provided is invalid, this line needs to be fixed based on > intent: > use=3D"prohibited" value=3D"xml"/> >=20 > Both issues are major issues as they need being fixed, but I consider > them easy to fix. >=20 > Minor Issue: >=20 > In the definition of 'AttackPattern' class, the restriction in the = prose > (4.3.1) is not expressed in the schema. > << > AttackPatternID: OPTIONAL. STRING. An identifier of an attack > pattern to be reported. This attribute SHOULD be used whenever > such identifier is available, but could be omitted if no such = one > is available. In this case, either RawData or Reference = elements, > or both of them, MUST be provided. > >> > Same issue with 'Platform', 'Vulnerability', 'Weakness', = 'EventReport', > 'Verification'... > Also the other MUST-level requirement of ensuring consistency of the = value > might be tested using a schematron schema, that could be a useful = addition > if the goal of the schema is to provice automated verification. >=20 > In the example, the foreign namespaces definition also include links = to > schemas, it might be better to remove those and keep in the main = schema > the list of possible namespaces (and their schemas), ie: keep the = schema > referring to other schema for people requiring schema validation, and > remove verbosity in instances (it should affect only the definition of > XMLDATA). The downside being that the main schema needs to be updated > when the list in 4.1 is updated (and schema link should be in the list > in 4.1). >=20 > HTH, >=20 > [1] > torate> >=20 > -- > Baroula que barouleras, au ti=E9u toujou t'entourneras. >=20 > ~~Yves >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From vumip1@gmail.com Tue Apr 3 19:38: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 DEADC21F856C; Tue, 3 Apr 2012 19:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=0.773, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBQWpDA-oaDb; Tue, 3 Apr 2012 19:38: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 37C8F21F8568; Tue, 3 Apr 2012 19:38:11 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so587840obb.31 for ; Tue, 03 Apr 2012 19:38:10 -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=6uEBZ9heJkgKZQdg8XGDIyAo9fY484LtFO+LXwB22SQ=; b=Cu4yBE1GGi/5dcs1VLoLR22aNE1Qv2js3jXoSf9I07NQruwi+Z5VDOnV7xMNmtzIRj p3aSWAOnoCMGNcxLsfUiAZKLNvXuxhUPsnfD+IXO8LumZTY0Y1e5OXVSKvH5ENEWMWo8 fJt7R9LWMqjON1LB7iiqM3amHfO7ATkUH/pMXd4kFPlS/sqi5Wh+G8OSgyJVvFYtaMGf INnv4b+RNORrsXVPdXXnlMskUpl+uAxnynFbC/dRLiQj9N5+zpx+6wHtEdp1eOrccVtJ 87z4OAskACWmZXcjQ1XwzQKtnTrdfhJVPVlBuFjUT6KR5LX9UUE8xz1OW3m5lWlTWnM4 3WpA== MIME-Version: 1.0 Received: by 10.182.188.38 with SMTP id fx6mr22118610obc.77.1333507090880; Tue, 03 Apr 2012 19:38:10 -0700 (PDT) Received: by 10.182.171.104 with HTTP; Tue, 3 Apr 2012 19:38:10 -0700 (PDT) Date: Tue, 3 Apr 2012 22:38:10 -0400 Message-ID: From: Bhumip Khasnabish To: opsawg@ietf.org, apps-discuss@ietf.org, dc@ietf.org, cdni@ietf.org, scim@ietf.org, dcrg-interest@irtf.org Content-Type: multipart/alternative; boundary=f46d04478bdd7518e904bcd150de Subject: [apps-discuss] Fwd: slides from IETF83 Cloud Storage Talk by Giorgio X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 02:38:12 -0000 --f46d04478bdd7518e904bcd150de Content-Type: text/plain; charset=ISO-8859-1 The slides from IETF83 Cloud Storage Talk by Giorgio are now available at the following Website: http://trac.tools.ietf.org/area/app/trac/wiki/Clouds File names are as follows: IETF83-Cloud-Storage-Talk-Giorgio-29Mar2012-part1.pdf and IETF83-Cloud-Storage-Talk-Giorgio-29Mar2012-part2.pdf --f46d04478bdd7518e904bcd150de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The slides from IETF83 Cloud Storage Talk by Giorgio are now available a= t the following Website:
http://trac.tools.ietf.org/area/app/tra= c/wiki/Clouds

File names are as follows:
=A0
IETF83-Cloud-Storage-Talk-Giorgio-2= 9Mar2012-part1.pdf
and
IETF83-Cloud-Storage-Talk-Giorgio-29Mar2012-= part2.pdf
=A0
=A0
=A0

--f46d04478bdd7518e904bcd150de-- From robin@berjon.com Wed Apr 4 06:28: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 BFBC321F855B for ; Wed, 4 Apr 2012 06:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpZDhitNeGI7 for ; Wed, 4 Apr 2012 06:28:34 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id BAB4D21F8539 for ; Wed, 4 Apr 2012 06:28:34 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5BF8620E20 for ; Wed, 4 Apr 2012 09:28:33 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 04 Apr 2012 09:28:33 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version; s=smtpout; bh=fQhoU190dxOZPISsqDPIRYviZxk=; b=Es0 uKjiMGkVZhzrYURCn4DpmQMs+85PjKf0nCwQpdZYZpbVwKh6bZLUcY5cCkBzv7WZ zgEdNDB1e2DQFRj9tTdIoRB0bF2B6+4zkDHkrovc2RsNfx038JiJ8ZH46vjmB3Cf xBetxIpZeAOj49EDiOHtbgb9i7Vk9fT/EksgtarI= X-Sasl-enc: 9W+2HGVkY3XEMCYgzS7WH6rFyhBsXUgFnV5q+TPSJ2Ze 1333546112 Received: from vis154b.sophia.inria.fr (vis154b.sophia.inria.fr [194.254.174.154]) by mail.messagingengine.com (Postfix) with ESMTPSA id C10198E0182; Wed, 4 Apr 2012 09:28:32 -0400 (EDT) From: Robin Berjon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Apr 2012 15:28:33 +0200 Message-Id: <6C13AB73-6302-43D4-87BC-FB7ECD968A5B@berjon.com> To: apps-discuss@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 04 Apr 2012 08:16:24 -0700 Cc: draft-shelby-exi-registration@tools.ietf.org Subject: [apps-discuss] Feedback on draft-shelby-exi-registration-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: Wed, 04 Apr 2012 13:28:35 -0000 Dear all, please find some notes below on the draft-shelby-exi-registration-01 = proposal that describes a +exi media type suffix. Before I jump in, I = would like to make it clear that these comments are strictly my own and = are not made as any of former chair of the EXI WG, the XBC WG, or as = member of the W3C TAG. =95 It is mentioned that the +exi suffix is defined "for use in a = specific class of protocols". It further seems to be implied that these = protocols do not support conveying content encoding separately from the = type. I think that it would be helpful to specify what those protocols = are. Given the cost and impact of introducing a +exi structure suffix = across the board, without that information I can only suspect that it = may be both cheaper and simpler to update the relevant protocols. Additionally, if those protocols are designed to be simpler, easier to = process profiles of HTTP, given that the use case covers devices that = obviously already have an EXI decoder, in absence of further information = I also wonder if those protocols could not be replaced by some form of = EXI-encoded HTTP (possibly minus a number of headers). But naturally = this is just a speculation made in absence of information. =95 Reading the following: """ The "+exi" Structure Syntax Suffix defined in this document is=20 appropriate for use with a special class of protocols that: o Make use of a Media Type to identify the semantics of the protocol payload, and offer more that one serialization of the payloads. For example, some protocols may offer JSON, XML and EXI representations" """ I cannot help but get a strong sense that this is actually making a case = for using content coding rather than a structured suffix since it = mirrors (certainly in the case of EXI) the semantics versus = serialisation distinction. EXI was deliberately defined to be a content = coding for XML; the group's decision to define an "exi" content coding = rather than a +exi suffix was intentional and not an oversight. Conflating content coding and media type seems at the very least strange = to me. To take an example, we currently have image/svg+xml. This draft = introduces image/svg+exi. Can you explain why that would be a good thing = to introduce, and if it is should we also look into adding = image/svg+gzip and image/svg+identity? =95 This part "use EXI as a native encoding (without the use of XML as = an interemediate)" worries me because it seems to stem from a rather = fundamental misunderstanding of what EXI is. EXI is XML. There is no = form of requirement to hop through XML Data Model -> XML -> EXI, and = whichever way the EXI bitstream was produced really, really should be = immaterial for any protocol transmitting it as well as for a potential = media type registration. =95 This is worrying: "The registration of a Media Type using this = suffix MUST describe how to determine the XML Schema that is used to = encode/decode a payload identified by that Media Type." What it does is = register a generic suffix for a very specific usage. For instance, SVG = has no XML Schema. The above therefore precludes SVG from potentially = registering image/svg+exi (assuming it would be a sensible thing to do). What's more, EXI is not limited to relying on schema information from = XML Schema. It is perfectly valid to use DTDs, RelaxNG, JSON Schema, = domain-specific knowledge, etc. in order to generate a schema-informed = EXI encoding. So the above essentially rules out a large (possibly the = majority) of XML content, and rules out valid EXI encodings. Again, 1) = that seems very restrictive to justify a structured suffix; and 2) it = reinforces the feeling that this registration may be in part motivated = by some misunderstanding of EXI. Thanks! --=20 Robin Berjon - http://berjon.com/ - @robinberjon From msk@cloudmark.com Wed Apr 4 11:32: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 053AF11E808D for ; Wed, 4 Apr 2012 11:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tUB4z8vDTOW for ; Wed, 4 Apr 2012 11:32:16 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2F23611E808A for ; Wed, 4 Apr 2012 11:32:16 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Wed, 4 Apr 2012 11:32:16 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: WGLC for draft-ietf-appsawg-mime-default-charset Thread-Index: Ac0SkUIE/J9NYopZQNuNU3Uqul8O9g== Date: Wed, 4 Apr 2012 18:32:15 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280C9874exchmbx901corpclo_" MIME-Version: 1.0 Subject: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 18:32:17 -0000 --_000_9452079D1A51524AA5749AD23E0039280C9874exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This message starts Working Group Last Call for draft-ietf-appsawg-mime-def= ault-charset. Please review the document and provide comments to the list,= the co-chairs, or the authors by Friday, April 20th. The datatracker link is https://datatracker.ietf.org/doc/draft-ietf-appsawg= -mime-default-charset/. -MSK, APPSAWG co-chair --_000_9452079D1A51524AA5749AD23E0039280C9874exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This message starts Working Group Last Call for draf= t-ietf-appsawg-mime-default-charset.  Please review the document and p= rovide comments to the list, the co-chairs, or the authors by Friday, April= 20th.


The datatracker link is https://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/.

 

-MSK, APPSAWG co-chair

 

--_000_9452079D1A51524AA5749AD23E0039280C9874exchmbx901corpclo_-- From gsalguei@cisco.com Wed Apr 4 12:15: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 33A2811E80BE for ; Wed, 4 Apr 2012 12:15:46 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBlvS9oPH442 for ; Wed, 4 Apr 2012 12:15:45 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 4171111E80AC for ; Wed, 4 Apr 2012 12:15:45 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q34JFgai014932 for ; Wed, 4 Apr 2012 15:15:42 -0400 (EDT) Received: from dhcp-64-102-154-251.cisco.com (dhcp-64-102-154-251.cisco.com [64.102.154.251]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q34JFbrq002189; Wed, 4 Apr 2012 15:15:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: <4F75729F.50903@stpeter.im> Date: Wed, 4 Apr 2012 15:15:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8C9E5284-209A-4BA9-9F55-F8E89A1121A2@cisco.com> References: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> <9452079D1A51524AA5749AD23E0039280C0BFA@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280C0FE9@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C132B@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB50B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C142E@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F75729F.50903@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger 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, 04 Apr 2012 19:15:46 -0000 Peter - Late to this party but I do want to weigh in and agree with what you, = Eran and Paul have stated. This work is very narrowly scoped and adds = minimal normative elements over and above RFC 6415 (primarily the = addition of an acct URI and link rel as well as the resource parameter). = I think the draft clearly states this but I'm willing to add text to = further clarify if some is suggested. The notion of this work being = handled by another WG other than the one that shepherded RFC 6415 = (APPSAWG) seems imprudent. There is plenty of interest in progressing = this work and I'd hate to further delay progress by not being able to = find a suitable home for the document given the work that preceded it = and that it is clearly founded on. =20 Given the narrow focus of the work and the fact that we have received a = significant amount of feedback, we believe this document is fairly = mature and nearing a final form. We have released 3 versions and are = about a week from submitting a fourth based on the latest round of = comments. What is a reasonable way forward to continue the work? Do we = continue it as an individual submission that might be AD-sponsored? Or = do we adopt it as a WG? Thanks! Gonzalo On Mar 30, 2012, at 4:45 AM, Peter Saint-Andre wrote: > On 3/30/12 4:26 AM, Eran Hammer wrote: >> And my answer is that right now it is a small task, but the responses >> indicated that some people might want it to be bigger. >=20 > I also think it's a small task. If some people construe it as larger, > then perhaps we need to clarify the scope in the document. >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From msk@cloudmark.com Wed Apr 4 14:07: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 781D711E8089 for ; Wed, 4 Apr 2012 14:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiygWNiOSHYQ for ; Wed, 4 Apr 2012 14:07:01 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id AC50D21F859E for ; Wed, 4 Apr 2012 14:07:01 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 4 Apr 2012 14:07:01 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Revised webfinger draft (-02) Thread-Index: Ac0NTjN3PPuV9i7nTOWIJZJHpX6j7AAUZkqgAAT2Q5AABFAtMAAAmxdwAACqzvAAASE20AATfYUAASKPkyA= Date: Wed, 4 Apr 2012 21:07:00 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C9D16@exch-mbx901.corp.cloudmark.com> References: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> <9452079D1A51524AA5749AD23E0039280C0BFA@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280C0FE9@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C132B@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB50B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C142E@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280C9D16exchmbx901corpclo_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Revised webfinger 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, 04 Apr 2012 21:07:05 -0000 --_000_9452079D1A51524AA5749AD23E0039280C9D16exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since you pointed out that it could be the case that this is a small task t= hat uses grand language, could the authors consider adjusting the latter co= ndition to highlight the former? That might make adopting it here easier t= o do. -MSK From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, March 29, 2012 7:27 PM To: Murray S. Kucherawy; apps-discuss@ietf.org Subject: RE: [apps-discuss] Revised webfinger draft (-02) And my answer is that right now it is a small task, but the responses indic= ated that some people might want it to be bigger. EH From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 10:12 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) I'm not advocating throwing anything away. I'm proposing figuring out what= path would be most appropriate, regardless of whether it's a new innovatio= n or a derivative innovation. Our charter constrains us to small tasks. If webfinger can legitimately be= characterized as a small task, then we can do a call for adoption. If not= , which seems to be the case, then this isn't the right place for it, and w= e have other procedures for advancing such work. That's the question I'm p= osing here. -MSK From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, March 29, 2012 9:47 AM To: Murray S. Kucherawy; apps-discuss@ietf.org Subject: RE: [apps-discuss] Revised webfinger draft (-02) It would be appropriate for APPSAWG if the scope is narrowly defined as add= ing a few enhancements to RFC 6415 (which *is* what the current draft attem= pts to do, even though its prose might sounds grander). But in the context = of the recent OAuth WG meeting discussing a competing foundation (SWD), a n= ew WG seems to be in order. My concern is that we are reaching a point (or maybe pass it) where progres= sing a work to standards track RFC status no longer translate into requirin= g new work to explain why it cannot build on top of the published standard.= If this body throws away work as recent as October 2011 just because it's = more convenient for some to start from scratch, I don't see why anyone woul= d bother go through the significant cost and effort of getting it published= here in the first place. EH From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 9:18 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) That sounds like a mighty strong statement that, in any case, it's not appr= opriate for APPSAWG. Perhaps the proponents should request a non-WG list to talk about it for a = while to let the problem definition congeal for a while, and then request a= working group when a charter falls out of that. -MSK From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, March 29, 2012 9:03 AM To: Murray S. Kucherawy; apps-discuss@ietf.org Subject: RE: [apps-discuss] Revised webfinger draft (-02) This clearly does not belong in the Security area or the OAuth working grou= p. I would strongly warn that moving this effort into any WG requires very car= eful work on the charter as historically there has been very little consens= us and success in agreeing on what problems we are trying to solve. RFC 641= 5 was the end of a 5+ years process across multiple standard bodies includi= ng the IETF, W3C, OASIS, and the OpenID Foundation. This has proved a reall= y hard problem to *define*. EH From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 6:57 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) Having talked with Barry now, an amended question: Would this work better fit in another working group like OAuth (which has i= ts own interest and concerns in webfinger), or perhaps in its own working g= roup? It may well be that it's too big to fit in APPSAWG's charter for sma= ller work items. -MSK From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 4:35 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) To the working group, This has been hovering outside APPSAWG for two meetings now. Is APPSAWG th= e right place to process it? That is, should we bring it in as a working g= roup document? Or would it be better done through the ISE, or perhaps in s= ome other working group? -MSK From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, March 28, 2012 6:50 PM To: apps-discuss@ietf.org Subject: [apps-discuss] Revised webfinger draft (-02) Folks, I published a revised version of the Webfinger specification based on feedb= ack I've received so far that seems to have general agreement. As request= ed, I added a change log at the end of the document that I hope will help. = The draft is here: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02 The "diff" tool on that page allows you to quickly see exactly what changed= . Paul --_000_9452079D1A51524AA5749AD23E0039280C9D16exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since you pointed out = that it could be the case that this is a small task that uses grand languag= e, could the authors consider adjusting the latter condition to highlight t= he former?  That might make adopting it here easier to do.

 

-MSK=

 

From: Eran Ham= mer [mailto:eran@hueniverse.com]
Sent: Thursday, March 29, 2012 7:27 PM
To: Murray S. Kucherawy; apps-discuss@ietf.org
Subject: RE: [apps-discuss] Revised webfinger draft (-02)=

 

And my answer is that = right now it is a small task, but the responses indicated that some people = might want it to be bigger.

 

EH

 

 

I’m not advocati= ng throwing anything away.  I’m proposing figuring out what path= would be most appropriate, regardless of whether it’s a new innovati= on or a derivative innovation.

 

Our charter constrains= us to small tasks.  If webfinger can legitimately be characterized as= a small task, then we can do a call for adoption.  If not, which seem= s to be the case, then this isn’t the right place for it, and we have other procedures for advancing such work.  That&#= 8217;s the question I’m posing here.

 

-MSK=

 

From: Eran Ham= mer [mailto:eran@hueniverse.com= ]
Sent: Thursday, March 29, 2012 9:47 AM
To: Murray S. Kucherawy; ap= ps-discuss@ietf.org
Subject: RE: [apps-discuss] Revised webfinger draft (-02)=

 

It would be appropriat= e for APPSAWG if the scope is narrowly defined as adding a few enhancements= to RFC 6415 (which *is* what the current draft attempts to do, even= though its prose might sounds grander). But in the context of the recent OAuth WG meeting discussing a competing f= oundation (SWD), a new WG seems to be in order.

 

My concern is that we = are reaching a point (or maybe pass it) where progressing a work to standar= ds track RFC status no longer translate into requiring new work to explain = why it cannot build on top of the published standard. If this body throws away work as recent as October 2011 just bec= ause it’s more convenient for some to start from scratch, I don’= ;t see why anyone would bother go through the significant cost and effort o= f getting it published here in the first place.

 

EH

 

 

 

 

 

That sounds like a mig= hty strong statement that, in any case, it’s not appropriate for APPS= AWG.

 

Perhaps the proponents= should request a non-WG list to talk about it for a while to let the probl= em definition congeal for a while, and then request a working group when a = charter falls out of that.

 

-MSK=

 

From: Eran Ham= mer [mailto:eran@hueniverse.com= ]
Sent: Thursday, March 29, 2012 9:03 AM
To: Murray S. Kucherawy; ap= ps-discuss@ietf.org
Subject: RE: [apps-discuss] Revised webfinger draft (-02)=

 

This clearly does not = belong in the Security area or the OAuth working group.

 

I would strongly warn = that moving this effort into any WG requires very careful work on the chart= er as historically there has been very little consensus and success in agre= eing on what problems we are trying to solve. RFC 6415 was the end of a 5+ years process across multiple s= tandard bodies including the IETF, W3C, OASIS, and the OpenID Foundation. T= his has proved a really hard problem to *define*.<= /p>

 

EH

 

 

Having talked with Bar= ry now, an amended question:

Would this work better fit in another working group like OAuth (which has i= ts own interest and concerns in webfinger), or perhaps in its own working g= roup?  It may well be that it’s too big to fit in APPSAWG’= s charter for smaller work items.

 

-MSK=

 

 

To the working group,<= o:p>

 

This has been hovering= outside APPSAWG for two meetings now.  Is APPSAWG the right place to = process it?  That is, should we bring it in as a working group documen= t?  Or would it be better done through the ISE, or perhaps in some other working group?

 

-MSK=

 
--_000_9452079D1A51524AA5749AD23E0039280C9D16exchmbx901corpclo_-- From tony@att.com Wed Apr 4 15:33: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 C08E111E8122; Wed, 4 Apr 2012 15:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.835 X-Spam-Level: X-Spam-Status: No, score=-102.835 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qJugEg33CWX; Wed, 4 Apr 2012 15:33:12 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1B80511E811E; Wed, 4 Apr 2012 15:33:12 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 72ccc7f4.0.1362671.00-404.3787430.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 04 Apr 2012 22:33:12 +0000 (UTC) X-MXL-Hash: 4f7ccc28596645c1-c70c0a286e1ef63a8c40952db801a3ce74cbd015 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 q34MXBAF012821; Wed, 4 Apr 2012 18:33:11 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q34MX7fR012796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2012 18:33:08 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor); Wed, 4 Apr 2012 18:32:42 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q34MWgBK000912; Wed, 4 Apr 2012 18:32:42 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q34MWeUY000801; Wed, 4 Apr 2012 18:32:40 -0400 Received: from [135.70.246.76] (vpn-135-70-246-76.vpn.east.att.com[135.70.246.76]) by maillennium.att.com (mailgw1) with ESMTP id <20120404222945gw1004oruve> (Authid: tony); Wed, 4 Apr 2012 22:29:45 +0000 X-Originating-IP: [135.70.246.76] Message-ID: <4F7CCC06.7030503@att.com> Date: Wed, 04 Apr 2012 18:32:38 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "domainrep@ietf.org" References: <9452079D1A51524AA5749AD23E0039280C8BC0@exch-mbx901.corp.cloudmark.com> <4F7C4851.4070405@att.com> <4F7C5471.8030309@bbiw.net> In-Reply-To: <4F7C5471.8030309@bbiw.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=lfzeU_yUqTgA:10 a=vnNYxAp2wzwA:10 a=nqx3OqInfd] X-AnalysisOut: [IA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1] X-AnalysisOut: [0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=U0dKssfmjYBsul6zYL0A:9 a=burmj3Rp3i3EbdaRMHwA:7 ] X-AnalysisOut: [a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10] Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] [domainrep] XML vs. JSON examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 22:33:12 -0000 On 4/4/2012 10:02 AM, Dave Crocker wrote: > The latter naming template convention (+xml) is well-established. > > Even if an equivalent convention has not yet been established for > json, it makes sense to reapply the model for naming json-based > media-types. Although draft-ietf-appsawg-media-type-regs both mentions the use of +json and defines a registry that can be used to register it, and despite +json being used already in a variety of registered media types, +json hasn't been formally defined yet. So, I posted draft-hansen-media-type-suffix-regs-00 for consideration to fill in this hole. Discussion of the draft should occur on the APPS AWG mailing list . Tony Hansen tony@att.com From derhoermi@gmx.net Wed Apr 4 16:06: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 01D3E21F8533 for ; Wed, 4 Apr 2012 16:06:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVDaUL66ig7S for ; Wed, 4 Apr 2012 16:06:01 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id AC10821F852B for ; Wed, 4 Apr 2012 16:06:00 -0700 (PDT) Received: (qmail invoked by alias); 04 Apr 2012 23:05:59 -0000 Received: from dslb-094-223-206-119.pools.arcor-ip.net (EHLO HIVE) [94.223.206.119] by mail.gmx.net (mp032) with SMTP; 05 Apr 2012 01:05:59 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/SMbZ/4tLSdTX5hi65PTWKGJJTtLhE1cZuzeyH9r YSc9ObI05TturQ From: Bjoern Hoehrmann To: Tony Hansen Date: Thu, 05 Apr 2012 01:06:06 +0200 Message-ID: References: <9452079D1A51524AA5749AD23E0039280C8BC0@exch-mbx901.corp.cloudmark.com> <4F7C4851.4070405@att.com> <4F7C5471.8030309@bbiw.net> <4F7CCC06.7030503@att.com> In-Reply-To: <4F7CCC06.7030503@att.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "domainrep@ietf.org" , General discussion of application-layer protocols Subject: Re: [apps-discuss] [domainrep] XML vs. JSON examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 23:06:02 -0000 * Tony Hansen wrote: >Although draft-ietf-appsawg-media-type-regs both mentions the use of >+json and defines a registry that can be used to register it, and >despite +json being used already in a variety of registered media types, >+json hasn't been formally defined yet. > >So, I posted draft-hansen-media-type-suffix-regs-00 for consideration to >fill in this hole. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04304.html -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ned.freed@mrochek.com Wed Apr 4 16:38: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 6B42111E80B5; Wed, 4 Apr 2012 16:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yYIEVpV2cEc; Wed, 4 Apr 2012 16:38:50 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id ECEE811E809F; Wed, 4 Apr 2012 16:38:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ODXEGIXFF40058Y9@mauve.mrochek.com>; Wed, 4 Apr 2012 16:38:44 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ODX7A1LRLC00ZUIL@mauve.mrochek.com>; Wed, 4 Apr 2012 16:38:38 -0700 (PDT) Message-id: <01ODXEGFAIIY00ZUIL@mauve.mrochek.com> Date: Wed, 04 Apr 2012 16:38:06 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 05 Apr 2012 01:06:06 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 References: <9452079D1A51524AA5749AD23E0039280C8BC0@exch-mbx901.corp.cloudmark.com> <4F7C4851.4070405@att.com> <4F7C5471.8030309@bbiw.net> <4F7CCC06.7030503@att.com> To: Bjoern Hoehrmann Cc: "domainrep@ietf.org" , General discussion of application-layer protocols Subject: Re: [apps-discuss] [domainrep] XML vs. JSON examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Apr 2012 23:38:50 -0000 > * Tony Hansen wrote: > >Although draft-ietf-appsawg-media-type-regs both mentions the use of > >+json and defines a registry that can be used to register it, and > >despite +json being used already in a variety of registered media types, > >+json hasn't been formally defined yet. > > > >So, I posted draft-hansen-media-type-suffix-regs-00 for consideration to > >fill in this hole. > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04304.html It someone wants to do this registration in an RFC, I have no objection - as long as the RFC in question isn't the registration document itself. Ned From ned.freed@mrochek.com Wed Apr 4 17: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 90D6E11E8135; Wed, 4 Apr 2012 17:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvZ1WiCUg83A; Wed, 4 Apr 2012 17:01:11 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A3DE511E8133; Wed, 4 Apr 2012 17:01:11 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ODXF8A2DPS00WEY6@mauve.mrochek.com>; Wed, 4 Apr 2012 17:01:06 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ODX7A1LRLC00ZUIL@mauve.mrochek.com>; Wed, 4 Apr 2012 17:01:03 -0700 (PDT) Message-id: <01ODXF88B37200ZUIL@mauve.mrochek.com> Date: Wed, 04 Apr 2012 16:53:37 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 04 Apr 2012 18:32:38 -0400" <4F7CCC06.7030503@att.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <9452079D1A51524AA5749AD23E0039280C8BC0@exch-mbx901.corp.cloudmark.com> <4F7C4851.4070405@att.com> <4F7C5471.8030309@bbiw.net> <4F7CCC06.7030503@att.com> To: Tony Hansen Cc: "domainrep@ietf.org" , General discussion of application-layer protocols Subject: Re: [apps-discuss] [domainrep] XML vs. JSON examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 00:01:12 -0000 > On 4/4/2012 10:02 AM, Dave Crocker wrote: > > The latter naming template convention (+xml) is well-established. > > > > Even if an equivalent convention has not yet been established for > > json, it makes sense to reapply the model for naming json-based > > media-types. > Although draft-ietf-appsawg-media-type-regs both mentions the use of > +json and defines a registry that can be used to register it, and > despite +json being used already in a variety of registered media types, > +json hasn't been formally defined yet. > So, I posted draft-hansen-media-type-suffix-regs-00 for consideration to > fill in this hole. The draft looks good to me. The one question I have is whether or not we also want to register +ber for Basic Encoding Rules. +der is actually a subset of +ber, but while some types require use of DER, there are probably some that do not, and using +der for those would be incorrect. And either one can be processed to some extend without the ASN.1 schema. The latter point is why it doesn't make sense to register +per for Packed Encoding Rules. PER cannot be processed without knowing the ASN.1 schema involved, because what's in the schema changes the representation on the wire. I've also never heard of any actual use of PER or Canonical Encoding Rules (CER), so I see no reason to bother with either. Which is a pity, because I like CER a lot more than DER. Ned From tony@att.com Wed Apr 4 20:44: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 24E3A11E80C5; Wed, 4 Apr 2012 20:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.776 X-Spam-Level: X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Siy5c9Raq2v; Wed, 4 Apr 2012 20:44:41 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1498F11E80AB; Wed, 4 Apr 2012 20:44:40 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 8251d7f4.0.1437362.00-304.3989042.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 05 Apr 2012 03:44:41 +0000 (UTC) X-MXL-Hash: 4f7d15295a4bae63-bffd7e3e2735bfdfba63c48424556a8580fccefc 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 q353idON031759; Wed, 4 Apr 2012 23:44:40 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q353iX3n031739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2012 23:44:34 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor); Wed, 4 Apr 2012 23:44:21 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q353iKu1004119; Wed, 4 Apr 2012 23:44:20 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q353iECe003957; Wed, 4 Apr 2012 23:44:16 -0400 Received: from [135.70.50.134] (vpn-135-70-50-134.vpn.west.att.com[135.70.50.134]) by maillennium.att.com (mailgw1) with ESMTP id <20120405034118gw1004orv7e> (Authid: tony); Thu, 5 Apr 2012 03:41:19 +0000 X-Originating-IP: [135.70.50.134] Message-ID: <4F7D150B.1000604@att.com> Date: Wed, 04 Apr 2012 23:44:11 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "domainrep@ietf.org" , General discussion of application-layer protocols References: <9452079D1A51524AA5749AD23E0039280C8BC0@exch-mbx901.corp.cloudmark.com> <4F7C4851.4070405@att.com> <4F7C5471.8030309@bbiw.net> <4F7CCC06.7030503@att.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=mW1RiBFPTJEA:10 a=vnNYxAp2wzwA:10 a=WtyMWy3etK] X-AnalysisOut: [IA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1] X-AnalysisOut: [0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=aHbQn7i] X-AnalysisOut: [Ur0rU4xo5ydYA:9 a=wPNLvfGTeEIA:10 a=GD-vvujBj0gA:10 a=2i86] X-AnalysisOut: [k7FQ2MBY2oPB:21] Subject: Re: [apps-discuss] [domainrep] XML vs. JSON examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 03:44:42 -0000 Hmmm, interesting. Even though I'm a co-author on that doc, I forgot about that particular tidbit in it. :-) I still think it's worth separating out the registration of these suffixes and making them explicit. Tony Hansen On 4/4/2012 7:06 PM, Bjoern Hoehrmann wrote: > * Tony Hansen wrote: >> Although draft-ietf-appsawg-media-type-regs both mentions the use of >> +json and defines a registry that can be used to register it, and >> despite +json being used already in a variety of registered media types, >> +json hasn't been formally defined yet. >> >> So, I posted draft-hansen-media-type-suffix-regs-00 for consideration to >> fill in this hole. > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04304.html From paulej@packetizer.com Wed Apr 4 23:08: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 817CD21F85DB for ; Wed, 4 Apr 2012 23:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0Ap3m+xGjex for ; Wed, 4 Apr 2012 23:08:37 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BEAD421F8685 for ; Wed, 4 Apr 2012 23:08:36 -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 q3568BQp019471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2012 02:08:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333606092; bh=EHMvx5IVyOGK1G1kBElOVdnrmBYqphGYHUwl7qwD0G8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=rUVq3OUD45v/Vd6nOzZ1mYv6cVKzWqsETIeapbNWxibxXMrkjSbyfUtXO01HO/KZe tliPJITFaCMbqvAKTbsHB5skKiD5N4MRaX9+sDnz08n1NelX2gewVlAsUXk54HQMZX pxK27uBhwfxojtnDGYAahL2/QHPV0r5zNoflvQgg= From: "Paul E. Jones" To: "'Murray S. Kucherawy'" , References: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> <9452079D1A51524AA5749AD23E0039280C0BFA@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280C0FE9@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C132B@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB50B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C142E@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C9D16@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C9D16@exch-mbx901.corp.cloudmark.com> Date: Thu, 5 Apr 2012 02:08:15 -0400 Message-ID: <006801cd12f2$7dccc5d0$79665170$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01CD12D0.F6BFE0C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIu9uTQOHonqm8rGpkT+zjk6FKq9wFMvbOwAZNX8mkBehjPOwIT3OQgAaXbFDQDlfxh1wHdyPIrAi7y8dqVSjWoAA== Content-Language: en-us Subject: Re: [apps-discuss] Revised webfinger 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, 05 Apr 2012 06:08:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0069_01CD12D0.F6BFE0C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Murray, WebFinger is a concept that has been under discussion for a long time, both inside and outside the IETF. The core foundation of WebFinger is documented in RFC 6415, which defines how to query for host metadata and to build a resource descriptor document for a given resource. This is what we need to discover information about people and objects, though it does not say explicitly how one should discover information about a person. It stops just short of that, leaving open the options of using an email address, something like an email address, etc. Discussion continued on that and folks converged on the "acct" URI scheme. There was also discussion that we needed to mandate JSON to appeal to most developers. RFC 6415 specifies both and recommends that servers support JSON, but only requires XML. Numerous people wanted to see that changed, some arguing for JSON only. We took the compromising position of requiring the server to provide both. (It's trivial to implement on the server side and allows the client to use what it prefers.) There were also requests on the Webfinger (external) list to support CORS. So with those points of convergence, we drafted the WebFinger spec to build on RFC 6415, adding the things people wanted in WebFinger. The draft: . Introduces the acct URI scheme for use with RFC 6415 . Introduces the acct link relation for the same (as per RFC 5988) . Mandates server-side support for JRD (defined in RFC 6415) . Mandates server-side use of CORS . Introduces a "resource" parameter to be used with RFC 6415 What I have observed is that there are a number of people who have been following and participating in the work on WebFinger. Those people see this draft as "completing the work" by registering the "acct" (user account) related URI scheme and link relation and specifying those other few things. Then there is the group of people who I believe were largely unaware of RFC 6415's existence. That may not be correct, but I got the impression that some believed we were creating everything from scratch in this draft, while were actually just building on RFC 6415. As an example, one person commented that "LRDD" was not defined. Indeed, our draft does not define it, since it was defined in RFC 6415. One person stated that JRD is only documented on a blog, apparently unaware that JRD is defined and documented in RFC 6415. So, I submit that the draft is not using grand language and makes no attempt to appear bigger than it is. What I believe we have is two camps: those who have been following the work and see it for what it is and those who have not and are seeing this for the first time. This is not unexpected, though I do not want people to be left with the impression that this is all new. I think that's the most important misconception to address. I hope this message clarifies the situation. I, too, would like to see work on this document go forward. This is the WG where discussion took place on RFC 6415, so I assume it is the right venue for these extensions to that document. It's certainly not a significant amount of work and not "foreign" work to this group. (I believe my email might actually be approaching then length of the draft now, so I should stop.) Paul From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Wednesday, April 04, 2012 5:07 PM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) Since you pointed out that it could be the case that this is a small task that uses grand language, could the authors consider adjusting the latter condition to highlight the former? That might make adopting it here easier to do. -MSK From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, March 29, 2012 7:27 PM To: Murray S. Kucherawy; apps-discuss@ietf.org Subject: RE: [apps-discuss] Revised webfinger draft (-02) And my answer is that right now it is a small task, but the responses indicated that some people might want it to be bigger. EH From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 10:12 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) I'm not advocating throwing anything away. I'm proposing figuring out what path would be most appropriate, regardless of whether it's a new innovation or a derivative innovation. Our charter constrains us to small tasks. If webfinger can legitimately be characterized as a small task, then we can do a call for adoption. If not, which seems to be the case, then this isn't the right place for it, and we have other procedures for advancing such work. That's the question I'm posing here. -MSK From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, March 29, 2012 9:47 AM To: Murray S. Kucherawy; apps-discuss@ietf.org Subject: RE: [apps-discuss] Revised webfinger draft (-02) It would be appropriate for APPSAWG if the scope is narrowly defined as adding a few enhancements to RFC 6415 (which *is* what the current draft attempts to do, even though its prose might sounds grander). But in the context of the recent OAuth WG meeting discussing a competing foundation (SWD), a new WG seems to be in order. My concern is that we are reaching a point (or maybe pass it) where progressing a work to standards track RFC status no longer translate into requiring new work to explain why it cannot build on top of the published standard. If this body throws away work as recent as October 2011 just because it's more convenient for some to start from scratch, I don't see why anyone would bother go through the significant cost and effort of getting it published here in the first place. EH From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 9:18 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) That sounds like a mighty strong statement that, in any case, it's not appropriate for APPSAWG. Perhaps the proponents should request a non-WG list to talk about it for a while to let the problem definition congeal for a while, and then request a working group when a charter falls out of that. -MSK From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, March 29, 2012 9:03 AM To: Murray S. Kucherawy; apps-discuss@ietf.org Subject: RE: [apps-discuss] Revised webfinger draft (-02) This clearly does not belong in the Security area or the OAuth working group. I would strongly warn that moving this effort into any WG requires very careful work on the charter as historically there has been very little consensus and success in agreeing on what problems we are trying to solve. RFC 6415 was the end of a 5+ years process across multiple standard bodies including the IETF, W3C, OASIS, and the OpenID Foundation. This has proved a really hard problem to *define*. EH From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 6:57 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) Having talked with Barry now, an amended question: Would this work better fit in another working group like OAuth (which has its own interest and concerns in webfinger), or perhaps in its own working group? It may well be that it's too big to fit in APPSAWG's charter for smaller work items. -MSK From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 4:35 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) To the working group, This has been hovering outside APPSAWG for two meetings now. Is APPSAWG the right place to process it? That is, should we bring it in as a working group document? Or would it be better done through the ISE, or perhaps in some other working group? -MSK From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, March 28, 2012 6:50 PM To: apps-discuss@ietf.org Subject: [apps-discuss] Revised webfinger draft (-02) Folks, I published a revised version of the Webfinger specification based on feedback I've received so far that seems to have general agreement. As requested, I added a change log at the end of the document that I hope will help. The draft is here: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02 The "diff" tool on that page allows you to quickly see exactly what changed. Paul ------=_NextPart_000_0069_01CD12D0.F6BFE0C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Murray,

 

WebFinger is a concept = that has been under discussion for a long time, both inside and outside = the IETF.  The core foundation of WebFinger is documented in RFC = 6415, which defines how to query for host metadata and to build a = resource descriptor document for a given resource.  This is what we = need to discover information about people and objects, though it does = not say explicitly how one should discover information about a = person.  It stops just short of that, leaving open the options of = using an email address, something like an email address, etc.  = Discussion continued on that and folks converged on the = “acct” URI scheme.

 

There was also = discussion that we needed to mandate JSON to appeal to most = developers.  RFC 6415 specifies both and recommends that servers = support JSON, but only requires XML.  Numerous people wanted to see = that changed, some arguing for JSON only.  We took the compromising = position of requiring the server to provide both.  (It’s = trivial to implement on the server side and allows the client to use = what it prefers.)   There were also requests on the Webfinger = (external) list to support CORS.

 

So with those points of = convergence, we drafted the WebFinger spec to build on RFC 6415, adding = the things people wanted in WebFinger.  The = draft:

·         = Introduces = the acct URI scheme for use with RFC 6415

·         = Introduces = the acct link relation for the same (as per RFC = 5988)

·         = Mandates = server-side support for JRD (defined in RFC = 6415)

·         = Mandates = server-side use of CORS

·         = Introduces = a “resource” parameter to be used with RFC = 6415

 

What I have observed is = that there are a number of people who have been following and = participating in the work on WebFinger.  Those people see this = draft as “completing the work” by registering the = “acct” (user account) related URI scheme and link relation = and specifying those other few things.

 

Then there is the group = of people who I believe were largely unaware of RFC 6415’s = existence.  That may not be correct, but I got the impression that = some believed we were creating everything from scratch in this draft, = while were actually just building on RFC 6415.  As an example, one = person commented that “LRDD” was not defined.  Indeed, = our draft does not define it, since it was defined in RFC 6415.  = One person stated that JRD is only documented on a blog, apparently = unaware that JRD is defined and documented in RFC = 6415.

 

So, I submit that the = draft is not using grand language and makes no attempt to appear bigger = than it is.  What I believe we have is two camps: those who have = been following the work and see it for what it is and those who have not = and are seeing this for the first time.  This is not unexpected, = though I do not want people to be left with the impression that this is = all new.  I think that’s the most important misconception to = address.

 

I hope this message = clarifies the situation.  I, too, would like to see work on this = document go forward.  This is the WG where discussion took place on = RFC 6415, so I assume it is the right venue for these extensions to that = document.  It’s certainly not a significant amount of work = and not “foreign” work to this group.  (I believe my = email might actually be approaching then length of the draft now, so I = should stop.)

 

Paul

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy
Sent: Wednesday, April = 04, 2012 5:07 PM
To: apps-discuss@ietf.org
Subject: = Re: [apps-discuss] Revised webfinger draft = (-02)

 

Since you pointed out that it could be the case = that this is a small task that uses grand language, could the authors = consider adjusting the latter condition to highlight the former?  = That might make adopting it here easier to do.

 

-MSK

 

From:= = Eran Hammer [mailto:eran@hueniverse.com]=
Sent: Thursday, March 29, 2012 7:27 PM
To: = Murray S. Kucherawy; apps-discuss@ietf.org
Sub= ject: RE: [apps-discuss] Revised webfinger draft = (-02)

 

And my answer is that right now it is a small = task, but the responses indicated that some people might want it to be = bigger.

 

EH

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-bounces= @ietf.org] On Behalf Of Murray S. Kucherawy
Sent: = Thursday, March 29, 2012 10:12 AM
To: apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] Revised webfinger draft = (-02)

 

I’m not advocating throwing anything = away.  I’m proposing figuring out what path would be most = appropriate, regardless of whether it’s a new innovation or a = derivative innovation.

 

Our charter constrains = us to small tasks.  If webfinger can legitimately be characterized = as a small task, then we can do a call for adoption.  If not, which = seems to be the case, then this isn’t the right place for it, and = we have other procedures for advancing such work.  That’s the = question I’m posing here.

 

-MSK

 

From:= = Eran Hammer [mailto:eran@hueniverse.com]=
Sent: Thursday, March 29, 2012 9:47 AM
To: = Murray S. Kucherawy; apps-discuss@ietf.org
Sub= ject: RE: [apps-discuss] Revised webfinger draft = (-02)

 

It would be appropriate for APPSAWG if the scope = is narrowly defined as adding a few enhancements to RFC 6415 (which = *is* what the current draft attempts to do, even though its prose = might sounds grander). But in the context of the recent OAuth WG meeting = discussing a competing foundation (SWD), a new WG seems to be in = order.

 

My concern is that we = are reaching a point (or maybe pass it) where progressing a work to = standards track RFC status no longer translate into requiring new work = to explain why it cannot build on top of the published standard. If this = body throws away work as recent as October 2011 just because it’s = more convenient for some to start from scratch, I don’t see why = anyone would bother go through the significant cost and effort of = getting it published here in the first place.

 

EH

 

 

 

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-bounces= @ietf.org] On Behalf Of Murray S. Kucherawy
Sent: = Thursday, March 29, 2012 9:18 AM
To: apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] Revised webfinger draft = (-02)

 

That sounds like a mighty strong statement that, = in any case, it’s not appropriate for = APPSAWG.

 

Perhaps the proponents = should request a non-WG list to talk about it for a while to let the = problem definition congeal for a while, and then request a working group = when a charter falls out of that.

 

-MSK

 

From:= = Eran Hammer [mailto:eran@hueniverse.com]=
Sent: Thursday, March 29, 2012 9:03 AM
To: = Murray S. Kucherawy; apps-discuss@ietf.org
Sub= ject: RE: [apps-discuss] Revised webfinger draft = (-02)

 

This clearly does not belong in the Security = area or the OAuth working group.

 

I would strongly warn = that moving this effort into any WG requires very careful work on the = charter as historically there has been very little consensus and success = in agreeing on what problems we are trying to solve. RFC 6415 was the = end of a 5+ years process across multiple standard bodies including the = IETF, W3C, OASIS, and the OpenID Foundation. This has proved a really = hard problem to *define*.

 

EH

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-bounces= @ietf.org] On Behalf Of Murray S. Kucherawy
Sent: = Thursday, March 29, 2012 6:57 AM
To: apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] Revised webfinger draft = (-02)

 

Having talked with Barry now, an amended = question:

Would this work better fit in another working group = like OAuth (which has its own interest and concerns in webfinger), or = perhaps in its own working group?  It may well be that it’s = too big to fit in APPSAWG’s charter for smaller work = items.

 

-MSK

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discu= ss-bounces@ietf.org] On Behalf Of Murray S. = Kucherawy
Sent: Thursday, March 29, 2012 4:35 AM
To: = apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] Revised webfinger draft = (-02)

 

To the working group,

 

This has been hovering = outside APPSAWG for two meetings now.  Is APPSAWG the right place = to process it?  That is, should we bring it in as a working group = document?  Or would it be better done through the ISE, or perhaps = in some other working group?

 

-MSK

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-bounces= @ietf.org] On Behalf Of Paul E. Jones
Sent: = Wednesday, March 28, 2012 6:50 PM
To: apps-discuss@ietf.org
Sub= ject: [apps-discuss] Revised webfinger draft = (-02)

 

Folks,

 

I published = a revised version of the Webfinger specification based on feedback = I’ve received so far that seems to  have general = agreement.  As requested, I added a change log at the end of the = document that I hope will help.  The draft is = here:

http= ://tools.ietf.org/html/draft-jones-appsawg-webfinger-02

 

The = “diff” tool on that page allows you to quickly see exactly = what changed.

 

Paul

 

------=_NextPart_000_0069_01CD12D0.F6BFE0C0-- From mnot@mnot.net Thu Apr 5 09:25: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 4B63421F872B for ; Thu, 5 Apr 2012 09:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 762MKng5cadk for ; Thu, 5 Apr 2012 09:25:09 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9944F21F8710 for ; Thu, 5 Apr 2012 09:25:09 -0700 (PDT) Received: from [10.6.129.168] (unknown [50.56.228.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B221822E253; Thu, 5 Apr 2012 12:25:02 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Apr 2012 11:25:01 -0500 Message-Id: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> To: erik.wilde@emc.com Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org application-layer protocols" Subject: [apps-discuss] Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 16:25:10 -0000 Overall, I'm really happy to see this draft; have been considering doing = something along these lines too. That said: *** Major issues * "Resource Profiles" - this spec defines the profile is being about the = *resource* of its context. This is too loose; in HTML and other uses = I've seen, profiles are about the *representation* they occur within. In other words, the common idea of a profile, IME, is that it describes = the conventions, extensions, etc. that are used in a particular = document, but it doesn't say anything about the resource that the = document was retrieved from. That's a good design, because link relations are already a defined = mechanism to talk about resource behaviours; having two such mechanisms = isn't a good idea (at least without some discussion). E.g., when I interact with a resource, I know it supports particular = behaviours, because it's been linked to with relation "Foo." When I get = a representation from the "Foo" resource, it will have a media type that = describes the format, and also a profile ("Bar") that describes = additional features / conventions of that document (such as a particular = use of JSON or XML), but that profile won't -- and shouldn't! -- be an = additional way of describing the behaviours of the "Foo" resource. *** Nits / minor feedback: * """This link relation type is independent of the resource = representation it is used in (but the representation must support types = links for this mechanism to work)""" I'd state this in terms of "context", as per the link RFC. * s/must support types links/must support typed links/ * """ In fact, for the purpose of this specification, the URI does not necessarily have to link to a dereferencable resource, and clients can treat the occurrence of a specific URI in the same sense as a namespace URI and invoke specific behavior based on the assumption that a specific profile URI signals that a resource follows a specific profile. """ Here, I'd state this in terms of "target URIs", as does the link RFC. * Your Security Considerations section isn't going to pass muster; if it = were me, I'd talk about how software shouldn't make security-sensitive = assumptions based upon profiles. *""" As one example, consider the case of podcasts, a specific kind of feed using additional fields for media-related metadata. Using a 'profile' link, it would be possible for a client to understand that a specific feed is supposed to be a podcast feed, and that it may contain entries using podcast-specific fields. This may allow a client to behave differently when handling such a feed (such as rendering a UI), even when the current set of entries in the feed may not contain any podcast entries. """ This is an interesting use case. My use cases for "profile" tend to be = things like "links that this document contain follow *this* convention". = More examples would be good. Cheers, -- Mark Nottingham http://www.mnot.net/ From stephen.farrell@cs.tcd.ie Thu Apr 5 13:10: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 D0AAF21F8685 for ; Thu, 5 Apr 2012 13:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I98zRTpFLV4l for ; Thu, 5 Apr 2012 13:10:48 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B85021F8663 for ; Thu, 5 Apr 2012 13:10:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E7FCD171C02 for ; Thu, 5 Apr 2012 21:10:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1333656647; bh=fh7mClla1kKULT0hm2rAAtJh UdystROWWgkKfPmZB9Y=; b=s7lWVskzaqy3+wvnIFjXRB+x0lRC93jAYXc/itnz nGh+kYRmTN2iwSxC6BLiX1fAcmUivvmmh8+dgmc7npuU8zzcechJ8DFSzUhu8dbV i9mEriNfK9rEexhaC73civR28FnEnwhNoGc9UlfLsUHhEMmwkXS/tz9SVDMJwqSQ 61AxhrL9W4R9CztnLXIiUlWfdf0sAt7LghXE9oyICCeKj6MYUWr5kMLUdff/h3zD 3LBFgBGVyilSSgASteLs2mZklTMz1WZ1gFi1t8X3R3qzCt4UlEe9Nljwid3zy0lG QdC6ag0RHvHhH/U05WFAR1S6c2ygnF2qv3Zy3lYyOAiz1A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id PL4N+EIgNO7s for ; Thu, 5 Apr 2012 21:10:47 +0100 (IST) Received: from [10.87.48.3] (unknown [86.41.2.139]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id AE0E6171BFD for ; Thu, 5 Apr 2012 21:10:47 +0100 (IST) Message-ID: <4F7DFC47.2020604@cs.tcd.ie> Date: Thu, 05 Apr 2012 21:10:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] draft-farrell-decade-ni-02 - we think this is done... X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 20:10:49 -0000 ...well, modulo one or two questions still in the document [1] and getting your review:-) This document has been discussed in the decade WG as a way to standardise how to emded hashes into names, which is something that'll likely be needed there but is clearly more general. As if to prove that, at IETF-83 we added a binary form that seems to better fit what the core WG want for doing the same thing in CoAP. We've worked on it a good bit in the time since and so we reckon this is pretty much ready now. Our plan is to try get comments from the decade, core and appsarea lists and if we're looking good to then ask Barry Leiba if he'll AD sponsor this document, so it can be done in time to not slow down CoAP. (Barry's ok with this plan.) So, please take a read if you're interested in naming things with hashes and send your comments. Since this was first discussed on the decade list, I'll suggest using that [2] as a good place to send comments. Any of the above-mentioned lists will work though, since various authors are on each. Probably better to not cross-post to them all though. (I've sent separate mails to each for that reason.) Thanks, Stephen. [1] http://tools.ietf.org/html/draft-farrell-decade-ni [2] https://www.ietf.org/mailman/listinfo/decade From stpeter@stpeter.im Thu Apr 5 13:58: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 2E73721F866B for ; Thu, 5 Apr 2012 13:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpSzHpwDz6jx for ; Thu, 5 Apr 2012 13:58:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B4CEA21F8663 for ; Thu, 5 Apr 2012 13:58:07 -0700 (PDT) Received: from dhcp-64-101-72-239.cisco.com (unknown [64.101.72.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DDA2740058; Thu, 5 Apr 2012 15:11:39 -0600 (MDT) Message-ID: <4F7E075D.6000300@stpeter.im> Date: Thu, 05 Apr 2012 14:58:05 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Stephen Farrell References: <4F7DFC47.2020604@cs.tcd.ie> In-Reply-To: <4F7DFC47.2020604@cs.tcd.ie> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-farrell-decade-ni-02 - we think this is done... X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 20:58:08 -0000 On 4/5/12 2:10 PM, Stephen Farrell wrote: > > ...well, modulo one or two questions still in the document [1] > and getting your review:-) Looks good! /psa From martin.thomson@gmail.com Thu Apr 5 14:22: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 AA2BE21F866B for ; Thu, 5 Apr 2012 14:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.474 X-Spam-Level: X-Spam-Status: No, score=-4.474 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHt1wLqcCcSe for ; Thu, 5 Apr 2012 14:22:58 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC7DA21F860E for ; Thu, 5 Apr 2012 14:22:57 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1789556bku.31 for ; Thu, 05 Apr 2012 14:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ixk4rtsUwXsKzukIghYxjgI7eZAaSIpILXWECE9upBs=; b=SRR6Vbmk+VKZqcwGJtFTzh69buSS9aY6yrqXbiVP9N+J1L8DzVUeOj6pSrW/9smnJO tW4YQcsgugG4Hbl0OnTbPONm2Q5ZrU9XqfVtStKNoHtBn4yA4n22iFxQ+LUHtBHlOL3c S5xOd1ss7Wp4YqWKrRyVGOzdtTBmtBEVeGJB3/4RCNZHyYVN+H96MXf8R88Pyka0nsla T3i0sP/31hSE0qtb198Cw1wdeC7qIM1E+YwEv3F56v3jOWafbw5cFMwMaBSp2e7jh3xh QZKJmNg3dnY2Jm1JGtJw0JWZ0ix9A92g1j35dduwFzLsZug30+rWRa8Pp30DNruU6b1J 0Hwg== MIME-Version: 1.0 Received: by 10.205.129.4 with SMTP id hg4mr2124771bkc.16.1333660967574; Thu, 05 Apr 2012 14:22:47 -0700 (PDT) Received: by 10.205.38.73 with HTTP; Thu, 5 Apr 2012 14:22:47 -0700 (PDT) In-Reply-To: <4F7DFC47.2020604@cs.tcd.ie> References: <4F7DFC47.2020604@cs.tcd.ie> Date: Thu, 5 Apr 2012 14:22:47 -0700 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-farrell-decade-ni-02 - we think this is done... X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 21:22:58 -0000 On 5 April 2012 13:10, Stephen Farrell wrote: > So, please take a read if you're interested in naming things > with hashes and send your comments. This is my remaining concern. The draft uses /.well-known/ as the base "locator". That severely limits its use. Access to /.well-known/ is necessarily constrained. I might want to identify a resource outside of /.well-known/. I might also want to identify a resource that is served elsewhere. I can't do either with this scheme. I'd prefer something that allowed for the embedding of a complete HTTP URI. Bonus credit for embedding a any URI. From stephen.farrell@cs.tcd.ie Thu Apr 5 14:25: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 DFA2621F860E for ; Thu, 5 Apr 2012 14:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOyKRzLLo1pw for ; Thu, 5 Apr 2012 14:25:31 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFF421F8694 for ; Thu, 5 Apr 2012 14:25:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 49B4A171C02; Thu, 5 Apr 2012 22:25:30 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1333661130; bh=0fFQFLOrDdkfGL Rcsjag7wSNnmZW1uFfYkV32YRJBK4=; b=pwOuPmBnS7lbyWA4Ch5IwKoohgHYeP 6pE8da7t2bqd0W2uhVTUZvkCPj6++msmSInGNqbUYRvhYwucNRVWZji/he+l+5ak 9LhlK0OS7x5jF623yz0O3LzSpYxUrOuA9A84XfaTPprHvyx2/gEiP9KhvxblQ7fj vxyHh8iD3B08PmnR8dPEb7trtTlviSHSS7Ffs5DOjIW+2UxG9anx4iYD9TDSQTP/ DEa4xuibWTR6zLi+FHWz0wkRiEUF9F1aId1bvMr1gR+ZT6mvI7dL1WV+ChyWHBrO A0EE1Zoier5T1Ub9gNUeCDUc6j5eXvbIQNpsFl9iMdAH8CznPmGVbv5w== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Ub0XW18+EcWe; Thu, 5 Apr 2012 22:25:30 +0100 (IST) Received: from [10.87.48.4] (unknown [86.46.29.158]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3FD83171BFD; Thu, 5 Apr 2012 22:25:29 +0100 (IST) Message-ID: <4F7E0DC8.8030707@cs.tcd.ie> Date: Thu, 05 Apr 2012 22:25:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Martin Thomson References: <4F7DFC47.2020604@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-farrell-decade-ni-02 - we think this is done... X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 21:25:33 -0000 On 04/05/2012 10:22 PM, Martin Thomson wrote: > On 5 April 2012 13:10, Stephen Farrell wrote: >> So, please take a read if you're interested in naming things >> with hashes and send your comments. > > This is my remaining concern. The draft uses /.well-known/ as the > base "locator". That severely limits its use. Access to > /.well-known/ is necessarily constrained. > > I might want to identify a resource outside of /.well-known/. I might > also want to identify a resource that is served elsewhere. I can't do > either with this scheme. > > I'd prefer something that allowed for the embedding of a complete HTTP > URI. Bonus credit for embedding a any URI. Sure. We added that though in section 5. (For URLs anyway.) Be glad to add more text that makes that clear, and happy to say its usable with other schemes if you can offer good words for that. Cheers, S. > From martin.thomson@gmail.com Thu Apr 5 14:30: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 7C65421F86A0 for ; Thu, 5 Apr 2012 14:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuSNhofHefuD for ; Thu, 5 Apr 2012 14:30:21 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26A2321F869E for ; Thu, 5 Apr 2012 14:30:20 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1794081bku.31 for ; Thu, 05 Apr 2012 14:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UlTNcPLpxyjATn1Rh+dABP2NS9/i9VuleThi4459lZY=; b=ytCSqyOQ2fjBnHDgts6NkbJa4EqXv5RQhVnh7Y929QSuPTdJOgFhTzZWlp9hxzqxY6 XvYFDVGTpxbuNTSx3fTrtBrUW815Lxl6lr9ZM+VevID0p0DeUxC7wqlk7uqUAEQHg4+Q 7Eb4nCxE/OoV794D2ht9sEGfeIl4uUvsA40pXoy2DSKTxYipfRetopuSVjl4vBi+HMV6 7iqDMd2VY0nLs62GEksxh1sxsX5P9QzJh3BbrcMDQgMk45RIhVblbbfaJi6lEaE/VevW skoQRgX8zCGBWo5YIAEQntUVA4Bk5OTCocZSOba61YHTANZL1RKBHq8Z+jpEXW0jwL0w Vmwg== MIME-Version: 1.0 Received: by 10.204.154.82 with SMTP id n18mr2024594bkw.85.1333661415560; Thu, 05 Apr 2012 14:30:15 -0700 (PDT) Received: by 10.205.38.73 with HTTP; Thu, 5 Apr 2012 14:30:15 -0700 (PDT) In-Reply-To: <4F7E0DC8.8030707@cs.tcd.ie> References: <4F7DFC47.2020604@cs.tcd.ie> <4F7E0DC8.8030707@cs.tcd.ie> Date: Thu, 5 Apr 2012 14:30:15 -0700 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-farrell-decade-ni-02 - we think this is done... X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 21:30:22 -0000 On 5 April 2012 14:25, Stephen Farrell wrote: >> I might want to identify a resource outside of /.well-known/. =C2=A0I mi= ght >> also want to identify a resource that is served elsewhere. =C2=A0I can't= do >> either with this scheme. > > Sure. We added that though in section 5. (For URLs anyway.) > Be glad to add more text that makes that clear, and happy > to say its usable with other schemes if you can offer good > words for that. That doesn't quite do it. If I understand correctly, you want someone to look at a URI and "know" that this particular path component is actually a hash. What I want to do is provide an ni: URI that wraps: http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.18/jquery-ui.min.js And have clients (say my browser) load that URI and be able to check that the content is the right content. Without knowledge of URI components that should be opaque. That is, I want a mechanism for dealing with mixed content (see plenary) that doesn't require TLS. This might be done by something like: ni:sha256:blah:http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.18/jquery-= ui.min.js Though that completely ruins your nice URI form. From cabo@tzi.org Thu Apr 5 14:56: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 3588E21F8592 for ; Thu, 5 Apr 2012 14:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.949 X-Spam-Level: X-Spam-Status: No, score=-106.949 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOYZwCpS194U for ; Thu, 5 Apr 2012 14:56:40 -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 2299C21F859F for ; Thu, 5 Apr 2012 14:56:39 -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 q35LuT33002789; Thu, 5 Apr 2012 23:56:29 +0200 (CEST) Received: from [192.168.217.117] (p5489AB9F.dip.t-dialin.net [84.137.171.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 457ED7CD; Thu, 5 Apr 2012 23:56:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F7DFC47.2020604@cs.tcd.ie> Date: Thu, 5 Apr 2012 23:56:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F7DFC47.2020604@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1257) Cc: Apps Discuss Subject: Re: [apps-discuss] draft-farrell-decade-ni-02 - we think this is done... X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 21:56:41 -0000 ** Summary: This may seem nearly trivial, but upon looking closer really is awesome = work, something truly only the IETF could create. ** Nits: What is a "thing"? (abstract) The reference from section 3 to section 9.1 appears wrong -- I don't = think 9.1 actually defines the registry required here. If this is referencing 9.3, please make sure there that the "ID" column = is left empty (and thus no number consumed) if a number for the binary = encoding is not needed. I don't like the sentence Since application code often attempts to enforce such encoding, decoders MUST recognize the use of URI escape encoding. and the following sentences too much -- yes, you MUST implement URI = syntax, but not just for this reason. Add examples of percent-decoding (implementers implement from = examples!). How useful is: If an application is presented with a HTTP(S) URL with "/.well- known/ni/" as the start of its pathname component, then the reverse mapping to an ni URI either including or excluding the authority might produce an ni URI that is meaningful, but there is no guarantee that this will be the case. Wouldn't it be more appropriate to mandate that /.well-known/ni *MUST* = only be used in a way that makes this reverse mapping useful? s/URL Fragment/URL Segment/ (Fragment is confusing, as it means = something specific in URIs.) Maybe the human-readable form should be prefixed by "ni;" so it is = easily recognizable. = http://www.tcd.ie/.well-known/ni/sha256/UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQ= AlMO2X_-Q does not resolve (maybe you meant example.com?). I believe for this to be the replacement of "unsecure links out of = HTTPS", the secure media type issue must be solved in the base spec. (Oh, and is there ever a need to discuss content-coding in this = context???) Please re-spin = http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-00 and = make sure that Martin's concern is addressed... ** PS Again, I'm still in awe that a 10-page specification can solve so many = problems in one fell swoop. Gr=FC=DFe, Carsten From tzink@filtering.exchange.microsoft.com Thu Apr 5 15:18:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FC921F85C0 for ; Thu, 5 Apr 2012 15:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.669 X-Spam-Level: X-Spam-Status: No, score=-109.669 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uefq+1lJcDf for ; Thu, 5 Apr 2012 15:18:03 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id ACD1D21F85BD for ; Thu, 5 Apr 2012 15:18:03 -0700 (PDT) Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.3.5.0; Thu, 5 Apr 2012 15:18:03 -0700 Received: from DF-PIO-15M30.exchange.corp.microsoft.com (157.54.94.27) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.3.5.1; Thu, 5 Apr 2012 15:18:02 -0700 Received: from DF-PIO-15M30.exchange.corp.microsoft.com (2001:4898:c8:601d:a0fc:4f2e:176:913d) by DF-PIO-15M30.exchange.corp.microsoft.com (2001:4898:c8:601d:a0fc:4f2e:176:913d) with Microsoft SMTP Server (TLS) id 15.0.412.1; Thu, 5 Apr 2012 15:16:56 -0700 Received: from DF-PIO-15M30.exchange.corp.microsoft.com ([fe80::a0fc:4f2e:176:913d]) by DF-PIO-15M30.exchange.corp.microsoft.com ([fe80::bd46:865e:1d46:569%16]) with mapi id 15.00.0412.001; Thu, 5 Apr 2012 15:16:56 -0700 From: Terry Zink To: "apps-discuss@ietf.org" Thread-Topic: Looking to begin discussion about email and IPv6 Thread-Index: Ac0TcNVZC8yfbKKgTYyJdsZe8IIhSAACEtKA Date: Thu, 5 Apr 2012 22:16:53 +0000 Message-ID: <7c2b29c999e1441890f63fbb91692de0@DF-PIO-15M30.exchange.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:dc05:24:781f:fa9b:73b7:cd5d] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [apps-discuss] Looking to begin discussion about email and IPv6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 22:18:04 -0000 Hi, everyone, I am new to the IETF process but have wanted to get involved for some time.= =20 I browsed through the various working groups and I didn't any that were rel= ated to the topic I need to discuss, so I am bringing it up here. If need = be, perhaps we can create a separate WG. The topic I want to discuss is IPv6 and email. At the Paris IETF, one of m= y colleagues presented some slides I drew up regarding the problem of email= and IPv6. Because of widespread abuse of SMTP today in IPv4, the email in= dustry is hesitant to move to IPv6 for sending anonymous email as the curre= nt techniques in use will not scale. Has anyone else addressed this? There are workarounds floating around but = most of what we see today is that most people don't send mail over IPv6 and= those that do know who they want to receive it from. The problem is that = once IPv6 becomes mainstream, eventually we will "build a better spammer" a= nd the problem of abuse would swamp email servers. I have some ideas on how to address this, at least in the short term. I'd = also like go gauge interest for discussing this at the Vancouver IETF at th= e end of July. Thanks. -- Terry From marc.blanchet@viagenie.ca Thu Apr 5 15:30: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 ECACC21F8710 for ; Thu, 5 Apr 2012 15:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.829 X-Spam-Level: X-Spam-Status: No, score=-101.829 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q68I9qCQeuhg for ; Thu, 5 Apr 2012 15:30:43 -0700 (PDT) Received: from blues.viagenie.ca (blues.viagenie.ca [66.228.45.110]) by ietfa.amsl.com (Postfix) with ESMTP id 156D521F86F1 for ; Thu, 5 Apr 2012 15:30:43 -0700 (PDT) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by blues.viagenie.ca (Postfix) with ESMTPSA id 45B7D1C269; Thu, 5 Apr 2012 18:30:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <7c2b29c999e1441890f63fbb91692de0@DF-PIO-15M30.exchange.corp.microsoft.com> Date: Thu, 5 Apr 2012 18:30:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7c2b29c999e1441890f63fbb91692de0@DF-PIO-15M30.exchange.corp.microsoft.com> To: Terry Zink X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Looking to begin discussion about email and IPv6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 22:30:44 -0000 to me, the issue is real and relevant to IETF and apps area is a good = place to start discussing. I would suggest you to write an = internet-draft describing first the problem and maybe/optional the = solution space you are thinking. =20 if you don't know how to start writing an Internet-draft, either take a = look at another one or see: http://www.ietf.org/tao.html#anchor38 marc. Le 2012-04-05 =E0 18:16, Terry Zink a =E9crit : > Hi, everyone, >=20 > I am new to the IETF process but have wanted to get involved for some = time. =20 >=20 > I browsed through the various working groups and I didn't any that = were related to the topic I need to discuss, so I am bringing it up = here. If need be, perhaps we can create a separate WG. >=20 > The topic I want to discuss is IPv6 and email. At the Paris IETF, one = of my colleagues presented some slides I drew up regarding the problem = of email and IPv6. Because of widespread abuse of SMTP today in IPv4, = the email industry is hesitant to move to IPv6 for sending anonymous = email as the current techniques in use will not scale. >=20 > Has anyone else addressed this? There are workarounds floating around = but most of what we see today is that most people don't send mail over = IPv6 and those that do know who they want to receive it from. The = problem is that once IPv6 becomes mainstream, eventually we will "build = a better spammer" and the problem of abuse would swamp email servers. >=20 > I have some ideas on how to address this, at least in the short term. = I'd also like go gauge interest for discussing this at the Vancouver = IETF at the end of July. >=20 > Thanks. >=20 > -- Terry > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From msk@cloudmark.com Thu Apr 5 15:38: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 70E4C21F86D5 for ; Thu, 5 Apr 2012 15:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.921 X-Spam-Level: X-Spam-Status: No, score=-101.921 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgwHeS5gX1r6 for ; Thu, 5 Apr 2012 15:38:24 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAF721F8686 for ; Thu, 5 Apr 2012 15:38:24 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 5 Apr 2012 15:38:24 -0700 From: "Murray S. Kucherawy" To: Terry Zink , "apps-discuss@ietf.org" Thread-Topic: Looking to begin discussion about email and IPv6 Thread-Index: Ac0TcNVZC8yfbKKgTYyJdsZe8IIhSAACEtKAAACBPnA= Date: Thu, 5 Apr 2012 22:38:22 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280CC331@exch-mbx901.corp.cloudmark.com> References: <7c2b29c999e1441890f63fbb91692de0@DF-PIO-15M30.exchange.corp.microsoft.com> In-Reply-To: <7c2b29c999e1441890f63fbb91692de0@DF-PIO-15M30.exchange.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Looking to begin discussion about email and IPv6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 22:38:25 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Terry Zink > Sent: Thursday, April 05, 2012 3:17 PM > To: apps-discuss@ietf.org > Subject: [apps-discuss] Looking to begin discussion about email and IPv6 >=20 > [...] > I have some ideas on how to address this, at least in the short term. > I'd also like go gauge interest for discussing this at the Vancouver > IETF at the end of July. Hi Terry, This is a frequent topic in industry, especially at the Messaging Anti-Abus= e Working Group (MAAWG, http://www.maawg.org) which is not part of IETF. Y= ou'd probably get a lot of interested people if you put together a BoF ther= e. You can probably get some people together at IETF in Vancouver too for = a bar BoF. Off the top of my head, I can only think of this document (now expired) on = the topic: https://datatracker.ietf.org/doc/draft-oreirdan-rosenwald-ipv6mail-transiti= on/ I think this is of interest to people in the Applications area. I suggest = writing up a draft and circulating it for discussion with what you have in = mind. -MSK From stpeter@stpeter.im Thu Apr 5 15:41: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 4F17B21F8726 for ; Thu, 5 Apr 2012 15:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.979 X-Spam-Level: X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCl5bgVAY8h2 for ; Thu, 5 Apr 2012 15:41:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BAB6921F86DE for ; Thu, 5 Apr 2012 15:41:04 -0700 (PDT) Received: from dhcp-64-101-72-239.cisco.com (unknown [64.101.72.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6660D40058; Thu, 5 Apr 2012 16:54:37 -0600 (MDT) Message-ID: <4F7E1F7F.6070100@stpeter.im> Date: Thu, 05 Apr 2012 16:41:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <7c2b29c999e1441890f63fbb91692de0@DF-PIO-15M30.exchange.corp.microsoft.com> <9452079D1A51524AA5749AD23E0039280CC331@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280CC331@exch-mbx901.corp.cloudmark.com> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Looking to begin discussion about email and IPv6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 22:41:05 -0000 On 4/5/12 4:38 PM, Murray S. Kucherawy wrote: >> -----Original Message----- From: apps-discuss-bounces@ietf.org >> [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Terry Zink >> Sent: Thursday, April 05, 2012 3:17 PM To: apps-discuss@ietf.org >> Subject: [apps-discuss] Looking to begin discussion about email and >> IPv6 >> >> [...] I have some ideas on how to address this, at least in the >> short term. I'd also like go gauge interest for discussing this at >> the Vancouver IETF at the end of July. > > Hi Terry, > > This is a frequent topic in industry, especially at the Messaging > Anti-Abuse Working Group (MAAWG, http://www.maawg.org) which is not > part of IETF. You'd probably get a lot of interested people if you > put together a BoF there. You can probably get some people together > at IETF in Vancouver too for a bar BoF. Which reminds me that there's been talk about holding IETF interim meetings for relevant WGs at conferences like MAAWG and RIPE. Our new AppsArea overlords might want to consider something like that at a future MAAWG meeting. :) Peter -- Peter Saint-Andre https://stpeter.im/ From nico@cryptonector.com Thu Apr 5 15:42: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 68F4D21F85DF for ; Thu, 5 Apr 2012 15:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.06 X-Spam-Level: X-Spam-Status: No, score=-1.06 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3RsaCKHgFyg for ; Thu, 5 Apr 2012 15:42:08 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id F120721F85C7 for ; Thu, 5 Apr 2012 15:42:07 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id A8EA426C05B for ; Thu, 5 Apr 2012 15:42:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Aw9YS2FzeOaHlybOHVgll dp5KXVBxwciCsK/sgJYrofiErJOuf0iOzQnj6TqyAe0ds/LxbUjVWFSlOp7FNm+4 GmxMg2aMafuURQNdWThUl0ccHr+gqKkIDXLaCQFS0t5kWXajRekXmLvB9e9A073U hJ8DWx55IeTDSYSVTbjujE= 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=PlVBg0G5tW/CxGnNNJku rFa00+I=; b=XQP+7SQZSsvRO1Mo6OEwTDjnMNz7cpNu52vQLPO64zSsbVgALy0G SxsuKnmkd7fi1vY+gawRwgiuGRmbsyLgUlTyTNt+uAPvRFqoHobdivpaCczhU5Um mISP/xtNeD+rk6ueDiCKMTb7MGBg4WMOStjRHXbegTwjEqQdTcxLREM= Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 8B37D26C058 for ; Thu, 5 Apr 2012 15:42:07 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1187153ghb.31 for ; Thu, 05 Apr 2012 15:42:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.103.226 with SMTP id f62mr4594620yhg.0.1333665727041; Thu, 05 Apr 2012 15:42:07 -0700 (PDT) Received: by 10.220.107.6 with HTTP; Thu, 5 Apr 2012 15:42:06 -0700 (PDT) In-Reply-To: <7c2b29c999e1441890f63fbb91692de0@DF-PIO-15M30.exchange.corp.microsoft.com> References: <7c2b29c999e1441890f63fbb91692de0@DF-PIO-15M30.exchange.corp.microsoft.com> Date: Thu, 5 Apr 2012 17:42:06 -0500 Message-ID: From: Nico Williams To: Terry Zink Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Looking to begin discussion about email and IPv6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 22:42:08 -0000 How does IP6 have any kind of an effect on spam? Just curious, Nico -- From msk@cloudmark.com Thu Apr 5 15:43:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D9421F868C for ; Thu, 5 Apr 2012 15:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJXYcii1SMmR for ; Thu, 5 Apr 2012 15:43:38 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2B23F21F868A for ; Thu, 5 Apr 2012 15:43:38 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Thu, 5 Apr 2012 15:43:37 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Looking to begin discussion about email and IPv6 Thread-Index: Ac0TcNVZC8yfbKKgTYyJdsZe8IIhSAACEtKAAA+33QAADqVUcA== Date: Thu, 5 Apr 2012 22:43:36 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280CC35C@exch-mbx901.corp.cloudmark.com> References: <7c2b29c999e1441890f63fbb91692de0@DF-PIO-15M30.exchange.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Looking to begin discussion about email and IPv6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Apr 2012 22:43:38 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Nico Williams > Sent: Thursday, April 05, 2012 3:42 PM > To: Terry Zink > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Looking to begin discussion about email and I= Pv6 >=20 > How does IP6 have any kind of an effect on spam? Just curious, The portion of an anti-spam framework that evaluates based on client IP add= ress (DNSBLs, for instance) has a far larger problem to deal with in IPv6. -MSK From johnl@iecc.com Thu Apr 5 17:43: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 C45ED21F85E4 for ; Thu, 5 Apr 2012 17:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJOEQPP3FUNH for ; Thu, 5 Apr 2012 17:43:25 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 071B821F85DD for ; Thu, 5 Apr 2012 17:43:24 -0700 (PDT) Received: (qmail 88773 invoked from network); 6 Apr 2012 00:43:23 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Apr 2012 00:43: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=4f7e3c2b.xn--9vv.k1204; i=johnl@user.iecc.com; bh=PtZenc8kfps3Hod8eVOd7GSlJCu1eV8Op6G+gQzZEj4=; b=aZGUSQ7mCkSJehg5CN8z8b3d49AyIVPC+6YoKoB5NtGmSFXYH7d/qn+fk6SynxI4zX4me6ufGjQSWRhtk/zqZaq+HfWiTLSV3asLAjjsBT37STW44CpvvhPPP18HwUpDVrybb1lxetrpikQgk2wt2paNWpl7eowHamdG6Jz1QRA= 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=4f7e3c2b.xn--9vv.k1204; olt=johnl@user.iecc.com; bh=PtZenc8kfps3Hod8eVOd7GSlJCu1eV8Op6G+gQzZEj4=; b=E86cZSBXavbPJFSWYCcCl5oahW/vav+2Pd6of3opjAsTJSZus2AewmTM8L+e486hGXkAaafYdvtcEYwEqzm1k1V0lVWssC3H0r+bHNrlWzeUQn3fL35+w6A7ddwYcZYYKnTvd11aJ+9q2kOGv/0+HdR29zRlil5e5TeeB7e7A+c= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Apr 2012 00:43:01 -0000 Message-ID: <20120406004301.22442.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E0039280CC331@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Looking to begin discussion about email and IPv6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2012 00:43:25 -0000 >Off the top of my head, I can only think of this document (now expired) on the topic: > >https://datatracker.ietf.org/doc/draft-oreirdan-rosenwald-ipv6mail-transition/ There's also my draft of an alternate way to publish DNSBLs as B-trees that can directly express address ranges: http://tools.ietf.org/html/draft-levine-iprangepub-02 Something that would make our lives a lot easier is a way for networks to publish their customer allocation size, be it /64 or whatever. Sure, some naughty networks will like, but the largest ones won't, and when you get spam from a 'bot, it'd be a useful hint to know how large a range the bot has infected. R's, John From msk@cloudmark.com Thu Apr 5 22:51: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 5E4CC21F84F6 for ; Thu, 5 Apr 2012 22:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft97OrzXdUyV for ; Thu, 5 Apr 2012 22:51:25 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7516821F84F5 for ; Thu, 5 Apr 2012 22:51:25 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 5 Apr 2012 22:51:25 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Looking to begin discussion about email and IPv6 Thread-Index: Ac0TcNVZC8yfbKKgTYyJdsZe8IIhSAACEtKAAACBPnAAE2+zgAAD+s1w Date: Fri, 6 Apr 2012 05:51:24 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280CC72A@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280CC331@exch-mbx901.corp.cloudmark.com> <20120406004301.22442.qmail@joyce.lan> In-Reply-To: <20120406004301.22442.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] Looking to begin discussion about email and IPv6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2012 05:51:26 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDA1LCAyMDEyIDU6NDMg UE0NCj4gVG86IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KPiBDYzogTXVycmF5IFMuIEt1Y2hlcmF3 eQ0KPiBTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gTG9va2luZyB0byBiZWdpbiBkaXNjdXNz aW9uIGFib3V0IGVtYWlsIGFuZCBJUHY2DQo+IA0KPiBTb21ldGhpbmcgdGhhdCB3b3VsZCBtYWtl IG91ciBsaXZlcyBhIGxvdCBlYXNpZXIgaXMgYSB3YXkgZm9yIG5ldHdvcmtzDQo+IHRvIHB1Ymxp c2ggdGhlaXIgY3VzdG9tZXIgYWxsb2NhdGlvbiBzaXplLCBiZSBpdCAvNjQgb3Igd2hhdGV2ZXIu DQo+IFN1cmUsIHNvbWUgbmF1Z2h0eSBuZXR3b3JrcyB3aWxsIGxpa2UsIGJ1dCB0aGUgbGFyZ2Vz dCBvbmVzIHdvbid0LCBhbmQNCj4gd2hlbiB5b3UgZ2V0IHNwYW0gZnJvbSBhICdib3QsIGl0J2Qg YmUgYSB1c2VmdWwgaGludCB0byBrbm93IGhvdyBsYXJnZQ0KPiBhIHJhbmdlIHRoZSBib3QgaGFz IGluZmVjdGVkLg0KDQpJJ3ZlIGJlZW4ga2VlcGluZyBhbiBleWUgb24gdmFyaW91cyB3b3JrIGlu IHNpZHIsIGRuc29wLCBhbmQgd2VpcmRzIHRvIHNlZSB3aGVyZSB0aGlzIGNhcGFiaWxpdHkgaXMg bW9yZSBsaWtlbHkgdG8gZW1lcmdlLiAgSXQncyBkZWZpbml0ZWx5IGRlc2lyYWJsZSBzcGVjaWZp Y2FsbHkgZm9yIHRoZSBlbWFpbC1vdmVyLUlQdjYgc3BhY2UsIGJ1dCBwb3NzaWJseSBmb3Igb3Ro ZXIgc2VjdXJpdHktcmVsYXRlZCB0aGluZ3MgYXMgd2VsbC4gIEknbGwgYmUgcHV0dGluZyB3b3Jr IGludG8gaXQgd2hlcmV2ZXIgaXQgYXBwZWFycywgYW5kL29yIHdpbGwgc3VibWl0IGEgZHJhZnQg b2YgbXkgb3duIGlmIEkgY29tZSB1cCB3aXRoIGFuIGlkZWEgdGhhdCBzZWVtcyB3b3JrYWJsZS4g IEkganVzdCBoYXZlbid0IGZvdW5kIHRoYXQgeWV0Lg0KDQotTVNLDQo= From johnl@iecc.com Thu Apr 5 23:20: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 F004211E8093 for ; Thu, 5 Apr 2012 23:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1fL6nd6AveB for ; Thu, 5 Apr 2012 23:20:56 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E9C2F11E8091 for ; Thu, 5 Apr 2012 23:20:55 -0700 (PDT) Received: (qmail 74107 invoked from network); 6 Apr 2012 06:20:54 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Apr 2012 06:20:54 -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=4f7e8b46.xn--9vv.k1204; i=johnl@user.iecc.com; bh=kmssC19E011wHjtQ22cyrgj5wlm7CVzTXPbHiqHRzuE=; b=mm+ZOwgZTZWi/jKLcsUPfXFej7GAs7e1MALAPnedkazlt6kTu+N8DUVQSCGObthuIeNXciaU9szQWR4Ogi0oZfyYwdXnTuQbge3C0wP+DclonabtqCdQ/yQxL9LHm+CrWKoGd4Sa/e5Mkl/gYX7Hc5SRzOh/Arsvjz6P6R0XOrQ= 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=4f7e8b46.xn--9vv.k1204; olt=johnl@user.iecc.com; bh=kmssC19E011wHjtQ22cyrgj5wlm7CVzTXPbHiqHRzuE=; b=DzdC3soMVUpZcz/qWL1zafBUn1HJUhY1Vk9GcTgL+YEFQa6ViCDE2SbHZv5A66tWOrAuHrZTfoNNX4wM8zriO2de6DKP7IVw+wwj7RIuhjBwPtGpvUa9HiT40rVUCfpswI7O55keUIoXqDcz7NZ0PGPzVsFSDGivT3DixfBjYKA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Apr 2012 06:20:32 -0000 Message-ID: <20120406062032.33810.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E0039280CC72A@exch-mbx901.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Looking to begin discussion about email and IPv6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2012 06:20:57 -0000 >I've been keeping an eye on various work in sidr, dnsop, and weirds to see where this capability >is more likely to emerge. It's definitely desirable specifically for the email-over-IPv6 space, >but possibly for other security-related things as well. I'll be putting work into it wherever >it appears, and/or will submit a draft of my own if I come up with an idea that seems workable. >I just haven't found that yet. In Paris I had dinner with the guys who were running the conference network, and explained to them why we wanted the allocation size. They had a bunch of plausible ideas, none of which I remember in detail (darn that cheap but tasty wine from southern France) other than that if WEIRDS succeeds, it could either be a field in the response for the allocation, or they could SWIP all of the suballocations. I suggested that for both scale and privacy reasons ARIN would probably not welcome 50,000,000 SWIPs from Comcast, but they noted that large networks can run their own subservers, and it's quite possible to have entries for individuals that don't include the PII. R's, John From stephen.farrell@cs.tcd.ie Fri Apr 6 03:21:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DCA21F849C for ; Fri, 6 Apr 2012 03:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahp275vP6zr0 for ; Fri, 6 Apr 2012 03:21:21 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B29F21F844F for ; Fri, 6 Apr 2012 03:21:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A93C3171472; Fri, 6 Apr 2012 11:21:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1333707678; bh=/OM7NBqrceMTEF vgaZXFMXrdlwZhhwiwwO1yur4w1z4=; b=e3AFL8ejmVxAdUVW8sFWomxLqEYIwb a8Fp9bqcV7QvIR1yDjVN5md4KTISjdIO+qKjf0XN+Wb4RrXCrYdW/NYw8iFifV/C 04567xrPYdK7S9+2rwotWCaCYE07wXODBeSyY/2x2QKIHK4u/nlu5SvVwynqoAlV SqlsIlLAkLBNwTQ517zOIc3jst+j5fanZrE+sEouH4WoDZOuAS2/TyGGjzs1Sehv mwgpR2NMJi+uLWbO+w0x6BmQM/zcWsZxNPz50usoiACSeJ2brQtTN4dO9r/PqPRF dPH3VFqCxFabRYbOrUyJfJd0BIW/vuooYWYxWIaiue4wu3Ss/HcYNBMA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id CXVi8lg9xc4m; Fri, 6 Apr 2012 11:21:18 +0100 (IST) Received: from [10.87.48.4] (unknown [86.46.29.158]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id BB071171471; Fri, 6 Apr 2012 11:21:17 +0100 (IST) Message-ID: <4F7EC39D.1090209@cs.tcd.ie> Date: Fri, 06 Apr 2012 11:21:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Martin Thomson References: <4F7DFC47.2020604@cs.tcd.ie> <4F7E0DC8.8030707@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-farrell-decade-ni-02 - we think this is done... X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2012 10:21:22 -0000 On 04/05/2012 10:30 PM, Martin Thomson wrote: > On 5 April 2012 14:25, Stephen Farrell wrote: >>> I might want to identify a resource outside of /.well-known/. I might >>> also want to identify a resource that is served elsewhere. I can't do >>> either with this scheme. >> >> Sure. We added that though in section 5. (For URLs anyway.) >> Be glad to add more text that makes that clear, and happy >> to say its usable with other schemes if you can offer good >> words for that. > > That doesn't quite do it. If I understand correctly, you want someone > to look at a URI and "know" that this particular path component is > actually a hash. > > What I want to do is provide an ni: URI that wraps: > > http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.18/jquery-ui.min.js > > And have clients (say my browser) load that URI and be able to check > that the content is the right content. Without knowledge of URI > components that should be opaque. That is, I want a mechanism for > dealing with mixed content (see plenary) that doesn't require TLS. > > This might be done by something like: > > ni:sha256:blah:http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.18/jquery-ui.min.jse > > Though that completely ruins your nice URI form. Well, it is less nice but following draft-hallambaker-decade-ni-params we could add support for: ni:///sha256;abc...?url=http://ajax... I've probably got the encoding there wrong but would that meet the need if properly done? S. From stephen.farrell@cs.tcd.ie Fri Apr 6 03:28: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 D898921F85E7 for ; Fri, 6 Apr 2012 03:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUfX9a0eg1hu for ; Fri, 6 Apr 2012 03:28:23 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id BD66C21F8587 for ; Fri, 6 Apr 2012 03:28:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 353E6171472; Fri, 6 Apr 2012 11:28:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1333708101; bh=3JwX+0XLRxYSj9 GyuUa/ofuNxwk7GAdPx3BjCnCMX7E=; b=i0ReLVviSwMaWNLacWYLDIsO3i9sEd maKRofYNkcnLXm+CgTv6ONLLK6jTTwkNgYMyr/5L/a+ebm2jnObARHldNABEPeuY 7/2Ms/fILvquZo3+vy+oWD93u1XQd8u76CycImfPSPichdOV4wrUz6IK8y+4aZ90 Pu+AsIGAg9MJmKBO1x996WDfClrZQKSxU/1XgoMCgG0qDv1TRYVXDgJw0EaPWAoV /QqDLTktY0GP6v5BsKetBHeD8k9YKFl3dQ96flJKKSfrylFFJEAoZBtc8/XitnBL LcNKdBhP6L4krO1mWzZupn6R1301CvrEOAb/IW9ogYweLBzL4HB4qz6Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 5v-dhGxosCJi; Fri, 6 Apr 2012 11:28:21 +0100 (IST) Received: from [10.87.48.4] (unknown [86.46.29.158]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A8A85171471; Fri, 6 Apr 2012 11:28:21 +0100 (IST) Message-ID: <4F7EC545.7090702@cs.tcd.ie> Date: Fri, 06 Apr 2012 11:28:21 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Carsten Bormann References: <4F7DFC47.2020604@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Apps Discuss Subject: Re: [apps-discuss] draft-farrell-decade-ni-02 - we think this is done... X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2012 10:28:24 -0000 Hi Carsten, On 04/05/2012 10:56 PM, Carsten Bormann wrote: > ** Summary: > > This may seem nearly trivial, but upon looking closer really is awesome work, something truly only the IETF could create. Thanks that's nice to hear. > ** Nits: > > What is a "thing"? (abstract) :-) I like it saying "thing" > > The reference from section 3 to section 9.1 appears wrong -- I don't think 9.1 actually defines the registry required here. > If this is referencing 9.3, please make sure there that the "ID" column is left empty (and thus no number consumed) if a number for the binary encoding is not needed. Yep, should be 9.3 and I'll add something making the ID colum optional. > I don't like the sentence > Since application > code often attempts to enforce such encoding, decoders MUST recognize > the use of URI escape encoding. > and the following sentences too much -- yes, you MUST implement URI syntax, but not just for this reason. > Add examples of percent-decoding (implementers implement from examples!). Would gratefully accept such. > > How useful is: > If an application is presented with a HTTP(S) URL with "/.well- > known/ni/" as the start of its pathname component, then the reverse > mapping to an ni URI either including or excluding the authority > might produce an ni URI that is meaningful, but there is no guarantee > that this will be the case. > Wouldn't it be more appropriate to mandate that /.well-known/ni *MUST* only be used in a way that makes this reverse mapping useful? Not sure to be honest. > s/URL Fragment/URL Segment/ (Fragment is confusing, as it means something specific in URIs.) Sure. > > Maybe the human-readable form should be prefixed by "ni;" so it is easily recognizable. Sure. Might have to re-do the ABNF to allow for that but do-able. > > http://www.tcd.ie/.well-known/ni/sha256/UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q does not resolve (maybe you meant example.com?). Ack. > I believe for this to be the replacement of "unsecure links out of HTTPS", the secure media type issue must be solved in the base spec. > (Oh, and is there ever a need to discuss content-coding in this context???) Not sure what you mean by "solved" can you elaborate? > Please re-spin http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-00 and make sure that Martin's concern is addressed... Will do. Probably over the weekend. Cheers, S. > ** PS > > Again, I'm still in awe that a 10-page specification can solve so many problems in one fell swoop. > > Grüße, Carsten > > From cabo@tzi.org Fri Apr 6 05: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 ECB6421F85E3 for ; Fri, 6 Apr 2012 05:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.716 X-Spam-Level: X-Spam-Status: No, score=-106.716 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9O5jr1uPStE for ; Fri, 6 Apr 2012 05:08:48 -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 5D26E21F85D3 for ; Fri, 6 Apr 2012 05:08:46 -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 q36C8Ztc004495; Fri, 6 Apr 2012 14:08:36 +0200 (CEST) Received: from [192.168.217.105] (p54899D39.dip.t-dialin.net [84.137.157.57]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F0C4182C; Fri, 6 Apr 2012 14:08:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F7EC545.7090702@cs.tcd.ie> Date: Fri, 6 Apr 2012 14:08:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <93FE0923-1A47-4E97-94E9-559B3E217F01@tzi.org> References: <4F7DFC47.2020604@cs.tcd.ie> <4F7EC545.7090702@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1257) Cc: Apps Discuss Subject: Re: [apps-discuss] draft-farrell-decade-ni-02 - we think this is done... X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2012 12:08:50 -0000 On Apr 6, 2012, at 12:28, Stephen Farrell wrote: >> I believe for this to be the replacement of "unsecure links out of = HTTPS", the secure media type issue must be solved in the base spec. >> (Oh, and is there ever a need to discuss content-coding in this = context???) >=20 > Not sure what you mean by "solved" can you elaborate? The problem is that the ni: hash only secures the bytes of the payload. (At least that's my assumption -- it might be worth saying explicitly = what is hashed here, BTW.) The entity I would have been retrieving over a secure HTTPS channel also = has metadata. Many of these are not critical, as they only pertain to the retrieval = process (say, the Etag). However, the media type is critical for correctly interpreting the = returned result. While I'm not aware of the proverbial contract text that means something = different when interpreted as SJIS instead of UTF-8, attacks on the = basis of swapping the media type are conceivable. (Also, there is lots = of potential for misconfiguration, damaging the reliability.) I'm naming content-coding as another example that it is not quite clear = what is the input to the hash function. So maybe it is worth having another (normative) document that spells out = how exactly ni:// is used in the Browser Web (among others, to solve the = "unsecure links" problem)? Gr=FC=DFe, Carsten From stephen.farrell@cs.tcd.ie Fri Apr 6 08:45: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 22A3C21F8569 for ; Fri, 6 Apr 2012 08:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QJOiKGbs2Z7 for ; Fri, 6 Apr 2012 08:45:46 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 54CD221F8555 for ; Fri, 6 Apr 2012 08:45:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EC4E8171478; Fri, 6 Apr 2012 16:45:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1333727144; bh=BPgRuF1oApRRpm 2mcvEIn+j36gqIsW9oT52dd1SF158=; b=UOL1/C/y4QNdqNpLJap0mWCL++BrEw ypZVrAUdRUVVOOM81hS+EX4mOIaSRyS890tjLrn1WkzH4L1iCdQk7HzjIzjMLzfd /vJmL72G2MfVvczxi/uDmj5dRggMRBrVJ7dR2mLms0rEgMFDjR/foEq5YoJGIrZT 8mRQdbp8fBuWbgc295CZUuzZHmguEUuqEk/gvC/oztbYGjap4W7qlRTKusWedYbm IFbc9ovjdGdggbevVFR1EwQ/2G8fEJvW+odljRimMVciSOrrXgQ2UqqBDBryyhWP UIUqYhjSOTCzFsPvuvkaGs3SyYVzDAI8C0sGWTLGQQ0iFyn/egkyLc2A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id X7og1JTCjb2s; Fri, 6 Apr 2012 16:45:44 +0100 (IST) Received: from [10.87.48.4] (unknown [86.46.29.158]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 718A7171477; Fri, 6 Apr 2012 16:45:44 +0100 (IST) Message-ID: <4F7F0FA8.4030704@cs.tcd.ie> Date: Fri, 06 Apr 2012 16:45:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Carsten Bormann References: <4F7DFC47.2020604@cs.tcd.ie> <4F7EC545.7090702@cs.tcd.ie> <93FE0923-1A47-4E97-94E9-559B3E217F01@tzi.org> In-Reply-To: <93FE0923-1A47-4E97-94E9-559B3E217F01@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Apps Discuss Subject: Re: [apps-discuss] draft-farrell-decade-ni-02 - we think this is done... X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2012 15:45:47 -0000 Hiya, On 04/06/2012 01:08 PM, Carsten Bormann wrote: > On Apr 6, 2012, at 12:28, Stephen Farrell wrote: > >>> I believe for this to be the replacement of "unsecure links out of HTTPS", the secure media type issue must be solved in the base spec. >>> (Oh, and is there ever a need to discuss content-coding in this context???) >> >> Not sure what you mean by "solved" can you elaborate? > > The problem is that the ni: hash only secures the bytes of the payload. > (At least that's my assumption -- it might be worth saying explicitly what is hashed here, BTW.) > > The entity I would have been retrieving over a secure HTTPS channel also has metadata. > Many of these are not critical, as they only pertain to the retrieval process (say, the Etag). > However, the media type is critical for correctly interpreting the returned result. > While I'm not aware of the proverbial contract text that means something different when interpreted as SJIS instead of UTF-8, attacks on the basis of swapping the media type are conceivable. (Also, there is lots of potential for misconfiguration, damaging the reliability.) > > I'm naming content-coding as another example that it is not quite clear what is the input to the hash function. > So maybe it is worth having another (normative) document that spells out how exactly ni:// is used in the Browser Web (among others, to solve the "unsecure links" problem)? Ah now I see. Yes, I think other documents should define the hash input bytes, each in their own contexts. I'd be happy to help out with making a start on the web/ajax thing, but would need help from someone who knows more about the input bytes. Cheers, S. > Grüße, Carsten > > From ted.ietf@gmail.com Fri Apr 6 11:59: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 A777C21F84A5; Fri, 6 Apr 2012 11:59:54 -0700 (PDT) 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_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXX2VuUCkHp9; Fri, 6 Apr 2012 11:59:53 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A4EBB21F84BD; Fri, 6 Apr 2012 11:59:53 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1584865vbb.31 for ; Fri, 06 Apr 2012 11:59:53 -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=ZYFTGUaDocOFSkOMTywvCWzl0FJKSSGnMR5PPLMNF6U=; b=EBNTTMQwkCaoac8S+biDYmKqPoRH8rgKR7VBxW3yl/U1UctXUz4KLSaFfTDTXUr838 Y5+QyE5N94WXr/Cei0H17Rx4L1m6nwPEJf45b1TlbeFuIZ+qaWFClUT3raDlDx8aldCt 7K4NkOe7RrEmgSSjwEuopKxllty21eoEmOPQNJbe2ZVr6bxk+xA+/wQepvJsHm8xc3iv 2bDjgyQ+NeXL8wifcX9EcUcchkZbAQyAx9iBtaWjXjcQ92W3PnfxwxfDaBqeu6U3QgCP 3gG1tSRYEaaz+nrCAxc2LBiIlzufW+5GTMxnGUvggoaEUXGXDrIZDluTYZBlp34bR0wU uBkQ== MIME-Version: 1.0 Received: by 10.52.88.2 with SMTP id bc2mr2515248vdb.82.1333738793149; Fri, 06 Apr 2012 11:59:53 -0700 (PDT) Received: by 10.52.162.99 with HTTP; Fri, 6 Apr 2012 11:59:53 -0700 (PDT) Date: Fri, 6 Apr 2012 11:59:53 -0700 Message-ID: From: Ted Hardie To: apps-discuss@ietf.org, draft-johansson-loa-registry.all@tools.ietf.org, IESG Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Reivew of draft-johansson-loa-registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2012 18:59:54 -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-johansson-loa-registry Reviewer:Ted Hardie Review Date: April 6, 2012 Summary: There are some clarifications needed to ensure that the resulting registry is as useful as possible. Major Issues: The document currently describes a registry primarily focused on SAML Authentication Context Profiles, but with the understanding that other protocols may re-use the registry contents in their own contexts: Although the registry will contain URIs that reference SAML Authentication Context Profiles other protocols MAY use such URIs to represent levels of assurance definitions without relying on their SAML XML definitions. Use of the registry by protocols other than SAML or OpenID Connect is encouraged. Each registration contains a URI, a schema definition, a short name, and an informational URL. It is not clear, however, whether these URIs must be unique across registrations. Would it be possible, for example, to have a non-SAML usage documented in this registry by having it re-register with an existing URI, but a different informational URL? I believe this point should be made explicit as guidance to the expert reviewers. The document uses ABNF to describe the required format of the short name, but there is no reference for ABNF given; presumably RFC5234 should be included as a reference. The ABNF in the document excludes specific prefixes (LOA, AL) in order to avoid non-descriptive short names, but it is not clear why it also excludes all-digit references. In general, the use of the ABNF for this seems fairly clumsy, and I would suggest that the document shift this from ABNF determinism to advice (to both registrants and expert reviewers), to help ensure that the resulting names are useful. There are a host of equally problematic possibilities (saml-loa-10, for example) that good guidance would better avoid than ABNF rules. For the "informational URL" definition, a list of permitted URI schemes might be useful, as it is not clear whether a contact-only URI would be acceptable. The document says: Informational URL: A URL containing auxilliary information. This URL MUST minimally reference contact information for the administrative authority of the level of assurance definition. Would an informational URL of mailto:loa-registrant@example.org be acceptable? Minor Issues: The example given in 3.1 does not give an information URL, but the registration template implies that this field is mandatory. In 4.1, the document twice uses the term "bona fide" to describe entries: The expectation of the IANA LoA Registry is that it contain bona fide Level of Assurance Profiles while not presenting a very high bar for entry. Expert reviewers SHOULD NOT place undue value in any percieved or actual quality of the associated trust framework or federation and SHOULD only exclude such registrations that in the view of the experts do not represent bona fide attempts at defining an LoA. I suggest that "good faith" be used to replace at least one of these, to clarify the meaning. Nits: [list editorial issues such as typographical errors, preferably by section number] I personally found the Introduction somewhat hard to parse, and I believe it would be improved by bringing paragraphs two and three forward, then following them with the gist of paragraphs one and four. In the Acknowledgements Section: The various versions of the draft was socialized should be "were socialized". From dret@berkeley.edu Fri Apr 6 13: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 D7DA111E8099 for ; Fri, 6 Apr 2012 13:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w52EDUk8PSsX for ; Fri, 6 Apr 2012 13:06:15 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id C66BA11E8098 for ; Fri, 6 Apr 2012 13:06:15 -0700 (PDT) Received: from 65-122-15-169.dia.static.qwest.net ([65.122.15.169] helo=dretair.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1SGFQD-0003fs-Di; Fri, 06 Apr 2012 13:06:15 -0700 Message-ID: <4F7F416C.3050400@berkeley.edu> Date: Fri, 06 Apr 2012 12:18:04 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: REST Discuss , "apps-discuss@ietf.org application-layer protocols" References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> In-Reply-To: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham Subject: Re: [apps-discuss] Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2012 20:06:17 -0000 hello mark. thanks a lot for the feedback! i am cross-posting this response to rest-discuss@yahoogroups.com, because it may be interesting for that community as well. too bad that the IETF drafts don't have commenting support on the IETF page itself, that would be really useful! On 2012-04-05 09:25 , Mark Nottingham wrote: > Overall, I'm really happy to see this draft; have been considering doing something along these lines too. > *** Major issues > * "Resource Profiles" - this spec defines the profile is being about the *resource* of its context. This is too loose; in HTML and other uses I've seen, profiles are about the *representation* they occur within. actually, most of the abstract talks about the profile qualifying a representation, but you're correct that this should be made very clear, and that it should be about the specific representation containing the profile link. i'll rewrite all the places where the text says that profiles are about resources. > In other words, the common idea of a profile, IME, is that it describes the conventions, extensions, etc. that are used in a particular document, but it doesn't say anything about the resource that the document was retrieved from. yes, that is how it should be. only that i really would not want to say "describes" here, to clearly avoid the expectation that a 'profile' link MUST resolve to some sort of description. i'd say it "identifies" conventions, extensions, etc., and the only dependable operation on a 'profile' link is to compare the URI to known profile URIs. > That's a good design, because link relations are already a defined mechanism to talk about resource behaviours; having two such mechanisms isn't a good idea (at least without some discussion). > E.g., when I interact with a resource, I know it supports particular behaviours, because it's been linked to with relation "Foo." When I get a representation from the "Foo" resource, it will have a media type that describes the format, and also a profile ("Bar") that describes additional features / conventions of that document (such as a particular use of JSON or XML), but that profile won't -- and shouldn't! -- be an additional way of describing the behaviours of the "Foo" resource. now i am little bit confused. taking your example, i am not concerned with the link relation that was used to discover 'foo' at all. all i am concerned with is that if i am retrieving 'foo' and i find a 'bar' profile identifier in the representation, i know that it follows constraints and conventions beyond the 'foo' media type. one example i am currently considering adding is atompub. currently, when you retrieve a feed, there's no way to tell it's atompub-capable just by looking at it. that could be easily remedied by adding a 'profile' link identifying the support of atompub. that's the kind of scenario i have in mind, but it sounds to me you're thinking about something else, or am i just misunderstanding you? > *** Nits / minor feedback: > * """This link relation type is independent of the resource representation it is used in (but the representation must support types links for this mechanism to work)""" > I'd state this in terms of "context", as per the link RFC. "This link relation type is independent of the context in which it is used (however, the representation must support typed links for this mechanism to work)" > * s/must support types links/must support typed links/ done. > * """ > In fact, for the purpose of this > specification, the URI does not necessarily have to link to a > dereferencable resource, and clients can treat the occurrence of a > specific URI in the same sense as a namespace URI and invoke specific > behavior based on the assumption that a specific profile URI signals > that a resource follows a specific profile. > """ > Here, I'd state this in terms of "target URIs", as does the link RFC. "In fact, for the purpose of this specification, the target URI does not necessarily have to identify a dereferencable resource (or even use a dereferencable URI scheme), and clients can treat the occurrence of a specific URI in the same way as an XML namespace URI and invoke specific behavior based on the assumption that a specific profile target URI signals that a resource representation follows a specific profile." > * Your Security Considerations section isn't going to pass muster; if it were me, I'd talk about how software shouldn't make security-sensitive assumptions based upon profiles. any specific suggestions on how to phrase that? ;-) > *""" > As one example, consider the case of podcasts, a specific kind of > feed using additional fields for media-related metadata. Using a > 'profile' link, it would be possible for a client to understand that > a specific feed is supposed to be a podcast feed, and that it may > contain entries using podcast-specific fields. This may allow a > client to behave differently when handling such a feed (such as > rendering a UI), even when the current set of entries in the feed may > not contain any podcast entries. > """ > This is an interesting use case. My use cases for "profile" tend to be things like "links that this document contain follow *this* convention". More examples would be good. to me, it's both about those links and about conventions followed in the document itself. i am currently planning to include three examples in the next version of the draft: - HCard - Dublin Core - AtomPub particularly this last one might be what you're looking for, right? if you have any suggestions what to add to this list, please let me know. thanks a lot for the feedback! i'll continue working on the examples, and as soon as these are finished, i am planning to publish -01 and see whether the additional examples make it easier to understand what this draft is trying to accomplish, and there might be more feedback. cheers and happy easter everybody, 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 stephen.farrell@cs.tcd.ie Fri Apr 6 15:03: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 E248521F8507 for ; Fri, 6 Apr 2012 15:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2jljhQNvMES for ; Fri, 6 Apr 2012 15:03:38 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB4D21F8504 for ; Fri, 6 Apr 2012 15:03:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E5772171479; Fri, 6 Apr 2012 23:03:36 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1333749816; bh=bmyQmfXli/wTh9 MaMkUhuIIlQ/5W6kl4sler9fh1HIc=; b=6OxCCHTcukAfHfgFYtEuWE3ZgY0iZR b/PsowbWjg/mcoyVVyu/+KDtzoW69Wn/TqzKSFNCrbCdNCVB4t+3Fc9XpMx0/JJb wieZtY7vlulCIJV+Pa9LQ+USnuNK1QhpjybUAmXz0DxwD7MxI3T9BflXc5veJoIC VgObV1TxZQQB5+cTu8cpu0UScltHco4ukVPwKUtMqgwFJc5MjQwFmXY2WCaFaSOh 8oouV4vKzVylmy6t48HrqQuGG+NN2i/kH204Z5CHXlA7PvhCkiIDvXbnS04OPQ+G 7jHTCsMnybn5dDs8ESyNJNEsGPYsTumaKkmdKEEcYBzA+5JI2cUe++ZA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 0JSdhryHX6S4; Fri, 6 Apr 2012 23:03:36 +0100 (IST) Received: from [10.87.48.4] (unknown [86.42.31.105]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 48F8F171478; Fri, 6 Apr 2012 23:03:36 +0100 (IST) Message-ID: <4F7F6837.8030900@cs.tcd.ie> Date: Fri, 06 Apr 2012 23:03:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Carsten Bormann , Martin Thomson References: <4F7DFC47.2020604@cs.tcd.ie> <4F7EC545.7090702@cs.tcd.ie> <93FE0923-1A47-4E97-94E9-559B3E217F01@tzi.org> <4F7F0FA8.4030704@cs.tcd.ie> In-Reply-To: <4F7F0FA8.4030704@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Apps Discuss Subject: Re: [apps-discuss] draft-farrell-decade-ni-02 - we think this is done... X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Apr 2012 22:03:39 -0000 So I took a stab at addressing Carsten's and Martin's good comments. Bit more to do but the significant changes so far are: - added a "url=" query string parameter to draft-hallambaker-decade-ni-params for Martin's use-case - added an "nih" scheme to draft-farrell-decade-ni for the "human" scheme (nice acronym:-); that seems better than using the "ni" scheme with two different but sorta similar encodings (base32 and base64Url) Previews at [1,2] (but might change when co-authors get a chance to think about those changes). More comments welcome, TIA, S. [1] http://down.dsg.cs.tcd.ie/misc/draft-farrell-decade-ni.txt [2] http://down.dsg.cs.tcd.ie/misc/draft-hallambaker-decade-ni-params.txt On 04/06/2012 04:45 PM, Stephen Farrell wrote: > > Hiya, > > On 04/06/2012 01:08 PM, Carsten Bormann wrote: >> On Apr 6, 2012, at 12:28, Stephen Farrell wrote: >> >>>> I believe for this to be the replacement of "unsecure links out of >>>> HTTPS", the secure media type issue must be solved in the base spec. >>>> (Oh, and is there ever a need to discuss content-coding in this >>>> context???) >>> >>> Not sure what you mean by "solved" can you elaborate? >> >> The problem is that the ni: hash only secures the bytes of the payload. >> (At least that's my assumption -- it might be worth saying explicitly >> what is hashed here, BTW.) >> >> The entity I would have been retrieving over a secure HTTPS channel >> also has metadata. >> Many of these are not critical, as they only pertain to the retrieval >> process (say, the Etag). >> However, the media type is critical for correctly interpreting the >> returned result. >> While I'm not aware of the proverbial contract text that means >> something different when interpreted as SJIS instead of UTF-8, attacks >> on the basis of swapping the media type are conceivable. (Also, there >> is lots of potential for misconfiguration, damaging the reliability.) >> >> I'm naming content-coding as another example that it is not quite >> clear what is the input to the hash function. >> So maybe it is worth having another (normative) document that spells >> out how exactly ni:// is used in the Browser Web (among others, to >> solve the "unsecure links" problem)? > > Ah now I see. Yes, I think other documents should define the > hash input bytes, each in their own contexts. > > I'd be happy to help out with making a start on the web/ajax > thing, but would need help from someone who knows more about > the input bytes. > > Cheers, > S. > >> Grüße, Carsten >> >> > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From leifj@sunet.se Sun Apr 8 05:21:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3CF21F84D6; Sun, 8 Apr 2012 05:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE3pxiMaRAiY; Sun, 8 Apr 2012 05:21:53 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 4C18321F84BD; Sun, 8 Apr 2012 05:21:53 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q38CLi2f007054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Apr 2012 14:21:48 +0200 (CEST) Message-ID: <4F8182D7.1030106@sunet.se> Date: Sun, 08 Apr 2012 14:21:43 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-johansson-loa-registry.all@tools.ietf.org, IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Reivew of draft-johansson-loa-registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Apr 2012 12:21:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/06/2012 08:59 PM, Ted Hardie 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. Excellent review Ted, thank you very much! > > Document: draft-johansson-loa-registry Reviewer:Ted Hardie Review > Date: April 6, 2012 > > Summary: > > There are some clarifications needed to ensure that the resulting > registry is as useful as possible. > > Major Issues: > > The document currently describes a registry primarily focused on > SAML Authentication Context Profiles, but with the understanding > that other protocols may re-use the registry contents in their own > contexts: > > Although the registry will contain URIs that reference SAML > Authentication Context Profiles other protocols MAY use such URIs > to represent levels of assurance definitions without relying on > their SAML XML definitions. Use of the registry by protocols other > than SAML or OpenID Connect is encouraged. > > Each registration contains a URI, a schema definition, a short > name, and an informational URL. It is not clear, however, whether > these URIs must be unique across registrations. Would it be > possible, for example, to have a non-SAML usage documented in this > registry by having it re-register with an existing URI, but a > different informational URL? I believe this point should be made > explicit as guidance to the expert reviewers. No that would not be consistent with the intent of the registry. Did you suggest that such a practice would be useful? > > The document uses ABNF to describe the required format of the short > name, but there is no reference for ABNF given; presumably RFC5234 > should be included as a reference. The ABNF in the document > excludes specific prefixes (LOA, AL) in order to avoid > non-descriptive short names, but it is not clear why it also > excludes all-digit references. In general, the use of the ABNF for > this seems fairly clumsy, and I would suggest that the document > shift this from ABNF determinism to advice (to both registrants > and expert reviewers), to help ensure that the resulting names are > useful. There are a host of equally problematic possibilities > (saml-loa-10, for example) that good guidance would better avoid > than ABNF rules. > I see your point. However I believe there is value in having very clear guidance which the ABNF does give... Perhaps if I include text in the reviewers guide along the lines of "The reviewers should exclude registrations where the short name does not unambiguously identify the LoA definition or where the short name is a simple variation on one of the reserved (cf above) LoA names." > For the "informational URL" definition, a list of permitted URI > schemes might be useful, as it is not clear whether a contact-only > URI would be acceptable. The document says: > > Informational URL: A URL containing auxilliary information. This > URL MUST minimally reference contact information for the > administrative authority of the level of assurance definition. > > Would an informational URL of mailto:loa-registrant@example.org be > acceptable? > Ah yes. Good catch! > > Minor Issues: > > The example given in 3.1 does not give an information URL, but the > registration template implies that this field is mandatory. > Good catch. Quite embarrassing :-) > In 4.1, the document twice uses the term "bona fide" to describe > entries: > > The expectation of the IANA LoA Registry is that it contain bona > fide Level of Assurance Profiles while not presenting a very high > bar for entry. Expert reviewers SHOULD NOT place undue value in > any percieved or actual quality of the associated trust framework > or federation and SHOULD only exclude such registrations that in > the view of the experts do not represent bona fide attempts at > defining an LoA. > > I suggest that "good faith" be used to replace at least one of > these, to clarify the meaning. > I like it. > > > > Nits: [list editorial issues such as typographical errors, > preferably by section number] > > I personally found the Introduction somewhat hard to parse, and I > believe it would be improved by bringing paragraphs two and three > forward, then following them with the gist of paragraphs one and > four. > > > In the Acknowledgements Section: > > The various versions of the draft was socialized > > should be "were socialized". Yep Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+BgtEACgkQ8Jx8FtbMZnfR4ACbBK2JHXFpM9nEehqAp6IinGW9 2HwAn3qHKIXXpVHEHEEJ7+6qpmIZTc+a =mHA3 -----END PGP SIGNATURE----- From barryleiba.mailing.lists@gmail.com Sun Apr 8 12:00: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 9CA1F21F854D for ; Sun, 8 Apr 2012 12:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.398 X-Spam-Level: X-Spam-Status: No, score=-101.398 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WERVI9QggiGo for ; Sun, 8 Apr 2012 12:00:33 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7147A21F860F for ; Sun, 8 Apr 2012 12:00:31 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1840473ghb.31 for ; Sun, 08 Apr 2012 12:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ztINZJ+Ux0NTMYz5P2jG9REee4T2wl0Y5ePinS2c75c=; b=VZ1rfiOmugn47YrjWf2qHg8Udrtb5CUAcBytgHsM6unx9UXR8ytiQ+zv8Wy68k02jg pFWP6Fq/XLkrTe4GxoOIKzNmdgDZTn3WCm6kxaAfRHh7K1IJPrliZI4DmewA93D55jFK jxaP3GgaGtykwieu9sEFpx+Q+RejkXGwpdz2Z4zBhCn2UQzN2ja06gaslKLePNu+LBBx XZNF8flP1ODBVNnsurWsuMEuEYLqqKbmPJe2bqwnQ1PZuwt1Vj4zi6emLNq59eEfWuSG keDmD0ExUdwf92Z553HVWCZ8qQ+DrxvGVJTPrXsVLBeIhvCK8U00xQtXoYfm/u/zIs53 Pe7w== MIME-Version: 1.0 Received: by 10.236.79.40 with SMTP id h28mr3977032yhe.50.1333911631076; Sun, 08 Apr 2012 12:00:31 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.230.1 with HTTP; Sun, 8 Apr 2012 12:00:30 -0700 (PDT) In-Reply-To: References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> Date: Sun, 8 Apr 2012 15:00:30 -0400 X-Google-Sender-Auth: ws3Gvem-Mroj6LyzyN8a9lOkNs8 Message-ID: From: Barry Leiba To: Walter Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Apr 2012 19:00:33 -0000 > Is there any news from Area Managers regarding the status of the > creation of the proposed list as previously advised? The purpose of non-working-group email lists on the IETF servers is to provide a place for discussion of things related to IETF work -- an offshoot of existing work, perhaps, a proposal for new work that needs some fleshing out, or maybe a discussion of issues that we think will lead to new work some time later. The ADs are not convinced that the work proposed here is best done in the IETF, nor that it's likely to develop into something that kicks off new IETF work later. That view seems backed by most comments by others in the discussion of the proposal on the apps-discuss list. Walter has also said that there are a good number of participants ready to work on financial protocols here, if only we would create a list for it, but has shown no evidence of it, and all requests from the ADs for such evidence -- in the form of actual posts from people expressing interest in working on this here -- have been responded to by statements, both on and off the list, that we can't reasonably expect people to post here first, but that once we have a proper mailing list, they'll show up and work. Despite that, the ADs have been inclined to create a list and see what happens. But discussion at the Paris meeting continued the skepticism from the community that such a list will do anything useful for IETF work. In addition, there were several outright objections to creating the list. Apart from concern about the resources spent in the management of it, applications-area participants point out that there are many places outside the IETF to get free mailing lists for discussion... and there's a worry that an IETF list may simply be used to claim that the IETF backs this work (which it doesn't, at least not yet), and perhaps, worse, that it backs it in preference to other related proposals. Given the clear consensus in the Applications Area, the Applications ADs have decided NOT to create the proposed mailing list. We suggest that the proponents use Google, Yahoo!, or some other free service to discuss their proposals with their many interested collaborators, and consider coming to the IETF with a BoF proposal or working group proposal when things are more solidly defined and ready to start real protocol work. Walter: We understand that you will not be happy with this response, but this is clearly the consensus of the Applications Area participants and we tend to agree with them. That said, we do want to add that many of your messages, particularly the private ones to us, can best be described as impatient and at worst, mean spirited, implying that any refusal to create this mailing list only proves that the IETF is a useless organization and that you'd simply "take your ball and go home." That's probably not the best way to gain the cooperation of the community. We did set that aside (indeed, asking the rest of the community, which was unaware of the content of our off-list messages) and decided based on the potential benefits to the Internet and the IETF, and the consensus of community. Barry and Pete, Applications Area Directors From ned.freed@mrochek.com Sun Apr 8 14:16: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 4A33E21F848B for ; Sun, 8 Apr 2012 14:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+NQ8fJwr6If for ; Sun, 8 Apr 2012 14:16:40 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CE23B21F848A for ; Sun, 8 Apr 2012 14:16:39 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE2UNOL34G008SYV@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 8 Apr 2012 14:16:35 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Sun, 8 Apr 2012 14:16:32 -0700 (PDT) Message-id: <01OE2UNN2HJ000ZUIL@mauve.mrochek.com> Date: Sun, 08 Apr 2012 14:08:23 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 04 Apr 2012 18:32:15 +0000" <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> To: "Murray S. Kucherawy" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Apr 2012 21:16:41 -0000 > This message starts Working Group Last Call for draft-ietf-appsawg-mime-default-charset. Please review the document and provide comments to the list, the co-chairs, or the authors by Friday, April 20th. > The datatracker link is https://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/. > -MSK, APPSAWG co-chair I just reviewed this document and it's looking good to me. You'll probably want to remove the anchor2 bit at the end of the WGLC. There also one very minor typo: OLD: "including absence of any default." NEW: "including the absence of any default." Ned From walter.stanish@gmail.com Sun Apr 8 15:30: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 5E85621F8554 for ; Sun, 8 Apr 2012 15:30:24 -0700 (PDT) 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=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwF1JLmepBoH for ; Sun, 8 Apr 2012 15:30:23 -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 6F1E021F8531 for ; Sun, 8 Apr 2012 15:30:23 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so5791652obb.31 for ; Sun, 08 Apr 2012 15:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Lpw9XsNV5kDCAS/+bZDbCixMMOP4dMOFJWk9GLAGn8g=; b=z0byZ1Du3umCECwdTLWLJx9LsW+gxfu4p0V5sY6ZRkCi785PQxNEC7SUNtsO5St2f0 7iVNmq2hRyT/KD5Hq7FWYY6y0w52W1cvaKNSEZZq2K18/asHG7tDURuYTp1voAB/ZxUw rzK49jMTUH2DN/1NXgY9oGsQr2NMt0vsNKsZANvG6mAjcAECfqn5PzAO74SqEhifC/Ge uYuUlGqv3HA8eVoMkoFlUOCCTnaeg+MvJF6TlYRiYoZpwmhU4VEpyW2ySlzNmT75LFDy cbCSPwHuOLWLkMFYIgpL0l+RGi9dZGcZbcp/oqRX+ofF3op8S+encjBcNGokkdi1Cil3 u+FA== MIME-Version: 1.0 Received: by 10.60.14.36 with SMTP id m4mr7203507oec.37.1333924222919; Sun, 08 Apr 2012 15:30:22 -0700 (PDT) Received: by 10.60.9.8 with HTTP; Sun, 8 Apr 2012 15:30:22 -0700 (PDT) In-Reply-To: References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> Date: Mon, 9 Apr 2012 05:30:22 +0700 Message-ID: From: Walter To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Apr 2012 22:30:24 -0000 > Given the clear consensus in the Applications Area, the Applications > ADs have decided NOT to create the proposed mailing list. =A0We suggest > that the proponents use Google, Yahoo!, or some other free service to > discuss their proposals with their many interested collaborators, and > consider coming to the IETF with a BoF proposal or working group > proposal when things are more solidly defined and ready to start real > protocol work. > > Walter: > We understand that you will not be happy with this response, but this > is clearly the consensus of the Applications Area participants and we > tend to agree with them. That said, we do want to add that many of > your messages, particularly the private ones to us, can best be > described as impatient and at worst, mean spirited, implying that any > refusal to create this mailing list only proves that the IETF is a > useless organization and that you'd simply "take your ball and go > home." =A0That's probably not the best way to gain the cooperation of > the community. We did set that aside (indeed, asking the rest of the > community, which was unaware of the content of our off-list messages) > and decided based on the potential benefits to the Internet and the > IETF, and the consensus of community. > > Barry and Pete, Applications Area Directors Thanks ("Barry and") Pete. Certainly, this is an *extremely* disappointing result and one that is in direct contrast to (1) previous communications (2) reasonable expectations from the internet finance innovation community (3) the IETF's own mission statement. Before closing out discussions around the request it does unfortunately seem, particularly given the rather extended and unflattering characterization of my person and perspective that you somehow thought to weave in to your response, necessary to raise a few honest points of concern with your statements. You will note that these points will continue to be focused on the matter at hand rather than personal character. (Regarding your negative statements regarding my person, and it is both regrettable for them to have occurred and - due to the nature of the forum - for me to be obliged to comment further, I am happy either accept your immediate and total retraction of all statements regarding my character or agreement to publish the full contents of the limited number of our off-list communications that you insinuate were in demonstration of poor faith or character on my part in order to clear my name for the public record - your choice, but promptly please.) Firstly, the phrase "discussion at the Paris meeting continued the skepticism from the community that such a list will do anything useful for IETF work." is at odds with the IETF charter which commits to providing a forum for technical matters relating to the internet community. The IETF charter is certainly NOT "to do anything useful for existing IETF work" (this is so Kafkaesque as to be laughable, if it were not so worrisome. Consider "The disease which inflicts bureaucracy and what they usually die from is routine." -- John Stuart Mill). More concretely, why should financial exchange continue to be excluded from open consideration under the IETF whilst telephony, messaging and other 'applications' are not? No objection was made when this question was raised earlier and in fact supporting statements from IETF history were made. Secondly, the phrase "resource spent in the management" seems almost a joke considering how much time has been requested and willingly volunteered over the past 4-5 months for the mere 'consideration' of this matter. To the observer it would appear that a mailing list runs itself, and nought further has been requested. If there is some issue of financial or human resource relating to administration then surely this should be detailed explicitly? Thirdly, the phrase "there's a worry that an IETF list may simply be used to claim that the IETF backs this work (which it doesn't, at least not yet), and perhaps, worse, that it backs it in preference to other related proposals." is nonsensical - there is probably a strong case that the IETF has an identity crisis. Firstly, the IETF's own documentation clearly states that there is no such thing as membership of the IETF and that it is effectively participation driven, with output being communications. The IETF does not 'back' anything. Opening a mailing list and inviting participation is akin to requesting participation and perspective (and thus, "IETF participation") from relevant parts of the internet community at large (such participation is equally if not more transparent and valid than discussion at physical meetings in particular languages and timezones). As this has not occurred to date, the IETF community in all likelihood cannot, should not, and will not claim any authority within the internet financial exchange sphere *anyway*, so who in this worrisome what-if world would care for their perceived backing? This whole point seems to be based on a premature and spurious question. In fact, *it is only by engaging in transparent, peer-reviewed discussions of exactly the type proposed - a mailing list hosted for the greater community - that we, the volunteer community of participants, can claim to have any authority of output whatsoever*. Fourthly, the insinuation that "real protocol work" occurs only within the IETF not only completely and demonstrably spurious but quite frankly condescending to the internet community at large given the nature of your response. Putting aside the above, and looking at the path of this proposal over the time since last December when it was initially made, perhaps IETF procedures would benefit from some good faith review, since IETF relevance to the modern internet community seems - at least from this quarter - to be in the throws of being largely undermined. Regarding the path forward for our proposed area of interest, the various quarters of the internet finance innovation community with which we have been in touch thus far will be forced to converge on an alternate, non-IETF forum. Whilst this could have been done months ago, the expedient option was sacrificed willingly in order to try to work with the IETF... an unfortunate but nonetheless well meant decision that I for one am very happy to stand by in hindsight... even if without mincing words it does rather seem that fair and democratic ideals are being viscerally dismembered by bureaucracy while an agreeable but disengaged audience idles nearby, engaged in the discreet patter of polite conversation with the occasional raised eyebrow and a glass of pleasant Parisian white, reaping the comfortable benefits of prior social engagement. To my mind, today is a sad day both for the internet community and for the = IETF. Yet consider... "Tis better to have loved and lost Than never to have loved at all" -- Tennyson and "It is unbecoming for young men to utter maxims." -- Aristotle (Truly, one should never take oneself too seriously.) Transparency triumphs in the end! Walter Stanish Payward, Inc. PS: Development will continue elsewhere and an appropriate message will be posted here once a venue is established, just for the record. Cheerio for the moment, then! From barryleiba@gmail.com Sun Apr 8 18:14: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 AC88021F8570 for ; Sun, 8 Apr 2012 18:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ef0vp1Ojsqfl for ; Sun, 8 Apr 2012 18:14:37 -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 228E421F856A for ; Sun, 8 Apr 2012 18:14:37 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so5910440obb.31 for ; Sun, 08 Apr 2012 18:14: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=nNaErDE2KMqwyEUEgMFgljOfPeqYO9J6r9QGH65DGsQ=; b=WYPq5+QFwj5kuzFPoV4LDuvwWRnUDers5CZfHqLg11ru0iFnX77XLRZ+ONGhAZIGJw Pd3xZPT1EyLgcO3OiuVeIP1XkjgG+j3nzw2gjZUDEkuQXxpnxgxyjlHZ2croe3jWrb2I V57DI9rFAmXbuYSJENzbBP8pWKvkbbufCWrDtc9FgjABnJzqluxPV6NXmk16Symlk6nn vfVq4AHhHnCrbZoJfG95DOpLX0auYtaiXdmvxCgk2rL4nvvZGIXFhlcgKv4FrvF34YUT v444iki0toBPCY/2CIBtSgNVjg+nypEI4Akc7kyn2KVpGRfAQg2rCX2BaCb1Uaamy+Et SR+g== MIME-Version: 1.0 Received: by 10.182.225.2 with SMTP id rg2mr7648839obc.2.1333934076744; Sun, 08 Apr 2012 18:14:36 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.10.68 with HTTP; Sun, 8 Apr 2012 18:14:36 -0700 (PDT) In-Reply-To: References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> Date: Sun, 8 Apr 2012 21:14:36 -0400 X-Google-Sender-Auth: wfUKXLhZ9SX4KQASlvREIw1Iolo Message-ID: From: Barry Leiba To: Walter Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Apr 2012 01:14:37 -0000 >> Walter: >> We understand that you will not be happy with this response, but [...] Crap. The part that starts as above wasn't meant to be posted publicly, and I screwed up. I wanted to get the message sent before I went out, and copy/pasted too hastily, including a part that I'd meant to send as a private note from me (not from Pete) later. Let me be clear that 1. that part was not meant to be posted publicly, and 2. that part was not from Pete and me together, but from me alone. I'm sorry that it got sent publicly, and I'm embarrassed at my error. Barry From walter.stanish@gmail.com Sun Apr 8 19:09: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 9C96021F859F for ; Sun, 8 Apr 2012 19:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CkM4oYcSqEB for ; Sun, 8 Apr 2012 19:09:37 -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 8341C21F85A2 for ; Sun, 8 Apr 2012 19:09:36 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so5956448obb.31 for ; Sun, 08 Apr 2012 19:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6Is+iDpm9lBDyo+mAk9cchorJrEOtlAEatvvNvHO0pQ=; b=EDA1Q/vLkOw0SYIjYHm0xY3uU+IhPezyxYBq9BkGBylNbNgjFw+/kUNHkOSh1VcvSj 50GmBDz6ZcrTLRFGW6y6OVAeezwmSAlDCBc1N75hoxeFjIMh4Uobzoldh7LFHVa8ABWu l+QdmNVfTjscgV2uWP/hiVpndKaoahG0iwuUCO1y1ugbZqUroDIEsFLfEbLb54ovCnUC DqW15/s75dUXej4mOkQ9CZEpHAC81snnw42a7CwQrVr4ro7G+zHHeWT+/IwEo3BGfNWu VIo4fPHHv6ER3PAn/1FDUOaN+ViJ3+nE5sDPQCdsupTi7/ngJJpWDLSHqPoKXjMVGHBj k49g== MIME-Version: 1.0 Received: by 10.60.14.166 with SMTP id q6mr7640100oec.17.1333937376196; Sun, 08 Apr 2012 19:09:36 -0700 (PDT) Received: by 10.60.9.8 with HTTP; Sun, 8 Apr 2012 19:09:36 -0700 (PDT) In-Reply-To: References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> Date: Mon, 9 Apr 2012 09:09:36 +0700 Message-ID: From: Walter To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Apr 2012 02:09:37 -0000 >>> Walter: >>> We understand that you will not be happy with this response, but [...] > > Crap. > The part that starts as above wasn't meant to be posted publicly, and > I screwed up. =A0I wanted to get the message sent before I went out, and > copy/pasted too hastily, including a part that I'd meant to send as a > private note from me (not from Pete) later. > > Let me be clear that > 1. that part was not meant to be posted publicly, and > 2. that part was not from Pete and me together, but from me alone. > > I'm sorry that it got sent publicly, and I'm embarrassed at my error. That's rather interesting given that you were not privy to most (earlier) communications. Regardless, I am still awaiting either a retraction of your statements regarding my character or an agreement to publish all communications in order to resolve the accusations for the public record. Your choice, but quickly please. - Walter From cabo@tzi.org Mon Apr 9 01:44: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 6211521F866A for ; Mon, 9 Apr 2012 01:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.631 X-Spam-Level: X-Spam-Status: No, score=-106.631 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhqrozDN0MaA for ; Mon, 9 Apr 2012 01:44:38 -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 371FD21F8659 for ; Mon, 9 Apr 2012 01:44:37 -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 q398iTNr017384 for ; Mon, 9 Apr 2012 10:44:29 +0200 (CEST) Received: from [192.168.217.105] (p5489A929.dip.t-dialin.net [84.137.169.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A5F8B9A7; Mon, 9 Apr 2012 10:44:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 9 Apr 2012 10:44:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> To: Apps Discuss X-Mailer: Apple Mail (2.1257) Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Apr 2012 08:44:39 -0000 I sent Walter a private message. I would ask anyone out of the IETF who wants to react to this message at = all, to do the same. Gr=FC=DFe, Carsten From julian.reschke@gmx.de Mon Apr 9 03:12: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 8931521F84DC for ; Mon, 9 Apr 2012 03:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axOg044zL-KK for ; Mon, 9 Apr 2012 03:12:18 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 82F2221F85AE for ; Mon, 9 Apr 2012 03:12:17 -0700 (PDT) Received: (qmail invoked by alias); 09 Apr 2012 10:12:15 -0000 Received: from unknown (EHLO [192.168.2.100]) [82.113.99.5] by mail.gmx.net (mp012) with SMTP; 09 Apr 2012 12:12:15 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+ZSV0FKhmZOX0/XOz+7Ka6dubSYYnVAJCTqK4+HS R4Ap524V64OmJz Message-ID: <4F82B5F6.3050806@gmx.de> Date: Mon, 09 Apr 2012 12:12:06 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ned Freed References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> <01OE2UNN2HJ000ZUIL@mauve.mrochek.com> In-Reply-To: <01OE2UNN2HJ000ZUIL@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Apr 2012 10:12:18 -0000 On 2012-04-08 23:08, Ned Freed wrote: >> This message starts Working Group Last Call for draft-ietf-appsawg-mime-default-charset. Please review the document and provide comments to the list, the co-chairs, or the authors by Friday, April 20th. > >> The datatracker link is https://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/. > >> -MSK, APPSAWG co-chair > > I just reviewed this document and it's looking good to me. > > You'll probably want to remove the anchor2 bit at the end of the WGLC. Of course. I'm also not totally convinced that HTTPbis actually needs to reference this document at all; any opinions on this? > There also one very minor typo: > > OLD: "including absence of any default." > NEW: "including the absence of any default." Done. Best regards, Julian From ned.freed@mrochek.com Mon Apr 9 07:34: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 565C121F8724 for ; Mon, 9 Apr 2012 07:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKRyzGIEDke8 for ; Mon, 9 Apr 2012 07:34:29 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D693221F8723 for ; Mon, 9 Apr 2012 07:34:29 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE3UWFQ1F400P50M@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 9 Apr 2012 07:34:26 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Mon, 9 Apr 2012 07:29:36 -0700 (PDT) Message-id: <01OE3UQGECV600ZUIL@mauve.mrochek.com> Date: Mon, 09 Apr 2012 07:28:17 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 09 Apr 2012 12:12:06 +0200" <4F82B5F6.3050806@gmx.de> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> <01OE2UNN2HJ000ZUIL@mauve.mrochek.com> <4F82B5F6.3050806@gmx.de> To: Julian Reschke Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Apr 2012 14:34:30 -0000 > On 2012-04-08 23:08, Ned Freed wrote: > >> This message starts Working Group Last Call for draft-ietf-appsawg-mime-default-charset. Please review the document and provide comments to the list, the co-chairs, or the authors by Friday, April 20th. > > > >> The datatracker link is https://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/. > > > >> -MSK, APPSAWG co-chair > > > > I just reviewed this document and it's looking good to me. > > > > You'll probably want to remove the anchor2 bit at the end of the WGLC. > Of course. > I'm also not totally convinced that HTTPbis actually needs to reference > this document at all; any opinions on this? Really ard to say without knowing how they deal with the iso-8859-1. I can see it being done in a way that doesn't need a reference. Or it could be done in a way where a reference would be helpful. Not sure I see any need for a normative reference though. Ned > > There also one very minor typo: > > > > OLD: "including absence of any default." > > NEW: "including the absence of any default." > Done. > Best regards, Julian From ted.ietf@gmail.com Mon Apr 9 07:42: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 8AD9321F8717; Mon, 9 Apr 2012 07:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzzTDoqTfAkN; Mon, 9 Apr 2012 07:42:08 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B64721F8713; Mon, 9 Apr 2012 07:42:08 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2198866vcb.31 for ; Mon, 09 Apr 2012 07:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8Klkpw7/8RdtBfrYWemgZ745qrSgg4b7kYfC8FOziEo=; b=Qtde9kS0MJycowsAnx+lWH87fdVsLmMHpoKmcMPOz/LkDqFW0dR/vBf52cizwqYfZj NytYh2RcL92+HU04tE9hoHi/jhN5kuOFG7NHehAS1T76ejHrVkLuwAdCXMQTkSqmP6cR uW3i5k+Vt3UgFkFBrfh5nWwWiUZh9c9fl57EDuaqAFPAbt/mgX6ngrprGO3WrV3xBW0R Fc5CNBJKBJUhqVgPda8+hZc3JqLoomz8qY2Kbpwh3rJjocD88yQUKzLO20FXtZ1ROxUK yAgAjlPIVUXS9KZcGA6OpZLwyP2e3X8b0hXbA/Gy8T5sInE316HGIIA4Tq0LhKFpx8TS DLAQ== MIME-Version: 1.0 Received: by 10.220.230.67 with SMTP id jl3mr3727559vcb.50.1333982527964; Mon, 09 Apr 2012 07:42:07 -0700 (PDT) Received: by 10.52.162.99 with HTTP; Mon, 9 Apr 2012 07:42:07 -0700 (PDT) In-Reply-To: <4F8182D7.1030106@sunet.se> References: <4F8182D7.1030106@sunet.se> Date: Mon, 9 Apr 2012 07:42:07 -0700 Message-ID: From: Ted Hardie To: Leif Johansson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-johansson-loa-registry.all@tools.ietf.org, IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Reivew of draft-johansson-loa-registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Apr 2012 14:42:09 -0000 On Sun, Apr 8, 2012 at 5:21 AM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > >> Each registration contains a URI, a schema definition, a short >> name, and an informational URL. =A0It is not clear, however, whether >> these URIs must be unique across registrations. =A0Would it be >> possible, for example, to have a non-SAML usage documented in this >> registry by having it re-register with an existing URI, but a >> different informational URL? I believe this point should be made >> explicit as guidance to the expert reviewers. > > No that would not be consistent with the intent of the registry. Did you > suggest that such a practice would be useful? > Honestly, I have no opinion on whether having multiple registrations with different informational URLs would be useful or not; it's hard to say without knowing= how much re-use there would be. I think it would be best if you clarified that= each registration must present a unique URI, though, if you don't intend for that to happen. >> >> The document uses ABNF to describe the required format of the short >> name, but there is no reference for ABNF given; presumably RFC5234 >> should be included as a reference. =A0 The ABNF =A0in the document >> excludes specific prefixes (LOA, AL) in order to avoid >> non-descriptive short names, but it is not clear why it also >> excludes all-digit references. =A0In general, the use of the ABNF for >> this seems fairly clumsy, and I would suggest that the document >> shift this from ABNF determinism to advice =A0(to both registrants >> and expert reviewers), to help ensure that the resulting names are >> useful. There are a host of equally problematic possibilities >> (saml-loa-10, for example) that good guidance would better avoid >> than ABNF rules. >> > > I see your point. However I believe there is value in having very > clear guidance which the ABNF does give... Perhaps if I include > text in the reviewers guide along the lines of "The reviewers should > exclude registrations where the short name does not unambiguously > identify the LoA definition or where the short name is a simple > variation on one of the reserved (cf above) LoA names." > That would make sense. Once you have updated the document and added the ABNF reference, a fresh run through an ABNF checker is probably in order. >> For the "informational URL" definition, a list of permitted URI >> schemes might be useful, as it is not clear whether a contact-only >> URI would be acceptable. The document says: >> >> Informational URL: =A0A URL containing auxilliary information. =A0This >> URL MUST minimally reference contact information for the >> administrative authority of the level of assurance definition. >> >> Would an informational URL of mailto:loa-registrant@example.org =A0be >> acceptable? >> > > Ah yes. Good catch! > Just to confirm, you plan to add a list? >> >> Minor Issues: >> >> The example given in 3.1 does not give an information URL, but the >> registration template implies that this field is mandatory. >> > > Good catch. Quite embarrassing :-) > >> In 4.1, the document twice uses the term "bona fide" to describe >> entries: >> >> The expectation of the IANA LoA Registry is that it contain bona >> fide Level of Assurance Profiles while not presenting a very high >> bar for entry. =A0Expert reviewers SHOULD NOT place undue value in >> any percieved or actual quality of the associated trust framework >> or federation and SHOULD only exclude such registrations that in >> the view of the experts do not represent bona fide attempts at >> defining an LoA. >> >> I suggest that "good faith" be used to replace at least one of >> these, to clarify the meaning. >> > > I like it. > >> >> >> >> Nits: [list editorial issues such as typographical errors, >> preferably by section number] >> >> I personally found the Introduction somewhat hard to parse, and I >> believe it would be improved by bringing paragraphs two and three >> forward, then following them with the gist of paragraphs one and >> four. >> >> >> In the Acknowledgements Section: >> >> The various versions of the draft was socialized >> >> should be "were socialized". > > Yep > Thanks for your quick reply, regards, Ted Hardie > =A0 =A0 =A0 =A0Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk+BgtEACgkQ8Jx8FtbMZnfR4ACbBK2JHXFpM9nEehqAp6IinGW9 > 2HwAn3qHKIXXpVHEHEEJ7+6qpmIZTc+a > =3DmHA3 > -----END PGP SIGNATURE----- From msk@cloudmark.com Mon Apr 9 09:25: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 E642F21F876E for ; Mon, 9 Apr 2012 09:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTUGESieEMEC for ; Mon, 9 Apr 2012 09:25:45 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 36E5821F8738 for ; Mon, 9 Apr 2012 09:25:45 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 09:25:44 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: draft-jones-appsawg-webfinger adoption Thread-Index: Ac0WbWmTl5dNaSbeReyxN4pCULWEwg== Date: Mon, 9 Apr 2012 16:25:44 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280CECC1@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.153] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280CECC1exchmbx901corpclo_" MIME-Version: 1.0 Subject: [apps-discuss] draft-jones-appsawg-webfinger adoption X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Apr 2012 16:25:46 -0000 --_000_9452079D1A51524AA5749AD23E0039280CECC1exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've changed the state of this document to "Call for WG Adoption Issued". = I believe there's rough consensus to process it through APPSAWG. If there are any other opinions, especially any against this idea, please s= ay so on the list or to the chairs (appsawg-chairs@tools.ietf.org) soon. Thanks, -MSK, APPSAWG co-chair --_000_9452079D1A51524AA5749AD23E0039280CECC1exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve changed the state of this document to = 220;Call for WG Adoption Issued”.  I believe there’s rough= consensus to process it through APPSAWG.

 

If there are any other opinions, especially any agai= nst this idea, please say so on the list or to the chairs (appsawg-chairs@tools.ietf.org) soon.

 

Thanks,

-MSK, APPSAWG co-chair

 

--_000_9452079D1A51524AA5749AD23E0039280CECC1exchmbx901corpclo_-- From internet-drafts@ietf.org Mon Apr 9 09:43: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 E13CD21F877F; Mon, 9 Apr 2012 09:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMITIL-S6Flh; Mon, 9 Apr 2012 09:43:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3E321F858A; Mon, 9 Apr 2012 09:43:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120409164305.14339.86233.idtracker@ietfa.amsl.com> Date: Mon, 09 Apr 2012 09:43:05 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-jones-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, 09 Apr 2012 16:43:06 -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 Worki= ng Group of the IETF. Title : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-jones-appsawg-webfinger-03.txt Pages : 20 Date : 2012-04-09 This specification defines the WebFinger protocol. WebFinger may be used to discover information about people on the Internet, such as a person's personal profile address, identity service, telephone number, or preferred avatar. WebFinger may also be used to learn information about objects on the network, such as the amount of toner in a printer or the physical location of a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-03.txt From cabo@tzi.org Mon Apr 9 09:57: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 EC85321F864E for ; Mon, 9 Apr 2012 09:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wraIRNOlAs+u for ; Mon, 9 Apr 2012 09:57:34 -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 18B6421F8780 for ; Mon, 9 Apr 2012 09:57:33 -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 q39GvLKR028885; Mon, 9 Apr 2012 18:57:21 +0200 (CEST) Received: from [192.168.217.117] (p54899DC6.dip.t-dialin.net [84.137.157.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1CCFAA18; Mon, 9 Apr 2012 18:57:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> Date: Mon, 9 Apr 2012 18:57:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Apr 2012 16:57:35 -0000 * Technical summary This is the right thing to do, and should have been done right after the = end of the UTF wars. * Editorial issues The document appears to spell out a SHOULD for "text/html" and = "text/xml". Does it change the meaning of text/html and text/xml? Reading more closely, this apparently isn't meant, but there is a = potential misunderstanding. More generally: When looking at a random media type three years from now, how do I find = out whether this sentence does apply: It does not change the defaults for any currently registered media type. Even more generally:=20 Who is affected by (needs to read) this specification? Who are the targets of the SHOULDs and MUSTs? How do I find out whether an implementation complies? interoperates? And meta^3: What is the IETF name for specifications that are exclusively intended = to remind us not to make a certain class of mistake again when = generating future specifications? Which specification wins when such a = meta-specification is neglected in a specific specification? Gr=FC=DFe, Carsten From stpeter@stpeter.im Mon Apr 9 10:49: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 C38E921F879B; Mon, 9 Apr 2012 10:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qWZwlS4rpg0; Mon, 9 Apr 2012 10:49:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BBF8521F879A; Mon, 9 Apr 2012 10:49:25 -0700 (PDT) Received: from dhcp-64-101-72-235.cisco.com (unknown [64.101.72.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1908940058; Mon, 9 Apr 2012 12:03:09 -0600 (MDT) Message-ID: <4F832123.8030304@stpeter.im> Date: Mon, 09 Apr 2012 11:49:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Henry S. Thompson" References: In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-xdash-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, 09 Apr 2012 17:49:26 -0000 Hi Henry, thanks for the review. Comments inline. On 3/30/12 4:20 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-xdash > > Title: Deprecating the X- Prefix and Similar Constructs in Application Protocols > > Reviewer: Henry S. Thompson > > Review Date: 2012-03-30 > > IETF Last Call Date: 2012-03-15 > > Summary: This draft is almost ready for publication as an Proposed > Standard but has a few issues that should be fixed > before publication > > Major Issues: > > Abstract and Introduction > > [This started out as a nit about the use of scare-quotes in the > Abstract, but now that I see how much depends on it throughout the > document, I have promoted it] > > I have an allergy to scare-quotes, I guess, but putting > quotes around "standard" here seems . . . odd. If what you mean is > more along the lines of "distinguished between the names of parameters > defined in the relevant standards and those without such definitions", > then words along those lines might serve better. . . I'm not a big fan of scare quotes, either. The point here is that people have assumed that parameters without X- or similar constructs are produced in accordance with a standards process (e.g., even if they are registered directly with the IANA such a registration has been handled as defined in a specification produced by a recognized standards development organization), and have assumed that parameters with X- or similar constructs are produced outside a standards process. Given the leakage of the latter parameters into the standards space, we included the scare quotes to indicate that the categories of standard parameters and non-standard parameters are imprecise and illegitimate (some apparently non-standard parameters are de facto standards on the wire). In our discussions with the IESG, Dave Crocker suggested the term "standardized", and after a bit of reflection I now think that would be clearer because a de facto standard simply emerges and can't be said to have been actively standardized / produced in accordance with a standards process. > If you make such > a change, then "newly-defined parameters" could become something such > as "parameters getting their names outside the standards process". Well, newly-defined parameters are any parameters that people create and name after this document is published as a BCP, so they will have gotten their names in accordance with a standards process. :) > More importantly, the distinction between "parameters named in, or by > means licensed by, the relevant standard" and "parameters named > elsewhere" deserves more careful definition than that implied just by > contrasting, in quotes, "standard" and "non-standard", given the > weight the distinction has to bear later on. My take is that people have conflated standardized parameters with standard parameters, thinking that a parameter that was never standardized cannot become a standard. Clearly that's not true, because some parameters that were never standardized (that were not produced in accordance with a standards process) have become standard parameters. The more I think about it, the more I would prefer the terms 'standardized' and 'unstandardized' (without any scare quotes) over the terms 'standard' and 'non-standard'. Thus, I suggest the following clarifications to the Introduction (as well as appropriate terminology changes throughout): Many application protocols use parameters with textual (as opposed to numerical) names to identify data (media types, header fields in Internet mail messages and HTTP requests, vCard parameters and properties, etc.). Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs (e.g., "x."), where the "X" is commonly understood to stand for "eXperimental" or "eXtension". Under this convention, the name of a parameter not only identified the data, but also embedded the status of the parameter into the name itself: a parameter defined in a specification produced by a recognized standards development organization (or registered according to processes defined in such a specification) did not start with "X-" or similar constructs, whereas a parameter defined outside such a specification or process started with "X-" or similar constructs. > Section 2. Maybe not major? Depends on the answer. What does > "discriminate between 'standard' and 'non-standard' parameters" > actually _mean_? Either a parameter is defined in the relevant > standard, or via a standards-licensed route, or it isn't. This > section seems to imply there is some kind of generic processing > reserved to parameters named in or licensed by the relevant standard > (or, perhaps, to parameters _not_ so named), but this reader at least > is not clear what such generic processing might be. Based on IESG feedback, we changed Section 2 to read: Implementations of application protocols MUST NOT make any assumptions about the status of a parameter, nor take automatic action regarding a parameter, based solely on the presence or absence of "X-" or a similar construct in the parameter's name. > It seems that the > authors of this RFC know, or suspect, that some application > implementers are lazy, and deploy such processing without actually > using a list derived from the relevant specs and registries---if so, > give an example? If not, what is this section for, exactly? Mark, would you like to provide some examples based on your experience? > Minor Issues: > > 3 Maybe, if you think there are relevant cases, add something along > the lines of "MUST follow any naming guidelines set out in the > relevant standard(s)". We do say that this specification does not override naming rules for existing application protocols (e.g., the "x-name" token in RFC 5545). Are there other naming guidelines that you have in mind here? Thanks again, Peter -- Peter Saint-Andre https://stpeter.im/ From ned.freed@mrochek.com Mon Apr 9 11:59: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 23F3B21F86C6 for ; Mon, 9 Apr 2012 11:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az+58xfrm4e5 for ; Mon, 9 Apr 2012 11:59:38 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1FC21F846F for ; Mon, 9 Apr 2012 11:59:38 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE44661FHS009RVF@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 9 Apr 2012 11:59:35 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Mon, 9 Apr 2012 11:59:33 -0700 (PDT) Message-id: <01OE44651K9400ZUIL@mauve.mrochek.com> Date: Mon, 09 Apr 2012 11:29:28 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 09 Apr 2012 18:57:20 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> To: Carsten Bormann Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Apr 2012 18:59:39 -0000 > * Technical summary > This is the right thing to do, and should have been done right after the end of the UTF wars. Not entirely sure we had the necessary understanding of the issues at that point, but it's water under the bridge in any case. > * Editorial issues > The document appears to spell out a SHOULD for "text/html" and "text/xml". > Does it change the meaning of text/html and text/xml? > Reading more closely, this apparently isn't meant, but there is a potential misunderstanding. There are a total of three places where there are references to these media types. There's no compliance language at all in the first two locations, and the third location is inside of a parenthetical phrase that also contains no compliance language. Unless you manage to miss th=ose parentheses there's simply no way these references can be conflated with compliance language. And if we're to the point where we're trying to write prose that's consistent even when basic punctuation cues are missed, well, all I can say is that we've got a lot of work ahead of us. That said, if this really is a valid concern (I'm extremely skeptical myself), one way to address is would be to omit the third reference entirely (maybe mention text/html in the second along with text/xml). If that isn't sufficient, my only other suggestion would be to say something like "XML and HTML based media types" instead of referring to those types specificaly. But that last seems like serious overkill. > More generally: > When looking at a random media type three years from now, how do I find out > whether this sentence does apply: > It does not change the > defaults for any currently registered media type. Um, the absence of any sort change to a specific subset of the types necessarily applies universally. More specifically, since this specification doesn't change any default anywhere, it doesn't matter in the slightest when the type was registered. New types are supposed to either make charset mandatory or not allow it at all. And you can tell that the case by, well, reading the registration and seeing whether or not they did that. The only way there would be some sort of flag day problem here is if some sort of default was changed. But this document does not do that, and Section 4 is already quite explicit about this. (HTTPbis may do this for text/html, but that's an issue for that set of documents to deal with.) > Even more generally: > Who is affected by (needs to read) this specification? Since this document specifies how registrations for types that allow for multiple characters and which might employ charset parameters, anyone creating registrations subject to those issues should read it. This is why there's a normative reference in the revised media type registrations procedures to this document. > Who are the targets of the SHOULDs and MUSTs? See above. > How do I find out whether an implementation complies? interoperates? I assume this is intended to become a BCP. (The IESG makes the final determination on that, and has from time to time had what I regard as screwy notions about the correct track for some documents, but in this case BCP seems rather obvious.) BCP aren't necessarily about implementations or interoperability. In this particular case we're talking about registration compliance. This will become part of the media type registration review process once it is approved. > And meta^3: > What is the IETF name for specifications that are exclusively intended to > remind us not to make a certain class of mistake again when generating future > specifications? I have no idea. But since that's not what this specification is doing, I fail to see the relevance. > Which specification wins when such a meta-specification is neglected in a > specific specification? This is tantamount to asking, "What happens if the IESG and/or media type reviwer screw up and fail to properly apply these new rules to some registration." The answer is we handle it like any other screwup using processes we already have in place for such things. Ned From internet-drafts@ietf.org Mon Apr 9 18:41: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 1BA3211E8095; Mon, 9 Apr 2012 18:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5kUnGHUwNcX; Mon, 9 Apr 2012 18:41:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9397E11E8079; Mon, 9 Apr 2012 18:41:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120410014118.2007.8059.idtracker@ietfa.amsl.com> Date: Mon, 09 Apr 2012 18:41:18 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-05.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, 10 Apr 2012 01:41:19 -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 Worki= ng Group of the IETF. Title : Deprecating the X- Prefix and Similar Constructs in Appl= ication Protocols Author(s) : Peter Saint-Andre D. Crocker Mark Nottingham Filename : draft-ietf-appsawg-xdash-05.txt Pages : 13 Date : 2012-04-09 Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly-defined parameters with textual (as opposed to numerical) names in application protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-xdash-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-xdash-05.txt From stpeter@stpeter.im Mon Apr 9 18:45: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 E5CDE11E8079 for ; Mon, 9 Apr 2012 18:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7E6Nw+y+G67 for ; Mon, 9 Apr 2012 18:45:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC9B11E8074 for ; Mon, 9 Apr 2012 18:45:27 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 60B8540058 for ; Mon, 9 Apr 2012 19:59:13 -0600 (MDT) Message-ID: <4F8390B6.8060907@stpeter.im> Date: Mon, 09 Apr 2012 19:45:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20120410014118.2007.8059.idtracker@ietfa.amsl.com> In-Reply-To: <20120410014118.2007.8059.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-05.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, 10 Apr 2012 01:45:28 -0000 This version addresses feedback from the IESG and the AppsDir review. Continued feedback is welcome. On 4/9/12 7:41 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : Deprecating the X- Prefix and Similar Constructs in Application Protocols > Author(s) : Peter Saint-Andre > D. Crocker > Mark Nottingham > Filename : draft-ietf-appsawg-xdash-05.txt > Pages : 13 > Date : 2012-04-09 > > Historically, designers and implementers of application protocols > have often distinguished between standardized and unstandardized > parameters by prefixing the names of unstandardized parameters with > the string "X-" or similar constructs. In practice, that convention > causes more problems than it solves. Therefore, this document > deprecates the convention for newly-defined parameters with textual > (as opposed to numerical) names in application protocols. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-xdash-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-xdash-05.txt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From James.H.Manger@team.telstra.com Mon Apr 9 21:08: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 D70AE21F8593 for ; Mon, 9 Apr 2012 21:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.028 X-Spam-Level: X-Spam-Status: No, score=0.028 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBZ1TyRTvALv for ; Mon, 9 Apr 2012 21:08:19 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 06E2921F858F for ; Mon, 9 Apr 2012 21:08:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,397,1330866000"; d="scan'208";a="69086626" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 10 Apr 2012 14:08:17 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6675"; a="57931249" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipccvi.tcif.telstra.com.au with ESMTP; 10 Apr 2012 14:08:17 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Tue, 10 Apr 2012 14:08:16 +1000 From: "Manger, James H" To: Stephen Farrell Date: Tue, 10 Apr 2012 14:08:15 +1000 Thread-Topic: draft-farrell-decade-ni-02: glitch in examples Thread-Index: Ac0Tdv8UPe/vtTqdSlGaFLO6WlVXZgDSdC2A Message-ID: <255B9BB34FB7D647A506DC292726F6E114F0499619@WSMSG3153V.srv.dir.telstra.com> References: <4F7DFC47.2020604@cs.tcd.ie> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Apps Discuss Subject: [apps-discuss] draft-farrell-decade-ni-02: glitch in examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 04:08:20 -0000 Stephen, A couple of "typos" in draft-farrell-decade-ni-02: The example SubjectPublicKeyInfo is shown in a strange way: each pair of by= tes is shown in the opposite order to bytes on the wire (and the offset at = the start of the line is in nibbles). The first few bytes of the BER-encodi= ng are 30 820122, while the example starts: 0000000 8230 2201 0d30 0906 862a 8648 0df7 0101 The BER-encoding is actually: 30 820122 30 0D 06 09 2A86 ... Half of the example names are wrong, almost certainly due to this strange f= ormat.=20 The 120-bit "Binary Name" in figure 6 is wrong. It swaps the order of bytes= (after the first). It should be: 03 53269057 E12FE2B7 4BA07C89 2560A2 The human-readable names (120-bit and 32-bit) are wrong. They have base32-e= ncoded pairs of bytes in the wrong order. They should be: sha-256-120;kmtjav7bf7rlos5apseskyfc;???? sha-256-32;kmtjavy;???? I am not sure what the correct checksums are. The example checksums (eokv and csdh) look wrong. I assume the 4 base32 cha= rs in the checksum should encode 5+5+5+1 bits respectively of the 16-bit CR= C. Hence the last char encodes 1 bit, padded with 4 zeros: either 00000 or = 10000, which should give 'a' or 'q' (not 'v' or 'h'). P.S. A CRC16 is calculated over an array of bytes. However the input is def= ined as a text string. I guess ASCII/UTF-8 encoding is assumed. It might be= better to calculate the CRC over the bytes of the truncated hash. -- James Manger From hannes.tschofenig@gmx.net Tue Apr 10 00:36: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 4738F21F86FC for ; Tue, 10 Apr 2012 00:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yhlQ1QT873V for ; Tue, 10 Apr 2012 00:36:00 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0FCF721F86A0 for ; Tue, 10 Apr 2012 00:35:59 -0700 (PDT) Received: (qmail invoked by alias); 10 Apr 2012 07:35:58 -0000 Received: from unknown (EHLO [10.255.128.206]) [192.100.123.77] by mail.gmx.net (mp035) with SMTP; 10 Apr 2012 09:35:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19EpL9/1ZZEgF4ibnSZkaO1HABP+Hzojr79fXLSf5 WxX9LdF0J5MyyE Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: Date: Tue, 10 Apr 2012 10:35:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3553E9F7-3E65-4143-BCF1-D8529D1A7C84@gmx.net> References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Apps Discuss Subject: [apps-discuss] Payment Protocols -- was Re: Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 07:36:01 -0000 Hi Carsten,=20 I don't know why we have to switch to private communication here.=20 While I am still trying to catch up with the mailing list discussion. = =46rom the discussion I have seen so far I believe the usual = "terminology" problem showed up here.=20 The title "finance area mailing list" is probably the wrong term. = Instead, we are talking about Internet payment protocols. There is = nothing really magic about these protocols and we have to a certain = extent worked on those type of protocols already in the IETF, as some of = you had stated already. Even I had worked myself on a (failed) payment = protocol (see = http://tools.ietf.org/html/draft-jennings-sipping-pay-06)... Of course, = they may not cover all the use cases Walter probably has in mind (and I = do not fully understand the long list of stated functionality myself = either).=20 Nevertheless, there are various groups who are quite pragmatic and have = started (or even finished) their work on payment protocols. I had been = approached last year by some folks from the Web identity management = community who wanted to standardize an OAuth based payment protocol. = Sounds crazy? Not really. Facebook is using such a protocol with their = 'Facebook Credits' (see https://developers.facebook.com/docs/credits/) = and so is Google with 'Google Checkout/Google Wallet'. Just recently = the OMA had standardized their new payment protocol (see = http://oneapi.gsmworld.com/payment-restful-api/) focusing on the needs = of their telecommunication operator community. To my knowledge all these = approaches use OAuth under the hood.=20 I don't know how far these attempts are away from what Walter is trying = to accomplish. I believe the main disconnect is in the understanding of = how the process works in bringing work to the IETF and the lack of = agreed terminology and scope makes is easy to talk past each other.=20 Once getting to the point of talking about the same topic there are = various other challenges, such as=20 * who are all the stakeholders that need to be involved?=20 * are these communities interested to bring their work to the IETF?=20 * are they interested in a common standard? * are there use cases similar or where are the differences? =20 * is this work likely to hit deployment (given that there were some = unsuccessful attempts in the past already)? * why did various earlier attempts fail?=20 [I am particularly interested in the last item given that we see a = number of new efforts showing up these days.] =20 Ciao Hannes On Apr 9, 2012, at 11:44 AM, Carsten Bormann wrote: > I sent Walter a private message. > I would ask anyone out of the IETF who wants to react to this message = at all, to do the same. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From stephen.farrell@cs.tcd.ie Tue Apr 10 00: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 CCD0221F8757 for ; Tue, 10 Apr 2012 00:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.416 X-Spam-Level: X-Spam-Status: No, score=-103.416 tagged_above=-999 required=5 tests=[AWL=-2.213, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTBG9qDpDJ30 for ; Tue, 10 Apr 2012 00:48:43 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id CC9CE21F8741 for ; Tue, 10 Apr 2012 00:48:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 870D6171474; Tue, 10 Apr 2012 08:48:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1334044119; bh=UFi3a TwWG4uZRta2+z7l3R7gQQjkvIWYh3ABqtrg3dk=; b=bQSI2oujx/NHJSG/hXHil eFyNeOLzRy15yvRDLw/IqINB5s36mWZUzca4/37JNu8m974TDhBLtXafeRUqHXfk MfVH0TO1l61aZyWsJhoAQqxWRs0H9j96h5YCxthYEeGUytRuPmw9dEdwRSVZKgnf elTGwN98sSbLsDrhboCzKGyFYMdBah5F6ZOWyYj5Eo1GM3JiYDijlP5NZaPNueEv 8xoPYQ0HrGisdyYFx2FPvqZsvuHNGOiAUibwFcOj7t/UGWWlhJPWpXqiGYTQbqKc bh50rx3fMm0GiynBcpuGSs7LM+Dix56o1RJC1elOXme6aw/uNR2MuoUZfQgtKQ3U Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 4cy4C9-Fl24g; Tue, 10 Apr 2012 08:48:39 +0100 (IST) Received: from [10.87.48.6] (unknown [86.46.27.125]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 09655171473; Tue, 10 Apr 2012 08:48:33 +0100 (IST) References: <4F7DFC47.2020604@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F0499619@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F0499619@WSMSG3153V.srv.dir.telstra.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B176) From: Stephen Farrell Date: Tue, 10 Apr 2012 08:48:30 +0100 To: "Manger, James H" Cc: Apps Discuss Subject: Re: [apps-discuss] draft-farrell-decade-ni-02: glitch in examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 07:48:43 -0000 Thanks James. Looks odd ok, will check it out & get back, Good catch though, Cheers, S On 10 Apr 2012, at 05:08, "Manger, James H" wrote: > Stephen, >=20 > A couple of "typos" in draft-farrell-decade-ni-02: >=20 > The example SubjectPublicKeyInfo is shown in a strange way: each pair of b= ytes is shown in the opposite order to bytes on the wire (and the offset at t= he start of the line is in nibbles). The first few bytes of the BER-encoding= are 30 820122, while the example starts: > 0000000 8230 2201 0d30 0906 862a 8648 0df7 0101 >=20 > The BER-encoding is actually: > 30 820122 > 30 0D > 06 09 2A86 > ... >=20 > Half of the example names are wrong, almost certainly due to this strange f= ormat.=20 >=20 > The 120-bit "Binary Name" in figure 6 is wrong. It swaps the order of byte= s (after the first). It should be: > 03 53269057 E12FE2B7 4BA07C89 2560A2 >=20 > The human-readable names (120-bit and 32-bit) are wrong. They have base32-= encoded pairs of bytes in the wrong order. They should be: > sha-256-120;kmtjav7bf7rlos5apseskyfc;???? > sha-256-32;kmtjavy;???? >=20 > I am not sure what the correct checksums are. >=20 > The example checksums (eokv and csdh) look wrong. I assume the 4 base32 ch= ars in the checksum should encode 5+5+5+1 bits respectively of the 16-bit CR= C. Hence the last char encodes 1 bit, padded with 4 zeros: either 00000 or 1= 0000, which should give 'a' or 'q' (not 'v' or 'h'). >=20 > P.S. A CRC16 is calculated over an array of bytes. However the input is de= fined as a text string. I guess ASCII/UTF-8 encoding is assumed. It might be= better to calculate the CRC over the bytes of the truncated hash. >=20 >=20 > -- > James Manger >=20 From julian.reschke@gmx.de Tue Apr 10 01:25: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 7FC3F21F8725 for ; Tue, 10 Apr 2012 01:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBYYWkiKAC2F for ; Tue, 10 Apr 2012 01:25:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 99E8E21F8720 for ; Tue, 10 Apr 2012 01:25:37 -0700 (PDT) Received: (qmail invoked by alias); 10 Apr 2012 08:25:36 -0000 Received: from p57A6FD87.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.253.135] by mail.gmx.net (mp004) with SMTP; 10 Apr 2012 10:25:36 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/xxn1NX8jxNgdWHG6r1PbUpLAPP5/FxHENopc01X IZrJ7jibKRtDFi Message-ID: <4F83EE7F.3070707@gmx.de> Date: Tue, 10 Apr 2012 10:25:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ned Freed References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> <01OE2UNN2HJ000ZUIL@mauve.mrochek.com> <4F82B5F6.3050806@gmx.de> <01OE3UQGECV600ZUIL@mauve.mrochek.com> In-Reply-To: <01OE3UQGECV600ZUIL@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 08:25:38 -0000 On 2012-04-09 16:28, Ned Freed wrote: > ... >> I'm also not totally convinced that HTTPbis actually needs to reference >> this document at all; any opinions on this? > > Really ard to say without knowing how they deal with the iso-8859-1. I > can see > it being done in a way that doesn't need a reference. Or it could be > done in a > way where a reference would be helpful. HTTPbis simply has stopped having a custom rule; it just delegates to the applicable MIME specs. -> > Not sure I see any need for a normative reference though. > > Ned > ... Best regards, Julian From julian.reschke@gmx.de Tue Apr 10 01:29: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 F2FE621F8720 for ; Tue, 10 Apr 2012 01:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnYJ6F0BqpCc for ; Tue, 10 Apr 2012 01:29:43 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 19C0221F84DA for ; Tue, 10 Apr 2012 01:29:42 -0700 (PDT) Received: (qmail invoked by alias); 10 Apr 2012 08:29:42 -0000 Received: from p57A6FD87.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.253.135] by mail.gmx.net (mp012) with SMTP; 10 Apr 2012 10:29:42 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/Fy34WTR7Fr3cJdK6kI798wa9oweIb8BXBmPUfZi S+XY2fCY0+gJUj Message-ID: <4F83EF76.3000703@gmx.de> Date: Tue, 10 Apr 2012 10:29:42 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Carsten Bormann References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 08:29:44 -0000 On 2012-04-09 18:57, Carsten Bormann wrote: > * Technical summary > > This is the right thing to do, and should have been done right after the end of the UTF wars. > > * Editorial issues > > The document appears to spell out a SHOULD for "text/html" and "text/xml". > Does it change the meaning of text/html and text/xml? No. But it licenses future revisions of these specs to do the right thing. > Reading more closely, this apparently isn't meant, but there is a potential misunderstanding. We tried to clarify this in the latest draft. Can you suggest changes? > More generally: > When looking at a random media type three years from now, how do I find out whether this sentence does apply: > It does not change the > defaults for any currently registered media type. The media type definition will have to state the default. > Even more generally: > Who is affected by (needs to read) this specification? > Who are the targets of the SHOULDs and MUSTs? > How do I find out whether an implementation complies? interoperates? The audience is people registering media types. And yes, one could argue this spec needs to RFC2119 keywords. > And meta^3: > What is the IETF name for specifications that are exclusively intended to remind us not to make a certain class of mistake again when generating future specifications? Which specification wins when such a meta-specification is neglected in a specific specification? This document updates RFC 2046, I don't think more needs to be done here... Best regards, Julian From cabo@tzi.org Tue Apr 10 01:54: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 194EE21F8745 for ; Tue, 10 Apr 2012 01:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy-88HhL3kfd for ; Tue, 10 Apr 2012 01:54:26 -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 CA16D21F872F for ; Tue, 10 Apr 2012 01:54:20 -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 q3A8s9tH002370; Tue, 10 Apr 2012 10:54:09 +0200 (CEST) Received: from [192.168.217.105] (p54899DC6.dip.t-dialin.net [84.137.157.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6FDB8BE3; Tue, 10 Apr 2012 10:54:09 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F83EF76.3000703@gmx.de> Date: Tue, 10 Apr 2012 10:54:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> <4F83EF76.3000703@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 08:54:27 -0000 On Apr 10, 2012, at 10:29, Julian Reschke wrote: > On 2012-04-09 18:57, Carsten Bormann wrote: >> * Technical summary >>=20 >> This is the right thing to do, and should have been done right after = the end of the UTF wars. >>=20 >> * Editorial issues >>=20 >> The document appears to spell out a SHOULD for "text/html" and = "text/xml". >> Does it change the meaning of text/html and text/xml? >=20 > No. But it licenses future revisions of these specs to do the right = thing. >=20 >> Reading more closely, this apparently isn't meant, but there is a = potential misunderstanding. >=20 > We tried to clarify this in the latest draft. Can you suggest changes? (such as "text/html" and "text/xml")=20 -> (such as "text/html" and "text/xml" are able to)=20 And in the start of that paragraph: registrations -> future registrations >=20 >> More generally: >> When looking at a random media type three years from now, how do I = find out whether this sentence does apply: >> It does not change the >> defaults for any currently registered media type. >=20 > The media type definition will have to state the default. Yes. s/currently// Again. maybe=20 for text/* media types -> for future registrations of text/* media types in the same paragraph. >> Even more generally: >> Who is affected by (needs to read) this specification? >> Who are the targets of the SHOULDs and MUSTs? >> How do I find out whether an implementation complies? interoperates? >=20 > The audience is people registering media types. >=20 > And yes, one could argue this spec needs to RFC2119 keywords. I can't parse that last sentence. The MUST and the MUST NOT at the end of 3 are clearly meta-specs, and = not for registrations either, but for "protocols". They generate a conflict for existing specs such as RFC 2616 without = indication how to resolve that conflict. I know (the draft is mute about that) that we are fixing 2616, but this = draft says nothing about how to handle that kind of conflict. Again, adding little words such as "future" might help. Or maybe the indication that these existing conflicting protocols are = unbearable and will all need to be fixed (!?). >=20 >> And meta^3: >> What is the IETF name for specifications that are exclusively = intended to remind us not to make a certain class of mistake again when = generating future specifications? Which specification wins when such a = meta-specification is neglected in a specific specification? >=20 > This document updates RFC 2046, I don't think more needs to be done = here... I'm fine with that, I'm just not fine with the ambiguity resulting from = retroactively changing meta-specs that have conflicting specs in force. I think with the above clarifications in place we might be reaching the = point of diminishing returns in managing this specific conflict. I'm just trying to make the more general point here that you have to be = careful in how you rewrite history. Gr=FC=DFe, Carsten From julian.reschke@gmx.de Tue Apr 10 02:03: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 0CB8921F8731 for ; Tue, 10 Apr 2012 02:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vO4QqIktnpKZ for ; Tue, 10 Apr 2012 02:03:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 05A8921F8670 for ; Tue, 10 Apr 2012 02:03:16 -0700 (PDT) Received: (qmail invoked by alias); 10 Apr 2012 09:03:13 -0000 Received: from p57A6FD87.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.253.135] by mail.gmx.net (mp040) with SMTP; 10 Apr 2012 11:03:13 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19+FxwjJIB+CyQW0GZ+QPavPtHV9cKEMeC5aHnl4d 5PnslMZYfm2u15 Message-ID: <4F83F74D.2020206@gmx.de> Date: Tue, 10 Apr 2012 11:03:09 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Carsten Bormann References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> <4F83EF76.3000703@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 09:03:18 -0000 On 2012-04-10 10:54, Carsten Bormann wrote: > On Apr 10, 2012, at 10:29, Julian Reschke wrote: > >> On 2012-04-09 18:57, Carsten Bormann wrote: >>> * Technical summary >>> >>> This is the right thing to do, and should have been done right after the end of the UTF wars. >>> >>> * Editorial issues >>> >>> The document appears to spell out a SHOULD for "text/html" and "text/xml". >>> Does it change the meaning of text/html and text/xml? >> >> No. But it licenses future revisions of these specs to do the right thing. >> >>> Reading more closely, this apparently isn't meant, but there is a potential misunderstanding. >> >> We tried to clarify this in the latest draft. Can you suggest changes? > > (such as "text/html" and "text/xml") > -> > (such as "text/html" and "text/xml" are able to) > > And in the start of that paragraph: > > registrations > -> > future registrations Thanks for the suggestions. I will consider these... >>> More generally: >>> When looking at a random media type three years from now, how do I find out whether this sentence does apply: >>> It does not change the >>> defaults for any currently registered media type. >> >> The media type definition will have to state the default. > > Yes. > > s/currently// > > Again. maybe > > for text/* media types > -> > for future registrations of text/* media types > > in the same paragraph. > >>> Even more generally: >>> Who is affected by (needs to read) this specification? >>> Who are the targets of the SHOULDs and MUSTs? >>> How do I find out whether an implementation complies? interoperates? >> >> The audience is people registering media types. >> >> And yes, one could argue this spec needs to RFC2119 keywords. > > I can't parse that last sentence. I meant to say "does not need". > The MUST and the MUST NOT at the end of 3 are clearly meta-specs, and not for registrations either, but for "protocols". > They generate a conflict for existing specs such as RFC 2616 without indication how to resolve that conflict. Good point. Note it has been resolved for httpbis a long time ago. > I know (the draft is mute about that) that we are fixing 2616, but this draft says nothing about how to handle that kind of conflict. > > Again, adding little words such as "future" might help. > Or maybe the indication that these existing conflicting protocols are unbearable and will all need to be fixed (!?). > >> >>> And meta^3: >>> What is the IETF name for specifications that are exclusively intended to remind us not to make a certain class of mistake again when generating future specifications? Which specification wins when such a meta-specification is neglected in a specific specification? >> >> This document updates RFC 2046, I don't think more needs to be done here... > > I'm fine with that, I'm just not fine with the ambiguity resulting from retroactively changing meta-specs that have conflicting specs in force. > I think with the above clarifications in place we might be reaching the point of diminishing returns in managing this specific conflict. > I'm just trying to make the more general point here that you have to be careful in how you rewrite history. > ... Understood. I don't think we *are* rewriting history, though. Best regards, Julian From sm@resistor.net Tue Apr 10 02:26: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 341CE11E8089 for ; Tue, 10 Apr 2012 02:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJ8RNix-UoeK for ; Tue, 10 Apr 2012 02:25:59 -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 11B0411E8086 for ; Tue, 10 Apr 2012 02:25:58 -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 q3A9PfKY016976; Tue, 10 Apr 2012 02:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334049947; i=@resistor.net; bh=6lnq2cnThKdn2pZOr8fwnJ916gBFZ4dkA3TuriYEWzM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XsZnDQjDI4oRV39R76cocVjgZgm0S7QJcLWSkZuXwGVc4nggXM02CIjSJgXTWNsdo HE5Eg7/LJrpPRMe2+lnWF0CFUHSr3LD35IYN4A8Ugx9lVOia2UF79cr1DRNYJcpPY9 qr1fhpFVTVqDZZYjhWGbwH6mfDAQFfK8DQdSgssU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334049947; i=@resistor.net; bh=6lnq2cnThKdn2pZOr8fwnJ916gBFZ4dkA3TuriYEWzM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=i3Fl7tiKdiJ2+MX1gnNOx2lCpokQj0/xHyiYgkZ5QQDLFtG9nb/PyTk+6DZmZA31g L8PplPaUNnuCWym3J7yAhBMwB1lg/ln4vNeCZCsysrHL4jjOFunapn07EtqhPa6smr pgmNJ28HFbHdSjPcQFuWsn5cMI6cx13Ogc73YOso= Message-Id: <6.2.5.6.2.20120410004434.0b0b7920@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Apr 2012 01:23:52 -0700 To: Hannes Tschofenig , Carsten Bormann From: SM In-Reply-To: <3553E9F7-3E65-4143-BCF1-D8529D1A7C84@gmx.net> References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> <3553E9F7-3E65-4143-BCF1-D8529D1A7C84@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Apps Discuss Subject: Re: [apps-discuss] Payment Protocols -- was Re: Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 09:26:04 -0000 At 00:35 10-04-2012, Hannes Tschofenig wrote: >The title "finance area mailing list" is probably the wrong term. >Instead, we are talking Yes. This is not the ideal venue for discussing about the creation of a new (IETF) area in my opinion. >I don't know how far these attempts are away from what Walter is >trying to accomplish. I believe the main disconnect is in the >understanding of how the process works in bringing work to the IETF >and the lack of agreed terminology and scope makes is easy to talk >past each other. Agreed. Although I do point people to the "Tao" and other process-related documents (see http://www.ietf.org/newcomers.html for a starter guide), it is not helpful to people trying to understand how the process works and to bring new work in the IETF. Please note that this should not be construed as an opinion about whether person X is a newcomer or not. >Once getting to the point of talking about the same topic there are >various other challenges, such as >* who are all the stakeholders that need to be involved? >* are these communities interested to bring their work to the IETF? The problem has turned into a catch 22. There is a view that having an IETF mailing list would allow communities interested in bringing their work to the IETF to discuss and build support. There is another view that by having such a mailing list, the IETF is "blessing" the work. A mailing list allows focused discussions by a group of people interested in working on, for example, protocol X. The absence of a mailing list does not hinder that. One could look at this in terms of discussions. If the volume of discussions is significant enough, it makes sense to move the discussion to a new mailing list if there isn't already one. >* why did various earlier attempts fail? Previous attempts have been about EDINT. That is not the same as the problem discussed recently. Regards, -sm From hannes.tschofenig@nsn.com Tue Apr 10 03:51: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 5953421F8746 for ; Tue, 10 Apr 2012 03:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.15 X-Spam-Level: X-Spam-Status: No, score=-105.15 tagged_above=-999 required=5 tests=[AWL=1.449, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiBhuNdiQ7hs for ; Tue, 10 Apr 2012 03:51:16 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8025B21F86C7 for ; Tue, 10 Apr 2012 03:51:16 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q3AApENs003464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Apr 2012 12:51:14 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q3AApBVj007347; Tue, 10 Apr 2012 12:51:14 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 12:50:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Apr 2012 13:50:30 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D014D637B@FIESEXC035.nsn-intra.net> In-Reply-To: <6.2.5.6.2.20120410004434.0b0b7920@resistor.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [apps-discuss] Payment Protocols -- was Re: Proposal for a Finance Area Mailing List Thread-Index: Ac0W+/C2N0WgmJABQ2CtFL/Wi+rBzQACuySA References: <4F5ADDCA.80303@KingsMountain.com><4F60968D.4020703@stpeter.im><3553! E9F7-3E65 -4143-BCF1-D 8529D1A7C84@gmx.net> <6.2.5.6.2.20120410004434.0b0b7920@resistor.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext SM" , "Hannes Tschofenig" , "Carsten Bormann" X-OriginalArrivalTime: 10 Apr 2012 10:50:31.0273 (UTC) FILETIME=[BFBE1D90:01CD1707] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2767 X-purgate-ID: 151667::1334055074-00003570-BD20F53B/0-0/0-0 Cc: Apps Discuss Subject: Re: [apps-discuss] Payment Protocols -- was Re: Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 10:51:17 -0000 Hi SM,=20 > At 00:35 10-04-2012, Hannes Tschofenig wrote: > >The title "finance area mailing list" is probably the wrong term. > >Instead, we are talking >=20 > Yes. >=20 > This is not the ideal venue for discussing about the creation of a > new (IETF) area in my opinion. I completely agree! That makes no sense.=20 >=20 > >I don't know how far these attempts are away from what Walter is > >trying to accomplish. I believe the main disconnect is in the > >understanding of how the process works in bringing work to the IETF > >and the lack of agreed terminology and scope makes is easy to talk > >past each other. >=20 > Agreed. >=20 > Although I do point people to the "Tao" and other process-related > documents (see http://www.ietf.org/newcomers.html for a starter > guide), it is not helpful to people trying to understand how the > process works and to bring new work in the IETF. Please note that > this should not be construed as an opinion about whether person X is > a newcomer or not. Makes sense.=20 >=20 > >Once getting to the point of talking about the same topic there are > >various other challenges, such as > >* who are all the stakeholders that need to be involved? > >* are these communities interested to bring their work to the IETF? >=20 > The problem has turned into a catch 22. There is a view that having > an IETF mailing list would allow communities interested in bringing > their work to the IETF to discuss and build support. There is > another view that by having such a mailing list, the IETF is > "blessing" the work. Yes, a challenging situation.=20 >=20 > A mailing list allows focused discussions by a group of people > interested in working on, for example, protocol X. The absence of a > mailing list does not hinder that. One could look at this in terms > of discussions. If the volume of discussions is significant enough, > it makes sense to move the discussion to a new mailing list if there > isn't already one. I agree with you.=20 >=20 > >* why did various earlier attempts fail? >=20 > Previous attempts have been about EDINT. That is not the same as the > problem discussed recently. I have not been involved in that specific effort. Cannot comment.=20 >From a protocol point of view the topic seems pretty easy. Hence, the problems must be somewhere else. I believe I know why the Internet Open Trading Protocol failed. More focused attempts on the other hand have been quite successful, for example, Diameter Credit Control. Ciao Hannes >=20 > Regards, > -sm >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From alexey.melnikov@isode.com Tue Apr 10 04:34: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 BAAF021F854A for ; Tue, 10 Apr 2012 04:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.577 X-Spam-Level: X-Spam-Status: No, score=-101.577 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0OnYMLJhdVE for ; Tue, 10 Apr 2012 04:34:21 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id B46B421F850D for ; Tue, 10 Apr 2012 04:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334057536; d=isode.com; s=selector; i=@isode.com; bh=T0etWOuayiPw40FbpkJuMx8Kmw3PiR2hC5/EwBRpYx0=; 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=JqpyiP8XJ9qcVdFaaRz6vqwWEk/Q5zE62OY9X3OjvjIpQVE5QyYlhdUa/GJ0OBah4w4+zu tqZRCmFffVUiQV2o5+4Vs3gwPeQnl6Eptf9a8g1csHdmdRhMm43GoeKAiFOrIAeyhdIGM4 jslCZBRh1R6VHicn8U5NGV3gMLemiVA=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 10 Apr 2012 12:32:16 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F831AF1.7000302@isode.com> Date: Mon, 09 Apr 2012 18:22:57 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "apps-discuss@ietf.org" References: <9452079D1A51524AA5749AD23E0039280C4828@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C4828@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040807020202020807030306" Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:34:24 -0000 This is a multi-part message in MIME format. --------------040807020202020807030306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/04/2012 06:08, Murray S. Kucherawy wrote: > > This message serves as the beginning of Working Group Last Call on > draft-ietf-appsawg-media-type-regs, to end on Friday, April 13^th . > Please review the document and provide any feedback to the authors > directly or to apps-discuss@ietf.org . > > The datatracker page for the document: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/ > > This is a very well written document, which includes lots of useful improvements over the previous RFC. I think there is a small list of issues (mostly nits or clarity issues) that need addressing before IESG sees it. 3.2. Vendor Tree A registration may be placed in the vendor tree by anyone who needs to interchange files associated with some product or set of products. However, the registration properly belongs to the vendor or organization producing the software that employs the type being registered, and that vendor or organization can at any time elect to assert ownership of the registration. Can you expand a bit on what "assert ownership" means? Does this only apply to third party registrations? What are the practical implications? For example, can the vendor/organization request removal of the registration (I hope the answer to this question is "no".) 4.2. Naming Requirements Type and subtype names MUST conform to the following ABNF: type-name = restricted-name subtype-name = restricted-name restricted-name = 1*127restricted-name-chars restricted-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "." / "+" / "-" / "^" / "_" Ok, this might be silly, but I thought I should ask: can a subtype-name (or type-name) start with a dot? 4.2.1. Text Media Types A "charset" parameter SHOULD NOT be specified when charset information is transported inside the payload (e.g., as in "text/ xml"). As you are already referencing [I-D.ietf-appsawg-mime-default-charset] Normatively, it would be good to make it clear that this document is merely repeating requirements from [I-D.ietf-appsawg-mime-default-charset]. (The same applies to the next paragraph, but there it is clearer.) If a "charset" parameter is specified, it SHOULD be a required parameter, eliminating the options of specifying a default value. If there is a strong reason for the parameter to be optional despite this advice, each subtype MAY specify its own default value, or alternately, it MAY specify that there is no default value. Finally, the "UTF-8" charset [RFC3629] SHOULD be selected as the default. See [I-D.ietf-appsawg-mime-default-charset] for additional information on the use of "charset" parameters in conjunction with subtypes of text. 4.4. Canonicalization and Format Requirements As such, teferences to typo: references or inclusion of format specifications in registrations is encouraged but not required. Note, however, that the public availability of a meaningful specification will often make the difference between simply having a name reserved so that there are no conflicts with other uses and having the potential for other implementations of the media type and useful interoperation with them. 5.2.1. Provisional Registrations Accordingly, a provisonal registration process is provided to support early assigment of media type names. A provisional registration MAY be submitted to IANA for standards tree types. The only required fields in such registrations are the media type name and contact information (inckuding the standards body name). typo: including Provisional registrations MAY be updated or abandoned at any time. I am a bit concerned about "abandoned". It is true that the standardization of a media type might not complete. But if the media type ends up being deployed in any form, wouldn't it be better to mark it as OBSOLETE or something like this instead? I.e. I would prefer for entries not being deleted from the registry. 5.6. Change Procedures Once a media type has been published by the IANA, the owner may request a change to its definition. The descriptions of the different registration trees above designate the "owners" of each type of registration. The same procedure that would be appropriate for the original registration request is used to process a change request. I don't remember seeing IETF (or IESG) being the owner of all Standards Tree registration. Did I miss it? 6. Structured Syntax Suffix Registration Procedures 3. Send a copy of the template or a pointer to the containing document (with specific reference to the section with the template) to the mailing list ietf-types@ietf.org, I've noticed that everywhere else in the document you are using ietf-types@iana.org. Although at the moment both mailing lists are going to the same place, there is no guaranty that that would be true in the future. So I suggest you be consistent everywhere. 10.1. Normative References [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. I think this reference is actually Informative. In Appendix A: it might be worth pointing out that submission to ietf-types@iana.org for review is not an absolute requirement anymore. --------------040807020202020807030306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 02/04/2012 06:08, Murray S. Kucherawy wrote:

This message serves as the beginning of Working Group Last Call on draft-ietf-appsawg-media-type-regs, to end on Friday, April 13th.  Please review the document and provide any feedback to the authors directly or to apps-discuss@ietf.org.

 

The datatracker page for the document: https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/

 

This is a very well written document, which includes lots of useful improvements over the previous RFC.
I think there is a small list of issues (mostly nits or clarity issues) that need addressing before IESG sees it.

3.2.  Vendor Tree

   A registration may be placed in the vendor tree by anyone who needs
   to interchange files associated with some product or set of products.
   However, the registration properly belongs to the vendor or
   organization producing the software that employs the type being
   registered, and that vendor or organization can at any time elect to
   assert ownership of the registration.

Can you expand a bit on what "assert ownership" means? Does this only apply
to third party registrations? What are the practical implications?
For example, can the vendor/organization request removal of the registration
(I hope the answer to this question is "no".)

4.2.  Naming Requirements

   Type and subtype names MUST conform to the following ABNF:

       type-name = restricted-name
       subtype-name = restricted-name

       restricted-name = 1*127restricted-name-chars
       restricted-name-chars = ALPHA / DIGIT / "!" /
                               "#" / "$" / "&" / "." /
                               "+" / "-" / "^" / "_"

Ok, this might be silly, but I thought I should ask: can a subtype-name
(or type-name) start with a dot?

4.2.1.  Text Media Types

   A "charset" parameter SHOULD NOT be specified when charset
   information is transported inside the payload (e.g., as in "text/
   xml").

As you are already referencing [I-D.ietf-appsawg-mime-default-charset]
Normatively, it would be good to make it clear that this document is merely
repeating requirements from [I-D.ietf-appsawg-mime-default-charset].
(The same applies to the next paragraph, but there it is clearer.)

   If a "charset" parameter is specified, it SHOULD be a required
   parameter, eliminating the options of specifying a default value.  If
   there is a strong reason for the parameter to be optional despite
   this advice, each subtype MAY specify its own default value, or
   alternately, it MAY specify that there is no default value.  Finally,
   the "UTF-8" charset [RFC3629] SHOULD be selected as the default.  See
   [I-D.ietf-appsawg-mime-default-charset] for additional information on
   the use of "charset" parameters in conjunction with subtypes of text.


4.4.  Canonicalization and Format Requirements

   As such, teferences to

typo: references

   or inclusion of format specifications in registrations is encouraged
   but not required.  Note, however, that the public availability of a
   meaningful specification will often make the difference between
   simply having a name reserved so that there are no conflicts with
   other uses and having the potential for other implementations of the
   media type and useful interoperation with them.


5.2.1.  Provisional Registrations

   Accordingly, a provisonal registration process is provided to support
   early assigment of media type names.  A provisional registration MAY
   be submitted to IANA for standards tree types.  The only required
   fields in such registrations are the media type name and contact
   information (inckuding the standards body name).

typo: including

   Provisional registrations MAY be updated or abandoned at any time.

I am a bit concerned about "abandoned". It is true that the standardization
of a media type might not complete. But if the media type ends up being
deployed in any form, wouldn't it be better to mark it as OBSOLETE or
something like this instead? I.e. I would prefer for entries not being deleted
from the registry.

5.6.  Change Procedures

   Once a media type has been published by the IANA, the owner may
   request a change to its definition.  The descriptions of the
   different registration trees above designate the "owners" of each
   type of registration.  The same procedure that would be appropriate
   for the original registration request is used to process a change
   request.

I don't remember seeing IETF (or IESG) being the owner of all Standards Tree
registration. Did I miss it?

6.  Structured Syntax Suffix Registration Procedures

   3.  Send a copy of the template or a pointer to the containing
       document (with specific reference to the section with the
       template) to the mailing list ietf-types@ietf.org,

I've noticed that everywhere else in the document you are using
ietf-types@iana.org. Although at the moment both mailing lists are going
to the same place, there is no guaranty that that would be true in the future.
So I suggest you be consistent everywhere.


10.1.  Normative References

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

I think this reference is actually Informative.


In Appendix A: it might be worth pointing out that submission to
ietf-types@iana.org for review is not an absolute requirement anymore.

--------------040807020202020807030306-- From alexey.melnikov@isode.com Tue Apr 10 04:34: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 B844121F850D for ; Tue, 10 Apr 2012 04:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.077 X-Spam-Level: X-Spam-Status: No, score=-102.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vl0CCcXSJNrG for ; Tue, 10 Apr 2012 04:34:24 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 77F5921F853B for ; Tue, 10 Apr 2012 04:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334057547; d=isode.com; s=selector; i=@isode.com; bh=RKLZb5Z9bW7LXiLbyYPij8fYqHr+bnXoyw94Ay77vmg=; 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=R1xuUHah7Vv999OT5vSevB59+ENiK7scCC/0VOtkXCHb41LkgccPi5F+8MkM2dYFRztm5X /dR/nqlD611hOQjEiz83A71Pi+0aiOPxQwYXw/Juv0PVq9DrWak5JV4OlAh11HyjDrX/7p C2uSn27nlEOK7jchpa90vjyjMcJbDME=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 10 Apr 2012 12:32:26 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F841156.6030908@isode.com> Date: Tue, 10 Apr 2012 11:54:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: John Levine MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] Review of draft-levine-application-gzip-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:34:24 -0000 Hi John, I am sorry I've missed this document earlier. I am generally happy that you wrote this draft and support its publication. Having said that, I think it needs some changes: In Section 1: Some applications have informally used the media type application/ x-gzip. The media types defined in this document should replace that media type in future applications. Also I've seen application/x-gzip-compressed being mentioned on the web. But I think it would be better to wait for draft-ietf-appsawg-media-type-regs-04 to be submitted to IESG (it is in the APPSAWG WGLC now). That document would relax restrictions on registering x-* media types. I think your document should register media types already in use, as changing existing implementations to use application/gzip is hopeless at this point, unless there is some evidence that application/gzip is also in use. In the latter case aliasing mechanism proposed in draft-ietf-appsawg-media-type-regs should be used. 3.1. Regsistration Details Person and email address to contact for further information: see http://www.gzip.net/ I've just tried this URI and I am getting "this domain is for sale". It doesn't look like this is a good stable reference. 5. References This Section should be named "Normative References". Nit: spot typos in names of Sections 2.1 and 3.1. From alexey.melnikov@isode.com Tue Apr 10 05:55: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 42C3D21F85DB for ; Tue, 10 Apr 2012 05:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.219 X-Spam-Level: X-Spam-Status: No, score=-102.219 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIttbMDySY7Y for ; Tue, 10 Apr 2012 05:55:51 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 14D6521F85D5 for ; Tue, 10 Apr 2012 05:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334062549; d=isode.com; s=selector; i=@isode.com; bh=OEWIzuwxsmLtFk+oRH206iCs14xoTNxctqmFDFICXGE=; 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=nF9p69sSUD1jkJJV+nku5UKVBuc8ak8oOR07AgUGTJty/LSff/94N+ddQouoynQZwPyh+j GzEdXrw+6btPsKQewgEmBiKMw30k2y22VBtSs8LvPrL/+/tL+06uD6P+JPfCgSJx/3yfP6 2X/cvSOlmWKFaVTT9LK2NW8q9ghGKOc=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 10 Apr 2012 13:55:49 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F842DFB.2060709@isode.com> Date: Tue, 10 Apr 2012 13:56:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "apps-discuss@ietf.org" , draft-ietf-conex-concepts-uses.all@tools.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020703080700020904000007" Subject: [apps-discuss] AppsDir review of draft-ietf-conex-concepts-uses-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: Tue, 10 Apr 2012 12:55:52 -0000 This is a multi-part message in MIME format. --------------020703080700020904000007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-conex-concepts-uses-04.txt Title: ConEx Concepts and Use Cases Reviewer: Alexey Melnikov Review Date: 10 April 2012 IETF Last Call Date: 12 April 2012 IESG Telechat Date: 12 April 2012 Review Summary: This draft is ready for publication as an Informational RFC. Document Summary: This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. I've already reviewed this document as a Gen-Art reviewer and have no new issues to report. I don't think the document has Apps Area issues. --------------020703080700020904000007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

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-conex-concepts-uses-04.txt

Title: ConEx Concepts and Use Cases

Reviewer: Alexey Melnikov

Review Date: 10 April 2012

IETF Last Call Date: 12 April 2012

IESG Telechat Date: 12 April 2012

 

Review Summary:  This draft is ready for publication as an Informational RFC.

 

Document Summary:  This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today.


I've already reviewed this document as a Gen-Art reviewer and have no new issues to report. I don't think the document has Apps Area issues.

--------------020703080700020904000007-- From alexey.melnikov@isode.com Tue Apr 10 06:18: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 CE7C221F860D for ; Tue, 10 Apr 2012 06:18:08 -0700 (PDT) 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.298, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piaL-um3UZyb for ; Tue, 10 Apr 2012 06:18:08 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id DA2E021F8606 for ; Tue, 10 Apr 2012 06:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334063886; d=isode.com; s=selector; i=@isode.com; bh=ZwcsBolAUqw+PIP8e0x/7ZOicBJr1rMjzdNV3DvEit8=; 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=TlRKpDudhz1OdEn+p4e6cLIwmB8bpUD3RPzbExfF9DxWOd23iSOuFFWx/xugd+aWDTQ8z7 It+q7QA4+blqQlk8vny9SRwzqDrVfjgoy98fWC09ciF2FKHW7CRwV7n9MZ0qEkLFKKg0sB xpbLcv7NykovKTPp3oNyh6kDsEbRkhM=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 10 Apr 2012 14:18:06 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F843332.7060705@isode.com> Date: Tue, 10 Apr 2012 14:18:42 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Ned Freed References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> <01OE2UNN2HJ000ZUIL@mauve.mrochek.com> <4F82B5F6.3050806@gmx.de> <01OE3UQGECV600ZUIL@mauve.mrochek.com> In-Reply-To: <01OE3UQGECV600ZUIL@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 13:18:08 -0000 On 09/04/2012 15:28, Ned Freed wrote: >> On 2012-04-08 23:08, Ned Freed wrote: >> >> This message starts Working Group Last Call for >> draft-ietf-appsawg-mime-default-charset. Please review the document >> and provide comments to the list, the co-chairs, or the authors by >> Friday, April 20th. >> > >> >> The datatracker link is >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/. >> > >> >> -MSK, APPSAWG co-chair >> > >> > I just reviewed this document and it's looking good to me. >> > >> > You'll probably want to remove the anchor2 bit at the end of the WGLC. >> Of course. >> I'm also not totally convinced that HTTPbis actually needs to reference >> this document at all; any opinions on this? > > Really ard to say without knowing how they deal with the iso-8859-1. I > can see > it being done in a way that doesn't need a reference. Or it could be > done in a > way where a reference would be helpful. > > Not sure I see any need for a normative reference though. (I've mentioned my opinion to Julian, but I would like to state it for the record.) I think an update to RFC 2616 should have a reference to draft-ietf-appsawg-mime-default-charset and make it clear that the previous default was removed. An Informative reference to draft-ietf-appsawg-mime-default-charset should be fine. From john.levine@gmail.com Tue Apr 10 06:24: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 99C0521F85D0 for ; Tue, 10 Apr 2012 06:24:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFHvWSqFlzq7 for ; Tue, 10 Apr 2012 06:24:01 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF1321F85B4 for ; Tue, 10 Apr 2012 06:24:01 -0700 (PDT) Received: by yenm5 with SMTP id m5so2559087yen.31 for ; Tue, 10 Apr 2012 06:24:01 -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=hMwxwaE6+i3fqxws+rri2pZ5GcWkV4nlgQpC3QXk4kI=; b=iZ14EoeZJkGIPm5Iarxvj7/wdEpFKqW7XTU4dzBWX2eRhWV1WLnleOUypBEZm678et paRlz8z7WCWXSoA24+jnmTQP6YF/N9Y5IJGobDh87sN0ZXOgR0U3x6mdRnEGXgiCdXRj AMUKzvP/aiDOPTuGyqQgpIMlrKkAi54kkjsvHUDe9zDUhcmoMXrkRMU1aWBXwspdh1CF 6qFtWJc7vyAB0ta6lfKs+UlafjPGCK7qOs4gpdnM0BhxcGdnlQacWoBZyQbcPPcEq69w T4SPkEH8StTNweucWWJvtZkKurZsL20LbVyEn/zQ+FP+DHPelbtmDed2fM1U7wRf1+B1 cqkA== MIME-Version: 1.0 Received: by 10.60.27.38 with SMTP id q6mr16657463oeg.20.1334064241044; Tue, 10 Apr 2012 06:24:01 -0700 (PDT) Sender: john.levine@gmail.com Received: by 10.182.20.3 with HTTP; Tue, 10 Apr 2012 06:24:00 -0700 (PDT) In-Reply-To: <4F841156.6030908@isode.com> References: <4F841156.6030908@isode.com> Date: Tue, 10 Apr 2012 13:24:00 +0000 X-Google-Sender-Auth: qpryf5LxlW4EA5ekbb477sDjcIs Message-ID: From: John Levine To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Cc: John Levine , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [taugh.com-standards] Review of draft-levine-application-gzip-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:25:49 -0000 I don't feel strongly about gzip vs. x-gzip but I also don't think there is much x-gzip now. There is a good chance that DMARC will use whichever it defines. Will look for a better ref than gzip.net although the real refs are the RFCs of course. r's from my Kindle John On 4/10/12, Alexey Melnikov wrote: > Hi John, > I am sorry I've missed this document earlier. > > I am generally happy that you wrote this draft and support its > publication. Having said that, I think it needs some changes: > > In Section 1: > > Some applications have informally used the media type application/ > x-gzip. The media types defined in this document should replace that > media type in future applications. > > Also I've seen application/x-gzip-compressed being mentioned on the web. > > But I think it would be better to wait for > draft-ietf-appsawg-media-type-regs-04 to be submitted to IESG (it is in > the APPSAWG WGLC now). That document would relax restrictions on > registering x-* media types. I think your document should register media > types already in use, as changing existing implementations to use > application/gzip is hopeless at this point, unless there is some > evidence that application/gzip is also in use. In the latter case > aliasing mechanism proposed in draft-ietf-appsawg-media-type-regs should > be used. > > 3.1. Regsistration Details > > Person and email address to contact for further information: see > http://www.gzip.net/ > > I've just tried this URI and I am getting "this domain is for sale". It > doesn't look like this is a good stable reference. > > 5. References > > This Section should be named "Normative References". > > Nit: spot typos in names of Sections 2.1 and 3.1. > > From julian.reschke@gmx.de Tue Apr 10 06:38: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 74FDA21F8595 for ; Tue, 10 Apr 2012 06:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=-3.935, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1R1CcRaQdEk for ; Tue, 10 Apr 2012 06:38:49 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8C26B21F8582 for ; Tue, 10 Apr 2012 06:38:48 -0700 (PDT) Received: (qmail invoked by alias); 10 Apr 2012 13:38:47 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp037) with SMTP; 10 Apr 2012 15:38:47 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19YlON/MlJYxCZRW0sdJgr1ickRD8a9Gf4bWhf7Ow +Y4nCtl6+XpkWN Message-ID: <4F8437E7.1070501@gmx.de> Date: Tue, 10 Apr 2012 15:38:47 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> <01OE2UNN2HJ000ZUIL@mauve.mrochek.com> <4F82B5F6.3050806@gmx.de> <01OE3UQGECV600ZUIL@mauve.mrochek.com> <4F843332.7060705@isode.com> In-Reply-To: <4F843332.7060705@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 13:38:49 -0000 On 2012-04-10 15:18, Alexey Melnikov wrote: > ... >> Not sure I see any need for a normative reference though. > > (I've mentioned my opinion to Julian, but I would like to state it for > the record.) > I think an update to RFC 2616 should have a reference to > draft-ietf-appsawg-mime-default-charset and make it clear that the > previous default was removed. An Informative reference to > draft-ietf-appsawg-mime-default-charset should be fine. HTTPbis *does* make it clear that the default (overriding the base spec) was removed. What's not clear to me is why it would need to reference draft-ietf-appsawg-mime-default-charset. Best regards, Julian From julian.reschke@gmx.de Tue Apr 10 06:42: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 31E6021F8598 for ; Tue, 10 Apr 2012 06:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.567 X-Spam-Level: X-Spam-Status: No, score=-104.567 tagged_above=-999 required=5 tests=[AWL=-1.967, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oG8fO30Nfx8A for ; Tue, 10 Apr 2012 06:42:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D517721F8585 for ; Tue, 10 Apr 2012 06:42:34 -0700 (PDT) Received: (qmail invoked by alias); 10 Apr 2012 13:42:33 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp070) with SMTP; 10 Apr 2012 15:42:33 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19Yy/EQ/OlYM+JbDdH6p42lnBxeLWKN337ay5j2cR gF4rU5a4jJIRsH Message-ID: <4F8438C8.2070506@gmx.de> Date: Tue, 10 Apr 2012 15:42:32 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ned Freed References: <20120330125228.15497.35035.idtracker@ietfa.amsl.com> <1271382236.20120330141948@pobox.com> <01ODS3YTKX1400ZUIL@mauve.mrochek.com> In-Reply-To: <01ODS3YTKX1400ZUIL@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps-Discusssion , Bill McQuillan Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:42:36 -0000 On 2012-04-01 06:44, Ned Freed wrote: > >> RFC 2397 defaults media type of "data:" URIs to text/plain;charset=US-ASCII. > >> Should this be updated to default to utf8? > > I'm not entirely sure of all the ramifications, but they are minimal this > sound like a really good idea to me. There is one (IMHO) important erratum for 2397, and also it should be updated to be based on RFC 3986. With respect to the encoding default, it would make sense to check what current implementations do; if they indeed agree on UTF-8, it might make sense to make that modification. (Does anybody happen to have a test case?) I volunteer to work on a 2397bis if Larry is ok with this. Best regards, Julian From ned.freed@mrochek.com Tue Apr 10 07:27: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 87B0F11E80BE for ; Tue, 10 Apr 2012 07:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sx5LLtLEVWwN for ; Tue, 10 Apr 2012 07:27:49 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 160F711E80B8 for ; Tue, 10 Apr 2012 07:27:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE58YH0ZGW008JZU@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 10 Apr 2012 07:27:44 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Tue, 10 Apr 2012 07:27:39 -0700 (PDT) Message-id: <01OE58YDHRAA00ZUIL@mauve.mrochek.com> Date: Tue, 10 Apr 2012 07:26:47 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 10 Apr 2012 10:25:35 +0200" <4F83EE7F.3070707@gmx.de> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> <01OE2UNN2HJ000ZUIL@mauve.mrochek.com> <4F82B5F6.3050806@gmx.de> <01OE3UQGECV600ZUIL@mauve.mrochek.com> <4F83EE7F.3070707@gmx.de> To: Julian Reschke Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 14:27:49 -0000 > On 2012-04-09 16:28, Ned Freed wrote: > > ... > >> I'm also not totally convinced that HTTPbis actually needs to reference > >> this document at all; any opinions on this? > > > > Really ard to say without knowing how they deal with the iso-8859-1. I > > can see > > it being done in a way that doesn't need a reference. Or it could be > > done in a > > way where a reference would be helpful. > HTTPbis simply has stopped having a custom rule; it just delegates to > the applicable MIME specs. -> > Well, the change certainly needs to be noted as a change somewhere, don't you think? Otherwise people could easily assume that the rule is in there (and there's a lot of "there") somewhere. Ned From julian.reschke@gmx.de Tue Apr 10 07:33: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 C562621F8582 for ; Tue, 10 Apr 2012 07:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.911 X-Spam-Level: X-Spam-Status: No, score=-103.911 tagged_above=-999 required=5 tests=[AWL=-1.312, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+EEHTrH8DYh for ; Tue, 10 Apr 2012 07:33:46 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A212921F8670 for ; Tue, 10 Apr 2012 07:33:45 -0700 (PDT) Received: (qmail invoked by alias); 10 Apr 2012 14:33:44 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp012) with SMTP; 10 Apr 2012 16:33:44 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+zM2QvR6mzl8hdOiVS/8A7dwiUht7GeoT4XXltxz zZEqlMC4eKCEP7 Message-ID: <4F8444C8.2030709@gmx.de> Date: Tue, 10 Apr 2012 16:33:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ned Freed References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> <01OE2UNN2HJ000ZUIL@mauve.mrochek.com> <4F82B5F6.3050806@gmx.de> <01OE3UQGECV600ZUIL@mauve.mrochek.com> <4F83EE7F.3070707@gmx.de> <01OE58YDHRAA00ZUIL@mauve.mrochek.com> In-Reply-To: <01OE58YDHRAA00ZUIL@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 14:33:46 -0000 On 2012-04-10 16:26, Ned Freed wrote: >> On 2012-04-09 16:28, Ned Freed wrote: >> > ... >> >> I'm also not totally convinced that HTTPbis actually needs to >> reference >> >> this document at all; any opinions on this? >> > >> > Really ard to say without knowing how they deal with the iso-8859-1. I >> > can see >> > it being done in a way that doesn't need a reference. Or it could be >> > done in a >> > way where a reference would be helpful. > >> HTTPbis simply has stopped having a custom rule; it just delegates to >> the applicable MIME specs. -> >> > > Well, the change certainly needs to be noted as a change somewhere, don't > you think? Otherwise people could easily assume that the rule is in there > (and there's a lot of "there") somewhere. Best regards, Julian From mnot@mnot.net Tue Apr 10 08: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 892D211E80BE for ; Tue, 10 Apr 2012 08:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.028 X-Spam-Level: X-Spam-Status: No, score=-106.028 tagged_above=-999 required=5 tests=[AWL=-3.429, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlBmop30BLf9 for ; Tue, 10 Apr 2012 08:56:26 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id CD59511E8122 for ; Tue, 10 Apr 2012 08:56:26 -0700 (PDT) Received: from [10.6.129.255] (unknown [50.56.228.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2C4DE22E256; Tue, 10 Apr 2012 11:56:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4F7F416C.3050400@berkeley.edu> Date: Tue, 10 Apr 2012 10:56:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> To: Erik Wilde X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org application-layer protocols" , REST Discuss Subject: Re: [apps-discuss] Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 15:56:27 -0000 On 06/04/2012, at 2:18 PM, Erik Wilde wrote: >> That's a good design, because link relations are already a defined = mechanism to talk about resource behaviours; having two such mechanisms = isn't a good idea (at least without some discussion). >> E.g., when I interact with a resource, I know it supports particular = behaviours, because it's been linked to with relation "Foo." When I get = a representation from the "Foo" resource, it will have a media type that = describes the format, and also a profile ("Bar") that describes = additional features / conventions of that document (such as a particular = use of JSON or XML), but that profile won't -- and shouldn't! -- be an = additional way of describing the behaviours of the "Foo" resource. >=20 > now i am little bit confused. taking your example, i am not concerned = with the link relation that was used to discover 'foo' at all. all i am = concerned with is that if i am retrieving 'foo' and i find a 'bar' = profile identifier in the representation, i know that it follows = constraints and conventions beyond the 'foo' media type. Yup. > one example i am currently considering adding is atompub. currently, = when you retrieve a feed, there's no way to tell it's atompub-capable = just by looking at it. Well, what thing in this case is atom pub capable? The format that the = links are occurring within, or the targets of the links themselves? I'd = argue the latter. You can take that argument too far, of course, but = generally I see profiles as describing format conventions, and link = relations as describing behaviours of resources. Of course, some of = those behaviours can be "produce this format" and some of the formatting = conventions can be "link to something with this behaviour". Am happy to be proven wrong on this, I just think we need good patterns = of use / best practices to encourage reasonable design. Make sense? -- Mark Nottingham http://www.mnot.net/ From sm@elandsys.com Tue Apr 10 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 B477611E8147 for ; Tue, 10 Apr 2012 12:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a2ffwpqZxce for ; Tue, 10 Apr 2012 12:52:00 -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 50A4911E8144 for ; Tue, 10 Apr 2012 12:52:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.8]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3AJpkrF000951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 12:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334087519; i=@elandsys.com; bh=zFgpvkGEMaaEYWwC0gk3Gp38idhJMvhr5IjG2JZorEw=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=4EHXZLRQIiZpGJmu6radKbPZp7lTX+gWChaxfx1g6anMRE+DQN/ROmPuiUAmYAKKN 9zZ1bcHqRBvjOHY1GVRotIjH4BynwjoIacNZ4AGfjR4fue6lWoBWJ5eTg+EF8mORXN lwNiWP59pAOtE+yIZFtNGX53G4i0uHbpk5aW/GuE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334087519; i=@elandsys.com; bh=zFgpvkGEMaaEYWwC0gk3Gp38idhJMvhr5IjG2JZorEw=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=v//1I6QEod90LzIeat2BbljrGf246QzbLHu/I+W92ftAi2jXID+MeVNvk6BvCC1eR cLVXJmPdOqovZ0wY2Gs+4+3xFOJ4wG1NrMY2Gh5mkQ28sUg8xdz7qSEL6S5cAek0l8 tDszRQ+/kY357oKa5iUNjh1X/4HL9pc5ot/CtKKg= Message-Id: <6.2.5.6.2.20120410113236.0ad78c48@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Apr 2012 12:50:25 -0700 To: apps-discuss@ietf.org, draft-ietf-conex-concepts-uses.all@tools.ietf.org From: S Moonesamy In-Reply-To: <4F842DFB.2060709@isode.com> References: <4F842DFB.2060709@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] AppsDir review of draft-ietf-conex-concepts-uses-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: Tue, 10 Apr 2012 19:52:03 -0000 I read draft-ietf-conex-concepts-uses-04. Here are some quick comments. As well-known application protocols such as FTP, SMTP and HTTP run over TCP, ConEx deployments shouldn't have a negative impact on them. As a stylistic nit, the definitions in Section 2.4 could have been before Section 2.2 and 2.3. "Network operators (or providers): Operator of a residential, commercial, enterprise, campus or other network. User: The contractual entity that represents an individual, household, business, or institution that uses the service of a network operator. There is no implication that the contract has to be commercial; for instance, the users of a university or enterprise network service could be students or employees who do not pay for access but may be required to comply with some form of contract or acceptable use policy. There is also no implication that every user is an end user. Where two networks form a customer-provider relationship, the term user applies to the customer network." The above from Section 2.4 defines providers and users. According to the definition of User, a provider can also be a User. It would have been easier not to get into a definition of provider (network operator) and user to keep the picture simple. In Section 3.3: "They may even penalize users of applications that employ scavenger services for the large amount of volume they send, rather than rewarding them for carefully avoiding congestion while sending it." What are "scavenger services"? "While the volume-based approach described in Comcast's Protocol- Agnostic Congestion Management System [RFC6057] aims to overcome the over/under-constraining problem by only measuring volume and triggering traffic management action during periods of high utilization, it still does not provide incentives to use scavenger transports because congestion-causing volume cannot be distinguished from volume overall." What are "scavenger transports"? "These approaches suffer from being at odds with IPSec and some application-layer encryption, and they may raise additional policy concerns." If I am not mistaken, that should be "IPsec". In Section 5.5: "Not-ConEx packets bring no such information. Therefore the network will tend to rate-limit not-ConEx packets conservatively in order to manage the unknown risk of congestion." Another way to look at this is: Therefore the network will tend to rate-limit non-TCP packets conservatively in order to manage the unknown risk of congestion. Editorial nit: "On the host side, we have already shown (Figure Figure 1)" Regards, S. Moonesamy From sm@elandsys.com Tue Apr 10 15:06: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 C460511E813A for ; Tue, 10 Apr 2012 15:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPxeqf1BzJO6 for ; Tue, 10 Apr 2012 15:06:11 -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 DF13F11E812C for ; Tue, 10 Apr 2012 15:06:10 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.8]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3AM5trp017854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 15:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334095568; i=@elandsys.com; bh=28+V5rDsspWAvUYCZoorrhyjMTxhNj8yUit/36dsDxU=; h=Date:To:From:Subject:Cc; b=QAM5fIc/RtPy9r1aREQJM07JPFIqvOnj4CZ2MfeY2u9Lyj3+QUwepgBQRINnx8sUg 4NSK4QatumphjkWPWtrn+RWqUf8sN80Wb0TZ9bv8ZZxllLfCw6VTg0acZsoONd/8uW yeUQGN0M+i8H+gyqnEyDqN3/fwNmr104VyMQKu9U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334095568; i=@elandsys.com; bh=28+V5rDsspWAvUYCZoorrhyjMTxhNj8yUit/36dsDxU=; h=Date:To:From:Subject:Cc; b=Pg+kvhw2KRmxxxYveM/U8Mx4vuwGS2bTIELu/hCWrNXhFfP61kKgY9ke0o2sQjA6H 6BTNB98SlZ6UZOZ9Fv1B0cClqyfZoff/8cwGn+MypkiBq+GeYeceB9NDudXddZCfy+ Qa2qmMZ6LqIP3gWxxg2Slhi4kJ6kdp9H+oYudpIs= Message-Id: <6.2.5.6.2.20120410125815.08d5c788@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Apr 2012 14:58:13 -0700 To: Eliot Lear From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: [apps-discuss] Review of draft-lear-lisp-nerd-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 22:06:15 -0000 Hi Eliot, draft-lear-lisp-nerd-08 presents an experimental database and a discussion of methods to transport the mapping of EIDs to RLOCs to routers in a reliable, scalable, and secure manner. It does not conflict with any work currently being done in the Applications Area. Given that it is an Independent Submission, these comments are optional. Overall, the draft was an interesting read. I don't the LISP background to perform an adequate review. I skipped the lengthy References section due to lack of time. In Section 2: "Operational functions are split into two components: database updates and state exchange between ITR and ETR during a communication." I suggest expanding ITR and ETR on first use. In Section 2.1: "A NERD is generated by an authority that allocates provider independent (PI) addresses (e.g., IANA or an RIR) which are used by sites as EIDs." According to draft-ietf-lisp-06 (Section 3), PI addresses are assigned. In Section 2.3: "Each region runs a database authority. In this case, provider independent address space is allocated to either Regional Internet Registries (RIRs) or to affiliates of such organizations of network operations guilds (NOGs)." I am at a loss here. The draft is talking about PI addresses for a region. Such assignments are generally through RIRs and NIRs and not through NOGs. Shouldn't the paragraph be discussing about registration of entries on a regional basis without resorting to an apex (see previous paragraph).? In Section 3: "The database name is an ASCII-encoded domain name, as specified in [RFC5321]" Where is that specified in RFC 5321? "This is the name that will appear in the Subject field of the certificate used to verify the database." I suggest taking a look at RFC 6125, specifically Section 2.3. In Section 4.2: "This begs the question: how does a router know to retrieve version 1105450 in our example above? It cannot. A redirect must be given by the server to that URI when the router attempts to retrieve differences from the current version, say, 1105503." I understand what you mean. Some readers might consider the above as underspecified. In Section 5.4.1: "One possible method of doing this is provided in [RFC4108]" Section 3 mentions that Cryptographic Message Syntax was not used as it is not widely deployed. Doesn't RFC 4108 require CMS? In Section 7: "Good old NNTP [RFC0977] itself provides two separate mechanisms (one push and another pull) to provide a coherent update process." RFC 3977 obsoletes RFC 977. In Section 7.1: "While the administrative lines may appear to be correct, the location of name servers may not be. If name servers sit within PI address space, thus requiring LISP to reach, a circular dependency is created." Wouldn't the service used to resolve the domain names, e.g. for HTTP, also sit within PI address space? The problem (discussed in Section 8.1) would also apply to any protocol that relies on DNS. The little gem in the draft is 'The format of the AFI is specified by IANA as "Address Family Numbers"'. Regards, S. Moonesamy From sm@elandsys.com Tue Apr 10 16: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 2E9D221F8652; Tue, 10 Apr 2012 16:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xIUGB1SpzkG; Tue, 10 Apr 2012 16:24:31 -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 1407721F8650; Tue, 10 Apr 2012 16:24:31 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.8]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3ANOHxA020579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 16:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334100270; i=@elandsys.com; bh=/LZu0MXIwDkl7dt2NG7/Px7Jz3Rssw7APmfhIKzeX3g=; h=Date:To:From:Subject:Cc; b=p0TdAGMvgMjnb2qOKh+ucTFSHPX5PPHPxHNLLIZKA7lhtpJkvPaxhapHwi80/vdtN S4gU75x3uE9pDhEZmRWtrMT+0KXhMli/oy2YXOTnOEhu/4vvApx4awkfNxbUu26p4b ob1PYb2DRhQ5SzdZDDOuDn2qyqzlG7HZB5zK8Wyk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334100270; i=@elandsys.com; bh=/LZu0MXIwDkl7dt2NG7/Px7Jz3Rssw7APmfhIKzeX3g=; h=Date:To:From:Subject:Cc; b=v0ziZ4eiMLZ8kAhiDmsWIx7nNqcstWQdt1kkOmSv2DNyXbhPFKIrGXiYbP1oZnyia ZP5zhRsvM4lzTqn1PaKWh7MHIXKe+rClNMVBd5d8JN0KrAhan3JGBncGvTIxcJ0/Bu hWYDsPa88llEwhdZhVyX6w51/a23PcWHGNWLBOw4= Message-Id: <6.2.5.6.2.20120410153427.08d5c3b0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Apr 2012 16:20:23 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-dbider-sha2-mac-for-ssh.all@tools.ietf.org, iesg@ietf.org Subject: [apps-discuss] AppsDir review of draft-dbider-sha2-mac-for-ssh-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: Tue, 10 Apr 2012 23:24:33 -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-dbider-sha2-mac-for-ssh-05 Title: SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol Reviewer: S. Moonesamy Review Date: April 10, 2012 IETF Last Call Date: April 16, 2012 IESG Telechat Date: April 26, 2012 Summary: This draft is ready for publication as a Proposed Standard. The draft defines algorithm names and parameters for use of some of the SHA-2 family of secure hash algorithms for data integrity verification in SSH protocol. It updates RFC 4253. Nits: In the Abstract Section: "It also updates RFC4253 by specifying a new RECOMMENDED data integrity algorithm." Should the word "RECOMMENDED" be interpreted as a RFC 2119 key word? In Section 3: "IANA is requested to update the SSH algorithm registry with the following entries." Shouldn't that be the Secure Shell MAC Algorithm Names registry? Regards, S. Moonesamy From jhutz@cmu.edu Tue Apr 10 18:55: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 7FE4E11E813E; Tue, 10 Apr 2012 18:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTJJik6RNOiV; Tue, 10 Apr 2012 18:55:13 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id ED6A511E8081; Tue, 10 Apr 2012 18:55:12 -0700 (PDT) Received: from [192.168.202.157] (pool-98-111-232-78.pitbpa.fios.verizon.net [98.111.232.78]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q3B1sxwL017790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 21:54:59 -0400 (EDT) From: Jeffrey Hutzelman To: "Mark D. Baushke" In-Reply-To: <25039.1334105406@eng-mail01.juniper.net> References: <6.2.5.6.2.20120410153427.08d5c3b0@elandnews.com> <25039.1334105406@eng-mail01.juniper.net> Content-Type: text/plain; charset="UTF-8" Date: Tue, 10 Apr 2012 21:54:58 -0400 Message-ID: <1334109298.2933.14.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: iesg@ietf.org, draft-dbider-sha2-mac-for-ssh.all@tools.ietf.org, S Moonesamy , apps-discuss@ietf.org, jhutz@cmu.edu Subject: Re: [apps-discuss] AppsDir review of draft-dbider-sha2-mac-for-ssh-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: Wed, 11 Apr 2012 01:55:13 -0000 On Tue, 2012-04-10 at 17:50 -0700, Mark D. Baushke wrote: > > In the Abstract Section: > > > > "It also updates RFC4253 by specifying a new RECOMMENDED data > > integrity algorithm." > > > > Should the word "RECOMMENDED" be interpreted as a RFC 2119 key word? > > Yes, the word "RECOMMENDED" given in both the Abstract and in section > "2. Data Integrity Algorithms" is a RFC 2119 key word as is specified in > section "1.1. Requirements Terminology" of document > draft-dbider-sha2-mac-for-ssh-05. Technically, the abstract itself does not impose a normative requirement in the language of RFC2119. However, the quoted sentence describes section 2, which does use that language; for clarity, the abstract also uses uppercase "RECOMMENDED". IMHO, changing this would serve only to make the abstract less clear and/or less concise. > > In Section 3: > > > > "IANA is requested to update the SSH algorithm registry with the > > following entries." > > > > Shouldn't that be the Secure Shell MAC Algorithm Names registry? > > Yes. I was uncertain how to properly address the registry. No. It should be the "Secure Shell Protocol Parameters" registry, of which the MAC Algorithm Names table is one part. So, if you want to replace "SSH algorithm registry" with "Secure Shell Protocol Parameters", that would be a reasonable change, but don't spin a new internet-draft at this time just for that change. Aside from that, the terminology used in section 3 is consistent with that used on the registry web page. Unless IANA indicates that something is unclear to them, I would not make any other changes. -- Jeff From stephen.farrell@cs.tcd.ie Tue Apr 10 19:34: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 06D2311E814A for ; Tue, 10 Apr 2012 19:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGE6LZOMsICE for ; Tue, 10 Apr 2012 19:34:31 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id DDDCC11E809B for ; Tue, 10 Apr 2012 19:34:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 80B2C17147C; Wed, 11 Apr 2012 03:34:29 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334111669; bh=CquDAsAwEdXDT+ YvoorKT1fnMVbMN9LvdVne2+nJb4U=; b=CDRFAj3YBUWz4STK+hb/6Ysu2iVEbh EufXGBioCwJrQ9RGpUl37FEnAu6qy5ApXntLZ9xjBQSxyfcHaQxHnZ9T8wNEJAoc JPJTx5RhB5/7rSYMqFbm0qo2U+0agO/3xs3pEMkfxc0qskHWau4dvB69UETC9RGg +r3SAdrYglV9Iatd4VzbuVEivRTj2x4/SQrJXyzUGBHO1dZ06c6WH57EI2pkECmk GRDJd2dP5xnz/utry0JxpHuZSbzaPJWLY2oYpEwPeKgKDGDszHBOsGPidLge6ZZA Hotkf6/YfDncAxYayyTsK9wfxXoNy+NAo0JpCpO76It/fgwapU43nkfA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 8J+VHf4lFVCK; Wed, 11 Apr 2012 03:34:29 +0100 (IST) Received: from [10.87.48.3] (unknown [86.44.64.139]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id CF886171479; Wed, 11 Apr 2012 03:34:23 +0100 (IST) Message-ID: <4F84EDAE.5030207@cs.tcd.ie> Date: Wed, 11 Apr 2012 03:34:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <4F7DFC47.2020604@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F0499619@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F0499619@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] draft-farrell-decade-ni-02: glitch in examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 02:34:33 -0000 Hi again James, On 04/10/2012 05:08 AM, Manger, James H wrote: > Stephen, > > A couple of "typos" in draft-farrell-decade-ni-02: > > The example SubjectPublicKeyInfo is shown in a strange way: each pair of bytes is shown in the opposite order to bytes on the wire (and the offset at the start of the line is in nibbles). The first few bytes of the BER-encoding are 30 820122, while the example starts: > 0000000 8230 2201 0d30 0906 862a 8648 0df7 0101 > > The BER-encoding is actually: > 30 820122 > 30 0D > 06 09 2A86 > ... > > Half of the example names are wrong, almost certainly due to this strange format. Yep. That was me being sloppy ("od -x" did used to do the right thing on some platform I used sometime in the distant past I think;-) > > The 120-bit "Binary Name" in figure 6 is wrong. It swaps the order of bytes (after the first). It should be: > 03 53269057 E12FE2B7 4BA07C89 2560A2 Ditto. > > The human-readable names (120-bit and 32-bit) are wrong. They have base32-encoded pairs of bytes in the wrong order. They should be: > sha-256-120;kmtjav7bf7rlos5apseskyfc;???? > sha-256-32;kmtjavy;???? We're deleting the last character, yes. Might need to think more about I18N for that all right. I'm told dropping the last character is ok, but have yet to check. > > I am not sure what the correct checksums are. > > The example checksums (eokv and csdh) look wrong. I assume the 4 base32 chars in the checksum should encode 5+5+5+1 bits respectively of the 16-bit CRC. Hence the last char encodes 1 bit, padded with 4 zeros: either 00000 or 10000, which should give 'a' or 'q' (not 'v' or 'h'). > > P.S. A CRC16 is calculated over an array of bytes. However the input is defined as a text string. I guess ASCII/UTF-8 encoding is assumed. It might be better to calculate the CRC over the bytes of the truncated hash. Fair point. OTOH, that'd mean omitting the "nih:sha-256;" part but I guess that'd be not much harm. I suspect that you may be right about the checksum. Will check with co-authors more involved with CoAP (Ari basically) to see what they prefer, since its them that want the CRC. I've posted a -03 that I hope is good now, other than the CRC input. Thanks again, Stephen. > > -- > James Manger > > From zach@sensinode.com Tue Apr 10 23: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 1695C21F8516 for ; Tue, 10 Apr 2012 23:27:26 -0700 (PDT) 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_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfDIDRc1C8Uw for ; Tue, 10 Apr 2012 23:27:25 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id E8E0221F8513 for ; Tue, 10 Apr 2012 23:27:24 -0700 (PDT) Received: from [10.59.1.44] (188-127-194-226.cust.suomicom.fi [188.127.194.226]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3B6RM7w004814; Wed, 11 Apr 2012 09:27:22 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <20120402124522.GX16698@jay.w3.org> Date: Wed, 11 Apr 2012 09:27:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> To: Carine Bournez X-Mailer: Apple Mail (2.1084) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 06:27:26 -0000 Carine, On Apr 2, 2012, at 3:45 PM, Carine Bournez wrote: > A consequence of relaxing these constraints in section 2 is that=20 > section 4 would have MAYs everywhere instead of those MUSTs: > << > Interoperability considerations: The registration of a Media Type > using this suffix MUST describe how to determine the XML Schema > that is used to encode/decode a payload identified by that Media > Type. In particular this description defines how to determine = the > Schema used to encode a payload using the SchemaID option of the > EXI header. The format of the identifier to be used in the > SchemaID, a reference to where the corresponding Schema is > defined, and a description of how future versions of such Schemas > will be handled MUST be included. A default Schema version in = the > absence of the SchemaID field MAY be defined. >>>=20 >=20 > Other points than schemaID would also need to be mentioned (I thought=20= > I had commented on that earlier as well). > It will be fine to specify a number of constraints when you define and > register a given foo+exi media type, but for the +exi suffix generic=20= > description, I'd just list interop key points without specific = restrictions. This draft is defining what you must define when registering a given = foo+exi, thus I think we are in line with making sure constraints are = specified. This draft *does not* intend to define a generic +exi suffix.=20= Regarding the other points than schemaID, I do agree that other settings = for EXI are controlled entirely by the EXI header. This should be = obvious, but probably it should be called out somehow. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Tue Apr 10 23: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 4010221F8581 for ; Tue, 10 Apr 2012 23:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RFnv+ih763q for ; Tue, 10 Apr 2012 23:31:55 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 63E4F21F8577 for ; Tue, 10 Apr 2012 23:31:46 -0700 (PDT) Received: from [10.59.1.44] (188-127-194-226.cust.suomicom.fi [188.127.194.226]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3B6Vih4005708; Wed, 11 Apr 2012 09:31:45 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <0885CE0D-11A3-4396-9443-37B4FF8D36C9@mnot.net> Date: Wed, 11 Apr 2012 09:31:44 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <0885CE0D-11A3-4396-9443-37B4FF8D36C9@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 06:31:56 -0000 On Mar 31, 2012, at 1:55 PM, Mark Nottingham wrote: > What's the use case here? Content negotiation, or something else? In particular this would be aimed at M2M applications that make use of = Schema-informed EXI. - Content-negotiation when an application also uses other forms of its = base media type (+xml, +json etc.) - Interoperability, this registration would force the schemaID to be = defined precisely and thus solve a problem in EXI. This is why the use = of this +exi form would only be for Schema informed use of EXI.=20 - This use of EXI is *not* content-encoding in my opinion, thus we are = providing a better media type model and encouraging media types that = mean something semantically.=20 Zach >=20 > Regards, >=20 >=20 > On 29/03/2012, at 10:52 PM, Zach Shelby wrote: >=20 >> I have posted a new version of the +exi registration draft. This = version improves the Interoperability considerations of the registration = requirements and further clarifies when this suffix may be used, as per = the feedback on the list from Carine and others. >>=20 >> http://www.ietf.org/id/draft-shelby-exi-registration-01.txt >>=20 >> Regards, >> Zach >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Date: March 29, 2012 10:47:32 PM GMT+02:00 >>> To: zach@sensinode.com >>> Subject: New Version Notification for = draft-shelby-exi-registration-01.txt >>>=20 >>> A new version of I-D, draft-shelby-exi-registration-01.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >>>=20 >>> Filename: draft-shelby-exi-registration >>> Revision: 01 >>> Title: The +exi Media Type Suffix >>> Creation date: 2012-03-29 >>> WG ID: Individual Submission >>> Number of pages: 5 >>>=20 >>> Abstract: >>> Efficient XML Interchange (EXI) is an XML representation technique >>> specified by the W3C to provie a binary alternative to the standard >>> text XML representation. This document defines a new Structure >>> Syntax Suffix "+exi" for use in a specific class of = protocols, where >>> "exi" content-type encoding or the generic = "application/exi" Media >>> Type are not applicable. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=20 >> --=20 >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >> Mobile: +358 40 7796297 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > -- > Mark Nottingham > http://www.mnot.net/ >=20 >=20 >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From sm@elandsys.com Tue Apr 10 23:32: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 CFE0921F86CB; Tue, 10 Apr 2012 23:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcK7qBy9jKV7; Tue, 10 Apr 2012 23:32:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9276521F86A3; Tue, 10 Apr 2012 23:32:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.8]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3B6WfAB024193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 23:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334125975; i=@elandsys.com; bh=wdf0IEsBM7AMQ1FEoeNBdA3+WwyfMu3AdLFDT0zTL9g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jo3gxuv0CF/AC5c7R2LzvCtXCuAaQBzABZN+Sfs+LeT5m5L6aXVJyD+Zvkq4aRK2E 0HtpkHSDoi40WSnox2yIuPKUFH9tOGRMxRGRTvmegTOhNrJE0KCwKNLWL+u4lAP9lb ocGA0G7EaxgqtjoYQM0OApE2gIuEgxEDcJ8qoIoo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334125975; i=@elandsys.com; bh=wdf0IEsBM7AMQ1FEoeNBdA3+WwyfMu3AdLFDT0zTL9g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vtWKqFKufx6V8ZYS/J0KSIoEAldfT4QQj9I2rCcBYVJcEC1S0AYpmJGmQOe1O69O+ bALXLSmstuWjrPkdDNjHSPN8vwtluuMWRXSEeK2IgABR/J0cWUqfegEjDRMwHLoHZc owVowtfCFEMco7p3+1/ntjDafoT2QFmxZxINDW6E= Message-Id: <6.2.5.6.2.20120410224902.07658bb8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Apr 2012 23:15:15 -0700 To: "Mark D. Baushke" From: S Moonesamy In-Reply-To: <25039.1334105406@eng-mail01.juniper.net> References: <6.2.5.6.2.20120410153427.08d5c3b0@elandnews.com> <25039.1334105406@eng-mail01.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-dbider-sha2-mac-for-ssh.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-dbider-sha2-mac-for-ssh-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: Wed, 11 Apr 2012 06:32:59 -0000 Hi Mark, The document shepherd commented on the nits ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04889.html ). I consider all the comments as addressed and defer to his judgement. At 17:50 10-04-2012, Mark D. Baushke wrote: >Yes, the word "RECOMMENDED" given in both the Abstract and in section >"2. Data Integrity Algorithms" is a RFC 2119 key word as is specified in >section "1.1. Requirements Terminology" of document >draft-dbider-sha2-mac-for-ssh-05. It is customary only to use RFC 2119 key words after the definition (Section 1.1 in the draft). >Yes. I was uncertain how to properly address the registry. > >The intent is to properly reference the "Secure Shell (SSH) Protocol >Parameters" document under the "MAC Algorithm Names" section. This is >the URL: > >http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xml#ssh-parameters-18 > >and the related text format of that document: > >http://www.ietf.org/assignments/ssh-parameters/ssh-parameters.txt > >to the table to be updated properly with the new MACs. IANA reviews the IANA Considerations section for any action (see the message from Amanda Barber). That section seems clear enough as IANA will be updating the correct registry. I'll suggest text just in case: IANA is requested to update the MAC Algorithm Names registry for Secure Shell Protocol Parameters with the following entries: Regards, S. Moonesamy From zach@sensinode.com Tue Apr 10 23: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 7D51E21F869F for ; Tue, 10 Apr 2012 23:49:15 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZD+A7jRzO90 for ; Tue, 10 Apr 2012 23:49:14 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 782DD21F869D for ; Tue, 10 Apr 2012 23:49:05 -0700 (PDT) Received: from [10.59.1.44] (188-127-194-226.cust.suomicom.fi [188.127.194.226]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3B6n0VR008983; Wed, 11 Apr 2012 09:49:00 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: <6C13AB73-6302-43D4-87BC-FB7ECD968A5B@berjon.com> Date: Wed, 11 Apr 2012 09:49:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6C13AB73-6302-43D4-87BC-FB7ECD968A5B@berjon.com> To: Robin Berjon X-Mailer: Apple Mail (2.1084) Cc: draft-shelby-exi-registration@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Feedback on draft-shelby-exi-registration-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: Wed, 11 Apr 2012 06:49:15 -0000 Hi Robin, First some background here. We have two different M2M applications that = are using EXI in Schema-informed mode, are already using other = +xml/+json etc. media types and have been requesting to use a +exi = suffix. Through discussion on this mailing list we determined that the = way we are using this probably doesn't fit well under the category of = content-encoding (but that is philosophical) and that a registration = would be useful for interoperability around the use of the schemaID = field.=20 - ZigBee Smart Energy 2.0 - SenML (http://tools.ietf.org/html/draft-jennings-senml-08)=20 I was the poor soul to volunteer to write up this draft to see what such = a registry would look like. None of us involved here are absolutely = determined to do it like this, but we do want to explore if this could = ensure better interoperability for this use of EXI.=20 On Apr 4, 2012, at 4:28 PM, Robin Berjon wrote: > Dear all, >=20 > please find some notes below on the draft-shelby-exi-registration-01 = proposal that describes a +exi media type suffix. Before I jump in, I = would like to make it clear that these comments are strictly my own and = are not made as any of former chair of the EXI WG, the XBC WG, or as = member of the W3C TAG. >=20 >=20 > =95 It is mentioned that the +exi suffix is defined "for use in a = specific class of protocols". It further seems to be implied that these = protocols do not support conveying content encoding separately from the = type. I think that it would be helpful to specify what those protocols = are. Given the cost and impact of introducing a +exi structure suffix = across the board, without that information I can only suspect that it = may be both cheaper and simpler to update the relevant protocols. That is not the case. By "protocols" here I am referring to = "applications". The web transfer protocols in questions, HTTP and CoAP, = can both handle content-encoding.=20 > Additionally, if those protocols are designed to be simpler, easier to = process profiles of HTTP, given that the use case covers devices that = obviously already have an EXI decoder, in absence of further information = I also wonder if those protocols could not be replaced by some form of = EXI-encoded HTTP (possibly minus a number of headers). But naturally = this is just a speculation made in absence of information. The IETF already has an efficient RESTful transfer protocol called CoAP = which is a great match for carrying Schema-informed EXI payloads. Thus = the increased activity around EXI in the IETF these days.=20 http://tools.ietf.org/html/draft-ietf-core-coap-09 >=20 > =95 Reading the following: > """ > The "+exi" Structure Syntax Suffix defined in this document is=20 > appropriate for use with a special class of protocols that: >=20 > o Make use of a Media Type to identify the semantics of the = protocol > payload, and offer more that one serialization of the payloads. > For example, some protocols may offer JSON, XML and EXI > representations" > """ > I cannot help but get a strong sense that this is actually making a = case for using content coding rather than a structured suffix since it = mirrors (certainly in the case of EXI) the semantics versus = serialisation distinction. EXI was deliberately defined to be a content = coding for XML; the group's decision to define an "exi" content coding = rather than a +exi suffix was intentional and not an oversight. >=20 > Conflating content coding and media type seems at the very least = strange to me. To take an example, we currently have image/svg+xml. This = draft introduces image/svg+exi. Can you explain why that would be a good = thing to introduce, and if it is should we also look into adding = image/svg+gzip and image/svg+identity? Well no, that is not what this draft is doing. It does not automatically = create a +exi suffix for every media type on earth. It creates = registration rules if such a media type would be registered and makes = those rules strict to limit the number of registrations as this is for a = particular use case.=20 > =95 This part "use EXI as a native encoding (without the use of XML as = an interemediate)" worries me because it seems to stem from a rather = fundamental misunderstanding of what EXI is. EXI is XML. There is no = form of requirement to hop through XML Data Model -> XML -> EXI, and = whichever way the EXI bitstream was produced really, really should be = immaterial for any protocol transmitting it as well as for a potential = media type registration. Yes, I understand that fully. This is more of a documentation problem = with EXI is Schema-informed mode.=20 > =95 This is worrying: "The registration of a Media Type using this = suffix MUST describe how to determine the XML Schema that is used to = encode/decode a payload identified by that Media Type." What it does is = register a generic suffix for a very specific usage. For instance, SVG = has no XML Schema. The above therefore precludes SVG from potentially = registering image/svg+exi (assuming it would be a sensible thing to do). That is exactly the point, SVG should use content-encoding as this = suffix is only meant for use with Schema-informed EXI. This +exi suffix = would only be allowed for use with applications that are using EXI in a = way where further information in the registration (use of schemaID) is = required for interoperability. All other uses of EXI would be required = to continue to use application/exi or content-encoding exi.=20 > What's more, EXI is not limited to relying on schema information from = XML Schema. It is perfectly valid to use DTDs, RelaxNG, JSON Schema, = domain-specific knowledge, etc. in order to generate a schema-informed = EXI encoding. So the above essentially rules out a large (possibly the = majority) of XML content, and rules out valid EXI encodings. Agreed, this could obviously be expanded to other valid ways of = generating a grammar.=20 > Again, 1) that seems very restrictive to justify a structured suffix; = and Correct, that is the whole point as you already have a content-encoding = defined.=20 > 2) it reinforces the feeling that this registration may be in part = motivated by some misunderstanding of EXI Nope, that is not an excuse that I can claim :-) Zach > . >=20 >=20 > Thanks! >=20 > --=20 > Robin Berjon - http://berjon.com/ - @robinberjon >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From carine@jay.w3.org Wed Apr 11 00:50:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADCE21F86D6 for ; Wed, 11 Apr 2012 00:50:54 -0700 (PDT) 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_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCP5OoYqmFyd for ; Wed, 11 Apr 2012 00:50:53 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8C021F86D5 for ; Wed, 11 Apr 2012 00:50:50 -0700 (PDT) Received: from carine by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1SHsKG-0003sP-EQ; Wed, 11 Apr 2012 03:50:48 -0400 Date: Wed, 11 Apr 2012 03:50:48 -0400 From: Carine Bournez To: Zach Shelby Message-ID: <20120411075024.GN18899@jay.w3.org> References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 07:50:54 -0000 Hi, On Wed, Apr 11, 2012 at 09:27:22AM +0300, Zach Shelby wrote: > > This draft is defining what you must define when registering a given foo+exi, thus I think we are in line with making sure constraints are specified. This draft *does not* intend to define a generic +exi suffix. The title of the draft is "The +exi Media Type Suffix". Is there some subtlety that I am missing entirely? I don't think you can override or define another draft for +exi once one is registered, that's the point of registering. Let me clarify my point: I think defining a +exi suffix for schema-informed mode saying "you must specify the form of schemaID that you are using" would be a huge mistake. It is (1) not useful, since the EXI 1.0 spec already says you have to define schemaID for your application, (2) harmful, since it tries to redefine the mechanism for options that is already defined in EXI 1.0, at least for the schema-informed mode. What's wrong with using Content-Encoding, exactly? Semantically, EXI *is* xml, so having something like foo+xml vs. foo+exi does not make sense, while *encoding* foo+xml with EXI makes sense. -- Carine Bournez -+- W3C Europe From ht@inf.ed.ac.uk Wed Apr 11 01:11: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 2DDB621F869C for ; Wed, 11 Apr 2012 01:11:20 -0700 (PDT) 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_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFtUP9RZjp-e for ; Wed, 11 Apr 2012 01:11:18 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA5A21F86B2 for ; Wed, 11 Apr 2012 01:11:17 -0700 (PDT) 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 q3B8Anxq011220; Wed, 11 Apr 2012 09:10:54 +0100 (BST) 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 q3B8Ao37018917; Wed, 11 Apr 2012 09:10:50 +0100 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 q3B8AnU9001560; Wed, 11 Apr 2012 09:10:49 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3B8AnPu001556; Wed, 11 Apr 2012 09:10:49 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Carine Bournez References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 11 Apr 2012 09:10:49 +0100 In-Reply-To: <20120411075024.GN18899@jay.w3.org> (Carine Bournez's message of "Wed, 11 Apr 2012 03:50:48 -0400") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (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: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 08:11:20 -0000 Carine Bournez writes: > Let me clarify my point: I think defining a +exi suffix for schema-informed > mode saying "you must specify the form of schemaID that you are using" would > be a huge mistake. It is (1) not useful, since the EXI 1.0 spec already says > you have to define schemaID for your application, (2) harmful, since it tries > to redefine the mechanism for options that is already defined in EXI 1.0, > at least for the schema-informed mode. > What's wrong with using Content-Encoding, exactly? Semantically, EXI *is* xml, > so having something like foo+xml vs. foo+exi does not make sense, while > *encoding* foo+xml with EXI makes sense. +1 This approach seems BAD (Broken As Designed) and would set a very harmful precedent. 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 yusuke.doi@toshiba.co.jp Wed Apr 11 01:30: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 442A211E814C for ; Wed, 11 Apr 2012 01:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhAY+DTqHplk for ; Wed, 11 Apr 2012 01:30:09 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE2611E80BE for ; Wed, 11 Apr 2012 01:30:08 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q3B8U7fG003874 for ; Wed, 11 Apr 2012 17:30:07 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q3B8U7HG005546 for apps-discuss@ietf.org; Wed, 11 Apr 2012 17:30:07 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id TAA05545; Wed, 11 Apr 2012 17:30:07 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q3B8U6Ft016750 for ; Wed, 11 Apr 2012 17:30:06 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id q3B8U6DO024452; Wed, 11 Apr 2012 17:30:06 +0900 (JST) Received: from [133.196.16.79] (ncg-dhcp79.isl.rdc.toshiba.co.jp [133.196.16.79]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 2AF2D97CB6; Wed, 11 Apr 2012 17:30:06 +0900 (JST) Message-ID: <4F85410D.20802@toshiba.co.jp> Date: Wed, 11 Apr 2012 17:30:05 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Carine Bournez References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> In-Reply-To: <20120411075024.GN18899@jay.w3.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 08:30:10 -0000 Hi, (2012-04-11 16:50), Carine Bournez wrote: > Let me clarify my point: I think defining a +exi suffix for schema-informed > mode saying "you must specify the form of schemaID that you are using" would > be a huge mistake. It is (1) not useful, since the EXI 1.0 spec already says > you have to define schemaID for your application, (2) harmful, since it tries > to redefine the mechanism for options that is already defined in EXI 1.0, > at least for the schema-informed mode. I cannot understand (some of) your point. I think EXI spec does not define any 'mechanism for options' according to schemaId definition. The EXI spec (in schema-informed mode) is useful only if decoders know the running application a priori. Regards, Yusuke From carine@jay.w3.org Wed Apr 11 01:59: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 C117F21F85B1 for ; Wed, 11 Apr 2012 01:59:23 -0700 (PDT) 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, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgrjv7mqBfZo for ; Wed, 11 Apr 2012 01:59:23 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 4159E21F85AC for ; Wed, 11 Apr 2012 01:59:23 -0700 (PDT) Received: from carine by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1SHtOa-0007ET-43; Wed, 11 Apr 2012 04:59:20 -0400 Date: Wed, 11 Apr 2012 04:59:20 -0400 From: Carine Bournez To: Yusuke DOI Message-ID: <20120411085920.GP18899@jay.w3.org> References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F85410D.20802@toshiba.co.jp> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 08:59:24 -0000 On Wed, Apr 11, 2012 at 05:30:05PM +0900, Yusuke DOI wrote: >> you have to define schemaID for your application, (2) harmful, since it tries >> to redefine the mechanism for options that is already defined in EXI 1.0, >> at least for the schema-informed mode. > > I cannot understand (some of) your point. I think EXI spec does not define any 'mechanism for options' according to schemaId definition. The EXI spec (in schema-informed mode) is useful only if decoders know the running application a priori. Rephrasing: the EXI 1.0 spec has a mechanism to tell the other end that schema-informed mode is in use, and the EXI 1.0 spec says that the application level has to take care of defining the form of schemaID. -- Carine Bournez -+- W3C Europe From sm@elandsys.com Wed Apr 11 02:30: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 7A21821F86FD; Wed, 11 Apr 2012 02:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWzRVByfz7EC; Wed, 11 Apr 2012 02:30:06 -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 0CA0921F86F1; Wed, 11 Apr 2012 02:30:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.247]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3B9TkBg004420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 02:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334136600; i=@elandsys.com; bh=UH8Dobnb4TkFPeNF/7Ib0vZnviF69Bz7wsHxB1NhcbI=; h=Date:To:From:Subject:Cc; b=Cbz+7fXqfg6S7qS8aOhngaeauErvwu+FHth9Y9TYDU0bVbGiDKaTXMXtFdg0Q0oo5 CZn2ccO20o1yL0Q7XgoSzUFrv+hOuQjmwzBiNOMDq/6ExWdUae61mz5sD6824J4KdH Hr5I0P33jh0dpy19PerY5A6Qhxsrjef1zmLDoFOQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334136600; i=@elandsys.com; bh=UH8Dobnb4TkFPeNF/7Ib0vZnviF69Bz7wsHxB1NhcbI=; h=Date:To:From:Subject:Cc; b=WiJ8UVilFcj3Av53YGzg0ihJ97hAh2G68QqUUoLQVTnjKjDOkwJE4QPsjzN6hWY8U lMqf3sL7V+kLT2e+9Jcm4hUcnqOO/YFAVI96vwCaaBEwB9MfwajL6ONCTd/iJxh7UE Gy+6pfH5q2J8WB4HdaOYEjP1HAgUKh7nCq44VryY= Message-Id: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Apr 2012 02:25:36 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: appsdir@ietf.org Subject: [apps-discuss] Responding to Applications Area Directorate reviews X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 09:30:08 -0000 Hello, I'll comment on the template used for Applications Area Directorate (AppsDir) reviews as it may help authors to respond to the reviews. "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." In plain English, this means that the comments in the review does not bear more weight than a comment submitted by an individual during a Last Call. The Applications Area Directors may or may not agree with the comments of the AppsDir reviewer. The Applications Area Directorate does not have any veto power on a draft. It is suggested that the author(s) asks the document shepherd (RFC 4858) or the Area Director who sponsored the draft for guidance about IETF process, changes that should be made, whether to post a new revision, etc. A review generally list issues as major or minor. I'll use a review performed by Ted Hardie as an example ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04847.html ). The reviewer explained why he considered some issues as major. The author discussed about the issues with the reviewer ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04859.html ). There isn't a clear-cut rule on what is a major or minor issue. It's up to the reviewer to make a judgement call. It is up to the author(s), or working group, to decide about whether these issues should be resolved and how to do so. Some AppsDir reviews may list nits. These nits are generally editorial issues. For example: "I personally found the Introduction somewhat hard to parse" That doesn't mean that the author has to make changes to the Introduction section. It's an editorial decision. It's up to the authors to determine whether the text should be changed so that the reader can understand it. Regards, S. Moonesamy From dave@cridland.net Wed Apr 11 02: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 5FF6511E80BE for ; Wed, 11 Apr 2012 02:54:20 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0Yc9FG8IR+0 for ; Wed, 11 Apr 2012 02:54:19 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id D0C3111E809F for ; Wed, 11 Apr 2012 02:54:16 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 014801168087; Wed, 11 Apr 2012 10:54:08 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WBAD020GMNs; Wed, 11 Apr 2012 10:53:57 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id EBAE91168067; Wed, 11 Apr 2012 10:53:55 +0100 (BST) References: <6.2.5.6.2.20120410125815.08d5c788@elandnews.com> In-Reply-To: <6.2.5.6.2.20120410125815.08d5c788@elandnews.com> MIME-Version: 1.0 Message-Id: <3404.1334138036.089383@puncture> Date: Wed, 11 Apr 2012 10:53:56 +0100 From: Dave Cridland To: SM , General discussion of application-layer protocols , Eliot Lear Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [apps-discuss] Review of draft-lear-lisp-nerd-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 09:54:20 -0000 I also had a quick skim. What struck me was that, given the decision to use object-level security over transport-level, there seemed to be portions of information left unprotected. For example, the protocol appears to rely on versioning information left unprotected, as well as HTTP-level redirects which also appear to be unprotected. I wondered whether any interesting attack could be mounted by presenting older versions of the NERD as newer, meaning that the deltas were misinterpreted. I'd think that the correct thing to do would be to include the versioning information within the PKCS#7, and also include expiry and/or next-update information, so that participating routers could flag up outdated information and alert operators, as well as be reasonably aware of when some form of quiet disruption was occuring. That said, I freely admit that not only is this area not my forté to begin with, but I lack experience of LISP at all, so I won't be surprised if I'm missing something obvious. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From zach@sensinode.com Wed Apr 11 04: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 23C8411E80AC for ; Wed, 11 Apr 2012 04:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YviiO9-G0IhN for ; Wed, 11 Apr 2012 04:50:31 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC9411E808F for ; Wed, 11 Apr 2012 04:50:30 -0700 (PDT) Received: from [10.59.1.92] (188-127-194-226.cust.suomicom.fi [188.127.194.226]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3BBoNL4008167; Wed, 11 Apr 2012 14:50:23 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <20120411085920.GP18899@jay.w3.org> Date: Wed, 11 Apr 2012 14:50:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> To: Carine Bournez X-Mailer: Apple Mail (2.1084) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 11:50:32 -0000 On Apr 11, 2012, at 11:59 AM, Carine Bournez wrote: > On Wed, Apr 11, 2012 at 05:30:05PM +0900, Yusuke DOI wrote: >>> you have to define schemaID for your application, (2) harmful, since = it tries >>> to redefine the mechanism for options that is already defined in EXI = 1.0, >>> at least for the schema-informed mode. >>=20 >> I cannot understand (some of) your point. I think EXI spec does not = define any 'mechanism for options' according to schemaId definition. The = EXI spec (in schema-informed mode) is useful only if decoders know the = running application a priori. >=20 >=20 > Rephrasing: the EXI 1.0 spec has a mechanism to tell the other end = that > schema-informed mode is in use, and the EXI 1.0 spec says that the=20 > application level has to take care of defining the form of schemaID. Right. This is what we are trying to fix at the application level, by = providing a registry where this information is easily available to = anyone on the Internet that runs into that media type. Just waving our = hands and hoping that in some specification, somewhere, the = interpretation of schemaID has been defined does not work on the = Internet. The knowledge alone of application/foo with content-encoding: = exi does not tell you sufficient information for Schema-informed mode to = actually decode the payload. For encodings like gzip or deflate, that is = obviously not a problem.=20 Now, if EXI folks think that the way we are approaching this is not the = right one, how do you propose to fix the problem?=20 One possible way would be for application/foo media types that expect to = be used with exi content-encoding (Schema-informed mode) to include the = needed schema information in the application/foo media type = registration. Not sure how easy it would be to add such information = there, or if some instructions would be needed regarding that. =20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From cabo@tzi.org Wed Apr 11 05:04: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 584DE21F84B6 for ; Wed, 11 Apr 2012 05:04:16 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLUqMNGHrg9G for ; Wed, 11 Apr 2012 05:04:15 -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 00EFB21F84A6 for ; Wed, 11 Apr 2012 05:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3BC45xe010895; Wed, 11 Apr 2012 14:04:05 +0200 (CEST) Received: from dynamic-218-h.informatik.uni-bremen.de (dynamic-218-h.informatik.uni-bremen.de [134.102.218.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3A5AA33E; Wed, 11 Apr 2012 14:04:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20120411085920.GP18899@jay.w3.org> Date: Wed, 11 Apr 2012 14:04:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> To: Carine Bournez X-Mailer: Apple Mail (2.1257) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 12:04:16 -0000 On Apr 11, 2012, at 10:59, Carine Bournez wrote: > Rephrasing: the EXI 1.0 spec has a mechanism to tell the other end = that > schema-informed mode is in use, and the EXI 1.0 spec says that the=20 > application level has to take care of defining the form of schemaID. Let me try to translate this into language pertaining to the discussion = at hand: EXI can be used as a content-coding for XML documents in "Built-In" = mode. This would be the usage for the "Content-Encoding: EXI" that has been = registered. EXI requires out of band information to use the "Schema-Informed" mode. In the Internet, This would normally be provided in an Internet = media-type definition. The media-type definition may also want to constrain the allowable = values for the numerous options EXI provides, allowing for constrained = implementations of EXI. No existing application/foo+xml media type provides the latter kind of = information. With Content-Encoding: EXI, they are therefore limited to "Built-In" = mode. Any application that needs a tailored, schema-informed version of EXI = should therefore register one or more application/foo+exi media types. The next thing we should do is write down a template for all the = information that needs to be nailed down in an application/foo+exi media = type registration. Gr=FC=DFe, Carsten From jan.algermissen@nordsc.com Tue Apr 10 11:58: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 3F03211E811A for ; Tue, 10 Apr 2012 11:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bHWt1EWw0L5 for ; Tue, 10 Apr 2012 11:58:53 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 82CCF11E80FD for ; Tue, 10 Apr 2012 11:58:53 -0700 (PDT) Received: from [192.168.2.103] (p548F9CC3.dip.t-dialin.net [84.143.156.195]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0Lu38g-1S8IYe2WYw-011d7h; Tue, 10 Apr 2012 20:58:50 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: Date: Tue, 10 Apr 2012 20:58:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> To: Mark Nottingham X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:H5B5E2hCIwVtejN6pRPgZ7S732hfxH/cgYfw8lcUDW8 n76CgdoRxt+F63UfS/+Llpc0sNIXMQuttuyuuhPv7D8VE7Tm/O 2HkvPeHMgggxkcLZO7gom50oytdkeWJCeo/HVQyq0swFUHBxqQ a9VBdoH0nf4UD8wN1N0bUloLpEYmlzZ7k+QFP/DZCUPXNrMXrm yNwSi8Vh8kJqdhjIsUiUxQD7ayiss1EmUaPaGhwOmC3Nj0189E xUAWWfQ+5SmCQpJfnAVICATYVGZpYM6uVpws+IRR1aV9WTjEyx qYRKXEG4M8x+0Yef7mbFkEw6i4+VqTuiw8LoT9BFHl3XRn1xPL 7v2Ux4zPsxN4A1T+4jZxV4nuPXIKBeMc6aGDBSw2VLwuupzbBx 0frmFjDlaKCng== X-Mailman-Approved-At: Wed, 11 Apr 2012 08:06:57 -0700 Cc: Erik Wilde , "apps-discuss@ietf.org application-layer protocols" , REST Discuss Subject: Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Apr 2012 18:58:54 -0000 On Apr 10, 2012, at 5:56 PM, Mark Nottingham wrote: > > one example i am currently considering adding is atompub. currently, = when you retrieve a feed, there's no way to tell it's atompub-capable = just by looking at it. The thing is that it is not necessary to *learn* this. If it is your = expectation that the service you are interacting with is actually an = atompub service then fine, go ahead. If the service behaves as you = expect, fine; your use case succeeds. If it isn't you'll discover that from the response and change = configuration of your set of entry URIs or whatever. The decision regarding your use case comes first and you do not need to = double check at runtime. For example, you have a bookmark for your = favorite search engine. Do you check every time you use that bookmark = whether the search engine is still there? Or do you just use the = bookmark based according to your expectations? Likewise, what does that check for atompub capabilities buy you? The = reason you check for them is that you assume they are there in the first = place. If that check fails .... then what? You are in exactly the same = situation as when you POST you atom entry right away and see what = happens. The nature (as in "Amazon is an online store") of services changes = slowly (if at all) and the particular HTTP idioms that services use also = changes slowly (e.g. creation with PUT vs. creation with POST). In REST = there is, IMHO at least, a third xxx-time besides the traditional = design-time and run-time. It is what I think of as 'configuration-time'. = This is where a method like OPTIONS plays its part, for example. Try out = a service once, learn what it is and what its particularities are and = then adjust your configuration for interactions with that service. The = things you discover at configuration-time are not likely to change soon. = If they do, you adjust your configuration and maybe you do not need to = do that , ever. >=20 > Well, what thing in this case is atom pub capable? The format that the = links are occurring within, or the targets of the links themselves? I'd = argue the latter. You can take that argument too far, of course, but = generally I see profiles as describing format conventions, and link = relations as describing behaviours of resources. Of course, some of = those behaviours can be "produce this format" and some of the formatting = conventions can be "link to something with this behaviour". >=20 > Am happy to be proven wrong on this, I just think we need good = patterns of use / best practices to encourage reasonable design. +1 Jan >=20 > Make sense? From mdb@juniper.net Tue Apr 10 17:50: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 162E821F8566; Tue, 10 Apr 2012 17:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPnyI72F4diq; Tue, 10 Apr 2012 17:50:34 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 84D5921F8564; Tue, 10 Apr 2012 17:50:19 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT4TVSzcWhscw035YIdyUr2G0+o3dr0J5@postini.com; Tue, 10 Apr 2012 17:50:34 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 10 Apr 2012 17:50:08 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q3B0o7151444; Tue, 10 Apr 2012 17:50:07 -0700 (PDT) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id EF2A11145A; Tue, 10 Apr 2012 17:50:06 -0700 (PDT) To: S Moonesamy In-Reply-To: <6.2.5.6.2.20120410153427.08d5c3b0@elandnews.com> References: <6.2.5.6.2.20120410153427.08d5c3b0@elandnews.com> Comments: In-reply-to: S Moonesamy message dated "Tue, 10 Apr 2012 16:20:23 -0700." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.2; nmh 1.2; GNU Emacs 22.1.1 X-Face: #8D_6URD2G%vC.hzU Sender: MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Wed, 11 Apr 2012 08:07:18 -0700 Cc: draft-dbider-sha2-mac-for-ssh.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-dbider-sha2-mac-for-ssh-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: Wed, 11 Apr 2012 00:50:35 -0000 S Moonesamy writes: > 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-dbider-sha2-mac-for-ssh-05 > Title: SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport > Layer Protocol > > Reviewer: S. Moonesamy > Review Date: April 10, 2012 > IETF Last Call Date: April 16, 2012 > IESG Telechat Date: April 26, 2012 > > Summary: This draft is ready for publication as a Proposed Standard. > > The draft defines algorithm names and parameters for use of some of > the SHA-2 family of secure hash algorithms for data integrity > verification in SSH protocol. It updates RFC 4253. > > Nits: > > In the Abstract Section: > > "It also updates RFC4253 by specifying a new RECOMMENDED data > integrity algorithm." > > Should the word "RECOMMENDED" be interpreted as a RFC 2119 key word? Yes, the word "RECOMMENDED" given in both the Abstract and in section "2. Data Integrity Algorithms" is a RFC 2119 key word as is specified in section "1.1. Requirements Terminology" of document draft-dbider-sha2-mac-for-ssh-05. Please advise any changes needed to the document to make this clearer. > In Section 3: > > "IANA is requested to update the SSH algorithm registry with the > following entries." > > Shouldn't that be the Secure Shell MAC Algorithm Names registry? Yes. I was uncertain how to properly address the registry. The intent is to properly reference the "Secure Shell (SSH) Protocol Parameters" document under the "MAC Algorithm Names" section. This is the URL: http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xml#ssh-parameters-18 and the related text format of that document: http://www.ietf.org/assignments/ssh-parameters/ssh-parameters.txt to the table to be updated properly with the new MACs. Please advise as to the correct method to reference the IANA registry as needed for section 3. Should the text in section 3 be rewritten as: IANA is requested to update the Secure Shell (SSH) Protocol Parameters "MAC Algorithm Names" registry with the following entries: or is some other method of reference needed? Thank you, -- Mark From ht@inf.ed.ac.uk Wed Apr 11 08:15: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 1944111E8170 for ; Wed, 11 Apr 2012 08:15:24 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUlQH8gFIBoT for ; Wed, 11 Apr 2012 08:15:23 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id BDD2711E8164 for ; Wed, 11 Apr 2012 08:15:22 -0700 (PDT) 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 q3BFFCmQ023161; Wed, 11 Apr 2012 16:15:12 +0100 (BST) 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 q3BFFD5s003155; Wed, 11 Apr 2012 16:15:13 +0100 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 q3BFFDj3009860; Wed, 11 Apr 2012 16:15:13 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3BFFCEl009856; Wed, 11 Apr 2012 16:15:12 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Carsten Bormann References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 11 Apr 2012 16:15:12 +0100 In-Reply-To: (Carsten Bormann's message of "Wed, 11 Apr 2012 14:04:05 +0200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (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: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:15:24 -0000 Carsten Bormann writes: > EXI requires out of band information to use the "Schema-Informed" > mode. In the Internet, This would normally be provided in an > Internet media-type definition. The media-type definition may also > want to constrain the allowable values for the numerous options EXI > provides, allowing for constrained implementations of EXI. Your conclusion (use media type) doesn't follow. Consider the analogy of Content-Encoding: gzip -- suppose gzip provided improved performance based on the decade in which the encoded document was written, since natural language priors slowly shift over time. Now decoding requires OOB information about document creation date. How shall we provide it. I know -- we'll define media types application/...+gzip for every decade of interest! I hope it's obvious that would be a mistake. . . If decoding requires some parameters, surely the right thing to do is to transmit them in the obvious place, i.e. in the response message header. Either use the Content-Encoding (and Accept-Encoding) header itself, by registering a new Content-Coding value [1] (foo+exi), or (better) ask the W3C EXI WG to publish a Note defining an extension-header for specifying or requesting a schemaID (and more generally, perhaps, other properties specifiable in the EXI Options docuemtns). Not only would the second option fit the architecture better, it would remove the necessity for publishing a new RFC every time you update the relevant schema! ht [1] http://www.iana.org/assignments/http-parameters/http-parameters.xml -- 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 tony@att.com Wed Apr 11 08:25: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 7830721F8575 for ; Wed, 11 Apr 2012 08:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTCulJB2BzMs for ; Wed, 11 Apr 2012 08:25:41 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 9074921F8572 for ; Wed, 11 Apr 2012 08:25:41 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 572a58f4.0.1115370.00-275.3087673.nbfkord-smmo04.seg.att.com (envelope-from ); Wed, 11 Apr 2012 15:25:41 +0000 (UTC) X-MXL-Hash: 4f85a2750c5a2e13-72d1a4c9daeaf7074002a98bbe310c26ca17c8e2 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 q3BFPeFV019567 for ; Wed, 11 Apr 2012 11:25:41 -0400 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 q3BFPcbT019563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Apr 2012 11:25:38 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Wed, 11 Apr 2012 11:25:19 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3BFPJjJ011045 for ; Wed, 11 Apr 2012 11:25:19 -0400 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3BFPBQE010787 for ; Wed, 11 Apr 2012 11:25:11 -0400 Received: from [135.91.110.244] (ds135-91-110-244.dhcps.ugn.att.com[135.91.110.244]) by maillennium.att.com (mailgw1) with ESMTP id <20120411152212gw1004or7te> (Authid: tony); Wed, 11 Apr 2012 15:22:12 +0000 X-Originating-IP: [135.91.110.244] Message-ID: <4F85A256.3000400@att.com> Date: Wed, 11 Apr 2012 11:25:10 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <0885CE0D-11A3-4396-9443-37B4FF8D36C9@mnot.net> <201204020745.q327j8Rr014728@toshiba.co.jp> <019201cd10e8$31dfa590$959ef0b0$@packetizer.com> In-Reply-To: <019201cd10e8$31dfa590$959ef0b0$@packetizer.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=p4QNoMogDYAA:10 a=vnNYxAp2wzwA:10 a=I33QWX3c-g] X-AnalysisOut: [EA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:1] X-AnalysisOut: [0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=Aw8TyfFb4e4_T-A0z3kA:9 a] X-AnalysisOut: [=3z2xXJCcnt5ZCepL1g0A:7 a=QEXdDO2ut3YA:10] Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:25:42 -0000 On 4/2/2012 11:49 AM, Paul E. Jones wrote: > I've noted that nearly every time that JSON is employed the associated media type is application/json. In fact, I cannot recall having seen any standards with application/whatever+json. So, does this suggest that the level of granularity is not needed? The following have all been registered: vnd.collection+json vnd.hal+json vnd.oftn.l10n+json Tony Hansen From julian.reschke@gmx.de Wed Apr 11 08:30: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 0F59A11E808F for ; Wed, 11 Apr 2012 08:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.583 X-Spam-Level: X-Spam-Status: No, score=-103.583 tagged_above=-999 required=5 tests=[AWL=-0.984, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrhO7WomowoB for ; Wed, 11 Apr 2012 08:30:43 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id EFB3511E8088 for ; Wed, 11 Apr 2012 08:30:42 -0700 (PDT) Received: (qmail invoked by alias); 11 Apr 2012 15:30:41 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp004) with SMTP; 11 Apr 2012 17:30:41 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19I9n80tBRIalvOw1sjSKdZa157SnkfbsUPYdTqDo rJ2OpGBnAj/OlE Message-ID: <4F85A3A2.9000505@gmx.de> Date: Wed, 11 Apr 2012 17:30:42 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Henry S. Thompson" References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:30:44 -0000 On 2012-04-11 17:15, Henry S. Thompson wrote: > Carsten Bormann writes: > >> EXI requires out of band information to use the "Schema-Informed" >> mode. In the Internet, This would normally be provided in an >> Internet media-type definition. The media-type definition may also >> want to constrain the allowable values for the numerous options EXI >> provides, allowing for constrained implementations of EXI. > > Your conclusion (use media type) doesn't follow. Consider the analogy > of Content-Encoding: gzip -- suppose gzip provided improved > performance based on the decade in which the encoded document was > written, since natural language priors slowly shift over time. Now > decoding requires OOB information about document creation date. How shall > we provide it. I know -- we'll define media types > application/...+gzip for every decade of interest! I hope it's > obvious that would be a mistake. . . > > If decoding requires some parameters, surely the right thing to do is > to transmit them in the obvious place, i.e. in the response message > header. If decoding requires additional information, than IMHO you can't use HTTP's Content-Coding or Transfer-Encoding. By all means, if you think otherwise then send feedback to the HTTPbis WG. > Either use the Content-Encoding (and Accept-Encoding) header itself, > by registering a new Content-Coding value [1] (foo+exi), or (better) > ask the W3C EXI WG to publish a Note defining an extension-header for > specifying or requesting a schemaID (and more generally, perhaps, > other properties specifiable in the EXI Options docuemtns). > > Not only would the second option fit the architecture better, it would > remove the necessity for publishing a new RFC every time you update > the relevant schema! Adding more request headers here is problematic because they contribute to the message size, even when they are never used. Best regards, Julian From dhc@dcrocker.net Wed Apr 11 08:39: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 480DD11E8088; Wed, 11 Apr 2012 08:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVqFvYcBA4tE; Wed, 11 Apr 2012 08:39:53 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8956811E8085; Wed, 11 Apr 2012 08:39:53 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3BFda93030701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 08:39:40 -0700 Message-ID: <4F85A5B5.4030202@dcrocker.net> Date: Wed, 11 Apr 2012 08:39:33 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 11 Apr 2012 08:39:40 -0700 (PDT) Cc: appsdir@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews 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: Wed, 11 Apr 2012 15:39:54 -0000 On 4/11/2012 2:25 AM, S Moonesamy wrote: > > In plain English, this means that the comments in the review does not bear more > weight than a comment submitted by an individual during a Last Call. SM, It might be worth adding simple language like this to our material, including the apps area review team web page AND the template. The essence of directorate-based reviews is perspective, not authority. In our case, it supplies a review from someone with an applications-oriented perspective. What should matter, therefore, are the merits of the review and not the body "authorizing" it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned.freed@mrochek.com Wed Apr 11 09:09: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 E345221F853C for ; Wed, 11 Apr 2012 09:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYKkZoadiHqH for ; Wed, 11 Apr 2012 09:09:17 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF4621F8539 for ; Wed, 11 Apr 2012 09:09:16 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE6QSLU0EO0000P5@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 11 Apr 2012 09:09:12 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Wed, 11 Apr 2012 09:09:08 -0700 (PDT) Message-id: <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> Date: Wed, 11 Apr 2012 08:57:39 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 11 Apr 2012 17:30:42 +0200" <4F85A3A2.9000505@gmx.de> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> To: Julian Reschke Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:09:18 -0000 > On 2012-04-11 17:15, Henry S. Thompson wrote: > > Carsten Bormann writes: > > > >> EXI requires out of band information to use the "Schema-Informed" > >> mode. In the Internet, This would normally be provided in an > >> Internet media-type definition. The media-type definition may also > >> want to constrain the allowable values for the numerous options EXI > >> provides, allowing for constrained implementations of EXI. > > > > Your conclusion (use media type) doesn't follow. Consider the analogy > > of Content-Encoding: gzip -- suppose gzip provided improved > > performance based on the decade in which the encoded document was > > written, since natural language priors slowly shift over time. Now > > decoding requires OOB information about document creation date. How shall > > we provide it. I know -- we'll define media types > > application/...+gzip for every decade of interest! I hope it's > > obvious that would be a mistake. . . > > > > If decoding requires some parameters, surely the right thing to do is > > to transmit them in the obvious place, i.e. in the response message > > header. > If decoding requires additional information, than IMHO you can't use > HTTP's Content-Coding or Transfer-Encoding. By all means, if you think > otherwise then send feedback to the HTTPbis WG. Julian is 100% correct here. If EXI requires knowledge of the type itself, it's not a separable encoding, which is what Content-Coding, Transfer-Encoding, and Content-Transfer-Encoding all require. And while I suppose we could adopt the foo+exi approach, having an explosion of encodings is a really bad idea. And if this is the case, it really isn't suitable for a +exi suffix either. +exi is supposed to mean the format can at least be parsed, independent of any knowledge of the type semantics. This is why I support the idea of having +ber and +der but not +per - with +per you have to know the ASN.1 schema in order to parse the material properly. For better or worse, we don't currently have a place in the architecture for these entities. We could define some other sort of type naming convention if there's really a need for it, but adding additional out of band information that has to be processed in order to interpret the material correctly is rather obviously highly problematic. Ned From cabo@tzi.org Wed Apr 11 09:09: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 BA55021F8546 for ; Wed, 11 Apr 2012 09:09:32 -0700 (PDT) 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_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XcgDRxTLofB for ; Wed, 11 Apr 2012 09:09:32 -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 CF1A121F8542 for ; Wed, 11 Apr 2012 09:09:31 -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 q3BG9N4q009069; Wed, 11 Apr 2012 18:09:23 +0200 (CEST) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D0E2E4F0; Wed, 11 Apr 2012 18:09:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 11 Apr 2012 18:09:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> To: ht@inf.ed.ac.uk (Henry S. Thompson) X-Mailer: Apple Mail (2.1257) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:09:32 -0000 Actually, the context in which we (at least some of us) are discussing = this does not involve HTTP. So HTTP header fields definitely are not = the right way to handle this. (But even in HTTP, I'd expect coding = parameters to be specified in the payload, just like it is done in = RFC1950.) Our use case is about reigning in the exuberant puzzle of choices. = Flexibility is overrated. Options often cost more money to implement = than the optional functionality, and they hurt interoperability. We = want to nail down as much as possible. I'd expect us to never send an = EXI header, but always define that in the media type. Yes, we might = have a couple more media types in the end. But the point of = standardization is to create markets by reducing choice, so that = proliferation will be limited. Gr=FC=DFe, Carsten From msk@cloudmark.com Wed Apr 11 09:28: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 A5F3111E8074 for ; Wed, 11 Apr 2012 09:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+Ha+ABhR5mt for ; Wed, 11 Apr 2012 09:28:03 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id F1DBF21F858E for ; Wed, 11 Apr 2012 09:28:02 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id wgTz1i0010ZaKgw01gTzJB; Wed, 11 Apr 2012 09:27:59 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=HuX06jvS c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=OsLRAgjgfhMA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=LQcigEgVJn5rR9JZyfoA:9 a=U8xenhLcuBezkKnEm5YA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Wed, 11 Apr 2012 09:27:45 -0700 From: "Murray S. Kucherawy" To: "appsdir@ietf.org" , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews Thread-Index: AQHNF/leTGpOPedjX0mdSf3zDHtLeZaVzjXg Date: Wed, 11 Apr 2012 16:27:44 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D3639@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> <4F85A5B5.4030202@dcrocker.net> In-Reply-To: <4F85A5B5.4030202@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334161680; bh=UMkRisjbGftE3bkLItijXvyarREs1umqLb1oPglXC9g=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=IIQk24iCiJzowdxWHKa7bWU/iCsX49K7nuT7O5pPOX2f4VBOTP/hAXvQT8y6ax/Yp UT3IXDfkVpHykpSsdpldJXcQdAya9Quiz3ajPJng8flGIqelt76LhaRGk8wDLLWXdp 5NWIdQFUO/Wn2JBku8yRBPiqHnHo5jFe8b6/IKm4= Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 16:28:03 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Dave Crocker > Sent: Wednesday, April 11, 2012 8:40 AM > To: S Moonesamy > Cc: appsdir@ietf.org; apps-discuss@ietf.org > Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Dir= ectorate reviews >=20 > > In plain English, this means that the comments in the review does not > > bear more weight than a comment submitted by an individual during a > > Last Call. >=20 > It might be worth adding simple language like this to our material, > including the apps area review team web page AND the template. >=20 > The essence of directorate-based reviews is perspective, not authority. >=20 > In our case, it supplies a review from someone with an applications- > oriented perspective. What should matter, therefore, are the merits of > the review and not the body "authorizing" it. I think that's a laudable goal, but there are constant reminders that direc= torate reviews at least appear to carry more weight since their association= with authority (the ADs in particular) is difficult to obscure. Often I s= ee DISCUSSes posted based solely on the fact that a review team or director= ate did a review but it was not addressed. Further, those reviews are refe= renced in the DISCUSS as (for example) "the review done by Murray Kucherawy= of the Applications Directorate", rather than just by name. It's true that we're volunteers, but being appointed to the directorate doe= s mean someone thinks you're an expert at something. This paragraph of SM's message captures it better, I think, though I would = change the word "veto" to something else: The Applications Area Directors may or may not agree with the comments of t= he AppsDir reviewer. The Applications Area Directorate does not have any = veto power on a draft. It is suggested that the author(s) asks the document shepherd (RFC 4858) or the Area Director who sp= onsored the draft for guidance about IETF process, changes that should be m= ade, whether to post a new revision, etc. -MSK From julian.reschke@gmx.de Wed Apr 11 09:34: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 0208221F858E for ; Wed, 11 Apr 2012 09:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.386 X-Spam-Level: X-Spam-Status: No, score=-103.386 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDfDw0O3l8Ch for ; Wed, 11 Apr 2012 09:34:55 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D7AF921F84F3 for ; Wed, 11 Apr 2012 09:34:54 -0700 (PDT) Received: (qmail invoked by alias); 11 Apr 2012 16:34:53 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp069) with SMTP; 11 Apr 2012 18:34:53 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX187orpyMIg7zp1PupT7v3FFx+HLFApDN4FQUX80jJ nOFQQu7/8jI28N Message-ID: <4F85B2AD.9040801@gmx.de> Date: Wed, 11 Apr 2012 18:34:53 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ned Freed References: <20120330125228.15497.35035.idtracker@ietfa.amsl.com> <1271382236.20120330141948@pobox.com> <01ODS3YTKX1400ZUIL@mauve.mrochek.com> <4F8438C8.2070506@gmx.de> In-Reply-To: <4F8438C8.2070506@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps-Discusssion , Bill McQuillan Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:34:56 -0000 On 2012-04-10 15:42, Julian Reschke wrote: > On 2012-04-01 06:44, Ned Freed wrote: >> >>> RFC 2397 defaults media type of "data:" URIs to >>> text/plain;charset=US-ASCII. >> >>> Should this be updated to default to utf8? >> >> I'm not entirely sure of all the ramifications, but they are minimal this >> sound like a really good idea to me. > > There is one (IMHO) important erratum for 2397, and also it should be > updated to be based on RFC 3986. > > With respect to the encoding default, it would make sense to check what > current implementations do; if they indeed agree on UTF-8, it might make > sense to make that modification. (Does anybody happen to have a test case?) > ... So it appears that those UAs that do support text/plain data URIs all default to ISO-8859-1. Specifying UTF-8 instead probably wouldn't be helpful. Best regards, Julian From tony@att.com Wed Apr 11 09:41: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 6190B11E80A3 for ; Wed, 11 Apr 2012 09:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLP3-W7+CEBK for ; Wed, 11 Apr 2012 09:41:32 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 702F211E8089 for ; Wed, 11 Apr 2012 09:41:32 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id c34b58f4.0.1154284.00-306.3199051.nbfkord-smmo04.seg.att.com (envelope-from ); Wed, 11 Apr 2012 16:41:32 +0000 (UTC) X-MXL-Hash: 4f85b43c3b3068e6-d382b638a03255fdeec8f0dbcfe669db4dca9f49 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 q3BGfVCJ028612 for ; Wed, 11 Apr 2012 12:41:31 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3BGfQMi028580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Apr 2012 12:41:26 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Wed, 11 Apr 2012 12:41:07 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3BGf6PC020641 for ; Wed, 11 Apr 2012 12:41:06 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3BGf19b020286 for ; Wed, 11 Apr 2012 12:41:01 -0400 Received: from [135.91.110.244] (ds135-91-110-244.dhcps.ugn.att.com[135.91.110.244]) by maillennium.att.com (mailgw1) with ESMTP id <20120411163802gw1004or84e> (Authid: tony); Wed, 11 Apr 2012 16:38:02 +0000 X-Originating-IP: [135.91.110.244] Message-ID: <4F85B41C.1010004@att.com> Date: Wed, 11 Apr 2012 12:41:00 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> In-Reply-To: <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=p4QNoMogDYAA:10 a=vnNYxAp2wzwA:10 a=BlG6E5tz_8] X-AnalysisOut: [UA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1] X-AnalysisOut: [0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=oQMXLekNysl7CA7k7ZIA:9 a] X-AnalysisOut: [=LyPr6f2XGSM0gIZA7CcA:7 a=wPNLvfGTeEIA:10] Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:41:33 -0000 Sometimes wikipedia actually has useful information. :-) From the wikipedia entry for EXI: "An advantage of EXI over Fast Infoset is that EXI (optionally) uses more constraints from the XML schema. This can make the EXI data more compact; for example, if the XML schema specifies that elements named 'bar' may only exist within elements named 'foo', EXI can assign a shorter token to the 'bar' element, knowing that it doesn't have to share the same token space as elements that occur elsewhere in the document. "The main disadvantage is that to take advantage of this "schema-informed" compression, not only does the document require a schema, but the decoder needs a copy of the same schema that the encoder used." This supports Ned's comment that +exi might not be viable. Tony Hansen On 4/11/2012 11:57 AM, Ned Freed wrote: >> If decoding requires additional information, than IMHO you can't use >> HTTP's Content-Coding or Transfer-Encoding. By all means, if you think >> otherwise then send feedback to the HTTPbis WG. > > Julian is 100% correct here. If EXI requires knowledge of the type > itself, it's > not a separable encoding, which is what Content-Coding, > Transfer-Encoding, and > Content-Transfer-Encoding all require. And while I suppose we could > adopt the > foo+exi approach, having an explosion of encodings is a really bad idea. > > And if this is the case, it really isn't suitable for a +exi suffix > either. > +exi is supposed to mean the format can at least be parsed, > independent of any > knowledge of the type semantics. This is why I support the idea of > having +ber > and +der but not +per - with +per you have to know the ASN.1 schema in > order to > parse the material properly. > > For better or worse, we don't currently have a place in the > architecture for > these entities. We could define some other sort of type naming > convention if > there's really a need for it, but adding additional out of band > information > that has to be processed in order to interpret the material correctly > is rather > obviously highly problematic. From carine@jay.w3.org Wed Apr 11 09:44: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 CB86811E8098 for ; Wed, 11 Apr 2012 09:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Oh8Ves01dG9 for ; Wed, 11 Apr 2012 09:44:51 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3CA11E8089 for ; Wed, 11 Apr 2012 09:44:51 -0700 (PDT) Received: from carine by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1SI0f2-0001Pi-0L; Wed, 11 Apr 2012 12:44:48 -0400 Date: Wed, 11 Apr 2012 12:44:48 -0400 From: Carine Bournez To: Carsten Bormann Message-ID: <20120411164447.GA24351@jay.w3.org> References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:44:51 -0000 On Wed, Apr 11, 2012 at 02:04:05PM +0200, Carsten Bormann wrote: > Let me try to translate this into language pertaining to the discussion at hand: > > EXI can be used as a content-coding for XML documents in "Built-In" mode. > This would be the usage for the "Content-Encoding: EXI" that has been registered. > > EXI requires out of band information to use the "Schema-Informed" mode. Not necessarily, see below. > In the Internet, This would normally be provided in an Internet media-type definition. > The media-type definition may also want to constrain the allowable values for the numerous options EXI provides, allowing for constrained implementations of EXI. > > No existing application/foo+xml media type provides the latter kind of information. > With Content-Encoding: EXI, they are therefore limited to "Built-In" mode. > Any application that needs a tailored, schema-informed version of EXI should therefore register one or more application/foo+exi media types. If you use the content-encoding and the original media type, let's say svg, then the schema is the svg schema. There is absolutely no issue in that case. If foo has an application/foo media type for which the schema is known, the application readily knows which schema to use when receiving the EXI stream with the content-encoding header. > The next thing we should do is write down a template for all the information that needs to be nailed down in an application/foo+exi media type registration. I don't think that a +exi system will provide a better solution for the Web. -- Carine Bournez -+- W3C Europe From leifj@sunet.se Wed Apr 11 12:14: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 BB3EA21F84EB; Wed, 11 Apr 2012 12:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1XpBatxQv3B; Wed, 11 Apr 2012 12:14:49 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id B258B21F84D9; Wed, 11 Apr 2012 12:14:48 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q3BJEfBY007765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 21:14:44 +0200 (CEST) Message-ID: <4F85D81F.4010901@sunet.se> Date: Wed, 11 Apr 2012 21:14:39 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ted Hardie References: <4F8182D7.1030106@sunet.se> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-johansson-loa-registry.all@tools.ietf.org, IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Reivew of draft-johansson-loa-registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 19:14:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> Would an informational URL of >>>> mailto:loa-registrant@example.org be acceptable? >>>> > > Ah yes. Good catch! > > >> Just to confirm, you plan to add a list? yep -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+F2BsACgkQ8Jx8FtbMZnez+ACghTRcI5fRnvtFaoE5KycJVhwX GdYAoMB+11OHyLwCr2j1uBezWLPEJogU =E1gr -----END PGP SIGNATURE----- From zach@sensinode.com Wed Apr 11 12:26:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1552E11E80BB for ; Wed, 11 Apr 2012 12:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7AaAVYCLEZt for ; Wed, 11 Apr 2012 12:26:18 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id EA6D911E80B3 for ; Wed, 11 Apr 2012 12:26:17 -0700 (PDT) Received: from [192.168.1.102] (87-93-36-61.bb.dnainternet.fi [87.93.36.61]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3BJQBsk006518; Wed, 11 Apr 2012 22:26:13 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> Date: Wed, 11 Apr 2012 22:26:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <937A7D71-423A-4678-83A3-5704B125B744@sensinode.com> References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1084) Cc: Julian Reschke , apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:26:19 -0000 Ned, On Apr 11, 2012, at 6:57 PM, Ned Freed wrote: >> If decoding requires additional information, than IMHO you can't use >> HTTP's Content-Coding or Transfer-Encoding. By all means, if you = think >> otherwise then send feedback to the HTTPbis WG. >=20 > Julian is 100% correct here. If EXI requires knowledge of the type = itself, it's > not a separable encoding, which is what Content-Coding, = Transfer-Encoding, and > Content-Transfer-Encoding all require. And while I suppose we could = adopt the > foo+exi approach, having an explosion of encodings is a really bad = idea. >=20 > And if this is the case, it really isn't suitable for a +exi suffix = either. > +exi is supposed to mean the format can at least be parsed, = independent of any > knowledge of the type semantics. This is why I support the idea of = having +ber > and +der but not +per - with +per you have to know the ASN.1 schema in = order to > parse the material properly. >=20 > For better or worse, we don't currently have a place in the = architecture for > these entities. We could define some other sort of type naming = convention if > there's really a need for it, but adding additional out of band = information > that has to be processed in order to interpret the material correctly = is rather > obviously highly problematic. I agree with your analysis in general. Luckily the situation with EXI = schema-informed mode is not as bad as with PER. We actually do have a = schemaID field in the EXI header where some indication about the OOB = schema information can be included. The standard itself however doesn't = specify how to use that field. It is really a documentation problem = we're trying to solve, where the application/foo+exi registration = includes the definition of how to interpret the schemaID field of the = EXI header.=20 Let me use SenML as a practical example. Here draft-jennings-senml-08 = defines a schema for use with the EXI serialization (version 1 of the = markup). In the application/senml+exi IANA registration, I would = indicate that in the absence of the schemaID field the schema is by = default version 1 of SenML. For future versions, the integer of the = SenML version is to be included in the schemaID field. This way a single = senml+exi registration can handle this, and all future versions of the = SenML markup. =20 Zach=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From cabo@tzi.org Wed Apr 11 13:43: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 DCBCC11E80B8 for ; Wed, 11 Apr 2012 13:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpuNlhYVitne for ; Wed, 11 Apr 2012 13:43:20 -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 0B34011E8075 for ; Wed, 11 Apr 2012 13:43:16 -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 q3BKh8hG001148; Wed, 11 Apr 2012 22:43:08 +0200 (CEST) Received: from [192.168.217.105] (p5489ADE7.dip.t-dialin.net [84.137.173.231]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 468FE59D; Wed, 11 Apr 2012 22:43:08 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <20120411164447.GA24351@jay.w3.org> Date: Wed, 11 Apr 2012 22:43:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4DDB792A-4154-4C7B-A3EC-82573FE20D3E@tzi.org> References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <20120411164447.GA24351@jay.w3.org> To: Carine Bournez X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 20:43:21 -0000 On Apr 11, 2012, at 18:44, Carine Bournez wrote: > If you use the content-encoding and the original media type, let's say = svg, > then the schema is the svg schema. There is absolutely no issue in = that case. > If foo has an application/foo media type for which the schema is = known,=20 > the application readily knows which schema to use when receiving the = EXI > stream with the content-encoding header. Ah, SVG actually is a great example for why I think there need to be = separate +exi registrations. So, for image/svg+xml (see http://www.w3.org/TR/SVG/mimereg.html), what = is "the SVG schema"? What values of schemaId are defined, and what do they point to? What about "application/svg+xml"? =93application/vnd.oipf.dae.svg+xml=94?= Gr=FC=DFe, Carsten From Claudio.Allocchio@garr.it Wed Apr 11 13:53: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 BD0A711E80D0; Wed, 11 Apr 2012 13:53:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWtV5QAupyos; Wed, 11 Apr 2012 13:53:22 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 57C9E11E80B8; Wed, 11 Apr 2012 13:53:19 -0700 (PDT) Received: from webcam1-all.garrtest.units.it (webcam1-all.garrtest.units.it [140.105.201.5]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q3BKqmqu074623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 22:52:50 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q3BKqmqu074623 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=jm20gW1AIwV0vqBfA3N1D6n3XThnuWUBXbIdS1YpFsRRYY1FVIQInDEi+H72HtHcK m767Ll6b+y9oxr+2PQLvnZt0PgdVpv0jdc0ENwFi09Cq9LLNDEAwCCiTK9XxaLG+Suq Xn+OtakCd4MdOJ0YxMuZBA+5qk9O56L3ahyBSaM= Date: Wed, 11 Apr 2012 22:52:47 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@webcam1-all.garrtest.units.it To: dcrocker@bbiw.net In-Reply-To: <4F85A5B5.4030202@dcrocker.net> Message-ID: References: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> <4F85A5B5.4030202@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 Cc: appsdir@ietf.org, S Moonesamy , apps-discuss@ietf.org Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 20:53:23 -0000 On Wed, 11 Apr 2012, Dave Crocker wrote: > > > On 4/11/2012 2:25 AM, S Moonesamy wrote: >> >> In plain English, this means that the comments in the review does not bear more >> weight than a comment submitted by an individual during a Last Call. > > > SM, > > It might be worth adding simple language like this to our material, including > the apps area review team web page AND the template. > > The essence of directorate-based reviews is perspective, not authority. > > In our case, it supplies a review from someone with an applications-oriented > perspective. What should matter, therefore, are the merits of the review and > not the body "authorizing" it. +1 I write (in private) exactly the same idea this morning, and as I seem not to be alone with it, it might be a good idea! > > 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@elandsys.com Wed Apr 11 13:53: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 6EE7911E80DC; Wed, 11 Apr 2012 13:53:47 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhh0OxfLZewy; Wed, 11 Apr 2012 13:53:45 -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 74CA211E80B8; Wed, 11 Apr 2012 13:53:45 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.247]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3BKqrjx025521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 13:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334177599; i=@elandsys.com; bh=59G4Hn8OCDTkYtV6akLMF2EFI7LCKGkVIzSohBV2624=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1b5dYGZZ/awZL0cxUySxlWHQJA1ovsKuAXdZd2vB2d/MKul/bJc8AhrKG9XNDah1H MeJJ4ozp23v41EGvqZZMbqUOKT6Vk2nj9+ZPgRdJk72SyM/ErrBMLovQ7EKjP09Dit EaxNZ0Vd4pG2QVCy545aQZrXOq1/OlZTUttVffNo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334177599; i=@elandsys.com; bh=59G4Hn8OCDTkYtV6akLMF2EFI7LCKGkVIzSohBV2624=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YJM0AnaROLCEMizmtI14BTl0ins/Vjt4Zhw+A1BQLxdXM761QDBf/1Kuu/TOSE58o pzfF/v7OFcZfjmtnlx6ij7BaUOKjfuSsxWy1vC7E27ZVEPAsArOlnlOD6D13msRzXl qu3xLjE/gU/TGXdaCoJopZXOYFTu4RsxtWhYl5e0= Message-Id: <6.2.5.6.2.20120411102722.08f818f8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Apr 2012 13:47:03 -0700 To: dcrocker@bbiw.net, "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: <4F85A5B5.4030202@dcrocker.net> References: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> <4F85A5B5.4030202@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: appsdir@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 20:53:47 -0000 At 08:39 11-04-2012, Dave Crocker wrote: >It might be worth adding simple language like this to our material, including >the apps area review team web page AND the template. I'll add it the AppsDir Wiki. >The essence of directorate-based reviews is perspective, not authority. > >In our case, it supplies a review from someone with an applications-oriented >perspective. What should matter, therefore, are the merits of the review and >not the body "authorizing" it. Yes. At 09:27 11-04-2012, Murray S. Kucherawy wrote: >I think that's a laudable goal, but there are constant reminders >that directorate reviews at least appear to carry more weight since >their association with authority (the ADs in The guidance at http://trac.tools.ietf.org/area/app/trac/wiki/AppsDirReview says: "What to Look For The most important item is to give the Apps ADs a sense of how important it is that they pay attention to the document." That applies for reviews performed by the Application Area Directorate. > particular) is difficult to obscure. Often I see DISCUSSes posted > based solely on the > fact that a review team or directorate did a review but it was not > addressed. Further, those reviews are referenced in the DISCUSS as > (for example) "the review done by Murray Kucherawy of the > Applications Directorate", rather than just by name. If someone from a review team or directorate did a review, it is likely because some AD sees a benefit is getting their perspective. If the issues pointed out in the review have not been addressed and an AD thinks that it is worthy of a DISCUSS, it is within their prerogative to do so. Maybe the "Applications Directorate" part was added to acknowledge the effort. >It's true that we're volunteers, but being appointed to the >directorate does mean someone thinks you're an expert at something. If a person joins the directorate, it means: (a) that the person will perform document reviews as requested by the Application Area Directors. (b) that the person implicitly acknowledges that he can comment on a particular subject and provide relevant technical arguments. As the reviews are posted to an IETF mailing list which is open to everyone who cares to join it, the community can assess the expertise of the person (see point (b)). If a person are still on the Application Area Directorate, it means: (i) that the person can still commit your time to perform document reviews as requested by the Application Area Directors. (ii) Someone thinks that the person have contributed the expertise and experience he said he had through AppsDir reviews. >This paragraph of SM's message captures it better, I think, though I >would change the word "veto" to something else: I chose "veto" instead of an euphemism so that the reader does not have to second-guess what I meant. Regards, S. Moonesamy From msk@cloudmark.com Wed Apr 11 14: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 EAC3121F84CD for ; Wed, 11 Apr 2012 14:33:35 -0700 (PDT) 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.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZmWo9N8kGmr for ; Wed, 11 Apr 2012 14:33:35 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5195421F84BD for ; Wed, 11 Apr 2012 14:33:35 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id wlZ21i0010ZaKgw01lZ2oS; Wed, 11 Apr 2012 14:33:02 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=JPe5Qr2b c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=yxIi0zTuf70A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=wPPvXI8NAAAA:8 a=k7Ga1wGzAAAA:8 a=48vgC7mUAAAA:8 a=KNXWKSl9tpG3gR-WX3EA:9 a=CjuIK1q_8ugA:10 a=pOcSzP0BEVkA:10 a=fcAx7uNQz4EA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Wed, 11 Apr 2012 14:12:07 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" , "appsdir@ietf.org" Thread-Topic: [appsdir] Responding to Applications Area Directorate reviews Thread-Index: AQHNGCZUJ9imLJvYjE2nZmT/izqMDZaWHK9g Date: Wed, 11 Apr 2012 21:12:07 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D3BE0@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> <4F85A5B5.4030202@dcrocker.net> <6.2.5.6.2.20120411102722.08f818f8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120411102722.08f818f8@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334179982; bh=fAkHrrhO57e8MMP/SMSGme9FaYPxld/cd0V9qnnSNu4=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=nB+kOrGJ1XLHu8nZWzIybHq7IuCmuoaU9LHWYVDN547pj3HVKt8556HzHROqB4J8w sldK5EfpLfD0XsFmBlPXMKWpuoP55kcfJeJqdeLVvfSKgBlmRwq9FZ7ddmNbPTKwaY +kti+7LhcSJgAXQcJb7DXcDdQpph9YpYo5I+PSGQ= Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 21:33:36 -0000 > -----Original Message----- > From: S Moonesamy [mailto:sm+ietf@elandsys.com] > Sent: Wednesday, April 11, 2012 1:47 PM > To: dcrocker@bbiw.net; Murray S. Kucherawy > Cc: apps-discuss@ietf.org; appsdir@ietf.org > Subject: Re: [appsdir] Responding to Applications Area Directorate review= s >=20 > If someone from a review team or directorate did a review, it is likely > because some AD sees a benefit is getting their perspective. If the > issues pointed out in the review have not been addressed and an AD > thinks that it is worthy of a DISCUSS, it is within their prerogative > to do so. > [...] I think most of what you said is geared toward those of us that are already= part of AppsDir. I'm talking from the perspective of people who receive t= hese reviews, especially those of us less familiar with the process. And from my own experience as an author, for reasons I mentioned earlier, i= t certainly seems as if directorate reviews get more attention than individ= ual ones even though we disclaim that in the boilerplate at the top. -MSK From cabo@tzi.org Wed Apr 11 14:42: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 74DF111E80E9; Wed, 11 Apr 2012 14:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.459 X-Spam-Level: X-Spam-Status: No, score=-106.459 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MyXDf26pBlP; Wed, 11 Apr 2012 14:42:48 -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 93DA311E80DC; Wed, 11 Apr 2012 14:42:42 -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 q3BLgVra022470; Wed, 11 Apr 2012 23:42:32 +0200 (CEST) Received: from [192.168.217.105] (p5489ADE7.dip.t-dialin.net [84.137.173.231]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A557D5BB; Wed, 11 Apr 2012 23:42:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <9452079D1A51524AA5749AD23E0039280D3BE0@exch-mbx901.corp.cloudmark.com> Date: Wed, 11 Apr 2012 23:42:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <70570E58-94E5-4BDF-A6F0-A358EB9893BE@tzi.org> References: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> <4F85A5B5.4030202@dcrocker.net> <6.2.5.6.2.20120411102722.08f818f8@elandnews.com> <9452079D1A51524AA5749AD23E0039280D3BE0@exch-mbx901.corp.cloudmark.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1257) Cc: "appsdir@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 21:42:49 -0000 On Apr 11, 2012, at 23:12, Murray S. Kucherawy wrote: > And from my own experience as an author, for reasons I mentioned = earlier, it certainly seems as if directorate reviews get more attention = than individual ones even though we disclaim that in the boilerplate at = the top. And, like for any kind of cross-area review they *should* get good = attention, please! So the de-facto status is not a bug, but a feature. We should just make sure to make very clear that there is no formal = status, so the WG is as free to process (as, in, heed or discard) advice = as for any other kind of more or less informed advice, including direct = advice from an AD outside the formal ballot process. Gr=FC=DFe, Carsten From msk@cloudmark.com Wed Apr 11 14:46: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 8B00711E80EC for ; Wed, 11 Apr 2012 14:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VgZP877rIfk for ; Wed, 11 Apr 2012 14:46:09 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 08FD211E80E9 for ; Wed, 11 Apr 2012 14:46:09 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id wlmC1i0010as01C01lmCvn; Wed, 11 Apr 2012 14:46:12 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=HuX06jvS c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=OsLRAgjgfhMA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=gKmFwSsBAAAA:8 a=48vgC7mUAAAA:8 a=FrfPsi_zrIV_dJQZYlcA:9 a=CjuIK1q_8ugA:10 a=ACBgD4iW9t8A:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Wed, 11 Apr 2012 14:45:56 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" , "appsdir@ietf.org" Thread-Topic: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews Thread-Index: AQHNGCwGK8fP/yHK7kGlotQbk297PZaWKFOQ Date: Wed, 11 Apr 2012 21:45:55 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D3CF3@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> <4F85A5B5.4030202@dcrocker.net> <6.2.5.6.2.20120411102722.08f818f8@elandnews.com> <9452079D1A51524AA5749AD23E0039280D3BE0@exch-mbx901.corp.cloudmark.com> <70570E58-94E5-4BDF-A6F0-A358EB9893BE@tzi.org> In-Reply-To: <70570E58-94E5-4BDF-A6F0-A358EB9893BE@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334180772; bh=L3GklM8EdHtt4lk8Mjs8i8S8BCwEAEQDppKZ7Oal8VA=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=u1cGD8Xasgm8cnTQaMRbD58TexXECdAtu5mjiziZCa3QnpqHnBEvJeQsq9zdahSd6 /Q3UWJqcALWG73EH+uKCWVGExMSugW5IB3Tnqc5V6jCJUOc6T4i4sHiPGC9VJCBVho /ywcUHp4pqWM6fM1YKawSxbUhiU3apmHH9HlLZDI= Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2012 21:46:09 -0000 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Wednesday, April 11, 2012 2:43 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org; appsdir@ietf.org > Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Dir= ectorate reviews >=20 > And, like for any kind of cross-area review they *should* get good attent= ion, please! > So the de-facto status is not a bug, but a feature. I totally agree. I just don't want us to go too far claiming they won't ge= t special attention when they often do. It seems misleading at best. -MSK From dhc@dcrocker.net Wed Apr 11 15:02: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 0DBF811E80DB; Wed, 11 Apr 2012 15:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzLYQXV31mbt; Wed, 11 Apr 2012 15:02:06 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECF411E80CC; Wed, 11 Apr 2012 15:02:06 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3BM1eME007159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 15:01:44 -0700 Message-ID: <4F85FF41.4060502@dcrocker.net> Date: Wed, 11 Apr 2012 15:01:37 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> <4F85A5B5.4030202@dcrocker.net> <9452079D1A51524AA5749AD23E0039280D3639@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280D3639@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 11 Apr 2012 15:01:44 -0700 (PDT) Cc: "appsdir@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews 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: Wed, 11 Apr 2012 22:02:07 -0000 On 4/11/2012 9:27 AM, Murray S. Kucherawy wrote: > I think that's a laudable goal, but there are constant reminders that > directorate reviews at least appear to carry more weight since their > association with authority (the ADs in particular) is difficult to obscure. > Often I see DISCUSSes posted based solely on the fact that a review team or > directorate did a review but it was not addressed. Further, those reviews > are referenced in the DISCUSS as (for example) "the review done by Murray > Kucherawy of the Applications Directorate", rather than just by name. ... On 4/11/2012 2:12 PM, Murray S. Kucherawy wrote: > And from my own experience as an author, for reasons I mentioned earlier, it > certainly seems as if directorate reviews get more attention than individual > ones even though we disclaim that in the boilerplate at the top. Note that when an IAB person speaks in a working group, the fact of their affiliation does weight heavily in psychological terms, but they have no /formal/ status in the wg. I think the same applies here. Yes, it's "notable" that the review is from a directorate, but the formal status is that it's just another review. That some folk like ADs pay special attention might well be true, but it might be good and it might be problematic. It's a separable issue that's their own choice and not a de jure formality. Those of us writing and pursuing our reviews need to keep in mind that the formal status is that it has not formal status. The review is our personal comments. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From cabo@tzi.org Wed Apr 11 16: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 AD7CF11E80FA for ; Wed, 11 Apr 2012 16:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.44 X-Spam-Level: X-Spam-Status: No, score=-106.44 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpcSLtE-iIAn for ; Wed, 11 Apr 2012 16:05:54 -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 0066F11E80EA for ; Wed, 11 Apr 2012 16:05:53 -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 q3BN5kXT018432; Thu, 12 Apr 2012 01:05:46 +0200 (CEST) Received: from [192.168.217.105] (p5489ADE7.dip.t-dialin.net [84.137.173.231]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8DBC65C4; Thu, 12 Apr 2012 01:05:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> Date: Thu, 12 Apr 2012 01:05:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 23:05:54 -0000 On Apr 11, 2012, at 17:57, Ned Freed wrote: > And if this is the case, it really isn't suitable for a +exi suffix = either. > +exi is supposed to mean the format can at least be parsed, = independent of any > knowledge of the type semantics. This is why I support the idea of = having +ber > and +der but not +per - with +per you have to know the ASN.1 schema in = order to > parse the material properly. So how would you handle the PERs and (schema-informed) EXIs of this = world? Should it be -exi, not +exi? (As in application/senml-exi?) (Again, the media type registration will do a lot more than just tack = EXI encoding on existing XML.) Gr=FC=DFe, Carsten From sm@elandsys.com Wed Apr 11 17:55: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 8BD4F21F84A2; Wed, 11 Apr 2012 17:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4i4NnZmoInYJ; Wed, 11 Apr 2012 17:55:51 -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 9E59221F849A; Wed, 11 Apr 2012 17:55:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.167]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3C0tbHq012613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 17:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334192150; i=@elandsys.com; bh=mijIYluSYmT1h06+xM01v94wMRq/mbRrVCaCM8zWEw4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=QVcxp0MgGH3DiXHZKOrvu2yKq3lInOx74ZqI0XoosihsYmgFGkol30UHAwv1YuTua pu0chEsO9eUjdp1GcQHIhWMcWZgRU1YoktOgU/Fokycuz11S5XPnTDW9n4jQqT6Com BZb3sw0TxXVHd0eO8bL0AfV6fQZMpf3O7caHZ33o= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334192150; i=@elandsys.com; bh=mijIYluSYmT1h06+xM01v94wMRq/mbRrVCaCM8zWEw4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=XB2tZ8CRVUhwVOKSt+Qp1ssh0LRZy+atdzrXd6xA+egH6AGvT6dCE83feuw91+N50 Ood36YotinD8H3FMR/c+UWKiaKIVMZbjhiGpm9nHfAkogTnQInbg0GYVJ61iSyaQk/ sBbq2h2iAuHUpO4dkosMQ5n7M+myqCt3o3t75hLg= Message-Id: <6.2.5.6.2.20120411145300.0737c1c0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Apr 2012 17:34:36 -0700 To: apps-discuss@ietf.org, appsdir@ietf.org From: S Moonesamy In-Reply-To: <9452079D1A51524AA5749AD23E0039280D3BE0@exch-mbx901.corp.cl oudmark.com> References: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> <4F85A5B5.4030202@dcrocker.net> <6.2.5.6.2.20120411102722.08f818f8@elandnews.com> <9452079D1A51524AA5749AD23E0039280D3BE0@exch-mbx901.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 00:55:55 -0000 Hi Murray, At 14:12 11-04-2012, Murray S. Kucherawy wrote: >And from my own experience as an author, for reasons I mentioned >earlier, it certainly seems as if directorate reviews get more >attention than individual ones even though we disclaim that in the >boilerplate at the top. I agree that directorate reviews get more attention. Dave commented on the psychological aspect. The candid answer is at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04899.html If the Apps ADs ask me about this matter, I will give them the same answer. If an author of a draft which has been reviewed by AppsDir considers the answer as inappropriate, I suggest that he/she files a complaint with the Apps ADs as that's a problem for them to address in any manner they wish. Regards, S. Moonesamy From paul.hoffman@vpnc.org Wed Apr 11 20:01: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 3C7ED11E8085 for ; Wed, 11 Apr 2012 20:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB-01ssVgcss for ; Wed, 11 Apr 2012 20:01:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A121A11E8075 for ; Wed, 11 Apr 2012 20:01:53 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3C31qm2053212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 11 Apr 2012 20:01:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Apr 2012 20:01:52 -0700 Message-Id: To: "apps-discuss@ietf.org Discuss" Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [apps-discuss] IETF LC for DANE X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 03:01:54 -0000 The TLSA protocol from the DANE WG has just entered IETF Last Call: = = This may be of particular interest to Apps folks because the protocol is = aimed at apps that use TLS, and expects them to do more than they are = doing now in exchange for a different (and presumably much better) = security model. Murray already did a bang-up job on his AppsDir review, = but more Last Call comments are welcome from everyone. --Paul Hoffman From stpeter@stpeter.im Wed Apr 11 20:59: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 CB3E611E80B2 for ; Wed, 11 Apr 2012 20:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxoTpOdLR9Qc for ; Wed, 11 Apr 2012 20:59:24 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5446711E80B1 for ; Wed, 11 Apr 2012 20:59:24 -0700 (PDT) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8E8E140058; Wed, 11 Apr 2012 22:13:16 -0600 (MDT) Message-ID: <4F865313.5040304@stpeter.im> Date: Wed, 11 Apr 2012 21:59:15 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] IETF LC for DANE X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 03:59:24 -0000 On 4/11/12 9:01 PM, Paul Hoffman wrote: > The TLSA protocol from the DANE WG has just entered IETF Last Call: > > > This may be of particular interest to Apps folks because the > protocol is aimed at apps that use TLS, and expects them to do more > than they are doing now in exchange for a different (and presumably > much better) security model. Murray already did a bang-up job on his > AppsDir review, but more Last Call comments are welcome from > everyone. Thanks for the heads-up. I know a few folks who plan to review it during Last Call, me included. :) Peter -- Peter Saint-Andre https://stpeter.im/ From dret@berkeley.edu Wed Apr 11 22:19: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 3959B21F85A1 for ; Wed, 11 Apr 2012 22:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDdwBhoV2B7P for ; Wed, 11 Apr 2012 22:19:35 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 9070021F85A0 for ; Wed, 11 Apr 2012 22:19:35 -0700 (PDT) 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 1SICRK-00027H-Cr; Wed, 11 Apr 2012 22:19:28 -0700 Message-ID: <4F8665E4.9050303@berkeley.edu> Date: Wed, 11 Apr 2012 22:19:32 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jan Algermissen References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> In-Reply-To: <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , "apps-discuss@ietf.org application-layer protocols" , REST Discuss Subject: Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 05:19:36 -0000 hello jan. On 2012-04-10 11:58 , Jan Algermissen wrote: > Likewise, what does that check for atompub capabilities buy you? The reason you check for them is that you assume they are there in the first place. If that check fails .... then what? You are in exactly the same situation as when you POST you atom entry right away and see what happens. the idea is to be able to check for the profile URI to see whether a feed i have discovered supports atompub or not. if it does, i might show an "upload" feature in a UI that otherwise i would not show. without the feed advertising its capabilities, i cannot know, and i certainly don't want to create a fake post to test whether atompub is supported or not. if all operations in atompub were exposed via links, it would be a different story in this particular case, but they are not, so a profile URI would be one way to go. and it's just one example and not the whole 'profile' story. 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 dret@berkeley.edu Wed Apr 11 22:36: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 C299921F85A5 for ; Wed, 11 Apr 2012 22:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7mBjgUTx7ul for ; Wed, 11 Apr 2012 22:36:18 -0700 (PDT) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1253421F8527 for ; Wed, 11 Apr 2012 22:36:18 -0700 (PDT) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.64]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1SIChb-0004cD-4p; Wed, 11 Apr 2012 22:36:16 -0700 Message-ID: <4F8669D4.7050401@berkeley.edu> Date: Wed, 11 Apr 2012 22:36:20 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Mark Nottingham References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org application-layer protocols" , REST Discuss Subject: Re: [apps-discuss] Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 05:36:18 -0000 hello mark. thanks for the comments! On 2012-04-10 8:56 , Mark Nottingham wrote: > On 06/04/2012, at 2:18 PM, Erik Wilde wrote: >> now i am little bit confused. taking your example, i am not concerned with the link relation that was used to discover 'foo' at all. all i am concerned with is that if i am retrieving 'foo' and i find a 'bar' profile identifier in the representation, i know that it follows constraints and conventions beyond the 'foo' media type. > Yup. good to see we're in basic agreement. >> one example i am currently considering adding is atompub. currently, when you retrieve a feed, there's no way to tell it's atompub-capable just by looking at it. > Well, what thing in this case is atom pub capable? The format that the links are occurring within, or the targets of the links themselves? I'd argue the latter. You can take that argument too far, of course, but generally I see profiles as describing format conventions, and link relations as describing behaviours of resources. Of course, some of those behaviours can be "produce this format" and some of the formatting conventions can be "link to something with this behaviour". with atompub i think you're right about 'edit' links in entries, so if i aggregate atompub-capable feeds, then my aggregate feed may not be atompub-capable, but the entries may very well be. but if my feed is indeed able to accept POST requests to create new entries, then there simply is no link to represent that fact, and a profile URI would be one way to represent that capability in the feed itself. while i see your point about profile more being about format conventions (this is where HTML started this idea, and in that case my podcast example might better fit your bill), i think eventually the line between format conventions and behavior is fuzzy. maybe the best way for me to go forward is to finish the examples section, and then we can start more concrete discussions whether this would be the kind of scenario we'd like to encourage for 'profile' links. 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 presnick@qualcomm.com Wed Apr 11 22:40: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 493C221F85B4 for ; Wed, 11 Apr 2012 22:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuzqrLjwyRF4 for ; Wed, 11 Apr 2012 22:40:45 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5804221F85B1 for ; Wed, 11 Apr 2012 22:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1334209245; x=1365745245; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F866AC0.3000603@qualcomm.com>|Date:=20Th u,=2012=20Apr=202012=2000:40:16=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Apps=20Discuss=20,=0D=0A=09|Subject:=20Reserved=20URI=20query=20parameter =20in=20draft-ietf-oauth-v2-bearer|Content-Type:=20text/p lain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=xFq+81AAClSaUJqsFDsI8sW2cDZdFGPhqnTDKTOM3eA=; b=r/PY6JjEg9/Yt5Jriqo+zVjtqK3URPMn+3WXBblVpHhZlxzyZuA3kAgy kOhPsP16t8eIpROt2cSJL8V4L8Upg5e213ltz95T14b/ojDIuvGHgjWaq el6UXZkzgYDCErhVS5ttLK/w68WumFDNL4PvUvQY0hC/uTIqOjKS/rRZX g=; X-IronPort-AV: E=McAfee;i="5400,1158,6677"; a="180932466" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 11 Apr 2012 22:40:44 -0700 X-IronPort-AV: E=Sophos;i="4.75,409,1330934400"; d="scan'208";a="195552509" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 11 Apr 2012 22:40:24 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 11 Apr 2012 22:40:18 -0700 Message-ID: <4F866AC0.3000603@qualcomm.com> Date: Thu, 12 Apr 2012 00:40:16 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Apps Discuss , Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 05:40:46 -0000 Folks, Mark mentioned to me that he did not think one major issue in his review of this document was fully addressed. I would like to get some feedback from other folks here on the Apps-discuss list as I cannot say myself that I fully understand the implications of the issue. Mike Jones wrote: > Mark Nottingham wrote: > >> * Section 2.3 URI Query Parameter >> >> This section effectively reserves a URI query parameter for the >> draft's use. This should not be done lightly, since this would be a >> precedent for the IETF encroaching upon a server's URIs (done >> previously in RFC5785, but in a much more limited fashion, as a >> tactic to prevent further, uncontrolled encroachment). >> >> Given that the draft already discourages the use of this mechanism, >> I'd recommend dropping it altogether. If the Working Group wishes it >> to remain, this issues should be vetted both through the APPS area >> and the W3C liaison. >> >> (The same criticism could be leveled at Section 2.2 Form-Encoded Body >> Parameter, but that at least isn't surfaced in an identifier) > > There are some contexts, especially limited browsers and/or > development environments, where query parameters are usable but the > other methods are not. Thus, the query parameter method must be > retained. Also, Justin Richter's comments describing the value to him > of the query parameter method are pertinent: A URL with all > parameters including authorization is a powerful artifact which can be > passed around between systems as a unit. > > As to using a standard parameter name, this is essential for > interoperability. It is not reserved in any contexts other than when > the Bearer spec is employed, which is a voluntary act by both > parties. Thus, this poses no undue burdens or namespace restrictions > on implementations in practice. > > Finally, you'll find that OAuth 1.0 [RFC 5849] similarly defined, not > one, but two standard query parameter values: oauth_token and > oauth_verifier. As this didn't cause any problems in practice then, > I'm sure that defining an access_token parameter within the Bearer > spec for interoperability purposes won't cause a problem either. Would anyone (including, but not limited to, Mark) be able to better explain the issue here? Thanks, pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From stephen.farrell@cs.tcd.ie Thu Apr 12 05:02: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 51C6E21F85A3; Thu, 12 Apr 2012 05:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVWCEWHgnza6; Thu, 12 Apr 2012 05:02:03 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C92B21F84B8; Thu, 12 Apr 2012 05:02:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 03CD317147D; Thu, 12 Apr 2012 13:02:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334232120; bh=0hhJx339BfR99P Ll1NZFG4gOklDtxqctzoHczcMrAe0=; b=K0lLb3kFAcvmUon0d8x3Gc4B1OGUGi fIERPG0yeqetw4LEPV6wkq3shTpu+CoByT13bpLLU6BTW3dar1iioTPHm3WOIWJt ufImCG631VXFFzcDzgG/AkbGO4TNx6tcIgqFnxiRoB/dXqGGGEIqMu0UrxCTR0E8 6sG8PWl1vV50pfJfU0WDU5ZwTieiHaDrvPaeWHZ3l53hmLCrvZuMbH76uuijFtUy oMvEZqGLxhXNjNMt/EcOfQ03sVvNkR2DD1UDWcIuSY9Qqv1bxOsMsm45M+Z8vUQm EGeEvoY6TFgtva9WJeWm0LeC9H0VRq2jDNgL9Uj8rxfQ9IwdYjUVJlPw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 1IXcjoiVrK-H; Thu, 12 Apr 2012 13:02:00 +0100 (IST) Received: from [10.87.48.3] (unknown [86.45.63.74]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 56A6117147C; Thu, 12 Apr 2012 13:02:00 +0100 (IST) Message-ID: <4F86C437.3000006@cs.tcd.ie> Date: Thu, 12 Apr 2012 13:01:59 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> In-Reply-To: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 12:02:04 -0000 On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: > Hi all, > > those who had attended the last IETF meeting may have noticed the ongoing activity in the 'Applications Area Working Group' regarding Web Finger. > We had our discussion regarding Simple Web Discovery (SWD) as part of the re-chartering process. > > Here are the two specifications: > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 > http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 > > Now, the questions that seems to be hanging around are > > 1) Aren't these two mechanisms solving pretty much the same problem? > 2) Do we need to have two standards for the same functionality? > 3) Do you guys have a position or comments regarding either one of them? > > Ciao > Hannes > > PS: Please also let me know if your view is: "I don't really know what all this is about and the documents actually don't provide enough requirements to make a reasonable judgement about the solution space." > So just as a data-point. We (the IETF, but including me personally;-) mucked up badly on this some years ago in the PKI space - we standardised both CMP (rfc 2510) and CMC (rfc 2797) as two ways to do the same thing, after a protracted battle between factions supporting one or the other. We even made sure they had as much common syntax as possible. (CRMF, rfc 2511) Result: neither fully adopted, lots of people still do proprietary stuff, neither can be killed off (despite attempts), both need to be maintained (CMP is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO partly as a result of us screwing up for what seemed like good reasons at the time, PKI administration stuff has never gotten beyond horrible-to-do. All-in-all, a really bad outcome which is still a PITA a dozen years later. As OAuth AD I will need *serious* convincing that there is a need to provide two ways to do the same thing. I doubt it'll be possible to convince me, in fact, so if you wanna try, you'll need to start by saying that they are not in fact two ways to do the same thing:-) S. PS: This discussion needs to also involve the Apps area, so I've cc'd that list. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Thu Apr 12 05:56: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 A854A21F8692 for ; Thu, 12 Apr 2012 05:56:22 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PhduYp403eo for ; Thu, 12 Apr 2012 05:56:20 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id B98F721F867F for ; Thu, 12 Apr 2012 05:56:20 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id x0wL1i0010EuLVk010wLl3; Thu, 12 Apr 2012 05:56:20 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Thu, 12 Apr 2012 05:56:20 -0700 From: Eran Hammer To: Pete Resnick , Apps Discuss , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" Thread-Topic: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer Thread-Index: AQHNGG7U0F8LwN3hVU263jHNydMVG5aXJLK6 Date: Thu, 12 Apr 2012 12:56:19 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net> References: <4F866AC0.3000603@qualcomm.com> In-Reply-To: <4F866AC0.3000603@qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.172.63.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 12:56:22 -0000 The issue is pretty simple. The OAuth bearer token specification defines an= HTTP Authorization header scheme. It also provides a "hack" for sending th= e same authentication credentials direction in the HTTP request URI. For ex= ample:=0A= =0A= http://example.com/protected/resource?access_token=3Dalskjdlaskjd=0A= =0A= This in practice claims the 'access_token' URI query parameter as a reseved= parameter name used by the bearer token specification. The reason is that = any future (or existing) implementation using this parameter name will now = be in conflict with the OAuth bearer token specification. We do not have a = mechanism for reserving URI query parameters - but in practice, this update= s RFC 3986 by taking ownership of the query parameter name.=0A= =0A= There were other voices on the OAuth WG to simply drop this mechanism but r= esistance from the authors and lack of strong consensus kept it in.=0A= =0A= I supported Mark's recommendation of dropping that mechanism.=0A= =0A= Hope this is helpful.=0A= =0A= EH=0A= =0A= ________________________________________=0A= From: apps-discuss-bounces@ietf.org [apps-discuss-bounces@ietf.org] on beha= lf of Pete Resnick [presnick@qualcomm.com]=0A= Sent: Wednesday, April 11, 2012 10:40 PM=0A= To: Apps Discuss; draft-ietf-oauth-v2-bearer.all@tools.ietf.org=0A= Subject: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2= -bearer=0A= =0A= Folks,=0A= =0A= Mark mentioned to me that he did not think one major issue in his review=0A= of this document was fully addressed. I would like to get some feedback=0A= from other folks here on the Apps-discuss list as I cannot say myself=0A= that I fully understand the implications of the issue.=0A= =0A= Mike Jones wrote:=0A= =0A= > Mark Nottingham wrote:=0A= >=0A= >> * Section 2.3 URI Query Parameter=0A= >>=0A= >> This section effectively reserves a URI query parameter for the=0A= >> draft's use. This should not be done lightly, since this would be a=0A= >> precedent for the IETF encroaching upon a server's URIs (done=0A= >> previously in RFC5785, but in a much more limited fashion, as a=0A= >> tactic to prevent further, uncontrolled encroachment).=0A= >>=0A= >> Given that the draft already discourages the use of this mechanism,=0A= >> I'd recommend dropping it altogether. If the Working Group wishes it=0A= >> to remain, this issues should be vetted both through the APPS area=0A= >> and the W3C liaison.=0A= >>=0A= >> (The same criticism could be leveled at Section 2.2 Form-Encoded Body=0A= >> Parameter, but that at least isn't surfaced in an identifier)=0A= >=0A= > There are some contexts, especially limited browsers and/or=0A= > development environments, where query parameters are usable but the=0A= > other methods are not. Thus, the query parameter method must be=0A= > retained. Also, Justin Richter's comments describing the value to him=0A= > of the query parameter method are pertinent: A URL with all=0A= > parameters including authorization is a powerful artifact which can be=0A= > passed around between systems as a unit.=0A= >=0A= > As to using a standard parameter name, this is essential for=0A= > interoperability. It is not reserved in any contexts other than when=0A= > the Bearer spec is employed, which is a voluntary act by both=0A= > parties. Thus, this poses no undue burdens or namespace restrictions=0A= > on implementations in practice.=0A= >=0A= > Finally, you'll find that OAuth 1.0 [RFC 5849] similarly defined, not=0A= > one, but two standard query parameter values: oauth_token and=0A= > oauth_verifier. As this didn't cause any problems in practice then,=0A= > I'm sure that defining an access_token parameter within the Bearer=0A= > spec for interoperability purposes won't cause a problem either.=0A= =0A= Would anyone (including, but not limited to, Mark) be able to better=0A= explain the issue here?=0A= =0A= Thanks,=0A= =0A= pr=0A= =0A= --=0A= Pete Resnick=0A= Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102=0A= =0A= _______________________________________________=0A= apps-discuss mailing list=0A= apps-discuss@ietf.org=0A= https://www.ietf.org/mailman/listinfo/apps-discuss=0A= From julian.reschke@gmx.de Thu Apr 12 06:09: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 1026121F856C for ; Thu, 12 Apr 2012 06:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.053 X-Spam-Level: X-Spam-Status: No, score=-103.053 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLGYLlrYxNPq for ; Thu, 12 Apr 2012 06:09:15 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0D02A21F854E for ; Thu, 12 Apr 2012 06:09:14 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2012 13:09:13 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp036) with SMTP; 12 Apr 2012 15:09:13 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+X+UxJ7OKX5XQhT54Q02s03gTb4Y1svNYghzJqhs Z2RMvE3Q5PG7bS Message-ID: <4F86D3F5.9020802@gmx.de> Date: Thu, 12 Apr 2012 15:09:09 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Eran Hammer References: <4F866AC0.3000603@qualcomm.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Pete Resnick , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 13:09:16 -0000 On 2012-04-12 14:56, Eran Hammer wrote: > The issue is pretty simple. The OAuth bearer token specification defines an HTTP Authorization header scheme. It also provides a "hack" for sending the same authentication credentials direction in the HTTP request URI. For example: > > http://example.com/protected/resource?access_token=alskjdlaskjd > > This in practice claims the 'access_token' URI query parameter as a reseved parameter name used by the bearer token specification. The reason is that any future (or existing) implementation using this parameter name will now be in conflict with the OAuth bearer token specification. We do not have a mechanism for reserving URI query parameters - but in practice, this updates RFC 3986 by taking ownership of the query parameter name. > > There were other voices on the OAuth WG to simply drop this mechanism but resistance from the authors and lack of strong consensus kept it in. > > I supported Mark's recommendation of dropping that mechanism. > > Hope this is helpful. > > EH > ... It is. Right now the spec describes the two fallback methods and the auth scheme side-by side. Maybe it should be reorganized so that is only mentions the query-parameter and form-based schemes as workarounds in an appendix, so that it becomes clearer that when you use those, you're *not* doing HTTP Bearer authentication? Best regards, Julian From julian.reschke@gmx.de Thu Apr 12 07:10: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 18A0221F859A for ; Thu, 12 Apr 2012 07:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.779 X-Spam-Level: X-Spam-Status: No, score=-102.779 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJNa1bJ-GqD0 for ; Thu, 12 Apr 2012 07:10:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A140321F856C for ; Thu, 12 Apr 2012 07:10:37 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2012 14:10:34 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp072) with SMTP; 12 Apr 2012 16:10:34 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+ONR0QgUmOdS7eI93b2DSho6H9Gwfv/Tja50RX1l T88d0B/UE6rMPj Message-ID: <4F86E258.3040409@gmx.de> Date: Thu, 12 Apr 2012 16:10:32 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> <4F68B37E.9060608@gmx.de> <1332262482.2171.11.camel@neutron> <4F68BDB7.7030808@gmx.de> <1332269074.2171.21.camel@neutron> <4F68D295.2040401@gmx.de> <1332277294.2171.25.camel@neutron> <4F68F2F8.7000207@gmx.de> <9452079D1A51524AA5749AD23E0039280949C7@exch-mbx901.corp.cloudmark.com> <4F697B48.1050305@it.aoyama.ac.jp> <4F699B49.1010108@gmx.de> In-Reply-To: <4F699B49.1010108@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 14:10:39 -0000 On 2012-03-21 10:11, Julian Reschke wrote: > On 2012-03-21 07:55, "Martin J. Dürst" wrote: >> On 2012/03/21 6:40, Murray S. Kucherawy wrote: >> >>> Does there need to be one-and-only-one? >> >> In theory, not necessarily. In practice, not having a lot of variation >> usually helps. >> >>> Or I guess more accurately, do we need to say this is the one and only >>> way to do this? Seems like that closes the door to someone coming up >>> with a better idea. >> >> Fragment pointers into datastructures such as JSON isn't exactly a brand >> new field with lots of new possibilities. And XPointer has shown that >> making it too complicated cuts out most implementations. My proposal >> would be to somehow include an extensibility hatch, but then say this is >> the one and only one. > > In XML, as far as I understand, the escape hatch is that identifiers do > not allow brackets, and thus these are free for defining new addressing > schemes. So in JSON Pointer, we'd need to escape a few more characters > when using in fragment identifiers. > > Also, it seems this needs to be coordinated with a potential spec > defining a "+json" media type suffix... > ... It would be good if we made up our minds whether we are defining a fragment identifier syntax for application/json or not. My proposal is to keep things simple for now and thus not to do it; that implies removing or clarifying the examples in the spec. Best regards, Julian From mnot@mnot.net Thu Apr 12 07:12: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 B313921F853C for ; Thu, 12 Apr 2012 07:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=-3.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0vfeMBEA26n for ; Thu, 12 Apr 2012 07:12:27 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2A221F8535 for ; Thu, 12 Apr 2012 07:12:27 -0700 (PDT) Received: from [10.6.129.16] (unknown [50.56.228.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E35AE22E253; Thu, 12 Apr 2012 10:12:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: <4F86E258.3040409@gmx.de> Date: Thu, 12 Apr 2012 09:12:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> <4F68B37E.9060608@gmx.de> <1332262482.2171.11.camel@neutron> <4F68BDB7.7030808@gmx.de> <1332269074.2171.21.camel@neutron> <4F68D295.2040401@gmx.de> <1332277294.2171.25.camel@neutron> <4F68F2F8.7000207@gmx.de> <9452079D1A51524AA5749AD23E0039280949C7@exch-mbx901.corp.cloudmark.com> <4F697B48.1050305@it.aoyama.ac.jp> <4F699B49.1010108@gmx.de> <4F86E258.3040409@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 14:12:27 -0000 On 12/04/2012, at 9:10 AM, Julian Reschke wrote: > It would be good if we made up our minds whether we are defining a = fragment identifier syntax for application/json or not. >=20 > My proposal is to keep things simple for now and thus not to do it; = that implies removing or clarifying the examples in the spec. +1 -- Mark Nottingham http://www.mnot.net/ From jan.algermissen@nordsc.com Thu Apr 12 00:12: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 652F121F8473 for ; Thu, 12 Apr 2012 00:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwRSfJVhKQE5 for ; Thu, 12 Apr 2012 00:12:23 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9400A21F84B2 for ; Thu, 12 Apr 2012 00:12:23 -0700 (PDT) Received: from [192.168.2.103] (p548FB5B7.dip.t-dialin.net [84.143.181.183]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MJF5W-1SJt9r34Cg-002lHE; Thu, 12 Apr 2012 09:12:13 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: <4F8665E4.9050303@berkeley.edu> Date: Thu, 12 Apr 2012 09:12:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5006D354-A78D-4347-A3D1-0ED840BD81ED@nordsc.com> References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> <4F8665E4.9050303@berkeley.edu> To: Erik Wilde X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:5+lqunDZ2L/vQxYyGbNyTWVAi+h34bCLBSWHD7QopgX LPqfmwJcR+vXwa5kBaNFkapRXUGi4K9tVb7/JxcgUAWSEPTZUs Tk2BBYq4A8E0PQiS/qOB3bGDevLyxOHQc26FrApiLRc4cM0uSs eNOAdJ8fSz943CNgxYdYRVATo8oO9wPyMxubTVKCVcX4BrKzUm 2xD4jdzI3wmHwL9mOzb5Qgv363NUMiMwqmkcr8AKarwX/9gjY7 t/q4F/zwZtz7kKVIBSogfHy7F+OU/FglyNyb3pjBqxKLrIQnNe bLB9pw7UM2/NPriEqKg6lu2VORfXeYdQxesr8/Na01juaKgSbV 61lQGmcAHCPlkXEl7tplD9SUbDEDVawmVzN1yHypki03h9oCey +JYEjMhh6VFIw== X-Mailman-Approved-At: Thu, 12 Apr 2012 08:28:28 -0700 Cc: Mark Nottingham , "apps-discuss@ietf.org application-layer protocols" , REST Discuss Subject: Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 07:12:24 -0000 Hi Erik, On Apr 12, 2012, at 7:19 AM, Erik Wilde wrote: > hello jan. >=20 > On 2012-04-10 11:58 , Jan Algermissen wrote: >> Likewise, what does that check for atompub capabilities buy you? The = reason you check for them is that you assume they are there in the first = place. If that check fails .... then what? You are in exactly the same = situation as when you POST you atom entry right away and see what = happens. >=20 > the idea is to be able to check for the profile URI to see whether a = feed i have discovered supports atompub or not. if it does, i might show = an "upload" feature in a UI that otherwise i would not show. without the = feed advertising its capabilities, i cannot know, and i certainly don't = want to create a fake post to test whether atompub is supported or not. Ok (though I personally would not see a profile as saying something = about the resource, but about the payload) Anyhow - have you considered supporting your use case with the 'service' = link relation? The pointed-to service document would tell your UA, what = resource are app-collections. (BTW, seems the registry is broken there, because service cites atompub = as its spec - which it is not). Jan >=20 > if all operations in atompub were exposed via links, it would be a = different story in this particular case, but they are not, so a profile = URI would be one way to go. and it's just one example and not the whole = 'profile' story. >=20 > cheers, >=20 > dret. >=20 > --=20 > 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 julian.reschke@gmx.de Thu Apr 12 08:34: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 B377021F869D for ; Thu, 12 Apr 2012 08:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.889 X-Spam-Level: X-Spam-Status: No, score=-102.889 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xjs2PjHE7ISj for ; Thu, 12 Apr 2012 08:34:03 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B385421F867F for ; Thu, 12 Apr 2012 08:34:02 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2012 15:34:01 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp024) with SMTP; 12 Apr 2012 17:34:01 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/MXJZpnCHMkHYN32R3eqyhiOLy7p0Fskqi/eBR3w qb3+xzmeuWLsMR Message-ID: <4F86F5E9.1040202@gmx.de> Date: Thu, 12 Apr 2012 17:34:01 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 15:34:03 -0000 Hi there, right now, the draft escapes forward slashes in reference tokens using ^-escapes, that is: a/b becomes a^/b and a^b becomes a^^b (Reminder: previously "\" was used, but it results in ugly double escaping when the pointer occurs in a JSON string). A drawback of this scheme is that when the pointer is used inside a URI, such as the path component of a an HTTP URI, the / still needs to be escaped, so the name a/b becomes the pointer a^/b and would end up as a%5e%2fb in the URI. An alternate proposal I heard during the IETF meeting in Paris was to simply apply URI percent escaping to the characters in the URI gen-delims range: gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" so a/b would simply become a%2fb and wouldn't need any further escaping in a URI path component. Feedback appreciated, Julian From julian.reschke@gmx.de Thu Apr 12 08:49: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 988CA21F8698 for ; Thu, 12 Apr 2012 08:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.867 X-Spam-Level: X-Spam-Status: No, score=-102.867 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVbsyOoWUMTJ for ; Thu, 12 Apr 2012 08:49:56 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 59B3E21F8693 for ; Thu, 12 Apr 2012 08:49:49 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2012 15:49:47 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp031) with SMTP; 12 Apr 2012 17:49:47 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19v1XlWdnZvYT7wbQYFHzCLbn4OTQADSzb/hsFMiM kAPgwLd3aizmIu Message-ID: <4F86F99A.3070601@gmx.de> Date: Thu, 12 Apr 2012 17:49:46 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jan Algermissen References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> <4F8665E4.9050303@berkeley.edu> <5006D354-A78D-4347-A3D1-0ED840BD81ED@nordsc.com> In-Reply-To: <5006D354-A78D-4347-A3D1-0ED840BD81ED@nordsc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Mark Nottingham , Erik Wilde , REST Discuss , "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 15:49:56 -0000 On 2012-04-12 09:12, Jan Algermissen wrote: > ... > Ok (though I personally would not see a profile as saying something about the resource, but about the payload) Right; that would be consistent with the use of the profile attribute in HTML4. > Anyhow - have you considered supporting your use case with the 'service' link relation? The pointed-to service document would tell your UA, what resource are app-collections. > > (BTW, seems the registry is broken there, because service cites atompub as its spec - which it is not). Indeed, let's blame Mark for this :-) Seems we need a spec for "service" then. best regards, Julian From julian.reschke@gmx.de Thu Apr 12 08:52:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0EB21F851B for ; Thu, 12 Apr 2012 08:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.848 X-Spam-Level: X-Spam-Status: No, score=-102.848 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpr12uAOHcOl for ; Thu, 12 Apr 2012 08:52:42 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id AD4E821F850C for ; Thu, 12 Apr 2012 08:52:39 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2012 15:52:38 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 12 Apr 2012 17:52:38 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19sSeRNXYNsNZIvF4P8fcu6kMjNHqrSK0Ui2eJ3wE y93JwJzMX9zJCr Message-ID: <4F86FA46.4020504@gmx.de> Date: Thu, 12 Apr 2012 17:52:38 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Joe Hildebrand References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 15:52:43 -0000 On 2012-04-12 17:49, Joe Hildebrand wrote: > I really like this. Would you unescape *all* %-encoded, or just the ones in > that list? What about escape sequences that lead to invalid UTF-8, for > example? > ... Assuming that your question refers to the process of retrieving a sequence of reference tokens from a URI path... I would 1) separate into URI path segments (using "/" as delimiter) 2) for each path segment, percent-unescape-then-UTF8-decode to obtain the reference token Best regards, Julian From dret@berkeley.edu Thu Apr 12 09:06: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 B8FE721F86AF for ; Thu, 12 Apr 2012 09:06:12 -0700 (PDT) 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_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPdyuyhVUtap for ; Thu, 12 Apr 2012 09:06:12 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 21ABE21F8661 for ; Thu, 12 Apr 2012 09:06:12 -0700 (PDT) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.67]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1SIMX6-0002iV-AD; Thu, 12 Apr 2012 09:06:09 -0700 Message-ID: <4F86FD73.2010708@berkeley.edu> Date: Thu, 12 Apr 2012 09:06:11 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Julian Reschke References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> <4F8665E4.9050303@berkeley.edu> <5006D354-A78D-4347-A3D1-0ED840BD81ED@nordsc.com> <4F86F99A.3070601@gmx.de> In-Reply-To: <4F86F99A.3070601@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , Jan Algermissen , REST Discuss , "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 16:06:12 -0000 hello. On 2012-04-12 08:49 , Julian Reschke wrote: > On 2012-04-12 09:12, Jan Algermissen wrote: >> (BTW, seems the registry is broken there, because service cites >> atompub as its spec - which it is not). > Indeed, let's blame Mark for this :-) yup, that occurred to me a while ago when i was looking for a spec for the "registered" 'service' relation and there was none, but back then, nobody seemed to think that was an issue that needed fixing. i think it would be good to have an actual spec (just out of curiosity it would be interesting to know how this value was able to creep in there without being spec'ed or reviewed a la rfc5988), and since i am in spec writing mode these days, i could easily get a 'service' one started. however, since this one would likely update rfc5023, i'd suggest to maybe also (if we can get agreement around this) include a 'profile' URI, assuming that there is some agreement on the 'profile' concept and that it would make sense for signaling that "an atom feed is following the atompub profile". 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 mnot@mnot.net Thu Apr 12 09:09: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 1EBA721F86CE for ; Thu, 12 Apr 2012 09:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.966 X-Spam-Level: X-Spam-Status: No, score=-104.966 tagged_above=-999 required=5 tests=[AWL=-2.967, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puSx0ZEtl+LO for ; Thu, 12 Apr 2012 09:09:49 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 776E121F86C9 for ; Thu, 12 Apr 2012 09:09:49 -0700 (PDT) Received: from [10.6.129.16] (unknown [50.56.228.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A426222E1EB; Thu, 12 Apr 2012 12:09:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4F86FD73.2010708@berkeley.edu> Date: Thu, 12 Apr 2012 11:09:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> <4F8665E4.9050303@berkeley.edu> <5006D354-A78D-4347-A3D1-0ED840BD81ED@nordsc.com> <4F86F99A.3070601@gmx.de> <4F86FD73.2010708@berkeley.edu> To: Erik Wilde X-Mailer: Apple Mail (2.1257) Cc: Julian Reschke , Jan Algermissen , REST Discuss , "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 16:09:50 -0000 IIRC that one and a few other ones got in while it was the Atom link = relation registry, which was FCFS (no spec required). Cheers, On 12/04/2012, at 11:06 AM, Erik Wilde wrote: > hello. >=20 > On 2012-04-12 08:49 , Julian Reschke wrote: >> On 2012-04-12 09:12, Jan Algermissen wrote: >>> (BTW, seems the registry is broken there, because service cites >>> atompub as its spec - which it is not). >> Indeed, let's blame Mark for this :-) >=20 > yup, that occurred to me a while ago when i was looking for a spec for = the "registered" 'service' relation and there was none, but back then, = nobody seemed to think that was an issue that needed fixing. i think it = would be good to have an actual spec (just out of curiosity it would be = interesting to know how this value was able to creep in there without = being spec'ed or reviewed a la rfc5988), and since i am in spec writing = mode these days, i could easily get a 'service' one started. however, = since this one would likely update rfc5023, i'd suggest to maybe also = (if we can get agreement around this) include a 'profile' URI, assuming = that there is some agreement on the 'profile' concept and that it would = make sense for signaling that "an atom feed is following the atompub = profile". >=20 > cheers, >=20 > dret. >=20 > --=20 > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Thu Apr 12 09:10: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 DF72C21F86C1 for ; Thu, 12 Apr 2012 09:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0Ha7t-T+409 for ; Thu, 12 Apr 2012 09:10:23 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0CF2B21F8512 for ; Thu, 12 Apr 2012 09:10:22 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2012 16:10:21 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 12 Apr 2012 18:10:21 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+HC9k08BaHv8vD0tVNzlk4Y4zhUfEQ/qXyHpupNQ 2WLA9KFMNYbwX6 Message-ID: <4F86FE6E.40801@gmx.de> Date: Thu, 12 Apr 2012 18:10:22 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Erik Wilde References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> <4F8665E4.9050303@berkeley.edu> <5006D354-A78D-4347-A3D1-0ED840BD81ED@nordsc.com> <4F86F99A.3070601@gmx.de> <4F86FD73.2010708@berkeley.edu> In-Reply-To: <4F86FD73.2010708@berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Mark Nottingham , Jan Algermissen , REST Discuss , "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 16:10:24 -0000 On 2012-04-12 18:06, Erik Wilde wrote: > hello. > > On 2012-04-12 08:49 , Julian Reschke wrote: >> On 2012-04-12 09:12, Jan Algermissen wrote: >>> (BTW, seems the registry is broken there, because service cites >>> atompub as its spec - which it is not). >> Indeed, let's blame Mark for this :-) > > yup, that occurred to me a while ago when i was looking for a spec for > the "registered" 'service' relation and there was none, but back then, > nobody seemed to think that was an issue that needed fixing. i think it > would be good to have an actual spec (just out of curiosity it would be > interesting to know how this value was able to creep in there without > being spec'ed or reviewed a la rfc5988), and since i am in spec writing Well, because it was in the Atom link relation registry before RFC 5988 was approved. > mode these days, i could easily get a 'service' one started. however, > since this one would likely update rfc5023, i'd suggest to maybe also > (if we can get agreement around this) include a 'profile' URI, assuming > that there is some agreement on the 'profile' concept and that it would > make sense for signaling that "an atom feed is following the atompub > profile". > ... Not sure about that. It seems you are using "profile" in a very different way then it was used in HTML4; is this really a good idea? Best regards, Julian From pbryan@anode.ca Thu Apr 12 09:21: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 180E921F86A6 for ; Thu, 12 Apr 2012 09:21:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiTFaajcvIIZ for ; Thu, 12 Apr 2012 09:21:33 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 501ED21F86A2 for ; Thu, 12 Apr 2012 09:21:33 -0700 (PDT) Received: from [10.1.226.50] (nat-204-14-239-208-sfo.net.salesforce.com [204.14.239.208]) by maple.anode.ca (Postfix) with ESMTPSA id BE8256482 for ; Thu, 12 Apr 2012 16:21:32 +0000 (UTC) Message-ID: <1334247691.2570.8.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Thu, 12 Apr 2012 09:21:31 -0700 In-Reply-To: <4F86F5E9.1040202@gmx.de> References: <4F86F5E9.1040202@gmx.de> Content-Type: multipart/alternative; boundary="=-hf4NzsllfYztjV2FMn2V" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 16:21:34 -0000 --=-hf4NzsllfYztjV2FMn2V Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit This takes us back to a previous version of JSON Pointer, which in fact did use URI escaping of %2F to distinguish between the '/' token delimiter and a '/' character within a token. IIRC, the objections that lead us to change were: 1. It requires URI decoding logic in non-URI-processing code (e.g. when pointers are used in JSON strings rather than in URI fragment identifiers). This has always been a somewhat weak argument, IMO. 2. Some URI parsers normalize the URI (i.e. expand %2F into '/') before any JSON Pointer parsing code can get a chance to see it. In response to this, I went down the path of using a single escape character. If we can overcome these objections, I'd be happy to entertain returning to URI escaping. Paul On Thu, 2012-04-12 at 17:34 +0200, Julian Reschke wrote: > Hi there, > > right now, the draft escapes forward slashes in reference tokens using > ^-escapes, that is: > > a/b > > becomes > > a^/b > > and > > a^b > > becomes > > a^^b > > (Reminder: previously "\" was used, but it results in ugly double > escaping when the pointer occurs in a JSON string). > > A drawback of this scheme is that when the pointer is used inside a URI, > such as the path component of a an HTTP URI, the / still needs to be > escaped, so the name > > a/b > > becomes the pointer > > a^/b > > and would end up as > > a%5e%2fb > > in the URI. > > > An alternate proposal I heard during the IETF meeting in Paris was to > simply apply URI percent escaping to the characters in the URI > gen-delims range: > > gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" > > so > > a/b > > would simply become > > a%2fb > > and wouldn't need any further escaping in a URI path component. > > Feedback appreciated, > > Julian > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-hf4NzsllfYztjV2FMn2V Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit This takes us back to a previous version of JSON Pointer, which in fact did use URI escaping of %2F to distinguish between the '/' token delimiter and a '/' character within a token. IIRC, the objections that lead us to change were:

1. It requires URI decoding logic in non-URI-processing code (e.g. when pointers are used in JSON strings rather than in URI fragment identifiers). This has always been a somewhat weak argument, IMO.

2. Some URI parsers normalize the URI (i.e. expand %2F into '/') before any JSON Pointer parsing code can get a chance to see it.

In response to this, I went down the path of using a single escape character. If we can overcome these objections, I'd be happy to entertain returning to URI escaping.

Paul

On Thu, 2012-04-12 at 17:34 +0200, Julian Reschke wrote: 
Hi there,

right now, the draft escapes forward slashes in reference tokens using 
^-escapes, that is:

  a/b

becomes

  a^/b

and

  a^b

becomes

  a^^b

(Reminder: previously "\" was used, but it results in ugly double 
escaping when the pointer occurs in a JSON string).

A drawback of this scheme is that when the pointer is used inside a URI, 
such as the path component of a an HTTP URI, the / still needs to be 
escaped, so the name

   a/b

becomes the pointer

   a^/b

and would end up as

   a%5e%2fb

in the URI.


An alternate proposal I heard during the IETF meeting in Paris was to 
simply apply URI percent escaping to the characters in the URI 
gen-delims range:

  gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"

so

   a/b

would simply become

   a%2fb

and wouldn't need any further escaping in a URI path component.

Feedback appreciated,

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

--=-hf4NzsllfYztjV2FMn2V-- From dret@berkeley.edu Thu Apr 12 09:24: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 1111921F86C3 for ; Thu, 12 Apr 2012 09:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KMNFIsS6LaM for ; Thu, 12 Apr 2012 09:24:35 -0700 (PDT) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id D491B21F86C1 for ; Thu, 12 Apr 2012 09:24:34 -0700 (PDT) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.67]) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1SIMot-0007sj-HQ; Thu, 12 Apr 2012 09:24:32 -0700 Message-ID: <4F8701B8.9020307@berkeley.edu> Date: Thu, 12 Apr 2012 09:24:24 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jan Algermissen References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> <4F8665E4.9050303@berkeley.edu> <5006D354-A78D-4347-A3D1-0ED840BD81ED@nordsc.com> In-Reply-To: <5006D354-A78D-4347-A3D1-0ED840BD81ED@nordsc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , "apps-discuss@ietf.org application-layer protocols" , REST Discuss Subject: Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 16:24:36 -0000 hello jan. On 2012-04-12 00:12 , Jan Algermissen wrote: > On Apr 12, 2012, at 7:19 AM, Erik Wilde wrote: >> the idea is to be able to check for the profile URI to see whether a feed i have discovered supports atompub or not. if it does, i might show an "upload" feature in a UI that otherwise i would not show. without the feed advertising its capabilities, i cannot know, and i certainly don't want to create a fake post to test whether atompub is supported or not. > Ok (though I personally would not see a profile as saying something about the resource, but about the payload) yes, we have agreement on this. a profile (quoting from the -01 text i am writing now) "are additional semantics that can be used to process a resource representation, such as constraints, conventions, extensions, or any other aspects that do not alter the basic media type semantics." if a feed indicates it supports atompub, that extends what to expect in the feed, and in case of atompub, it also extends the feed's behavior. like i said in a response to mark, i think the line between "format conventions" and "behavior" is fuzzy. but i'd argue that the 'atompub profile' definitely would be specific for the representation (the atompub enabled feed), because a different representation of the collection resource might very well expose a different mechanism to provide write access to the collection. 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 tbray@textuality.com Thu Apr 12 09:34: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 5ADC321F8646 for ; Thu, 12 Apr 2012 09:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tEPswnSAJ0C for ; Thu, 12 Apr 2012 09:34:46 -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 35E8921F8539 for ; Thu, 12 Apr 2012 09:34:46 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3406722obb.31 for ; Thu, 12 Apr 2012 09:34:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=7zo5YLQy8k1aKxSbtEbhdZZOOu8jX7lvi0RT5zleJlA=; b=BgZVj5LbllH8NMaKtGJgxniCWx1gZXkSL5dbbxi+2Age48FsFSBYpZD7a6Ib3vNmsu 1fGD0VA/DTOQUupiB0sU5XpwXLHSOzPyXrsxFa3UMOeVXLAMMnMGEsoj9Razec8ag/On Kkxf0BVyYDTk2C8fqObIE1qv6izgXQk8FwdI3jYx10FuRgbAnKVUORbHApBTepmJN2c7 jvmYafVt7sqrO8MPSk0E0zn+J+B2XLyHpEJai/aZ63+EvCd3StTYla9Iemroz8DQ75yI SLYeS5+L1BAvKZxTLuBl6bfOk+hGpGK+49Hv5DNuN8rWLHAW95aDFR+CtGFQI0z71Ne2 N6Eg== MIME-Version: 1.0 Received: by 10.182.113.42 with SMTP id iv10mr1039481obb.18.1334248485773; Thu, 12 Apr 2012 09:34:45 -0700 (PDT) Received: by 10.182.29.6 with HTTP; Thu, 12 Apr 2012 09:34:45 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net> References: <4F866AC0.3000603@qualcomm.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net> Date: Thu, 12 Apr 2012 09:34:45 -0700 Message-ID: From: Tim Bray To: Eran Hammer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlc3Sx9xYZW7l14n8AMhGCzysZgKcVAT8eUvuEnS5yKI6i/uz8NWfasgCu5BR1f3yIF96pa Cc: Pete Resnick , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 16:34:47 -0000 Well, it would claim it as a reserved paramater name if there a way to do such a thing, which there explicitly isn=92t in RFC3986. URIs are for most application purposes opaque strings; this breaks that and is a hideous architectural botch. For example, there is a huge amount of deployed code out there which compares two URIs and determines whether they are equivalent or different (to start with, every piece of crawling and caching infrastructure in the world); must it all now be refactored to check the parameters for oauth_* and disregard those values in their equality considerations? Chapter 6 of RFC3986 explicitly discusses issues in comparing URIs for equivalency; read it, and you=92ll find nothing there about ?name=3Dvalue pairs. This is not how URIs work. It might be convenient in some application scenarios, but in other application scenarios it might be convenient to add your own IP packet header bits, and you can=92t do that either. Please back this horrible idea out. -T On Thu, Apr 12, 2012 at 5:56 AM, Eran Hammer wrote: > The issue is pretty simple. The OAuth bearer token specification defines = an HTTP Authorization header scheme. It also provides a "hack" for sending = the same authentication credentials direction in the HTTP request URI. For = example: > > http://example.com/protected/resource?access_token=3Dalskjdlaskjd > > This in practice claims the 'access_token' URI query parameter as a resev= ed parameter name used by the bearer token specification. The reason is tha= t any future (or existing) implementation using this parameter name will no= w be in conflict with the OAuth bearer token specification. We do not have = a mechanism for reserving URI query parameters - but in practice, this upda= tes RFC 3986 by taking ownership of the query parameter name. > > There were other voices on the OAuth WG to simply drop this mechanism but= resistance from the authors and lack of strong consensus kept it in. > > I supported Mark's recommendation of dropping that mechanism. > > Hope this is helpful. > > EH > > ________________________________________ > From: apps-discuss-bounces@ietf.org [apps-discuss-bounces@ietf.org] on be= half of Pete Resnick [presnick@qualcomm.com] > Sent: Wednesday, April 11, 2012 10:40 PM > To: Apps Discuss; draft-ietf-oauth-v2-bearer.all@tools.ietf.org > Subject: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-= v2-bearer > > Folks, > > Mark mentioned to me that he did not think one major issue in his review > of this document was fully addressed. I would like to get some feedback > from other folks here on the Apps-discuss list as I cannot say myself > that I fully understand the implications of the issue. > > Mike Jones wrote: > >> Mark Nottingham wrote: >> >>> * Section 2.3 URI Query Parameter >>> >>> This section effectively reserves a URI query parameter for the >>> draft's use. This should not be done lightly, since this would be a >>> precedent for the IETF encroaching upon a server's URIs (done >>> previously in RFC5785, but in a much more limited fashion, as a >>> tactic to prevent further, uncontrolled encroachment). >>> >>> Given that the draft already discourages the use of this mechanism, >>> I'd recommend dropping it altogether. If the Working Group wishes it >>> to remain, this issues should be vetted both through the APPS area >>> and the W3C liaison. >>> >>> (The same criticism could be leveled at Section 2.2 Form-Encoded Body >>> Parameter, but that at least isn't surfaced in an identifier) >> >> There are some contexts, especially limited browsers and/or >> development environments, where query parameters are usable but the >> other methods are not. =A0Thus, the query parameter method must be >> retained. =A0Also, Justin Richter's comments describing the value to him >> of the query parameter method are pertinent: =A0A URL with all >> parameters including authorization is a powerful artifact which can be >> passed around between systems as a unit. >> >> As to using a standard parameter name, this is essential for >> interoperability. =A0It is not reserved in any contexts other than when >> the Bearer spec is employed, which is a voluntary act by both >> parties. =A0Thus, this poses no undue burdens or namespace restrictions >> on implementations in practice. >> >> Finally, you'll find that OAuth 1.0 [RFC 5849] similarly defined, not >> one, but two standard query parameter values: =A0oauth_token and >> oauth_verifier. =A0As this didn't cause any problems in practice then, >> I'm sure that defining an access_token parameter within the Bearer >> spec for interoperability purposes won't cause a problem either. > > Would anyone (including, but not limited to, Mark) be able to better > explain the issue here? > > Thanks, > > pr > > -- > Pete Resnick > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > > _______________________________________________ > 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 dret@berkeley.edu Thu Apr 12 09:39: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 4340D21F86AF for ; Thu, 12 Apr 2012 09:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwskcZStIt6F for ; Thu, 12 Apr 2012 09:39:39 -0700 (PDT) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD2D21F86A7 for ; Thu, 12 Apr 2012 09:39:39 -0700 (PDT) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.67]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1SIN3S-000835-6I; Thu, 12 Apr 2012 09:39:36 -0700 Message-ID: <4F87053F.2080203@berkeley.edu> Date: Thu, 12 Apr 2012 09:39:27 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Julian Reschke References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> <4F8665E4.9050303@berkeley.edu> <5006D354-A78D-4347-A3D1-0ED840BD81ED@nordsc.com> <4F86F99A.3070601@gmx.de> <4F86FD73.2010708@berkeley.edu> <4F86FE6E.40801@gmx.de> In-Reply-To: <4F86FE6E.40801@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , Jan Algermissen , REST Discuss , "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 16:39:40 -0000 hello julian. On 2012-04-12 09:10 , Julian Reschke wrote: > It seems you are using "profile" in a very different way then it was > used in HTML4; is this really a good idea? i certainly do not intend to use it in a different way, because like you, i do not think that would be a good idea. my current definition is that "a profile are additional semantics that can be used to process a resource representation, such as constraints, conventions, extensions, or any other aspects that do not alter the basic media type semantics." my understanding of HTML's profile was always like this. quoting from http://www.w3.org/TR/html4/struct/global.html#profiles : "User agents may be able to recognize the name (without actually retrieving the profile) and perform some activity based on known conventions for that profile. For instance, search engines could provide an interface for searching through catalogs of HTML documents, where these documents all use the same profile for representing catalog entries." mark also noted that he regards a profile mostly as saying something about a representation's content, such as a metadata profile in HTML, saying that the web page uses dublin core. but even when you look at the dublin core HTML profile (http://dublincore.org/documents/dcq-html/), it also defines conventions about links (http://dublincore.org/documents/dcq-html/#sect-2-4), and not just about non-link data. which is the point i was trying to make saying that the line between "format extensions" and "links" is fuzzy: essentially, a link *is* a format extension, only one that extends beyond the current resource. i am not sure i was able to fully address your concerns, so if you still think i am "redefining" what 'profile' is supposed to do, could you be a bit more specific why you think that's the case, and how you'd like to see it done? thanks a lot and 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 julian.reschke@gmx.de Thu Apr 12 09:52: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 8FC5521F858E for ; Thu, 12 Apr 2012 09:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.798 X-Spam-Level: X-Spam-Status: No, score=-102.798 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN7Qs3+Rs30l for ; Thu, 12 Apr 2012 09:52:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 41F5621F84FD for ; Thu, 12 Apr 2012 09:52:37 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2012 16:52:35 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp024) with SMTP; 12 Apr 2012 18:52:35 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18gGK9Djv4gnIZH5BfgZZg8vlVe6HeLSGyGqxY+od zhVfmKUM0LIphD Message-ID: <4F870853.8020500@gmx.de> Date: Thu, 12 Apr 2012 18:52:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Erik Wilde References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> <4F8665E4.9050303@berkeley.edu> <5006D354-A78D-4347-A3D1-0ED840BD81ED@nordsc.com> <4F86F99A.3070601@gmx.de> <4F86FD73.2010708@berkeley.edu> <4F86FE6E.40801@gmx.de> <4F87053F.2080203@berkeley.edu> In-Reply-To: <4F87053F.2080203@berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Mark Nottingham , Jan Algermissen , REST Discuss , "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 16:52:39 -0000 On 2012-04-12 18:39, Erik Wilde wrote: > hello julian. > > On 2012-04-12 09:10 , Julian Reschke wrote: >> It seems you are using "profile" in a very different way then it was >> used in HTML4; is this really a good idea? > > i certainly do not intend to use it in a different way, because like > you, i do not think that would be a good idea. my current definition is > that "a profile are additional semantics that can be used to process a > resource representation, such as constraints, conventions, extensions, > or any other aspects that do not alter the basic media type semantics." > > my understanding of HTML's profile was always like this. quoting from > http://www.w3.org/TR/html4/struct/global.html#profiles : > > "User agents may be able to recognize the name (without actually > retrieving the profile) and perform some activity based on known > conventions for that profile. For instance, search engines could provide > an interface for searching through catalogs of HTML documents, where > these documents all use the same profile for representing catalog entries." > > mark also noted that he regards a profile mostly as saying something > about a representation's content, such as a metadata profile in HTML, > saying that the web page uses dublin core. but even when you look at the > dublin core HTML profile (http://dublincore.org/documents/dcq-html/), it > also defines conventions about links > (http://dublincore.org/documents/dcq-html/#sect-2-4), and not just about > non-link data. which is the point i was trying to make saying that the > line between "format extensions" and "links" is fuzzy: essentially, a > link *is* a format extension, only one that extends beyond the current > resource. > > i am not sure i was able to fully address your concerns, so if you still > think i am "redefining" what 'profile' is supposed to do, could you be a > bit more specific why you think that's the case, and how you'd like to > see it done? > ... Maybe we need to switch to examples to get a clearer picture. With "profile" I understand that the link *target* is a URI describing the profile, such as which describes that hcard profile. If you want to use the profile link relation to declare that something is a an AtomPub server, on which resource would you set the link relation? Best regards, Julian From dret@berkeley.edu Thu Apr 12 10:27: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 4CE1321F853E for ; Thu, 12 Apr 2012 10:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGonqffRUj+2 for ; Thu, 12 Apr 2012 10:27:01 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 92F0821F8448 for ; Thu, 12 Apr 2012 10:27:01 -0700 (PDT) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.67]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1SINnN-0001qq-D6; Thu, 12 Apr 2012 10:26:58 -0700 Message-ID: <4F87105E.5030708@berkeley.edu> Date: Thu, 12 Apr 2012 10:26:54 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Julian Reschke References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> <4F8665E4.9050303@berkeley.edu> <5006D354-A78D-4347-A3D1-0ED840BD81ED@nordsc.com> <4F86F99A.3070601@gmx.de> <4F86FD73.2010708@berkeley.edu> <4F86FE6E.40801@gmx.de> <4F87053F.2080203@berkeley.edu> <4F870853.8020500@gmx.de> In-Reply-To: <4F870853.8020500@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , Jan Algermissen , REST Discuss , "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 17:27:02 -0000 hello julian. On 2012-04-12 09:52 , Julian Reschke wrote: > Maybe we need to switch to examples to get a clearer picture. > With "profile" I understand that the link *target* is a URI describing > the profile, such as which describes > that hcard profile. no, the 'profile' link target URI *identifies* the profile in use, and it MAY point to a description (and hopefully will), but it does not have to do that. at that level it works exactly the same as XML namespace URIs: its definition is to be an identifier, but if you want to be nice, then you actually link to some description, but that's entirely up to you. here's what the draft currently says: "Profiles are identified by URI, but as with for example XML namespace URIs, the URI in this case first and foremost serves as an identifier, meaning that the presence of a specific URI has to be sufficient for a client to assert that a resource representation conforms to a profile." > If you want to use the profile link relation to declare that something > is a an AtomPub server, on which resource would you set the link relation? the feed served by the atompub-enabled server would contain such a 'profile' link on the feed level, indicating to a client that it can POST to that feed's URI to create a new collection member. 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 julian.reschke@gmx.de Thu Apr 12 10:40: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 0DAED21F8566 for ; Thu, 12 Apr 2012 10:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.711 X-Spam-Level: X-Spam-Status: No, score=-103.711 tagged_above=-999 required=5 tests=[AWL=-1.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLq6HyeyblK4 for ; Thu, 12 Apr 2012 10:40:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id A1C3021F8532 for ; Thu, 12 Apr 2012 10:40:21 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2012 17:40:20 -0000 Received: from p57A6FBC6.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.251.198] by mail.gmx.net (mp031) with SMTP; 12 Apr 2012 19:40:20 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19NI9YIM+RNmw/AFLCZDJRzGzr1V1l4fII6U0HDni AMmi6tWziwBoUD Message-ID: <4F871383.5090602@gmx.de> Date: Thu, 12 Apr 2012 19:40:19 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Erik Wilde References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> <4F8665E4.9050303@berkeley.edu> <5006D354-A78D-4347-A3D1-0ED840BD81ED@nordsc.com> <4F86F99A.3070601@gmx.de> <4F86FD73.2010708@berkeley.edu> <4F86FE6E.40801@gmx.de> <4F87053F.2080203@berkeley.edu> <4F870853.8020500@gmx.de> <4F87105E.5030708@berkeley.edu> In-Reply-To: <4F87105E.5030708@berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Mark Nottingham , Jan Algermissen , REST Discuss , "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 17:40:23 -0000 On 2012-04-12 19:26, Erik Wilde wrote: > hello julian. > > On 2012-04-12 09:52 , Julian Reschke wrote: >> Maybe we need to switch to examples to get a clearer picture. >> With "profile" I understand that the link *target* is a URI describing >> the profile, such as which describes >> that hcard profile. > > no, the 'profile' link target URI *identifies* the profile in use, and > it MAY point to a description (and hopefully will), but it does not have > to do that. at that level it works exactly the same as XML namespace Yes, sorry for being not precise. > URIs: its definition is to be an identifier, but if you want to be nice, > then you actually link to some description, but that's entirely up to > you. here's what the draft currently says: > > "Profiles are identified by URI, but as with for example XML namespace > URIs, the URI in this case first and foremost serves as an identifier, > meaning that the presence of a specific URI has to be sufficient for a > client to assert that a resource representation conforms to a profile." > >> If you want to use the profile link relation to declare that something >> is a an AtomPub server, on which resource would you set the link >> relation? > > the feed served by the atompub-enabled server would contain such a > 'profile' link on the feed level, indicating to a client that it can > POST to that feed's URI to create a new collection member. OK. I don't have a problem with that. The one thing to consider is, as others have pointed out, whether it would make sense to use "service" instead and let that point back to the same URI (assuming we have a proper definition of "service" :-) Best regards, Julian From dret@berkeley.edu Thu Apr 12 11:00: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 C770C21F85D7 for ; Thu, 12 Apr 2012 11:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT+5LZjuUFu8 for ; Thu, 12 Apr 2012 11:00:54 -0700 (PDT) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1786121F85BD for ; Thu, 12 Apr 2012 11:00:54 -0700 (PDT) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.67]) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1SIOK9-0001A7-JD; Thu, 12 Apr 2012 11:00:51 -0700 Message-ID: <4F87184F.7080308@berkeley.edu> Date: Thu, 12 Apr 2012 11:00:47 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Julian Reschke References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> <4F8665E4.9050303@berkeley.edu> <5006D354-A78D-4347-A3D1-0ED840BD81ED@nordsc.com> <4F86F99A.3070601@gmx.de> <4F86FD73.2010708@berkeley.edu> <4F86FE6E.40801@gmx.de> <4F87053F.2080203@berkeley.edu> <4F870853.8020500@gmx.de> <4F87105E.5030708@berkeley.edu> <4F871383.5090602@gmx.de> In-Reply-To: <4F871383.5090602@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , Jan Algermissen , atom-protocol@imc.org, REST Discuss , "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 18:00:55 -0000 hello julian. On 2012-04-12 10:40 , Julian Reschke wrote: >> the feed served by the atompub-enabled server would contain such a >> 'profile' link on the feed level, indicating to a client that it can >> POST to that feed's URI to create a new collection member. > OK. I don't have a problem with that. The one thing to consider is, as > others have pointed out, whether it would make sense to use "service" > instead and let that point back to the same URI (assuming we have a > proper definition of "service" :-) so i guess the difference here is the following: - 'profile' would just say that a feed is atompub-enabled, but it would not allow you to discover the specific service description for that feed. it would just be a link to discover and understand that i can POST to that URI. - 'service' would link to the specific service description for that feed, and thus must be a working link and would allow clients to find out more about the service provided by the atompub server. to be honest, i just looked at "naked atompub" and thought 'profile' might be a good thing and a good example for the 'profile' spec. if we assume "atompub + 'service'" is being used, then maybe 'profile' is of little additional value, and i should stop using it as an example. which (and now i am happily cross-posting to atom-protocol@imc.org as well) leads me to the question: should we have a 'service' spec or are we happy with 'service' just magically showing up in the registry? as somebody just reading and implementing atompub right now, there's no way for me to find out about 'service', so i think it should be properly spec'ed. if people agree (feedback from atom-protocol@imc.org would be very welcome), i'd be happy to come up with a first draft. 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 msk@cloudmark.com Thu Apr 12 11:09: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 C9B4121F860B for ; Thu, 12 Apr 2012 11:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhyNInAxPdlJ for ; Thu, 12 Apr 2012 11:09:18 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id B44E821F85D0 for ; Thu, 12 Apr 2012 11:09:18 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id x69M1i0020as01C0169MxP; Thu, 12 Apr 2012 11:09:21 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=SOLApZTH c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=strSrcXltg0A:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=nEgYUYOVEp9JdDSuo8gA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=q50natKIVWMPrYNOElcA:9 a=os9K5IzKSrkgkKfLu1cA:7 a=gKO2Hq4RSVkA:10 a=hTZeC7Yk6K0A:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Thu, 12 Apr 2012 11:09:07 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: WGLC on draft-ietf-appsawg-media-type-regs Thread-Index: Ac0QjpwXS/k4kzTsSYSQ+Pgexg+sugISKdAQ Date: Thu, 12 Apr 2012 18:09:06 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280EC8C9@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280C4828@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C4828@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280EC8C9exchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334254162; bh=I3VOy3BsLQ5oxxOYcRRl4UOGo8cB3u7Yp46vH/FvypY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=ngMst0sPDU1qjj/e1BR1wU0m2UiH9WC/VXXwA3DjeXgqoE08y1rUWPIar7vy56enS 7L9cBNdJLz5HAfyeSJFjcNxRoPLhrIgshUQ7H9gjCDNKAe7Lex5aVMIuhwbsYQkq5E +UXPG2nv7/ZRmWDA0YvGtST3uxjxsw61X8hcyNPo= Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 18:09:19 -0000 --_000_9452079D1A51524AA5749AD23E0039280EC8C9exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder that this WGLC ends today. If anyone has any reviews to re= port or comments to provide, please do so. I'd like to hand it over to Bar= ry this weekend if possible. -MSK From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy Sent: Sunday, April 01, 2012 10:08 PM To: apps-discuss@ietf.org Subject: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs This message serves as the beginning of Working Group Last Call on draft-ie= tf-appsawg-media-type-regs, to end on Friday, April 13th. Please review th= e document and provide any feedback to the authors directly or to apps-disc= uss@ietf.org. The datatracker page for the document: https://datatracker.ietf.org/doc/dra= ft-ietf-appsawg-media-type-regs/ -MSK, APPSAWG co-chair --_000_9452079D1A51524AA5749AD23E0039280EC8C9exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder that t= his WGLC ends today.  If anyone has any reviews to report or comments = to provide, please do so.  I’d like to hand it over to Barry thi= s weekend if possible.

 

-MSK=

 

From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Sunday, April 01, 2012 10:08 PM
To: apps-discuss@ietf.org
Subject: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs

 

This message serves as the beginning of Working Grou= p Last Call on draft-ietf-appsawg-media-type-regs, to end on Friday, April = 13th.  Please review the document and provide any feedback = to the authors directly or to apps-discuss@ietf.org.

 

The datatracker page for the document: https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/

 

-MSK, APPSAWG co-chair

 

--_000_9452079D1A51524AA5749AD23E0039280EC8C9exchmbx901corpclo_-- From john-ietf@jck.com Thu Apr 12 11:27: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 D90D721F84D2 for ; Thu, 12 Apr 2012 11:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+1ebZ6N5RU4 for ; Thu, 12 Apr 2012 11:27:22 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id D5EE721F84CD for ; Thu, 12 Apr 2012 11:27:21 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SIOee-000EB7-R9; Thu, 12 Apr 2012 14:22:00 -0400 Date: Thu, 12 Apr 2012 14:27:14 -0400 From: John C Klensin To: Pete Resnick , Apps Discuss , draft-ietf-oauth-v2-bearer.all@tools.ietf.org Message-ID: <969CE95E2B28189A109BB90F@PST.JCK.COM> In-Reply-To: <4F866AC0.3000603@qualcomm.com> References: <4F866AC0.3000603@qualcomm.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 18:27:23 -0000 Pete, The first part of this may be the same as Tim Bray's answer in different form, but, in studying it I spotted an additional, and IMO, fundamental, issue. I want to note that, prior to your request, I had not reviewed this specification -- it falls into an area in which I have assumed, and continue to believe, that there are lots of competent people in the IETF watching and that, in general, my time is therefore better spent in other ways. I've also had a specific reason to avoid it for which I will provide details to you you off list. We've basically got two types of identifiers or identifier structures. One is completely restricted and associated, to the best of our ability, with very specific syntax rules and actual or implied registries for keywords. The other is free-form or has a form whose locus of interpretation is either determined by a registered keyword and associated rigid syntax or a very narrow rule about where interpretation of the syntax can occur. We have both with email addresses: A high-level syntax (ignoring source routes, "@" divides things into a left side and a right side. The right side is a domain name (specific syntax and with the DNS itself serving as a registry). The left side can be interpreted only by the destination server and is otherwise pretty much an opaque blob of text. It is no secret that I've never been a big fan of URIs. Much of the reason is that they try to combine the above and do it badly: we've got a method type that has a rigid syntax (case-insensitive ASCII alphanumeric string if I recall) and a registry. After that, the syntax gets method-dependent, with some symbols and strings (varying somewhat by method) having specific syntax and registry structure (e.g., when the locator is a domain name and nothing else is permitted there) and other bits being opaque except to the method or the combination of a method and a particular host or other identifier, or... And syntax is sometimes reserved and sometimes not. At some level, that characterization is unfair because the actual rules are more precise than the above implies. On the other hand, I suggest that the number of people in the community who could actually describe the exact rules to a third party in a reasonably short period of time, without the spec in front of them and without hand waving, and have that third party understand the rules when they are finished is few indeed. But now the this spec presumes to come along and essentially create an overlay on the general URI spec (see below) that reserves a query parameter that can somehow be used even in environments in which normal URI interpretation doesn't permit queries. It isn't clear from a quick reading of the spec whether that is actually intended or whether this is a collection of methods that apply to HTTP 1.1 only -- the text talks about URIs but the cases and examples given appear to be very HTTP (and maybe even HTTP 1.1)-specific. If it were clearly restricted to HTTP/HTTPS URLs, it would be somewhat more palatable because those URIs at least don't prohibit query parts. But the problem is with defining a specific query keyword, across hosts/locations and maybe across methods, for this use. The document doesn't discuss what has been done to demonstrate that they keyword is not in use anywhere else (a nearly impossible task given that there is no registry and no restrictions on such keywords and that they are interpreted on a per-server basis). It should at least discuss what would happen if someone were using this keyword for an entirely different purpose. Presumably such a use would safely fail any OAUTH-related tests, but the effect of OAUTH changing the intent of the original parameter would be, it seems to me, unpredictable. This is not a suggestion because the basic problem would remain, but we have mechanisms that we have tried in the past to at least significantly minimize the risks that a specific keyword or bit of syntax that is newly-introduced into a previously unrestricted or less restricted space will not interfere with an unknown catalog of prior (or even future but unrelated) uses. None of them use anything as generic-sounding as "access_token". If, contrary to the other suggestions here (and Tim's and Mark's comments), the IESG were to go ahead with this spec, the practical risks would be reduced by borrowing notes from IDNA (perhaps "xyz--access_token" or "access-_token") or some of the discussions about alternatives to "x-" (perhaps "oath-bearer.access_token"). Note the deliberately-odd mix of hyphens and underscores in both examples. Unless some syntax can be found that violates the URI specification (or at least the HTTP/HTTPS URL specification, see above) so as to mark a clear boundary between "end of normal URI" and access token information, perhaps the "right" way to do this would be to encapsulate the URI as a payload inside an OATH access package. Another plausible alternative would be to simply eliminate this option by dropping Section 2.3 from the spec. But that leads to a broader issue and criticism: IETF protocols have generally been the most successful when they provide a minimum number of ways to do something, ideally no more than one. This specification provides three (see Section 2), which we normally discourage, at least in the absence of very strong motivation. As far as I can tell (I've read through the spec, but not studied every word), that motivation is not explained in the document, nor are there criteria for which one should be selected under different circumstances (other than the "MUST NOT use...unless" statement about the method in Section 2.2), and there is no mandatory-to-implement provision for clients or servers. If the authors intend to require that all servers support all three models so that clients can do as they like without interoperability issues, they should say so. Otherwise, this is a recipe for interoperability failures (and, if all servers are required to support all methods, it is a requirement for apparently-unnecessary complexity. Recommendation: This specification should not be approved unless either: (i) Two of the three methods are removed, noting that removing 2.3 would eliminate most of the keyword and syntax-related objections. If 2.3 remains, those issues should be dealt with as well. (ii) The document was enhanced with a consensus discussion about why multiple methods are needed, how clients and servers should make decisions about what to actually implement and use, and what, if any methods and features can be depended on for interoperability (e.g., are mandatory to implement). You asked :-( regards, john From tony@att.com Thu Apr 12 11:51: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 488FB21F85FD for ; Thu, 12 Apr 2012 11:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9ccLeca43l6 for ; Thu, 12 Apr 2012 11:51:01 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3E521F85F9 for ; Thu, 12 Apr 2012 11:51:01 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 414278f4.0.1646565.00-355.4582959.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 12 Apr 2012 18:51:01 +0000 (UTC) X-MXL-Hash: 4f872415218aa740-b6d2b006e688fca87ce9f5533245ddab7b3aba12 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 q3CIp0vJ021752 for ; Thu, 12 Apr 2012 14:51:00 -0400 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 q3CIosda021682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2012 14:50:55 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Thu, 12 Apr 2012 14:50:34 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3CIoXIb030239 for ; Thu, 12 Apr 2012 14:50:33 -0400 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3CIoQcI029959 for ; Thu, 12 Apr 2012 14:50:26 -0400 Received: from [135.91.110.244] (ds135-91-110-244.dhcps.ugn.att.com[135.91.110.244]) by maillennium.att.com (mailgw1) with ESMTP id <20120412184726gw1004orave> (Authid: tony); Thu, 12 Apr 2012 18:47:26 +0000 X-Originating-IP: [135.91.110.244] Message-ID: <4F8723F1.8080201@att.com> Date: Thu, 12 Apr 2012 14:50:25 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org Discuss" References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> In-Reply-To: <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> Content-Type: multipart/alternative; boundary="------------070301090504090504010304" X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=p4QNoMogDYAA:10 a=vnNYxAp2wzwA:10 a=BlG6E5tz_8] X-AnalysisOut: [UA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=S-geHJfn51ZclWcMFzcA:9 a=-1G8GjJopp0jHufiS] X-AnalysisOut: [80A:7 a=wPNLvfGTeEIA:10 a=gKmFwSsBAAAA:8 a=7XVi9I_DrLr9QUy] X-AnalysisOut: [vx0QA:9 a=6-Ayyv992kyE6m0d4Z8A:7 a=_W_S_7VecoQA:10 a=ACBgD] X-AnalysisOut: [4iW9t8A:10] Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 18:51:02 -0000 This is a multi-part message in MIME format. --------------070301090504090504010304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable The Structured Syntax Suffixes are appropriate for use when the media=20 type identifies the semantics of the protocol payload. That is, knowing=20 the semantics of the specific media type provides for more specific=20 processing of the content than that afforded by generic processing of=20 the underlying representation. At the same time, using the suffix provides receivers of the media types = to do generic processing of the underlying representation in cases where 1) they do not need to handle specially the specific semantics of=20 the exact media type, and, 2) there is no special knowledge needed by such a generic processor = in order to parse that underlying representation other than what would=20 be needed to parse any example of that underlying representation. Please correct me if the following is wrong: It is my understanding that the general underlying representation of=20 EXI-based types *may* be totally generic. However, each EXI type also=20 pre-defines a dictionary specific to that type that the EXI=20 representation may use to shorten the output. So if I hand a media type=20 to a generic EXI parser, it will do fine until it hits something that is = only defined in that type-specific dictionary. Unfortunately, the=20 type-specific dictionary is not included in the EXI representation, but=20 must be gathered out-of-band. So it seems like +exi *could* be used if the representation stuck to=20 only using the generic dictionary and eschewed any type-specific=20 out-of-band dictionaries. Tony Hansen On 4/11/2012 7:05 PM, Carsten Bormann wrote: > On Apr 11, 2012, at 17:57, Ned Freed wrote: > >> And if this is the case, it really isn't suitable for a +exi suffix ei= ther. >> +exi is supposed to mean the format can at least be parsed, independe= nt of any >> knowledge of the type semantics. This is why I support the idea of hav= ing +ber >> and +der but not +per - with +per you have to know the ASN.1 schema in= order to >> parse the material properly. > So how would you handle the PERs and (schema-informed) EXIs of this wor= ld? > Should it be -exi, not +exi? > > (As in application/senml-exi?) > > (Again, the media type registration will do a lot more than just tack E= XI encoding on existing XML.) > > Gr=FC=DFe, Carsten --------------070301090504090504010304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The Structured Syntax Suffixes are appropriate for use when the media type identifies the semantics of the protocol payload. That is, knowing the semantics of the specific media type provides for more specific processing of the content than that afforded by generic processing of the underlying representation.

At the same time, using the suffix provides receivers of the media types to do generic processing of the underlying representation in cases where

    1) they do not need to handle specially the specific semantics of the exact media type, and,

    2) there is no special knowledge needed by such a generic processor in order to parse that underlying representation other than what would be needed to parse any example of that underlying representation.

Please correct me if the following is wrong:

It is my understanding that the general underlying representation of EXI-based types *may* be totally generic. However, each EXI type also pre-defines a dictionary specific to that type that the EXI representation may use to shorten the output. So if I hand a media type to a generic EXI parser, it will do fine until it hits something that is only defined in that type-specific dictionary. Unfortunately, the type-specific dictionary is not included in the EXI representation, but must be gathered out-of-band.

So it seems like +exi *could* be used if the representation stuck to only using the generic dictionary and eschewed any type-specific out-of-band dictionaries.

    Tony Hansen

On 4/11/2012 7:05 PM, Carsten Bormann wrote: 
On Apr 11, 2012, at 17:57, Ned Freed wrote:


And if this is the case, it really isn't suitable for a +exi suffix either.
+exi is supposed to mean the format can at least be parsed,  independent of any
knowledge of the type semantics. This is why I support the idea of having +ber
and +der but not +per - with +per you have to know the ASN.1 schema in order to
parse the material properly.

So how would you handle the PERs and (schema-informed) EXIs of this world?
Should it be -exi, not +exi?

(As in application/senml-exi?)

(Again, the media type registration will do a lot more than just tack EXI encoding on existing XML.)

Grüße, Carsten
--------------070301090504090504010304-- From ned.freed@mrochek.com Thu Apr 12 12:16: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 A275321F869D for ; Thu, 12 Apr 2012 12:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGw1M6go6EMr for ; Thu, 12 Apr 2012 12:16:37 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 16EC421F867F for ; Thu, 12 Apr 2012 12:16:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE8BMARU68008YI5@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 12 Apr 2012 12:16:35 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Thu, 12 Apr 2012 12:16:33 -0700 (PDT) Message-id: <01OE8BM9RF5Y00ZUIL@mauve.mrochek.com> Date: Thu, 12 Apr 2012 12:09:34 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 11 Apr 2012 03:50:48 -0400" <20120411075024.GN18899@jay.w3.org> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> To: Carine Bournez Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 19:16:37 -0000 > Hi, > On Wed, Apr 11, 2012 at 09:27:22AM +0300, Zach Shelby wrote: > > > > This draft is defining what you must define when registering a given foo+exi, thus I think we are in line with making sure constraints are specified. This draft *does not* intend to define a generic +exi suffix. > The title of the draft is "The +exi Media Type Suffix". Is there some > subtlety that I am missing entirely? If such a subtlety is there, I'm missing it too. > I don't think you can override or > define another draft for +exi once one is registered, that's the point > of registering. Exactly. > Let me clarify my point: I think defining a +exi suffix for schema-informed > mode saying "you must specify the form of schemaID that you are using" would > be a huge mistake. It is (1) not useful, since the EXI 1.0 spec already says > you have to define schemaID for your application, (2) harmful, since it tries > to redefine the mechanism for options that is already defined in EXI 1.0, > at least for the schema-informed mode. I remain to be convinced that +exi is a good idea or even allowable, but not for these reasons. The problem as I see it is that the point of + suffixes is to allow some degree of processing even though you don't know the specifics of the type. But this doesn't seem to be the case for +exi. > What's wrong with using Content-Encoding, exactly? Semantically, EXI *is* xml, > so having something like foo+xml vs. foo+exi does not make sense, while > *encoding* foo+xml with EXI makes sense. The main problem with encodings is that they are not intended to have this sort of structure. And more to the point, I doubt very much that existing software is prepared to deal with taking apart structured encoding names and figuring out if they have the necessary schema available. Ned From ned.freed@mrochek.com Thu Apr 12 14:01: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 90F3921F8730 for ; Thu, 12 Apr 2012 14:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYY3b8E1ea3Y for ; Thu, 12 Apr 2012 14:01:37 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5870821F872D for ; Thu, 12 Apr 2012 14:01:36 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE8FAF1RV4005JVJ@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 12 Apr 2012 14:01:32 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Thu, 12 Apr 2012 14:01:30 -0700 (PDT) Message-id: <01OE8FADTZ7S00ZUIL@mauve.mrochek.com> Date: Thu, 12 Apr 2012 13:57:00 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 12 Apr 2012 14:50:25 -0400" <4F8723F1.8080201@att.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <4F8723F1.8080201@att.com> To: Tony Hansen Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 21:01:37 -0000 > The Structured Syntax Suffixes are appropriate for use when the media > type identifies the semantics of the protocol payload. That is, knowing > the semantics of the specific media type provides for more specific > processing of the content than that afforded by generic processing of > the underlying representation. > At the same time, using the suffix provides receivers of the media types > to do generic processing of the underlying representation in cases where > 1) they do not need to handle specially the specific semantics of > the exact media type, and, > 2) there is no special knowledge needed by such a generic processor > in order to parse that underlying representation other than what would > be needed to parse any example of that underlying representation. > Please correct me if the following is wrong: > It is my understanding that the general underlying representation of > EXI-based types *may* be totally generic. However, each EXI type also > pre-defines a dictionary specific to that type that the EXI > representation may use to shorten the output. So if I hand a media type > to a generic EXI parser, it will do fine until it hits something that is > only defined in that type-specific dictionary. Unfortunately, the > type-specific dictionary is not included in the EXI representation, but > must be gathered out-of-band. Even this might, and I emphasize might, be barely acceptable if there was always a SchemaId in the content clearly identifying the necessary schema and such schemata are always generally available. But it has been clearly stated that that's not always the case. Indeed, one of the purposes of registering these types is apparently to specify the SchemaId default when one is not included. If that's the case, then this is really not acceptable. Media type registrations are not intended for this sort of automatic information extraction. Some other mechanism would have to be used, and we'd have to have a pretty serious discussion about the advisability of doing that. > So it seems like +exi *could* be used if the representation stuck to > only using the generic dictionary and eschewed any type-specific > out-of-band dictionaries. Agreed. That would make the definition of +exi acceptable. Whether or not that's an acceptable restriction for users of EXI is, of course, another question entirely. Ned From ned.freed@mrochek.com Thu Apr 12 14: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 7924421F8722 for ; Thu, 12 Apr 2012 14:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvzAHzbYIJJc for ; Thu, 12 Apr 2012 14:19:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id BC9B421F8762 for ; Thu, 12 Apr 2012 14:19:02 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE8FW37PW0001S16@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 12 Apr 2012 14:19:00 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Thu, 12 Apr 2012 14:18:58 -0700 (PDT) Message-id: <01OE8FW1U53G00ZUIL@mauve.mrochek.com> Date: Thu, 12 Apr 2012 14:15:49 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 12 Apr 2012 00:40:16 -0500" <4F866AC0.3000603@qualcomm.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4F866AC0.3000603@qualcomm.com> To: Pete Resnick Cc: draft-ietf-oauth-v2-bearer.all@tools.ietf.org, Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 21:19:03 -0000 > Folks, > Mark mentioned to me that he did not think one major issue in his review > of this document was fully addressed. I would like to get some feedback > from other folks here on the Apps-discuss list as I cannot say myself > that I fully understand the implications of the issue. > Mike Jones wrote: > > Mark Nottingham wrote: > > > >> * Section 2.3 URI Query Parameter > >> > >> This section effectively reserves a URI query parameter for the > >> draft's use. This should not be done lightly, since this would be a > >> precedent for the IETF encroaching upon a server's URIs (done > >> previously in RFC5785, but in a much more limited fashion, as a > >> tactic to prevent further, uncontrolled encroachment). > >> > >> Given that the draft already discourages the use of this mechanism, > >> I'd recommend dropping it altogether. If the Working Group wishes it > >> to remain, this issues should be vetted both through the APPS area > >> and the W3C liaison. > >> > >> (The same criticism could be leveled at Section 2.2 Form-Encoded Body > >> Parameter, but that at least isn't surfaced in an identifier) > > > > There are some contexts, especially limited browsers and/or > > development environments, where query parameters are usable but the > > other methods are not. Thus, the query parameter method must be > > retained. Also, Justin Richter's comments describing the value to him > > of the query parameter method are pertinent: A URL with all > > parameters including authorization is a powerful artifact which can be > > passed around between systems as a unit. > > > > As to using a standard parameter name, this is essential for > > interoperability. It is not reserved in any contexts other than when > > the Bearer spec is employed, which is a voluntary act by both > > parties. Thus, this poses no undue burdens or namespace restrictions > > on implementations in practice. > > > > Finally, you'll find that OAuth 1.0 [RFC 5849] similarly defined, not > > one, but two standard query parameter values: oauth_token and > > oauth_verifier. As this didn't cause any problems in practice then, > > I'm sure that defining an access_token parameter within the Bearer > > spec for interoperability purposes won't cause a problem either. > Would anyone (including, but not limited to, Mark) be able to better > explain the issue here? Pete, I think the issue is moot at this point. A quick google search clearly shows that this stuff is already deployed by multiple vendors, including use of access_token. As such, it is effectively impossible to change it at this point. I have to say I would have a lot more comfortable with a name like oauth_access_token that removes the possibility of conflict with other uses, but at this point it's a "grin and bear it" situation AFAICT. Ned From ned.freed@mrochek.com Thu Apr 12 14:34: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 23A5821F8779 for ; Thu, 12 Apr 2012 14:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmmH38YUNXlu for ; Thu, 12 Apr 2012 14:34:05 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8866421F8777 for ; Thu, 12 Apr 2012 14:34:04 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE8GFJ1UUO008L2X@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 12 Apr 2012 14:33:54 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Thu, 12 Apr 2012 14:33:51 -0700 (PDT) Message-id: <01OE8GFH6CVW00ZUIL@mauve.mrochek.com> Date: Thu, 12 Apr 2012 14:20:19 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 11 Apr 2012 22:26:11 +0300" <937A7D71-423A-4678-83A3-5704B125B744@sensinode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <937A7D71-423A-4678-83A3-5704B125B744@sensinode.com> To: Zach Shelby Cc: Julian Reschke , Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 21:34:06 -0000 > Ned, > On Apr 11, 2012, at 6:57 PM, Ned Freed wrote: > >> If decoding requires additional information, than IMHO you can't use > >> HTTP's Content-Coding or Transfer-Encoding. By all means, if you think > >> otherwise then send feedback to the HTTPbis WG. > > > > Julian is 100% correct here. If EXI requires knowledge of the type itself, it's > > not a separable encoding, which is what Content-Coding, Transfer-Encoding, and > > Content-Transfer-Encoding all require. And while I suppose we could adopt the > > foo+exi approach, having an explosion of encodings is a really bad idea. > > > > And if this is the case, it really isn't suitable for a +exi suffix either. > > +exi is supposed to mean the format can at least be parsed, independent of any > > knowledge of the type semantics. This is why I support the idea of having +ber > > and +der but not +per - with +per you have to know the ASN.1 schema in order to > > parse the material properly. > > > > For better or worse, we don't currently have a place in the architecture for > > these entities. We could define some other sort of type naming convention if > > there's really a need for it, but adding additional out of band information > > that has to be processed in order to interpret the material correctly is rather > > obviously highly problematic. > I agree with your analysis in general. Luckily the situation with EXI > schema-informed mode is not as bad as with PER. I'm afraid I'm not seeing any substantive difference. In fact PER might arguably be better, because if memory serves the OSI presentation layer included the means of negotiating use or non-use of PER as well as identifyin the specific ASN.1 schema involved. > We actually do have a schemaID field in the EXI header where some indication > about the OOB schema information can be included. The standard itself > however doesn't specify how to use that field. It is really a documentation > problem we're trying to solve, where the application/foo+exi registration > includes the definition of how to interpret the schemaID field of the EXI > header. But that's only part of the problem. Consistent interpretation of the field is of course necessary, but not sufficient. > Let me use SenML as a practical example. Here draft-jennings-senml-08 defines > a schema for use with the EXI serialization (version 1 of the markup). In the > application/senml+exi IANA registration, I would indicate that in the absence > of the schemaID field the schema is by default version 1 of SenML. And pray tell how is a generic +exi processor going to be able to know that? Your specification doesn't define any sort of registry for saying "media type foo has this schema as a default", nor is there any way to query such a registry, and it's an open question as to whether or not such a registry is viable or usable in this context. > For future versions, the integer of the SenML version is to be included in > the schemaID field. This way a single senml+exi registration can handle this, > and all future versions of the SenML markup. As I said in a previous email, mandating the presence of the SchemaID field might be an acceptable compromise. Or it might not. This is not up to me, and to be frank I'm still on the fence about this approach myself. Ned From ned.freed@mrochek.com Thu Apr 12 14:40: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 DB46E21F858F for ; Thu, 12 Apr 2012 14:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 240uj9iXOXTK for ; Thu, 12 Apr 2012 14:40:49 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 03BE021F8569 for ; Thu, 12 Apr 2012 14:40:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE8GO14J5C00CEDE@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 12 Apr 2012 14:40:45 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Thu, 12 Apr 2012 14:40:43 -0700 (PDT) Message-id: <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> Date: Thu, 12 Apr 2012 14:34:12 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 12 Apr 2012 01:05:45 +0200" <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> To: Carsten Bormann Cc: Ned Freed , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 21:40:50 -0000 > On Apr 11, 2012, at 17:57, Ned Freed wrote: > > And if this is the case, it really isn't suitable for a +exi suffix either. > > +exi is supposed to mean the format can at least be parsed, independent of any > > knowledge of the type semantics. This is why I support the idea of having +ber > > and +der but not +per - with +per you have to know the ASN.1 schema in order to > > parse the material properly. > So how would you handle the PERs and (schema-informed) EXIs of this world? > Should it be -exi, not +exi? > (As in application/senml-exi?) That's definitely an option - an informal sort of suffix. Another alternative would be to define some other formalism (it really cannot be "-" since other media types use "-" for other purposes). Looking at the ABNF of allowed characters, carat is allowed and I don't think it has ever been used. OTOH, how many things like EXI are ever going to show up? Ned From stpeter@stpeter.im Thu Apr 12 14: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 C956321F8731 for ; Thu, 12 Apr 2012 14:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.656 X-Spam-Level: X-Spam-Status: No, score=-102.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsTr09aEg6WV for ; Thu, 12 Apr 2012 14:57:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0A89921F86F4 for ; Thu, 12 Apr 2012 14:57:39 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6783940058; Thu, 12 Apr 2012 16:11:33 -0600 (MDT) Message-ID: <4F874FD0.3040203@stpeter.im> Date: Thu, 12 Apr 2012 15:57:36 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <9452079D1A51524AA5749AD23E0039280C4828@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280EC8C9@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280EC8C9@exch-mbx901.corp.cloudmark.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 21:57:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/12/12 12:09 PM, Murray S. Kucherawy wrote: > Just a reminder that this WGLC ends today. If anyone has any > reviews to report or comments to provide, please do so. I’d like > to hand it over to Barry this weekend if possible. Overall this looks very good. I have a few comments. 1. I wonder about this: In the case of registration for the IETF itself, the registration proposal MUST be published as an IETF Consensus RFC, which can be on the Standards Track, a BCP, Informational, or Experimental. Given the descriptions of Informational and Experimental documents in RFC 2026, I don't think we can say that they reflect IETF consensus. See in particular: An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. 2. It's not clear to me where open-source projects fit into the taxonomy. One might think that an organization like Mozilla is a "vendor" or "producer", according to Section 3.2: The vendor tree is used for media types associated with publicly available products. "Vendor" and "producer" are construed very broadly in this context and are considered equivalent. Note that industry consortia as well as non-commercial entities that do not qualify as recognized standards bodies can quite appropriately register media types in the vendor tree. However, Section 3.3 seems to add a further proviso regarding the commercial nature of a vendor or producer: Registrations for media types created experimentally or as part of products that are not distributed commercially may be registered in the personal or vanity tree. So, is commercial distribution a necessary feature of a vendor or producer? 3. I don't know if the unregistered "x." tree is truly consistent with draft-ietf-appsawg-xdash. I'm not saying it needs to be, but that would IMHO be desirable. Note that the xdash document, despite the name, is not limited to the literal string "x-" but applies more generally to similar constructs, such as "x.". Given that we are significantly easing the registration process in draft-ietf-appsawg-media-type-regs, do we still feel a need to even mention the "x." tree? I might provide further comments later today... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+HT9AACgkQNL8k5A2w/vzLfwCgpo9UmUJ2GubNgzNrf77rl/DE VaUAn3HPMEu0y1sCcrZhqE6sapr13oqh =wkGa -----END PGP SIGNATURE----- From ned.freed@mrochek.com Thu Apr 12 15:40: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 9FFA021F85B9 for ; Thu, 12 Apr 2012 15:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LX1+iDZqpVM for ; Thu, 12 Apr 2012 15:40:39 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAFC21F85B5 for ; Thu, 12 Apr 2012 15:40:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE8IR1220W00TCJ5@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 12 Apr 2012 15:40:26 -0700 (PDT) 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 <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Thu, 12 Apr 2012 15:40:24 -0700 (PDT) Message-id: <01OE8IQZIB1000ZUIL@mauve.mrochek.com> Date: Thu, 12 Apr 2012 15:23:49 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 12 Apr 2012 15:57:36 -0600" <4F874FD0.3040203@stpeter.im> References: <9452079D1A51524AA5749AD23E0039280C4828@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280EC8C9@exch-mbx901.corp.cloudmark.com> <4F874FD0.3040203@stpeter.im> To: Peter Saint-Andre Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 22:40:39 -0000 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > On 4/12/12 12:09 PM, Murray S. Kucherawy wrote: > > Just a reminder that this WGLC ends today. If anyone has any > > reviews to report or comments to provide, please do so. I’d like > > to hand it over to Barry this weekend if possible. > Overall this looks very good. I have a few comments. > 1. I wonder about this: > In the case of registration for the IETF itself, the registration > proposal MUST be published as an IETF Consensus RFC, which can be on > the Standards Track, a BCP, Informational, or Experimental. > Given the descriptions of Informational and Experimental documents in > RFC 2026, I don't think we can say that they reflect IETF consensus. You're reading it backwards. Nowhere does it say that all informational specifications reflect IETF consensus, but rather than some IETF Consensus RFCs can be published as informational. This is an incontrovertible fact, as is the fact that standards tree media types have been defined in informational specifications, and I suspect this will be done in the future as well. For better or worse, the fact that everything has to go in one of a small set of categories sometimes necessitates that awkward choices be made. But in the case of a standards tree registration in an RFC, the IESG has final say on that, including but not limited to assessing whether or not it makes sense for the type to be in the standards tree at all, irrespective of the document status. And I think this is already very clear. > See in particular: > An "Informational" specification is published for the general > information of the Internet community, and does not represent an > Internet community consensus or recommendation. Except that sometimes it does, and this has been true for a long time, RFC 2026 assertions notwithstanding. And in the case of it registering a media type in the standards tree, it has to. > 2. It's not clear to me where open-source projects fit into the > taxonomy. One might think that an organization like Mozilla is a > "vendor" or "producer", according to Section 3.2: According to their web site, the Mozilla Foundation qualifies as a non-commercial entity. > The vendor tree is used for media types associated with publicly > available products. "Vendor" and "producer" are construed very > broadly in this context and are considered equivalent. Note that > industry consortia as well as non-commercial entities that do not > qualify as recognized standards bodies can quite appropriately > register media types in the vendor tree. > However, Section 3.3 seems to add a further proviso regarding the > commercial nature of a vendor or producer: > Registrations for media types created experimentally or as part of > products that are not distributed commercially may be registered in > the personal or vanity tree. > So, is commercial distribution a necessary feature of a vendor or > producer? Once again you're reading things backwards. This is a restriction on who may register a personal or vanity type, nothing more. We really don't want types associated commercial entities showing up in the prs. tree. And I really don't see how you can read it any other way. The term "vendor tree" appears nowhere in this paragraph and the paragraph itself appears in a section talking about the prs. tree, so how can it possibly apply any sort of restriction on a different tree? > 3. I don't know if the unregistered "x." tree is truly consistent with > draft-ietf-appsawg-xdash. I'm not saying it needs to be, but that > would IMHO be desirable. Note that the xdash document, despite the > name, is not limited to the literal string "x-" but applies more > generally to similar constructs, such as "x.". Given that we are > significantly easing the registration process in > draft-ietf-appsawg-media-type-regs, do we still feel a need to even > mention the "x." tree? If there's a clear preference and consensus to drop it that's fine, but absent that I'm uncomfortable with removing it. Ned From mnot@mnot.net Thu Apr 12 16:05: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 7FF2921F86B4 for ; Thu, 12 Apr 2012 16:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.969 X-Spam-Level: X-Spam-Status: No, score=-104.969 tagged_above=-999 required=5 tests=[AWL=-2.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMog69RygEZQ for ; Thu, 12 Apr 2012 16:05:03 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6919C21F8625 for ; Thu, 12 Apr 2012 16:05:03 -0700 (PDT) Received: from [10.6.129.16] (unknown [50.56.228.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A831422E256; Thu, 12 Apr 2012 19:04:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <01OE8FW1U53G00ZUIL@mauve.mrochek.com> Date: Thu, 12 Apr 2012 18:04:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1257) Cc: Pete Resnick , Apps Discuss , draft-ietf-oauth-v2-bearer.all@tools.ietf.org Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 23:05:04 -0000 On 12/04/2012, at 4:15 PM, Ned Freed wrote: >=20 > Pete, I think the issue is moot at this point. A quick google search = clearly > shows that this stuff is already deployed by multiple vendors, = including use of > access_token. As such, it is effectively impossible to change it at = this point. >=20 > I have to say I would have a lot more comfortable with a name like > oauth_access_token that removes the possibility of conflict with other = uses, > but at this point it's a "grin and bear it" situation AFAICT. I would still like to see us do the right thing by the W3C, and I don't = see why the IESG can't insert language that cautions against this (as = well as future things like it). Besides which, those sites have chosen to adopt a private, pre-standard = convention for their Web sites; having a standard start to encroach on = their name space is a very different thing. Cheers, -- Mark Nottingham http://www.mnot.net/ From James.H.Manger@team.telstra.com Thu Apr 12 16:27: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 4131E21F867F for ; Thu, 12 Apr 2012 16:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qp8G2xMAmN4M for ; Thu, 12 Apr 2012 16:27:12 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 881DD21F8675 for ; Thu, 12 Apr 2012 16:27:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,414,1330866000"; d="scan'208";a="74386654" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 13 Apr 2012 09:27:11 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6678"; a="58959220" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipccni.tcif.telstra.com.au with ESMTP; 13 Apr 2012 09:27:10 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Fri, 13 Apr 2012 09:27:10 +1000 From: "Manger, James H" To: Julian Reschke , "apps-discuss@ietf.org" Date: Fri, 13 Apr 2012 09:27:09 +1000 Thread-Topic: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters Thread-Index: Ac0YwbSS9fhKKiN3SW6F364RGuT3pgAQfdAw Message-ID: <255B9BB34FB7D647A506DC292726F6E114F079AE69@WSMSG3153V.srv.dir.telstra.com> References: <4F86F5E9.1040202@gmx.de> In-Reply-To: <4F86F5E9.1040202@gmx.de> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 23:27:13 -0000 > a/b > > would simply become > > a%2fb > > and wouldn't need any further escaping in a URI path component. Not true. The % then needs escaping when you put the JSON pointer in a URI. a%252fb -- James Manger From sm@resistor.net Thu Apr 12 16:53: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 90F6421F8659 for ; Thu, 12 Apr 2012 16:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVhHy2JRGDAk for ; Thu, 12 Apr 2012 16:53:58 -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 8DBD321F8535 for ; Thu, 12 Apr 2012 16:53:58 -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 q3CNrnPM019507; Thu, 12 Apr 2012 16:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334274837; i=@resistor.net; bh=52uAj9cZ2Qz0Hc/fMMqF2SGH4WosVUGZ9WmKYFmkKjc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VlRlDaXNX0Uh1yUeoNv/HhsJdmHmWaiXnmvF9FS2fSAyJiAY/Fu11HCwqRZ1Eiow/ rjEcQaqtXvZ6+Ld0W1D9SheTqvzPpnGsUhHVnDWODA4ynobc6kIvJfOTjfIaBROZoK 48Ad7pmhVZYvO6357cuhFEw81TUg5An+fwCStGpw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334274837; i=@resistor.net; bh=52uAj9cZ2Qz0Hc/fMMqF2SGH4WosVUGZ9WmKYFmkKjc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GCTJqsn8bXe8Jz9vzIsBep4q6LOQBPxqFej3hThzLwHA/fvOfDauBJKhAevvR+aH9 aGpvrDZkaYuz6c51DP1unIPJU03yfnsCLGsOGVUq8bXgC3MemaHlO0h+MyxGU9fr/Y V36T+QmLuDpyEp2APtfSfgwnPJ6FB2N/098yCelQ= Message-Id: <6.2.5.6.2.20120412163839.0a800fd0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Apr 2012 16:52:55 -0700 To: Peter Saint-Andre From: SM In-Reply-To: <4F874FD0.3040203@stpeter.im> References: <9452079D1A51524AA5749AD23E0039280C4828@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280EC8C9@exch-mbx901.corp.cloudmark.com> <4F874FD0.3040203@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 23:53:59 -0000 Hi Peter, At 14:57 12-04-2012, Peter Saint-Andre wrote: >1. I wonder about this: > > In the case of registration for the IETF itself, the registration > proposal MUST be published as an IETF Consensus RFC, which can be on > the Standards Track, a BCP, Informational, or Experimental. > >Given the descriptions of Informational and Experimental documents in >RFC 2026, I don't think we can say that they reflect IETF consensus. >See in particular: The descriptions from RFC 2026 are no longer applicable. If you decide to argue about this on process grounds, you are correct and I am wrong. RFC 5471 defines the boilerplate text for an RFC in the IETF Stream which represents consensus. As this is the IETF, rumor has it that there might be a Standard Track document which does not represent IETF Consensus. "Registrations published in non-IETF RFC streams are allowed and require IESG approval." Documents in the IETF Stream also require IESG approval. The hurdle is lower for non-IETF streams. I don't have enough background information to comment on whether that should be changed. Regards, -sm From msk@cloudmark.com Thu Apr 12 17:09: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 AEEF821F870E for ; Thu, 12 Apr 2012 17:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQaSgz0xoYD9 for ; Thu, 12 Apr 2012 17:09:39 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id ADE8621F86CB for ; Thu, 12 Apr 2012 17:09:39 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id xC9f1i0010ZaKgw01C9fln; Thu, 12 Apr 2012 17:09:39 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=H85ZMpki c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=LD9JQlAwAFUA:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=nEgYUYOVEp9JdDSuo8gA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=CWqadYH1_exY0MUCqTUA:9 a=-AfBkavNvkEYwuLzAV0A:7 a=gKO2Hq4RSVkA:10 a=hTZeC7Yk6K0A:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 12 Apr 2012 17:09:39 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: WGLC for draft-ietf-appsawg-mime-default-charset Thread-Index: Ac0SkUIE/J9NYopZQNuNU3Uqul8O9gGeFE6w Date: Fri, 13 Apr 2012 00:09:37 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280EECA4@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280EECA4exchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334275779; bh=LasU+MhKCCOCLEWRk798WTyIk9WaHgHMRg58aGsXal4=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=Y2kkDSUXXvE4CzwGvqFVktLItQlKXpehMxsPsH0LV2QKj+kyxNzradoR5+czhDudD ru1dUC9ezlgRHpOodxUoBhmKXgbYzpOGk8HkPXf7tfyZDfy/1ahNn5BryfgjdTZhsT 3sytNBb8PlK2KZhYC4I/qDxwCM8tnBuAUgwxMB2o= Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 00:09:40 -0000 --_000_9452079D1A51524AA5749AD23E0039280EECA4exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, since a "last day" reminder brought a flurry of activity on the other= draft, let's see if this helps this one: A reminder that WGLC for this document ends a week from today. If anyone h= as any reviews to report or comments to provide, please do so sooner rather= than later. -MSK From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy Sent: Wednesday, April 04, 2012 11:32 AM To: apps-discuss@ietf.org Subject: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset This message starts Working Group Last Call for draft-ietf-appsawg-mime-def= ault-charset. Please review the document and provide comments to the list,= the co-chairs, or the authors by Friday, April 20th. The datatracker link is https://datatracker.ietf.org/doc/draft-ietf-appsawg= -mime-default-charset/. -MSK, APPSAWG co-chair --_000_9452079D1A51524AA5749AD23E0039280EECA4exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well, since a “l= ast day” reminder brought a flurry of activity on the other draft, le= t’s see if this helps this one:

 

A reminder that WGLC f= or this document ends a week from today.  If anyone has any reviews to report or= comments to provide, please do so sooner rather than later.

 

-MSK

 

From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Wednesday, April 04, 2012 11:32 AM
To: apps-discuss@ietf.org
Subject: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-cha= rset

 

This message starts Working Group Last Call for draf= t-ietf-appsawg-mime-default-charset.  Please review the document and p= rovide comments to the list, the co-chairs, or the authors by Friday, April= 20th.


The datatracker link is https://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/.

 

-MSK, APPSAWG co-chair

 

--_000_9452079D1A51524AA5749AD23E0039280EECA4exchmbx901corpclo_-- From ned.freed@mrochek.com Thu Apr 12 18:16:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3DF21F86F8 for ; Thu, 12 Apr 2012 18:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUY5bCThF5Ks for ; Thu, 12 Apr 2012 18:16:01 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7068821F86F6 for ; Thu, 12 Apr 2012 18:16:01 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE8O6VER1C008YST@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 12 Apr 2012 18:15:59 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Thu, 12 Apr 2012 18:15:57 -0700 (PDT) Message-id: <01OE8O6UFDOQ00ZUIL@mauve.mrochek.com> Date: Thu, 12 Apr 2012 17:33:39 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 09 Apr 2012 18:22:57 +0100" <4F831AF1.7000302@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <9452079D1A51524AA5749AD23E0039280C4828@exch-mbx901.corp.cloudmark.com> <4F831AF1.7000302@isode.com> To: Alexey Melnikov Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 01:16:02 -0000 > On 02/04/2012 06:08, Murray S. Kucherawy wrote: > > > > This message serves as the beginning of Working Group Last Call on > > draft-ietf-appsawg-media-type-regs, to end on Friday, April 13^th . > > Please review the document and provide any feedback to the authors > > directly or to apps-discuss@ietf.org . > > > > The datatracker page for the document: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/ > > > > > This is a very well written document, which includes lots of useful > improvements over the previous RFC. > I think there is a small list of issues (mostly nits or clarity issues) > that need addressing before IESG sees it. > 3.2. Vendor Tree > A registration may be placed in the vendor tree by anyone who needs > to interchange files associated with some product or set of products. > However, the registration properly belongs to the vendor or > organization producing the software that employs the type being > registered, and that vendor or organization can at any time elect to > assert ownership of the registration. > Can you expand a bit on what "assert ownership" means? Does this only apply > to third party registrations? What are the practical implications? How about I change it to read: A registration may be placed in the vendor tree by anyone who needs to interchange files associated with some product or set of products. However, the registration properly belongs to the vendor or organization producing the software that employs the type being registered, and that vendor or organization can at any time elect to assert ownership of a registration done by a third party in order to correct or update it. > For example, can the vendor/organization request removal of the registration > (I hope the answer to this question is "no".) Explicitly talking about deleting registrations is a place where we really don't want to go. There's nothing in the process that would allow someone to delete a registration, irrespective of whether or not they're considered to be the owner. That said, there are these things called lawsuits, and who knows what could result from one of those. > 4.2. Naming Requirements > Type and subtype names MUST conform to the following ABNF: > type-name = restricted-name > subtype-name = restricted-name > restricted-name = 1*127restricted-name-chars > restricted-name-chars = ALPHA / DIGIT / "!" / > "#" / "$" / "&" / "." / > "+" / "-" / "^" / "_" > Ok, this might be silly, but I thought I should ask: can a subtype-name > (or type-name) start with a dot? Such a type would necessarily be in a new tree with a blank name, and that requires an IETF standards action to create. I guess I could imagine, the, well, "tree with no name" making some sort of wierd sense for, I don't know, types that are supposed to be invisible or something. But most likely not. A type with a name beginning with #, $, or better still, & might be amusing though. And there's nothing AFAIK preventing those. I guess we could change the ABNF so that the first character has to be an ALPHA or DIGIT if we think it's worth the bother. Comments? > 4.2.1. Text Media Types > A "charset" parameter SHOULD NOT be specified when charset > information is transported inside the payload (e.g., as in "text/ > xml"). > As you are already referencing [I-D.ietf-appsawg-mime-default-charset] > Normatively, it would be good to make it clear that this document is merely > repeating requirements from [I-D.ietf-appsawg-mime-default-charset]. > (The same applies to the next paragraph, but there it is clearer.) I'll add something. > If a "charset" parameter is specified, it SHOULD be a required > parameter, eliminating the options of specifying a default value. If > there is a strong reason for the parameter to be optional despite > this advice, each subtype MAY specify its own default value, or > alternately, it MAY specify that there is no default value. Finally, > the "UTF-8" charset [RFC3629] SHOULD be selected as the default. See > [I-D.ietf-appsawg-mime-default-charset] for additional information on > the use of "charset" parameters in conjunction with subtypes of text. > 4.4. Canonicalization and Format Requirements > As such, teferences to > typo: references Fixed. > or inclusion of format specifications in registrations is encouraged > but not required. Note, however, that the public availability of a > meaningful specification will often make the difference between > simply having a name reserved so that there are no conflicts with > other uses and having the potential for other implementations of the > media type and useful interoperation with them. > 5.2.1. Provisional Registrations > Accordingly, a provisonal registration process is provided to support > early assigment of media type names. A provisional registration MAY > be submitted to IANA for standards tree types. The only required > fields in such registrations are the media type name and contact > information (inckuding the standards body name). > typo: including > Provisional registrations MAY be updated or abandoned at any time. > I am a bit concerned about "abandoned". It is true that the standardization > of a media type might not complete. But if the media type ends up being > deployed in any form, wouldn't it be better to mark it as OBSOLETE or > something like this instead? I.e. I would prefer for entries not being > deleted > from the registry. Bad idea. What if someone puts in a provisional registration for some type, then finds out that there's already widespread unregistered usage of that type under another name? What if the first name chosen doesn't deploy at all and then someone suggests a much better name? What if two people provisionally register what turns out to be the same thing at the same time? I could go on and on and on, but I think this makes the point. You're trying to optimize what is likely to be a fairly unlikely occurance - a name proves successful but registration is abandoned - at the expense of other far more likely cases, cases which if handled this way will lead to registration clutter. Like it or not, really have no choice here but to place some degree of trust in the people doing these registrations. In fact I'd go so far as to say the (sometimes only implied, sometimes all too explicit) lack of trust is at least part of the perception problem we're faced with in a more general sense. > 5.6. Change Procedures > Once a media type has been published by the IANA, the owner may > request a change to its definition. The descriptions of the > different registration trees above designate the "owners" of each > type of registration. The same procedure that would be appropriate > for the original registration request is used to process a change > request. > I don't remember seeing IETF (or IESG) being the owner of all Standards Tree > registration. Did I miss it? You missed it because it is intentionally not there. The owner of such registrations should be whatever standards body does the registration, not the IETF. I guess I could add a statement to that effect, but given the owner is necessarily what's going to be checked to see if they're an "authorized standards body", I think it just falls out of other considerations. > 6. Structured Syntax Suffix Registration Procedures > 3. Send a copy of the template or a pointer to the containing > document (with specific reference to the section with the > template) to the mailing list ietf-types@ietf.org, > I've noticed that everywhere else in the document you are using > ietf-types@iana.org. Although at the moment both mailing lists are going > to the same place, there is no guaranty that that would be true in the > future. > So I suggest you be consistent everywhere. Agreed, but in point of fact I'd prefer to change the name to something that doesn't have "ietf" in it. I'd prefer to use "media-types@iana.org", but I'm unsure of how to go about making such a change. Should I just change the address everywhere and ask IANA to create the new address in the IANA considerations section? > 10.1. Normative References > [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., > Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext > Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. > I think this reference is actually Informative. On examination I agree. Moved. > In Appendix A: it might be worth pointing out that submission to > ietf-types@iana.org for review is not an absolute requirement anymore. ??? Appendix A is about grandfather media types, and I see no reference to the mailing list there. Why would I want/need to introduce one? Ned From msk@cloudmark.com Thu Apr 12 18:40: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 C120121F865F for ; Thu, 12 Apr 2012 18:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.691 X-Spam-Level: X-Spam-Status: No, score=-102.691 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6r-C-0Hvs12 for ; Thu, 12 Apr 2012 18:40:32 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7245D21F865E for ; Thu, 12 Apr 2012 18:40:32 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id xDgb1i0030ZaKgw01DgcjN; Thu, 12 Apr 2012 18:40:36 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=SOLApZTH c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=strSrcXltg0A:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=BcE-ssbIbGKcfZFUe6oA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=FKXwgalrFVCz-rlS:21 a=onlh1RI1AhbZyvvm:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=MkHmZP10yDedWLSAgK0A:9 a=DG-iKsTtQOLk2qIG9MQA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=mXQqWcz0ub74hTxd:21 a=sG1mFCqCMv7tWQc3:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 12 Apr 2012 18:40:21 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: WGLC on draft-ietf-appsawg-media-type-regs Thread-Index: Ac0QjpwXS/k4kzTsSYSQ+Pgexg+sugISKdAQAA/BxhA= Date: Fri, 13 Apr 2012 01:40:20 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280EEE4C@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280C4828@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280EC8C9@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280EC8C9@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280EEE4Cexchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334281236; bh=JOy0qdxbh1ogbIBCWjXg/Qpn8HUEXGif2hJ9DgY9n50=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=A9HKE9aY4NW+oLIApUtCMcKrie+Yl/Tt+oryXrgOmC97g8TohY0G8LxwZC6hRL00B Tb4RFS9Pvh+FQa3fbSxWMbuxDe9IsyaoHsWnXotVdowOQ9j/dM7SNRnQWE8kbLhloa zJZlYD8B99K+QTL/QGrjulLEwSpLOqZG1vFsJWY8= Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 01:40:33 -0000 --_000_9452079D1A51524AA5749AD23E0039280EEE4Cexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, it actually ends tomorrow. But I'm glad all this chatter got starte= d on the second-last day rather than the last one. Maybe I'll use this tri= ck again in the future! -MSK From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy Sent: Thursday, April 12, 2012 11:09 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs Just a reminder that this WGLC ends today. If anyone has any reviews to re= port or comments to provide, please do so. I'd like to hand it over to Bar= ry this weekend if possible. -MSK From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Sunday, April 01, 2012 10:08 PM To: apps-discuss@ietf.org Subject: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs This message serves as the beginning of Working Group Last Call on draft-ie= tf-appsawg-media-type-regs, to end on Friday, April 13th. Please review th= e document and provide any feedback to the authors directly or to apps-disc= uss@ietf.org. The datatracker page for the document: https://datatracker.ietf.org/doc/dra= ft-ietf-appsawg-media-type-regs/ -MSK, APPSAWG co-chair --_000_9452079D1A51524AA5749AD23E0039280EEE4Cexchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry, it actually end= s tomorrow.  But I’m glad all this chatter got started on the se= cond-last day rather than the last one.  Maybe I’ll use this tri= ck again in the future!

 

-MSK=

 

From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 12, 2012 11:09 AM
To: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-re= gs

 

Just a reminder that t= his WGLC ends today.  If anyone has any reviews to report or comments = to provide, please do so.  I’d like to hand it over to Barry thi= s weekend if possible.

 

-MSK=

 
--_000_9452079D1A51524AA5749AD23E0039280EEE4Cexchmbx901corpclo_-- From ned.freed@mrochek.com Thu Apr 12 20:06: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 275B121F8736 for ; Thu, 12 Apr 2012 20:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP9bGYZ8jucL for ; Thu, 12 Apr 2012 20:06:20 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 58B2521F875C for ; Thu, 12 Apr 2012 20:06:18 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE8S1K09U8004F2K@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 12 Apr 2012 20:06:14 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Thu, 12 Apr 2012 20:06:11 -0700 (PDT) Message-id: <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> Date: Thu, 12 Apr 2012 19:49:51 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 12 Apr 2012 21:10:06 -0400" <4F877CEE.5030107@arcanedomain.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <4F877CEE.5030107@arcanedomain.com> To: Noah Mendelsohn Cc: john+ietf@jck.com, ned+ietf@mrochek.com, "www-tag@w3.org" , apps-discuss@ietf.org, tony+mtsuffix@maillennium.att.com Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 03:06:21 -0000 > The W3C Technical Architecture Group have been concerned about conflicting > sources of definitions of fragment identifier semantics located by > following RFC 3986 and the media type definition. We believe that those > defining and registering media types (including ones that follow generic > rules such as 3023bis) need more explicit advice than currently contained > within draft-ietf-appsawg-media-type-regs. > In particular, we are working on defining best practice for use and > definition of fragment identifier semantics, and the document > http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12 is under > development (although it has not been formally reviewed or approved by the > TAG). Referencing a developing draft, rather than a final specification, especially when the reference is pretty clearly going to be normative, is going to be a major problem. > We believe media type registration authors should be pointed to these > recommendations by reference from draft-ietf-appsawg-media-type-regs. See above. If my understanding of the rules is correct, that's really not possible until your specification is stable. What is something in the final version conflicts in some way? What if something in the final version is rejected by IETF consensus? This is exactly why I refrained from adding a reference to the xdash document until it was clearly stable, and why I considered every other alternative before very reluctantly adding a reference to the mime-default-charset specification. And these are both specifications internal to the IETF. > We would like to coordinate the development of these documents effectively > and would appreciate your feedback on how best to accomplish this. Well, not to put too fine a point on it, but it sure would have been nice to have been aware of this at some point in the last 10 months (the -00 version of this revision was posted as a draft on 13-Jun-2011), instead of on the day before the end of the WGLC. Anyway, since I'm just the editor here and not one of the people managing the process, I'm going to defer to the document shepard, WG chairs, and the Apps ADs as to what should happen now. But the one thing I'm definitely not going to do on my own is add a reference to a developing document. Ned From James.H.Manger@team.telstra.com Thu Apr 12 21:04: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 65DD821F8792 for ; Thu, 12 Apr 2012 21:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.591 X-Spam-Level: X-Spam-Status: No, score=-0.591 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwE+yBlSpbGA for ; Thu, 12 Apr 2012 21:04:59 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9A01421F8783 for ; Thu, 12 Apr 2012 21:04:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,414,1330866000"; d="scan'208";a="69534363" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 13 Apr 2012 14:04:57 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6678"; a="58317212" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccvi.tcif.telstra.com.au with ESMTP; 13 Apr 2012 14:04:57 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Fri, 13 Apr 2012 14:04:56 +1000 From: "Manger, James H" To: Julian Reschke , "apps-discuss@ietf.org" Date: Fri, 13 Apr 2012 14:04:55 +1000 Thread-Topic: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters Thread-Index: Ac0YwbSS9fhKKiN3SW6F364RGuT3pgAYKrbw Message-ID: <255B9BB34FB7D647A506DC292726F6E114F079B4E0@WSMSG3153V.srv.dir.telstra.com> References: <4F86F5E9.1040202@gmx.de> In-Reply-To: <4F86F5E9.1040202@gmx.de> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 04:04:59 -0000 If we really want URL-friendly escapes for JSON pointers pick '~' as the es= cape character. Use '~0' and '~1' as escapes for a '~' and '/' in a JSON me= mber name respectively. If we want a different separator (eg ';') to distin= guish arrays vs objects in pointers, escape it as '~2'. { "a/b": true, "c~d": false, "d":{"e":null}, "f;g":null, "h":[100,200] } JSON pointers to items in the above JSON value could be: /a~1b /c~0d /d/e /f~2g /h;0 These 5 can go in a URI query parameter or fragment without any %-escaping. You still need URI %-escaping for other characters (eg for pointer "/" = to fragment "#/%3Chi%3E") so the receiver always needs to do %-unescaping, = but there should be less confusion between JSON pointer and URI layers. It = is mostly harmless to apply %-escaping more than necessary (eg it doesn't m= atter whether or not the pointer "/a~1b" is put in a URI fragment as "#/a~1= b" or "#%2fa~1b" or "#%2fa%7eb"). -- James Manger From msk@cloudmark.com Thu Apr 12 23:12: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 7395E21F84B9 for ; Thu, 12 Apr 2012 23:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7r+JuZG9vZ2 for ; Thu, 12 Apr 2012 23:12:05 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id E591D21F8474 for ; Thu, 12 Apr 2012 23:12:05 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id xJC71i0010as01C01JC7cK; Thu, 12 Apr 2012 23:12:20 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=SOLApZTH c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=_y1Qy5JH2LwA:10 a=4zWJvGiJOd0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=9NGZVl_YAAAA:8 a=9aueKP-jAAAA:8 a=SSmOFEACAAAA:8 a=zQP7CpKOAAAA:8 a=07GO8HKJt7XY8mYe6mIA:9 a=CcNI5IP9WcsjrLIyOGoA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=I9DA3x22SqsA:10 a=jwvSBeqQ3e8A:10 a=69XIa8IdTDMA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Thu, 12 Apr 2012 23:11:52 -0700 From: "Murray S. Kucherawy" To: Ned Freed , Noah Mendelsohn Thread-Topic: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures Thread-Index: AQHNGSJoMJziXrzkM0OJ32UBsVMLtZaYRUvQ Date: Fri, 13 Apr 2012 06:11:51 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> In-Reply-To: <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334297540; bh=nXhEIYGK+wPPeK1XL5+sl93tMls1a/AhnTV0mVNBv/0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=mP/dolulCN43pcJnpeBqHjrZfTK/hYd4BPNBf6TvZKHLNJwi9CXdbxcwLGNYOBBOh 4uRuBPeDdVLP47Cacb+KO03NMc+2LKjoa1x1xZLC2ABAb8o4GWEyg+Bk9uzYx6otKq NAc5xslI7+MQURoP9viy5dgl8CPHSFupGUqRRUMw= Cc: "john+ietf@jck.com" , "apps-discuss@ietf.org" , "www-tag@w3.org" , "tony+mtsuffix@maillennium.att.com" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 06:12:06 -0000 Hello Noah, > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Ned Freed > Sent: Thursday, April 12, 2012 7:50 PM > To: Noah Mendelsohn > Cc: john+ietf@jck.com; ned+ietf@mrochek.com; www-tag@w3.org; apps-discuss= @ietf.org; tony+mtsuffix@maillennium.att.com > Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifica= tions and Registration Procedures >=20 > > The W3C Technical Architecture Group have been concerned about > > conflicting sources of definitions of fragment identifier semantics > > located by following RFC 3986 and the media type definition. We > > believe that those defining and registering media types (including > > ones that follow generic rules such as 3023bis) need more explicit > > advice than currently contained within draft-ietf-appsawg-media-type-re= gs. I'm the document shepherd and responsible working group co-chair for this d= ocument. I concur with Ned on all of his points, perhaps especially that t= he timing of this kind of input is unfortunate. Can you provide (hopefully quickly) more specifics about the advice you thi= nk is absent from the draft? -MSK, APPSAWG co-chair From zach@sensinode.com Thu Apr 12 23:27: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 DE92021F8587 for ; Thu, 12 Apr 2012 23:27:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKjSgSLNjpEw for ; Thu, 12 Apr 2012 23:27:36 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6EE21F857F for ; Thu, 12 Apr 2012 23:27:36 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3D6RSMO004349; Fri, 13 Apr 2012 09:27:28 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <01OE8FADTZ7S00ZUIL@mauve.mrochek.com> Date: Fri, 13 Apr 2012 09:27:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6203A26D-489B-44E5-9624-4CD0C1297C31@sensinode.com> References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <4F8723F1.8080201@att.com> <01OE8FADTZ7S00ZUIL@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 06:27:38 -0000 On Apr 12, 2012, at 11:57 PM, Ned Freed wrote: >> So it seems like +exi *could* be used if the representation stuck to >> only using the generic dictionary and eschewed any type-specific >> out-of-band dictionaries. >=20 > Agreed. That would make the definition of +exi acceptable. Whether or = not > that's an acceptable restriction for users of EXI is, of course, = another > question entirely. Using EXI in its normal mode is already fine as a content-encoding. The = problem we need to solve here is exactly the Schema-informed mode where = an indication of out-of-band dictionary information is needed, and where = the use of content-encoding is not really appropriate (as we all seem to = agree). Now I am as much on the fence as Ned it here about this. Seems we are in = a sticky situation where serializations that require OOB dictionary = information fall between RESTful cracks. Examples of these that I know = of include: - ASN.1 PER=20 - EXI Schema-informed mode - Google Protocol Buffers=20 - Surely more...=20 These tend to be applied in M2M and other applications where data = efficiency is extremely important and using OOB dictionary information = is what gives us that efficiency.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Thu Apr 12 23:39: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 4EB6021F8643 for ; Thu, 12 Apr 2012 23:39:10 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm9XYITNKjto for ; Thu, 12 Apr 2012 23:39:09 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0B221F860D for ; Thu, 12 Apr 2012 23:39:08 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3D6d7wh006475; Fri, 13 Apr 2012 09:39:07 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> Date: Fri, 13 Apr 2012 09:39:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 06:39:10 -0000 On Apr 13, 2012, at 12:34 AM, Ned Freed wrote: >> So how would you handle the PERs and (schema-informed) EXIs of this = world? >> Should it be -exi, not +exi? >=20 >> (As in application/senml-exi?) >=20 > That's definitely an option - an informal sort of suffix. Another = alternative > would be to define some other formalism (it really cannot be "-" since = other > media types use "-" for other purposes). Looking at the ABNF of = allowed > characters, carat is allowed and I don't think it has ever been used. = OTOH, how > many things like EXI are ever going to show up? This could be the right approach to look at. As I wrote in a previous = mail there are a few types of serializations that require OOB dictionary = information such as EXI schema-informed mode, ASN.1 PER, and Google = Protocol Buffers. =20 So application/senml^exi would need to result in some sort of registry = entry where information on how to determine the OOB dictionary is easily = available to anyone who runs across that media type. It seems to me that = the media type registry already contains quite a few fields that could = be used for that purpose -- for example "interoperability = considerations".=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From julian.reschke@gmx.de Fri Apr 13 00:12: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 987CC21F846C for ; Fri, 13 Apr 2012 00:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1HucCPGzHXZ for ; Fri, 13 Apr 2012 00:12:27 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6A1F821F846E for ; Fri, 13 Apr 2012 00:12:25 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2012 07:12:20 -0000 Received: from p57A6FBC6.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.251.198] by mail.gmx.net (mp029) with SMTP; 13 Apr 2012 09:12:20 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+nyLtLwzKnFGNLU+VGw60Fv6FD554QCpSd6Kfy1b 4APExPlUxQOu+N Message-ID: <4F87D1D4.6050302@gmx.de> Date: Fri, 13 Apr 2012 09:12:20 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <4F86F5E9.1040202@gmx.de> <255B9BB34FB7D647A506DC292726F6E114F079AE69@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F079AE69@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 07:12:27 -0000 On 2012-04-13 01:27, Manger, James H wrote: >> a/b >> >> would simply become >> >> a%2fb >> >> and wouldn't need any further escaping in a URI path component. > > Not true. The % then needs escaping when you put the JSON pointer in a URI. > > a%252fb > > -- > James Manger No. The whole idea is to produce a string that can be used as a valid URI path directly. Best regards, Julian From ned.freed@mrochek.com Fri Apr 13 00:53: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 77F9A21F8625 for ; Fri, 13 Apr 2012 00:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NR-Lg86HmgG0 for ; Fri, 13 Apr 2012 00:53:03 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4C50F21F849A for ; Fri, 13 Apr 2012 00:53:01 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE9220K5I8007AXE@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 13 Apr 2012 00:52:56 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Fri, 13 Apr 2012 00:52:53 -0700 (PDT) Message-id: <01OE921YMRSW00ZUIL@mauve.mrochek.com> Date: Fri, 13 Apr 2012 00:43:24 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 12 Apr 2012 18:04:53 -0500" <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> To: Mark Nottingham Cc: Pete Resnick , Ned Freed , draft-ietf-oauth-v2-bearer.all@tools.ietf.org, Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 07:53:03 -0000 > On 12/04/2012, at 4:15 PM, Ned Freed wrote: > > > > Pete, I think the issue is moot at this point. A quick google search clearly > > shows that this stuff is already deployed by multiple vendors, including use of > > access_token. As such, it is effectively impossible to change it at this point. > > > > I have to say I would have a lot more comfortable with a name like > > oauth_access_token that removes the possibility of conflict with other uses, > > but at this point it's a "grin and bear it" situation AFAICT. > I would still like to see us do the right thing by the W3C, and I don't see > why the IESG can't insert language that cautions against this (as well as > future things like it). I certainly don't object to doing that. In fact I don't object to dropping this nasty hack from the document, although perhaps documenting it as *not* standardized and explaining why it sucks would be even better. But I also think that believing this will prevent or even significantly limit it's use is probably unrealistic given how far it deployment appears to have gotten. Ned From sm@resistor.net Fri Apr 13 01:54: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 37BC821F846F for ; Fri, 13 Apr 2012 01:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE0jrzE7c37R for ; Fri, 13 Apr 2012 01:54:04 -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 0659021F85C0 for ; Fri, 13 Apr 2012 01:54:03 -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 q3D8rtoI015796 for ; Fri, 13 Apr 2012 01:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334307240; i=@resistor.net; bh=ZyV3kt+ijXSoIRrTScrGQcJZnSptVh/Lel1bd7ESg40=; h=Date:To:From:Subject:Cc; b=LdeoJMCnQaTY/tlRd4eh6pYtVOjtoGCVkaCQ9mrwGv5Ck26sFVQi3g2Pkwf7RYQjW zkGGTFIm8AA86ocVb8gnq5NzsbBcG5Wr+8OHym07gh0/z7e/Co/gCx5z68QXcV6F9g B5CLTnLomqFiEZiv2NhNn7op2NaDiiX3x0Q4ffQU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334307240; i=@resistor.net; bh=ZyV3kt+ijXSoIRrTScrGQcJZnSptVh/Lel1bd7ESg40=; h=Date:To:From:Subject:Cc; b=SIXM3hp0fK5OFCxHAvSXzgJDEAvULCKi46X8l+Uv7u3cQpRi1Z6AM6PIED/5dEFt0 MMSkQTqedvECNN125ZLZSKmKDRjTBwbDd2ixoGWgOLulze0pq8XzXb/MqShZDAtO1D sIFE8IWSVIwbL++RtVnESxJdb2ghc667lW47SUZM= Message-Id: <6.2.5.6.2.20120412232341.0ae76d78@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Apr 2012 01:26:14 -0700 To: apps-discuss@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Comments on draft-ietf-appsawg-media-type-regs-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, 13 Apr 2012 08:54:06 -0000 I'll defer to the authors for the following nits on draft-ietf-appsawg-media-type-regs-04. In Section 3.1: "The first procedure is used for registering registrations from IETF Consensus documents, or in rare cases when registering a grandfathered (see Appendix A) and/or otherwise incomplete registration is in the interest of the Internet community." Suggested text: The first procedure is used for registering registrations from IETF documents, or in rare cases when registering a grandfathered (see Appendix A) and/or otherwise incomplete registration is in the interest of the Internet community. The proposed change aligns the text with the "MUST" in the first paragraph of Section 3.1. "In the case of registration for the IETF itself, the registration proposal MUST be published as an IETF Consensus RFC, which can be on the Standards Track, a BCP, Informational, or Experimental." The text is redundant (see first paragraph of that section). Depending on what the objective is, the above text could be modified to refer to "Standards Action" or "IETF Review". In Section 3.2: "The vendor tree is used for media types associated with publicly available products." Peter raised a question about whether Mozilla is a vendor. It qualifies as a vendor. In Section 3.4: 'Subtype names with "x." as the first facet may be used for types intended exclusively for use in private, local environments. As I-D.ietf-appsawg-xdash is a work product of this working group, it does not make sense to register "x." for use in private, local environment. In Section 4.2.8: "The primary guideline for whether a structured type name suffix should be registerable is that it be described by a readily-available description, preferably within a document published by an established standards organization, and for which there's a reference that can be used in a References section of an RFC." I suggest prefacing "References" with "normative". In Section 4.2.9: "In some cases a single media type may have been widely deployed prior to registrion under multiple names." Typo: registration. "However, a list of deprecated aliases the type is known by MAY be supplied as additional information in order to assist application in processing the media type properly." Suggested text: to assist the software In Section 4.4: "A precise and openly available specification of the format of each media type MUST exist for all types registered in the standards tree and MUST at a minimum be referenced by, if it is not actually included in, the media type registration proposal itself." RFC 5226 has the following description for "Specification Required": "documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible" It's less hassle to align the terms instead of trying to figure out what "precise" or "openly available" means. Suggested text: A permanent and readily available publicly available specification, in sufficient detail so that interoperability between independent implementations is possible, of the format of each media type MUST exist for all types registered in the standards tree and MUST at a minimum be referenced by, if it is not actually included in, the media type registration proposal itself. "As such, teferences to or inclusion of format specifications in" Typo: references. In Section 4.6: 'The security considerations section of all registrations is subject to continuing evaluation and modification, and in particular MAY be extended by use of the "comments on media types" mechanism described in Section 5.4 below.' Is the intent to have ongoing evaluation with any updated information added as comments? BTW, "and modification" does not seem correct in the above. Does it mean that a registration made through a specification would require an update of the specification? In Section 4.10: "RFC publication of vendor and personal media type registrations is allowed but not required." I suggest "encouraged" instead of "allowed". "Additionally, any copyright on the registration template MUST allow the IANA to copy it into the IANA registry." There was a question some time back about copyright and IANA registries. I suggest going with the lesser restrictive copyright as inbound rights. That would allow derivative work as long as you don't claim that it is what's in the IANA registry. An alternative argument would be to require inbound rights to the IETF and leave IETF/IANA interaction as an internal issue. "To become Internet Standards, a protocol or data object must go through the IETF standards process." Suggested text: "To become an Internet Standard". "As discussed above, registration of a top-level type requires standards-track processing in the IETF and, hence, RFC publication." Suggested text: As discussed above, registration of a top-level type requires Standards Action in the IETF and, hence, the publication of a RFC on the Standards Track. In Section 5.2: "A web form for registration requests is also available:" This is an opportunity to fix the URL if someone thinks that it is worth the bother. Regards, -sm From julian.reschke@gmx.de Fri Apr 13 02:03: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 C19BD21F8587 for ; Fri, 13 Apr 2012 02:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.464 X-Spam-Level: X-Spam-Status: No, score=-103.464 tagged_above=-999 required=5 tests=[AWL=-0.865, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWuzFuHOExAM for ; Fri, 13 Apr 2012 02:03:23 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6670C21F8584 for ; Fri, 13 Apr 2012 02:03:22 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2012 09:03:20 -0000 Received: from p57A6FBC6.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.251.198] by mail.gmx.net (mp017) with SMTP; 13 Apr 2012 11:03:20 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/Ir7R8l4fI23PBydTEEUhNxhKN3zw7Q78ZN36lcp A7O6XY7WxLHVfU Message-ID: <4F87EBD4.90501@gmx.de> Date: Fri, 13 Apr 2012 11:03:16 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jeni Tennison References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ned Freed , apps-discuss@ietf.org, tony+mtsuffix@maillennium.att.com, Noah Mendelsohn , john+ietf@jck.com, "www-tag@w3.org List" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 09:03:23 -0000 On 2012-04-13 10:30, Jeni Tennison wrote: > Hi Murray, Ned, > ... I read your document this morning and I think it's really helpful. Now how to coordinate with the registration spec is indeed a tricky question. > (Not speaking for the TAG, just trying to give you a rapid response.) > > On 13 Apr 2012, at 07:11, Murray S. Kucherawy wrote: >> I'm the document shepherd and responsible working group co-chair for this document. I concur with Ned on all of his points, perhaps especially that the timing of this kind of input is unfortunate. > > I am really sorry that we haven't raised these issues more explicitly earlier in the process, and completely understand that you can't point to a draft document and don't want your publication to be held up. That's precisely why we want to discuss how best to manage providing guidance about fragment identifiers with you: it could be: > > * incorporating some specific text into the draft > * including a reference out to a document which we'll try to expedite through the W3C publication process > * adding some general hand-wavy text in the draft about guidance about fragids being available elsewhere > * not touching the media type specification draft but creating another draft specifically about fragment identifiers that can be published later that references and builds on it > > Basically I don't think we know how best to provide guidance about fragment identifiers in such a way that it's findable for those registering media types. > >> Can you provide (hopefully quickly) more specifics about the advice you think is absent from the draft? > > > What we see happening is that fragment identifier syntax is being specified at four levels: > > 1. the general pattern whereby plain name fragment identifiers are used to reference things related to the document, or named fragments within them > 2. generic syntax specified for top-level types (eg Media Fragment URIs [1]) Here be dragons. As far as I understand there is no inheritance of fragment identifier syntax from top-level types. The Media Fragment spec essentially has invented it; without coordinating with the IETF. > 3. generic syntax specified for types sharing a suffix (eg XPointer for XML [2]) > 4. specific syntax specified for individual media types > > Taking these in reverse order, I think what we're aiming for is: > > Media type registrants need to be guided to specify the fragment identifier schemes that they inherit from any top-level type or suffix type and how any clashes should be handled. They also need to be guided to reserve plain name fragment identifiers for their common use, and to think about what constraints the media type places on "active fragment identifiers" which may be used within scripts. If there is no multiple inheritance (from top level types), there should be fewer or no clashes at all. > Registrations for structured syntax suffix types need to include information about the interpretation of fragment identifiers in types with that suffix, and there should be a field along those lines on the registration form for them. Sounds right to me. > Fragment identifier schemes for top-level types also need to be findable somehow. If the media type specification draft is the only place that they are defined, then the references need to go in there. We should think about what would happen if someone came up with a fragment identifier scheme for, say, lines and characters in text files based on line/column numbering and how that would be found. > > I'm now the one tasked within the TAG on drafting the precise guidance. It seems to me that it isn't all that much text (if you cut out all the explanation and rationale that's in the draft we pointed you at [3]). It might be that if we can incorporate it directly within the media type specification draft that would be the quickest route, but I don't know. I'd really value your advice about the best way forward. > > Thanks, > > Jeni > > [1] http://www.w3.org/TR/media-frags/ > [2] http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html#frag Note that the draft above has never been submitted as Internet Draft, so from the IETF's point of view it doesn't exist. See . > [3] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12 Best regards, Julian From walter.stanish@gmail.com Fri Apr 13 02:54: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 371D721F8675 for ; Fri, 13 Apr 2012 02:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+clqPU7kCh0 for ; Fri, 13 Apr 2012 02:54:41 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 040B321F863C for ; Fri, 13 Apr 2012 02:54:40 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2762695bku.31 for ; Fri, 13 Apr 2012 02:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=lRh6yts9ozXP5SqLKtmy/dUIOyfCl4Bi1JLeTRBoDX8=; b=ZFM8oAL6V9ejgT0UClYJw8JwUIrL11yfB7ObyQjWJvM20GRkwpx/J77nJqw4z2gIIO IcYcdIccUGPVVOIQZwIP5YRRgJt4QXE4hfHcd0ezOvhpXPacgmbJJMNP1R1gCLuIGNai AFbUs1GkimOqI5OANIF8gdUCndmk5nUVCY+5xy+E9LwjYz32xfXVWiHEuEw1jBpprLyq Gu4qugVLyDWCy7sKP39Bw8AOGQ2nxZ8IuGbRN5lmptzwCd/T5bL3PBZAO74aSATnak1V Mns4ASTzOwJ8hrGDWmIt+ONMsTxcvL6GzE8rpgGQPUpMYTH7L5OpARt4DXYVFhxD6kOF HggA== MIME-Version: 1.0 Received: by 10.204.151.217 with SMTP id d25mr285761bkw.89.1334310879955; Fri, 13 Apr 2012 02:54:39 -0700 (PDT) Received: by 10.204.184.17 with HTTP; Fri, 13 Apr 2012 02:54:39 -0700 (PDT) Date: Fri, 13 Apr 2012 16:54:39 +0700 Message-ID: From: Walter To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: Barry Leiba , apps-discuss@ietf.org Subject: [apps-discuss] The Internet Financial EXchange (IFEX) Project X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 09:54:43 -0000 > PS: Development will continue elsewhere and an appropriate message > will be posted here once a venue is established, just for the record. The Internet Financial EXchange (IFEX) Project is an open body for the discussion and development of financial standards for the internet community. The project seeks to focus on enhancing interoperability between financial settlement systems of all types, including conventional financial systems, emerging digital currencies, alternative financial communities, and financial service providers. Interested parties are invited to review the proposals on the website at http://www.ifex-project.org/ and join the mailing list at http://group.ifex-project.org/ Two items on the site that may be of particular interest: (1) The latest version of the IIBAN Proposal (v1) for financial endpoint identification at http://www.ifex-project.org/our-proposals/iiban. This latest version includes initial IANA registry contents and a reference mechanism for financial endpoint transcription error correction. (Relevance: In contrast to settlement system-specific financial endpoint identifiers, IIBAN provides a democratically allocated, 13 character identifier that is already familiar in format to users in Europe and other countries and is theoretically compatible with conventional banking infrastructure in those regions. In addition, IIBAN is not tied to any specific financial commodity or settlement system, and provides strong protection against identifier transcription errors.) (2) The IFEX Protocol is a *work in progress* that hopes to bridge the gap between conventional financial systems, emerging digital currencies, alternative financial communities, and financial service providers by providing a standard protocol for transaction and settlement path negotiation with arbitrary financial instruments, currencies or assets. (Relevance: better connectivity, lower settlement fees, real time redundant financial routing, arbitrary instrument/currency/asset handling) How IFEX's proposed infrastructure differs from existing projects: - Not a currency, not a settlement-network, but a mechanism for bridging them. - Broader and more inclusive scope than existing vendor-specific APIs and conventional finance industry networking protocols. Global focus. No legacy 'features'. No artificial barriers to innovators. The hope is to move towards an open source implementation of the (work in progress) IFEX protocol that interoperates with major and emerging settlement networks for the benefit of all parts of the community. We have already had expressions of interest from representatives in a range of communities (Bitcoin, CES, Ripple, W3C Web Payments, digital currency exchange developers, etc.), and look forward your input on the mailing list. Happy Friday the 13th! Regards, Walter Stanish The IFEX Project http://www.ifex-project.org/ From carine@jay.w3.org Fri Apr 13 05:16: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 6AE5C21F8763 for ; Fri, 13 Apr 2012 05:16:00 -0700 (PDT) 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, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3P1yExRAua3 for ; Fri, 13 Apr 2012 05:16:00 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id EAC1721F86B5 for ; Fri, 13 Apr 2012 05:15:59 -0700 (PDT) Received: from carine by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1SIfPy-0007vU-FX; Fri, 13 Apr 2012 08:15:58 -0400 Date: Fri, 13 Apr 2012 08:15:58 -0400 From: Carine Bournez To: Carsten Bormann Message-ID: <20120413121558.GD696@jay.w3.org> References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <20120411164447.GA24351@jay.w3.org> <4DDB792A-4154-4C7B-A3EC-82573FE20D3E@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DDB792A-4154-4C7B-A3EC-82573FE20D3E@tzi.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 12:16:00 -0000 On Wed, Apr 11, 2012 at 10:43:07PM +0200, Carsten Bormann wrote: > > If foo has an application/foo media type for which the schema is known, > > the application readily knows which schema to use when receiving the EXI > > stream with the content-encoding header. > > Ah, SVG actually is a great example for why I think there need to be separate +exi registrations. > > So, for image/svg+xml (see http://www.w3.org/TR/SVG/mimereg.html), what is "the SVG schema"? There's currently no schema defined for use with EXI, for various reasons (other things in SVG are under discussion for future use with EXI). > What values of schemaId are defined, and what do they point to? The EXI 1.0 spec mentions the use of a URI as an example for schemaIds. > What about "application/svg+xml"? ?application/vnd.oipf.dae.svg+xml?? The +exi proposal would have the same question: either define the schema, or the mechanism to use schemaId, or another out-of-band mechanism. From jeni@jenitennison.com Fri Apr 13 01: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 C032221F8691 for ; Fri, 13 Apr 2012 01:31:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM+CSKTM0wfR for ; Fri, 13 Apr 2012 01:31:08 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7B921F8656 for ; Fri, 13 Apr 2012 01:31:07 -0700 (PDT) Received: from cpc19-epso4-2-0-cust100.6-3.cable.virginmedia.com ([86.30.196.101] helo=[192.168.123.64]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SIbuJ-0003mz-2q; Fri, 13 Apr 2012 09:31:03 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jeni Tennison In-Reply-To: <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> Date: Fri, 13 Apr 2012 09:30:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> To: "Murray S. Kucherawy" , Ned Freed X-Mailer: Apple Mail (2.1257) X-Mailcore-Auth: 9919842 X-Mailcore-Domain: 1066436 X-Mailman-Approved-At: Fri, 13 Apr 2012 08:06:09 -0700 Cc: Noah Mendelsohn , john+ietf@jck.com, apps-discuss@ietf.org, "www-tag@w3.org List" , tony+mtsuffix@maillennium.att.com Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 08:31:09 -0000 Hi Murray, Ned, (Not speaking for the TAG, just trying to give you a rapid response.) On 13 Apr 2012, at 07:11, Murray S. Kucherawy wrote: > I'm the document shepherd and responsible working group co-chair for = this document. I concur with Ned on all of his points, perhaps = especially that the timing of this kind of input is unfortunate. I am really sorry that we haven't raised these issues more explicitly = earlier in the process, and completely understand that you can't point = to a draft document and don't want your publication to be held up. = That's precisely why we want to discuss how best to manage providing = guidance about fragment identifiers with you: it could be: * incorporating some specific text into the draft * including a reference out to a document which we'll try to expedite = through the W3C publication process * adding some general hand-wavy text in the draft about guidance about = fragids being available elsewhere * not touching the media type specification draft but creating another = draft specifically about fragment identifiers that can be published = later that references and builds on it Basically I don't think we know how best to provide guidance about = fragment identifiers in such a way that it's findable for those = registering media types. > Can you provide (hopefully quickly) more specifics about the advice = you think is absent from the draft? What we see happening is that fragment identifier syntax is being = specified at four levels: 1. the general pattern whereby plain name fragment identifiers are = used to reference things related to the document, or named fragments = within them 2. generic syntax specified for top-level types (eg Media Fragment = URIs [1]) 3. generic syntax specified for types sharing a suffix (eg XPointer = for XML [2]) 4. specific syntax specified for individual media types Taking these in reverse order, I think what we're aiming for is: Media type registrants need to be guided to specify the fragment = identifier schemes that they inherit from any top-level type or suffix = type and how any clashes should be handled. They also need to be guided = to reserve plain name fragment identifiers for their common use, and to = think about what constraints the media type places on "active fragment = identifiers" which may be used within scripts. Registrations for structured syntax suffix types need to include = information about the interpretation of fragment identifiers in types = with that suffix, and there should be a field along those lines on the = registration form for them. Fragment identifier schemes for top-level types also need to be findable = somehow. If the media type specification draft is the only place that = they are defined, then the references need to go in there. We should = think about what would happen if someone came up with a fragment = identifier scheme for, say, lines and characters in text files based on = line/column numbering and how that would be found. I'm now the one tasked within the TAG on drafting the precise guidance. = It seems to me that it isn't all that much text (if you cut out all the = explanation and rationale that's in the draft we pointed you at [3]). It = might be that if we can incorporate it directly within the media type = specification draft that would be the quickest route, but I don't know. = I'd really value your advice about the best way forward. Thanks, Jeni [1] http://www.w3.org/TR/media-frags/ [2] = http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html= #frag [3] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12 --=20 Jeni Tennison http://www.jenitennison.com From jhildebr@cisco.com Thu Apr 12 08:49: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 6D0DD21F8698 for ; Thu, 12 Apr 2012 08:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEsYUDWVc72J for ; Thu, 12 Apr 2012 08:49:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id ACCDE21F8693 for ; Thu, 12 Apr 2012 08:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=1464; q=dns/txt; s=iport; t=1334245764; x=1335455364; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=sZCkP5xBJcg4wp7yJXzNEw1QzO5loxM8CqsOqVwnCic=; b=T6Iz53ilsW4XTvUnh/QkzeAFeoLrUqlMYck+EU8pVtqvZ4vQ5yj7vFo5 0E/iwgqOiz16SJEIWiOxv7lRkbW52bUQikbMaHB6SIZy8NZk2lftDZeW6 XYbeAUdzTmMz1OYEkKqzvPSenlMZ4RaD231Y0rGushE7tCnXvKDog46OH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUHADr4hk+tJXHB/2dsb2JhbABEuWUCgQeCCQEBAQMBAQEBDwEnAgExEA0BCG0wAQEEARIih14DBgULmmGgFASKM4dLBIhajRKOTYFpgwY X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="74152112" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 12 Apr 2012 15:49:24 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q3CFnN4I008731; Thu, 12 Apr 2012 15:49:23 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Apr 2012 10:49:23 -0500 Received: from 64.101.74.200 ([64.101.74.200]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Apr 2012 15:49:23 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 12 Apr 2012 09:49:22 -0600 From: Joe Hildebrand To: Julian Reschke , Message-ID: Thread-Topic: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters Thread-Index: Ac0Yw9QdrZE43NkDSkmjDdJb6XLhpg== In-Reply-To: <4F86F5E9.1040202@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Apr 2012 15:49:23.0391 (UTC) FILETIME=[D4F1ACF0:01CD18C3] X-Mailman-Approved-At: Fri, 13 Apr 2012 08:06:25 -0700 Subject: Re: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 15:49:25 -0000 I really like this. Would you unescape *all* %-encoded, or just the ones in that list? What about escape sequences that lead to invalid UTF-8, for example? On 4/12/12 9:34 AM, "Julian Reschke" wrote: > Hi there, > > right now, the draft escapes forward slashes in reference tokens using > ^-escapes, that is: > > a/b > > becomes > > a^/b > > and > > a^b > > becomes > > a^^b > > (Reminder: previously "\" was used, but it results in ugly double > escaping when the pointer occurs in a JSON string). > > A drawback of this scheme is that when the pointer is used inside a URI, > such as the path component of a an HTTP URI, the / still needs to be > escaped, so the name > > a/b > > becomes the pointer > > a^/b > > and would end up as > > a%5e%2fb > > in the URI. > > > An alternate proposal I heard during the IETF meeting in Paris was to > simply apply URI percent escaping to the characters in the URI > gen-delims range: > > gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" > > so > > a/b > > would simply become > > a%2fb > > and wouldn't need any further escaping in a URI path component. > > Feedback appreciated, > > Julian > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Joe Hildebrand From jhildebr@cisco.com Thu Apr 12 09: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 B191121F853B for ; Thu, 12 Apr 2012 09:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpiIQXgA5sDH for ; Thu, 12 Apr 2012 09:12:29 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4BA21F8559 for ; Thu, 12 Apr 2012 09:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=645; q=dns/txt; s=iport; t=1334247149; x=1335456749; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=sLQ5G6Er5tGYx1n5Yw1ZGZOKaQQJiCurT5Vk1PKwSuQ=; b=U6BFys1t2XzYWh0zdQDnszPE1ajH5ZMWr2KpHpzQishKjmRBqHVrqlbB Hu+ZEQ/xOcKwPz77R+B0hVw9GScesWUJDy5BMfnt/qBcFIBIYDP/gmNLm zGmZN5J+vbpQAnmK1KqpaZdX7OUW1mYWmNnuWSdjLkkbvKdMPOS5SwXHs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMIAHf+hk+tJV2b/2dsb2JhbABEiimvPAKBB4IJAQEBAwESAScCATwFDQEIGIEFAQEEDgUih14DBgWaPqATijOHSwSIWo0Sjk2BaYMG X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="74182928" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 12 Apr 2012 16:12:29 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3CGCThP032561; Thu, 12 Apr 2012 16:12:29 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Apr 2012 11:12:28 -0500 Received: from 64.101.74.200 ([64.101.74.200]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Apr 2012 16:12:28 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 12 Apr 2012 10:12:28 -0600 From: Joe Hildebrand To: Julian Reschke Message-ID: Thread-Topic: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters Thread-Index: Ac0Yxw48KClKvNreTUewk7A3PIVk0w== In-Reply-To: <4F86FA46.4020504@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Apr 2012 16:12:28.0843 (UTC) FILETIME=[0EBCDFB0:01CD18C7] X-Mailman-Approved-At: Fri, 13 Apr 2012 08:06:34 -0700 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2012 16:12:30 -0000 On 4/12/12 9:52 AM, "Julian Reschke" wrote: > On 2012-04-12 17:49, Joe Hildebrand wrote: >> I really like this. Would you unescape *all* %-encoded, or just the ones in >> that list? What about escape sequences that lead to invalid UTF-8, for >> example? >> ... > > Assuming that your question refers to the process of retrieving a > sequence of reference tokens from a URI path... > > I would > > 1) separate into URI path segments (using "/" as delimiter) > > 2) for each path segment, percent-unescape-then-UTF8-decode to obtain > the reference token That makes sense. -- Joe Hildebrand From nrm@arcanedomain.com Thu Apr 12 18:10: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 2B21021F86F5 for ; Thu, 12 Apr 2012 18:10:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-HSiT1nylDP for ; Thu, 12 Apr 2012 18:10:11 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id A420B21F86F8 for ; Thu, 12 Apr 2012 18:10:10 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 4787F598077; Thu, 12 Apr 2012 18:10:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=arcanedomain.com; h=message-id :date:from:mime-version:to:cc:subject:content-type: content-transfer-encoding; q=dns; s=arcanedomain.com; b=EGCkTH/g kWNoxPmIaGUTLDI/QlgBVZdcJeDE1OmTycQRgHFcZLN1vRRjJXKqjeni0visQaSI vHfcRL/ahCvfLDPnTivTCnu+aPjU7SU8KY+PQ3AmOdg+oq/duXrypgjbFGD5sK52 qwaSpD+PNMzo8Zi/8XCPcMD1eCharXFHg10= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=arcanedomain.com; h= message-id:date:from:mime-version:to:cc:subject:content-type: content-transfer-encoding; s=arcanedomain.com; bh=m9AyqOH1i1D+WV c5zFdE7MgAiQ4=; b=NrjO2yBnnfXHCjhxofbfOmWuLA1YGwhXyIFEVsyynqJqP0 Yx9fnCXV3hjjkvXbs6jikFyuGj7M3gdklsDnMu1F0gMKBusiz8xZtFgvKDALVKF2 Xc3hVHLXnDp6NYiBx3Had8fsDY5vq2L0YeWHcoonKYAAaCMRXTkdj/gSKXpjY= Received: from [192.168.1.40] (unknown [146.115.66.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: webmaster@arcanedomain.com) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id 76A9659807A; Thu, 12 Apr 2012 18:10:09 -0700 (PDT) Message-ID: <4F877CEE.5030107@arcanedomain.com> Date: Thu, 12 Apr 2012 21:10:06 -0400 From: Noah Mendelsohn User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: ned+ietf@mrochek.com, john+ietf@jck.com, tony+mtsuffix@maillennium.att.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 13 Apr 2012 08:06:43 -0700 Cc: "www-tag@w3.org" , apps-discuss@ietf.org Subject: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 01:10:12 -0000 The W3C Technical Architecture Group have been concerned about conflicting sources of definitions of fragment identifier semantics located by following RFC 3986 and the media type definition. We believe that those defining and registering media types (including ones that follow generic rules such as 3023bis) need more explicit advice than currently contained within draft-ietf-appsawg-media-type-regs. In particular, we are working on defining best practice for use and definition of fragment identifier semantics, and the document http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12 is under development (although it has not been formally reviewed or approved by the TAG). We believe media type registration authors should be pointed to these recommendations by reference from draft-ietf-appsawg-media-type-regs. We would like to coordinate the development of these documents effectively and would appreciate your feedback on how best to accomplish this. Noah Mendelsohn For the W3C Technical Architecture Group From tony@att.com Fri Apr 13 08:38: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 9FE4321F8694 for ; Fri, 13 Apr 2012 08:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.986 X-Spam-Level: X-Spam-Status: No, score=-102.986 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14NRTqzWrOGW for ; Fri, 13 Apr 2012 08:38:45 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF4421F865F for ; Fri, 13 Apr 2012 08:38:43 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 288488f4.0.920399.00-497.1869322.nbfkord-smmo08.seg.att.com (envelope-from ); Fri, 13 Apr 2012 15:38:43 +0000 (UTC) X-MXL-Hash: 4f88488306fda049-d4b0854a09b6be985fb70b9de577a5dec4c9d14b 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 q3DFcgH7005956 for ; Fri, 13 Apr 2012 11:38:42 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3DFcaWg005946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Apr 2012 11:38:37 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Fri, 13 Apr 2012 11:38:18 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3DFcIZ5007166 for ; Fri, 13 Apr 2012 11:38:18 -0400 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3DFcBXK006759 for ; Fri, 13 Apr 2012 11:38:11 -0400 Received: from [135.70.210.70] (vpn-135-70-210-70.vpn.east.att.com[135.70.210.70]) by maillennium.att.com (mailgw1) with ESMTP id <20120413153509gw1004orcke> (Authid: tony); Fri, 13 Apr 2012 15:35:09 +0000 X-Originating-IP: [135.70.210.70] Message-ID: <4F884862.9080609@att.com> Date: Fri, 13 Apr 2012 11:38:10 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org Discuss" References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> In-Reply-To: <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=GmzIfwDQVSsA:10 a=vnNYxAp2wzwA:10 a=BlG6E5tz_8] X-AnalysisOut: [UA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1] X-AnalysisOut: [0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=hJOe-NJtPjZI8glen-8A:9 a] X-AnalysisOut: [=wPNLvfGTeEIA:10] Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 15:38:45 -0000 At this point, I'm not seeing what application/senml*exi (for any character used for the '*') buys me over application/senml. The key point in my mind is that I have to know that it's senml in order to parse it. Knowing that it uses exi underneath doesn't buy me anything without also knowing that it is senml. That is, I have to know about the senml dictionary just in order to process the file. The type's schema is useful for understanding the XML, but it's not required in order to *parse* the file. Contrast this with application/anything+xml. Here I can parse it either as application/anything or as generic xml without knowing anything about the type anything, and get useful information out. The type's schema is useful for understanding the XML, but it's not required in order to *parse* the file. In other words, I don't think a *exi extension is going to buy me anything for processing the media type. So why use it? Note: this is a serious question. Is there useful stuff that can be done with an application/senml*exi file without knowing that it's senml? Tony Hansen On 4/13/2012 2:39 AM, Zach Shelby wrote: > On Apr 13, 2012, at 12:34 AM, Ned Freed wrote: > >>> So how would you handle the PERs and (schema-informed) EXIs of this world? >>> Should it be -exi, not +exi? >>> (As in application/senml-exi?) >> That's definitely an option - an informal sort of suffix. Another alternative >> would be to define some other formalism (it really cannot be "-" since other >> media types use "-" for other purposes). Looking at the ABNF of allowed >> characters, carat is allowed and I don't think it has ever been used. OTOH, how >> many things like EXI are ever going to show up? > This could be the right approach to look at. As I wrote in a previous mail there are a few types of serializations that require OOB dictionary information such as EXI schema-informed mode, ASN.1 PER, and Google Protocol Buffers. > > So application/senml^exi would need to result in some sort of registry entry where information on how to determine the OOB dictionary is easily available to anyone who runs across that media type. It seems to me that the media type registry already contains quite a few fields that could be used for that purpose -- for example "interoperability considerations". > > Zach > From cabo@tzi.org Fri Apr 13 08:50: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 35DA921F87E7 for ; Fri, 13 Apr 2012 08:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.432 X-Spam-Level: X-Spam-Status: No, score=-106.432 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIOBEWoqaiC4 for ; Fri, 13 Apr 2012 08:50:45 -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 6C8FA21F87E5 for ; Fri, 13 Apr 2012 08:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q3DFoXSL019575; Fri, 13 Apr 2012 17:50:34 +0200 (CEST) Received: from [192.168.217.105] (p5489A4AB.dip.t-dialin.net [84.137.164.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AA0FFFE0; Fri, 13 Apr 2012 17:50:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F884862.9080609@att.com> Date: Fri, 13 Apr 2012 17:50:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> <4F884862.9080609@att.com> To: Tony Hansen X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 15:50:46 -0000 > Note: this is a serious question. Is there useful stuff that can be = done with an application/senml*exi file without knowing that it's senml? (Assuming that this is about the schema-informed EXI version:) I don't think so. Calling it application/senml is still not very good because there are = also application/senml+json and application/senml+xml. So I would call the schema-informed version application/senml-exi. (Actually, I'd call it application/senml-exi-a and elide the EXI header, = but that is a different discussion.) Gr=FC=DFe, Carsten From ht@inf.ed.ac.uk Fri Apr 13 09:17: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 B698521F861A for ; Fri, 13 Apr 2012 09:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kntWWNvAAC0B for ; Fri, 13 Apr 2012 09:17:45 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id C22F721F8615 for ; Fri, 13 Apr 2012 09:17:44 -0700 (PDT) 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 q3DGHRIU028516; Fri, 13 Apr 2012 17:17:27 +0100 (BST) 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 q3DGHQsf008206; Fri, 13 Apr 2012 17:17:26 +0100 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 q3DGHQuu008349; Fri, 13 Apr 2012 17:17:26 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3DGHPOb008344; Fri, 13 Apr 2012 17:17:25 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Carsten Bormann References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> <4F884862.9080609@att.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 13 Apr 2012 17:17:25 +0100 In-Reply-To: (Carsten Bormann's message of "Fri, 13 Apr 2012 17:50:32 +0200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (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 Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:17:45 -0000 Carsten Bormann writes: >> Note: this is a serious question. Is there useful stuff that can be done with an application/senml*exi file without knowing that it's senml? > > (Assuming that this is about the schema-informed EXI version:) > > I don't think so. > > Calling it application/senml is still not very good because there are also application/senml+json and application/senml+xml. > > So I would call the schema-informed version application/senml-exi. > (Actually, I'd call it application/senml-exi-a and elide the EXI header, but that is a different discussion.) Why not call it application/senml+xml and encode it with EXI? Doesn't that tell you everything you need? Provided you put everything you need about schemaIDs for senml in the media type registration for application/senml+xml. 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 stephen.farrell@cs.tcd.ie Fri Apr 13 09: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 1F47221F867A; Fri, 13 Apr 2012 09:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBgl92suJQZS; Fri, 13 Apr 2012 09:22:45 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 23B0921F8675; Fri, 13 Apr 2012 09:22:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6410217147A; Fri, 13 Apr 2012 17:22:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334334164; bh=W1oxmRoO9QeZoe EXt7ex2zKBC+zTIb+cDNEEcEWNDpo=; b=tkE3QvnZfaJn9KAIHcz6G6QicT5BBg p0eqcaHcNhwkcdIfduuR+oIBbK5AR2QKSJ+QlzXdcpM2ThrruDS9Mlvxdn0AL6BG JtRK0uVSHQKdb62x9OPCWdEMAZnP8EGwFeiND23U4/1oOhhY8KvooYxdRPUCo4ny EIMdXCufoDFkhiA9Rs103FcLojZMMVARrRhkvBPVdG/GUvnps9Wwv/tavdKlGdOY m+WO6To0whOVgR92pQZJ0u6zynweseF7nzFsnv6yT2l+heCdOK6yzAiDidn4l9jJ XoramisPSQ3THFXlMoRVAkpYCoqbNNKGRXn3YiNCctH4uMi8C4bFScVQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Rce+sZwfP0o7; Fri, 13 Apr 2012 17:22:44 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DD3A7171479; Fri, 13 Apr 2012 17:22:43 +0100 (IST) Message-ID: <4F8852D0.4020404@cs.tcd.ie> Date: Fri, 13 Apr 2012 17:22:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "oauth@ietf.org WG" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> In-Reply-To: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 16:22:46 -0000 Hi All, So Hannes and Derek and I have been discussing this with the Apps ADs and Apps-area WG chairs. I've also read the docs now, and after all that we've decided that this topic (what to do with swd and webfinger) is best handled in the apps area and not in the oauth WG. The logic for that is that 1) the two proposals are doing the same thing and we don't want two different standards for that, b) this is not an oauth-specific thing nor is it a general security thing, and c) there is clearly already interest in the topic in the apps area so its reasonable for the oauth wg to use that when its ready. The appsawg chairs and apps ADs are ok with the work being done there. So:- - I've asked the oauth chairs to take doing work on swd out of the proposed new charter - It may be that you want to add something saying that oauth will use the results of work in the applications area on a web discovery protocol as a basis for doing the dynamic client registration work here - Discussion of webfinger and swd should move over to the apps-discuss list - Note: this is not picking one or the other approach, the plan is that the apps area will do any selection needed and figure out the best starting point for a standards-track RFC on web discovery and we'll use their fine work for doing more with oauth. Regards, Stephen. On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: > Hi all, > > those who had attended the last IETF meeting may have noticed the ongoing activity in the 'Applications Area Working Group' regarding Web Finger. > We had our discussion regarding Simple Web Discovery (SWD) as part of the re-chartering process. > > Here are the two specifications: > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 > http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 > > Now, the questions that seems to be hanging around are > > 1) Aren't these two mechanisms solving pretty much the same problem? > 2) Do we need to have two standards for the same functionality? > 3) Do you guys have a position or comments regarding either one of them? > > Ciao > Hannes > > PS: Please also let me know if your view is: "I don't really know what all this is about and the documents actually don't provide enough requirements to make a reasonable judgement about the solution space." > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From julian.reschke@gmx.de Fri Apr 13 09:29: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 6092B21F87CC for ; Fri, 13 Apr 2012 09:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.786 X-Spam-Level: X-Spam-Status: No, score=-102.786 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27J+0Kusx-V8 for ; Fri, 13 Apr 2012 09:29:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 422A821F8618 for ; Fri, 13 Apr 2012 09:29:35 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2012 16:29:33 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 13 Apr 2012 18:29:33 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+gKTIB8OSguetjH2y2iZnhwDxNShH2jRYslSc4oM jWQTj6LWc/BI1X Message-ID: <4F88546D.5020007@gmx.de> Date: Fri, 13 Apr 2012 18:29:33 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Henry S. Thompson" References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> <4F884862.9080609@att.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:29:36 -0000 On 2012-04-13 18:17, Henry S. Thompson wrote: > Carsten Bormann writes: > >>> Note: this is a serious question. Is there useful stuff that can be done with an application/senml*exi file without knowing that it's senml? >> >> (Assuming that this is about the schema-informed EXI version:) >> >> I don't think so. >> >> Calling it application/senml is still not very good because there are also application/senml+json and application/senml+xml. >> >> So I would call the schema-informed version application/senml-exi. >> (Actually, I'd call it application/senml-exi-a and elide the EXI header, but that is a different discussion.) > > Why not call it application/senml+xml and encode it with EXI? Doesn't > that tell you everything you need? Provided you put everything you > need about schemaIDs for senml in the media type registration for > application/senml+xml. You can't use +xml unless it's XML. Best regards, Julian From ht@inf.ed.ac.uk Fri Apr 13 09:36: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 83D4621F87F7 for ; Fri, 13 Apr 2012 09:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYdrA9PklCL4 for ; Fri, 13 Apr 2012 09:36:29 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4184B21F8694 for ; Fri, 13 Apr 2012 09:36:29 -0700 (PDT) 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 q3DGaR9u003166; Fri, 13 Apr 2012 17:36:27 +0100 (BST) 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 q3DGaRoF008692; Fri, 13 Apr 2012 17:36:27 +0100 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 q3DGaRrW008833; Fri, 13 Apr 2012 17:36:27 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3DGaRqL008829; Fri, 13 Apr 2012 17:36:27 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Julian Reschke References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> <4F884862.9080609@att.com> <4F88546D.5020007@gmx.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 13 Apr 2012 17:36:27 +0100 In-Reply-To: <4F88546D.5020007@gmx.de> (Julian Reschke's message of "Fri, 13 Apr 2012 18:29:33 +0200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (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 Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:36:30 -0000 Julian Reschke writes: > On 2012-04-13 18:17, Henry S. Thompson wrote: >> Carsten Bormann writes: >> >>>> Note: this is a serious question. Is there useful stuff that can be done with an application/senml*exi file without knowing that it's senml? >>> >>> (Assuming that this is about the schema-informed EXI version:) >>> >>> I don't think so. >>> >>> Calling it application/senml is still not very good because there are also application/senml+json and application/senml+xml. >>> >>> So I would call the schema-informed version application/senml-exi. >>> (Actually, I'd call it application/senml-exi-a and elide the EXI header, but that is a different discussion.) >> >> Why not call it application/senml+xml and encode it with EXI? Doesn't >> that tell you everything you need? Provided you put everything you >> need about schemaIDs for senml in the media type registration for >> application/senml+xml. > > You can't use +xml unless it's XML. But it _is_ XML if it's encoded using EXI. . . Surely the whole point of EXI is that it can be used to efficiently encode _any_ XML infoset. Are you telling me I can't use EXI with e.g. application/rdf+xml? 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 julian.reschke@gmx.de Fri Apr 13 09: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 215D921F8467 for ; Fri, 13 Apr 2012 09:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.776 X-Spam-Level: X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxpcGedDul-w for ; Fri, 13 Apr 2012 09:47:06 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D94D721F8455 for ; Fri, 13 Apr 2012 09:47:05 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2012 16:47:04 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 13 Apr 2012 18:47:04 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/WaXgTB6DWPR0+c8WppXsvIjJWshmtNLQAqUD64W 3FlBfa/Ybt6Gid Message-ID: <4F885889.5020401@gmx.de> Date: Fri, 13 Apr 2012 18:47:05 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Henry S. Thompson" References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> <4F884862.9080609@att.com> <4F88546D.5020007@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:47:07 -0000 On 2012-04-13 18:36, Henry S. Thompson wrote: > Julian Reschke writes: > >> On 2012-04-13 18:17, Henry S. Thompson wrote: >>> Carsten Bormann writes: >>> >>>>> Note: this is a serious question. Is there useful stuff that can be done with an application/senml*exi file without knowing that it's senml? >>>> >>>> (Assuming that this is about the schema-informed EXI version:) >>>> >>>> I don't think so. >>>> >>>> Calling it application/senml is still not very good because there are also application/senml+json and application/senml+xml. >>>> >>>> So I would call the schema-informed version application/senml-exi. >>>> (Actually, I'd call it application/senml-exi-a and elide the EXI header, but that is a different discussion.) >>> >>> Why not call it application/senml+xml and encode it with EXI? Doesn't >>> that tell you everything you need? Provided you put everything you >>> need about schemaIDs for senml in the media type registration for >>> application/senml+xml. >> >> You can't use +xml unless it's XML. > > But it _is_ XML if it's encoded using EXI. . . No. We're talking about bits on the wire, not data models. > Surely the whole point of EXI is that it can be used to efficiently > encode _any_ XML infoset. Are you telling me I can't use EXI with > e.g. application/rdf+xml? You can use EXI to compress application/rdf+xml, but once you did that it's not application/rdf+xml anymore. The same would be true for application/rdf+xml compressed with gzip (which reminds me about an epic debate we had last year about ".svgz"). Best regards, Julian From ht@inf.ed.ac.uk Fri Apr 13 10:04: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 3D47121F846E for ; Fri, 13 Apr 2012 10:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7awSMduCCfjO for ; Fri, 13 Apr 2012 10:04:35 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3F31221F8467 for ; Fri, 13 Apr 2012 10:04:35 -0700 (PDT) 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 q3DH4ILc008195; Fri, 13 Apr 2012 18:04:23 +0100 (BST) 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 q3DH4I5I009363; Fri, 13 Apr 2012 18:04:18 +0100 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 q3DH4Ik6009381; Fri, 13 Apr 2012 18:04:18 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3DH4IeB009376; Fri, 13 Apr 2012 18:04:18 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Julian Reschke References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> <4F884862.9080609@att.com> <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 13 Apr 2012 18:04:17 +0100 In-Reply-To: <4F885889.5020401@gmx.de> (Julian Reschke's message of "Fri, 13 Apr 2012 18:47:05 +0200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (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 Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:04:36 -0000 Julian Reschke writes: > HST wrote: > >> Surely the whole point of EXI is that it can be used to efficiently >> encode _any_ XML infoset. Are you telling me I can't use EXI with >> e.g. application/rdf+xml? > > You can use EXI to compress application/rdf+xml, but once you did that > it's not application/rdf+xml anymore. The same would be true for > application/rdf+xml compressed with gzip (which reminds me about an > epic debate we had last year about ".svgz"). What? Surely Content-Encoding is logically independent from, and processing-wise transparent wrt Content-Type. Here's what 2616 says: "The Content-Type entity-header field indicates the media type of the entity-body" and "The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. " So I take an entity-body which is application/rdf+xml, I encode it with gzip, I send it marked Content-Encoding: gzip Content-Type: application/rdf+xml The gzip-aware UA decodes the entity body with gunzip and hands over the result as application/rdf+xml. Same for exi, modulo the fudge about infoset vs. character sequence which was thrashed through wrt the 'exi' content-code. 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 julian.reschke@gmx.de Fri Apr 13 10:38: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 64C2C11E80A3 for ; Fri, 13 Apr 2012 10:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.377 X-Spam-Level: X-Spam-Status: No, score=-103.377 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bgx2lcalmSKT for ; Fri, 13 Apr 2012 10:38:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 13A3711E8086 for ; Fri, 13 Apr 2012 10:38:16 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2012 17:38:15 -0000 Received: from p57A6DDA5.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.221.165] by mail.gmx.net (mp020) with SMTP; 13 Apr 2012 19:38:15 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18x0uoxUl8xotWGkWWUITLnMaa5WKos8mX4KAyDkv NDdArLjMnzbTWN Message-ID: <4F886487.3050806@gmx.de> Date: Fri, 13 Apr 2012 19:38:15 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Henry S. Thompson" References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> <4F884862.9080609@att.com> <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:38:18 -0000 On 2012-04-13 19:04, Henry S. Thompson wrote: > ... >> You can use EXI to compress application/rdf+xml, but once you did that >> it's not application/rdf+xml anymore. The same would be true for >> application/rdf+xml compressed with gzip (which reminds me about an >> epic debate we had last year about ".svgz"). > > What? Surely Content-Encoding is logically independent from, and > processing-wise transparent wrt Content-Type. Yes. > Here's what 2616 says: > > "The Content-Type entity-header field indicates the media type of > the entity-body" > > and > > "The Content-Encoding entity-header field is used as a modifier to > the media-type. When present, its value indicates what additional > content codings have been applied to the entity-body, and thus what > decoding mechanisms must be applied in order to obtain the > media-type referenced by the Content-Type header field. " > > So I take an entity-body which is application/rdf+xml, I encode it > with gzip, I send it marked > > Content-Encoding: gzip > Content-Type: application/rdf+xml > > The gzip-aware UA decodes the entity body with gunzip and hands over > the result as application/rdf+xml. > > Same for exi, modulo the fudge about infoset vs. character sequence > which was thrashed through wrt the 'exi' content-code. > ... All true, but as far as I can tell, you didn't mention Content-Encoding in the message I replied to. Best regards, Julian From julian.reschke@gmx.de Fri Apr 13 10:43: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 1A4A521F865D for ; Fri, 13 Apr 2012 10:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.307 X-Spam-Level: X-Spam-Status: No, score=-103.307 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEZ5Xpv1Wg2b for ; Fri, 13 Apr 2012 10:43:02 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3DDA821F863F for ; Fri, 13 Apr 2012 10:43:01 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2012 17:42:59 -0000 Received: from p57A6DDA5.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.221.165] by mail.gmx.net (mp027) with SMTP; 13 Apr 2012 19:42:59 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+uXdwxHriuLdhtJkZXqwEPW1y8v10cTTsWG2upOt XjqN3QGZgC70Mv Message-ID: <4F8865A1.6090703@gmx.de> Date: Fri, 13 Apr 2012 19:42:57 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jeni Tennison References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ned Freed , apps-discuss@ietf.org, tony+mtsuffix@maillennium.att.com, Noah Mendelsohn , john+ietf@jck.com, "www-tag@w3.org List" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 17:43:03 -0000 On 2012-04-13 12:34, Jeni Tennison wrote: > Hi Julian, > > On 13 Apr 2012, at 10:03, Julian Reschke wrote: >> On 2012-04-13 10:30, Jeni Tennison wrote: >>> What we see happening is that fragment identifier syntax is being specified at four levels: >>> >>> 1. the general pattern whereby plain name fragment identifiers are used to reference things related to the document, or named fragments within them >>> 2. generic syntax specified for top-level types (eg Media Fragment URIs [1]) >> >> Here be dragons. >> >> As far as I understand there is no inheritance of fragment identifier syntax from top-level types. The Media Fragment spec essentially has invented it; without coordinating with the IETF. > > I think that their assumption was actually that all the image/*, video/* and audio/* types would re-register, referencing the Media Fragment spec. Perhaps that's the best way of handling it, and nothing needs to be said specifically about fragments identifiers for top-level types. > > In that case, the media type specification draft would need to point out that other media types within the same top-level type may describe the use of a particular fragment identifier syntax, and that if they do then to make content negotiation between different media types work more smoothly, it's best to adopt that same fragid syntax in new media types rather than inventing a new one. Makes sense. Can we turn this into advice for new media type registrations to be included into the updated registration spec? > ... Best regards, Julian From msk@cloudmark.com Fri Apr 13 10: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 EA9FC21F8797 for ; Fri, 13 Apr 2012 10:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwOFB7+gICBP for ; Fri, 13 Apr 2012 10:45:59 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 64C3C21F8786 for ; Fri, 13 Apr 2012 10:45:59 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id xVlZ1i0010as01C01VlZGx; Fri, 13 Apr 2012 10:45:36 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=H85ZMpki c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=Vhm4rtfK4QIA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=EGYWwU0pP8kselV1ijEA:9 a=TMeAxP0eBW1KDgzFfd8A:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 13 Apr 2012 10:45:33 -0700 From: "Murray S. Kucherawy" To: Stephen Farrell , "oauth@ietf.org WG" Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNGZGq3EJC/uqAeEiJeS7yiAAyipaZBtVQ Date: Fri, 13 Apr 2012 17:45:32 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> In-Reply-To: <4F8852D0.4020404@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334339136; bh=ZXjRX4lUDWq1QkHwOSk5FhP00wMJVfUHqavDsz4qz6Y=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=F3IkKM5QNg6j0mOnlTm8CvSKqOfwj2t63xHjZrsl1bSCvZj1Da/kdVPk7iv15kUcB hd2xmks0kOBAcFDg+aLtdD+RLHEnc9tLA2/ATdCJOpQefaZgA2X045zk4yj8W8MLg8 Ecc+VyaTOxNRGxZJ7WyjtepCvr6u9MOKaBgpxXnc= Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 17:46:00 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Stephen Farrell > Sent: Friday, April 13, 2012 9:23 AM > To: oauth@ietf.org WG > Cc: Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discover= y (SWD) >=20 > So Hannes and Derek and I have been discussing this with the Apps ADs > and Apps-area WG chairs. I've also read the docs now, and after all > that we've decided that this topic (what to do with swd and webfinger) > is best handled in the apps area and not in the oauth WG. >=20 > The logic for that is that 1) the two proposals are doing the same > thing and we don't want two different standards for that, b) this is > not an oauth-specific thing nor is it a general security thing, and c) > there is clearly already interest in the topic in the apps area so its > reasonable for the oauth wg to use that when its ready. >=20 > The appsawg chairs and apps ADs are ok with the work being done there. >=20 > So:- >=20 > - I've asked the oauth chairs to take doing work on swd > out of the proposed new charter > - It may be that you want to add something saying that > oauth will use the results of work in the applications > area on a web discovery protocol as a basis for doing > the dynamic client registration work here > - Discussion of webfinger and swd should move over to > the apps-discuss list > - Note: this is not picking one or the other approach, > the plan is that the apps area will do any selection > needed and figure out the best starting point for a > standards-track RFC on web discovery and we'll use their > fine work for doing more with oauth. Thank you Stephen, I think. :-) So the discussion on apps-discuss now should be focused on which of the two= should be the basis for forward progress. I've placed both documents in "= Call for Adoption" state in the datatracker for appsawg. Let the games begin. -MSK From ht@inf.ed.ac.uk Fri Apr 13 11:09: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 58CFC21F85DF for ; Fri, 13 Apr 2012 11:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOIgBWV2WulJ for ; Fri, 13 Apr 2012 11:09:22 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4681F21F8592 for ; Fri, 13 Apr 2012 11:09:22 -0700 (PDT) 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 q3DI91H1018405; Fri, 13 Apr 2012 19:09:06 +0100 (BST) 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 q3DI91rO010771; Fri, 13 Apr 2012 19:09:01 +0100 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 q3DI91rD010822; Fri, 13 Apr 2012 19:09:01 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3DI918p010818; Fri, 13 Apr 2012 19:09:01 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Julian Reschke References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> <4F884862.9080609@att.com> <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 13 Apr 2012 19:09:01 +0100 In-Reply-To: <4F886487.3050806@gmx.de> (Julian Reschke's message of "Fri, 13 Apr 2012 19:38:15 +0200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (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 Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 18:09:23 -0000 Julian Reschke writes: >> ... > > All true, but as far as I can tell, you didn't mention > Content-Encoding in the message I replied to. Ah, I see the disconnect. In my original message, I said: "Why not call it application/senml+xml and encode it with EXI? Doesn't that tell you everything you need?" I should have been more explicit -- what I meant the above to convey was "Why not call it application/senml+xml and encode it with EXI? That is, use Content-Type: application/senml+xml and Content-Encoding: exi . Doesn't that tell you everything you need?" So, reset. With that clarification, what do you think? 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 julian.reschke@gmx.de Fri Apr 13 11:17: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 1AD6421F8448 for ; Fri, 13 Apr 2012 11:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.248 X-Spam-Level: X-Spam-Status: No, score=-103.248 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+vFqSGjzO5V for ; Fri, 13 Apr 2012 11:17:01 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E94B411E8093 for ; Fri, 13 Apr 2012 11:17:00 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2012 18:16:59 -0000 Received: from p57A6DDA5.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.221.165] by mail.gmx.net (mp016) with SMTP; 13 Apr 2012 20:16:59 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+mW+t1dnqmF4zsOmbDSY0Si3dne1CQTDzbaaTW63 ldfsIujUI7yb9P Message-ID: <4F886D9B.9030203@gmx.de> Date: Fri, 13 Apr 2012 20:16:59 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Henry S. Thompson" References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> <4F884862.9080609@att.com> <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 18:17:02 -0000 On 2012-04-13 20:09, Henry S. Thompson wrote: > Julian Reschke writes: > >>> ... >> >> All true, but as far as I can tell, you didn't mention >> Content-Encoding in the message I replied to. > > Ah, I see the disconnect. In my original message, I said: > > "Why not call it application/senml+xml and encode it with EXI? > Doesn't that tell you everything you need?" > > I should have been more explicit -- what I meant the above to convey > was > > "Why not call it application/senml+xml and encode it with EXI? > That is, use Content-Type: application/senml+xml and > Content-Encoding: exi . > Doesn't that tell you everything you need?" > > So, reset. With that clarification, what do you think? Yes, absolutely, that works with HTTP. AFAIR, Core () doesn't have Content-Encoding, though. Best regards, Julian From ned.freed@mrochek.com Fri Apr 13 11:19: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 5612421F8615 for ; Fri, 13 Apr 2012 11:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BY73MTUyuPGx for ; Fri, 13 Apr 2012 11:19:40 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C8AFD21F8618 for ; Fri, 13 Apr 2012 11:19:40 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE9NX1RUEO001VHM@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 13 Apr 2012 11:19:38 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Fri, 13 Apr 2012 11:19:36 -0700 (PDT) Message-id: <01OE9NX0EXTM00ZUIL@mauve.mrochek.com> Date: Fri, 13 Apr 2012 11:14:38 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 13 Apr 2012 19:09:01 +0100" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> <4F884862.9080609@att.com> <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> To: ht@inf.ed.ac.uk Cc: Julian Reschke , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 18:19:41 -0000 > Julian Reschke writes: > >> ... > > > > All true, but as far as I can tell, you didn't mention > > Content-Encoding in the message I replied to. > Ah, I see the disconnect. In my original message, I said: > "Why not call it application/senml+xml and encode it with EXI? > Doesn't that tell you everything you need?" > I should have been more explicit -- what I meant the above to convey > was > "Why not call it application/senml+xml and encode it with EXI? > That is, use Content-Type: application/senml+xml and > Content-Encoding: exi . > Doesn't that tell you everything you need?" I'm a newcomer to all this myself, but I'm fairly sure the general answer to that is "no". This will work if the exi encoding isn't using schema-specific compression. But what if it is? Then you need to see start of the actual content before you can be sure you can decode it - it could contain a SchemaId pointing at a schema you do not have available for whatever reason. Or it could contain no SchemaId at all and you don't know what the default schema is for this type. So this would mess up negotiation schemes. Ned From julian.reschke@gmx.de Fri Apr 13 11:24: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 17BF521F86D4 for ; Fri, 13 Apr 2012 11:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjwYWWtymuzI for ; Fri, 13 Apr 2012 11:24:47 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4B4C821F86D3 for ; Fri, 13 Apr 2012 11:24:41 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2012 18:24:40 -0000 Received: from p57A6DDA5.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.221.165] by mail.gmx.net (mp010) with SMTP; 13 Apr 2012 20:24:40 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18TmpYXZ0wTek+aMdpVSP7YV1pX1/fNVHIsTApx0/ Z0TgeZB2C3SuJV Message-ID: <4F886F67.5090005@gmx.de> Date: Fri, 13 Apr 2012 20:24:39 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Henry S. Thompson" References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> <4F884862.9080609@att.com> <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> In-Reply-To: <4F886D9B.9030203@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 18:24:48 -0000 On 2012-04-13 20:16, Julian Reschke wrote: > On 2012-04-13 20:09, Henry S. Thompson wrote: >> Julian Reschke writes: >> >>>> ... >>> >>> All true, but as far as I can tell, you didn't mention >>> Content-Encoding in the message I replied to. >> >> Ah, I see the disconnect. In my original message, I said: >> >> "Why not call it application/senml+xml and encode it with EXI? >> Doesn't that tell you everything you need?" >> >> I should have been more explicit -- what I meant the above to convey >> was >> >> "Why not call it application/senml+xml and encode it with EXI? >> That is, use Content-Type: application/senml+xml and >> Content-Encoding: exi . >> Doesn't that tell you everything you need?" >> >> So, reset. With that clarification, what do you think? > > Yes, absolutely, that works with HTTP. > > AFAIR, Core () doesn't have > Content-Encoding, though. > ... ...with the constraint Ned mentioned in a parallel message (no out-of-band information needed). Best regards, Julian From zach@sensinode.com Fri Apr 13 11:25: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 B57E321F8726 for ; Fri, 13 Apr 2012 11:25:06 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P0tBMOKcPBq for ; Fri, 13 Apr 2012 11:25:05 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1AC21F8722 for ; Fri, 13 Apr 2012 11:25:04 -0700 (PDT) Received: from [192.168.1.102] (188-67-213-61.bb.dnainternet.fi [188.67.213.61]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3DIP0Hb023031; Fri, 13 Apr 2012 21:25:00 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4F886D9B.9030203@gmx.de> Date: Fri, 13 Apr 2012 21:24:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <20120402124522.GX16698@jay.w3.org> <8B84EAAD-CD22-4461-9BC6-AB78974A94A2@sensinode.com> <20120411075024.GN18899@jay.w3.org> <4F85410D.20802@toshiba.co.jp> <20120411085920.GP18899@jay.w3.org> <4F85A3A2.9000505@gmx.de> <01OE6QSJQ2EW00ZUIL@mauve.mrochek.com> <42487F00-DE42-49AA-9E4C-23412504C70A@tzi.org> <01OE8GNZLGKE00ZUIL@mauve.mrochek.com> <7AB551FC-03FC-4A89-8929-9E9017493C28@sensinode.com> <4F884862.9080609@att.com> <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 18:25:06 -0000 On Apr 13, 2012, at 9:16 PM, Julian Reschke wrote: > On 2012-04-13 20:09, Henry S. Thompson wrote: >> Julian Reschke writes: >>=20 >>>> ... >>>=20 >>> All true, but as far as I can tell, you didn't mention >>> Content-Encoding in the message I replied to. >>=20 >> Ah, I see the disconnect. In my original message, I said: >>=20 >> "Why not call it application/senml+xml and encode it with EXI? >> Doesn't that tell you everything you need?" >>=20 >> I should have been more explicit -- what I meant the above to convey >> was >>=20 >> "Why not call it application/senml+xml and encode it with EXI? >> That is, use Content-Type: application/senml+xml and >> Content-Encoding: exi . >> Doesn't that tell you everything you need?" >>=20 >> So, reset. With that clarification, what do you think? >=20 > Yes, absolutely, that works with HTTP. Correct, content-encoding is valid for the non-schema informed mode of = EXI where there is no OOB dictionary needed. There has never been an = argument against that, so all good there. We are trying to improve the interoperability situation with = schema-informed EXI (my +exi draft was an attempt at that). As Ned = pointed out though, for schema-informed EXI content-encoding is not = really valid, but at the same time +exi is not suitable either. For this = reason we are now looking at just using e.g. application/senml-exi = informally or possible thinking about a more formal suffix style for = encodings that require OOB dictionary information.=20 > AFAIR, Core () doesn't have = Content-Encoding, though. We actually fixed that in the -09 revision of CoAP. It is possible for = us to deal with content-encodings, we just have to make multiple code = entries in our registry.=20 Zach >=20 > Best regards, Julian > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From mnot@mnot.net Fri Apr 13 11:25: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 27A7A11E8098 for ; Fri, 13 Apr 2012 11:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.754 X-Spam-Level: X-Spam-Status: No, score=-104.754 tagged_above=-999 required=5 tests=[AWL=-2.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcOa7hldn5EM for ; Fri, 13 Apr 2012 11:25:35 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 61CB111E8093 for ; Fri, 13 Apr 2012 11:25:35 -0700 (PDT) Received: from [10.6.130.21] (unknown [50.56.228.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E815122E1EB; Fri, 13 Apr 2012 14:25:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Fri, 13 Apr 2012 13:25:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <03E644B3-EE1B-4858-AE72-40BB099CC5A1@mnot.net> References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> <0885CE0D-11A3-4396-9443-37B4FF8D36C9@mnot.net> To: Zach Shelby X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 18:25:36 -0000 OK. If you revise the draft, it might be helpful to add some examples to = Section 2 to illustrate this (I know it's already there, but examples do = help!). Cheers, On 11/04/2012, at 1:31 AM, Zach Shelby wrote: > On Mar 31, 2012, at 1:55 PM, Mark Nottingham wrote: >=20 >> What's the use case here? Content negotiation, or something else? >=20 > In particular this would be aimed at M2M applications that make use of = Schema-informed EXI. >=20 > - Content-negotiation when an application also uses other forms of its = base media type (+xml, +json etc.) > - Interoperability, this registration would force the schemaID to be = defined precisely and thus solve a problem in EXI. This is why the use = of this +exi form would only be for Schema informed use of EXI.=20 > - This use of EXI is *not* content-encoding in my opinion, thus we are = providing a better media type model and encouraging media types that = mean something semantically.=20 >=20 > Zach >=20 >>=20 >> Regards, >>=20 >>=20 >> On 29/03/2012, at 10:52 PM, Zach Shelby wrote: >>=20 >>> I have posted a new version of the +exi registration draft. This = version improves the Interoperability considerations of the registration = requirements and further clarifies when this suffix may be used, as per = the feedback on the list from Carine and others. >>>=20 >>> http://www.ietf.org/id/draft-shelby-exi-registration-01.txt >>>=20 >>> Regards, >>> Zach >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Date: March 29, 2012 10:47:32 PM GMT+02:00 >>>> To: zach@sensinode.com >>>> Subject: New Version Notification for = draft-shelby-exi-registration-01.txt >>>>=20 >>>> A new version of I-D, draft-shelby-exi-registration-01.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >>>>=20 >>>> Filename: draft-shelby-exi-registration >>>> Revision: 01 >>>> Title: The +exi Media Type Suffix >>>> Creation date: 2012-03-29 >>>> WG ID: Individual Submission >>>> Number of pages: 5 >>>>=20 >>>> Abstract: >>>> Efficient XML Interchange (EXI) is an XML representation technique >>>> specified by the W3C to provie a binary alternative to the standard >>>> text XML representation. This document defines a new Structure >>>> Syntax Suffix "+exi" for use in a specific class of = protocols, where >>>> "exi" content-type encoding or the generic = "application/exi" Media >>>> Type are not applicable. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>=20 >>> --=20 >>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>> http://www.sensinode.com >>> http://zachshelby.org - My blog "On the Internet of Things" >>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >>> Mobile: +358 40 7796297 >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> -- >> Mark Nottingham >> http://www.mnot.net/ >>=20 >>=20 >>=20 >>=20 >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 -- Mark Nottingham http://www.mnot.net/ From alexey.melnikov@isode.com Fri Apr 13 11:51: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 D52A011E80C1 for ; Fri, 13 Apr 2012 11:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB06Uu44NZNx for ; Fri, 13 Apr 2012 11:51:23 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3400611E8098 for ; Fri, 13 Apr 2012 11:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334343081; d=isode.com; s=selector; i=@isode.com; bh=gzDlRaQx2i6aQHbbObaMQ8239WjqFlCmzMQYB8I6fe8=; 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=iM8LazSliZr1kd5/j+YhMDjOpJV00l6RfFI4NODXg/F7cRH1ac8gg6GrRTqq+J8Hd2zcNy qZbkkLHPAuU6GhCevsGUmvQHSWTOr2hQHxFW1H9gpBXdlpIthc53O4/WNdzlTsqmcTbqxh 63iOPtwqGvxdU22BgwRef/ipBeAnlBs=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 13 Apr 2012 19:51:21 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F8875D1.1000502@isode.com> Date: Fri, 13 Apr 2012 19:52:01 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Julian Reschke References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> <01OE2UNN2HJ000ZUIL@mauve.mrochek.com> <4F82B5F6.3050806@gmx.de> <01OE3UQGECV600ZUIL@mauve.mrochek.com> <4F843332.7060705@isode.com> <4F8437E7.1070501@gmx.de> In-Reply-To: <4F8437E7.1070501@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 18:51:23 -0000 On 10/04/2012 14:38, Julian Reschke wrote: > On 2012-04-10 15:18, Alexey Melnikov wrote: >> ... >>> Not sure I see any need for a normative reference though. >> >> (I've mentioned my opinion to Julian, but I would like to state it for >> the record.) >> I think an update to RFC 2616 should have a reference to >> draft-ietf-appsawg-mime-default-charset and make it clear that the >> previous default was removed. An Informative reference to >> draft-ietf-appsawg-mime-default-charset should be fine. > > HTTPbis *does* make it clear that the default (overriding the base > spec) was removed. > > What's not clear to me is why it would need to reference > draft-ietf-appsawg-mime-default-charset. People who only read/implemented RFC 2616 need to be told that the rules changed. Similarly for people who read/implemented RFC 2046. Navigating through the maze of RFCs obsoleting each other is difficult for people who don't deal with them on a daily basis (and it is non trivial even for people who do). A reference to draft-ietf-appsawg-mime-default-charset would help with that. From alexey.melnikov@isode.com Fri Apr 13 12:11: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 A055511E80CB for ; Fri, 13 Apr 2012 12:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdSuP0tq7VXW for ; Fri, 13 Apr 2012 12:10:59 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 02AD011E807F for ; Fri, 13 Apr 2012 12:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334344258; d=isode.com; s=selector; i=@isode.com; bh=bPRYBupPXiLGNABeDIuDaWZRM04oO4aVIJXYYmDtaIg=; 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=J+Yf0w4AUdQfstWz7/aCyAE4WkhdUxJICxRNy6dZdkYeOlM7ZrxDEHqGEdHL/iTyTcCHLp lFa1g6AF0mIEmAN9+GxNDm+KGXlfyS6in6rxXMn/khT/UDjgKu/NP0gyyALudtpVCMVUKU dBZ3i+UhDfUyciTzgiiLGhrsemoXDDg=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 13 Apr 2012 20:10:57 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F887A6A.70503@isode.com> Date: Fri, 13 Apr 2012 20:11:38 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Ned Freed References: <9452079D1A51524AA5749AD23E0039280C4828@exch-mbx901.corp.cloudmark.com> <4F831AF1.7000302@isode.com> <01OE8O6UFDOQ00ZUIL@mauve.mrochek.com> In-Reply-To: <01OE8O6UFDOQ00ZUIL@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 19:11:00 -0000 Hi Ned, On 13/04/2012 01:33, Ned Freed wrote: >> On 02/04/2012 06:08, Murray S. Kucherawy wrote: >> > >> > This message serves as the beginning of Working Group Last Call on >> > draft-ietf-appsawg-media-type-regs, to end on Friday, April 13^th . >> > Please review the document and provide any feedback to the authors >> > directly or to apps-discuss@ietf.org . >> > >> > The datatracker page for the document: >> > https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/ >> > >> > >> This is a very well written document, which includes lots of useful >> improvements over the previous RFC. >> I think there is a small list of issues (mostly nits or clarity issues) >> that need addressing before IESG sees it. > >> 3.2. Vendor Tree > >> A registration may be placed in the vendor tree by anyone who needs >> to interchange files associated with some product or set of >> products. >> However, the registration properly belongs to the vendor or >> organization producing the software that employs the type being >> registered, and that vendor or organization can at any time elect to >> assert ownership of the registration. > >> Can you expand a bit on what "assert ownership" means? Does this only >> apply >> to third party registrations? What are the practical implications? > > How about I change it to read: > > A registration may be placed in the vendor tree by anyone who needs to > interchange files associated with some product or set of products. > However, > the registration properly belongs to the vendor or organization > producing the > software that employs the type being registered, and that vendor or > organization can at any time elect to assert ownership of a > registration done > by a third party in order to correct or update it. I like the new text, thanks! >> For example, can the vendor/organization request removal of the >> registration >> (I hope the answer to this question is "no".) > > Explicitly talking about deleting registrations is a place where we > really > don't want to go. There's nothing in the process that would allow > someone to > delete a registration, irrespective of whether or not they're > considered to be > the owner. That said, there are these things called lawsuits, and who > knows > what could result from one of those. All am really asking about is a statement in the document that entries are never deleted, but can be marked OBSOLETE instead. > >> 4.2. Naming Requirements > >> Type and subtype names MUST conform to the following ABNF: > >> type-name = restricted-name >> subtype-name = restricted-name > >> restricted-name = 1*127restricted-name-chars >> restricted-name-chars = ALPHA / DIGIT / "!" / >> "#" / "$" / "&" / "." / >> "+" / "-" / "^" / "_" > >> Ok, this might be silly, but I thought I should ask: can a subtype-name >> (or type-name) start with a dot? > > Such a type would necessarily be in a new tree with a blank name, and > that > requires an IETF standards action to create. Heh, Ok :-). > I guess I could imagine, the, > well, "tree with no name" making some sort of wierd sense for, I don't > know, > types that are supposed to be invisible or something. But most likely > not. > > A type with a name beginning with #, $, or better still, & might be > amusing > though. And there's nothing AFAIK preventing those. I guess we could > change the > ABNF so that the first character has to be an ALPHA or DIGIT if we > think it's > worth the bother. Comments? This is what I was thinking. >> 4.2.1. Text Media Types > >> A "charset" parameter SHOULD NOT be specified when charset >> information is transported inside the payload (e.g., as in "text/ >> xml"). > >> As you are already referencing [I-D.ietf-appsawg-mime-default-charset] >> Normatively, it would be good to make it clear that this document is >> merely >> repeating requirements from [I-D.ietf-appsawg-mime-default-charset]. >> (The same applies to the next paragraph, but there it is clearer.) > > I'll add something. > >> If a "charset" parameter is specified, it SHOULD be a required >> parameter, eliminating the options of specifying a default >> value. If >> there is a strong reason for the parameter to be optional despite >> this advice, each subtype MAY specify its own default value, or >> alternately, it MAY specify that there is no default value. >> Finally, >> the "UTF-8" charset [RFC3629] SHOULD be selected as the default. >> See >> [I-D.ietf-appsawg-mime-default-charset] for additional >> information on >> the use of "charset" parameters in conjunction with subtypes of >> text. > >> 4.4. Canonicalization and Format Requirements > >> As such, teferences to > >> typo: references > > Fixed. > >> or inclusion of format specifications in registrations is encouraged >> but not required. Note, however, that the public availability of a >> meaningful specification will often make the difference between >> simply having a name reserved so that there are no conflicts with >> other uses and having the potential for other implementations of the >> media type and useful interoperation with them. > > >> 5.2.1. Provisional Registrations > >> Accordingly, a provisonal registration process is provided to >> support >> early assigment of media type names. A provisional registration MAY >> be submitted to IANA for standards tree types. The only required >> fields in such registrations are the media type name and contact >> information (inckuding the standards body name). > >> typo: including > >> Provisional registrations MAY be updated or abandoned at any time. > >> I am a bit concerned about "abandoned". It is true that the >> standardization >> of a media type might not complete. But if the media type ends up being >> deployed in any form, wouldn't it be better to mark it as OBSOLETE or >> something like this instead? I.e. I would prefer for entries not being >> deleted from the registry. > > Bad idea. What if someone puts in a provisional registration for some > type, > then finds out that there's already widespread unregistered usage of > that type > under another name? What if the first name chosen doesn't deploy at > all and > then someone suggests a much better name? What if two people > provisionally > register what turns out to be the same thing at the same time? > > I could go on and on and on, but I think this makes the point. You're > trying to > optimize what is likely to be a fairly unlikely occurance - a name proves > successful but registration is abandoned - at the expense of other far > more > likely cases, cases which if handled this way will lead to registration > clutter. > > Like it or not, really have no choice here but to place some degree of > trust in > the people doing these registrations. In fact I'd go so far as to say the > (sometimes only implied, sometimes all too explicit) lack of trust is > at least > part of the perception problem we're faced with in a more general sense. I would feel more comfortable if you add some text about choices that are reasonable with some examples (from the above). Or maybe recommend preservation of the record if there is some indication of media type being in use. On a related note: is the Designated Expert going to be involved in this at all? (I.e., can the Designated Expert update the registration?) >> 5.6. Change Procedures > >> Once a media type has been published by the IANA, the owner may >> request a change to its definition. The descriptions of the >> different registration trees above designate the "owners" of each >> type of registration. The same procedure that would be appropriate >> for the original registration request is used to process a change >> request. > >> I don't remember seeing IETF (or IESG) being the owner of all >> Standards Tree >> registration. Did I miss it? > > You missed it because it is intentionally not there. The owner of such > registrations should be whatever standards body does the registration, > not the > IETF. I guess I could add a statement to that effect, but given the > owner is > necessarily what's going to be checked to see if they're an "authorized > standards body", I think it just falls out of other considerations. Ok, good point. >> 6. Structured Syntax Suffix Registration Procedures > >> 3. Send a copy of the template or a pointer to the containing >> document (with specific reference to the section with the >> template) to the mailing list ietf-types@ietf.org, > >> I've noticed that everywhere else in the document you are using >> ietf-types@iana.org. Although at the moment both mailing lists are going >> to the same place, there is no guaranty that that would be true in the >> future. >> So I suggest you be consistent everywhere. > > Agreed, but in point of fact I'd prefer to change the name to > something that > doesn't have "ietf" in it. I'd prefer to use "media-types@iana.org", > but I'm > unsure of how to go about making such a change. Should I just change the > address everywhere and ask IANA to create the new address in the IANA > considerations section? Yes. Also it would be worth telling IANA to keep the old one as an alias, but this can be communicated to IANA out-of-band. >> 10.1. Normative References > >> [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., >> Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext >> Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. > >> I think this reference is actually Informative. > > On examination I agree. Moved. > >> In Appendix A: it might be worth pointing out that submission to >> ietf-types@iana.org for review is not an absolute requirement anymore. > > ??? Appendix A is about grandfather media types, and I see no > reference to the > mailing list there. Why would I want/need to introduce one? I meant the Appendix with changes since the previous RFC. > > Ned From julian.reschke@gmx.de Fri Apr 13 12:18: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 2119E11E80E0 for ; Fri, 13 Apr 2012 12:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.155 X-Spam-Level: X-Spam-Status: No, score=-103.155 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rB8F8KrFsYJX for ; Fri, 13 Apr 2012 12:18:55 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3A37B11E80D6 for ; Fri, 13 Apr 2012 12:18:55 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2012 19:18:54 -0000 Received: from p57A6DDA5.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.221.165] by mail.gmx.net (mp002) with SMTP; 13 Apr 2012 21:18:54 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19P9CECFfFPuH1SccFe5r59mTiHTdddiyETDwo1jm pepGhHXqpYPXio Message-ID: <4F887C1C.7050306@gmx.de> Date: Fri, 13 Apr 2012 21:18:52 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> <01OE2UNN2HJ000ZUIL@mauve.mrochek.com> <4F82B5F6.3050806@gmx.de> <01OE3UQGECV600ZUIL@mauve.mrochek.com> <4F843332.7060705@isode.com> <4F8437E7.1070501@gmx.de> <4F8875D1.1000502@isode.com> In-Reply-To: <4F8875D1.1000502@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 19:18:56 -0000 On 2012-04-13 20:52, Alexey Melnikov wrote: > On 10/04/2012 14:38, Julian Reschke wrote: >> On 2012-04-10 15:18, Alexey Melnikov wrote: >>> ... >>>> Not sure I see any need for a normative reference though. >>> >>> (I've mentioned my opinion to Julian, but I would like to state it for >>> the record.) >>> I think an update to RFC 2616 should have a reference to >>> draft-ietf-appsawg-mime-default-charset and make it clear that the >>> previous default was removed. An Informative reference to >>> draft-ietf-appsawg-mime-default-charset should be fine. >> >> HTTPbis *does* make it clear that the default (overriding the base >> spec) was removed. >> >> What's not clear to me is why it would need to reference >> draft-ietf-appsawg-mime-default-charset. > People who only read/implemented RFC 2616 need to be told that the rules > changed. Similarly for people who read/implemented RFC 2046. Navigating > through the maze of RFCs obsoleting each other is difficult for people > who don't deal with them on a daily basis (and it is non trivial even > for people who do). A reference to > draft-ietf-appsawg-mime-default-charset would help with that. I'm still not convinced. HTTPbis removes the default, and states so in the "Changes from RFC 2616" section. How does a reference to draft-ietf-appsawg-mime-default-charset make things better? Best regards, Julian From john@jck.com Fri Apr 13 12:53: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 ECAB521F8833 for ; Fri, 13 Apr 2012 12:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNCjGGcTJBs3 for ; Fri, 13 Apr 2012 12:53:26 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 138E521F8832 for ; Fri, 13 Apr 2012 12:53:26 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SImTK-000GDs-Gd; Fri, 13 Apr 2012 15:47:54 -0400 Date: Fri, 13 Apr 2012 15:53:10 -0400 From: John C Klensin To: Ned Freed , Mark Nottingham Message-ID: <0D4BD162580A7D4CE6A01C71@PST.JCK.COM> In-Reply-To: <01OE921YMRSW00ZUIL@mauve.mrochek.com> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Pete Resnick , Apps Discuss , draft-ietf-oauth-v2-bearer.all@tools.ietf.org Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 19:53:27 -0000 --On Friday, April 13, 2012 00:43 -0700 Ned Freed wrote: >> On 12/04/2012, at 4:15 PM, Ned Freed wrote: >> > >> > Pete, I think the issue is moot at this point. A quick >> > google search clearly shows that this stuff is already >> > deployed by multiple vendors, including use of >> > access_token. As such, it is effectively impossible to >> > change it at this point. >> > >> > I have to say I would have a lot more comfortable with a >> > name like oauth_access_token that removes the possibility >> > of conflict with other uses, but at this point it's a "grin >> > and bear it" situation AFAICT. > >> I would still like to see us do the right thing by the W3C, >> and I don't see why the IESG can't insert language that >> cautions against this (as well as future things like it). > > I certainly don't object to doing that. In fact I don't object > to dropping this nasty hack from the document, although > perhaps documenting it as *not* standardized and explaining > why it sucks would be even better. > > But I also think that believing this will prevent or even > significantly limit it's use is probably unrealistic given how > far it deployment appears to have gotten. Agreeing that the horse has left the barn and is far down the street, the IETF is still being asked to publish this and publish it with some level of authority that we call "IETF Consensus" and/or "Standard". Recommendation: (1) For reasons explained in my earlier note, prune this down to one recommended/standardized method, not three. (2) For any other methods, document them as existing practice (and consequently alternatives) and _at least_ discuss the reasons for and against using them. (3) If the recommendation is to use a reserved query parameter keyword, seriously consider making that keyword something like "oauth_access_token" but noting that "access_token" is in use as a synonym and that, while we discourage it, servers SHOULD normally treat it as a synonym. I disagree with Ned to the extent that, as a firm believer in Murphy's Law and the general perversity of the universe, I would have said "reduce", rather than "remove", the possibility of conflict, but even "reduce" would be A Good Thing. (4) The document should explain the risks associated with someone using "?access_token" to mean something else entirely and of parsing, hashing, or encoding URL tails in ways that effectively disable the intent of the spec. I think that represents a reasonable balance with reality and existing practice while avoiding IETF endorsement of practices we have ample reason to believe are undesirable and should not be encouraged or endorsed. An alternative would be to not standardize this at all but simply publish a slightly-revised version of the document as an Informational description of existing practice, noting W3C endorsement to whatever degree that is appropriate. I actually don't think that is a particularly good idea, but it would be another way out. best, john From john-ietf@jck.com Fri Apr 13 12:53: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 8AF8A21F883B for ; Fri, 13 Apr 2012 12:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5t5fLy9WrkC for ; Fri, 13 Apr 2012 12:53:58 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5101221F883A for ; Fri, 13 Apr 2012 12:53:58 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SImTv-000GE2-7Z; Fri, 13 Apr 2012 15:48:31 -0400 Date: Fri, 13 Apr 2012 15:53:46 -0400 From: John C Klensin To: Ned Freed , Mark Nottingham Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Pete Resnick , Apps Discuss , draft-ietf-oauth-v2-bearer.all@tools.ietf.org Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 19:53:58 -0000 --On Friday, April 13, 2012 00:43 -0700 Ned Freed wrote: >> On 12/04/2012, at 4:15 PM, Ned Freed wrote: >> > >> > Pete, I think the issue is moot at this point. A quick >> > google search clearly shows that this stuff is already >> > deployed by multiple vendors, including use of >> > access_token. As such, it is effectively impossible to >> > change it at this point. >> > >> > I have to say I would have a lot more comfortable with a >> > name like oauth_access_token that removes the possibility >> > of conflict with other uses, but at this point it's a "grin >> > and bear it" situation AFAICT. > >> I would still like to see us do the right thing by the W3C, >> and I don't see why the IESG can't insert language that >> cautions against this (as well as future things like it). > > I certainly don't object to doing that. In fact I don't object > to dropping this nasty hack from the document, although > perhaps documenting it as *not* standardized and explaining > why it sucks would be even better. > > But I also think that believing this will prevent or even > significantly limit it's use is probably unrealistic given how > far it deployment appears to have gotten. Agreeing that the horse has left the barn and is far down the street, the IETF is still being asked to publish this and publish it with some level of authority that we call "IETF Consensus" and/or "Standard". Recommendation: (1) For reasons explained in my earlier note, prune this down to one recommended/standardized method, not three. (2) For any other methods, document them as existing practice (and consequently alternatives) and _at least_ discuss the reasons for and against using them. (3) If the recommendation is to use a reserved query parameter keyword, seriously consider making that keyword something like "oauth_access_token" but noting that "access_token" is in use as a synonym and that, while we discourage it, servers SHOULD normally treat it as a synonym. I disagree with Ned to the extent that, as a firm believer in Murphy's Law and the general perversity of the universe, I would have said "reduce", rather than "remove", the possibility of conflict, but even "reduce" would be A Good Thing. (4) The document should explain the risks associated with someone using "?access_token" to mean something else entirely and of parsing, hashing, or encoding URL tails in ways that effectively disable the intent of the spec. I think that represents a reasonable balance with reality and existing practice while avoiding IETF endorsement of practices we have ample reason to believe are undesirable and should not be encouraged or endorsed. An alternative would be to not standardize this at all but simply publish a slightly-revised version of the document as an Informational description of existing practice, noting W3C endorsement to whatever degree that is appropriate. I actually don't think that is a particularly good idea, but it would be another way out. best, john From carine@jay.w3.org Fri Apr 13 13:02: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 9F6CB21F8534 for ; Fri, 13 Apr 2012 13:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHqLG1Iox5Aj for ; Fri, 13 Apr 2012 13:02:22 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0937D21F84EA for ; Fri, 13 Apr 2012 13:02:21 -0700 (PDT) Received: from carine by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1SImhC-0002QD-M4; Fri, 13 Apr 2012 16:02:14 -0400 Date: Fri, 13 Apr 2012 16:02:14 -0400 From: Carine Bournez To: Julian Reschke Message-ID: <20120413200214.GE696@jay.w3.org> References: <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F886F67.5090005@gmx.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:02:22 -0000 On Fri, Apr 13, 2012 at 08:24:39PM +0200, Julian Reschke wrote: >>>> >>>> All true, but as far as I can tell, you didn't mention >>>> Content-Encoding in the message I replied to. >>> >>> Ah, I see the disconnect. In my original message, I said: >>> >>> "Why not call it application/senml+xml and encode it with EXI? >>> Doesn't that tell you everything you need?" >>> >>> I should have been more explicit -- what I meant the above to convey >>> was >>> >>> "Why not call it application/senml+xml and encode it with EXI? >>> That is, use Content-Type: application/senml+xml and >>> Content-Encoding: exi . >>> Doesn't that tell you everything you need?" >>> >>> So, reset. With that clarification, what do you think? >> >> Yes, absolutely, that works with HTTP. >> >> AFAIR, Core () doesn't have >> Content-Encoding, though. >> ... > > ...with the constraint Ned mentioned in a parallel message (no > out-of-band information needed). I suppose that the registration for application/senml+xml could mandate use of a particular schema when encoded with EXI and exclude any additional schema (i.e. no schemaId allowed). -- Carine Bournez -+- W3C Europe From julian.reschke@gmx.de Fri Apr 13 13:16:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870B521F85DF for ; Fri, 13 Apr 2012 13:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.118 X-Spam-Level: X-Spam-Status: No, score=-103.118 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GxZRTQDgeBJ for ; Fri, 13 Apr 2012 13:16:31 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9A1DD21F85DD for ; Fri, 13 Apr 2012 13:16:30 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2012 20:16:29 -0000 Received: from p57A6DDA5.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.221.165] by mail.gmx.net (mp028) with SMTP; 13 Apr 2012 22:16:29 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19F+eM34L9F2b6f9qt6C146Du/NnL6NqYkV0lBYoF alxATwwDHYn8kl Message-ID: <4F88899D.3090405@gmx.de> Date: Fri, 13 Apr 2012 22:16:29 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Carine Bournez References: <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org> In-Reply-To: <20120413200214.GE696@jay.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 Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:16:31 -0000 On 2012-04-13 22:02, Carine Bournez wrote: > ... > I suppose that the registration for application/senml+xml could > mandate use of a particular schema when encoded with EXI and exclude > any additional schema (i.e. no schemaId allowed). > ... Nope. Content-Encoding and media type are orthogonal things. Best regards, Julian From ht@inf.ed.ac.uk Fri Apr 13 13:28: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 C05EB11E80E5 for ; Fri, 13 Apr 2012 13:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9ft4XyzNPeo for ; Fri, 13 Apr 2012 13:28:23 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id F381911E80F1 for ; Fri, 13 Apr 2012 13:28:19 -0700 (PDT) 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 q3DKS15M002254; Fri, 13 Apr 2012 21:28:01 +0100 (BST) 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 q3DKS1WZ013056; Fri, 13 Apr 2012 21:28:01 +0100 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 q3DKS0bp013690; Fri, 13 Apr 2012 21:28:00 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3DKS05i013686; Fri, 13 Apr 2012 21:28:00 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Julian Reschke References: <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org> <4F88899D.3090405@gmx.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 13 Apr 2012 21:28:00 +0100 In-Reply-To: <4F88899D.3090405@gmx.de> (Julian Reschke's message of "Fri, 13 Apr 2012 22:16:29 +0200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (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 Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:28:24 -0000 Julian Reschke writes: > On 2012-04-13 22:02, Carine Bournez wrote: >> ... >> I suppose that the registration for application/senml+xml could >> mandate use of a particular schema when encoded with EXI and exclude >> any additional schema (i.e. no schemaId allowed). >> ... > > Nope. Content-Encoding and media type are orthogonal things. But she said "when encoded with EXI". Why can't a media type registration say that, literally? That is "When encoding with EXI, use this schema: [ref] and schemaID: http://...". 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 julian.reschke@gmx.de Fri Apr 13 13:31: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 1275811E80FA for ; Fri, 13 Apr 2012 13:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.086 X-Spam-Level: X-Spam-Status: No, score=-103.086 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2fuRmTdEcvD for ; Fri, 13 Apr 2012 13:31:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id ED28411E80F6 for ; Fri, 13 Apr 2012 13:30:59 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2012 20:30:58 -0000 Received: from p57A6DDA5.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.221.165] by mail.gmx.net (mp070) with SMTP; 13 Apr 2012 22:30:58 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18X1GsaSVIXBAtlE6fffw+CZw6B77UzyWMOlTwtdb JQOXrP97EoYul6 Message-ID: <4F888D02.7050802@gmx.de> Date: Fri, 13 Apr 2012 22:30:58 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Henry S. Thompson" References: <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org> <4F88899D.3090405@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:31:06 -0000 On 2012-04-13 22:28, Henry S. Thompson wrote: > Julian Reschke writes: > >> On 2012-04-13 22:02, Carine Bournez wrote: >>> ... >>> I suppose that the registration for application/senml+xml could >>> mandate use of a particular schema when encoded with EXI and exclude >>> any additional schema (i.e. no schemaId allowed). >>> ... >> >> Nope. Content-Encoding and media type are orthogonal things. > > But she said "when encoded with EXI". Why can't a media type > registration say that, literally? That is "When encoding with EXI, > use this schema: [ref] and schemaID: http://...". Back to our confusion :-) Yes, you can use EXI, but you can't use EXI-as-a-HTTP-Content-Encoding in this case. The HTTP Content Encoding must be fully defined in absence of any out-of-band information. For instance, a recipient (say browser) needs to be able to remove the encoding without having to know *anything* about the media type. Best regards, Julian From zach@sensinode.com Fri Apr 13 13:38: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 094EB21F866A for ; Fri, 13 Apr 2012 13:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NATpEQR4CK1p for ; Fri, 13 Apr 2012 13:38:53 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id DBB0C21F8669 for ; Fri, 13 Apr 2012 13:38:52 -0700 (PDT) Received: from [192.168.1.102] (188-67-213-61.bb.dnainternet.fi [188.67.213.61]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3DKcm8p031766; Fri, 13 Apr 2012 23:38:49 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4F888D02.7050802@gmx.de> Date: Fri, 13 Apr 2012 23:38:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4124299A-80EA-4245-AB98-5A9D0BED0F71@sensinode.com> References: <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org> <4F88899D.3090405@gmx.de> <4F888D02.7050802@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:38:54 -0000 On Apr 13, 2012, at 11:30 PM, Julian Reschke wrote: > On 2012-04-13 22:28, Henry S. Thompson wrote: >> Julian Reschke writes: >>=20 >>> On 2012-04-13 22:02, Carine Bournez wrote: >>>> ... >>>> I suppose that the registration for application/senml+xml could >>>> mandate use of a particular schema when encoded with EXI and = exclude >>>> any additional schema (i.e. no schemaId allowed). >>>> ... >>>=20 >>> Nope. Content-Encoding and media type are orthogonal things. >>=20 >> But she said "when encoded with EXI". Why can't a media type >> registration say that, literally? That is "When encoding with EXI, >> use this schema: [ref] and schemaID: http://...". >=20 > Back to our confusion :-) >=20 > Yes, you can use EXI, but you can't use EXI-as-a-HTTP-Content-Encoding = in this case. The HTTP Content Encoding must be fully defined in absence = of any out-of-band information. >=20 > For instance, a recipient (say browser) needs to be able to remove the = encoding without having to know *anything* about the media type. Exactly. So now we are back to registering something like = application/senml-exi (in addition to senml+xml and senml+json) where = the schema information is included in the media type registration and no = content-encoding is used. This would work for the applications I know of = right now (SEP2 and SenML). Do we need to write up some kind of = information guideline draft for including this kind of information in = the media registration when OOB info needs to be defined (not just for = EXI, but in general)?=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From tony@att.com Fri Apr 13 14:06: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 72C8711E8104 for ; Fri, 13 Apr 2012 14:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.637 X-Spam-Level: X-Spam-Status: No, score=-104.637 tagged_above=-999 required=5 tests=[AWL=1.362, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK+HHbha1H1L for ; Fri, 13 Apr 2012 14:06:47 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCA511E80F1 for ; Fri, 13 Apr 2012 14:05:53 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 035988f4.0.2109483.00-293.5884636.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 13 Apr 2012 21:05:53 +0000 (UTC) X-MXL-Hash: 4f8895311522a8ff-bd5691934fd5ada0b907fc64804b0b083e7379c3 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 q3DL5qA0022689 for ; Fri, 13 Apr 2012 17:05:52 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3DL5l0M022674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Apr 2012 17:05:47 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Fri, 13 Apr 2012 17:05:13 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3DL5Da5023260 for ; Fri, 13 Apr 2012 17:05:13 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3DL572g022614 for ; Fri, 13 Apr 2012 17:05:07 -0400 Received: from [135.70.210.70] (vpn-135-70-210-70.vpn.east.att.com[135.70.210.70]) by maillennium.att.com (mailgw1) with ESMTP id <20120413210205gw1004ore1e> (Authid: tony); Fri, 13 Apr 2012 21:02:05 +0000 X-Originating-IP: [135.70.210.70] Message-ID: <4F889502.9040505@att.com> Date: Fri, 13 Apr 2012 17:05:06 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org Discuss" References: <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org> <4F88899D.3090405@gmx.de> <4F888D02.7050802@gmx.de> <4124299A-80EA-4245-AB98-5A9D0BED0F71@sensinode.com> In-Reply-To: <4124299A-80EA-4245-AB98-5A9D0BED0F71@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=GmzIfwDQVSsA:10 a=vnNYxAp2wzwA:10 a=BlG6E5tz_8] X-AnalysisOut: [UA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1] X-AnalysisOut: [0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=qkMQBcKtRQsZOMvYrVIA:9 a] X-AnalysisOut: [=wPNLvfGTeEIA:10] Cc: "draft-ietf-appsawg-media-type-regs@tools.ietf.org" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:06:48 -0000 On 4/13/2012 4:38 PM, Zach Shelby wrote: > Exactly. So now we are back to registering something like application/senml-exi (in addition to senml+xml and senml+json) where the schema information is included in the media type registration and no content-encoding is used. This would work for the applications I know of right now (SEP2 and SenML). Do we need to write up some kind of information guideline draft for including this kind of information in the media registration when OOB info needs to be defined (not just for EXI, but in general)? I'm thinking that a statement along these lines needs to go into draft-ietf-appsawg-media-type-regs (whose WGLC ends today) -- in other words, beef up the section on +suffix registration with text that helps people better understand when a +suffix should be used, and when it should *not* be used. I'll work with Ned on that. Tony From ht@inf.ed.ac.uk Fri Apr 13 14:18: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 3B3AD21F8646 for ; Fri, 13 Apr 2012 14:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBbrcUPSn+Bo for ; Fri, 13 Apr 2012 14:18:18 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4E51E21F8615 for ; Fri, 13 Apr 2012 14:18:18 -0700 (PDT) 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 q3DLHkno006551; Fri, 13 Apr 2012 22:17:51 +0100 (BST) 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 q3DLHkxF013888; Fri, 13 Apr 2012 22:17:46 +0100 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 q3DLHkdu014636; Fri, 13 Apr 2012 22:17:46 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3DLHkIL014631; Fri, 13 Apr 2012 22:17:46 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Zach Shelby References: <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org> <4F88899D.3090405@gmx.de> <4F888D02.7050802@gmx.de> <4124299A-80EA-4245-AB98-5A9D0BED0F71@sensinode.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 13 Apr 2012 22:17:45 +0100 In-Reply-To: <4124299A-80EA-4245-AB98-5A9D0BED0F71@sensinode.com> (Zach Shelby's message of "Fri, 13 Apr 2012 23:38:48 +0300") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (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: Julian Reschke , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:18:19 -0000 Zach Shelby writes: > Do we need to write up some kind of information guideline draft for > including this kind of information in the media registration when > OOB info needs to be defined (not just for EXI, but in general)? This still just feels wrong. Consider encrypted transmissions. You need a key to decrypt them. That's (of necessity) OOB information. The idea that the media type of the transmission somehow should be involved in that whole aspect of things just seems wrong. Compression, like encryption, is (at least partly) _orthogonal_ to media type. We are getting into the delicate, difficult territory I already mentioned once, to do with the extent to which accepting 'exi' as a coding-type amounted to bending the rules. The simple two-layer story implicit in the original media type architecture (here's a character sequence, and here's a key to unlock its meaning), later extended to three (the +... media types) in one direction, or three/four in another (transfer- and content-encoding) is just not flexible enough to deal with the complexity of contemporary practice. Compound documents, e.g. XHTML+MathML+(SVG-with-XHTML-inside) are one class of problems. What does it mean, for example, to say that the meaning of a fragment identifier is determined by _the_ media type of the entity-body in such a case? Encodings of information, rather than byte-sequences (e.g. EXI) are another. OOB-dependencies may well be another. I'll crawl back into my hole now, and maybe wait to see what the proposed media type registration for 'senml-exi' looks like, since I've run out of ideas to try to provide a locally-adequate workaround. . . 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 stephen.farrell@cs.tcd.ie Fri Apr 13 14:20: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 2530921F86C7 for ; Fri, 13 Apr 2012 14:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9zFasSILKYI for ; Fri, 13 Apr 2012 14:20:52 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F80C21F86C5 for ; Fri, 13 Apr 2012 14:20:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 58F7017147A; Fri, 13 Apr 2012 22:20:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334352045; bh=vwoZZbaBTjt0vB ou6pNOLCJ8mRLXIXCRPCyuovTxWpE=; b=6J+NX/lUGoIDVkYNijpK1Gd5KCn3SG tNKU1xPU7qCUsbFNvuGDjnmU/8g+5o7LnXhRs/3WS2i/Y4dGihTMQir3zeBmnToh XZeKLh7LIYqMEdSUyJcGgQkCWqAnwlofpHcyX6gUEDQtNe8VRikqmXxUOTpfSzRf RFoObc8SKmhkgASCIzSYBUEgWmQ9NOAyvaSfzx8RXJJTOv1Sw63E118zUa0Z9EAl mKXdryA+CcjgC2B3gjUiIIRcsXmngZbYmyzst/hTU5ie1NnrIPd1YnR1Vp1mrKjK zkliE9Z5ZgPuP3R27AVRzh8G9uBbPv/aQBmAoZOirpET7cXMYf/lsmfg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id dTVX8nXMlOZZ; Fri, 13 Apr 2012 22:20:45 +0100 (IST) Received: from [10.87.48.3] (unknown [86.45.51.188]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E48B0171479; Fri, 13 Apr 2012 22:20:41 +0100 (IST) Message-ID: <4F8898A9.8020806@cs.tcd.ie> Date: Fri, 13 Apr 2012 22:20:41 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ned Freed References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> In-Reply-To: <01OE921YMRSW00ZUIL@mauve.mrochek.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pete Resnick , Mark Nottingham , draft-ietf-oauth-v2-bearer.all@tools.ietf.org, Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 21:20:53 -0000 On 04/13/2012 08:43 AM, Ned Freed wrote: > I certainly don't object to doing that. In fact I don't object to dropping this > nasty hack from the document, although perhaps documenting it as *not* > standardized and explaining why it sucks would be even better. So I've a possibly naive question: Why is it harmful to standardise a parameter name for use in query strings? Note: I'm not asking if access_token is a good or bad name for one of those, nor how exactly to standardise one well or badly, nor who should do that, but it seems from the comments here that some folks are against the idea of standardising anything after the authority is a bad idea, and I don't get why exactly that might be the case. Thanks, S. From ned.freed@mrochek.com Fri Apr 13 14:23: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 60F3D21F87EC for ; Fri, 13 Apr 2012 14:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTrAn7f1P4vz for ; Fri, 13 Apr 2012 14:23:47 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 80EC721F87E4 for ; Fri, 13 Apr 2012 14:23:38 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE9UD386XS00A4II@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 13 Apr 2012 14:23:35 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Fri, 13 Apr 2012 14:23:33 -0700 (PDT) Message-id: <01OE9UD1WBEQ00ZUIL@mauve.mrochek.com> Date: Fri, 13 Apr 2012 13:52:04 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 13 Apr 2012 20:11:38 +0100" <4F887A6A.70503@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <9452079D1A51524AA5749AD23E0039280C4828@exch-mbx901.corp.cloudmark.com> <4F831AF1.7000302@isode.com> <01OE8O6UFDOQ00ZUIL@mauve.mrochek.com> <4F887A6A.70503@isode.com> To: Alexey Melnikov Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-media-type-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:23:48 -0000 > >> For example, can the vendor/organization request removal of the > >> registration > >> (I hope the answer to this question is "no".) > > > > Explicitly talking about deleting registrations is a place where we > > really > > don't want to go. There's nothing in the process that would allow > > someone to > > delete a registration, irrespective of whether or not they're > > considered to be > > the owner. That said, there are these things called lawsuits, and who > > knows > > what could result from one of those. > All am really asking about is a statement in the document that entries > are never deleted, but can be marked OBSOLETE instead. And I continue to believe that it's a bad idea to get into this in this specific context. I will also note that under change procedures the document already says: Media type registrations may not be deleted; media types that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field; such media types will be clearly marked in the lists published by the IANA. So the information is there. And I think it's sufficient. But I will add a pointer to that section to the end of the paragraph, to make it clear that's what's being referred to. > > > >> 4.2. Naming Requirements > > > >> Type and subtype names MUST conform to the following ABNF: > > > >> type-name = restricted-name > >> subtype-name = restricted-name > > > >> restricted-name = 1*127restricted-name-chars > >> restricted-name-chars = ALPHA / DIGIT / "!" / > >> "#" / "$" / "&" / "." / > >> "+" / "-" / "^" / "_" > > > >> Ok, this might be silly, but I thought I should ask: can a subtype-name > >> (or type-name) start with a dot? > > > > Such a type would necessarily be in a new tree with a blank name, and > > that > > requires an IETF standards action to create. > Heh, Ok :-). > > I guess I could imagine, the, > > well, "tree with no name" making some sort of wierd sense for, I don't > > know, > > types that are supposed to be invisible or something. But most likely > > not. > > > > A type with a name beginning with #, $, or better still, & might be > > amusing > > though. And there's nothing AFAIK preventing those. I guess we could > > change the > > ABNF so that the first character has to be an ALPHA or DIGIT if we > > think it's > > worth the bother. Comments? > This is what I was thinking. OK, how does this look: restricted-name = restricted name-first *126restricted-name-chars restricted-name-first = ALPHA / DIGIT restricted-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "." / "+" / "-" / "^" / "_" > >> 4.2.1. Text Media Types > > > >> A "charset" parameter SHOULD NOT be specified when charset > >> information is transported inside the payload (e.g., as in "text/ > >> xml"). > > > >> As you are already referencing [I-D.ietf-appsawg-mime-default-charset] > >> Normatively, it would be good to make it clear that this document is > >> merely > >> repeating requirements from [I-D.ietf-appsawg-mime-default-charset]. > >> (The same applies to the next paragraph, but there it is clearer.) > > > > I'll add something. > > > >> If a "charset" parameter is specified, it SHOULD be a required > >> parameter, eliminating the options of specifying a default > >> value. If > >> there is a strong reason for the parameter to be optional despite > >> this advice, each subtype MAY specify its own default value, or > >> alternately, it MAY specify that there is no default value. > >> Finally, > >> the "UTF-8" charset [RFC3629] SHOULD be selected as the default. > >> See > >> [I-D.ietf-appsawg-mime-default-charset] for additional > >> information on > >> the use of "charset" parameters in conjunction with subtypes of > >> text. > > > >> 4.4. Canonicalization and Format Requirements > > > >> As such, teferences to > > > >> typo: references > > > > Fixed. > > > >> or inclusion of format specifications in registrations is encouraged > >> but not required. Note, however, that the public availability of a > >> meaningful specification will often make the difference between > >> simply having a name reserved so that there are no conflicts with > >> other uses and having the potential for other implementations of the > >> media type and useful interoperation with them. > > > > > >> 5.2.1. Provisional Registrations > > > >> Accordingly, a provisonal registration process is provided to > >> support > >> early assigment of media type names. A provisional registration MAY > >> be submitted to IANA for standards tree types. The only required > >> fields in such registrations are the media type name and contact > >> information (inckuding the standards body name). > > > >> typo: including > > > >> Provisional registrations MAY be updated or abandoned at any time. > > > >> I am a bit concerned about "abandoned". It is true that the > >> standardization > >> of a media type might not complete. But if the media type ends up being > >> deployed in any form, wouldn't it be better to mark it as OBSOLETE or > >> something like this instead? I.e. I would prefer for entries not being > >> deleted from the registry. > > > > Bad idea. What if someone puts in a provisional registration for some > > type, > > then finds out that there's already widespread unregistered usage of > > that type > > under another name? What if the first name chosen doesn't deploy at > > all and > > then someone suggests a much better name? What if two people > > provisionally > > register what turns out to be the same thing at the same time? > > > > I could go on and on and on, but I think this makes the point. You're > > trying to > > optimize what is likely to be a fairly unlikely occurance - a name proves > > successful but registration is abandoned - at the expense of other far > > more > > likely cases, cases which if handled this way will lead to registration > > clutter. > > > > Like it or not, really have no choice here but to place some degree of > > trust in > > the people doing these registrations. In fact I'd go so far as to say the > > (sometimes only implied, sometimes all too explicit) lack of trust is > > at least > > part of the perception problem we're faced with in a more general sense. > I would feel more comfortable if you add some text about choices that > are reasonable with some examples (from the above). Or maybe recommend > preservation of the record if there is some indication of media type > being in use. I'm sorry, but I think this is also a bad idea. The problem with such lists is they tend to be taken as enumerating all the options, or at least suggesting what usage should look like, no matter how you label them. And since this is a new thing, we really have no idea how it's going to work. > On a related note: is the Designated Expert going to be involved in this > at all? (I.e., can the Designated Expert update the registration?) We've been over this before. It's really IANA's call as to how much vetting for basic syntax and whatnot they are comfortable doing versus getting the expert reviewer involved. As such, I don't want to specify how this is going t be handled, because it could easily turn out to be incorrect. > >> 5.6. Change Procedures > > > >> Once a media type has been published by the IANA, the owner may > >> request a change to its definition. The descriptions of the > >> different registration trees above designate the "owners" of each > >> type of registration. The same procedure that would be appropriate > >> for the original registration request is used to process a change > >> request. > > > >> I don't remember seeing IETF (or IESG) being the owner of all > >> Standards Tree > >> registration. Did I miss it? > > > > You missed it because it is intentionally not there. The owner of such > > registrations should be whatever standards body does the registration, > > not the > > IETF. I guess I could add a statement to that effect, but given the > > owner is > > necessarily what's going to be checked to see if they're an "authorized > > standards body", I think it just falls out of other considerations. > Ok, good point. > >> 6. Structured Syntax Suffix Registration Procedures > > > >> 3. Send a copy of the template or a pointer to the containing > >> document (with specific reference to the section with the > >> template) to the mailing list ietf-types@ietf.org, > > > >> I've noticed that everywhere else in the document you are using > >> ietf-types@iana.org. Although at the moment both mailing lists are going > >> to the same place, there is no guaranty that that would be true in the > >> future. > >> So I suggest you be consistent everywhere. > > > > Agreed, but in point of fact I'd prefer to change the name to > > something that > > doesn't have "ietf" in it. I'd prefer to use "media-types@iana.org", > > but I'm > > unsure of how to go about making such a change. Should I just change the > > address everywhere and ask IANA to create the new address in the IANA > > considerations section? > Yes. Also it would be worth telling IANA to keep the old one as an > alias, but this can be communicated to IANA out-of-band. OK, I decided to go ahead and make the change, and I added the following paragraph at the end of the IANA considerations section: Finally, this document calls for the creation of a new email address, media-types@iana.org, for the media type review list, which replaces the ietf-types@iana.org address specified in RFC 4288. ietf-types@iana.org should be retained as an alias. I can always removed the bit about the alias if you think it is better communicated out of band. > >> 10.1. Normative References > > > >> [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., > >> Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext > >> Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. > > > >> I think this reference is actually Informative. > > > > On examination I agree. Moved. > > > >> In Appendix A: it might be worth pointing out that submission to > >> ietf-types@iana.org for review is not an absolute requirement anymore. > > > > ??? Appendix A is about grandfather media types, and I see no > > reference to the > > mailing list there. Why would I want/need to introduce one? > I meant the Appendix with changes since the previous RFC. That makes more sense. I'll add a note about it. Ned From mnot@mnot.net Fri Apr 13 14:24: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 57D0B11E8127 for ; Fri, 13 Apr 2012 14:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.292 X-Spam-Level: X-Spam-Status: No, score=-104.292 tagged_above=-999 required=5 tests=[AWL=-1.693, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lNdAJp94zje for ; Fri, 13 Apr 2012 14:24:49 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2097F11E8123 for ; Fri, 13 Apr 2012 14:24:49 -0700 (PDT) Received: from [10.6.130.21] (unknown [50.56.228.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 45B1B22E257; Fri, 13 Apr 2012 17:24:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: <4F8898A9.8020806@cs.tcd.ie> Date: Fri, 13 Apr 2012 16:24:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1257) Cc: Pete Resnick , Ned Freed , draft-ietf-oauth-v2-bearer.all@tools.ietf.org, Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 21:24:50 -0000 Because it's a name space that is managed and owned by the authority of = the URI, not any standards organisation. I.e. we tell them how the URI is structured, not what to put into it. We made *one* exception for this in .well-known as an escape valve for = abuse. If we continue allowing this kind of abuse, we'll have little = defence against things like standardising filename extensions in URLs = and reserving an "/about/" URI's semantics -- things which are clearly = violating the architecture of the WWW: http://www.w3.org/TR/webarch/#uri-opacity Cheers, On 13/04/2012, at 4:20 PM, Stephen Farrell wrote: >=20 >=20 > On 04/13/2012 08:43 AM, Ned Freed wrote: >> I certainly don't object to doing that. In fact I don't object to = dropping this >> nasty hack from the document, although perhaps documenting it as = *not* >> standardized and explaining why it sucks would be even better. >=20 > So I've a possibly naive question: >=20 > Why is it harmful to standardise a parameter name for use in > query strings? >=20 > Note: I'm not asking if access_token is a good or bad name for > one of those, nor how exactly to standardise one well or badly, > nor who should do that, but it seems from the comments here that > some folks are against the idea of standardising anything after > the authority is a bad idea, and I don't get why exactly that > might be the case. >=20 > Thanks, > S. >=20 -- Mark Nottingham http://www.mnot.net/ From johnl@iecc.com Fri Apr 13 14:27: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 C0E8321F87F3 for ; Fri, 13 Apr 2012 14:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.027 X-Spam-Level: X-Spam-Status: No, score=-111.027 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUt+QHvaUsr9 for ; Fri, 13 Apr 2012 14:27:03 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C4C2021F86EF for ; Fri, 13 Apr 2012 14:27:02 -0700 (PDT) Received: (qmail 30165 invoked from network); 13 Apr 2012 21:27:01 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Apr 2012 21:27:01 -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=4f889a25.xn--30v786c.k1204; i=johnl@user.iecc.com; bh=j4sw3jWkT7HJ6R46PKBqDghcPC5C+orfTc6YxcNlokY=; b=TqySbLtwQqN3PU2vYg2NiHZhTRsrihcLtodc17D78ILaHhadoO7BlJbBamGm4hUMp3BXaTEwZVbiXwk9rnrLez1rnspHYCQnPAEysVcHEAsc09b9bFm6Hmn9Ixg35XLzvW9KC6Q5I63ijZDyuYCQSoYyH+Ewwi5BLsRMd/sI1XQ= 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=4f889a25.xn--30v786c.k1204; olt=johnl@user.iecc.com; bh=j4sw3jWkT7HJ6R46PKBqDghcPC5C+orfTc6YxcNlokY=; b=TXCkgs6PJGIbfUE4B2t3h4oZooj+xUaUArYuuvRFrP0+Fu+bFAzkFEhcRbk3gZlYw6x5vS9zRKXqEBFpR9eCanOEcNfWlYATgIFPl4HrPr+Z32RbQ686TAfVMr5pPhKUqT5FV9JrFSCip0XC/12R50tCgjyB1H58Xz8rCourUtc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Apr 2012 21:26:39 -0000 Message-ID: <20120413212639.15905.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 Cc: johnl@taugh.com Subject: Re: [apps-discuss] [taugh.com-standards] Review of draft-levine-application-gzip-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:27:03 -0000 >I don't feel strongly about gzip vs. x-gzip but I also don't think >there is much x-gzip now. There is a good chance that DMARC will use >whichever it defines. Will look for a better ref than gzip.net >although the real refs are the RFCs of course. The right reference is www.gzip.org, which has been around for 15 years and seems unlikely to go away. R's, John >On 4/10/12, Alexey Melnikov wrote: >> Hi John, >> I am sorry I've missed this document earlier. >> >> I am generally happy that you wrote this draft and support its >> publication. Having said that, I think it needs some changes: >> >> In Section 1: >> >> Some applications have informally used the media type application/ >> x-gzip. The media types defined in this document should replace that >> media type in future applications. >> >> Also I've seen application/x-gzip-compressed being mentioned on the web. >> >> But I think it would be better to wait for >> draft-ietf-appsawg-media-type-regs-04 to be submitted to IESG (it is in >> the APPSAWG WGLC now). That document would relax restrictions on >> registering x-* media types. I think your document should register media >> types already in use, as changing existing implementations to use >> application/gzip is hopeless at this point, unless there is some >> evidence that application/gzip is also in use. In the latter case >> aliasing mechanism proposed in draft-ietf-appsawg-media-type-regs should >> be used. >> >> 3.1. Regsistration Details >> >> Person and email address to contact for further information: see >> http://www.gzip.net/ >> >> I've just tried this URI and I am getting "this domain is for sale". It >> doesn't look like this is a good stable reference. >> >> 5. References >> >> This Section should be named "Normative References". >> >> Nit: spot typos in names of Sections 2.1 and 3.1. >> >> >_______________________________________________ >apps-discuss mailing list >apps-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/apps-discuss > From tbray@textuality.com Fri Apr 13 15:07: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 39F6121F8460 for ; Fri, 13 Apr 2012 15:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3iEEH27m2rA for ; Fri, 13 Apr 2012 15:07:02 -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 9C5D521F844D for ; Fri, 13 Apr 2012 15:07:02 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so5394468obb.31 for ; Fri, 13 Apr 2012 15:07:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=bgzoHctOvFy3OFAVrXV/VsAdGa8P2KhPfS/1OUpdmEk=; b=gLW/aoC1U6tmMRa72HESgUwrlMyAeKJD50tPJqzJlUftLqevX5r26JnUgY2zmJKm4k cgruC5o+xN4giZTPeauQDH1+PQVmPRbmUDPmx2Bf4DvbD7Boz8CX2U+d6rkbOE+fP6sa NQH3QrhO/8KhZJ5IFDcdQDhgn7hrfLrY24cSCF9ctip3c4XExaYP56vC4R7YBf88m8tZ AuxepBYk9nALQf0HYZuAev9WpQIl6kEZlx/bXnNE9VQR4A4c+dLM6RSMA1fMUOilQu+S HElUTJT+NctlTOkBMjUg3nq79dC0VJwm1YVNfXrb0P6sScdG1ryMeOuSMXnzcxVH1GeX 46hA== MIME-Version: 1.0 Received: by 10.182.177.99 with SMTP id cp3mr4631377obc.28.1334354822272; Fri, 13 Apr 2012 15:07:02 -0700 (PDT) Received: by 10.182.29.6 with HTTP; Fri, 13 Apr 2012 15:07:02 -0700 (PDT) X-Originating-IP: [76.10.185.119] In-Reply-To: <4F8898A9.8020806@cs.tcd.ie> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> Date: Fri, 13 Apr 2012 15:07:02 -0700 Message-ID: From: Tim Bray To: Stephen Farrell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmzcJ5KliHGkOToZ9SarGEoOXh5ylquG/0dlQcdMMEfFggyj/J5/we4N4IGxlQ+ak9tEd2E Cc: Pete Resnick , Mark Nottingham , Ned Freed , Apps Discuss , draft-ietf-oauth-v2-bearer.all@tools.ietf.org Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 22:07:03 -0000 As I pointed out in the other thread on this, it=92s an architectural botch. Go and look in RFC3986 and find where it discusses reserving keywords in this part of the URI. Hey, it=92s not there! (hint, hint) What *is* there is a lengthy discussion of the very important task, done probably millions of times per second, of comparing two URIs and deciding if they're equivalent, i.e. identify the same thing; this is done by every piece of caching infrastructure and webcrawler. Do all these have to be retooled to peek in the arguments and change their decision based on whether some bits are just outh_* crud? (That question is rhetorical). This is a deeply bad idea. -T On Fri, Apr 13, 2012 at 2:20 PM, Stephen Farrell wrote: > > > On 04/13/2012 08:43 AM, Ned Freed wrote: >> I certainly don't object to doing that. In fact I don't object to droppi= ng this >> nasty hack from the document, although perhaps documenting it as *not* >> standardized and explaining why it sucks would be even better. > > So I've a possibly naive question: > > Why is it harmful to standardise a parameter name for use in > query strings? > > Note: I'm not asking if access_token is a good or bad name for > one of those, nor how exactly to standardise one well or badly, > nor who should do that, but it seems from the comments here that > some folks are against the idea of standardising anything after > the authority is a bad idea, and I don't get why exactly that > might be the case. > > Thanks, > S. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ned.freed@mrochek.com Fri Apr 13 15:23: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 95E8911E80FD for ; Fri, 13 Apr 2012 15:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNpyO-PpCG8F for ; Fri, 13 Apr 2012 15:23:14 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7666411E80E4 for ; Fri, 13 Apr 2012 15:23:11 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE9WFXQXA800RQGV@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 13 Apr 2012 15:23:09 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Fri, 13 Apr 2012 15:23:07 -0700 (PDT) Message-id: <01OE9WFWGO4C00ZUIL@mauve.mrochek.com> Date: Fri, 13 Apr 2012 15:19:00 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 13 Apr 2012 17:05:06 -0400" <4F889502.9040505@att.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org> <4F88899D.3090405@gmx.de> <4F888D02.7050802@gmx.de> <4124299A-80EA-4245-AB98-5A9D0BED0F71@sensinode.com> <4F889502.9040505@att.com> To: Tony Hansen Cc: "draft-ietf-appsawg-media-type-regs@tools.ietf.org" , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:23:14 -0000 > On 4/13/2012 4:38 PM, Zach Shelby wrote: > > Exactly. So now we are back to registering something like application/senml-exi (in addition to senml+xml and senml+json) where the schema information is included in the media type registration and no content-encoding is used. This would work for the applications I know of right now (SEP2 and SenML). Do we need to write up some kind of information guideline draft for including this kind of information in the media registration when OOB info needs to be defined (not just for EXI, but in general)? > I'm thinking that a statement along these lines needs to go into > draft-ietf-appsawg-media-type-regs (whose WGLC ends today) -- in other > words, beef up the section on +suffix registration with text that helps > people better understand when a +suffix should be used, and when it > should *not* be used. > I'll work with Ned on that. After this exercise I have to agree that better text is needed. Ned From ned.freed@mrochek.com Fri Apr 13 15: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 6FC0A21F87B2 for ; Fri, 13 Apr 2012 15:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPDaN2yBeE-r for ; Fri, 13 Apr 2012 15:29:24 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E743521F853F for ; Fri, 13 Apr 2012 15:29:23 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE9WNL2PG000CGQQ@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 13 Apr 2012 15:29:19 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Fri, 13 Apr 2012 15:29:16 -0700 (PDT) Message-id: <01OE9WNJ8DMG00ZUIL@mauve.mrochek.com> Date: Fri, 13 Apr 2012 15:23:21 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 13 Apr 2012 15:53:46 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: John C Klensin Cc: Pete Resnick , Mark Nottingham , Ned Freed , draft-ietf-oauth-v2-bearer.all@tools.ietf.org, Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 22:29:24 -0000 > Agreeing that the horse has left the barn and is far down the > street, the IETF is still being asked to publish this and > publish it with some level of authority that we call "IETF > Consensus" and/or "Standard". > Recommendation: > (1) For reasons explained in my earlier note, prune this down to > one recommended/standardized method, not three. > (2) For any other methods, document them as existing practice > (and consequently alternatives) and _at least_ discuss the > reasons for and against using them. > (3) If the recommendation is to use a reserved query parameter > keyword, seriously consider making that keyword something like > "oauth_access_token" but noting that "access_token" is in use as > a synonym and that, while we discourage it, servers SHOULD > normally treat it as a synonym. I disagree with Ned to the > extent that, as a firm believer in Murphy's Law and the general > perversity of the universe, I would have said "reduce", rather > than "remove", the possibility of conflict, but even "reduce" > would be A Good Thing. > (4) The document should explain the risks associated with > someone using "?access_token" to mean something else entirely > and of parsing, hashing, or encoding URL tails in ways that > effectively disable the intent of the spec. > I think that represents a reasonable balance with reality and > existing practice while avoiding IETF endorsement of practices > we have ample reason to believe are undesirable and should not > be encouraged or endorsed. > An alternative would be to not standardize this at all but > simply publish a slightly-revised version of the document as an > Informational description of existing practice, noting W3C > endorsement to whatever degree that is appropriate. I actually > don't think that is a particularly good idea, but it would be > another way out. Agreed on all points. I'm also not wild on the alternative, but as you say, it would be acceptable. Ned From stephen.farrell@cs.tcd.ie Fri Apr 13 15:35: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 66D5821F880F for ; Fri, 13 Apr 2012 15:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4CpbIOHs0UO for ; Fri, 13 Apr 2012 15:35:58 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6689F21F880E for ; Fri, 13 Apr 2012 15:35:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6C71E171479; Fri, 13 Apr 2012 23:35:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334356541; bh=QkdBEHky0JiyyD GOFFlMalVydPs4nY4FjgsDcHsqGi0=; b=b77qTSg8X3OynXODiA+kpSOrVPxpty b1PGN+aqG/MkWbOkOvMCMtbUAk4dJWIdPz3gBa4Jt6Nb3ZgYEbongyTVYVYZ3Yhy JrjRzt7XQ8zLQl2BLgLf79KXY2r0a3TXwy6jwzFnA2M31Bery3lywY2F/7vvEgmd +XfAi0iDIfhvrny38/w9pAr8MrGXTuTgC/Ei71hoXDyGCcHx3aw64M3GLAj6Ynkv 20ovojxygMaRsdRa40cTyqnCdswqQKLbQoLAAeZt39PyqEa5XhUeL72T9cibmE8O rbTm31Hd6A7eeTIZKWBzgJ1u5/hNFr66xY8PZPrzk9dloGch0OWuyOTA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ltjgTNvLDbXy; Fri, 13 Apr 2012 23:35:41 +0100 (IST) Received: from [10.87.48.3] (unknown [86.45.51.188]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 63B7F17147D; Fri, 13 Apr 2012 23:35:38 +0100 (IST) Message-ID: <4F88AA3A.8040401@cs.tcd.ie> Date: Fri, 13 Apr 2012 23:35:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Mark Nottingham References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> In-Reply-To: <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pete Resnick , Ned Freed , draft-ietf-oauth-v2-bearer.all@tools.ietf.org, Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 22:35:59 -0000 On 04/13/2012 10:24 PM, Mark Nottingham wrote: > Because it's a name space that is managed and owned by the authority of the URI, not any standards organisation. > > I.e. we tell them how the URI is structured, not what to put into it. > > We made *one* exception for this in .well-known as an escape valve for abuse. If we continue allowing this kind of abuse, we'll have little defence against things like standardising filename extensions in URLs and reserving an "/about/" URI's semantics -- things which are clearly violating the architecture of the WWW: > http://www.w3.org/TR/webarch/#uri-opacity (Sticking with the naivety:-) So, what's different there from how the base oauth draft registers client_id and shows how that can be used in a GET request? [1] Ta, S. [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-25#page-24 (bottom of page) > > Cheers, > > > On 13/04/2012, at 4:20 PM, Stephen Farrell wrote: > >> >> >> On 04/13/2012 08:43 AM, Ned Freed wrote: >>> I certainly don't object to doing that. In fact I don't object to dropping this >>> nasty hack from the document, although perhaps documenting it as *not* >>> standardized and explaining why it sucks would be even better. >> >> So I've a possibly naive question: >> >> Why is it harmful to standardise a parameter name for use in >> query strings? >> >> Note: I'm not asking if access_token is a good or bad name for >> one of those, nor how exactly to standardise one well or badly, >> nor who should do that, but it seems from the comments here that >> some folks are against the idea of standardising anything after >> the authority is a bad idea, and I don't get why exactly that >> might be the case. >> >> Thanks, >> S. >> > > -- > Mark Nottingham > http://www.mnot.net/ > > > > > From ned.freed@mrochek.com Fri Apr 13 15:44: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 BD46611E8142 for ; Fri, 13 Apr 2012 15:44:58 -0700 (PDT) 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.182, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOfZBOYbvnNQ for ; Fri, 13 Apr 2012 15:44:58 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 294B911E8135 for ; Fri, 13 Apr 2012 15:44:58 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE9X6YDC68008VRD@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 13 Apr 2012 15:44:56 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Fri, 13 Apr 2012 15:44:53 -0700 (PDT) Message-id: <01OE9X6WVWO000ZUIL@mauve.mrochek.com> Date: Fri, 13 Apr 2012 15:40:48 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 13 Apr 2012 16:02:14 -0400" <20120413200214.GE696@jay.w3.org> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org> To: Carine Bournez Cc: Julian Reschke , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:44:58 -0000 > On Fri, Apr 13, 2012 at 08:24:39PM +0200, Julian Reschke wrote: > >>>> > >>>> All true, but as far as I can tell, you didn't mention > >>>> Content-Encoding in the message I replied to. > >>> > >>> Ah, I see the disconnect. In my original message, I said: > >>> > >>> "Why not call it application/senml+xml and encode it with EXI? > >>> Doesn't that tell you everything you need?" > >>> > >>> I should have been more explicit -- what I meant the above to convey > >>> was > >>> > >>> "Why not call it application/senml+xml and encode it with EXI? > >>> That is, use Content-Type: application/senml+xml and > >>> Content-Encoding: exi . > >>> Doesn't that tell you everything you need?" > >>> > >>> So, reset. With that clarification, what do you think? > >> > >> Yes, absolutely, that works with HTTP. > >> > >> AFAIR, Core () doesn't have > >> Content-Encoding, though. > >> ... > > > > ...with the constraint Ned mentioned in a parallel message (no > > out-of-band information needed). > I suppose that the registration for application/senml+xml could > mandate use of a particular schema when encoded with EXI and exclude > any additional schema (i.e. no schemaId allowed). That's certainly doable from a registration standpoint - we even have an Encoding Considerations section that could be used for this. However, keep in mind that this approach could be a bit of a problem if a new version of senml comes out that includes a schema change. Ned From cabo@tzi.org Fri Apr 13 16:11: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 D55C921F85F7 for ; Fri, 13 Apr 2012 16:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.124 X-Spam-Level: X-Spam-Status: No, score=-106.124 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM4Hr1ZIYxU6 for ; Fri, 13 Apr 2012 16:11:16 -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 885E921F85F6 for ; Fri, 13 Apr 2012 16:11:16 -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 q3DNB5se015506; Sat, 14 Apr 2012 01:11:05 +0200 (CEST) Received: from [192.168.217.105] (p5489A4AB.dip.t-dialin.net [84.137.164.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E8EF5AF; Sat, 14 Apr 2012 01:11:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Sat, 14 Apr 2012 01:11:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F866AC0.3000603@qualcomm.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net> To: Tim Bray X-Mailer: Apple Mail (2.1257) Cc: Pete Resnick , Apps Discuss , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 23:11:22 -0000 On Apr 12, 2012, at 18:34, Tim Bray wrote: > Well, it would claim it as a reserved paramater name if there a way to > do such a thing, which there explicitly isn=92t in RFC3986. URIs are > for most application purposes opaque strings; this breaks that and is > a hideous architectural botch. I would like to turn this observation around. People put stuff like this into the URI because there are applications = where it would be useful to combine information such as what we'd prefer = to put into HTTP header fields with URI information into one *thing*. (Or they put stuff into Cookies because this URI munching doesn't always = work very well either.) Independent from the specific subject here (where there is little point = in further invention), I think it would be useful to explore a little = more the reasons for this and maybe find a better way to carry around = information that is ancillary to a resource access. The recent http+aes = brouhaha is another (somewhat different, as it is client-side only) = example for this need, I think. (The way mailto: has evolved is an = example where this need could be met within the URI scheme.) Gr=FC=DFe, Carsten From Michael.Jones@microsoft.com Fri Apr 13 16:34: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 39FEF11E8130 for ; Fri, 13 Apr 2012 16:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.978 X-Spam-Level: X-Spam-Status: No, score=-3.978 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSy0HHYiyvI7 for ; Fri, 13 Apr 2012 16:34:49 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id EF56F11E80CF for ; Fri, 13 Apr 2012 16:34:48 -0700 (PDT) Received: from mail58-db3-R.bigfish.com (10.3.81.236) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Apr 2012 23:34:47 +0000 Received: from mail58-db3 (localhost [127.0.0.1]) by mail58-db3-R.bigfish.com (Postfix) with ESMTP id A4BCE2A06D9; Fri, 13 Apr 2012 23:34:47 +0000 (UTC) X-SpamScore: -46 X-BigFish: VS-46(zzbb2dI9371I1415J14ffI168aJ542M1432N98dK1447Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail58-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail58-db3 (localhost.localdomain [127.0.0.1]) by mail58-db3 (MessageSwitch) id 1334360085545255_5497; Fri, 13 Apr 2012 23:34:45 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.251]) by mail58-db3.bigfish.com (Postfix) with ESMTP id 7EBEF6005F; Fri, 13 Apr 2012 23:34:45 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Apr 2012 23:34:45 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0283.004; Fri, 13 Apr 2012 23:34:41 +0000 From: Mike Jones To: Apps Discuss Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: Ac0Zzf+fWPGlQ9EZQfyCeUS6Cpo/MA== Date: Fri, 13 Apr 2012 23:34:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664673CC@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 23:34:51 -0000 Thanks for the questions Hannes, and for your note, Stephen. In response,= I'll first provide a brief feature comparison of Simple Web Discovery and = WebFinger, answer your questions, and then make some closing remarks. I'd = also suggest that people read http://www.goland.org/simplewebfinger/ and ht= tp://www.goland.org/managingfingerservice/ for background on the motivation= s for the choices in the Simple Web Discovery (SWD) protocol. FEATURE COMPARISON RESULT GRANULARITY AND PRIVACY CHARACTERISTICS: SWD returns the resource l= ocation(s) for a specific resource for a specific principal. As described = in the current spec, WebFinger appears to return all resources for the prin= cipal, by default. The example at http://tools.ietf.org/html/draft-jones-a= ppsawg-webfinger-03#section-3.2 "Retrieving a Person's Contact Information"= is telling. As described, WebFinger usage model seems to be "I'll get eve= rything about you and then look through it to decide what to do with it." = The assumption that WebFinger information is normally public also appears t= o be built into the protocol where the CORS response header "Access-Control= -Allow-Origin: *" is mandated, per http://tools.ietf.org/html/draft-jones-a= ppsawg-webfinger-03#section-7. The default privacy characteristics of thes= e approaches appear to be different. (It's these very same privacy charact= eristics that led sysadmins to nearly ubiquitously disabling the fingerd se= rvice!) SWD intentionally supports different permissioning on different resources f= or particular principals by reusing existing Internet mechanisms - specific= ally depending upon whether and how the requester is authenticated, differe= nt discovery requests may or may not be granted. (In a recent OAuth thread= , Blaine Cook pointed out that the set of resources returned by WebFinger c= ould be filtered using the same mechanisms, which is true. If that's the i= ntent, I believe that should be made explicit in the WebFinger document. A= nd yes, we should make the intention to use Internet authentication mechani= sms explicit in the SWD draft as well.) DOCUMENT VERSUS API MODEL, DEPLOYABILITY: WebFinger is built on a "documen= t model", where a single document is returned that contains multiple resour= ces for a principal. SWD is built on an "API model", where the location(s)= of a particular resource for a principal are returned. The problem with t= he document model is that different parties or services may be authoritativ= e for different resources for a given principal, and yet all need the right= s to edit or provide portions of the resulting document. This can hurt dep= loyability, because document edits then need to be coordinated among partie= s that may have different rights and responsibilities. (Just because I can= change your avatar doesn't mean that I should be able to change your mail = server.) In a recent OAuth thread, Blaine Cook responded to this characterization by= pointing out that the document model and the resource model are isomorphic= , since Web documents can be and often are dynamically composed, which is c= ertainly true. If a document model is adopted that can return multiple res= ources, with different parties having different permissions to write to tho= se resources, that effectively forces these documents to be dynamically com= posed by a service, for security and privacy reasons. Of course that's doa= ble, but seems less straight-forward to me. REDIRECT FUNCTIONALITY AND DEPLOYABILTY: SWD includes the ability to redir= ect some or all SWD requests to another location (possibly depending upon t= he specific resource and principal parameters). Deployers hosting numerous= sites for others told the SWD authors that this functionality is critical = for deployability, as it means that the SWD server for a domain can live in= a location outside the domain. In the recent OAuth thread, Blaine Cook pointed out that WebFinger can acco= mplish this functionality through a different means - by having the result = returned from the first host-meta query direct the second query another se= rver. As such, I now believe both proposals can accomplish this goal. =20 NUMBER OF ROUND TRIPS: WebFinger discoveries for user information normally= require both a host-meta query to retrieve the template and then a second = query to retrieve the user's information. This functionality is achieved i= n a single SWD query. In the recent OAuth thread, Blaine Cook argued that caching the first query= result is likely to eliminate the first round trip in many cases. That's = very likely the case for multi-user and multi-tenant service deployments, b= ut I suspect it's of little help to clients on personal devices, such as sm= art phones, using a high-latency channel, when UI response times are latenc= y-dependent, and when most discoveries ARE first-time discoveries. XML AND JSON VERSUS JSON: WebFinger specifies both XML and JSON support, w= hereas SWD specifies only JSON. I believe that it's simpler to specify onl= y one way of doing the same thing, with JSON being chosen because it's simp= ler for developers to use than XML (the same decision as made for the OAuth= specs, for what it's worth). DEFINING SPECIFIC RESOURCES: Besides specifying a discovery protocol, WebF= inger also defines specific resources and kinds of resources to be used wit= h that protocol: the "acct" URI scheme and the "acct" Link Relation. I'm = happy to have these be considered on their own merits, but I believe that l= ogically, they should be decoupled from the discovery protocol into a diffe= rent document or documents. HANNES' QUESTIONS 1) Aren't these two mechanisms solving pretty much the same problem? They are solving an overlapping set of problems, but with somewhat differe= nt mechanisms and characteristics. 2) Do we need to have two standards for the same functionality? I believe there's consensus that a single standard should suffice and is p= referable. 3) Do you guys have a position or comments regarding either one of them? I believe that SWD is a simpler and reasonable base to start with for stan= dardization. CLOSING I'll close by saying that I believe the authors of both proposals believe t= hat this work is incredibly important for the Internet and we share the goa= ls of making the resulting solution as simple, as deployable, and as ubiqui= tously adopted as possible and of producing it in a timely manner. I look = forward to working with them and the rest of the working group to make that= happen. -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Stephen Farrell Sent: Friday, April 13, 2012 9:23 AM To: oauth@ietf.org WG Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) Hi All, So Hannes and Derek and I have been discussing this with the Apps ADs and A= pps-area WG chairs. I've also read the docs now, and after all that we've d= ecided that this topic (what to do with swd and webfinger) is best handled = in the apps area and not in the oauth WG. The logic for that is that 1) the two proposals are doing the same thing an= d we don't want two different standards for that, b) this is not an oauth-s= pecific thing nor is it a general security thing, and c) there is clearly a= lready interest in the topic in the apps area so its reasonable for the oau= th wg to use that when its ready. The appsawg chairs and apps ADs are ok with the work being done there. So:- - I've asked the oauth chairs to take doing work on swd out of the proposed new charter - It may be that you want to add something saying that oauth will use the results of work in the applications area on a web discovery protocol as a basis for doing the dynamic client registration work here - Discussion of webfinger and swd should move over to the apps-discuss list - Note: this is not picking one or the other approach, the plan is that the apps area will do any selection needed and figure out the best starting point for a standards-track RFC on web discovery and we'll use their fine work for doing more with oauth. Regards, Stephen. On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: > Hi all, >=20 > those who had attended the last IETF meeting may have noticed the ongoing= activity in the 'Applications Area Working Group' regarding Web Finger.=20 > We had our discussion regarding Simple Web Discovery (SWD) as part of the= re-chartering process.=20 >=20 > Here are the two specifications: > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 > http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 >=20 > Now, the questions that seems to be hanging around are >=20 > 1) Aren't these two mechanisms solving pretty much the same problem? > 2) Do we need to have two standards for the same functionality? > 3) Do you guys have a position or comments regarding either one of them?= =20 >=20 > Ciao > Hannes >=20 > PS: Please also let me know if your view is: "I don't really know what al= l this is about and the documents actually don't provide enough requirement= s to make a reasonable judgement about the solution space." >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From john-ietf@jck.com Fri Apr 13 16:41: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 6C53011E813A for ; Fri, 13 Apr 2012 16:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.162 X-Spam-Level: X-Spam-Status: No, score=-102.162 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ehn-l67cpVO4 for ; Fri, 13 Apr 2012 16:41:42 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2673511E8138 for ; Fri, 13 Apr 2012 16:41:41 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SIq2E-000GR4-3T; Fri, 13 Apr 2012 19:36:10 -0400 Date: Fri, 13 Apr 2012 19:41:25 -0400 From: John C Klensin To: Carsten Bormann , Tim Bray Message-ID: <727EF992755CC4973CC63C45@PST.JCK.COM> In-Reply-To: References: <4F866AC0.3000603@qualcomm.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Pete Resnick , draft-ietf-oauth-v2-bearer.all@tools.ietf.org, Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 23:41:42 -0000 --On Saturday, April 14, 2012 01:11 +0200 Carsten Bormann wrote: > On Apr 12, 2012, at 18:34, Tim Bray wrote: > >> Well, it would claim it as a reserved paramater name if there >> a way to do such a thing, which there explicitly isn't in >> RFC3986. URIs are for most application purposes opaque >> strings; this breaks that and is a hideous architectural >> botch. > > I would like to turn this observation around. > > People put stuff like this into the URI because there are > applications where it would be useful to combine information > such as what we'd prefer to put into HTTP header fields with > URI information into one *thing*. (Or they put stuff into > Cookies because this URI munching doesn't always work very > well either.) > > Independent from the specific subject here (where there is > little point in further invention), I think it would be useful > to explore a little more the reasons for this and maybe find a > better way to carry around information that is ancillary to a > resource access. The recent http+aes brouhaha is another > (somewhat different, as it is client-side only) example for > this need, I think. (The way mailto: has evolved is an > example where this need could be met within the URI scheme.) Carsten, Just a quick personal opinion, related to your more general comment above but almost unrelated to the specific OAUTH parameter. We (that is IETF and W3C) made a decision (a very long time ago as these things go) to not establish an explicit terminator for the end of a URI tail. If we had such a terminator, we would now have a place, post-terminator, for putting "stuff" that is important but that would not foul up comparison of URIs. If we were smart about it, we might even establish a keyword registry for things hung off the end, thereby eliminating one of the other problems that people are concerned about. I don't know if it would be possible to revisit that decision at this point. Certainly it would be painful if it were even possible. But it seems to me that it, or something like it (an equally difficult possibility might be to figure out a way to hide qualifying information in the vicinity of the Method field) are, I think, the only ways that one can both insert information that is relevant to aspects of URIs generally without compromising either the ability to compare them of the assumption that anything that falls into the tail belongs to the target server and gets interpreted pretty much as it desires. regards, john From ned.freed@mrochek.com Fri Apr 13 17:26: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 402A711E80E0 for ; Fri, 13 Apr 2012 17:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik3a4-qyvusW for ; Fri, 13 Apr 2012 17:26:04 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id BAF2011E80B4 for ; Fri, 13 Apr 2012 17:26:04 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEA0QAXEJ4018GKH@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 13 Apr 2012 17:26:02 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Fri, 13 Apr 2012 17:26:00 -0700 (PDT) Message-id: <01OEA0Q9MNGU00ZUIL@mauve.mrochek.com> Date: Fri, 13 Apr 2012 17:22:48 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 10 Apr 2012 11:54:14 +0100" <4F841156.6030908@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4F841156.6030908@isode.com> To: Alexey Melnikov Cc: John Levine , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-levine-application-gzip-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 00:26:05 -0000 > Hi John, > I am sorry I've missed this document earlier. > I am generally happy that you wrote this draft and support its > publication. Having said that, I think it needs some changes: > In Section 1: > Some applications have informally used the media type application/ > x-gzip. The media types defined in this document should replace that > media type in future applications. > Also I've seen application/x-gzip-compressed being mentioned on the web. And application/gzip-compressed, application/gzipped, application/x-gunzip, and probably a bunch of others. > But I think it would be better to wait for > draft-ietf-appsawg-media-type-regs-04 to be submitted to IESG (it is in > the APPSAWG WGLC now). That document would relax restrictions on > registering x-* media types. I think your document should register media > types already in use, as changing existing implementations to use > application/gzip is hopeless at this point, unless there is some > evidence that application/gzip is also in use. In the latter case > aliasing mechanism proposed in draft-ietf-appsawg-media-type-regs should > be used. I'm ambivalent about this in this case. There are simply too many names for this media type in use; no matter which one we pick is cannot possibly conform to all existing usage. Ned From john-ietf@jck.com Fri Apr 13 20:35: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 8521221F85D6 for ; Fri, 13 Apr 2012 20:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsSej1N9PO-u for ; Fri, 13 Apr 2012 20:35:05 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 784D421F85D3 for ; Fri, 13 Apr 2012 20:35:05 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SItgB-000Gd3-3h; Fri, 13 Apr 2012 23:29:39 -0400 Date: Fri, 13 Apr 2012 23:34:55 -0400 From: John C Klensin To: Ned Freed , Alexey Melnikov Message-ID: In-Reply-To: <01OEA0Q9MNGU00ZUIL@mauve.mrochek.com> References: <4F841156.6030908@isode.com> <01OEA0Q9MNGU00ZUIL@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: John Levine , apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-levine-application-gzip-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 03:35:06 -0000 --On Friday, April 13, 2012 17:22 -0700 Ned Freed wrote: >> Hi John, >> I am sorry I've missed this document earlier. > >> I am generally happy that you wrote this draft and support its >> publication. Having said that, I think it needs some changes: > >> In Section 1: > >> Some applications have informally used the media type >> application/ x-gzip. The media types defined in this >> document should replace that media type in future >> applications. > >> Also I've seen application/x-gzip-compressed being mentioned >> on the web. > > And application/gzip-compressed, application/gzipped, > application/x-gunzip, and > probably a bunch of others. > >> But I think it would be better to wait for >> draft-ietf-appsawg-media-type-regs-04 to be submitted to IESG >> (it is in the APPSAWG WGLC now). That document would relax >> restrictions on registering x-* media types. I think your >> document should register media types already in use, as >> changing existing implementations to use application/gzip is >> hopeless at this point, unless there is some evidence that >> application/gzip is also in use. In the latter case aliasing >> mechanism proposed in draft-ietf-appsawg-media-type-regs >> should be used. > > I'm ambivalent about this in this case. There are simply too > many names for > this media type in use; no matter which one we pick is cannot > possibly conform > to all existing usage. And, of course, there is the separate issue that caused us to reject various "zip" and related types years ago -- it is basically a content-transfer-encoding (even if it also used locally) and not a content/media type. As with other things, the "horse have left the barn" principle may argue for registering it anyway, but we (and I believe any spec) should be aware that it breaks the model. john From ned.freed@mrochek.com Fri Apr 13 22:33: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 B695221F86CF for ; Fri, 13 Apr 2012 22:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXSet4lycGs9 for ; Fri, 13 Apr 2012 22:33:37 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B187521F86CE for ; Fri, 13 Apr 2012 22:33:36 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEABGI2B4W0053VD@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 13 Apr 2012 22:33:31 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Fri, 13 Apr 2012 22:33:25 -0700 (PDT) Message-id: <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> Date: Fri, 13 Apr 2012 22:00:37 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 13 Apr 2012 11:34:08 +0100" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> To: Jeni Tennison Cc: Ned Freed , apps-discuss@ietf.org, tony+mtsuffix@maillennium.att.com, Julian Reschke , Noah Mendelsohn , john+ietf@jck.com, "www-tag@w3.org List" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2012 05:33:37 -0000 > I think that their assumption was actually that all the image/*, video/* and > audio/* types would re-register, referencing the Media Fragment spec. Let me put the kibosh on any such assumption right now. The primary purpose of this revision exercise is to try and get more people to register the media types they use. This is, for a variety of reasons, a lot harder than it sounds. And you can multiply the reluctance of registrants by a factor of 100 at least when it comes to updating registrations. We're actually doing an adequate job of getting initial registrations for new types outside of the standards tree, but the number of people who are willing to revise registrations to include additional information, especially if that has no immediate relevance to them personally, is negligable. As such, the notion that existing registrations will be updated wholesale to include fragment identifier information is nothing short of laughable. > Perhaps that's the best way of handling it, and nothing needs to be said > specifically about fragments identifiers for top-level types. This isn't an option either. This is a registration best current practices (BCP) document that sets down rules for registering media types. Default or intrinsic syntax and semantics of fragment identifiers associated with a particular top-level type is a protocol specification. This isn't allowed in a BCP - BCPs are one shot affairs and not subject to interoperability testing, which rather obviously would apply to the specification of such semantics. If you want to put this stuff in an RFC, it needs to one that's on the regular standards track. And that means it needs to be in a different document. All you can put in this document are the registration rules for specifying a fragment identifier. Nothing more. > In that case, the media type specification draft would need to point out that > other media types within the same top-level type may describe the use of a > particular fragment identifier syntax, and that if they do then to make content > negotiation between different media types work more smoothly, it's best to > adopt that same fragid syntax in new media types rather than inventing a new > one. You can certainly put all that in a separate document and reference it here. But I doubt very, very much that that can be done on a sufficiently short time scale for this revision, although as I said before, I deferring how to handle this to the document shepard, WG chairs, and apps ADs. > >> 3. generic syntax specified for types sharing a suffix (eg XPointer for XML [2]) > >> 4. specific syntax specified for individual media types > >> > >> Taking these in reverse order, I think what we're aiming for is: > >> > >> Media type registrants need to be guided to specify the fragment identifier schemes that they inherit from any top-level type or suffix type and how any clashes should be handled. They also need to be guided to reserve plain name fragment identifiers for their common use, and to think about what constraints the media type places on "active fragment identifiers" which may be used within scripts. > > > > If there is no multiple inheritance (from top level types), there should be fewer or no clashes at all. > Even without anything being said for top-level types, there's always the > possibility of multiple inheritance. For example, say that someone invented a > fragment identifier syntax for programming languages that used > #function({name}) to reference functions within source files. If we wanted to > use that with XSLT, we would need to say so within the application/xslt+xml > media type definition and deal with the fact that the syntax clashed with > XPointer syntax inherited through the use of the +xml suffix. I have to say that this sounds like a much bigger problem than can possibly be addressed by the addition of a few simple rules to the registration specification, which given that the primary goal here is to have a registration process people can use easily, is all that's going to be acceptable here. > So it still rests with the media type definition itself to explain which > fragment identifier schemes are supported and how they interact, even if > there's no explicit recognition of inheritance from the top-level types. I suspect that without some defaults, probably based on type suffix as much on top-level types, laid out in one or more standards-track RFCs, this is unlikely to get much traction. > >> [2] http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html#frag > > > > Note that the draft above has never been submitted as Internet Draft, so > > from the IETF's point of view it doesn't exist. > > See . > OK :) I believe the question of what exactly to put in that draft about > fragment identifiers has been the main thing holding up its submission. The point of publishing an Internet Draft isn't to expose your polished final work to the world. Rather, it's to release your working material, missing parts and all, so that unresolved issues like, say, how to handle fragment identifiers can be exposed to broader discussion and input. This is *especially* true of a document which, if the path is any indication, is intended to be an update to RFC 3023. Indeed, I'd have to call it highly inappropriate to have handled such an update in this fashion. Ned From ned.freed@mrochek.com Fri Apr 13 23:01: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 EAAC221F86D9 for ; Fri, 13 Apr 2012 23:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVfBOOg6RGqm for ; Fri, 13 Apr 2012 23:01:19 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6D86521F86D5 for ; Fri, 13 Apr 2012 23:01:19 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEACFX3N74017ST7@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 13 Apr 2012 23:01:16 -0700 (PDT) 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 <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Fri, 13 Apr 2012 23:01:13 -0700 (PDT) Message-id: <01OEACFVDL5O00ZUIL@mauve.mrochek.com> Date: Fri, 13 Apr 2012 22:58:04 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 14 Apr 2012 01:11:04 +0200" References: <4F866AC0.3000603@qualcomm.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net> To: Carsten Bormann Cc: Pete Resnick , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2012 06:01:20 -0000 > On Apr 12, 2012, at 18:34, Tim Bray wrote: > > Well, it would claim it as a reserved paramater name if there a way to > > do such a thing, which there explicitly isn’t in RFC3986. URIs are > > for most application purposes opaque strings; this breaks that and is > > a hideous architectural botch. > I would like to turn this observation around. > People put stuff like this into the URI because there are applications where it would be useful to combine information such as what we'd prefer to put into HTTP header fields with URI information into one *thing*. This is clearly true, and there are all sorts of hacks out there to do this. There are just too many places where you have only one slot, so you have to combine stuff into one, as you say, thing. That said, the rules are what they are, and comparison of URIs has to be taken into account. > (Or they put stuff into Cookies because this URI munching doesn't always work > very well either.) > Independent from the specific subject here (where there is little point in > further invention), I think it would be useful to explore a little more the > reasons for this and maybe find a better way to carry around information that > is ancillary to a resource access. The recent http+aes brouhaha is another > (somewhat different, as it is client-side only) example for this need, I think. > (The way mailto: has evolved is an example where this need could be met within > the URI scheme.) I think this is an excellent idea, but of course it's far outside the purview of the present document. Ned From tbray@textuality.com Sat Apr 14 00:58: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 0EC3B21F8542 for ; Sat, 14 Apr 2012 00:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.727 X-Spam-Level: X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHVQhXEhPQUF for ; Sat, 14 Apr 2012 00:58:33 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8213C21F84AF for ; Sat, 14 Apr 2012 00:58:33 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so126425obb.31 for ; Sat, 14 Apr 2012 00:58:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=evKmZgq9S2KWpMt4WjIs6/8AZF8+3RgHrgskv/fK2ps=; b=kKtiV5rqN0Q2JPqLXoEVW0FeIcy4gleDQZqdL8I/5BR9U3qzZLdk+uS2gDQNLf8CUs KtF5s2BVwCny7xdaagXD3DuvM7+fGjOJ070cdGYNGK22lsztgkU2K+wwAQWBt7F7GaZb uTBySpMER8BJ59R2oQzh4jCbFoyJND3ZaFx6/J9ITD6OyDy5Ey3kbyEr1w3YYFTzAc25 281Jt1nm0XWiYiiEkFxXOBG4nFLAt2Z73JLsy6k5hC3eGioDJCKTjIaqEnrZPbTr86ze 5RMOhBl5WIySZ8+iJIH0KnfYa9xN8f7qKoW/D8gP5lEq40FQDlyikSNqUos+Kmb0ArlJ MH9w== MIME-Version: 1.0 Received: by 10.182.177.99 with SMTP id cp3mr6200752obc.28.1334390312055; Sat, 14 Apr 2012 00:58:32 -0700 (PDT) Received: by 10.182.29.6 with HTTP; Sat, 14 Apr 2012 00:58:31 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <4F866AC0.3000603@qualcomm.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net> <01OEACFVDL5O00ZUIL@mauve.mrochek.com> Date: Sat, 14 Apr 2012 00:58:31 -0700 Message-ID: From: Tim Bray To: Dick Hardt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQngHpHHg+BcBDbc6KqQbh/i5C19xchvgE8mewLwyR105e7/czZgBMT1K9uiFdCHD0UVrLJE Cc: Pete Resnick , Ned Freed , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2012 07:58:34 -0000 That would be http://tools.ietf.org/html/rfc3986#section-6 The fact that it=92s kind of long, but still doesn=92t find room for reserved ?key=3Dval pairs, is significant in this context. -T On Sat, Apr 14, 2012 at 12:43 AM, Dick Hardt wrote: > > On Apr 13, 2012, at 10:58 PM, Ned Freed wrote: > > > That said, the rules are what they are, and comparison of URIs has to be > taken > into account. > > > What is the URI comparison rule you are referring to? > > -- Dick From carine@jay.w3.org Sat Apr 14 05: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 77B4B21F862B for ; Sat, 14 Apr 2012 05:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otVaQBVqqKI8 for ; Sat, 14 Apr 2012 05:10:44 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id DF01021F8625 for ; Sat, 14 Apr 2012 05:10:43 -0700 (PDT) Received: from carine by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1SJ1oO-0001X5-Rd; Sat, 14 Apr 2012 08:10:40 -0400 Date: Sat, 14 Apr 2012 08:10:40 -0400 From: Carine Bournez To: Julian Reschke Message-ID: <20120414121040.GF696@jay.w3.org> References: <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org> <4F88899D.3090405@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F88899D.3090405@gmx.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 12:10:44 -0000 On Fri, Apr 13, 2012 at 10:16:29PM +0200, Julian Reschke wrote: > On 2012-04-13 22:02, Carine Bournez wrote: >> ... >> I suppose that the registration for application/senml+xml could >> mandate use of a particular schema when encoded with EXI and exclude >> any additional schema (i.e. no schemaId allowed). >> ... > > Nope. Content-Encoding and media type are orthogonal things. It was the case until the pack200 content encoding was registered. EXI has not set any precedent here. From julian.reschke@gmx.de Sat Apr 14 05: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 BB4B921F8623 for ; Sat, 14 Apr 2012 05:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSwptkveZhVg for ; Sat, 14 Apr 2012 05:28:09 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 65F1521F8512 for ; Sat, 14 Apr 2012 05:28:08 -0700 (PDT) Received: (qmail invoked by alias); 14 Apr 2012 12:28:07 -0000 Received: from p57A6E3B5.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.227.181] by mail.gmx.net (mp027) with SMTP; 14 Apr 2012 14:28:07 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/1OuhRYlr1skLmk0gUSjj5gOb4/JrbN7vZrYd22J XYQOTLypKy/Z9x Message-ID: <4F896D3D.9010805@gmx.de> Date: Sat, 14 Apr 2012 14:27:41 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Carine Bournez References: <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org> <4F88899D.3090405@gmx.de> <20120414121040.GF696@jay.w3.org> In-Reply-To: <20120414121040.GF696@jay.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 Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 12:28:10 -0000 On 2012-04-14 14:10, Carine Bournez wrote: > On Fri, Apr 13, 2012 at 10:16:29PM +0200, Julian Reschke wrote: >> On 2012-04-13 22:02, Carine Bournez wrote: >>> ... >>> I suppose that the registration for application/senml+xml could >>> mandate use of a particular schema when encoded with EXI and exclude >>> any additional schema (i.e. no schemaId allowed). >>> ... >> >> Nope. Content-Encoding and media type are orthogonal things. > > It was the case until the pack200 content encoding was registered. > EXI has not set any precedent here. If "pack200" violates that principle, it shouldn't have been registered. (Does it? Pointers, please) However, just because it happened once doesn't make it correct to do it again. Best regards, Julian From ned.freed@mrochek.com Sat Apr 14 07:11: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 62E7A21F861F for ; Sat, 14 Apr 2012 07:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qziLXKCuzOs for ; Sat, 14 Apr 2012 07:11:54 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CABB321F861B for ; Sat, 14 Apr 2012 07:11:53 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEATK4XW68005PB3@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 14 Apr 2012 07:11:49 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Sat, 14 Apr 2012 07:11:47 -0700 (PDT) Message-id: <01OEATK3NNY800ZUIL@mauve.mrochek.com> Date: Sat, 14 Apr 2012 06:55:26 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 14 Apr 2012 14:27:41 +0200" <4F896D3D.9010805@gmx.de> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org> <4F88899D.3090405@gmx.de> <20120414121040.GF696@jay.w3.org> <4F896D3D.9010805@gmx.de> To: Julian Reschke Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 14:11:55 -0000 > On 2012-04-14 14:10, Carine Bournez wrote: > > On Fri, Apr 13, 2012 at 10:16:29PM +0200, Julian Reschke wrote: > >> On 2012-04-13 22:02, Carine Bournez wrote: > >>> ... > >>> I suppose that the registration for application/senml+xml could > >>> mandate use of a particular schema when encoded with EXI and exclude > >>> any additional schema (i.e. no schemaId allowed). > >>> ... > >> > >> Nope. Content-Encoding and media type are orthogonal things. > > > > It was the case until the pack200 content encoding was registered. > > EXI has not set any precedent here. > If "pack200" violates that principle, it shouldn't have been registered. > (Does it? Pointers, please) My understanding is that pack200 is a type-specific compression format. That is, it only works if the input is a jar file. In this sense there is overlap with EXI - I believe EXI relies on the input having XML syntax (although it doesn't necessarily have to be well formed), which means it is only applicable to a subset of media types. If that's indeed the case, then yes, pack200 is not orthogonal to the media type. That said, it's not in the same class as EXI. I'm pretty sure I can decompress anything that's been compressed with pack200 with nothing but knowledge of the pack200 algorithm. I don't need to to have access to an external schema or type-specific rules about which schema is the default. I also note that pack200 doesn't present the same sort of issues for negotiation. A server knows the types of the objects it sends out and therefore knows when pack200 can and cannot be applied. And a client requesting pack200 encoding and getting it back won't ever have any difficulty handling it. The most that can be said is that it requires special-case handling on the server when an encoding is selected. (Which is also the case with EXI.) > However, just because it happened once doesn't make it correct to do it > again. Quite true. Even if pack200 had exactly the same characteristics as EXI, that would not provide justification for making the same mistake again. Ned From johnl@iecc.com Sat Apr 14 07:18: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 7767621F8589 for ; Sat, 14 Apr 2012 07:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.065 X-Spam-Level: X-Spam-Status: No, score=-111.065 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8me9g7yQBaUk for ; Sat, 14 Apr 2012 07:18:05 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A5A3C21F8576 for ; Sat, 14 Apr 2012 07:18:05 -0700 (PDT) Received: (qmail 3377 invoked from network); 14 Apr 2012 14:18:04 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Apr 2012 14:18:04 -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=4f89871c.xn--9vv.k1204; i=johnl@user.iecc.com; bh=CTdOgVYAgFcU8MFMryRycFI4+HYR0ooZ5yKftsABqJQ=; b=aRZgbKlu9xfWQienqLrZH3GeM7ZJ+eNPOJ/solRX3f3wUK55Hn/sCCmHU7FRJWGP1znjC7/F2DWSG5dlVFJZYuN/rSapCtEuqDFPSwnyyWhxe7DGeAHV4GHce+x7cJ1iSP3Uvh248jRJRCbMlVeYtlfMZXzrw8DRgFOG4kHtPrQ= 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=4f89871c.xn--9vv.k1204; olt=johnl@user.iecc.com; bh=CTdOgVYAgFcU8MFMryRycFI4+HYR0ooZ5yKftsABqJQ=; b=nmnVKQWZqHDsyg+eFBSGCaL1m6V4UerbL6df3zNvTgYmXB+5RrK7y9OKDKMTnrfnFWBD0NeJmTn/IRTWCOhDCuCvEMmCE0EzVqb5XYnrEhLnbBTKHpFEy9OrcAnC3Ic4UJ+Wqyayc+ydlP6bK3UFhpkRmF4M+7eJsgt3j+T+SOQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Apr 2012 14:17:41 -0000 Message-ID: <20120414141741.69972.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] Review of draft-levine-application-gzip-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 14:18:06 -0000 >And, of course, there is the separate issue that caused us to >reject various "zip" and related types years ago -- it is >basically a content-transfer-encoding (even if it also used >locally) and not a content/media type. You're right, but these days you could make much the same argument about application/pdf. (Text? Images? Encrypted? Forms to fill in? Active content? Whatever else they've addred to PDF lately?) In view of Ned's comments, I'm inclined to leave it as application/gzip. R's, John From john-ietf@jck.com Sat Apr 14 09:18: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 3CAEC21F848B for ; Sat, 14 Apr 2012 09:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twGE+8YQcBos for ; Sat, 14 Apr 2012 09:18:30 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 77B4321F8483 for ; Sat, 14 Apr 2012 09:18:29 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SJ5b1-000Htx-3w; Sat, 14 Apr 2012 12:13:07 -0400 Date: Sat, 14 Apr 2012 12:18:24 -0400 From: John C Klensin To: John Levine , apps-discuss@ietf.org Message-ID: In-Reply-To: <20120414141741.69972.qmail@joyce.lan> References: <20120414141741.69972.qmail@joyce.lan> 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] Review of draft-levine-application-gzip-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 16:18:31 -0000 --On Saturday, April 14, 2012 14:17 +0000 John Levine wrote: >> And, of course, there is the separate issue that caused us to >> reject various "zip" and related types years ago -- it is >> basically a content-transfer-encoding (even if it also used >> locally) and not a content/media type. > > You're right, but these days you could make much the same > argument about application/pdf. (Text? Images? Encrypted? > Forms to fill in? Active content? Whatever else they've > addred to PDF lately?) > > In view of Ned's comments, I'm inclined to leave it as > application/gzip. John, I think there are two separate issues here. One is what this should be called given that we decide it is an application type. I agree that application/gzip is a reasonable answer to that question. The other is whether we give up significant functionality by abandoning the distinction between a media (content) type and a content-[transfer-]encoding. The latter concerns me independent of the level of current practice, if only because, once we "officially" start down that slope, I don't see any model by which we stop. In the latter regard, I don't see your analogy to PDF as relevant. It would be relevant had we defined text/pdf, image/pdf, etc., but we didn't -- we defined it as an application type from the beginning. Independent of what goes on inside a PDF document (even one that is a aggregate of several kinds of things), it still meets the basic criteria for an application/ subtype, namely "go off and find a competent PDF processor and let it do its thing". The problem with compressed formats (or, worse, compressed aggregate ("archive") ones like zip or tar.gz) is that the compressor/uncompressor are just reversible transformation formats of something else -- where that something else might be one or more objects of substantially any media type. Now I don't think the original model works entirely well for the compressor-aggregator case either, first because one might end up needing content-transfer-encoding=SomeZip encoded with, e.g., base64, and, if the compression form is also an aggregating one, one could have SomeZip (text-file, image-file, image-file,...) There is no clear way to express that compressed aggregate in Media-type language either. At the same time, the binary data problem notwithstanding, it has hard for me to understand why a strict compression type shouldn't, in principle, be a CTE (and, while the discussion has mostly focused on gzip, zlib, as a pure stream compression format, seems like even more of a candidate for a CTE. Precisely because of the aggregation issue, "application/zip" is a more complex case than "application/gzip" but we see a lot of "application/x-zip" in the wild too. The above is no surprise. We were at least aware of the issue when MIME was designed. I'm just reluctant to give up on the distinction without a more general and careful examination of the model than one gets if one starts, as it appears to me that your document appears to start, with "this is useful, there is a lot of it out there (modulo details of the keyword chosen), so let's standardize it". Expressed a little differently, this spec, especially for zlib, changes or ignores the distinction between content-type and content-transfer-encoding of the base MIME specification. As such, it effectively updates that specification unless there is a clear explanation of why the distinction doesn't apply to this case. So I believe that the document has some obligation to either: (1) Explicitly update RFC 2045, especially the discussion in the last half of Section 6.4, to split whatever hairs need to be split to justify a stream compression method that can, in principle, be applied to media of any type as a media type rather than as a CTE. FWIW, updating 2045 probably requires a standards track spec, possibly a separate one. Or (2) Explain why that discussion either isn't applicable or should be ignored because of the special circumstances of this case. As a hypothetical question, if someone sat down now and wrote up a spec for two new content-transfer-encodings, Zlib and ZlibB64, explaining in those specs that, while application/x-zlib is in use, it was a mistake and should be deprecated in favor of the C-T-E form, what reaction would it get? I'm not predicting that such a spec would be written, but thinking about the possibility may help in the discussion. best, john From johnl@iecc.com Sat Apr 14 09:26: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 E859C21F84EF for ; Sat, 14 Apr 2012 09:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.078 X-Spam-Level: X-Spam-Status: No, score=-111.078 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63TlAfV+J7GO for ; Sat, 14 Apr 2012 09:26:38 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DBDC221F84DF for ; Sat, 14 Apr 2012 09:26:37 -0700 (PDT) Received: (qmail 43413 invoked from network); 14 Apr 2012 16:26:36 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Apr 2012 16:26:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f89a53c.xn--i8sz2z.k1204; i=johnl@user.iecc.com; bh=Vjsh00ixwFJvkO8fa5zE4JeBFWH5x2/hpOzjFCHaTRU=; b=bY2qZP8/4B6/433aSZNuL2XGe6JZ5dNT1THVEI8BcM5f1L5wgupo11biRWWSx+Da3yuf8SWqCq6rVV0vDlQCT8YezeI6XrqdnJvanm1krnb5KzOc7xAsWb1fY62EZDvjDzWWYIcYP8bH2sdzoKAXJk5k0+TdHkkgEcDeJQqwLkU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f89a53c.xn--i8sz2z.k1204; olt=johnl@user.iecc.com; bh=Vjsh00ixwFJvkO8fa5zE4JeBFWH5x2/hpOzjFCHaTRU=; b=DA8SxIcQlZUeZk+SZ0vA/FN4+ZZGq0divD/PJsvg+6BPnYYin98uWVtrz1gGoGmmaRE+IafcbmexVSSA5JIzYb8Cm/e2eFwKkLUSo9gdHsZO3mz6POUnsrjG/IsYBGUfBMnnagdzEoBbqCeEmovI09ytpcJx5ebH9ufk2uyGuUo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Apr 2012 16:26:14 -0000 Message-ID: <20120414162614.2336.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <20120414141741.69972.qmail@joyce.lan> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] draft-levine-application-gzip-02.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, 14 Apr 2012 16:26:39 -0000 >In view of Ned's comments, I'm inclined to leave it as >application/gzip. A little Googlage found at least five other MIME types that people have used to describe gzip data. I just posted a new version that mentions all of them and suggests that people use application/gzip or application/zlib in the future, fixes the reference to gzip.org, and a bunch of typos. R's, John From johnl@iecc.com Sat Apr 14 09:33: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 198B321F85D6 for ; Sat, 14 Apr 2012 09:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz2EikqJ8Ozk for ; Sat, 14 Apr 2012 09:33:49 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 26FAE21F85E5 for ; Sat, 14 Apr 2012 09:33:49 -0700 (PDT) Received: (qmail 44831 invoked from network); 14 Apr 2012 16:33:48 -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=af1e.4f89a6ec.k1204; bh=5s2ZLRSRktm1Dumv7NzlZoI8X6QzNofeHR3zwmTn2GU=; b=NjOlNM+uOoHdEjJUAf4no7+R5lzKeSM9TDdqnTnAlFcTDT7aTSuM1FbrTjC95AmiDMceo2uFBi1AKfnUgJ7FPITXH608hThBal7G0alPmKAdlZTHKQ++vlQA1ZJeFvoVbDHQg6c/tiBzVokPZKrPIT8PinR41VEEv+s1dYUv1A8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 14 Apr 2012 16:33:26 -0000 Date: 14 Apr 2012 16:33:46 +0000 Message-ID: From: "John R. Levine" To: "John C Klensin" In-Reply-To: References: <20120414141741.69972.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-levine-application-gzip-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 16:33:50 -0000 > Precisely because of the aggregation issue, "application/zip" is > a more complex case than "application/gzip" but we see a lot of > "application/x-zip" in the wild too. But "application/zip" is registered. See RFC 2912, section 4.5 for a suggestion about how one might say what's inside the ZIP file in an application/zip MIME part, and RFCs 2007 and 6362 for other references. I agree that in a more ideal world, the compression type would be in with the encoding, but that horse bolted 20 years ago. The reason I'm doing application/gzip is that the DMARC project is sending reports as application/zip for something where gzip would be more suitable, and when I asked why, the document author said that application/zip is registered and application/gzip isn't. So I'm levelling the playing field. 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 john-ietf@jck.com Sat Apr 14 09:41: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 08E7621F84DA for ; Sat, 14 Apr 2012 09:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6-VFrO4nirB for ; Sat, 14 Apr 2012 09:41:41 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 59FCB21F84D2 for ; Sat, 14 Apr 2012 09:41:41 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SJ5xS-000Hvb-M6; Sat, 14 Apr 2012 12:36:18 -0400 Date: Sat, 14 Apr 2012 12:41:35 -0400 From: John C Klensin To: "John R. Levine" Message-ID: <867F4054B121B5FC3C414605@PST.JCK.COM> In-Reply-To: References: <20120414141741.69972.qmail@joyce.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-levine-application-gzip-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 16:41:42 -0000 --On Saturday, April 14, 2012 16:33 +0000 "John R. Levine" wrote: >> Precisely because of the aggregation issue, "application/zip" >> is a more complex case than "application/gzip" but we see a >> lot of "application/x-zip" in the wild too. > > But "application/zip" is registered. See RFC 2912, section > 4.5 for a suggestion about how one might say what's inside the > ZIP file in an application/zip MIME part, and RFCs 2007 and > 6362 for other references. I agree that in a more ideal world, > the compression type would be in with the encoding, but that > horse bolted 20 years ago. Sorry. Had lost track of application/zip. Comments/objection withdrawn -- this spec should not be victimized when we've already made a worse mistake. At some stage, we should rethink the distinction that RFC 2045 tries to make, but I'm not volunteering and am not going to hold my breath. > The reason I'm doing application/gzip is that the DMARC > project is sending reports as application/zip for something > where gzip would be more suitable, and when I asked why, the > document author said that application/zip is registered and > application/gzip isn't. So I'm levelling the playing field. Seems reasonable. john From Michael.Jones@microsoft.com Sat Apr 14 11:13: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 F3C8421F8547 for ; Sat, 14 Apr 2012 11:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.659 X-Spam-Level: X-Spam-Status: No, score=-3.659 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxV4tmoKvV-T for ; Sat, 14 Apr 2012 11:13:19 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id C59F521F8527 for ; Sat, 14 Apr 2012 11:13:11 -0700 (PDT) Received: from mail111-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Sat, 14 Apr 2012 18:13:10 +0000 Received: from mail111-db3 (localhost [127.0.0.1]) by mail111-db3-R.bigfish.com (Postfix) with ESMTP id ADB803805A0; Sat, 14 Apr 2012 18:13:10 +0000 (UTC) X-SpamScore: -35 X-BigFish: VS-35(zz9371I542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail111-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail111-db3 (localhost.localdomain [127.0.0.1]) by mail111-db3 (MessageSwitch) id 1334427189404865_4416; Sat, 14 Apr 2012 18:13:09 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.233]) by mail111-db3.bigfish.com (Postfix) with ESMTP id 4209316004A; Sat, 14 Apr 2012 18:13:09 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 14 Apr 2012 18:13:08 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0283.004; Sat, 14 Apr 2012 18:13:06 +0000 From: Mike Jones To: Dick Hardt , Tim Bray Thread-Topic: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer Thread-Index: AQHNGhgaVyxYyd5HAE+IrZgHdKFgSJaanpIg Date: Sat, 14 Apr 2012 18:13:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436646DBCA@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4F866AC0.3000603@qualcomm.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net> <01OEACFVDL5O00ZUIL@mauve.mrochek.com> <898E78D1-DFFB-4B8B-9C75-7A2BD0D34CBE@gmail.com> In-Reply-To: <898E78D1-DFFB-4B8B-9C75-7A2BD0D34CBE@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Pete Resnick , Ned Freed , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2012 18:13:20 -0000 I don't believe that URI comparison considerations are pertinent here. Her= e's why... These URIs contain a bearer token. As such, it would be a complete securit= y breach for these URIs to ever become visible to any but the intended part= ies. Why? Per the Security Considerations section, this would allow anyon= e in possession of them to successfully impersonate the client and perform = operations as if they were the client. (That's the nature of a bearer toke= n.) Therefore, these URIs MUST never be visible to Web crawlers or any other th= ird parties that might try to use URI comparison rules on them in some gene= ric way. For security reasons, their use is scoped strictly to the client = and the protected resource. Therefore, URI comparison considerations do not apply. -- Mike -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 Sent: Saturday, April 14, 2012 1:25 AM To: Tim Bray Cc: Dick Hardt; Ned Freed; Carsten Bormann; Pete Resnick; Apps Discuss; dra= ft-ietf-oauth-v2-bearer.all@tools.ietf.org Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oaut= h-v2-bearer Thanks Tim. I did not see any discussion on normalizing key=3Dvalue pairs. One would as= sume that http://exmaple.com/?a=3D1&b=3D2 is equivalent to http://exmaple.c= om/?b=3D2&a=3D1 -- but that does not seem to be significant here. There are numerous practical reasons for the bearer token to be able to be = passed as a query parameter which I would be happy to enumerate if anyone i= s interested. (so far no one has asked :) I'm trying to understand the desire to remove this functionality, and after= reading the spec my take away is a desire to not specify a query parameter= . What am I missing? -- Dick On Apr 14, 2012, at 12:58 AM, Tim Bray wrote: > That would be http://tools.ietf.org/html/rfc3986#section-6 >=20 > The fact that it's kind of long, but still doesn't find room for=20 > reserved ?key=3Dval pairs, is significant in this context. -T >=20 > On Sat, Apr 14, 2012 at 12:43 AM, Dick Hardt wrote= : >>=20 >> On Apr 13, 2012, at 10:58 PM, Ned Freed wrote: >>=20 >>=20 >> That said, the rules are what they are, and comparison of URIs has to=20 >> be taken into account. >>=20 >>=20 >> What is the URI comparison rule you are referring to? >>=20 >> -- Dick From dick.hardt@gmail.com Sat Apr 14 00:44: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 2174721F85B1 for ; Sat, 14 Apr 2012 00:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCDx6mV6f3bW for ; Sat, 14 Apr 2012 00:44:09 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5B80621F85AE for ; Sat, 14 Apr 2012 00:43:40 -0700 (PDT) Received: by dady13 with SMTP id y13so6649245dad.27 for ; Sat, 14 Apr 2012 00:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=U5tZ9G1+/oEnkXzmG+IxMxrQR3TIqkb9uY9ClK0zN9g=; b=fPo3Ft9cENkGzRyEJPn1S3Sgn5ViaUDfHEH06UBKA2kxJThVHDRZQivMgbFWVstJFK dLBR1j0RIiV+kv8K1AwNChn3XxrzNBhH/ho3Y8VDhrUVmLotzNc3Nyn3qKkWVTBdIJ5F ojDH5VBpwlsTaklWbeMUht6qZl/Gi6ZuyXaODWDaB7wTOFRWnEgO5SES/hoZzS5eRR7P NAe67/XDRSFagMT1701gNeyzGXGkks1EvVzm47KakE827LC4x1xdoQJ60cJNimM4Hqfn LH2gbSUBybc2olivJ+XG1uuh6zlvDFHgK35iTS2V/MZ7UaWdZHSpWE68wwP1nF6QTb87 Wutw== Received: by 10.68.201.169 with SMTP id kb9mr10671361pbc.146.1334389420016; Sat, 14 Apr 2012 00:43:40 -0700 (PDT) Received: from [10.0.0.91] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id f7sm11060545pbr.3.2012.04.14.00.43.37 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Apr 2012 00:43:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_5EAD21E3-7725-4CC3-8CB9-0B8466EDA115" From: Dick Hardt In-Reply-To: <01OEACFVDL5O00ZUIL@mauve.mrochek.com> Date: Sat, 14 Apr 2012 00:43:36 -0700 Message-Id: References: <4F866AC0.3000603@qualcomm.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net> <01OEACFVDL5O00ZUIL@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Sat, 14 Apr 2012 13:04:41 -0700 Cc: Pete Resnick , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2012 07:44:10 -0000 --Apple-Mail=_5EAD21E3-7725-4CC3-8CB9-0B8466EDA115 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 13, 2012, at 10:58 PM, Ned Freed wrote: >=20 > That said, the rules are what they are, and comparison of URIs has to = be taken > into account. What is the URI comparison rule you are referring to?=20 -- Dick= --Apple-Mail=_5EAD21E3-7725-4CC3-8CB9-0B8466EDA115 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252
On Apr 13, 2012, at 10:58 PM, Ned Freed wrote:

That said, the rules are what they are, and comparison of URIs has to be taken
into account.

What is the URI comparison rule you are referring to? 

-- Dick
--Apple-Mail=_5EAD21E3-7725-4CC3-8CB9-0B8466EDA115-- From dick.hardt@gmail.com Sat Apr 14 01:24: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 5C43D21F85C4 for ; Sat, 14 Apr 2012 01:24:42 -0700 (PDT) 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.299, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D59kOPAqO6e for ; Sat, 14 Apr 2012 01:24:41 -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 D2D1D21F85B8 for ; Sat, 14 Apr 2012 01:24:39 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2510076pbb.31 for ; Sat, 14 Apr 2012 01:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=c4+S2oVHpUodNE3GKhkxc4vwTo1xJrBVfsh2HnvZ5fA=; b=ZNN1jUY8Xfz36zm6EfTl1CGtAF9Vr+KjxBUU05oGThaQmuGSfWlAg+lWnBoJncwj2b wSA9AfvJsOGA9yDjh2j53HwhlGGQHIlK5PdBdJiKR2khxxQSto4U7Zs4N8p58U7nD0Sr 2QcM4PFYI8pTSB3kEtUEZMgNvk8YfQ/I1O+SDxlexgQTtoPguskK+Pky4+zIh4ynkD3u 4NGCGpeFYIobX+4kK6+lWx74Gn+qG1LHkByFcb+fKmYyvRfqPgdaHgqbvhPDrt8916z3 vxux1Et6q2FN+DdD88QydpOaT2SQmteiRhotlpenjKLdZKpXIMiZL9y82XXiUrojeVT+ jYeA== Received: by 10.68.138.232 with SMTP id qt8mr10903340pbb.114.1334391879593; Sat, 14 Apr 2012 01:24:39 -0700 (PDT) Received: from [10.0.0.91] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id qb10sm6615823pbb.75.2012.04.14.01.24.37 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Apr 2012 01:24:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Dick Hardt In-Reply-To: Date: Sat, 14 Apr 2012 01:24:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <898E78D1-DFFB-4B8B-9C75-7A2BD0D34CBE@gmail.com> References: <4F866AC0.3000603@qualcomm.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE2816@P3PWEX2MB008.ex2.secureserver.net> <01OEACFVDL5O00ZUIL@mauve.mrochek.com> To: Tim Bray X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Sat, 14 Apr 2012 13:04:57 -0700 Cc: Ned Freed , Apps Discuss , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Pete Resnick , Dick Hardt Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2012 08:24:42 -0000 Thanks Tim. I did not see any discussion on normalizing key=3Dvalue pairs. One would = assume that http://exmaple.com/?a=3D1&b=3D2 is equivalent to = http://exmaple.com/?b=3D2&a=3D1 -- but that does not seem to be = significant here. There are numerous practical reasons for the bearer token to be able to = be passed as a query parameter which I would be happy to enumerate if = anyone is interested. (so far no one has asked :) I'm trying to understand the desire to remove this functionality, and = after reading the spec my take away is a desire to not specify a query = parameter. What am I missing? -- Dick On Apr 14, 2012, at 12:58 AM, Tim Bray wrote: > That would be http://tools.ietf.org/html/rfc3986#section-6 >=20 > The fact that it=92s kind of long, but still doesn=92t find room for > reserved ?key=3Dval pairs, is significant in this context. -T >=20 > On Sat, Apr 14, 2012 at 12:43 AM, Dick Hardt = wrote: >>=20 >> On Apr 13, 2012, at 10:58 PM, Ned Freed wrote: >>=20 >>=20 >> That said, the rules are what they are, and comparison of URIs has to = be >> taken >> into account. >>=20 >>=20 >> What is the URI comparison rule you are referring to? >>=20 >> -- Dick From nrm@arcanedomain.com Fri Apr 13 13:57: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 33A9E21F8740 for ; Fri, 13 Apr 2012 13:57:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qBZqYq1zjJO for ; Fri, 13 Apr 2012 13:57:31 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7883521F86E1 for ; Fri, 13 Apr 2012 13:57:31 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id D7C61598088; Fri, 13 Apr 2012 13:57:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=arcanedomain.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s= arcanedomain.com; b=gPuqfPfQXb2W2JW6zyO1w26bCAruRtUMGECBtuvB5w7q UzhezpOimAPqGVYEPGX1NbQflKDumDnJkL5aaO2IMiuVwm8ktjKayWybKn1bGp5C uM8RtcC31Qs2DbD+EmnNrSGvwmSvXziawnai+53Wam/Qwqs395VppRJYM0hHCyA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=arcanedomain.com; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s= arcanedomain.com; bh=98nqg9yd3cwFYQ1vqZvxQOXsBDs=; b=nrW8xwOWNj4 l10Dr/oan3UuIZZQsh01qxRcUMRfFv6mm8n0214S/l9mMK3JSa0//ExndAviNA7M B/njQYqozEo+rtlfhbbW5pcx7p0TKPirJ3cfjrvf/w0u1DyrygYotZgnRsBIvX1l RYLTf89g2LkjI4ZHIbJO7NZVVXUJM/28= Received: from [192.168.1.40] (unknown [146.115.66.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: webmaster@arcanedomain.com) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id 6A58D598086; Fri, 13 Apr 2012 13:57:29 -0700 (PDT) Message-ID: <4F889337.4040208@arcanedomain.com> Date: Fri, 13 Apr 2012 16:57:27 -0400 From: Noah Mendelsohn User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jeni Tennison References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 14 Apr 2012 13:05:28 -0700 Cc: Ned Freed , apps-discuss@ietf.org, tony+mtsuffix@maillennium.att.com, Julian Reschke , john+ietf@jck.com, "www-tag@w3.org List" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 20:57:32 -0000 On 4/13/2012 6:34 AM, Jeni Tennison wrote: > If we wanted to use that with XSLT, we would need to say so within the application/xslt+xml media type definition and deal with the fact that the syntax clashed with XPointer syntax inherited through the use of the +xml suffix. Shouldn't we consider some overall advice as to whether generic semantics, with the goal of enabling generic processing based only on the top-level type is highly desirable in all cases/OK to selectively break in particular derived type specs/a completely false goal? Noah From derhoermi@gmx.net Sat Apr 14 14:52: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 4F8B021F8566 for ; Sat, 14 Apr 2012 14:52:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ea9ZI9VVOFz for ; Sat, 14 Apr 2012 14:52:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B3F7B21F84B2 for ; Sat, 14 Apr 2012 14:52:06 -0700 (PDT) Received: (qmail invoked by alias); 14 Apr 2012 21:52:05 -0000 Received: from dslb-094-222-140-241.pools.arcor-ip.net (EHLO HIVE) [94.222.140.241] by mail.gmx.net (mp012) with SMTP; 14 Apr 2012 23:52:05 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/akgtz6JbantTQ+Kfe3oQCI++wXnqwmux/hxDtui em3kS5TFOgjw2V From: Bjoern Hoehrmann To: Noah Mendelsohn Date: Sat, 14 Apr 2012 23:52:14 +0200 Message-ID: <5vgjo7hbms1i3fqn2fp3olrrihgmg803rm@hive.bjoern.hoehrmann.de> References: <4F877CEE.5030107@arcanedomain.com> In-Reply-To: <4F877CEE.5030107@arcanedomain.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org, "www-tag@w3.org" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2012 21:52:08 -0000 * Noah Mendelsohn wrote: >The W3C Technical Architecture Group have been concerned about conflicting >sources of definitions of fragment identifier semantics located by >following RFC 3986 and the media type definition. We believe that those >defining and registering media types (including ones that follow generic >rules such as 3023bis) need more explicit advice than currently contained >within draft-ietf-appsawg-media-type-regs. Some people would like to have fragment identifier formats that apply to entire classes of media types, but nobody cares enough to do the legwork needed to put that into some kind of coherent standard. Issues would be, for instance, whether RFC 3023 can and should be updated to retroactive- ly define all "+xml" types use XPointer fragment identifiers and what to do with the fallout from such a decision, like clashes with existing XML types that assign different semantics to their fragment identifiers; and if you have a common format for something like 2D visual media or timed media, whether that can be accomplished with a similar retroactive over- riding specification, or context-specific semantics, like for HTML the fragment identifier is interpreted in a common way unless otherwise specified, or whether all existing registrations should be updated. Firefox for instance now implements a special feature for video/ogg that allows you to say http://example.org/video#t=30 and it will then seek 30 seconds into the video. RFC 5334, which defines video/ogg, however does not mention such a feature. The syntax comes from a W3C proposal saying that everybody should update their media type registrations to allow for this syntax, and Ned Freed called that "nothing short of laughable" here in this thread. I assume Firefox supports the same for "WebM", but I've not been able to get "WebM" to work there at all and "WebM" doesn't have a registered media type anyway. The W3C has so far failed to build consensus around what should be done with respect to these issues, so there is nothing draft-ietf-appsawg- media-type-regs could advise, short of the Applications Area Working Group building this consensus first. The Technical Architecture Group would seem to be requesting that. >In particular, we are working on defining best practice for use and >definition of fragment identifier semantics, and the document >http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12 is under >development (although it has not been formally reviewed or approved by the >TAG). I note that draft-ietf-appsawg-media-type-regs went from invididual sub- mission to the end of the Working Group Last Call in about the time the TAG did not review its own document that it now wants to have linked. The document does not seem very useful for building consensus around the issues I mentioned above, it is rather essentially written from a per- spective where media type specific fragment identifiers have been re- placed by universal "fragment structures" and attempts to make a couple of suggestions. I will discuss them in reverse order: Fragment structures should be defined in ways that enable other processors to ignore fragment identifiers that use different fragment structures. Invalid fragment identifiers should result in a warning rather than an error. How some application might treat an "invalid" or unrecognized fragment identifier is very much up to the application, it is entirely possible for instance that meaningful processing is no longer possible if some secondary resource identified by a fragment identifier cannot be re- trieved because the "fragment structure" is unknown to the application, in which case an error would be far more appropriate than a warning. The first part of this item addresses a "if there is no interoperabili- ty" case; that's questionable in itself, and I really don't see what this would mean in practise. If you take the example of #svgView, that exists, among other things, so you can show a zoomed part of one image in another. A processor that does not support that is not a conforming SVG implementation and would not render the image as intended. So what would the designers of the #svgView scheme care? Media type definitions should avoid 'must' language when describing supported fragment identifiers as in practice it is likely to be ignored. Instead, they should provide pointers to any known fragment structures that might be applied to that media type and give warnings of any contradictions between them. I am unaware of any example where fragment identifier requirements were ignored more than other requirement. Sure, some SVG implementations do not support all aspects of SVG fragment identifiers, but they might also fail to support SVG fonts or have broken error handling or can only load external PNG and JPEG images but not external SVG images, so there does not seem to be a reason to single this out. And quite frankly, this SVG feature would not be very useful if it was optional, just as XInclude would be quite difficult to use interoperably if it didn't require at least the element() scheme. Fragment structures should be defined at levels that anticipate content negotiation. For example, the semantics of the svgView() fragment identifiers could be meaningfully applied to all image formats. Were a similar scheme developed in future, it should be defined for all images rather than a particular image format. Anyone defining a media type can simply say their fragment identifier syntax is the same as the syntax for SVG. They would likely have to specify a whole lot of additional information (what if the identifier references a region in a bitmap that is not aligned on pixel bounds?). It may have been better had the scheme been named #imgView, but that's about all I can make from this suggestion. I note that content nego- tiation as a whole is not used in practise as assumed here, because it doesn't work very well. The "server picks" model doesn't work well as announcing all supported types all the time is infeasible, the "client picks" model is hard to configure at the server level and not really supported, never minding linking issues (if you copy and paste a URL to send it someone else, do you want to link the representation, like to point out a typo in a language negotiated page, or is it okay if the recepient sees the page in a differnet language?) So this is of no practical relevance anyway. Fragment structures which provide multiple ways of addressing the same secondary resource should indicate which fragment identifier is canonical and should be used for making statements about that secondary resource. This has nothing to do with the "structures", there would be no point in the SVG specification saying you have to use `2.0` where you could also simply use `2` or the specification of the XPath scheme saying it is always `[A and B]` and never `[B and A]`, and whether you reference `#example` or `//p[3]` is again not a decision that the definition of the media type or the fragment identifier "structure" can make. People who publish documents might want to say "Please do not rely on section numbers but rather use the IDs, the former may change", and in the odd event that some RDF folks want to make statements about regions in SVG images, they might it sensible to follow certain conventions, and they might indeed always use `2.0` instead of `2`, but having this in the SVG specification itself would be akin to the HTML specification saying people should not change section numbers or headings to make it easy to create stable references to them. >We believe media type registration authors should be pointed to these >recommendations by reference from draft-ietf-appsawg-media-type-regs. In its current form it does not provide useful information to people who might want to register a media type. That is primarily because there is currently no consensus whether someone registering, for instance, a new image media type should care about "media fragments" and reference that specification should they like to have #xywh fragment identifiers; if so there would be some marginal utility in exposing them to their existence but beyond that I don't see why anyone wishing to register a media type should bother reading this document. >We would like to coordinate the development of these documents effectively >and would appreciate your feedback on how best to accomplish this. I think it would be a good start if you abandon the "provide guidance" idea, as that is just a means to an end, and define the problem to be solved instead, show that it needs fixing, that it can be fixed, and so on and so forth. A problem is that Firefox supports media fragments on video/ogg resources but you cannot discover media fragments going from any of the URI, MIME, HTTP, Ogg, Theora, and so on specifications in any obvious manner. That is a problem. If people can simply make up their own generic "structures", there is nothing much to prevent collisions. That is probably also a problem. Maybe it's a bad idea for types to "in- herit" fragment identifiers, maybe RFC3023bis should not add XPointer to all +xml types. Maybe RFC 3986 should be updated to say that context may also affect how fragment identifiers are interpreted, as above, "HTML5" might say if you have ` X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD8B21F873D for ; Sat, 14 Apr 2012 23:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.003 X-Spam-Level: X-Spam-Status: No, score=-99.003 tagged_above=-999 required=5 tests=[AWL=0.787, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fEAwPv9GZXQ for ; Sat, 14 Apr 2012 23:08:27 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 177B221F873C for ; Sat, 14 Apr 2012 23:08:26 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q3F68IQO009124 for ; Sun, 15 Apr 2012 15:08:19 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 0e80_9c63_6539061c_86c1_11e1_8470_001d096c5782; Sun, 15 Apr 2012 15:08:17 +0900 Received: from [IPv6:::1] ([133.2.210.1]:41183) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 15 Apr 2012 15:08:21 +0900 Message-ID: <4F8A65CA.7080102@it.aoyama.ac.jp> Date: Sun, 15 Apr 2012 15:08:10 +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: Ned Freed References: <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org> <4F88899D.3090405@gmx.de> <20120414121040.GF696@jay.w3.org> <4F896D3D.9010805@gmx.de> <01OEATK3NNY800ZUIL@mauve.mrochek.com> In-Reply-To: <01OEATK3NNY800ZUIL@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 06:08:27 -0000 On 2012/04/14 22:55, Ned Freed wrote: > My understanding is that pack200 is a type-specific compression format. > That > is, it only works if the input is a jar file. In this sense there is > overlap > with EXI - I believe EXI relies on the input having XML syntax (although it > doesn't necessarily have to be well formed), If it's not well-formed, it's not XML. Did you mean "not valid"? Regards, Martin. > which means it is only > applicable > to a subset of media types. From eran@hueniverse.com Sat Apr 14 23:31: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 9B82D21F8755 for ; Sat, 14 Apr 2012 23:31:30 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tf8HzdN9KiaI for ; Sat, 14 Apr 2012 23:31:30 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id E35AF21F86F2 for ; Sat, 14 Apr 2012 23:31:29 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id y6XV1i0010EuLVk016XVtA; Sat, 14 Apr 2012 23:31:29 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Sat, 14 Apr 2012 23:31:29 -0700 From: Eran Hammer To: Stephen Farrell , Mark Nottingham Thread-Topic: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer Thread-Index: AQHNGbtQA3AE6iq1N0CHEtRtSCOel5aZuYyAgAAT1QCAAaFFoA== Date: Sun, 15 Apr 2012 06:31:28 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> In-Reply-To: <4F88AA3A.8040401@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pete Resnick , Ned Freed , Apps Discuss , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2012 06:31:30 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Friday, April 13, 2012 3:36 PM > To: Mark Nottingham > Cc: Pete Resnick; Ned Freed; draft-ietf-oauth-v2-bearer.all@tools.ietf.or= g; > Apps Discuss > Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf- > oauth-v2-bearer >=20 >=20 >=20 > On 04/13/2012 10:24 PM, Mark Nottingham wrote: > > Because it's a name space that is managed and owned by the authority of > the URI, not any standards organisation. > > > > I.e. we tell them how the URI is structured, not what to put into it. > > > > We made *one* exception for this in .well-known as an escape valve for > abuse. If we continue allowing this kind of abuse, we'll have little defe= nce > against things like standardising filename extensions in URLs and reservi= ng an > "/about/" URI's semantics -- things which are clearly violating the archi= tecture > of the WWW: > > http://www.w3.org/TR/webarch/#uri-opacity >=20 > (Sticking with the naivety:-) So, what's different there from how the bas= e > oauth draft registers client_id and shows how that can be used in a GET > request? [1] Big difference. The base draft specifies its own endpoints as part of a com= plete API package for obtaining authorization. These parameters are scoped = only for the endpoints defined and not for any others. There is no possibil= ity of conflict because the specification defines the entire namespace. OTOH, the bearer spec is applied to *any* web resources using OAuth authent= ication where some other namespace definition must exist. EH =20 > Ta, > S. >=20 > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-25#page-24 > (bottom of page) >=20 >=20 > > > > Cheers, > > > > > > On 13/04/2012, at 4:20 PM, Stephen Farrell wrote: > > > >> > >> > >> On 04/13/2012 08:43 AM, Ned Freed wrote: > >>> I certainly don't object to doing that. In fact I don't object to > >>> dropping this nasty hack from the document, although perhaps > >>> documenting it as *not* standardized and explaining why it sucks woul= d > be even better. > >> > >> So I've a possibly naive question: > >> > >> Why is it harmful to standardise a parameter name for use in query > >> strings? > >> > >> Note: I'm not asking if access_token is a good or bad name for one of > >> those, nor how exactly to standardise one well or badly, nor who > >> should do that, but it seems from the comments here that some folks > >> are against the idea of standardising anything after the authority is > >> a bad idea, and I don't get why exactly that might be the case. > >> > >> Thanks, > >> S. > >> > > > > -- > > Mark Nottingham > > http://www.mnot.net/ > > > > > > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From masinter@adobe.com Sun Apr 15 04:05: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 87E9821F8693 for ; Sun, 15 Apr 2012 04:05:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S08SROT+1CKF for ; Sun, 15 Apr 2012 04:05:35 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1506921F8685 for ; Sun, 15 Apr 2012 04:05:34 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKT4qrdr8qRCEkMpHzqoNjTV+1Gc3D20oY@postini.com; Sun, 15 Apr 2012 04:05:35 PDT 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 q3FB3IJ0028377; Sun, 15 Apr 2012 04:03:18 -0700 (PDT) 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 q3FB5Pvm029421; Sun, 15 Apr 2012 04:05:26 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Sun, 15 Apr 2012 04:05:25 -0700 From: Larry Masinter To: "sm@resistor.net" , "apps-discuss@ietf.org" Date: Sun, 15 Apr 2012 04:07:04 -0700 Thread-Topic: [apps-discuss] Comments on draft-ietf-appsawg-media-type-regs-04 Thread-Index: Ac0a96iUZI7ORGYrSyGLgaUKPE+4VA== 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: multipart/alternative; boundary="_000_cc048caf3e1948edb4b15af5092e5953blur_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-media-type-regs-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, 15 Apr 2012 11:05:36 -0000 --_000_cc048caf3e1948edb4b15af5092e5953blur_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 c2hvdWxkIHRoZXJlIGJlIGEgcHJvY2VzcyBmb3IgbW92aW5nIHZlbmRvciB0cmVlIGZvcm1hdHMg dG8gc3RhbmRhcmRzIHRyZWUsIHdoZW4gcHJvZHVjdCBmb3JtYXRzIGJlY29tZSBvcGVuIHN0YW5k YXJkcyAoYXMgaGFwcGVuZWQgd2l0aCBQREYpID8NCkNvbm5lY3RlZCBieSBEUk9JRCBvbiBWZXJp em9uIFdpcmVsZXNzDQoNCg0KLS0tLS1PcmlnaW5hbCBtZXNzYWdlLS0tLS0NCkZyb206IFNNIDxz bUByZXNpc3Rvci5uZXQ+DQpUbzogImFwcHMtZGlzY3Vzc0BpZXRmLm9yZyIgPGFwcHMtZGlzY3Vz c0BpZXRmLm9yZz4NClNlbnQ6IEZyaSwgQXByIDEzLCAyMDEyIDA4OjU0OjEwIEdNVCswMDowMA0K U3ViamVjdDogW2FwcHMtZGlzY3Vzc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1hcHBzYXdnLW1l ZGlhLXR5cGUtcmVncy0wNA0KDQpJJ2xsIGRlZmVyIHRvIHRoZSBhdXRob3JzIGZvciB0aGUgZm9s bG93aW5nIG5pdHMgb24NCmRyYWZ0LWlldGYtYXBwc2F3Zy1tZWRpYS10eXBlLXJlZ3MtMDQuDQoN CkluIFNlY3Rpb24gMy4xOg0KDQogICAiVGhlIGZpcnN0IHByb2NlZHVyZSBpcyB1c2VkIGZvciBy ZWdpc3RlcmluZyByZWdpc3RyYXRpb25zIGZyb20gSUVURg0KICAgIENvbnNlbnN1cyBkb2N1bWVu dHMsIG9yIGluIHJhcmUgY2FzZXMgd2hlbiByZWdpc3RlcmluZyBhDQogICAgZ3JhbmRmYXRoZXJl ZCAoc2VlIEFwcGVuZGl4IEEpIGFuZC9vciBvdGhlcndpc2UgaW5jb21wbGV0ZQ0KICAgIHJlZ2lz dHJhdGlvbiBpcyBpbiB0aGUgaW50ZXJlc3Qgb2YgdGhlIEludGVybmV0IGNvbW11bml0eS4iDQoN ClN1Z2dlc3RlZCB0ZXh0Og0KDQogICAgVGhlIGZpcnN0IHByb2NlZHVyZSBpcyB1c2VkIGZvciBy ZWdpc3RlcmluZyByZWdpc3RyYXRpb25zIGZyb20gSUVURg0KICAgIGRvY3VtZW50cywgb3IgaW4g cmFyZSBjYXNlcyB3aGVuIHJlZ2lzdGVyaW5nIGEgZ3JhbmRmYXRoZXJlZA0KICAgIChzZWUgQXBw ZW5kaXggQSkgYW5kL29yIG90aGVyd2lzZSBpbmNvbXBsZXRlIHJlZ2lzdHJhdGlvbiBpcyBpbiB0 aGUNCiAgICBpbnRlcmVzdCBvZiB0aGUgSW50ZXJuZXQgY29tbXVuaXR5Lg0KDQpUaGUgcHJvcG9z ZWQgY2hhbmdlIGFsaWducyB0aGUgdGV4dCB3aXRoIHRoZSAiTVVTVCIgaW4gdGhlIGZpcnN0DQpw YXJhZ3JhcGggb2YgU2VjdGlvbiAzLjEuDQoNCiAgICJJbiB0aGUgY2FzZSBvZiByZWdpc3RyYXRp b24gZm9yIHRoZSBJRVRGIGl0c2VsZiwgdGhlIHJlZ2lzdHJhdGlvbg0KICAgIHByb3Bvc2FsIE1V U1QgYmUgcHVibGlzaGVkIGFzIGFuIElFVEYgQ29uc2Vuc3VzIFJGQywgd2hpY2ggY2FuIGJlIG9u DQogICAgdGhlIFN0YW5kYXJkcyBUcmFjaywgYSBCQ1AsIEluZm9ybWF0aW9uYWwsIG9yIEV4cGVy aW1lbnRhbC4iDQoNClRoZSB0ZXh0IGlzIHJlZHVuZGFudCAoc2VlIGZpcnN0IHBhcmFncmFwaCBv ZiB0aGF0DQpzZWN0aW9uKS4gIERlcGVuZGluZyBvbiB3aGF0IHRoZSBvYmplY3RpdmUgaXMsIHRo ZSBhYm92ZSB0ZXh0IGNvdWxkDQpiZSBtb2RpZmllZCB0byByZWZlciB0byAiU3RhbmRhcmRzIEFj dGlvbiIgb3IgIklFVEYgUmV2aWV3Ii4NCg0KSW4gU2VjdGlvbiAzLjI6DQoNCiAgIlRoZSB2ZW5k b3IgdHJlZSBpcyB1c2VkIGZvciBtZWRpYSB0eXBlcyBhc3NvY2lhdGVkIHdpdGggcHVibGljbHkN CiAgIGF2YWlsYWJsZSBwcm9kdWN0cy4iDQoNClBldGVyIHJhaXNlZCBhIHF1ZXN0aW9uIGFib3V0 IHdoZXRoZXIgTW96aWxsYSBpcyBhIHZlbmRvci4gIEl0DQpxdWFsaWZpZXMgYXMgYSB2ZW5kb3Iu DQoNCkluIFNlY3Rpb24gMy40Og0KDQogICAnU3VidHlwZSBuYW1lcyB3aXRoICJ4LiIgYXMgdGhl IGZpcnN0IGZhY2V0IG1heSBiZSB1c2VkIGZvciB0eXBlcw0KICAgIGludGVuZGVkIGV4Y2x1c2l2 ZWx5IGZvciB1c2UgaW4gcHJpdmF0ZSwgbG9jYWwgZW52aXJvbm1lbnRzLg0KDQpBcyBJLUQuaWV0 Zi1hcHBzYXdnLXhkYXNoIGlzIGEgd29yayBwcm9kdWN0IG9mIHRoaXMgd29ya2luZyBncm91cCwg aXQNCmRvZXMgbm90IG1ha2Ugc2Vuc2UgdG8gcmVnaXN0ZXIgInguIiBmb3IgdXNlIGluIHByaXZh dGUsIGxvY2FsIGVudmlyb25tZW50Lg0KDQpJbiBTZWN0aW9uIDQuMi44Og0KDQogICAiVGhlIHBy aW1hcnkgZ3VpZGVsaW5lIGZvciB3aGV0aGVyIGEgc3RydWN0dXJlZCB0eXBlIG5hbWUgc3VmZml4 DQogICAgc2hvdWxkIGJlIHJlZ2lzdGVyYWJsZSBpcyB0aGF0IGl0IGJlIGRlc2NyaWJlZCBieSBh IHJlYWRpbHktYXZhaWxhYmxlDQogICAgZGVzY3JpcHRpb24sIHByZWZlcmFibHkgd2l0aGluIGEg ZG9jdW1lbnQgcHVibGlzaGVkIGJ5IGFuIGVzdGFibGlzaGVkDQogICAgc3RhbmRhcmRzIG9yZ2Fu aXphdGlvbiwgYW5kIGZvciB3aGljaCB0aGVyZSdzIGEgcmVmZXJlbmNlIHRoYXQgY2FuIGJlDQog ICAgdXNlZCBpbiBhIFJlZmVyZW5jZXMgc2VjdGlvbiBvZiBhbiBSRkMuIg0KDQpJIHN1Z2dlc3Qg cHJlZmFjaW5nICJSZWZlcmVuY2VzIiB3aXRoICJub3JtYXRpdmUiLg0KDQpJbiBTZWN0aW9uIDQu Mi45Og0KDQogICAiSW4gc29tZSBjYXNlcyBhIHNpbmdsZSBtZWRpYSB0eXBlIG1heSBoYXZlIGJl ZW4gd2lkZWx5IGRlcGxveWVkIHByaW9yDQogICAgdG8gcmVnaXN0cmlvbiB1bmRlciBtdWx0aXBs ZSBuYW1lcy4iDQoNClR5cG86IHJlZ2lzdHJhdGlvbi4NCg0KICAgIkhvd2V2ZXIsIGEgbGlzdCBv ZiBkZXByZWNhdGVkIGFsaWFzZXMgdGhlIHR5cGUgaXMga25vd24gYnkgTUFZDQogICAgYmUgc3Vw cGxpZWQgYXMgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBpbiBvcmRlciB0byBhc3Npc3QNCiAgICBh cHBsaWNhdGlvbiBpbiBwcm9jZXNzaW5nIHRoZSBtZWRpYSB0eXBlIHByb3Blcmx5LiINCg0KU3Vn Z2VzdGVkIHRleHQ6DQoNCiAgIHRvIGFzc2lzdCB0aGUgc29mdHdhcmUNCg0KSW4gU2VjdGlvbiA0 LjQ6DQoNCiAgICJBIHByZWNpc2UgYW5kIG9wZW5seSBhdmFpbGFibGUgc3BlY2lmaWNhdGlvbiBv ZiB0aGUgZm9ybWF0IG9mIGVhY2gNCiAgICBtZWRpYSB0eXBlIE1VU1QgZXhpc3QgZm9yIGFsbCB0 eXBlcyByZWdpc3RlcmVkIGluIHRoZSBzdGFuZGFyZHMgdHJlZQ0KICAgIGFuZCBNVVNUIGF0IGEg bWluaW11bSBiZSByZWZlcmVuY2VkIGJ5LCBpZiBpdCBpcyBub3QgYWN0dWFsbHkNCiAgICBpbmNs dWRlZCBpbiwgdGhlIG1lZGlhIHR5cGUgcmVnaXN0cmF0aW9uIHByb3Bvc2FsIGl0c2VsZi4iDQoN Cg0KUkZDIDUyMjYgaGFzIHRoZSBmb2xsb3dpbmcgZGVzY3JpcHRpb24gZm9yICJTcGVjaWZpY2F0 aW9uIFJlcXVpcmVkIjoNCg0KICAgImRvY3VtZW50ZWQgaW4gYSBwZXJtYW5lbnQgYW5kIHJlYWRp bHkgYXZhaWxhYmxlIHB1YmxpYw0KICAgIHNwZWNpZmljYXRpb24sIGluIHN1ZmZpY2llbnQgZGV0 YWlsIHNvIHRoYXQgaW50ZXJvcGVyYWJpbGl0eQ0KICAgIGJldHdlZW4gaW5kZXBlbmRlbnQgaW1w bGVtZW50YXRpb25zIGlzIHBvc3NpYmxlIg0KDQpJdCdzIGxlc3MgaGFzc2xlIHRvIGFsaWduIHRo ZSB0ZXJtcyBpbnN0ZWFkIG9mIHRyeWluZyB0byBmaWd1cmUgb3V0DQp3aGF0ICJwcmVjaXNlIiBv ciAib3Blbmx5IGF2YWlsYWJsZSIgbWVhbnMuDQoNClN1Z2dlc3RlZCB0ZXh0Og0KDQogICAgQSBw ZXJtYW5lbnQgYW5kIHJlYWRpbHkgYXZhaWxhYmxlIHB1YmxpY2x5IGF2YWlsYWJsZSBzcGVjaWZp Y2F0aW9uLCBpbg0KICAgIHN1ZmZpY2llbnQgZGV0YWlsIHNvIHRoYXQgaW50ZXJvcGVyYWJpbGl0 eSBiZXR3ZWVuIGluZGVwZW5kZW50DQogICAgaW1wbGVtZW50YXRpb25zIGlzIHBvc3NpYmxlLCBv ZiB0aGUgZm9ybWF0IG9mIGVhY2ggbWVkaWEgdHlwZSBNVVNUDQogICAgZXhpc3QgZm9yIGFsbCB0 eXBlcyByZWdpc3RlcmVkIGluIHRoZSBzdGFuZGFyZHMgdHJlZSAgYW5kIE1VU1QgYXQgYQ0KICAg IG1pbmltdW0gYmUgcmVmZXJlbmNlZCBieSwgaWYgaXQgaXMgbm90IGFjdHVhbGx5IGluY2x1ZGVk IGluLCB0aGUNCiAgICBtZWRpYSB0eXBlIHJlZ2lzdHJhdGlvbiBwcm9wb3NhbCBpdHNlbGYuDQoN CiAgICJBcyBzdWNoLCB0ZWZlcmVuY2VzIHRvIG9yIGluY2x1c2lvbiBvZiBmb3JtYXQgc3BlY2lm aWNhdGlvbnMgaW4iDQoNClR5cG86IHJlZmVyZW5jZXMuDQoNCkluIFNlY3Rpb24gNC42Og0KDQog ICAnVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gb2YgYWxsIHJlZ2lzdHJhdGlv bnMgaXMgc3ViamVjdA0KICAgIHRvIGNvbnRpbnVpbmcgZXZhbHVhdGlvbiBhbmQgbW9kaWZpY2F0 aW9uLCBhbmQgaW4gcGFydGljdWxhciBNQVkgYmUNCiAgICBleHRlbmRlZCBieSB1c2Ugb2YgdGhl ICJjb21tZW50cyBvbiBtZWRpYSB0eXBlcyIgbWVjaGFuaXNtIGRlc2NyaWJlZA0KICAgIGluIFNl Y3Rpb24gNS40IGJlbG93LicNCg0KSXMgdGhlIGludGVudCB0byBoYXZlIG9uZ29pbmcgZXZhbHVh dGlvbiB3aXRoIGFueSB1cGRhdGVkIGluZm9ybWF0aW9uDQphZGRlZCBhcyBjb21tZW50cz8NCg0K QlRXLCAiYW5kIG1vZGlmaWNhdGlvbiIgZG9lcyBub3Qgc2VlbSBjb3JyZWN0IGluIHRoZSBhYm92 ZS4gIERvZXMgaXQNCm1lYW4gdGhhdCBhIHJlZ2lzdHJhdGlvbiBtYWRlIHRocm91Z2ggYSBzcGVj aWZpY2F0aW9uIHdvdWxkIHJlcXVpcmUNCmFuIHVwZGF0ZSBvZiB0aGUgc3BlY2lmaWNhdGlvbj8N Cg0KSW4gU2VjdGlvbiA0LjEwOg0KDQogICAiUkZDIHB1YmxpY2F0aW9uIG9mIHZlbmRvciBhbmQg cGVyc29uYWwgbWVkaWEgdHlwZSByZWdpc3RyYXRpb25zDQogICAgaXMgYWxsb3dlZCBidXQgbm90 IHJlcXVpcmVkLiINCg0KSSBzdWdnZXN0ICJlbmNvdXJhZ2VkIiBpbnN0ZWFkIG9mICJhbGxvd2Vk Ii4NCg0KICAgIkFkZGl0aW9uYWxseSwgYW55IGNvcHlyaWdodCBvbiB0aGUgcmVnaXN0cmF0aW9u IHRlbXBsYXRlIE1VU1QgYWxsb3cNCiAgICB0aGUgSUFOQSB0byBjb3B5IGl0IGludG8gdGhlIElB TkEgcmVnaXN0cnkuIg0KDQpUaGVyZSB3YXMgYSBxdWVzdGlvbiBzb21lIHRpbWUgYmFjayBhYm91 dCBjb3B5cmlnaHQgYW5kIElBTkENCnJlZ2lzdHJpZXMuICBJIHN1Z2dlc3QgZ29pbmcgd2l0aCB0 aGUgbGVzc2VyIHJlc3RyaWN0aXZlIGNvcHlyaWdodCBhcw0KaW5ib3VuZCByaWdodHMuICBUaGF0 IHdvdWxkIGFsbG93IGRlcml2YXRpdmUgd29yayBhcyBsb25nIGFzIHlvdQ0KZG9uJ3QgY2xhaW0g dGhhdCBpdCBpcyB3aGF0J3MgaW4gdGhlIElBTkEgcmVnaXN0cnkuICBBbiBhbHRlcm5hdGl2ZQ0K YXJndW1lbnQgd291bGQgYmUgdG8gcmVxdWlyZSBpbmJvdW5kIHJpZ2h0cyB0byB0aGUgSUVURiBh bmQgbGVhdmUNCklFVEYvSUFOQSBpbnRlcmFjdGlvbiBhcyBhbiBpbnRlcm5hbCBpc3N1ZS4NCg0K ICAgIlRvIGJlY29tZSBJbnRlcm5ldCBTdGFuZGFyZHMsIGEgcHJvdG9jb2wgb3IgZGF0YSBvYmpl Y3QgbXVzdCBnbw0KICAgIHRocm91Z2ggdGhlIElFVEYgc3RhbmRhcmRzIHByb2Nlc3MuIg0KDQpT dWdnZXN0ZWQgdGV4dDogIlRvIGJlY29tZSBhbiBJbnRlcm5ldCBTdGFuZGFyZCIuDQoNCiAgICJB cyBkaXNjdXNzZWQgYWJvdmUsIHJlZ2lzdHJhdGlvbiBvZiBhIHRvcC1sZXZlbCB0eXBlIHJlcXVp cmVzDQogICAgc3RhbmRhcmRzLXRyYWNrIHByb2Nlc3NpbmcgaW4gdGhlIElFVEYgYW5kLCBoZW5j ZSwgUkZDIHB1YmxpY2F0aW9uLiINCg0KU3VnZ2VzdGVkIHRleHQ6DQoNCiAgIEFzIGRpc2N1c3Nl ZCBhYm92ZSwgcmVnaXN0cmF0aW9uIG9mIGEgdG9wLWxldmVsIHR5cGUgcmVxdWlyZXMNCiAgIFN0 YW5kYXJkcyBBY3Rpb24gaW4NCg== --_000_cc048caf3e1948edb4b15af5092e5953blur_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHN0eWxlIHR5cGU9InRleHQvY3NzIj5ib2R5IHt3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IGJhY2tncm91bmQtY29sb3I6I2ZmZmZmZjt9PC9zdHlsZT48L2hlYWQ+PGJvZHk+PGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweCI+c2hvdWxk IHRoZXJlIGJlIGEgcHJvY2VzcyBmb3IgbW92aW5nIHZlbmRvciB0cmVlIGZvcm1hdHMgdG8gc3Rh bmRhcmRzIHRyZWUsIHdoZW4gcHJvZHVjdCBmb3JtYXRzIGJlY29tZSBvcGVuIHN0YW5kYXJkcyAo YXMgaGFwcGVuZWQgd2l0aCBQREYpID88YnI+PGZvbnQgY29sb3I9IiMzMzMzMzMiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDE0cHgiPjxmb250IGZhY2U9InNhbnMtc2VyaWYiPkNvbm5lY3Rl ZCBieSBEUk9JRCBvbiBWZXJpem9uIFdpcmVsZXNzPC9mb250Pjwvc3Bhbj48L2k+PC9mb250Pjwv ZGl2Pjxicj48YnI+LS0tLS1PcmlnaW5hbCBtZXNzYWdlLS0tLS08YnI+PGJsb2NrcXVvdGUgc3R5 bGU9IjsgYm9yZGVyLWxlZnQ6IDJweCBzb2xpZCByZ2IoMTYsIDE2LCAyNTUpOyBtYXJnaW4tbGVm dDogNXB4OyBwYWRkaW5nLWxlZnQ6IDVweDsiPjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHgiPjxiPkZyb206IDwvYj5TTSAmbHQ7c21AcmVzaXN0b3Iu bmV0Jmd0OzxiPjxicj5UbzogPC9iPiZxdW90O2FwcHMtZGlzY3Vzc0BpZXRmLm9yZyZxdW90OyAm bHQ7YXBwcy1kaXNjdXNzQGlldGYub3JnJmd0OzxiPjxicj5TZW50OiA8L2I+RnJpLCBBcHIgMTMs IDIwMTIgMDg6NTQ6MTAgR01UKzAwOjAwPGI+PGJyPlN1YmplY3Q6IDwvYj5bYXBwcy1kaXNjdXNz XSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWFwcHNhd2ctbWVkaWEtdHlwZS1yZWdzLTA0PGJyPjxi cj48L2Rpdj48ZGl2PjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IEV4 Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQgLS0+DQo8c3R5bGU+PCEt LSAuRW1haWxRdW90ZSB7IG1hcmdpbi1sZWZ0OiAxcHQ7IHBhZGRpbmctbGVmdDogNHB0OyBib3Jk ZXItbGVmdDogIzgwMDAwMCAycHggc29saWQ7IH0gLS0+PC9zdHlsZT4NCjxkaXY+DQo8Zm9udCBz aXplPSIyIj48ZGl2IGNsYXNzPSJQbGFpblRleHQiPkknbGwgZGVmZXIgdG8gdGhlIGF1dGhvcnMg Zm9yIHRoZSBmb2xsb3dpbmcgbml0cyBvbiA8YnI+DQpkcmFmdC1pZXRmLWFwcHNhd2ctbWVkaWEt dHlwZS1yZWdzLTA0Ljxicj4NCjxicj4NCkluIFNlY3Rpb24gMy4xOjxicj4NCjxicj4NCiZuYnNw OyZuYnNwOyAmcXVvdDtUaGUgZmlyc3QgcHJvY2VkdXJlIGlzIHVzZWQgZm9yIHJlZ2lzdGVyaW5n IHJlZ2lzdHJhdGlvbnMgZnJvbSBJRVRGPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IENvbnNlbnN1 cyBkb2N1bWVudHMsIG9yIGluIHJhcmUgY2FzZXMgd2hlbiByZWdpc3RlcmluZyBhPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7IGdyYW5kZmF0aGVyZWQgKHNlZSBBcHBlbmRpeCBBKSBhbmQvb3Igb3Ro ZXJ3aXNlIGluY29tcGxldGU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgcmVnaXN0cmF0aW9uIGlz IGluIHRoZSBpbnRlcmVzdCBvZiB0aGUgSW50ZXJuZXQgY29tbXVuaXR5LiZxdW90Ozxicj4NCjxi cj4NClN1Z2dlc3RlZCB0ZXh0Ojxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgZmly c3QgcHJvY2VkdXJlIGlzIHVzZWQgZm9yIHJlZ2lzdGVyaW5nIHJlZ2lzdHJhdGlvbnMgZnJvbSBJ RVRGPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGRvY3VtZW50cywgb3IgaW4gcmFyZSBjYXNlcyB3 aGVuIHJlZ2lzdGVyaW5nIGEgZ3JhbmRmYXRoZXJlZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAo c2VlIEFwcGVuZGl4IEEpIGFuZC9vciBvdGhlcndpc2UgaW5jb21wbGV0ZSByZWdpc3RyYXRpb24g aXMgaW4gdGhlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVyZXN0IG9mIHRoZSBJbnRlcm5l dCBjb21tdW5pdHkuPGJyPg0KPGJyPg0KVGhlIHByb3Bvc2VkIGNoYW5nZSBhbGlnbnMgdGhlIHRl eHQgd2l0aCB0aGUgJnF1b3Q7TVVTVCZxdW90OyBpbiB0aGUgZmlyc3QgPGJyPg0KcGFyYWdyYXBo IG9mIFNlY3Rpb24gMy4xLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyAmcXVvdDtJbiB0aGUgY2Fz ZSBvZiByZWdpc3RyYXRpb24gZm9yIHRoZSBJRVRGIGl0c2VsZiwgdGhlIHJlZ2lzdHJhdGlvbjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBwcm9wb3NhbCBNVVNUIGJlIHB1Ymxpc2hlZCBhcyBhbiBJ RVRGIENvbnNlbnN1cyBSRkMsIHdoaWNoIGNhbiBiZSBvbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyB0aGUgU3RhbmRhcmRzIFRyYWNrLCBhIEJDUCwgSW5mb3JtYXRpb25hbCwgb3IgRXhwZXJpbWVu dGFsLiZxdW90Ozxicj4NCjxicj4NClRoZSB0ZXh0IGlzIHJlZHVuZGFudCAoc2VlIGZpcnN0IHBh cmFncmFwaCBvZiB0aGF0IDxicj4NCnNlY3Rpb24pLiZuYnNwOyBEZXBlbmRpbmcgb24gd2hhdCB0 aGUgb2JqZWN0aXZlIGlzLCB0aGUgYWJvdmUgdGV4dCBjb3VsZCA8YnI+DQpiZSBtb2RpZmllZCB0 byByZWZlciB0byAmcXVvdDtTdGFuZGFyZHMgQWN0aW9uJnF1b3Q7IG9yICZxdW90O0lFVEYgUmV2 aWV3JnF1b3Q7Ljxicj4NCjxicj4NCkluIFNlY3Rpb24gMy4yOjxicj4NCjxicj4NCiZuYnNwOyAm cXVvdDtUaGUgdmVuZG9yIHRyZWUgaXMgdXNlZCBmb3IgbWVkaWEgdHlwZXMgYXNzb2NpYXRlZCB3 aXRoIHB1YmxpY2x5PGJyPg0KJm5ic3A7Jm5ic3A7IGF2YWlsYWJsZSBwcm9kdWN0cy4mcXVvdDs8 YnI+DQo8YnI+DQpQZXRlciByYWlzZWQgYSBxdWVzdGlvbiBhYm91dCB3aGV0aGVyIE1vemlsbGEg aXMgYSB2ZW5kb3IuJm5ic3A7IEl0IDxicj4NCnF1YWxpZmllcyBhcyBhIHZlbmRvci48YnI+DQo8 YnI+DQpJbiBTZWN0aW9uIDMuNDo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgJ1N1YnR5cGUgbmFt ZXMgd2l0aCAmcXVvdDt4LiZxdW90OyBhcyB0aGUgZmlyc3QgZmFjZXQgbWF5IGJlIHVzZWQgZm9y IHR5cGVzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciB1 c2UgaW4gcHJpdmF0ZSwgbG9jYWwgZW52aXJvbm1lbnRzLjxicj4NCjxicj4NCkFzIEktRC5pZXRm LWFwcHNhd2cteGRhc2ggaXMgYSB3b3JrIHByb2R1Y3Qgb2YgdGhpcyB3b3JraW5nIGdyb3VwLCBp dCA8YnI+DQpkb2VzIG5vdCBtYWtlIHNlbnNlIHRvIHJlZ2lzdGVyICZxdW90O3guJnF1b3Q7IGZv ciB1c2UgaW4gcHJpdmF0ZSwgbG9jYWwgZW52aXJvbm1lbnQuPGJyPg0KPGJyPg0KSW4gU2VjdGlv biA0LjIuODo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgJnF1b3Q7VGhlIHByaW1hcnkgZ3VpZGVs aW5lIGZvciB3aGV0aGVyIGEgc3RydWN0dXJlZCB0eXBlIG5hbWUgc3VmZml4PGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7IHNob3VsZCBiZSByZWdpc3RlcmFibGUgaXMgdGhhdCBpdCBiZSBkZXNjcmli ZWQgYnkgYSByZWFkaWx5LWF2YWlsYWJsZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlw dGlvbiwgcHJlZmVyYWJseSB3aXRoaW4gYSBkb2N1bWVudCBwdWJsaXNoZWQgYnkgYW4gZXN0YWJs aXNoZWQ8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgc3RhbmRhcmRzIG9yZ2FuaXphdGlvbiwgYW5k IGZvciB3aGljaCB0aGVyZSdzIGEgcmVmZXJlbmNlIHRoYXQgY2FuIGJlPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7IHVzZWQgaW4gYSBSZWZlcmVuY2VzIHNlY3Rpb24gb2YgYW4gUkZDLiZxdW90Ozxi cj4NCjxicj4NCkkgc3VnZ2VzdCBwcmVmYWNpbmcgJnF1b3Q7UmVmZXJlbmNlcyZxdW90OyB3aXRo ICZxdW90O25vcm1hdGl2ZSZxdW90Oy48YnI+DQo8YnI+DQpJbiBTZWN0aW9uIDQuMi45Ojxicj4N Cjxicj4NCiZuYnNwOyZuYnNwOyAmcXVvdDtJbiBzb21lIGNhc2VzIGEgc2luZ2xlIG1lZGlhIHR5 cGUgbWF5IGhhdmUgYmVlbiB3aWRlbHkgZGVwbG95ZWQgcHJpb3I8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgdG8gcmVnaXN0cmlvbiB1bmRlciBtdWx0aXBsZSBuYW1lcy4mcXVvdDs8YnI+DQo8YnI+ DQpUeXBvOiByZWdpc3RyYXRpb24uPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7ICZxdW90O0hvd2V2 ZXIsIGEgbGlzdCBvZiBkZXByZWNhdGVkIGFsaWFzZXMgdGhlIHR5cGUgaXMga25vd24gYnkgTUFZ PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGJlIHN1cHBsaWVkIGFzIGFkZGl0aW9uYWwgaW5mb3Jt YXRpb24gaW4gb3JkZXIgdG8gYXNzaXN0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGFwcGxpY2F0 aW9uIGluIHByb2Nlc3NpbmcgdGhlIG1lZGlhIHR5cGUgcHJvcGVybHkuJnF1b3Q7PGJyPg0KPGJy Pg0KU3VnZ2VzdGVkIHRleHQ6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IHRvIGFzc2lzdCB0aGUg c29mdHdhcmU8YnI+DQo8YnI+DQpJbiBTZWN0aW9uIDQuNDo8YnI+DQo8YnI+DQombmJzcDsmbmJz cDsgJnF1b3Q7QSBwcmVjaXNlIGFuZCBvcGVubHkgYXZhaWxhYmxlIHNwZWNpZmljYXRpb24gb2Yg dGhlIGZvcm1hdCBvZiBlYWNoPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IG1lZGlhIHR5cGUgTVVT VCBleGlzdCBmb3IgYWxsIHR5cGVzIHJlZ2lzdGVyZWQgaW4gdGhlIHN0YW5kYXJkcyB0cmVlPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCBNVVNUIGF0IGEgbWluaW11bSBiZSByZWZlcmVuY2Vk IGJ5LCBpZiBpdCBpcyBub3QgYWN0dWFsbHk8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgaW5jbHVk ZWQgaW4sIHRoZSBtZWRpYSB0eXBlIHJlZ2lzdHJhdGlvbiBwcm9wb3NhbCBpdHNlbGYuJnF1b3Q7 PGJyPg0KPGJyPg0KPGJyPg0KUkZDIDUyMjYgaGFzIHRoZSBmb2xsb3dpbmcgZGVzY3JpcHRpb24g Zm9yICZxdW90O1NwZWNpZmljYXRpb24gUmVxdWlyZWQmcXVvdDs6PGJyPg0KPGJyPg0KJm5ic3A7 Jm5ic3A7ICZxdW90O2RvY3VtZW50ZWQgaW4gYSBwZXJtYW5lbnQgYW5kIHJlYWRpbHkgYXZhaWxh YmxlIHB1YmxpYzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZpY2F0aW9uLCBpbiBzdWZm aWNpZW50IGRldGFpbCBzbyB0aGF0IGludGVyb3BlcmFiaWxpdHk8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgYmV0d2VlbiBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMgaXMgcG9zc2libGUmcXVv dDs8YnI+DQo8YnI+DQpJdCdzIGxlc3MgaGFzc2xlIHRvIGFsaWduIHRoZSB0ZXJtcyBpbnN0ZWFk IG9mIHRyeWluZyB0byBmaWd1cmUgb3V0IDxicj4NCndoYXQgJnF1b3Q7cHJlY2lzZSZxdW90OyBv ciAmcXVvdDtvcGVubHkgYXZhaWxhYmxlJnF1b3Q7IG1lYW5zLjxicj4NCjxicj4NClN1Z2dlc3Rl ZCB0ZXh0Ojxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBBIHBlcm1hbmVudCBhbmQgcmVh ZGlseSBhdmFpbGFibGUgcHVibGljbHkgYXZhaWxhYmxlIHNwZWNpZmljYXRpb24sIGluPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1ZmZpY2llbnQgZGV0YWlsIHNvIHRoYXQgaW50ZXJvcGVyYWJp bGl0eSBiZXR3ZWVuIGluZGVwZW5kZW50PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGltcGxlbWVu dGF0aW9ucyBpcyBwb3NzaWJsZSwgb2YgdGhlIGZvcm1hdCBvZiBlYWNoIG1lZGlhIHR5cGUgTVVT VDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBleGlzdCBmb3IgYWxsIHR5cGVzIHJlZ2lzdGVyZWQg aW4gdGhlIHN0YW5kYXJkcyB0cmVlJm5ic3A7IGFuZCBNVVNUIGF0IGE8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgbWluaW11bSBiZSByZWZlcmVuY2VkIGJ5LCBpZiBpdCBpcyBub3QgYWN0dWFsbHkg aW5jbHVkZWQgaW4sIHRoZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBtZWRpYSB0eXBlIHJlZ2lz dHJhdGlvbiBwcm9wb3NhbCBpdHNlbGYuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7ICZxdW90O0Fz IHN1Y2gsIHRlZmVyZW5jZXMgdG8gb3IgaW5jbHVzaW9uIG9mIGZvcm1hdCBzcGVjaWZpY2F0aW9u cyBpbiZxdW90Ozxicj4NCjxicj4NClR5cG86IHJlZmVyZW5jZXMuPGJyPg0KPGJyPg0KSW4gU2Vj dGlvbiA0LjY6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7ICdUaGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgc2VjdGlvbiBvZiBhbGwgcmVnaXN0cmF0aW9ucyBpcyBzdWJqZWN0PGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7IHRvIGNvbnRpbnVpbmcgZXZhbHVhdGlvbiBhbmQgbW9kaWZpY2F0aW9uLCBh bmQgaW4gcGFydGljdWxhciBNQVkgYmU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgZXh0ZW5kZWQg YnkgdXNlIG9mIHRoZSAmcXVvdDtjb21tZW50cyBvbiBtZWRpYSB0eXBlcyZxdW90OyBtZWNoYW5p c20gZGVzY3JpYmVkPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGluIFNlY3Rpb24gNS40IGJlbG93 Lic8YnI+DQo8YnI+DQpJcyB0aGUgaW50ZW50IHRvIGhhdmUgb25nb2luZyBldmFsdWF0aW9uIHdp dGggYW55IHVwZGF0ZWQgaW5mb3JtYXRpb24gPGJyPg0KYWRkZWQgYXMgY29tbWVudHM/PGJyPg0K PGJyPg0KQlRXLCAmcXVvdDthbmQgbW9kaWZpY2F0aW9uJnF1b3Q7IGRvZXMgbm90IHNlZW0gY29y cmVjdCBpbiB0aGUgYWJvdmUuJm5ic3A7IERvZXMgaXQgPGJyPg0KbWVhbiB0aGF0IGEgcmVnaXN0 cmF0aW9uIG1hZGUgdGhyb3VnaCBhIHNwZWNpZmljYXRpb24gd291bGQgcmVxdWlyZSA8YnI+DQph biB1cGRhdGUgb2YgdGhlIHNwZWNpZmljYXRpb24/PGJyPg0KPGJyPg0KSW4gU2VjdGlvbiA0LjEw Ojxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyAmcXVvdDtSRkMgcHVibGljYXRpb24gb2YgdmVuZG9y IGFuZCBwZXJzb25hbCBtZWRpYSB0eXBlIHJlZ2lzdHJhdGlvbnM8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgaXMgYWxsb3dlZCBidXQgbm90IHJlcXVpcmVkLiZxdW90Ozxicj4NCjxicj4NCkkgc3Vn Z2VzdCAmcXVvdDtlbmNvdXJhZ2VkJnF1b3Q7IGluc3RlYWQgb2YgJnF1b3Q7YWxsb3dlZCZxdW90 Oy48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgJnF1b3Q7QWRkaXRpb25hbGx5LCBhbnkgY29weXJp Z2h0IG9uIHRoZSByZWdpc3RyYXRpb24gdGVtcGxhdGUgTVVTVCBhbGxvdzxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyB0aGUgSUFOQSB0byBjb3B5IGl0IGludG8gdGhlIElBTkEgcmVnaXN0cnkuJnF1 b3Q7PGJyPg0KPGJyPg0KVGhlcmUgd2FzIGEgcXVlc3Rpb24gc29tZSB0aW1lIGJhY2sgYWJvdXQg Y29weXJpZ2h0IGFuZCBJQU5BIDxicj4NCnJlZ2lzdHJpZXMuJm5ic3A7IEkgc3VnZ2VzdCBnb2lu ZyB3aXRoIHRoZSBsZXNzZXIgcmVzdHJpY3RpdmUgY29weXJpZ2h0IGFzIDxicj4NCmluYm91bmQg cmlnaHRzLiZuYnNwOyBUaGF0IHdvdWxkIGFsbG93IGRlcml2YXRpdmUgd29yayBhcyBsb25nIGFz IHlvdSA8YnI+DQpkb24ndCBjbGFpbSB0aGF0IGl0IGlzIHdoYXQncyBpbiB0aGUgSUFOQSByZWdp c3RyeS4mbmJzcDsgQW4gYWx0ZXJuYXRpdmUgPGJyPg0KYXJndW1lbnQgd291bGQgYmUgdG8gcmVx dWlyZSBpbmJvdW5kIHJpZ2h0cyB0byB0aGUgSUVURiBhbmQgbGVhdmUgPGJyPg0KSUVURi9JQU5B IGludGVyYWN0aW9uIGFzIGFuIGludGVybmFsIGlzc3VlLjxicj4NCjxicj4NCiZuYnNwOyZuYnNw OyAmcXVvdDtUbyBiZWNvbWUgSW50ZXJuZXQgU3RhbmRhcmRzLCBhIHByb3RvY29sIG9yIGRhdGEg b2JqZWN0IG11c3QgZ288YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgdGhyb3VnaCB0aGUgSUVURiBz dGFuZGFyZHMgcHJvY2Vzcy4mcXVvdDs8YnI+DQo8YnI+DQpTdWdnZXN0ZWQgdGV4dDogJnF1b3Q7 VG8gYmVjb21lIGFuIEludGVybmV0IFN0YW5kYXJkJnF1b3Q7Ljxicj4NCjxicj4NCiZuYnNwOyZu YnNwOyAmcXVvdDtBcyBkaXNjdXNzZWQgYWJvdmUsIHJlZ2lzdHJhdGlvbiBvZiBhIHRvcC1sZXZl bCB0eXBlIHJlcXVpcmVzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IHN0YW5kYXJkcy10cmFjayBw cm9jZXNzaW5nIGluIHRoZSBJRVRGIGFuZCwgaGVuY2UsIFJGQyBwdWJsaWNhdGlvbi4mcXVvdDs8 YnI+DQo8YnI+DQpTdWdnZXN0ZWQgdGV4dDo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgQXMgZGlz Y3Vzc2VkIGFib3ZlLCByZWdpc3RyYXRpb24gb2YgYSB0b3AtbGV2ZWwgdHlwZSByZXF1aXJlczxi cj4NCiZuYnNwOyZuYnNwOyBTdGFuZGFyZHMgQWN0aW9uIGluDQo8L2Rpdj48L2Jsb2NrcXVvdGU+ PC9ib2R5PjwvaHRtbD4NCg== --_000_cc048caf3e1948edb4b15af5092e5953blur_-- From ned.freed@mrochek.com Sun Apr 15 07:10: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 584DB21F87CC for ; Sun, 15 Apr 2012 07:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqDzfn0UTX6I for ; Sun, 15 Apr 2012 07:10:59 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id DF62A21F87AD for ; Sun, 15 Apr 2012 07:10:58 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEC7TBYUSG00A7Z7@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 15 Apr 2012 07:10:54 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Sun, 15 Apr 2012 07:10:48 -0700 (PDT) Message-id: <01OEC7T89V6200ZUIL@mauve.mrochek.com> Date: Sun, 15 Apr 2012 07:06:57 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 15 Apr 2012 04:07:04 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: Larry Masinter Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-media-type-regs-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, 15 Apr 2012 14:10:59 -0000 > should there be a process for moving vendor tree formats to standards tree, > when product formats become open standards (as happened with PDF) ? I think this is a sufficiently rare event that a process isn't needed. In the specific case of PDF, the registered type is application/pdf, which means there's no naming issue, but in general there will be, and that really needs to be handled on a case by case basis. There's also the possibility that standardization may actually result in an incompatible change to the format. Ned From ned.freed@mrochek.com Sun Apr 15 09:18: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 368C521F87E6 for ; Sun, 15 Apr 2012 09:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tun6PDS7kXxO for ; Sun, 15 Apr 2012 09:18:38 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id BFDEB21F86C2 for ; Sun, 15 Apr 2012 09:18:38 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OECCALWSPS0167FH@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 15 Apr 2012 09:18:34 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Sun, 15 Apr 2012 09:18:31 -0700 (PDT) Message-id: <01OECCAK6FDI00ZUIL@mauve.mrochek.com> Date: Sun, 15 Apr 2012 09:12:50 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 15 Apr 2012 07:06:57 -0700 (PDT)" <01OEC7T89V6200ZUIL@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OEC7T89V6200ZUIL@mauve.mrochek.com> To: Ned Freed Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-media-type-regs-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, 15 Apr 2012 16:18:39 -0000 > > should there be a process for moving vendor tree formats to standards tree, > > when product formats become open standards (as happened with PDF) ? > I think this is a sufficiently rare event that a process isn't needed. In the > specific case of PDF, the registered type is application/pdf, which means > there's no naming issue, but in general there will be, and that really needs to > be handled on a case by case basis. There's also the possibility that > standardization may actually result in an incompatible change to the format. ... and after giving this some more thought, I wouldn't touch it with a stick. Consider the change control issue - standards tree requires that change control rest with a standards body. And that doesn't mean "there's a subset of this that described in a standard", but rather "the standards actually describe what's showing up on the wire". Ned From internet-drafts@ietf.org Sun Apr 15 11:04: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 297C221F8835; Sun, 15 Apr 2012 11:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kURLK3XK3mke; Sun, 15 Apr 2012 11:04:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD52C21F8809; Sun, 15 Apr 2012 11:04:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120415180434.17452.90745.idtracker@ietfa.amsl.com> Date: Sun, 15 Apr 2012 11:04:34 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-05.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, 15 Apr 2012 18:04:35 -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 Worki= ng Group of the IETF. Title : Media Type Specifications and Registration Procedures Author(s) : Ned Freed John C. Klensin Tony Hansen Filename : draft-ietf-appsawg-media-type-regs-05.txt Pages : 31 Date : 2012-04-15 This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-05.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-05.txt From dret@berkeley.edu Sun Apr 15 12:32: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 A63D121F870A for ; Sun, 15 Apr 2012 12:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvhXmPze5a1w for ; Sun, 15 Apr 2012 12:32:16 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 05A8921F8707 for ; Sun, 15 Apr 2012 12:32:15 -0700 (PDT) Received: from [212.234.135.180] (helo=dretair.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1SJVBF-0002wg-Bz; Sun, 15 Apr 2012 12:32:15 -0700 Message-ID: <4F8B2231.1090300@berkeley.edu> Date: Sun, 15 Apr 2012 21:32:01 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: REST Discuss , application-layer protocols References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] draft-wilde-profile-link-01 published X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2012 19:32:16 -0000 hello. "The 'profile' Link Relation Type" is now available as version 01 (draft-wilde-profile-link-01) at http://tools.ietf.org/html/draft-wilde-profile-link. the changes are listed at http://tools.ietf.org/html/draft-wilde-profile-link-01#section-7.1, with the main changes being a bigger section with some examples, and the text in general has been revised to make it clear that profiles relate to representations (the ones they are found in) and not to resources. thanks for all the feedback so far, more feedback would be very welcome, and should you happen to be at www2012 this coming week, say hello and let me know what you think about 'profile' links! 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 stephen.farrell@cs.tcd.ie Sun Apr 15 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 6618421F8859 for ; Sun, 15 Apr 2012 13:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD9PJA1qTyws for ; Sun, 15 Apr 2012 13:49:56 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A4EB721F8858 for ; Sun, 15 Apr 2012 13:49:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 17022171479; Sun, 15 Apr 2012 21:49:55 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334522994; bh=Oezf848K2fKVIc 4SnUqExVtBLF1B9odSM7NhbL5sZQQ=; b=WUIS5rL0ZG8toJjkLPPf6zf81FsZEX nNsxPaC8eTLcHs6LM1F3HxsG0E3cq8blCUU88moZkLDjhMPnsY+lttP69z4CkCO0 xhxmNPRbITgkRS8/dUEd8R8kw/o7R21Ra2RNJo6jMFs+jnq5zWl0T4wyW8mnXdWa ttlkwaI50sj9i1gkLoNI3nUJTAdzkYtG70dr6m+iU1AzhQxgIMVUfw2PPMoQRdye XWZatgm0Ryvvr0KeLokFmgcJ7Tvw5eK0NWB7xYwNdUoxYYI8mAxr6zxL/PMkEyv4 fx47+20wPkkX4LP5oVjBci0uHS5DJPBo0SwDs2o20wiseRBP2DChawuA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id k2LWdvYd0xRN; Sun, 15 Apr 2012 21:49:54 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.25.149]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 58B28171478; Sun, 15 Apr 2012 21:49:51 +0100 (IST) Message-ID: <4F8B346E.5040300@cs.tcd.ie> Date: Sun, 15 Apr 2012 21:49:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Eran Hammer References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pete Resnick , Mark Nottingham , Ned Freed , Apps Discuss , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2012 20:49:59 -0000 Hi Eran, On 04/15/2012 07:31 AM, Eran Hammer wrote: > > >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of Stephen Farrell >> Sent: Friday, April 13, 2012 3:36 PM >> To: Mark Nottingham >> Cc: Pete Resnick; Ned Freed; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; >> Apps Discuss >> Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf- >> oauth-v2-bearer >> >> >> >> On 04/13/2012 10:24 PM, Mark Nottingham wrote: >>> Because it's a name space that is managed and owned by the authority of >> the URI, not any standards organisation. >>> >>> I.e. we tell them how the URI is structured, not what to put into it. >>> >>> We made *one* exception for this in .well-known as an escape valve for >> abuse. If we continue allowing this kind of abuse, we'll have little defence >> against things like standardising filename extensions in URLs and reserving an >> "/about/" URI's semantics -- things which are clearly violating the architecture >> of the WWW: >>> http://www.w3.org/TR/webarch/#uri-opacity >> >> (Sticking with the naivety:-) So, what's different there from how the base >> oauth draft registers client_id and shows how that can be used in a GET >> request? [1] > > Big difference. The base draft specifies its own endpoints as part of a complete API package for obtaining authorization. These parameters are scoped only for the endpoints defined and not for any others. There is no possibility of conflict because the specification defines the entire namespace. I guess that might be a big difference, not sure. Where is that aspect (a complete API package) described in the oauth base spec or elsewhere? I also don't recall mention of API packages in the other responses on this thread, so I'm not sure if that's a wide-spread opinion or if there's disagreement about it. > OTOH, the bearer spec is applied to *any* web resources using OAuth authentication where some other namespace definition must exist. Seems like a fair point. But like I said above, I'm unsure if that's just a matter of degree or not. (Maybe the base spec is "a little bit pregnant" in this respect? ;-) S > EH > >> Ta, >> S. >> >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-25#page-24 >> (bottom of page) >> >> >>> >>> Cheers, >>> >>> >>> On 13/04/2012, at 4:20 PM, Stephen Farrell wrote: >>> >>>> >>>> >>>> On 04/13/2012 08:43 AM, Ned Freed wrote: >>>>> I certainly don't object to doing that. In fact I don't object to >>>>> dropping this nasty hack from the document, although perhaps >>>>> documenting it as *not* standardized and explaining why it sucks would >> be even better. >>>> >>>> So I've a possibly naive question: >>>> >>>> Why is it harmful to standardise a parameter name for use in query >>>> strings? >>>> >>>> Note: I'm not asking if access_token is a good or bad name for one of >>>> those, nor how exactly to standardise one well or badly, nor who >>>> should do that, but it seems from the comments here that some folks >>>> are against the idea of standardising anything after the authority is >>>> a bad idea, and I don't get why exactly that might be the case. >>>> >>>> Thanks, >>>> S. >>>> >>> >>> -- >>> Mark Nottingham >>> http://www.mnot.net/ >>> >>> >>> >>> >>> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > From ned.freed@mrochek.com Sun Apr 15 14: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 5632721F886A for ; Sun, 15 Apr 2012 14:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bc+rTSNie9se for ; Sun, 15 Apr 2012 14:09:59 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3C94321F86D3 for ; Sun, 15 Apr 2012 14:09:59 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OECMGTOK1S018TB4@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 15 Apr 2012 14:09:55 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Sun, 15 Apr 2012 14:09:52 -0700 (PDT) Message-id: <01OECMGS7U9800ZUIL@mauve.mrochek.com> Date: Sun, 15 Apr 2012 14:09:09 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 14 Apr 2012 16:33:46 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20120414141741.69972.qmail@joyce.lan> To: "John R. Levine" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-levine-application-gzip-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 21:10:00 -0000 It occurs to me that the new media types registration process allows a registration to list deprecated type name aliases for the type. Seems to me we might want to take advantage of that. Ned From ned.freed@mrochek.com Sun Apr 15 14:50: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 C9BA021F8893 for ; Sun, 15 Apr 2012 14:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q856UbPZ-NQe for ; Sun, 15 Apr 2012 14:50:01 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id DEE7E21F8867 for ; Sun, 15 Apr 2012 14:50:00 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OECNUITVA8005WDB@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 15 Apr 2012 14:49:58 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Sun, 15 Apr 2012 14:49:56 -0700 (PDT) Message-id: <01OECNUHC01O00ZUIL@mauve.mrochek.com> Date: Sun, 15 Apr 2012 14:12:59 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 13 Apr 2012 01:26:14 -0700" <6.2.5.6.2.20120412232341.0ae76d78@elandnews.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <6.2.5.6.2.20120412232341.0ae76d78@elandnews.com> To: SM Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-media-type-regs-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, 15 Apr 2012 21:50:01 -0000 > I'll defer to the authors for the following nits on > draft-ietf-appsawg-media-type-regs-04. > In Section 3.1: > "The first procedure is used for registering registrations from IETF > Consensus documents, or in rare cases when registering a > grandfathered (see Appendix A) and/or otherwise incomplete > registration is in the interest of the Internet community." > Suggested text: > The first procedure is used for registering registrations from IETF > documents, or in rare cases when registering a grandfathered > (see Appendix A) and/or otherwise incomplete registration is in the > interest of the Internet community. > The proposed change aligns the text with the "MUST" in the first > paragraph of Section 3.1. Actually, it does no such thing. A document that has to be approved by the IESG is more or less by definition going to be a consensus document, since a key aspect of the IESG's job is to assess consensus. Your proposed change actually makes things less aligned. > "In the case of registration for the IETF itself, the registration > proposal MUST be published as an IETF Consensus RFC, which can be on > the Standards Track, a BCP, Informational, or Experimental." > The text is redundant (see first paragraph of that > section). Depending on what the objective is, the above text could > be modified to refer to "Standards Action" or "IETF Review". Wrong again, I'm afraid. A document can be approved but not published. That's the key point beind made here. Well, that and that the fact that the document doesn't have to be on the standards track. > In Section 3.4: > 'Subtype names with "x." as the first facet may be used for types > intended exclusively for use in private, local environments. > As I-D.ietf-appsawg-xdash is a work product of this working group, it > does not make sense to register "x." for use in private, local environment. This document isn't registering it. The tree already exists; this document simply isn't removing it. I'm not inclined to remove it because we have no idea if it's in use or not (I suspect it's not, but my suspicions are not evidence), and also aside from this whole "align with xdash even though it doesn't apply to existing mechanisms" argument, nobody has expressed any preference for removing it, let alone explaining how to actually accomplish this removal. This is different from the change to allow registration of x-. x- wasn't a tree, x. is. So simply removing it would change any x. type usage from that of an unregistered type to that of using an invalid tree. > In Section 4.2.8: > "The primary guideline for whether a structured type name suffix > should be registerable is that it be described by a readily-available > description, preferably within a document published by an established > standards organization, and for which there's a reference that can be > used in a References section of an RFC." > I suggest prefacing "References" with "normative". It's probably a bit too strict, but I'll go ahead and do this. I can always back it out if there are objections. > In Section 4.2.9: > "In some cases a single media type may have been widely deployed prior > to registrion under multiple names." > Typo: registration. This must already be fixed because I cannot find it. > "However, a list of deprecated aliases the type is known by MAY > be supplied as additional information in order to assist > application in processing the media type properly." > Suggested text: > to assist the software I prefer application. But it does need to be plural. > In Section 4.4: > "A precise and openly available specification of the format of each > media type MUST exist for all types registered in the standards tree > and MUST at a minimum be referenced by, if it is not actually > included in, the media type registration proposal itself." > RFC 5226 has the following description for "Specification Required": > "documented in a permanent and readily available public > specification, in sufficient detail so that interoperability > between independent implementations is possible" > It's less hassle to align the terms instead of trying to figure out > what "precise" or "openly available" means. > Suggested text: > A permanent and readily available publicly available specification, in > sufficient detail so that interoperability between independent > implementations is possible, of the format of each media type MUST > exist for all types registered in the standards tree and MUST at a > minimum be referenced by, if it is not actually included in, the > media type registration proposal itself. I'm not wild about the RFC 5226 text and actually preferred what we had, but in the interests of alignment I've changed things to use a variant of it. > "As such, teferences to or inclusion of format specifications in" > Typo: references. Can't find this one either. > In Section 4.6: > 'The security considerations section of all registrations is subject > to continuing evaluation and modification, and in particular MAY be > extended by use of the "comments on media types" mechanism described > in Section 5.4 below.' > Is the intent to have ongoing evaluation with any updated information > added as comments? > BTW, "and modification" does not seem correct in the above. Does it > mean that a registration made through a specification would require > an update of the specification? > In Section 4.10: > "RFC publication of vendor and personal media type registrations > is allowed but not required." > I suggest "encouraged" instead of "allowed". That was intentionally changed in the other direction. We don't really want to encourage a flood of RFCs containing the vendor format du jour. > "Additionally, any copyright on the registration template MUST allow > the IANA to copy it into the IANA registry." > There was a question some time back about copyright and IANA > registries. I suggest going with the lesser restrictive copyright as > inbound rights. That would allow derivative work as long as you > don't claim that it is what's in the IANA registry. An alternative > argument would be to require inbound rights to the IETF and leave > IETF/IANA interaction as an internal issue. You're proposing a specific mechanism, one of many possible mechanisms. It is completely inappropriate to restrict this to one mechanism or even suggest a mechanism - the key point is that IANA has the right to copy, not how it is done. > "To become Internet Standards, a protocol or data object must go > through the IETF standards process." > Suggested text: "To become an Internet Standard". Changed. > "As discussed above, registration of a top-level type requires > standards-track processing in the IETF and, hence, RFC publication." > Suggested text: > As discussed above, registration of a top-level type requires > Standards Action in the IETF and, hence, the publication of a RFC on > the Standards Track. That's better. Changed. > In Section 5.2: > "A web form for registration requests is also available:" > This is an opportunity to fix the URL if someone thinks that it is > worth the bother. No, actually, it's not. We'll be consulting with IANA before final publication on what changes need to be made to the web form. That will be the time to change the URL, assuming such a change is needed. Thanks for the review; sorry I didn't get to it before posting -05. Ned From sm@resistor.net Sun Apr 15 16:21: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 E0B2821F88B7 for ; Sun, 15 Apr 2012 16:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEAAnPtVQYyV for ; Sun, 15 Apr 2012 16:20:59 -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 B106121F889E for ; Sun, 15 Apr 2012 16:20:59 -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 q3FNKl9S022022; Sun, 15 Apr 2012 16:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334532055; i=@resistor.net; bh=EYv6nb6Z+A7U2KYopGsZvw3JMLHyZmEzefztj4uge9A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AT5/9UkDOBmOf1WIMpLy/dJwiF39XJ5lHl1a/dNuxR7Mi4WcFCPLppe/U+KhWix/I a/8vr4gE+3d0KdIIhP8ufI8Gj/+sNZZNJynoUXysGvYoFDZ1WVGuWzhV1KIN2qIK1x jC9L0qkeTuUruT2ByPFWhYSBZKK+Abq5xKsWPsXQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334532055; i=@resistor.net; bh=EYv6nb6Z+A7U2KYopGsZvw3JMLHyZmEzefztj4uge9A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Oy2a2rNRkBC4NLsDYjcUB4N6KfcFjXS46KL0tUE6RVWMh71aWiDhMCaCoNhjr++Rg o8ccCccZ6zld7kWzM/x/hNT6uwoFamv76EyjE9Ks/LMWQ07haY01VYwQNlDB2qvdH2 lmJ8ElY8aW8kPRBzHrrfOp3SXjbxAt0ihIKvwLxo= Message-Id: <6.2.5.6.2.20120415153915.092fbb50@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 15 Apr 2012 15:59:48 -0700 To: Ned Freed From: SM In-Reply-To: <01OECNUHC01O00ZUIL@mauve.mrochek.com> References: <6.2.5.6.2.20120412232341.0ae76d78@elandnews.com> <01OECNUHC01O00ZUIL@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-media-type-regs-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, 15 Apr 2012 23:21:02 -0000 Hi Ned, Thanks for the explanation you provided. At 14:12 15-04-2012, Ned Freed wrote: >Actually, it does no such thing. A document that has to be approved >by the IESG >is more or less by definition going to be a consensus document, since a key >aspect of the IESG's job is to assess consensus. Your proposed change actually >makes things less aligned. Ok. >Wrong again, I'm afraid. A document can be approved but not published. That's Ok. :-) >This document isn't registering it. The tree already exists; this document >simply isn't removing it. I'm not inclined to remove it because we >have no idea >if it's in use or not (I suspect it's not, but my suspicions are not >evidence), Please leave it. >It's probably a bit too strict, but I'll go ahead and do this. I can always >back it out if there are objections. I'll leave it to others to provide input on this (Section 4.2.8). >This must already be fixed because I cannot find it. From the diff of -05, I see that it has been fixed. >I prefer application. But it does need to be plural. Ok. >Can't find this one either. It's fixed in -05. >That was intentionally changed in the other direction. We don't really want to >encourage a flood of RFCs containing the vendor format du jour. I misinterpreted that text. >You're proposing a specific mechanism, one of many possible mechanisms. It is >completely inappropriate to restrict this to one mechanism or even suggest a >mechanism - the key point is that IANA has the right to copy, not how it is >done. Ok. >No, actually, it's not. We'll be consulting with IANA before final publication >on what changes need to be made to the web form. That will be the time to >change the URL, assuming such a change is needed. Ok. >Thanks for the review; sorry I didn't get to it before posting -05. It's alright. BTW, there isn't a sentence in the Abstract or Introduction in -05 about this document obsoleting RFC 4288. That may have to be added. Regards, -sm From ned.freed@mrochek.com Sun Apr 15 16:26: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 1A17421F88CE for ; Sun, 15 Apr 2012 16:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU0CY9pv3Mfq for ; Sun, 15 Apr 2012 16:26:44 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1B29621F88CD for ; Sun, 15 Apr 2012 16:26:44 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OECR8DMJCG005U1R@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 15 Apr 2012 16:26:39 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Sun, 15 Apr 2012 16:26:37 -0700 (PDT) Message-id: <01OECR8BYLKM00ZUIL@mauve.mrochek.com> Date: Sun, 15 Apr 2012 16:24:14 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 15 Apr 2012 15:08:10 +0900" <4F8A65CA.7080102@it.aoyama.ac.jp> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4F88546D.5020007@gmx.de> <4F885889.5020401@gmx.de> <4F886487.3050806@gmx.de> <4F886D9B.9030203@gmx.de> <4F886F67.5090005@gmx.de> <20120413200214.GE696@jay.w3.org> <4F88899D.3090405@gmx.de> <20120414121040.GF696@jay.w3.org> <4F896D3D.9010805@gmx.de> <01OEATK3NNY800ZUIL@mauve.mrochek.com> <4F8A65CA.7080102@it.aoyama.ac.jp> To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Cc: Julian Reschke , Ned Freed , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 23:26:45 -0000 > On 2012/04/14 22:55, Ned Freed wrote: > > My understanding is that pack200 is a type-specific compression format. > > That > > is, it only works if the input is a jar file. In this sense there is > > overlap > > with EXI - I believe EXI relies on the input having XML syntax (although it > > doesn't necessarily have to be well formed), > If it's not well-formed, it's not XML. Did you mean "not valid"? Yes, it has to be well formed, but validity isn't required in non-strict mode. Ned From ned.freed@mrochek.com Sun Apr 15 19:07: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 16D6721F87FF for ; Sun, 15 Apr 2012 19:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpJCpv8LF3ZR for ; Sun, 15 Apr 2012 19:07:18 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id F229A21F8808 for ; Sun, 15 Apr 2012 19:07:17 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OECWUGIZFK00Y7QH@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 15 Apr 2012 19:07:14 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Sun, 15 Apr 2012 19:07:11 -0700 (PDT) Message-id: <01OECWUEC9CY00ZUIL@mauve.mrochek.com> Date: Sun, 15 Apr 2012 19:05:13 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 15 Apr 2012 15:59:48 -0700" <6.2.5.6.2.20120415153915.092fbb50@resistor.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <6.2.5.6.2.20120412232341.0ae76d78@elandnews.com> <01OECNUHC01O00ZUIL@mauve.mrochek.com> <6.2.5.6.2.20120415153915.092fbb50@resistor.net> To: SM Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-media-type-regs-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, 16 Apr 2012 02:07:19 -0000 > BTW, there isn't a sentence in the Abstract or > Introduction in -05 about this document obsoleting RFC 4288. That > may have to be added. Another sort point with both John Klensin and myself. This "requirement" (it is actually nothing of the sort) is not just pointless, it's outright inappropriate. We managed to publish the EAI specifications without such language and we're going to push hard to do that here as well. Ned From laurentwalter.goix@telecomitalia.it Sun Apr 15 20:46: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 91CAB21F86FA for ; Sun, 15 Apr 2012 20:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFL4R27du5GF for ; Sun, 15 Apr 2012 20:46:06 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 59ED121F867B for ; Sun, 15 Apr 2012 20:46:06 -0700 (PDT) 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.245.1; Mon, 16 Apr 2012 05:45:57 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Mon, 16 Apr 2012 05:45:57 +0200 From: Goix Laurent Walter To: Erik Wilde , REST Discuss , application-layer protocols Date: Mon, 16 Apr 2012 05:45:51 +0200 Thread-Topic: [apps-discuss] draft-wilde-profile-link-01 published Thread-Index: Ac0bPnusig2LFlBURwu/sUCYX25J3gAQywaQ Message-ID: References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <4F8B2231.1090300@berkeley.edu> In-Reply-To: <4F8B2231.1090300@berkeley.edu> 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 Subject: [apps-discuss] R: draft-wilde-profile-link-01 published X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 03:46:07 -0000 Hello erik, Thanks for the update. Such types of link have also been widely used for years together with the w= ebfinger specification (usually under the http://webfinger.net/rel/profile-= page rel type for html profile pointers) so I would suppose it will also re= late to the wf/swd discussion and that ultimately this draft becomes compat= ible with the discovery solution ultimately specified. It may be worth addi= ng it as an example. I would also suggest to emphasize the usage on the "type" attribute togethe= r with this link rel to better characterize the type of information a clien= t should expect. Indeed I would expect in some cases more than one of such = "profile" link rel to be published within the same document, and the type m= ay be useful for this. E.g. so far in wf the http://webfinger.net/rel/profi= le-page and http://microformats.org/profile/hcard (and to some extent the h= ttp://portablecontacts.net/spec/1.0#me) rel types are widely used to discri= minate the expect type of "profile" format/info accessible. It would be val= uable to maintain such flexibility. walter -----Messaggio originale----- Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Pe= r conto di Erik Wilde Inviato: luned=EC 16 aprile 2012 2.32 A: REST Discuss; application-layer protocols Oggetto: [apps-discuss] draft-wilde-profile-link-01 published hello. "The 'profile' Link Relation Type" is now available as version 01 (draft-wilde-profile-link-01) at http://tools.ietf.org/html/draft-wilde-profile-link. the changes are listed at http://tools.ietf.org/html/draft-wilde-profile-link-01#section-7.1, with the main changes being a bigger section with some examples, and the text in general has been revised to make it clear that profiles relate to representations (the ones they are found in) and not to resources. thanks for all the feedback so far, more feedback would be very welcome, and should you happen to be at www2012 this coming week, say hello and let me know what you think about 'profile' links! 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 | _______________________________________________ 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 dret@berkeley.edu Sun Apr 15 22:46: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 F05D221F8739 for ; Sun, 15 Apr 2012 22:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZ-ds0nDf6e1 for ; Sun, 15 Apr 2012 22:46:24 -0700 (PDT) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB2221F8734 for ; Sun, 15 Apr 2012 22:46:24 -0700 (PDT) Received: from [212.234.135.180] (helo=dretair.local) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1SJelb-0002X4-3x; Sun, 15 Apr 2012 22:46:24 -0700 Message-ID: <4F8BB227.2050904@berkeley.edu> Date: Mon, 16 Apr 2012 07:46:15 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: REST Discuss , application-layer protocols References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <4F8B2231.1090300@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] draft-wilde-profile-link-01 published X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 05:46:26 -0000 hello walter. > Thanks for the update. > Such types of link have also been widely used for years together with the webfinger specification (usually under the http://webfinger.net/rel/profile-page rel type for html profile pointers) so I would suppose it will also relate to the wf/swd discussion and that ultimately this draft becomes compatible with the discovery solution ultimately specified. It may be worth adding it as an example. thanks for the pointer to web finger. i am sure there are quite a number of other formats out there using html profiles, maybe it would be interesting to create a small list of "well-known" profiles. > I would also suggest to emphasize the usage on the "type" attribute together with this link rel to better characterize the type of information a client should expect. Indeed I would expect in some cases more than one of such "profile" link rel to be published within the same document, and the type may be useful for this. E.g. so far in wf the http://webfinger.net/rel/profile-page and http://microformats.org/profile/hcard (and to some extent the http://portablecontacts.net/spec/1.0#me) rel types are widely used to discriminate the expect type of "profile" format/info accessible. It would be valuable to maintain such flexibility. while i think that the "type" idea is interesting, i am confused that you suggest http://microformats.org/profile/hcard as such a type. afaict, hCard is a specific profile and does not define a format for describing profiles. i would expect types to define a framework that could be used to define specific profiles, but maybe we have a different idea of what a "type" attribute could do? could you explain why you consider http://microformats.org/profile/hcard to be a type instead of a specific profile? thanks and 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 laurentwalter.goix@telecomitalia.it Sun Apr 15 23: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 7839721F8723 for ; Sun, 15 Apr 2012 23:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.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_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqL0uCf8-U2G for ; Sun, 15 Apr 2012 23:07:59 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 28CA521F86EB for ; Sun, 15 Apr 2012 23:07:58 -0700 (PDT) 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.245.1; Mon, 16 Apr 2012 08:07:56 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Mon, 16 Apr 2012 08:07:56 +0200 From: Goix Laurent Walter To: Erik Wilde , REST Discuss , application-layer protocols Date: Mon, 16 Apr 2012 08:07:45 +0200 Thread-Topic: draft-wilde-profile-link-01 published Thread-Index: Ac0blE8+KRv6ql35RQOinsHhoqAxbwAATyNQ Message-ID: References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <4F8B2231.1090300@berkeley.edu> <4F8BB227.2050904@berkeley.edu> In-Reply-To: <4F8BB227.2050904@berkeley.edu> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: e5k= DojP Dw2W GhyS G0q5 H5jT Jetq KRMD LzwS PQLr QfE2 QyXn Shsc TJvE WMpo YEZp; 3; YQBwAHAAcwAtAGQAaQBzAGMAdQBzAHMAQABpAGUAdABmAC4AbwByAGcAOwBkAHIAZQB0AEAAYgBlAHIAawBlAGwAZQB5AC4AZQBkAHUAOwByAGUAcwB0AC0AZABpAHMAYwB1AHMAcwBAAHkAYQBoAG8AbwBnAHIAbwB1AHAAcwAuAGMAbwBtAA==; Sosha1_v1; 7; {545E8414-0112-42A0-969F-B9364148DEC5}; bABhAHUAcgBlAG4AdAB3AGEAbAB0AGUAcgAuAGcAbwBpAHgAQAB0AGUAbABlAGMAbwBtAGkAdABhAGwAaQBhAC4AaQB0AA==; Mon, 16 Apr 2012 06:07:45 GMT; UgA6ACAAZAByAGEAZgB0AC0AdwBpAGwAZABlAC0AcAByAG8AZgBpAGwAZQAtAGwAaQBuAGsALQAwADEAIABwAHUAYgBsAGkAcwBoAGUAZAA= x-cr-puzzleid: {545E8414-0112-42A0-969F-B9364148DEC5} acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [apps-discuss] R: draft-wilde-profile-link-01 published X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 06:08:00 -0000 SGVsbG8gZXJpaywNCltzbmlwXQ0KPg0KPiA+IFRoYW5rcyBmb3IgdGhlIHVwZGF0ZS4NCj4gPiBT dWNoIHR5cGVzIG9mIGxpbmsgaGF2ZSBhbHNvIGJlZW4gd2lkZWx5IHVzZWQgZm9yIHllYXJzIHRv Z2V0aGVyIHdpdGgNCj4gdGhlIHdlYmZpbmdlciBzcGVjaWZpY2F0aW9uICh1c3VhbGx5IHVuZGVy IHRoZQ0KPiBodHRwOi8vd2ViZmluZ2VyLm5ldC9yZWwvcHJvZmlsZS1wYWdlIHJlbCB0eXBlIGZv ciBodG1sIHByb2ZpbGUNCj4gcG9pbnRlcnMpIHNvIEkgd291bGQgc3VwcG9zZSBpdCB3aWxsIGFs c28gcmVsYXRlIHRvIHRoZSB3Zi9zd2QNCj4gZGlzY3Vzc2lvbiBhbmQgdGhhdCB1bHRpbWF0ZWx5 IHRoaXMgZHJhZnQgYmVjb21lcyBjb21wYXRpYmxlIHdpdGggdGhlDQo+IGRpc2NvdmVyeSBzb2x1 dGlvbiB1bHRpbWF0ZWx5IHNwZWNpZmllZC4gSXQgbWF5IGJlIHdvcnRoIGFkZGluZyBpdCBhcw0K PiBhbiBleGFtcGxlLg0KPg0KPiB0aGFua3MgZm9yIHRoZSBwb2ludGVyIHRvIHdlYiBmaW5nZXIu IGkgYW0gc3VyZSB0aGVyZSBhcmUgcXVpdGUgYQ0KPiBudW1iZXINCj4gb2Ygb3RoZXIgZm9ybWF0 cyBvdXQgdGhlcmUgdXNpbmcgaHRtbCBwcm9maWxlcywgbWF5YmUgaXQgd291bGQgYmUNCj4gaW50 ZXJlc3RpbmcgdG8gY3JlYXRlIGEgc21hbGwgbGlzdCBvZiAid2VsbC1rbm93biIgcHJvZmlsZXMu DQpbd2FsdGVyXSBzb21lIHdvcmsgaW4gdGhhdCBkaXJlY3Rpb24gaGFzIGJlZW4gYWxyZWFkeSBy ZWNvcmRlZCBoZXJlIFsxXSB0aGF0IHlvdSBtYXkgd2FudCB0byBjaGVjaw0KDQo+DQo+ID4gSSB3 b3VsZCBhbHNvIHN1Z2dlc3QgdG8gZW1waGFzaXplIHRoZSB1c2FnZSBvbiB0aGUgInR5cGUiIGF0 dHJpYnV0ZQ0KPiB0b2dldGhlciB3aXRoIHRoaXMgbGluayByZWwgdG8gYmV0dGVyIGNoYXJhY3Rl cml6ZSB0aGUgdHlwZSBvZg0KPiBpbmZvcm1hdGlvbiBhIGNsaWVudCBzaG91bGQgZXhwZWN0LiBJ bmRlZWQgSSB3b3VsZCBleHBlY3QgaW4gc29tZSBjYXNlcw0KPiBtb3JlIHRoYW4gb25lIG9mIHN1 Y2ggInByb2ZpbGUiIGxpbmsgcmVsIHRvIGJlIHB1Ymxpc2hlZCB3aXRoaW4gdGhlDQo+IHNhbWUg ZG9jdW1lbnQsIGFuZCB0aGUgdHlwZSBtYXkgYmUgdXNlZnVsIGZvciB0aGlzLiBFLmcuIHNvIGZh ciBpbiB3Zg0KPiB0aGUgaHR0cDovL3dlYmZpbmdlci5uZXQvcmVsL3Byb2ZpbGUtcGFnZSBhbmQN Cj4gaHR0cDovL21pY3JvZm9ybWF0cy5vcmcvcHJvZmlsZS9oY2FyZCAoYW5kIHRvIHNvbWUgZXh0 ZW50IHRoZQ0KPiBodHRwOi8vcG9ydGFibGVjb250YWN0cy5uZXQvc3BlYy8xLjAjbWUpIHJlbCB0 eXBlcyBhcmUgd2lkZWx5IHVzZWQgdG8NCj4gZGlzY3JpbWluYXRlIHRoZSBleHBlY3QgdHlwZSBv ZiAicHJvZmlsZSIgZm9ybWF0L2luZm8gYWNjZXNzaWJsZS4gSXQNCj4gd291bGQgYmUgdmFsdWFi bGUgdG8gbWFpbnRhaW4gc3VjaCBmbGV4aWJpbGl0eS4NCj4NCj4gd2hpbGUgaSB0aGluayB0aGF0 IHRoZSAidHlwZSIgaWRlYSBpcyBpbnRlcmVzdGluZywgaSBhbSBjb25mdXNlZCB0aGF0DQo+IHlv dSBzdWdnZXN0IGh0dHA6Ly9taWNyb2Zvcm1hdHMub3JnL3Byb2ZpbGUvaGNhcmQgYXMgc3VjaCBh IHR5cGUuDQo+IGFmYWljdCwgaENhcmQgaXMgYSBzcGVjaWZpYyBwcm9maWxlIGFuZCBkb2VzIG5v dCBkZWZpbmUgYSBmb3JtYXQgZm9yDQo+IGRlc2NyaWJpbmcgcHJvZmlsZXMuIGkgd291bGQgZXhw ZWN0IHR5cGVzIHRvIGRlZmluZSBhIGZyYW1ld29yayB0aGF0DQo+IGNvdWxkIGJlIHVzZWQgdG8g ZGVmaW5lIHNwZWNpZmljIHByb2ZpbGVzLCBidXQgbWF5YmUgd2UgaGF2ZSBhDQo+IGRpZmZlcmVu dA0KPiBpZGVhIG9mIHdoYXQgYSAidHlwZSIgYXR0cmlidXRlIGNvdWxkIGRvPyBjb3VsZCB5b3Ug ZXhwbGFpbiB3aHkgeW91DQo+IGNvbnNpZGVyIGh0dHA6Ly9taWNyb2Zvcm1hdHMub3JnL3Byb2Zp bGUvaGNhcmQgdG8gYmUgYSB0eXBlIGluc3RlYWQgb2YNCj4gYQ0KPiBzcGVjaWZpYyBwcm9maWxl Pw0KW3dhbHRlcl0gbWF5YmUgaSB3YXNuJ3QgY2xlYXIgZW5vdWdoIEkgYXBvbG9naXplLiBJIHdh cyBpbmRlZWQgcmVmZXJyaW5nIHRvIHRoZSAidHlwZSIgYXR0cmlidXRlL3BhcmFtZXRlciBvZiB0 aGUgImxpbmsiIGVsZW1lbnQvaGVhZGVyLCB3aGljaCBpcyBhbHJlYWR5IGRlZmluZWQgYm90aCBp biBSRkM1OTg4IGFuZCBpbiBYUkQgZm9yIHJlZmVyZW5jaW5nIHRoZSBtZWRpYS10eXBlIGFzc29j aWF0ZWQgd2l0aCB0aGF0IGxpbmsuIEluIHRoYXQgc2Vuc2UgYW4gaGNhcmQgbGluayByZWwgd291 bGQgdHlwaWNhbGx5IGJlICJ0ZXh0L2h0bWwiIHdoaWxzdCBhIHBvY28jbWUgcmVwcmVzZW50YXRp b24gb2YgdGhlICJwcm9maWxlIiBsaW5rIGNvdWxkIGJlICJhcHBsaWNhdGlvbi9qc29uIi4NCkhv d2V2ZXIgSSBkbyB1bmRlcnN0YW5kIHRoYXQgdGhpcyBtYXkgbm90IGJlIGVub3VnaCBmb3IgY29y cmVjdGx5IGNoYXJhY3Rlcml6aW5nIHRoZSBmb3JtYXQgb2YgdGhlIHNwZWNpZmljIHByb2ZpbGUg aW5mb3JtYXRpb246IGhvdyB3b3VsZCBJIGluZGljYXRlIGluIGZhY3QgdGhhdCB0aGlzICJwcm9m aWxlIiBsaW5rL3dlYiBwYWdlIGlzIGhjYXJkLWVuYWJsZWQgb3Igbm90IGEgcHJpb3JpPyBTYW1l IGZvciBqc29uOiBwb2NvIGlzIGEgcG9wdWxhciBqc29uIGZvcm1hdCBmb3IgcmVwcmVzZW50aW5n IHByb2ZpbGUgaW5mbyBidXQgbWF5IG5vdCBiZSB0aGUgb25seSBvbmUuDQpNeSBwb2ludCBpcyBJ IG1heSBoYXZlIHRoZSBmb2xsb3dpbmcgeHJkIGF0IHRoaXMgc3RhZ2Ugd2l0aCB0aGUgcHJvZmls ZSByZWwgbGlua3M6DQo8TGluayByZWw9InByb2ZpbGUiIHR5cGU9InRleHQvaHRtbCIgaHJlZj0i aHR0cDovL2V4YW1wbGUuY29tL3Byb2ZpbGVzL2pvZSIgLz4NCjxMaW5rIHJlbD0icHJvZmlsZSIg dHlwZT0idGV4dC9odG1sIiBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vcHJvZmlsZXMvam9lL2hj YXJkIiAvPg0KPExpbmsgcmVsPSJwcm9maWxlIiB0eXBlPSJhcHBsaWNhdGlvbi9qc29uIiBocmVm PSJodHRwOi8vZXhhbXBsZS5jb20vcHJvZmlsZXMvam9lL3BvY28iIC8+DQouLi53aXRob3V0IGFu eSBjbGVhciB2aWV3IG9uIHdoaWNoICJwcm9maWxlIiBwcm92aWRlcyB3aGljaCBmb3JtYXQuDQpJ IGhvcGUgSSBoYXZlIGNsYXJpZmllZCBteSBwb2ludCBoZXJlIGFuZCB3ZWxjb21lIHlvdXIgZmVl ZGJhY2sgb24gdGhpcy4NCg0Kd2FsdGVyDQoNClsxXSBodHRwOi8vd3d3LnBhY2tldGl6ZXIuY29t L3dlYmZpbmdlci9saW5rX3JlbGF0aW9ucy5odG1sDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1 b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUg aW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBk ZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmln b3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3Vt ZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVk aWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBk aXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlz IGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRl bmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBw cmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFp bCwgVGhhbmtzLg0KDQo= From dret@berkeley.edu Mon Apr 16 00:10: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 351FE21F872B for ; Mon, 16 Apr 2012 00:10:56 -0700 (PDT) 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_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si03JNoWR6QM for ; Mon, 16 Apr 2012 00:10:55 -0700 (PDT) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5800721F872A for ; Mon, 16 Apr 2012 00:10:55 -0700 (PDT) Received: from hote-81-36.cccl.www2012.org ([81.194.81.36]) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1SJg5L-0001LF-88; Mon, 16 Apr 2012 00:10:52 -0700 Message-ID: <4F8BC5F8.8080800@berkeley.edu> Date: Mon, 16 Apr 2012 09:10:48 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Goix Laurent Walter References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <4F8B2231.1090300@berkeley.edu> <4F8BB227.2050904@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: application-layer protocols , REST Discuss Subject: Re: [apps-discuss] draft-wilde-profile-link-01 published X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 07:10:56 -0000 hello walter. On 2012-04-16 08:07 , Goix Laurent Walter wrote: >> thanks for the pointer to web finger. i am sure there are quite a >> number >> of other formats out there using html profiles, maybe it would be >> interesting to create a small list of "well-known" profiles. > [walter] some work in that direction has been already recorded here [1] that you may want to check these are link relation types and not profile identifiers, right? i am a bit concerned to see expected media types encoded in link relations, for example i'd prefer to see a "contact" link type and then getting a vCard or an xCard or HTML-embedded hCard is up to conneg and thus a runtime issue. doing it that way frees you from having to mint new link relation types when you want to support new media types (what about FoaF contact info, for example?). > [walter] maybe i wasn't clear enough I apologize. I was indeed referring to the "type" attribute/parameter of the "link" element/header, which is already defined both in RFC5988 and in XRD for referencing the media-type associated with that link. In that sense an hcard link rel would typically be "text/html" whilst a poco#me representation of the "profile" link could be "application/json". and that doesn't really help at all. for it to be helpful, the profile description language would need to have a media type, and then you could identify it by that. and generally speaking, a 'profile' link should not need to be dereferenced to be useful, it's an identifier. that also means that designing an environment where runtime lookup of the profile description is necessary would be a violation of the spec, because clients would not be able to "understand" that the meaning of a profile URI changes over time. this almost automatically means that any updates in the profile need to done by minting a new profile URI, and if it is done backwards compatible, then representations conforming to the new profile should list both profile versions: > However I do understand that this may not be enough for correctly characterizing the format of the specific profile information: how would I indicate in fact that this "profile" link/web page is hcard-enabled or not a priori? Same for json: poco is a popular json format for representing profile info but may not be the only one. if there is a format for describing profile information, then it should have a media type and then web clients can use that media type. just referring to it as JSON is not very helpful. but even if there was such a media type, it would not change the fact that the way how 'profile' is drafted right now, runtime access to profile descriptions is not part of the design; clients compare supported profile URIs to the profiles they find in a representation, and then decide what to do. > My point is I may have the following xrd at this stage with the profile rel links: > > > > ...without any clear view on which "profile" provides which format. > I hope I have clarified my point here and welcome your feedback on this. now i am getting the impression that you're having some misconceptions about profile. profile links are not intended to link to particular resource that contains data of interest to the client. in your example, the page would be about joe, and joe might decide to embed his information using hcard, and then the page would say and clients could extract joe's hcard info from the page without ever accessing http://microformats.org/profile/hcard; they would simply see that URI and then, if they supported hCard, understand that the page contain embedded hCard information. i hope that clarifies things a bit. 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 yoshiro.yoneya@jprs.co.jp Mon Apr 16 02:50: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 4876721F8633; Mon, 16 Apr 2012 02:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNkt0OA0LkS6; Mon, 16 Apr 2012 02:50:26 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8D82321F8650; Mon, 16 Apr 2012 02:50:26 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q3G9oOes029034; Mon, 16 Apr 2012 18:50:24 +0900 X-AuditID: ac120820-b7f4d6d000000ccc-93-4f8beb5f625a Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 8B.7E.03276.F5BEB8F4; Mon, 16 Apr 2012 18:50:24 +0900 (JST) Date: Mon, 16 Apr 2012 18:50:10 +0900 From: Yoshiro YONEYA To: apps-discuss@ietf.org, draft-ietf-emu-chbind.all@tools.ietf.org Message-Id: <20120416185010.ee76b398.yoshiro.yoneya@jprs.co.jp> X-Mailer: Sylpheed 3.1.3 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsWyRoiFTzfhdbe/wd4HTBarX65gs/i3o53Z YsaficwWXW2bWRxYPJYs+cnk8ff+O1aPL5c/swUwR3HZpKTmZJalFunbJXBlbLrfzlywX6Di 57KLjA2M53i6GDk5JARMJCZ1LmKHsMUkLtxbz9bFyMUhJHCcUeLvp2msXYwcHCwCqhK/f9iD 1LAJGEj8WvabCcQWEXCWaJ7bzwJiMwsISjS9fwVmCwsYSzw9vpEVxOYVsJe42X2VGWK+hcTy vp9sICN5ger/7hCGaNWSePjrFtQYeYntb+cwT2DknYVQNQtJ1SwkVQsYmVcxyuSnpekWp+al FOemGxjqlVTm62UVFBXrJYPoTYzgoONQ2ME445TBIUYBDkYlHl6ejG5/IdbEsuLK3EOMkhxM SqK8HC+AQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4Y2SBcrwpiZVVqUX5MClpDhYlcd7jZ3f4 CQmkJ5akZqemFqQWwWRlODiUJHhnvwJqFCxKTU+tSMvMKUFIM3FwggznARrO/xpkeHFBYm5x ZjpE/hSjpJQ47yGQZgGQREZpHlzvK0ZxoBeEeaeCZHmACQSu6xXQQCaggfElXSADSxIRUlIN jOsvS3z227WbR/ual8aN5uDkCVzfjXLlJd92ZTjttX/XPrP7X/9XU23rOb3J65gv7rymej7c PkRCgPX2XF0+7pvtc3ewXHdgOb1mE6vRmmW8QSlOj/3u8Db82OWVVqsiZ3+Zte+WEldPR2rI XePd0yOZt8o+YK4+WsDb3G2RaPIwKUL2e7+UEktxRqKhFnNRcSIARAAjmt0CAAA= Cc: iesg@ietf.org Subject: [apps-discuss] AppsDir review of draft-ietf-emu-chbind-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 09:50:27 -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-emu-chbind-14.txt Title: Channel Binding Support for EAP Methods Reviewer: Yoshiro Yoneya Review Date: 16 April 2012 IETF Last Call Date: 29 March 2012 IESG Telechat Date: 26 April 2012 Summary: This draft is almost ready for publication as an Standards Track RFC but has a few issues that should be fixed before publication. Major Issues: Section 5.1 [Page 13] Arrival order of i2 and i1 to the EAP server is not specified. What happens if i1 arrives before i2 arrival? What happens if i2 arrives but i1 never? Latter case could be potential DoS attack to the EAP server if the authenticator is malicious. Minor Issues: Section 5.3 [Page 17] In description of NSID: The word "RADIUS" is the first appearance in this document and it should have reference to RADIUS standard. Section 5.3.3 [Page 18] The word "AVP" is the first appearance in this document and its full wording should be dentoted here. Section 7 [Page 20] The word "TLV" is the first appearance in this document and its full wording should be denoted here. Nits: Section 3 [Page 6] First bullet: virtual Lads (VLANs) => virtual LANs (VLANs) Section 3 [Page 7] Second bullet: The EAP GSS-API mechanism [I-D.ietf-abfab-gss-eap] mechanism => The EAP GSS-API mechanism [I-D.ietf-abfab-gss-eap] Section 7.2 [Page 21] "Type" in packet format and "The code" in last paragraph seems to be the same thing, but the name is differ. Should use the same word. Section 12 [Page 27] Sam hartman's => Sam Hartman's -- Yoshiro YONEYA From alexey.melnikov@isode.com Mon Apr 16 03:53: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 9A34D21F8766; Mon, 16 Apr 2012 03:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.786 X-Spam-Level: X-Spam-Status: No, score=-101.786 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS8MH2kDf0Rw; Mon, 16 Apr 2012 03:53:00 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id DAC1A21F875E; Mon, 16 Apr 2012 03:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334573578; d=isode.com; s=selector; i=@isode.com; bh=KErkjEZPiZFaLHDCqpD7X/6zA1UTgHL3XBcHCPOEn9Q=; 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=xFBLU6RFzi4HCACyrW07V7G4u01YWL4yqxhaaDSsnvuYYxnGClFqf+A5zOHi62K1G7RlMb VCmHswTt13IWwov+cpIR0x+o0tCk7y/EKCgBceogl4oMr4mzpn932aBYaZnyboNmSVHTMj mwgMhIG+4vjK3Bg8z/0SpTi0b02qsFc=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Apr 2012 11:52:58 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F89AE3A.5050503@isode.com> Date: Sat, 14 Apr 2012 18:04:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: S Moonesamy References: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: appsdir@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Responding to Applications Area Directorate reviews X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 10:53:00 -0000 On 11/04/2012 10:25, S Moonesamy wrote: > Hello, > > I'll comment on the template used for Applications Area Directorate > (AppsDir) reviews as it may help authors to respond to the reviews. > > "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." > > In plain English, this means that the comments in the review does not > bear more weight than a comment submitted by an individual during a > Last Call. > > The Applications Area Directors may or may not agree with the comments > of the AppsDir reviewer. The Applications Area Directorate does not > have any veto power on a draft. It is suggested that the author(s) > asks the document shepherd (RFC 4858) or the Area Director who > sponsored the draft for guidance about IETF process, changes that > should be made, whether to post a new revision, etc. > > A review generally list issues as major or minor. I'll use a review > performed by Ted Hardie as an example ( > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04847.html ). > > > The reviewer explained why he considered some issues as major. The > author discussed about the issues with the reviewer ( > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04859.html ). > There isn't a clear-cut rule on what is a major or minor issue. It's > up to the reviewer to make a judgement call. It is up to the > author(s), or working group, to decide about whether these issues > should be resolved and how to do so. For me "major" is something I would have put a DISCUSS for. > Some AppsDir reviews may list nits. These nits are generally > editorial issues. For example: > > "I personally found the Introduction somewhat hard to parse" > > That doesn't mean that the author has to make changes to the > Introduction section. It's an editorial decision. It's up to the > authors to determine whether the text should be changed so that the > reader can understand it. SM, it is not clear if you are trying to suggest some changes to the boilerplate used in AppsDir reviews or not. Can you clarify? From sm@elandsys.com Mon Apr 16 05:21: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 C1BF421F8704; Mon, 16 Apr 2012 05:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP5G6fLSofMR; Mon, 16 Apr 2012 05:21: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 BDD2821F86FD; Mon, 16 Apr 2012 05:21:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.236.220]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3GCLB5e027267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2012 05:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334578884; i=@elandsys.com; bh=IyscHDPdRtpaLm2LGZE4q1XsqW3UnArfUHhlE6EWjl8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=B4PctGII4055WkMSrhWwDlDjeS19of/8Wk7QEUdocPZF8AR6N39N1wID1IBeocZup bWutEL7kmVH5eudjJyooHNSraKJp1ehIz9MOjuzM/1AufOhnQFUbt6e/l/LsMPxwIS 4StcMKKuB/iTyJKnvl+VI5wgZfUCu0y3xC16EwKo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334578884; i=@elandsys.com; bh=IyscHDPdRtpaLm2LGZE4q1XsqW3UnArfUHhlE6EWjl8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NVr/dc5PAZ6YQINNV2yqd1zGMZDfK9DI1pnOUKsAV7bJTJIAf2msC9PfxmYu6bpLD QJUenfzd7CH+wuzAajL1lwHJoST3ok6fqw4VMHBquhVJYz6FRpbV3li8MI1EBw9uZH rW1XBbA0wHoQ17gQTxF4QM25u/PEPxtpWW8LO870= Message-Id: <6.2.5.6.2.20120416042035.09470db0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 16 Apr 2012 05:14:11 -0700 To: Alexey Melnikov From: S Moonesamy In-Reply-To: <4F89AE3A.5050503@isode.com> References: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> <4F89AE3A.5050503@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: appsdir@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 12:21:28 -0000 Hi Alexey, At 10:04 14-04-2012, Alexey Melnikov wrote: >For me "major" is something I would have put a DISCUSS for. Yes, as long as it is accompanied by supporting arguments. >SM, it is not clear if you are trying to suggest some changes to the >boilerplate used in AppsDir reviews or not. Can you clarify? The boilerplate can be improved. I don't want to turn it into a long disclaimer though. I suggest to wait and see whether the information for document authors published at http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ends up being useful. The boilerplate can be fine-tuned if there is significant feedback from people affected by AppsDir reviews. Regards, S. Moonesamy From derek@ihtfp.com Mon Apr 16 07:38: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 624A821F86F7 for ; Mon, 16 Apr 2012 07:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.831 X-Spam-Level: X-Spam-Status: No, score=-101.831 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zjnAsQJWlHv for ; Mon, 16 Apr 2012 07:38:27 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id D642121F86F2 for ; Mon, 16 Apr 2012 07:38:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D2AD3260299; Mon, 16 Apr 2012 10:38:19 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 15078-01; Mon, 16 Apr 2012 10:38:18 -0400 (EDT) Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 64C9D2600BB; Mon, 16 Apr 2012 10:38:18 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3GEcFuS008464; Mon, 16 Apr 2012 10:38:15 -0400 From: Derek Atkins To: Tim Bray References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> Date: Mon, 16 Apr 2012 10:38:15 -0400 In-Reply-To: (Tim Bray's message of "Fri, 13 Apr 2012 15:07:02 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a X-Mailman-Approved-At: Mon, 16 Apr 2012 08:05:47 -0700 Cc: Ned Freed , draft-ietf-oauth-v2-bearer.all@tools.ietf.org, Apps Discuss , Mark Nottingham , Pete Resnick Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 14:38:28 -0000 Tim, Tim Bray writes: > As I pointed out in the other thread on this, it=E2=80=99s an architectur= al > botch. Go and look in RFC3986 and find where it discusses reserving > keywords in this part of the URI. Hey, it=E2=80=99s not there! (hint, h= int) > > What *is* there is a lengthy discussion of the very important task, > done probably millions of times per second, of comparing two URIs and > deciding if they're equivalent, i.e. identify the same thing; this is > done by every piece of caching infrastructure and webcrawler. Do all > these have to be retooled to peek in the arguments and change their > decision based on whether some bits are just outh_* crud? (That > question is rhetorical). > > This is a deeply bad idea. -T As pointed out elsewhere on this thread by Mike Jones, caches, crawlers, and other middleware will never see this because the bearer token MUST be protected by SSL/TLS. So no, nothing needs to be retooled because nothing will see it. -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From jeni@jenitennison.com Mon Apr 16 01:33: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 31AA721F86D7 for ; Mon, 16 Apr 2012 01:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TA95FrUdqiW for ; Mon, 16 Apr 2012 01:33:52 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9B29F21F86D6 for ; Mon, 16 Apr 2012 01:33:51 -0700 (PDT) Received: from cpc19-epso4-2-0-cust100.6-3.cable.virginmedia.com ([86.30.196.101] helo=[192.168.123.64]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SJhNd-0006ao-Nc; Mon, 16 Apr 2012 09:33:49 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jeni Tennison In-Reply-To: <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> Date: Mon, 16 Apr 2012 09:33:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> To: Ned Freed , "Murray S. Kucherawy" , john+ietf@jck.com, tony+mtsuffix@maillennium.att.com X-Mailer: Apple Mail (2.1257) X-Mailcore-Auth: 9919842 X-Mailcore-Domain: 1066436 X-Mailman-Approved-At: Mon, 16 Apr 2012 08:05:55 -0700 Cc: Julian Reschke , Noah Mendelsohn , apps-discuss@ietf.org, "www-tag@w3.org List" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 08:33:54 -0000 Hi Ned, all, Here is a set of concrete suggestions for amendments to = draft-ietf-appsawg-media-type-reg that I hope might focus discussion. = Basically they=20 * create a specific section in the media type registration template = for information about fragment identifier processing and provide some = high-level guidance about what should go there * create a section within the structured syntax suffix registration = template for discussions of generic processing of fragment identifiers = across media types that use that structured syntax I think there'd then be scope for a separate document that on all the = details about prioritising between overlapping fragment identifier = schemes and so on, but no need for that to be referenced from = draft-ietf-appsawg-media-type-reg. Thanks for your consideration, Jeni --- 1. Add a new section 'Fragment Identifier Recommendations' (before the = current 4.11 Additional Information) which says: Media type registrations SHOULD specify how applications should = interpret fragment identifiers [RFC3986] within the media type. Media types SHOULD adopt fragment identifier schemes that are used with other similar media types, to facilitate content negotiation across = them. In particular, media types that use a named structured syntax with a=20 registered "+suffix" SHOULD adopt any and all fragment identifier = schemes=20 defined within the structured syntax suffix registration. 2. Remove the last bullet point from the list in 4.11 Additional = Information, namely: o Information about how fragment/anchor identifiers [RFC3986] are constructed for use in conjunction with this media type. 3. In 5.7 Registration Template: a. Add a section 'Fragment identifier considerations' b. Remove the entry 'URI fragment/anchor identifier(s):' under = Additional information 4. Within 6.2 Structured Syntax Suffix Registration Template add a new = section: Fragment identifier considerations Generic processing of fragment identifiers for any type employing = this syntax should be described here. --=20 Jeni Tennison http://www.jenitennison.com From wmills@yahoo-inc.com Mon Apr 16 08:32: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 3437D21F8597 for ; Mon, 16 Apr 2012 08:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.014 X-Spam-Level: X-Spam-Status: No, score=-16.014 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_20=-0.74, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHIB732ap+3K for ; Mon, 16 Apr 2012 08:32:10 -0700 (PDT) Received: from nm9-vm4.bullet.mail.ne1.yahoo.com (nm9-vm4.bullet.mail.ne1.yahoo.com [98.138.91.169]) by ietfa.amsl.com (Postfix) with SMTP id 2349921F8593 for ; Mon, 16 Apr 2012 08:32:10 -0700 (PDT) Received: from [98.138.90.57] by nm9.bullet.mail.ne1.yahoo.com with NNFMP; 16 Apr 2012 15:32:06 -0000 Received: from [98.138.86.157] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 16 Apr 2012 15:32:06 -0000 Received: from [127.0.0.1] by omp1015.mail.ne1.yahoo.com with NNFMP; 16 Apr 2012 15:32:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 904104.48565.bm@omp1015.mail.ne1.yahoo.com Received: (qmail 46384 invoked by uid 60001); 16 Apr 2012 15:32:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334590326; bh=vrcVo1q82i0d/p6Igm9Enf6vp1WcwXV8JRO1HBIM5j8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TlLZ7yRaA8HGn3iTtDSphOvipxBjVTgq8PRk3KfXyzwFcWemVEz5Wg6xtN76fr20JOmGdLDFHQCEbn3nCpancyW+Lq6c8ayjoI5niyde1iI4nLsWGCfcDOxNIP+ufZ+7HOvzlOe+leMxePCTOpLIX5KasPECyBx1W+0ibZx7n7o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AraP9SoX6OCvtQkO9TnCc4+OIJWokcPNzM9/u8vTKv20MQ772Txt0kfRrFPv1txzDkmI+TQ7LXY9T0ZkC2U4xt41DJjO0pmasarS/h5eeREaI1u7FPFbHtFenad0T54E6uLruOcFknZxFcfHxF6TarPxx3Qg819PfchQxUWowOc=; X-YMail-OSG: Au8D49YVM1kcMGlFevCZqg_jTmmp6lpAAQ4qJ5zKRKIe2nU 6afRw_jfTkbNo1t4lUTJQeGj4T6QnwN4M855ulAsRgoxsI43gg.0r2wfhXtj LTlTyOt7nLrizIpZeNVSDLDMchRZoQOn84ryr7q.jSC2Rb6TOS8lNX1.m.su XTvOD_23Fb1oRt60Ld4zdjjWWLYVgde.iGypB6GotlahL5t1DXaZdvckICZP ev6YU9PKNRkJ4Qa2Ck4XcdkkGj.E9ppzlilVW7xGg9MhnAnXin0Fh1AnoWDC n6EThPGjC.wPAFq4vP0jlYnyP_eVQT16yPb6rgXa97d2rDPL401D91WO_Ilc PEHpykUGEOntaCB0Hhb4Wb0nbEySri_6WzQB51XU74NUPwupOhxm68GcxOkO VsPepWT40qkH5MNS0tf1MO13wT3On_zbUcPitxHmYgZkoPhrfl.nl9GeYIk1 o7UBkCDKfwpdN369Nr9AvYejt Received: from [99.31.212.42] by web31807.mail.mud.yahoo.com via HTTP; Mon, 16 Apr 2012 08:32:06 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> Message-ID: <1334590326.6719.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Mon, 16 Apr 2012 08:32:06 -0700 (PDT) From: William Mills To: Derek Atkins , Tim Bray In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-1811558597-1334590326=:6719" Cc: Pete Resnick , Mark Nottingham , Ned Freed , Apps Discuss , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer 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, 16 Apr 2012 15:32:11 -0000 ---125733401-1811558597-1334590326=:6719 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0AA big problem, in my opinion, is that credentials will end up in the = browser history cache when they are included in the URL.=C2=A0 This is sign= ificant.=C2=A0 Unless an explicit user "sign out" in the browser invalidate= s all tokens issued to the browser (this is a significant revocation requir= ement and revocations isn't properly solved yet) then someone sitting down = at the machine can recover a credential by looking in the history.=0A=0A=0A= Note that enterprise edge proxies that are doing SSL termination may well s= ee this, but that could be considered "their problem".=C2=A0 I have seen ap= parent evidence of =0Alarge companies using egress proxies that terminate a= ll SSL outbound at =0Atheir proxy (depressingly evil), and they frequently = get stuff wrong in =0Aterms of proxy settings.=0A=0A-bill=0A=0A=0A=0A>_____= ___________________________=0A> From: Derek Atkins =0A>To:= Tim Bray =0A>Cc: Ned Freed ;= draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss ; Mark Nottingham ; Pete Resnick =0A>Sent: Monday, April 16, 2012 7:38 AM=0A>Subject: Re: [apps-discus= s] Reserved URI query parameter in draft-ietf-oauth-v2-bearer=0A> =0A>Tim,= =0A>=0A>Tim Bray writes:=0A>=0A>> As I pointed out i= n the other thread on this, it=E2=80=99s an architectural=0A>> botch. Go an= d look in RFC3986 and find where it discusses reserving=0A>> keywords in th= is part of the URI.=C2=A0 Hey, it=E2=80=99s not there!=C2=A0 (hint, hint)= =0A>>=0A>> What *is* there is a lengthy discussion of the very important ta= sk,=0A>> done probably millions of times per second, of comparing two URIs = and=0A>> deciding if they're equivalent, i.e. identify the same thing; this= is=0A>> done by every piece of caching infrastructure and webcrawler.=C2= =A0 Do all=0A>> these have to be retooled to peek in the arguments and chan= ge their=0A>> decision based on whether some bits are just outh_* crud?=C2= =A0 =C2=A0 (That=0A>> question is rhetorical).=0A>>=0A>> This is a deeply b= ad idea. -T=0A>=0A>As pointed out elsewhere on this thread by Mike Jones, c= aches, crawlers,=0A>and other middleware will never see this because the be= arer token MUST=0A>be protected by SSL/TLS.=C2=A0 So no, nothing needs to b= e retooled because=0A>nothing will see it.=0A>=0A>-derek=0A>=0A>-- =0A>=C2= =A0 =C2=A0 =C2=A0 Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 617-623-3745=0A>=C2=A0 =C2=A0 =C2=A0 derek@ihtfp.com=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 www.ihtfp.com=0A>=C2=A0 =C2=A0 =C2=A0 C= omputer and Internet Security Consultant=0A>_______________________________= ________________=0A>apps-discuss mailing list=0A>apps-discuss@ietf.org=0A>h= ttps://www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A> ---125733401-1811558597-1334590326=:6719 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

A big problem, in my opinion, is that credentials will e= nd up in the browser history cache when they are included in the URL. = This is significant.  Unless an explicit user "sign out" in the brows= er invalidates all tokens issued to the browser (this is a significant revo= cation requirement and revocations isn't properly solved yet) then someone = sitting down at the machine can recover a credential by looking in the hist= ory.

Note that enterprise=0A edge= proxies that are doing SSL termination may well see this, but that=0A coul= d be considered "their problem".  I have seen apparent evidence of =0A= large companies using egress proxies that terminate all SSL outbound at =0A= their proxy (depressingly evil), and they frequently get stuff wrong in =0A= terms of proxy settings.

-bill
=0A

=0A
From: Derek Atkins <derek@ihtfp.com>
To: Tim Bray <tbray@textuality.= com>
Cc: Ned Freed = <ned.freed@mrochek.com>; draft-ietf-oauth-v2-bearer.all@tools.ietf.or= g; Apps Discuss <apps-discuss@ietf.org>; Mark Nottingham <mnot@mno= t.net>; Pete Resnick <presnick@qualcomm.com>
Sent: Monday, April 16, 2012 7:38 AM
= Subject: Re: [apps-discuss] Reserved URI query parameter= in draft-ietf-oauth-v2-bearer

=0ATim,

Tim Br= ay <tbray@textuality.com> writes:

> As I pointed o= ut in the other thread on this, it=E2=80=99s an architectural
> botch= . Go and look in RFC3986 and find where it discusses reserving
> keyw= ords in this part of the URI.  Hey, it=E2=80=99s not there!  (hin= t, hint)
>
> What *is* there is a lengthy discussion of the ver= y important task,
> done probably millions of times per second, of co= mparing two URIs and
> deciding if they're equivalent, i.e. identify = the same thing; this is
> done by every piece of caching infrastructu= re and webcrawler.  Do all
> these have to be retooled to peek i= n the arguments and change their
> decision based on whether some bit= s are just outh_* crud?    (That
> question is rhetorical).=
>
> This is a deeply bad idea. -T

As pointed out elsewhere on this thread by Mike Jones, caches, crawlers,
and other= middleware will never see this because the bearer token MUST
be protect= ed by SSL/TLS.  So no, nothing needs to be retooled because
nothing= will see it.

-derek

--
      Derek Atkin= s                617-623-3745
&= nbsp;     derek@ihtfp.com           = ; www.ihtfp.com
=       Computer and Internet Security Consultant
________= _______________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

---125733401-1811558597-1334590326=:6719-- From vkg@bell-labs.com Mon Apr 16 08:39: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 0646A21F863E for ; Mon, 16 Apr 2012 08:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.099 X-Spam-Level: X-Spam-Status: No, score=-109.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7CVhXxy4u78 for ; Mon, 16 Apr 2012 08:39:11 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D098021F84D0 for ; Mon, 16 Apr 2012 08:39:10 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q3GFd98V008955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2012 10:39:09 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3GFd9Ww017953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Apr 2012 10:39:09 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q3GFd8uJ018291; Mon, 16 Apr 2012 10:39:09 -0500 (CDT) Message-ID: <4F8C3E49.5030100@bell-labs.com> Date: Mon, 16 Apr 2012 10:44:09 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: draft-ietf-cdni-problem-statement@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] Review of draft-ietf-cdni-problem-statement-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, 16 Apr 2012 15:39:12 -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-cdni-problem-statement-04 Title: Content Distribution Network Interconnection (CDNI) Problem Statement Reviewer: Vijay K. Gurbani Review Date: Apr-16-2012 IETF Last Call Date: Not known IESG Telechat Date: Not known Summary: This draft is ready for publication as an Informational. Major Issues: 1 Minor Issues: 5 Nits: 4 Major Issues: - S6: I believe that expanding the security considerations for each CDNI interface will help in the long run. Here is a first stab at this that you may want to consider replacing the second paragraph with (please feel free to expand this since you are the subject matter experts here). Suggested text: 6.1 Security of the CDNI Request Routing Interface Appropriate levels of authentication and confidentiality must be used in this interface because it allows an upstream CDN to query capabilities of a downstream CDN, and conversely, allows the downstream CDN to control the upstream CDN's Request Routing function. Absent appropriate security on this interface, a rogue upstream CDN can inundate downstream CDNs with bogus requests, or have the downstream CDN send the rogue upstream CDN private information (e.g., load, resources). 6.2 Security of the CDNI Control Interface Information on this interface is of a very private nature as well. A pair of CDNs use this interface to allow bootstrapping of content acquisition; an upstream CDN may pre-position content in a downstream CDN, or it may purge the contents at a downstream CDN; a downstream CDN may provide administrative information to an upstream CDN, etc. All of these operations require that the peer CDNs are appropriately authenticated and that the confidentiality of information flowing between them is maintained. 6.3 Security of the CDNI Metadata Interface Because this interface allows a downstream CDN to request metadata from an upstream CDN, the latter must ensure that the former is appropriately authenticated before sending the data. Conversely, a downstream CDN must authenticate an upstream CDN before requesting metadata to insulate itself from poisoning by rouge upstream CDNs. The confidentiality of the information exchanged between the peers must be protected. 6.4 Security of the CDNI Logging Interface Logging data consists of potentially sensitive information (which user accesses which media resource, IP addresses of users, potential names and subscriber account information, etc.) This information must be protected as the log records are moved between hosts. Minor Issues: - S1: Your problem statement essentially is an interplay between four logical entities: end user, CSP, CDN, and NSP. I think this interplay needs to be laid out a bit more explicitly. It seems to me that your model is that a user is subscribed to a CSP. The CSP has arrangements with various CDN providers to distribute content. The user, at a certain point in time, is in a network owned by a NSP that uses a CDN that does not have receive content from CSP. Thus CSP is at a disadvantage since it will have to serve the user from a CDN that is not necessarily close to the user, thereby introducing a reduced quality of experience for the user. What CDNI does is enable the CSP to contract with an "authoritative" CDN provider for the delivery of content and that that authoritative CDN Provider could contract with one or more downstream CDN Provider(s) to distribute and deliver some or all of the content on behalf of the authoritative CDN Provider. Because the downstream CDN Provider(s) will be closer to the user, the user is subjected to a better viewing experience than he or she would be had the content been delivered from a farther CDN. I think that laying out the interplay between the four entities in the second paragraph of S1 more explicitly may provide better context to the reader who is not already well versed with CDNs. - S1: I would advise to order the terms defined by an alphabetical order (if possible). - S3, last paragraph: The term "where to go" is rather ambiguous. Do you mean, "which upstream CDN to acquire content from"? Or something else? It will help to make this more explicit. - S4, last paragraph: it is stated that "we assume that this [developing a new protocol] is unnecessary". Based on the contents of S4.1- S4.4, I believe you do more than "assume". You clearly enunciate a list of protocols that can be used for the various interfaces, thus providing a first order reasoning for why a new protocol for CDNI is not needed. Therefore, I would exhort you to use a stronger word than "assume"; something like: Secondly, although a new application protocol could be designed specifically for CDNI, our analysis below shows that this is unnecessary ... - S4.3: Are these "log lines" or "log records"? Presumably, one or more lines will aggregate to one log record. It seems appropriate in this document to talk about "log records" instead of "log lines". The CDNI logging interface draft can tease out more precisely how many lines comprise a record, etc. Secure ftp and secure copying (scp) appears to be missing in the list of protocols. I would suspect that sftp would be preferred over normal ftp. Nits: - Global: In the Abstract and S1, "End Users" is employed multiple times. End Users is defined in the Terminology section as a definition. I would propose that attach the acronym "EU" on the first encounter of "End User" in the Abstract and S1, and from then on simply use "EU". - S1, second paragraph: "attachment network" sounds incomplete. Maybe you meant "attachment to the network"? - S3: s/existing protocols: this is/existing protocols; this is/ - S4.1, last paragraph: May be good to give a reference to ALTO. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From stephen.farrell@cs.tcd.ie Mon Apr 16 08:47:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B44B21F85F2 for ; Mon, 16 Apr 2012 08:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.284 X-Spam-Level: X-Spam-Status: No, score=-102.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBXLBhhl1r7J for ; Mon, 16 Apr 2012 08:47:16 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 2F61B21F85EF for ; Mon, 16 Apr 2012 08:47:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 04F58171473; Mon, 16 Apr 2012 16:47:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334591233; bh=nNshFYPLJsArTe CJO8nUB1/VuSsVuUQoB8doKnXQvKs=; b=ruEuh5plC3XPGsv5L8Au12dOp2XbCR mGxRTfL5jEALPUjmTrrcOVvkYlhPZRoleXm7Hj1b3/phUsoYdJezz8LMn+tC47r0 QMBS9UZWyz5Zp9ivmtzPLuGlvygcI0uvyCXiXFyHBYgZsfocMQJRoqCnWKtHktL8 glvtWHS5UwI7l/TS5feTCxpz4zKnwvm2tY3KUFRq1NIUSGF2UA/Rgq9JFaHIFa4K 6BSEbMOG3GrwaPHUFNpYgTVK63x260nZB3bG5GRBMbg08mQBjG+y0R+VeoZFbsxD T51Iq+5XVhBFVb2AttYDaXpKdvr96+ssDsam3+JbcHWecCRfoQdT0f5A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id VkBZDN61I3Cm; Mon, 16 Apr 2012 16:47:13 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 8F12C171471; Mon, 16 Apr 2012 16:47:09 +0100 (IST) Message-ID: <4F8C3EFF.20103@cs.tcd.ie> Date: Mon, 16 Apr 2012 16:47:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: William Mills References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <1334590326.6719.YahooMailNeo@web31807.mail.mud.yahoo.com> In-Reply-To: <1334590326.6719.YahooMailNeo@web31807.mail.mud.yahoo.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Ned Freed , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss , Mark Nottingham , Pete Resnick , Derek Atkins Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 15:47:17 -0000 Hi Bill, On 04/16/2012 04:32 PM, William Mills wrote: > > > A big problem, in my opinion, is that credentials will end up in the browser history cache when they are included in the URL. This is significant. Unless an explicit user "sign out" in the browser invalidates all tokens issued to the browser (this is a significant revocation requirement and revocations isn't properly solved yet) then someone sitting down at the machine can recover a credential by looking in the history. > > > Note that enterprise edge proxies that are doing SSL termination may well see this, but that could be considered "their problem". I have seen apparent evidence of > large companies using egress proxies that terminate all SSL outbound at > their proxy (depressingly evil), and they frequently get stuff wrong in > terms of proxy settings. Right. I agree that is an issue. The draft does try to address that and we can chat about whether it does that well enough or not (but that's maybe more for the oauth list really.) But your issue is a different one from that being discussed in this thread. Yours is due to the value being a bearer token and not due to the name of the parameter being registered/reserved. S. > > -bill > > > >> ________________________________ >> From: Derek Atkins >> To: Tim Bray >> Cc: Ned Freed ; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss ; Mark Nottingham ; Pete Resnick >> Sent: Monday, April 16, 2012 7:38 AM >> Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer >> >> Tim, >> >> Tim Bray writes: >> >>> As I pointed out in the other thread on this, it’s an architectural >>> botch. Go and look in RFC3986 and find where it discusses reserving >>> keywords in this part of the URI. Hey, it’s not there! (hint, hint) >>> >>> What *is* there is a lengthy discussion of the very important task, >>> done probably millions of times per second, of comparing two URIs and >>> deciding if they're equivalent, i.e. identify the same thing; this is >>> done by every piece of caching infrastructure and webcrawler. Do all >>> these have to be retooled to peek in the arguments and change their >>> decision based on whether some bits are just outh_* crud? (That >>> question is rhetorical). >>> >>> This is a deeply bad idea. -T >> >> As pointed out elsewhere on this thread by Mike Jones, caches, crawlers, >> and other middleware will never see this because the bearer token MUST >> be protected by SSL/TLS. So no, nothing needs to be retooled because >> nothing will see it. >> >> -derek >> >> -- >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> >> From stpeter@stpeter.im Mon Apr 16 09:07: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 DEC4121F8656 for ; Mon, 16 Apr 2012 09:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.654 X-Spam-Level: X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfhFxHptqZLO for ; Mon, 16 Apr 2012 09:07:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE3C21F85FF for ; Mon, 16 Apr 2012 09:07:10 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4387A40058; Mon, 16 Apr 2012 10:21:17 -0600 (MDT) Message-ID: <4F8C43AC.10005@stpeter.im> Date: Mon, 16 Apr 2012 10:07:08 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ned Freed References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> In-Reply-To: <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeni Tennison , apps-discuss@ietf.org, tony+mtsuffix@maillennium.att.com, Julian Reschke , Noah Mendelsohn , john+ietf@jck.com, "www-tag@w3.org List" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 16:07:12 -0000 On 4/13/12 11:00 PM, Ned Freed wrote: >> Perhaps that's the best way of handling it, and nothing needs to be said >> specifically about fragments identifiers for top-level types. > > This isn't an option either. This is a registration best current practices > (BCP) document that sets down rules for registering media types. Default or > intrinsic syntax and semantics of fragment identifiers associated with a > particular top-level type is a protocol specification. This isn't allowed in a > BCP - BCPs are one shot affairs and not subject to interoperability testing, > which rather obviously would apply to the specification of such semantics. > > If you want to put this stuff in an RFC, it needs to one that's on the regular > standards track. And that means it needs to be in a different document. All you > can put in this document are the registration rules for specifying a fragment > identifier. Nothing more. Ned is right: this document defines best practices for *registering* media types. We all might want to more clearly specify the syntax and semantics of fragment identifiers, but IMHO that's out of scope for the registration procedures per se. Peter -- Peter Saint-Andre https://stpeter.im/ From wmills@yahoo-inc.com Mon Apr 16 09:23: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 A6FAF11E809C for ; Mon, 16 Apr 2012 09:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.878 X-Spam-Level: X-Spam-Status: No, score=-16.878 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAyno0XwOSqv for ; Mon, 16 Apr 2012 09:23:19 -0700 (PDT) Received: from nm25-vm0.bullet.mail.bf1.yahoo.com (nm25-vm0.bullet.mail.bf1.yahoo.com [98.139.213.156]) by ietfa.amsl.com (Postfix) with SMTP id 99F2311E8091 for ; Mon, 16 Apr 2012 09:23:19 -0700 (PDT) Received: from [98.139.212.144] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 16 Apr 2012 16:23:19 -0000 Received: from [98.139.212.205] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 16 Apr 2012 16:23:19 -0000 Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 16 Apr 2012 16:23:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 16725.1673.bm@omp1014.mail.bf1.yahoo.com Received: (qmail 90752 invoked by uid 60001); 16 Apr 2012 16:23:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334593398; bh=fXIGkT0l/vETyDeh4qhS0ecFDGREr0SWzCw56RQERGM=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Jvx37sAVO8/ejYCxVVvmg0rO2Ff/T2XpRYcRPE3qRX7Jnuds3HjUHryWEpl3BVp+PwvVp79v5kL/LUDRrkrseVh/MpgwFpE+OCZ9UAkD+F2RxLUoIQx4QQl4+zULey3uU8mqlNZxzIiBzwQdmIE8bftN9zqDWpD1CuVTmyDrBR8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KZWJJ1Z9m9sNgD+tj0EtkBb+EwL4KuHXsjdwbB7wuNQ15ute1yvy5KRocMRI9Oj78aBJMO4VgP74IQzSag9TFyBEec0p7Q1RddmnoFyFf829/co1+oS/o983WKpdN06tZNalOuRqBHrXkGXi05DCWNXdArGYfiTP7JMwfXUT91E=; X-YMail-OSG: T6_N.JkVM1mhH_I9iBFJZhWOt3eCWMLk5O2MD_yICqG9nmr DcQ49cHqJuIL11dktgHeSkd8knDp0vEdRTTKC8A7N23903VzRGMZ5_tpc_iP imjhY0OeGMVwkJCB4bbJddKOf3_QtQrRH2CnWKbg4T2q386Muas0p5uykP5. JAZt.tw8I3f8YDTwdrgPsgH8jZjQgoJS1CQ6Wc2oB5ptay.5xIm1lGarhTjg Hi7UUzewGhNFy_V17cmKxQUPxx.2qY2yS6sbgQpV5.BEIHgSuj6ZgRDnfybd WIfpoVkMzeTUw3TEk30XwC0ugruLUJRTMFCRMHDIjameY8CPYl7747G7.wMI TDgWPb9_lLsO8xE4Bs3Z_14t2bf_cv5ZuSvGkgLHorb1WKTQ62SVeN3BpEot MbyZb2ZRMfpPlb8nN19PAaP6cVXwd43GrKpyZVgM2exzCvrltOgKQ3tt0dFQ nVKmzNzToMIsMvZ6xO4GjCwVv Received: from [99.31.212.42] by web31808.mail.mud.yahoo.com via HTTP; Mon, 16 Apr 2012 09:23:18 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <1334590326.6719.YahooMailNeo@web31807.mail.mud.yahoo.com> <4F8C3EFF.20103@cs.tcd.ie> Message-ID: <1334593398.74981.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Mon, 16 Apr 2012 09:23:18 -0700 (PDT) From: William Mills To: Stephen Farrell In-Reply-To: <4F8C3EFF.20103@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Ned Freed , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss , Mark Nottingham , Pete Resnick , Derek Atkins Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer 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, 16 Apr 2012 16:23:20 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Stephen Farrell = =0A>To: William Mills =0A= >Cc: Derek Atkins ; Tim Bray ; Ned F= reed ; "draft-ietf-oauth-v2-bearer.all@tools.ietf.or= g" ; Apps Discuss ; Mark Nottingham ; Pete Resnick =0A>Sent: Monday, April 16, 2012 8:47 AM=0A>Subject: Re: [apps-di= scuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer=0A> =0A>= =0A>Hi Bill,=0A>=0A>On 04/16/2012 04:32 PM, William Mills wrote:=0A>> =0A>>= =0A>> A big problem, in my opinion, is that credentials will end up in the= browser history cache when they are included in the URL.=C2=A0 This is sig= nificant.=C2=A0 Unless an explicit user "sign out" in the browser invalidat= es all tokens issued to the browser (this is a significant revocation requi= rement and revocations isn't properly solved yet) then someone sitting down= at the machine can recover a credential by looking in the history.=0A>> = =0A>> =0A>> Note that enterprise edge proxies that are doing SSL terminatio= n may well see this, but that could be considered "their problem".=C2=A0 I = have seen apparent evidence of =0A>> large companies using egress proxies t= hat terminate all SSL outbound at =0A>> their proxy (depressingly evil), an= d they frequently get stuff wrong in =0A>> terms of proxy settings.=0A>=0A>= Right. I agree that is an issue. The draft does try to address that=0A>and = we can chat about whether it does that well enough or not (but=0A>that's ma= ybe more for the oauth list really.)=0A>=0A>But your issue is a different o= ne from that being discussed in=0A>this thread. Yours is due to the value b= eing a bearer token and=0A>not due to the name of the parameter being regis= tered/reserved.=0A=0AYeah, true.=C2=A0 But if it's not there then it doesn'= t need a name.=0A=0A=0A>=0A>S.=0A>=0A>=0A>> =0A>> -bill=0A>> =0A>> =0A>> = =0A>>> ________________________________=0A>>> From: Derek Atkins =0A>>> To: Tim Bray =0A>>> Cc: Ned Freed ; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Di= scuss ; Mark Nottingham ; Pete Resnic= k =0A>>> Sent: Monday, April 16, 2012 7:38 AM=0A>>>= Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oau= th-v2-bearer=0A>>>=0A>>> Tim,=0A>>>=0A>>> Tim Bray w= rites:=0A>>>=0A>>>> As I pointed out in the other thread on this, it=E2=80= =99s an architectural=0A>>>> botch. Go and look in RFC3986 and find where i= t discusses reserving=0A>>>> keywords in this part of the URI.=C2=A0 Hey, i= t=E2=80=99s not there!=C2=A0 (hint, hint)=0A>>>>=0A>>>> What *is* there is = a lengthy discussion of the very important task,=0A>>>> done probably milli= ons of times per second, of comparing two URIs and=0A>>>> deciding if they'= re equivalent, i.e. identify the same thing; this is=0A>>>> done by every p= iece of caching infrastructure and webcrawler.=C2=A0 Do all=0A>>>> these ha= ve to be retooled to peek in the arguments and change their=0A>>>> decision= based on whether some bits are just outh_* crud?=C2=A0 =C2=A0 (That=0A>>>>= question is rhetorical).=0A>>>>=0A>>>> This is a deeply bad idea. -T=0A>>>= =0A>>> As pointed out elsewhere on this thread by Mike Jones, caches, crawl= ers,=0A>>> and other middleware will never see this because the bearer toke= n MUST=0A>>> be protected by SSL/TLS.=C2=A0 So no, nothing needs to be reto= oled because=0A>>> nothing will see it.=0A>>>=0A>>> -derek=0A>>>=0A>>> -- = =0A>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0617-623-3745=0A>>>=C2=A0 =C2=A0 =C2= =A0 derek@ihtfp.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 www.ihtfp.com= =0A>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Computer and Internet Security Consultant= =0A>>> _______________________________________________=0A>>> apps-discuss m= ailing list=0A>>> apps-discuss@ietf.org=0A>>> https://www.ietf.org/mailman/= listinfo/apps-discuss=0A>>>=0A>>>=0A>>>=0A>=0A>=0A> From msk@cloudmark.com Mon Apr 16 09:49: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 F237721F85D3 for ; Mon, 16 Apr 2012 09:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHbwwzvsO9m1 for ; Mon, 16 Apr 2012 09:49:22 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6596A21F85D2 for ; Mon, 16 Apr 2012 09:49:22 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id ygpM1i0010ZaKgw01gpMn4; Mon, 16 Apr 2012 09:49:21 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=CMKorGXD c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=4zWJvGiJOd0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=9NGZVl_YAAAA:8 a=SSmOFEACAAAA:8 a=t1nnKUNFtySeYt2VX-kA:9 a=0qLjg1Qp34bHUJhMPWsA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=I9DA3x22SqsA:10 a=69XIa8IdTDMA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Mon, 16 Apr 2012 09:49:21 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures Thread-Index: AQHNG+r80LIQF+Mfl0iD33houG6N4ZadqYbw Date: Mon, 16 Apr 2012 16:49:20 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F37B9@exch-mbx901.corp.cloudmark.com> References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <4F8C43AC.10005@stpeter.im> In-Reply-To: <4F8C43AC.10005@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334594961; bh=WaeeqaFFUFBqfKCwAmMMSLBl/y4x1w33/XCs6PtCjvw=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=JVyOF1cMX/NiwywrbkSnqRzLuF6it+mNrNnYtgZa0V+V10ICq3xpmqiU6V+qUDVI7 M0x+yn5pT7WfOhrjJgCBjyMjn2KqNHv7+919sWQZ0ELE/R3rGopiD5gcR5HjuP8HWH RDivsQCU1EHP00sBIo9HMnham9guXwYGwv+m1RWo= Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 16:49:23 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Peter Saint-Andre > Sent: Monday, April 16, 2012 9:07 AM > To: Ned Freed > Cc: Jeni Tennison; apps-discuss@ietf.org; > tony+mtsuffix@maillennium.att.com; Julian Reschke; Noah Mendelsohn; > john+ietf@jck.com; www-tag@w3.org List > Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type > Specifications and Registration Procedures >=20 > > If you want to put this stuff in an RFC, it needs to one that's on the > > regular standards track. And that means it needs to be in a different > > document. All you can put in this document are the registration rules > > for specifying a fragment identifier. Nothing more. >=20 > Ned is right: this document defines best practices for *registering* > media types. We all might want to more clearly specify the syntax and > semantics of fragment identifiers, but IMHO that's out of scope for the > registration procedures per se. I think I agree. Would it be an appropriate path forward to put that into = another document, and then reference that one from this one as an Informati= ve? -MSK, as participant From stpeter@stpeter.im Mon Apr 16 09:53: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 560C021F86E4 for ; Mon, 16 Apr 2012 09:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.651 X-Spam-Level: X-Spam-Status: No, score=-102.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPJhFyrUJpRc for ; Mon, 16 Apr 2012 09:53:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A359521F86DA for ; Mon, 16 Apr 2012 09:53:44 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A8CB340058; Mon, 16 Apr 2012 11:07:51 -0600 (MDT) Message-ID: <4F8C4E97.1000709@stpeter.im> Date: Mon, 16 Apr 2012 10:53:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <4F8C43AC.10005@stpeter.im> <9452079D1A51524AA5749AD23E0039280F37B9@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F37B9@exch-mbx901.corp.cloudmark.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 16:53:46 -0000 On 4/16/12 10:49 AM, Murray S. Kucherawy wrote: >> -----Original Message----- From: apps-discuss-bounces@ietf.org >> [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Peter >> Saint-Andre Sent: Monday, April 16, 2012 9:07 AM To: Ned Freed Cc: >> Jeni Tennison; apps-discuss@ietf.org; >> tony+mtsuffix@maillennium.att.com; Julian Reschke; Noah >> Mendelsohn; john+ietf@jck.com; www-tag@w3.org List Subject: Re: >> [apps-discuss] W3C TAG Comment on Draft Media Type Specifications >> and Registration Procedures >> >>> If you want to put this stuff in an RFC, it needs to one that's >>> on the regular standards track. And that means it needs to be in >>> a different document. All you can put in this document are the >>> registration rules for specifying a fragment identifier. Nothing >>> more. >> >> Ned is right: this document defines best practices for >> *registering* media types. We all might want to more clearly >> specify the syntax and semantics of fragment identifiers, but IMHO >> that's out of scope for the registration procedures per se. > > I think I agree. Would it be an appropriate path forward to put that > into another document, and then reference that one from this one as > an Informative? I don't think so. All we're trying to do here is make is easier for folks to register media types. The thorny issues of the syntax and semantics of media types and pointers thereto (which is what fragment identifiers are at some level) are IMHO orthogonal to how you register media types. Plus, the document we point to from the registration BCP will likely change so significantly by the time it's done that the citation will be mostly meaningless at this time. Peter -- Peter Saint-Andre https://stpeter.im/ From msk@cloudmark.com Mon Apr 16 10:03: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 0E32A11E80E6 for ; Mon, 16 Apr 2012 10:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oeXWH7aI0Nz for ; Mon, 16 Apr 2012 10:03:47 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 32A2D11E80E2 for ; Mon, 16 Apr 2012 10:03:47 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id yh3m1i0010ZaKgw01h3mrw; Mon, 16 Apr 2012 10:03:46 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=CMKorGXD c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=cN_zoil0n28A:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=ACu5C7bljwlimB84ZvQA:9 a=CjuIK1q_8ugA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Mon, 16 Apr 2012 10:03:46 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: Call for Adoption: draft-hansen-media-type-suffix-regs Thread-Index: Ac0b8uKhKahSKZzSSfKpBhG9RJQYWw== Date: Mon, 16 Apr 2012 17:03:46 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F383E@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280F383Eexchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334595826; bh=Q2dUsZF5mrqYcbYQC3PGmbUD0ZFNe416LuDx/VwuJPE=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=XloB7de1ReaknwlKYs6lY9zbm62hIyAUIzGc31o6JHkcXvm69JdvhlepZayFVZQvl g+Ztj4TC2mHeuiaYiubzkfBE4rXuKrhyqQez8zkGforcYbI9gtawEyt92iPtAU2Q13 PxCFsUaeDj1TJMLj5nKtBG4TaNt2BEALxTrnBP1Q= Subject: [apps-discuss] Call for Adoption: draft-hansen-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:03:48 -0000 --_000_9452079D1A51524AA5749AD23E0039280F383Eexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We're putting the finishing touches on draft-ietf-appsawg-media-type-regs a= nd draft-ietf-appsawg-mime-charset-default will complete WGLC this week. I= n the mix now (by virtue of a reference from the former) is draft-hansen-me= dia-type-suffix-regs, and so we'd like to adopt it as a WG document. Please indicate your support or objection, and opinions thereto. -MSK --_000_9452079D1A51524AA5749AD23E0039280F383Eexchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’re putting the finishing touches on draft-i= etf-appsawg-media-type-regs and draft-ietf-appsawg-mime-charset-default wil= l complete WGLC this week.  In the mix now (by virtue of a reference f= rom the former) is draft-hansen-media-type-suffix-regs, and so we’d like to adopt it as a WG document.

 

Please indicate your support or objection, and opini= ons thereto.

 

-MSK

--_000_9452079D1A51524AA5749AD23E0039280F383Eexchmbx901corpclo_-- From stpeter@stpeter.im Mon Apr 16 10:07: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 A4D7F11E80CF for ; Mon, 16 Apr 2012 10:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.65 X-Spam-Level: X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vf4fY4kunTlD for ; Mon, 16 Apr 2012 10:07:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F2B4621F85C4 for ; Mon, 16 Apr 2012 10:07:30 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C5E0940058; Mon, 16 Apr 2012 11:21:37 -0600 (MDT) Message-ID: <4F8C51D1.2020905@stpeter.im> Date: Mon, 16 Apr 2012 11:07:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <9452079D1A51524AA5749AD23E0039280F383E@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F383E@exch-mbx901.corp.cloudmark.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Call for Adoption: draft-hansen-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:07:32 -0000 On 4/16/12 11:03 AM, Murray S. Kucherawy wrote: > We’re putting the finishing touches on > draft-ietf-appsawg-media-type-regs and > draft-ietf-appsawg-mime-charset-default will complete WGLC this week. > In the mix now (by virtue of a reference from the former) is > draft-hansen-media-type-suffix-regs, and so we’d like to adopt it as a > WG document. > > Please indicate your support or objection, and opinions thereto. I think it would be valuable to process this document as a WG item along with the aforementioned documents. Peter -- Peter Saint-Andre https://stpeter.im/ From alexey.melnikov@isode.com Mon Apr 16 10:15: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 2A99E11E80A0 for ; Mon, 16 Apr 2012 10:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfE2fiio6VX7 for ; Mon, 16 Apr 2012 10:15:37 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0F411E809D for ; Mon, 16 Apr 2012 10:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334596535; d=isode.com; s=selector; i=@isode.com; bh=f7WDyoEdpeDDbAkmr6J0Y3B1yREs/6/cX2lojZ+Rue4=; 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=TeR7oczWoW9Ya+jWLbgkfc9E6lnP6lxVFijp2GVxlfJnASK9kz0doYU2dgayP8pYurQiw5 7Zs0JKdYumMk1MKvfTJjnq8jd9BG+krETTN04WU+CEnY+MbBpCpGHY3GDd2KIF76od/m01 zNcrdPWw1tvXd9ckkrKz5g31Aa3T2Rg=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Apr 2012 18:15:35 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F8C53E6.4010801@isode.com> Date: Mon, 16 Apr 2012 18:16:22 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "Murray S. Kucherawy" References: <9452079D1A51524AA5749AD23E0039280F383E@exch-mbx901.corp.cloudmark.com> <4F8C51D1.2020905@stpeter.im> In-Reply-To: <4F8C51D1.2020905@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Call for Adoption: draft-hansen-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:15:38 -0000 On 16/04/2012 18:07, Peter Saint-Andre wrote: > On 4/16/12 11:03 AM, Murray S. Kucherawy wrote: >> We=92re putting the finishing touches on >> draft-ietf-appsawg-media-type-regs and >> draft-ietf-appsawg-mime-charset-default will complete WGLC this week. >> In the mix now (by virtue of a reference from the former) is >> draft-hansen-media-type-suffix-regs, and so we=92d like to adopt it as a >> WG document. >> >> Please indicate your support or objection, and opinions thereto. > I think it would be valuable to process this document as a WG item along > with the aforementioned documents. As a WG participant: +1 From dhc@dcrocker.net Mon Apr 16 10:48: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 7ACE521F8763 for ; Mon, 16 Apr 2012 10:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kM41CwpDrnrF for ; Mon, 16 Apr 2012 10:48:13 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB1721F8762 for ; Mon, 16 Apr 2012 10:48:13 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3GHlu2B007177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Apr 2012 10:47:59 -0700 Message-ID: <4F8C5B4C.5020704@dcrocker.net> Date: Mon, 16 Apr 2012 10:47:56 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <9452079D1A51524AA5749AD23E0039280F383E@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F383E@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 16 Apr 2012 10:48:00 -0700 (PDT) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Call for Adoption: draft-hansen-media-type-suffix-regs 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: Mon, 16 Apr 2012 17:48:14 -0000 On 4/16/2012 10:03 AM, Murray S. Kucherawy wrote: > We’re putting the finishing touches on draft-ietf-appsawg-media-type-regs and > draft-ietf-appsawg-mime-charset-default will complete WGLC this week. In the > mix now (by virtue of a reference from the former) is > draft-hansen-media-type-suffix-regs, and so we’d like to adopt it as a WG document. > > > > Please indicate your support or objection, and opinions thereto. +1 to adopt. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Mon Apr 16 10:56: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 5CA7411E80CE for ; Mon, 16 Apr 2012 10:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.645 X-Spam-Level: X-Spam-Status: No, score=-102.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssU+WfzshDIH for ; Mon, 16 Apr 2012 10:56:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DC16A11E80A6 for ; Mon, 16 Apr 2012 10:55:47 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0F7284005B; Mon, 16 Apr 2012 12:09:54 -0600 (MDT) Message-ID: <4F8C5D22.7050309@stpeter.im> Date: Mon, 16 Apr 2012 11:55:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 17:56:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/13/12 11:45 AM, Murray S. Kucherawy wrote: >> -----Original Message----- From: apps-discuss-bounces@ietf.org >> [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Stephen >> Farrell Sent: Friday, April 13, 2012 9:23 AM To: oauth@ietf.org >> WG Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web >> Finger vs. Simple Web Discovery (SWD) >> >> So Hannes and Derek and I have been discussing this with the Apps >> ADs and Apps-area WG chairs. I've also read the docs now, and >> after all that we've decided that this topic (what to do with swd >> and webfinger) is best handled in the apps area and not in the >> oauth WG. >> >> The logic for that is that 1) the two proposals are doing the >> same thing and we don't want two different standards for that, b) >> this is not an oauth-specific thing nor is it a general security >> thing, and c) there is clearly already interest in the topic in >> the apps area so its reasonable for the oauth wg to use that when >> its ready. >> >> The appsawg chairs and apps ADs are ok with the work being done >> there. >> >> So:- >> >> - I've asked the oauth chairs to take doing work on swd out of >> the proposed new charter - It may be that you want to add >> something saying that oauth will use the results of work in the >> applications area on a web discovery protocol as a basis for >> doing the dynamic client registration work here - Discussion of >> webfinger and swd should move over to the apps-discuss list - >> Note: this is not picking one or the other approach, the plan is >> that the apps area will do any selection needed and figure out >> the best starting point for a standards-track RFC on web >> discovery and we'll use their fine work for doing more with >> oauth. > > Thank you Stephen, I think. :-) > > So the discussion on apps-discuss now should be focused on which of > the two should be the basis for forward progress. I've placed both > documents in "Call for Adoption" state in the datatracker for > appsawg. > > Let the games begin. I've just had a chance to review both I-Ds: https://datatracker.ietf.org/doc/draft-jones-appsawg-webfinger/ (-03) http://datatracker.ietf.org/doc/draft-jones-simple-web-discovery/ (-02) Although at a later time I will provide more detailed feedback, I am left wondering why Simple Web Discovery was developed. It appears to solve the same problem as WebFinger (which predates SWD by several years as far as I can see) in similar ways (/.well-known/ etc.), with a few tweaks and optimizations (some of which might be premature IMHO). Thus I think it would be helpful for the authors of SWD to explain why they didn't use WebFinger, or provide feedback that would improve WebFinger if it didn't address some of their use cases (I note that the more recent WebFinger I-Ds include some SWD-ish features, such as the "resource" parameter -- whether that is a good thing remains to be determined). Although draft-jones-simple-web-discovery does not contain such an analysis, perhaps someone posted it to the OAUTH WG list or elsewhere, in which case I apologize for having missed it. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+MXSIACgkQNL8k5A2w/vzR4ACffCIM6A/RBj/y6RdyiudN+AF2 deMAoKmuesVvyS8yYVb0sqYXqCJnQF8+ =3OKr -----END PGP SIGNATURE----- From melvincarvalho@gmail.com Mon Apr 16 11:00: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 DBE4121F85CE for ; Mon, 16 Apr 2012 11:00:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPW5VD66l1+e for ; Mon, 16 Apr 2012 11:00:23 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38C3F21F85CC for ; Mon, 16 Apr 2012 11:00:15 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4210981vbb.31 for ; Mon, 16 Apr 2012 11:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b6q3SFGdgoXzW2ynCxV9smNstuf7QYTOdsVWyDHJ70M=; b=BcNqiMQKIWOLrRtQuT+nkJxUall/tvH/Sw5zUkueOxW2OWRTQ1PC3s4lBk8bjfSnc3 QCkLEpb3LnPGIaOwtUtW6Kvbshj29D5LrOjpgqQLmvgVCqqrsMX0u26W1giqMwamFjXH zaaUExPYK3TmohPvKzDvA/pjzDDtDV3j8f5fZPogR0o13ujWBkqEuoYkOYEUrrnTvWOp 4Nl4UCDBB7FIm3mavfagIxC9yhfU7NvidQc1LZZxmhB6e9l8XHEoX7J96iyqTW4sAP58 rqRUoLFL/LYD70zN6Ueci65ZXLcdaWD5mkTT3/Vs16yn8ZVpE8xUnnUVbhB7PtGyhYcH SarQ== MIME-Version: 1.0 Received: by 10.220.57.205 with SMTP id d13mr6447402vch.53.1334599214610; Mon, 16 Apr 2012 11:00:14 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Mon, 16 Apr 2012 11:00:14 -0700 (PDT) In-Reply-To: <4F8C5D22.7050309@stpeter.im> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> Date: Mon, 16 Apr 2012 20:00:14 +0200 Message-ID: From: Melvin Carvalho To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=00235445b9221ab86204bdcf98bc Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 18:00:25 -0000 --00235445b9221ab86204bdcf98bc Content-Type: text/plain; charset=ISO-8859-1 On 16 April 2012 19:55, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 4/13/12 11:45 AM, Murray S. Kucherawy wrote: > >> -----Original Message----- From: apps-discuss-bounces@ietf.org > >> [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Stephen > >> Farrell Sent: Friday, April 13, 2012 9:23 AM To: oauth@ietf.org > >> WG Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web > >> Finger vs. Simple Web Discovery (SWD) > >> > >> So Hannes and Derek and I have been discussing this with the Apps > >> ADs and Apps-area WG chairs. I've also read the docs now, and > >> after all that we've decided that this topic (what to do with swd > >> and webfinger) is best handled in the apps area and not in the > >> oauth WG. > >> > >> The logic for that is that 1) the two proposals are doing the > >> same thing and we don't want two different standards for that, b) > >> this is not an oauth-specific thing nor is it a general security > >> thing, and c) there is clearly already interest in the topic in > >> the apps area so its reasonable for the oauth wg to use that when > >> its ready. > >> > >> The appsawg chairs and apps ADs are ok with the work being done > >> there. > >> > >> So:- > >> > >> - I've asked the oauth chairs to take doing work on swd out of > >> the proposed new charter - It may be that you want to add > >> something saying that oauth will use the results of work in the > >> applications area on a web discovery protocol as a basis for > >> doing the dynamic client registration work here - Discussion of > >> webfinger and swd should move over to the apps-discuss list - > >> Note: this is not picking one or the other approach, the plan is > >> that the apps area will do any selection needed and figure out > >> the best starting point for a standards-track RFC on web > >> discovery and we'll use their fine work for doing more with > >> oauth. > > > > Thank you Stephen, I think. :-) > > > > So the discussion on apps-discuss now should be focused on which of > > the two should be the basis for forward progress. I've placed both > > documents in "Call for Adoption" state in the datatracker for > > appsawg. > > > > Let the games begin. > > I've just had a chance to review both I-Ds: > > https://datatracker.ietf.org/doc/draft-jones-appsawg-webfinger/ (-03) > > http://datatracker.ietf.org/doc/draft-jones-simple-web-discovery/ (-02) > > Although at a later time I will provide more detailed feedback, I am > left wondering why Simple Web Discovery was developed. It appears to > solve the same problem as WebFinger (which predates SWD by several > years as far as I can see) in similar ways (/.well-known/ etc.), with > a few tweaks and optimizations (some of which might be premature IMHO). > > Thus I think it would be helpful for the authors of SWD to explain why > they didn't use WebFinger, or provide feedback that would improve > WebFinger if it didn't address some of their use cases (I note that > the more recent WebFinger I-Ds include some SWD-ish features, such as > the "resource" parameter -- whether that is a good thing remains to be > determined). Although draft-jones-simple-web-discovery does not > contain such an analysis, perhaps someone posted it to the OAUTH WG > list or elsewhere, in which case I apologize for having missed it. > +1 > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk+MXSIACgkQNL8k5A2w/vzR4ACffCIM6A/RBj/y6RdyiudN+AF2 > deMAoKmuesVvyS8yYVb0sqYXqCJnQF8+ > =3OKr > -----END PGP SIGNATURE----- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --00235445b9221ab86204bdcf98bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 16 April 2012 19:55, Peter Saint-Andr= e <stpeter@stpet= er.im> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/13/12 11:45 AM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: apps-discuss-bounces@ietf.org
>> [mailto:apps-disc= uss-bounces@ietf.org] On Behalf Of Stephen
>> Farrell Sent: Friday, April 13, 2012 9:23 AM To: oauth@ietf.org
>> WG Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web
>> Finger vs. Simple Web Discovery (SWD)
>>
>> So Hannes and Derek and I have been discussing this with the Apps<= br> >> ADs and Apps-area WG chairs. I've also read the docs now, and<= br> >> after all that we've decided that this topic (what to do with = swd
>> and webfinger) is best handled in the apps area and not in the
>> oauth WG.
>>
>> The logic for that is that 1) the two proposals are doing the
>> same thing and we don't want two different standards for that,= b)
>> this is not an oauth-specific thing nor is it a general security >> thing, and c) there is clearly already interest in the topic in >> the apps area so its reasonable for the oauth wg to use that when<= br> >> its ready.
>>
>> The appsawg chairs and apps ADs are ok with the work being done >> there.
>>
>> So:-
>>
>> - I've asked the oauth chairs to take doing work on swd out of=
>> the proposed new charter - It may be that you want to add
>> something saying that oauth will use the results of work in the >> applications area on a web discovery protocol as a basis for
>> doing the dynamic client registration work here - Discussion of >> webfinger and swd should move over to the apps-discuss list -
>> Note: this is not picking one or the other approach, the plan is >> that the apps area will do any selection needed and figure out
>> the best starting point for a standards-track RFC on web
>> discovery and we'll use their fine work for doing more with >> oauth.
>
> Thank you Stephen, I think. =A0:-)
>
> So the discussion on apps-discuss now should be focused on which of > the two should be the basis for forward progress. =A0I've placed b= oth
> documents in "Call for Adoption" state in the datatracker fo= r
> appsawg.
>
> Let the games begin.

I've just had a chance to review both I-Ds:

https://datatracker.ietf.org/doc/draft-jones-appsawg-web= finger/ (-03)

http://datatracker.ietf.org/doc/draft-jones-simple-web= -discovery/ (-02)

Although at a later time I will provide more detailed feedback, I am
left wondering why Simple Web Discovery was developed. It appears to
solve the same problem as WebFinger (which predates SWD by several
years as far as I can see) in similar ways (/.well-known/ etc.), with
a few tweaks and optimizations (some of which might be premature IMHO).

Thus I think it would be helpful for the authors of SWD to explain why
they didn't use WebFinger, or provide feedback that would improve
WebFinger if it didn't address some of their use cases (I note that
the more recent WebFinger I-Ds include some SWD-ish features, such as
the "resource" parameter -- whether that is a good thing remains = to be
determined). Although draft-jones-simple-web-discovery does not
contain such an analysis, perhaps someone posted it to the OAUTH WG
list or elsewhere, in which case I apologize for having missed it.

+1


Peter

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

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

iEYEARECAAYFAk+MXSIACgkQNL8k5A2w/vzR4ACffCIM6A/RBj/y6RdyiudN+AF2
deMAoKmuesVvyS8yYVb0sqYXqCJnQF8+
=3D3OKr
-----END PGP SIGNATURE-----
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--00235445b9221ab86204bdcf98bc-- From bobwyman@gmail.com Mon Apr 16 11:45:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8190311E80A6 for ; Mon, 16 Apr 2012 11:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eZe3fokFnEF for ; Mon, 16 Apr 2012 11:45:26 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE0E11E80A4 for ; Mon, 16 Apr 2012 11:45:26 -0700 (PDT) Received: by qaea16 with SMTP id a16so3818600qae.10 for ; Mon, 16 Apr 2012 11:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bD8MdVMEpUkMd4fhwfwjkW5b9V8ByFvwpCtr43ZE0ls=; b=0m+eVpV7FkCThs+re6taa1cj8ius6exwdkpdFEdYHxFRwLsdxXjjbkqdVm4puk49nz JsKHCpzTvhs0mUOBqRWPQRJTeQKK5WCY4AoRIW/+x/W2e0FNe/pTe+w0od1QsxbJSNqf r8+ovJxWYN/BN5rkqiQ1eDmb4zaMc++cruIBPymXbBvafn4f128J4HHZ0pM9ZnsUNhvV cUrfjey3u7M9POEG/73je07N8oURtjpjG9w8NI40BreZ+2LyDFq99RAmf916WRMcda1A QAqAVVbwRekBtHf4rDJ7OSaqPqp1cNDWLQjvl9t8EcQXJSl5dQNaq74A2zvQXd7Wxjup uiyA== MIME-Version: 1.0 Received: by 10.224.174.143 with SMTP id t15mr16622027qaz.79.1334601925574; Mon, 16 Apr 2012 11:45:25 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.12.194 with HTTP; Mon, 16 Apr 2012 11:45:25 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664673CC@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943664673CC@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 16 Apr 2012 14:45:25 -0400 X-Google-Sender-Auth: pQ3joEMF6081SeRFMWJ9p4VcUOU Message-ID: From: Bob Wyman To: Mike Jones Content-Type: multipart/alternative; boundary=485b397dd665b0c23b04bdd039b1 Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 18:45:28 -0000 --485b397dd665b0c23b04bdd039b1 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 13, 2012 at 7:34 PM, Mike Jones wrote: > Thanks for the questions Hannes, and for your note, Stephen. In > response, I'll first provide a brief feature comparison of Simple Web > Discovery and WebFinger, answer your questions, and then make some closing > remarks. I'd also suggest that people read > http://www.goland.org/simplewebfinger/ and > http://www.goland.org/managingfingerservice/ for background on the > motivations for the choices in the Simple Web Discovery (SWD) protocol. > > FEATURE COMPARISON > > RESULT GRANULARITY AND PRIVACY CHARACTERISTICS: SWD returns the resource > location(s) for a specific resource for a specific principal. As described > in the current spec, WebFinger appears to return all resources for the > principal, by default. The example at > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2"Retrieving a Person's Contact Information" is telling. As described, > WebFinger usage model seems to be "I'll get everything about you and then > look through it to decide what to do with it." The assumption that > WebFinger information is normally public also appears to be built into the > protocol where the CORS response header "Access-Control-Allow-Origin: *" is > mandated, per > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-7. > The default privacy characteristics of these approaches appear to be > different. (It's these very same privacy characteristics that led > sysadmins to nearly ubiquitously disabling the fingerd service!) > > SWD intentionally supports different permissioning on different resources > for particular principals by reusing existing Internet mechanisms - > specifically depending upon whether and how the requester is authenticated, > different discovery requests may or may not be granted. (In a recent OAuth > thread, Blaine Cook pointed out that the set of resources returned by > WebFinger could be filtered using the same mechanisms, which is true. If > that's the intent, I believe that should be made explicit in the WebFinger > document. And yes, we should make the intention to use Internet > authentication mechanisms explicit in the SWD draft as well.) > > DOCUMENT VERSUS API MODEL, DEPLOYABILITY: WebFinger is built on a > "document model", where a single document is returned that contains > multiple resources for a principal. SWD is built on an "API model", where > the location(s) of a particular resource for a principal are returned. One of the nice things about WebFinger is that it can return, in a single response, "all that is known" about a particular entity or principle -- whether or not the requester anticipated that some link might exist. But, it seems to me that with SWD, one needs to anticipate what is available and, if you want to know many things, you need to issue many requests. But, even if you do issue many requests, you might not get "all that is known." This means that there is some serendipity lost... As a developer I don't have the opportunity to notice that some particular kind of link is appearing in WebFinger documents and then going through the discovery process of figuring out what the new stuff is. Thus, I would expect that the pace of innovation would be lower in an SWD based world than in one that relies on WebFinger. One might "fix" this aspect of SWD by defining an "all that is known" service that returns lots of data, but if you did, you would have basically re-invented WebFinger... > The problem with the document model is that different parties or services > may be authoritative for different resources for a given principal, and yet > all need the rights to edit or provide portions of the resulting document. > This can hurt deployability, because document edits then need to be > coordinated among parties that may have different rights and > responsibilities. (Just because I can change your avatar doesn't mean that > I should be able to change your mail server.) > > In a recent OAuth thread, Blaine Cook responded to this characterization > by pointing out that the document model and the resource model are > isomorphic, since Web documents can be and often are dynamically composed, > which is certainly true. If a document model is adopted that can return > multiple resources, with different parties having different permissions to > write to those resources, that effectively forces these documents to be > dynamically composed by a service, for security and privacy reasons. Of > course that's doable, but seems less straight-forward to me. > > REDIRECT FUNCTIONALITY AND DEPLOYABILTY: SWD includes the ability to > redirect some or all SWD requests to another location (possibly depending > upon the specific resource and principal parameters). Deployers hosting > numerous sites for others told the SWD authors that this functionality is > critical for deployability, as it means that the SWD server for a domain > can live in a location outside the domain. > > In the recent OAuth thread, Blaine Cook pointed out that WebFinger can > accomplish this functionality through a different means - by having the > result returned from the first host-meta query direct the second query > another server. As such, I now believe both proposals can accomplish this > goal. > > NUMBER OF ROUND TRIPS: WebFinger discoveries for user information > normally require both a host-meta query to retrieve the template and then a > second query to retrieve the user's information. This functionality is > achieved in a single SWD query. > > In the recent OAuth thread, Blaine Cook argued that caching the first > query result is likely to eliminate the first round trip in many cases. > That's very likely the case for multi-user and multi-tenant service > deployments, but I suspect it's of little help to clients on personal > devices, such as smart phones, using a high-latency channel, when UI > response times are latency-dependent, and when most discoveries ARE > first-time discoveries. > > XML AND JSON VERSUS JSON: WebFinger specifies both XML and JSON support, > whereas SWD specifies only JSON. I believe that it's simpler to specify > only one way of doing the same thing, with JSON being chosen because it's > simpler for developers to use than XML (the same decision as made for the > OAuth specs, for what it's worth). > > DEFINING SPECIFIC RESOURCES: Besides specifying a discovery protocol, > WebFinger also defines specific resources and kinds of resources to be used > with that protocol: the "acct" URI scheme and the "acct" Link Relation. > I'm happy to have these be considered on their own merits, but I believe > that logically, they should be decoupled from the discovery protocol into a > different document or documents. > > HANNES' QUESTIONS > > 1) Aren't these two mechanisms solving pretty much the same problem? > > They are solving an overlapping set of problems, but with somewhat > different mechanisms and characteristics. > > 2) Do we need to have two standards for the same functionality? > > I believe there's consensus that a single standard should suffice > and is preferable. > > 3) Do you guys have a position or comments regarding either one of them? > > I believe that SWD is a simpler and reasonable base to start with > for standardization. > > CLOSING > > I'll close by saying that I believe the authors of both proposals believe > that this work is incredibly important for the Internet and we share the > goals of making the resulting solution as simple, as deployable, and as > ubiquitously adopted as possible and of producing it in a timely manner. I > look forward to working with them and the rest of the working group to make > that happen. > > -- Mike > > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of Stephen Farrell > Sent: Friday, April 13, 2012 9:23 AM > To: oauth@ietf.org WG > Cc: Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > > Hi All, > > So Hannes and Derek and I have been discussing this with the Apps ADs and > Apps-area WG chairs. I've also read the docs now, and after all that we've > decided that this topic (what to do with swd and webfinger) is best handled > in the apps area and not in the oauth WG. > > The logic for that is that 1) the two proposals are doing the same thing > and we don't want two different standards for that, b) this is not an > oauth-specific thing nor is it a general security thing, and c) there is > clearly already interest in the topic in the apps area so its reasonable > for the oauth wg to use that when its ready. > > The appsawg chairs and apps ADs are ok with the work being done there. > > So:- > > - I've asked the oauth chairs to take doing work on swd > out of the proposed new charter > - It may be that you want to add something saying that > oauth will use the results of work in the applications > area on a web discovery protocol as a basis for doing > the dynamic client registration work here > - Discussion of webfinger and swd should move over to > the apps-discuss list > - Note: this is not picking one or the other approach, > the plan is that the apps area will do any selection > needed and figure out the best starting point for a > standards-track RFC on web discovery and we'll use their > fine work for doing more with oauth. > > Regards, > Stephen. > > On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: > > Hi all, > > > > those who had attended the last IETF meeting may have noticed the > ongoing activity in the 'Applications Area Working Group' regarding Web > Finger. > > We had our discussion regarding Simple Web Discovery (SWD) as part of > the re-chartering process. > > > > Here are the two specifications: > > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 > > http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 > > > > Now, the questions that seems to be hanging around are > > > > 1) Aren't these two mechanisms solving pretty much the same problem? > > 2) Do we need to have two standards for the same functionality? > > 3) Do you guys have a position or comments regarding either one of them? > > > > Ciao > > Hannes > > > > PS: Please also let me know if your view is: "I don't really know what > all this is about and the documents actually don't provide enough > requirements to make a reasonable judgement about the solution space." > > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > 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 > --485b397dd665b0c23b04bdd039b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 13, 2012 at 7:34 PM, Mike Jo= nes <Mi= chael.Jones@microsoft.com> wrote:
Thanks for the questions Hannes, and for your note, Stephen. =A0 In respons= e, I'll first provide a brief feature comparison of Simple Web Discover= y and WebFinger, answer your questions, and then make some closing remarks.= =A0I'd also suggest that people read http://www.goland.org/simplewebfinger/<= /a> and http://www.goland.org/managingfingerservice/ for background on = the motivations for the choices in the Simple Web Discovery (SWD) protocol.=

FEATURE COMPARISON

RESULT GRANULARITY AND PRIVACY CHARACTERISTICS: =A0SWD returns the resource= location(s) for a specific resource for a specific principal. =A0As descri= bed in the current spec, WebFinger appears to return all resources for the = principal, by default. =A0The example at http://= tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2 "= Retrieving a Person's Contact Information" is telling. =A0As descr= ibed, WebFinger usage model seems to be "I'll get everything about= you and then look through it to decide what to do with it." =A0The as= sumption that WebFinger information is normally public also appears to be b= uilt into the protocol where the CORS response header "Access-Control-= Allow-Origin: *" is mandated, per http://tool= s.ietf.org/html/draft-jones-appsawg-webfinger-03#section-7. =A0The defa= ult privacy characteristics of these approaches appear to be different. =A0= (It's these very same privacy characteristics that led sysadmins to nea= rly ubiquitously disabling the fingerd service!)

SWD intentionally supports different permissioning on different resources f= or particular principals by reusing existing Internet mechanisms - specific= ally depending upon whether and how the requester is authenticated, differe= nt discovery requests may or may not be granted. =A0(In a recent OAuth thre= ad, Blaine Cook pointed out that the set of resources returned by WebFinger= could be filtered using the same mechanisms, which is true. =A0If that'= ;s the intent, I believe that should be made explicit in the WebFinger docu= ment. =A0And yes, we should make the intention to use Internet authenticati= on mechanisms explicit in the SWD draft as well.)

DOCUMENT VERSUS API MODEL, DEPLOYABILITY: =A0WebFinger is built on a "= document model", where a single document is returned that contains mul= tiple resources for a principal. =A0SWD is built on an "API model"= ;, where the location(s) of a particular resource for a principal are retur= ned.

One of the nice things about WebFinger is that it can r= eturn, in a single response, "all that is known" about a particul= ar entity or principle -- whether or not the requester anticipated that som= e link might exist. But, it seems to me that with SWD, one needs to anticip= ate what is available and, if you want to know many things, you need to iss= ue many requests. But, even if you do issue many requests, you might not ge= t "all that is known." This means that there is some serendipity = lost... As a developer I don't have the opportunity to notice that some= particular kind of link is appearing in WebFinger documents and then going= through the discovery process of figuring out what the new stuff is. Thus,= I would expect that the pace of innovation would be lower in an SWD based = world than in one that relies on WebFinger.

One might "fix" this aspect of SWD by definin= g an "all that is known" service that returns lots of data, but i= f you did, you would have basically re-invented WebFinger...
=A0
=A0The problem with the document m= odel is that different parties or services may be authoritative for differe= nt resources for a given principal, and yet all need the rights to edit or = provide portions of the resulting document. =A0This can hurt deployability,= because document edits then need to be coordinated among parties that may = have different rights and responsibilities. =A0(Just because I can change y= our avatar doesn't mean that I should be able to change your mail serve= r.)

In a recent OAuth thread, Blaine Cook responded to this characterization by= pointing out that the document model and the resource model are isomorphic= , since Web documents can be and often are dynamically composed, which is c= ertainly true. =A0If a document model is adopted that can return multiple r= esources, with different parties having different permissions to write to t= hose resources, that effectively forces these documents to be dynamically c= omposed by a service, for security and privacy reasons. =A0Of course that&#= 39;s doable, but seems less straight-forward to me.

REDIRECT FUNCTIONALITY AND DEPLOYABILTY: =A0SWD includes the ability to red= irect some or all SWD requests to another location (possibly depending upon= the specific resource and principal parameters). =A0Deployers hosting nume= rous sites for others told the SWD authors that this functionality is criti= cal for deployability, as it means that the SWD server for a domain can liv= e in a location outside the domain.

In the recent OAuth thread, Blaine Cook pointed out that WebFinger can acco= mplish this functionality through a different means - by having the result = returned from the first host-meta query =A0direct the second query another = server. =A0As such, I now believe both proposals can accomplish this goal.<= br>
NUMBER OF ROUND TRIPS: =A0WebFinger discoveries for user information normal= ly require both a host-meta query to retrieve the template and then a secon= d query to retrieve the user's information. =A0This functionality is ac= hieved in a single SWD query.

In the recent OAuth thread, Blaine Cook argued that caching the first query= result is likely to eliminate the first round trip in many cases. =A0That&= #39;s very likely the case for multi-user and multi-tenant service deployme= nts, but I suspect it's of little help to clients on personal devices, = such as smart phones, using a high-latency channel, when UI response times = are latency-dependent, and when most discoveries ARE first-time discoveries= .

XML AND JSON VERSUS JSON: =A0WebFinger specifies both XML and JSON support,= whereas SWD specifies only JSON. =A0I believe that it's simpler to spe= cify only one way of doing the same thing, with JSON being chosen because i= t's simpler for developers to use than XML (the same decision as made f= or the OAuth specs, for what it's worth).

DEFINING SPECIFIC RESOURCES: =A0Besides specifying a discovery protocol, We= bFinger also defines specific resources and kinds of resources to be used w= ith that protocol: =A0the "acct" URI scheme and the "acct&qu= ot; Link Relation. =A0I'm happy to have these be considered on their ow= n merits, but I believe that logically, they should be decoupled from the d= iscovery protocol into a different document or documents.

HANNES' QUESTIONS

1) Aren't these two mechanisms solving pretty much the same problem?
=A0 =A0 =A0 =A0They are solving an overlapping set of problems, but = with somewhat different mechanisms and characteristics.

2) Do we need to have two standards for the same functionality?

=A0 =A0 =A0 =A0I believe there's consensus that a single standar= d should suffice and is preferable.

3) Do you guys have a position or comments regarding either one of them?
=A0 =A0 =A0 =A0I believe that SWD is a simpler and reasonable base t= o start with for standardization.

CLOSING

I'll close by saying that I believe the authors of both proposals belie= ve that this work is incredibly important for the Internet and we share the= goals of making the resulting solution as simple, as deployable, and as ub= iquitously adopted as possible and of producing it in a timely manner. =A0I= look forward to working with them and the rest of the working group to mak= e that happen.

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

-----Original Message-----
From: apps-discuss-bounces= @ietf.org [mailto:apps= -discuss-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Friday, April 13, 2012 9:23 AM
To: oauth@ietf.org WG
Cc: Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)


Hi All,

So Hannes and Derek and I have been discussing this with the Apps ADs and A= pps-area WG chairs. I've also read the docs now, and after all that we&= #39;ve decided that this topic (what to do with swd and webfinger) is best = handled in the apps area and not in the oauth WG.

The logic for that is that 1) the two proposals are doing the same thing an= d we don't want two different standards for that, b) this is not an oau= th-specific thing nor is it a general security thing, and c) there is clear= ly already interest in the topic in the apps area so its reasonable for the= oauth wg to use that when its ready.

The appsawg chairs and apps ADs are ok with the work being done there.

So:-

- I've asked the oauth chairs to take doing work on swd
=A0out of the proposed new charter
- It may be that you want to add something saying that
=A0oauth will use the results of work in the applications
=A0area on a web discovery protocol as a basis for doing
=A0the dynamic client registration work here
- Discussion of webfinger and swd should move over to
=A0the apps-discuss list
- Note: this is not picking one or the other approach,
=A0the plan is that the apps area will do any selection
=A0needed and figure out the best starting point for a
=A0standards-track RFC on web discovery and we'll use their
=A0fine work for doing more with oauth.

Regards,
Stephen.

On 04/12/2012 12:00 PM, Hannes Tschofenig wrote:
> Hi all,
>
> those who had attended the last IETF meeting may have noticed the ongo= ing activity in the 'Applications Area Working Group' regarding Web= Finger.
> We had our discussion regarding Simple Web Discovery (SWD) as part of = the re-chartering process.
>
> Here are the two specifications:
> http://tools.ietf.org/html/draft-jones-appsawg-webfinge= r-03
> http://tools.ietf.org/html/draft-jones-simple-web-di= scovery-02
>
> Now, the questions that seems to be hanging around are
>
> =A01) Aren't these two mechanisms solving pretty much the same pro= blem?
> =A02) Do we need to have two standards for the same functionality?
> =A03) Do you guys have a position or comments regarding either one of = them?
>
> Ciao
> Hannes
>
> PS: Please also let me know if your view is: "I don't really = know what all this is about and the documents actually don't provide en= ough requirements to make a reasonable judgement about the solution space.&= quot;
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_____________________________= __________________
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

--485b397dd665b0c23b04bdd039b1-- From Michael.Jones@microsoft.com Mon Apr 16 13: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 0399D11E808A for ; Mon, 16 Apr 2012 13:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.927 X-Spam-Level: X-Spam-Status: No, score=-3.927 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM2xElBzHIDL for ; Mon, 16 Apr 2012 13:41:46 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDF811E807F for ; Mon, 16 Apr 2012 13:41:45 -0700 (PDT) Received: from mail112-am1-R.bigfish.com (10.3.201.234) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 16 Apr 2012 20:41:44 +0000 Received: from mail112-am1 (localhost [127.0.0.1]) by mail112-am1-R.bigfish.com (Postfix) with ESMTP id B19A51803EE; Mon, 16 Apr 2012 20:41:44 +0000 (UTC) X-SpamScore: -44 X-BigFish: VS-44(zzbb2dI154cP9371I542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail112-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail112-am1 (localhost.localdomain [127.0.0.1]) by mail112-am1 (MessageSwitch) id 1334608902883060_8353; Mon, 16 Apr 2012 20:41:42 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.225]) by mail112-am1.bigfish.com (Postfix) with ESMTP id D379A340050; Mon, 16 Apr 2012 20:41:42 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 16 Apr 2012 20:41:41 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0283.004; Mon, 16 Apr 2012 20:41:40 +0000 From: Mike Jones To: Peter Saint-Andre , "Murray S. Kucherawy" Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNG/pG5uayAf9/8keNXPmuJBkS0pad6Z+g Date: Mon, 16 Apr 2012 20:41:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> In-Reply-To: <4F8C5D22.7050309@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 20:41:47 -0000 You can read a lot of the rationale for why Simple Web Discovery was develo= ped in these posts: http://www.goland.org/simplewebfinger/ http://www.goland.org/managingfingerservice/ BTW, I'll point out that Stephen requested that we move this discussion to = the Apps Discuss list, so while I'm replying here, people should follow up = there. (Although I'll warn you, the traffic volume there is fierce - even = compared to the OAuth list at its high water marks.) -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Peter Saint-Andre Sent: Monday, April 16, 2012 10:56 AM To: Murray S. Kucherawy Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/13/12 11:45 AM, Murray S. Kucherawy wrote: >> -----Original Message----- From: apps-discuss-bounces@ietf.org=20 >> [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Stephen Farrell=20 >> Sent: Friday, April 13, 2012 9:23 AM To: oauth@ietf.org WG Cc: Apps=20 >> Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple=20 >> Web Discovery (SWD) >>=20 >> So Hannes and Derek and I have been discussing this with the Apps ADs=20 >> and Apps-area WG chairs. I've also read the docs now, and after all=20 >> that we've decided that this topic (what to do with swd and=20 >> webfinger) is best handled in the apps area and not in the oauth WG. >>=20 >> The logic for that is that 1) the two proposals are doing the same=20 >> thing and we don't want two different standards for that, b) this is=20 >> not an oauth-specific thing nor is it a general security thing, and=20 >> c) there is clearly already interest in the topic in the apps area so=20 >> its reasonable for the oauth wg to use that when its ready. >>=20 >> The appsawg chairs and apps ADs are ok with the work being done=20 >> there. >>=20 >> So:- >>=20 >> - I've asked the oauth chairs to take doing work on swd out of the=20 >> proposed new charter - It may be that you want to add something=20 >> saying that oauth will use the results of work in the applications=20 >> area on a web discovery protocol as a basis for doing the dynamic=20 >> client registration work here - Discussion of webfinger and swd=20 >> should move over to the apps-discuss list - >> Note: this is not picking one or the other approach, the plan is that=20 >> the apps area will do any selection needed and figure out the best=20 >> starting point for a standards-track RFC on web discovery and we'll=20 >> use their fine work for doing more with oauth. >=20 > Thank you Stephen, I think. :-) >=20 > So the discussion on apps-discuss now should be focused on which of=20 > the two should be the basis for forward progress. I've placed both=20 > documents in "Call for Adoption" state in the datatracker for appsawg. >=20 > Let the games begin. I've just had a chance to review both I-Ds: https://datatracker.ietf.org/doc/draft-jones-appsawg-webfinger/ (-03) http://datatracker.ietf.org/doc/draft-jones-simple-web-discovery/ (-02) Although at a later time I will provide more detailed feedback, I am left w= ondering why Simple Web Discovery was developed. It appears to solve the sa= me problem as WebFinger (which predates SWD by several years as far as I ca= n see) in similar ways (/.well-known/ etc.), with a few tweaks and optimiza= tions (some of which might be premature IMHO). Thus I think it would be helpful for the authors of SWD to explain why they= didn't use WebFinger, or provide feedback that would improve WebFinger if = it didn't address some of their use cases (I note that the more recent WebF= inger I-Ds include some SWD-ish features, such as the "resource" parameter = -- whether that is a good thing remains to be determined). Although draft-j= ones-simple-web-discovery does not contain such an analysis, perhaps someon= e posted it to the OAUTH WG list or elsewhere, in which case I apologize fo= r having missed it. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+MXSIACgkQNL8k5A2w/vzR4ACffCIM6A/RBj/y6RdyiudN+AF2 deMAoKmuesVvyS8yYVb0sqYXqCJnQF8+ =3D3OKr -----END PGP SIGNATURE----- _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From stpeter@stpeter.im Mon Apr 16 13:44: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 501C121F857A for ; Mon, 16 Apr 2012 13:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.643 X-Spam-Level: X-Spam-Status: No, score=-102.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wncY4whL+bWD for ; Mon, 16 Apr 2012 13:44:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C840221F8577 for ; Mon, 16 Apr 2012 13:44:27 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2B3BA40058; Mon, 16 Apr 2012 14:58:35 -0600 (MDT) Message-ID: <4F8C84AA.1010009@stpeter.im> Date: Mon, 16 Apr 2012 14:44:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Mike Jones References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 20:44:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/16/12 2:41 PM, Mike Jones wrote: > You can read a lot of the rationale for why Simple Web Discovery > was developed in these posts: > http://www.goland.org/simplewebfinger/ > http://www.goland.org/managingfingerservice/ Thanks, I'll read those! > BTW, I'll point out that Stephen requested that we move this > discussion to the Apps Discuss list, so while I'm replying here, > people should follow up there. In fact I removed oauth@ietf.org from my message, so it went only to apps-discuss. > (Although I'll warn you, the traffic volume there is fierce - even > compared to the OAuth list at its high water marks.) Clearly you weren't on the hybi list -- that one was truly memorable. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+MhKoACgkQNL8k5A2w/vxakQCgqbR0TvhFYRgpuyTQfeE9FaSZ aNIAoMdCkCk5liZvBUDdSvinJ2VPltMC =Y5kE -----END PGP SIGNATURE----- From eran@hueniverse.com Mon Apr 16 14:57: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 3B8AF21F8622 for ; Mon, 16 Apr 2012 14:57:27 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvGwqtbDsNAx for ; Mon, 16 Apr 2012 14:57:26 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2C26E21F8621 for ; Mon, 16 Apr 2012 14:57:26 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id ylxR1i0020EuLVk01lxREU; Mon, 16 Apr 2012 14:57:25 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Mon, 16 Apr 2012 14:57:25 -0700 From: Eran Hammer To: Stephen Farrell Thread-Topic: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer Thread-Index: AQHNG0lWkXig/AJ3KkK9oC4oFdQOX5ad/8ZQ Date: Mon, 16 Apr 2012 21:57:24 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FEB0E5@P3PWEX2MB008.ex2.secureserver.net> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <4F8B346E.5040300@cs.tcd.ie> In-Reply-To: <4F8B346E.5040300@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pete Resnick , Mark Nottingham , Ned Freed , Apps Discuss , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 21:57:27 -0000 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Sunday, April 15, 2012 1:50 PM > To: Eran Hammer > Cc: Mark Nottingham; Pete Resnick; Ned Freed; draft-ietf-oauth-v2- > bearer.all@tools.ietf.org; Apps Discuss > Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf- > oauth-v2-bearer >=20 >=20 > Hi Eran, >=20 > On 04/15/2012 07:31 AM, Eran Hammer wrote: > > > > > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > >> bounces@ietf.org] On Behalf Of Stephen Farrell > >> Sent: Friday, April 13, 2012 3:36 PM > >> To: Mark Nottingham > >> Cc: Pete Resnick; Ned Freed; > >> draft-ietf-oauth-v2-bearer.all@tools.ietf.org; > >> Apps Discuss > >> Subject: Re: [apps-discuss] Reserved URI query parameter in > >> draft-ietf- oauth-v2-bearer > >> > >> > >> > >> On 04/13/2012 10:24 PM, Mark Nottingham wrote: > >>> Because it's a name space that is managed and owned by the authority > >>> of > >> the URI, not any standards organisation. > >>> > >>> I.e. we tell them how the URI is structured, not what to put into it. > >>> > >>> We made *one* exception for this in .well-known as an escape valve > >>> for > >> abuse. If we continue allowing this kind of abuse, we'll have little > >> defence against things like standardising filename extensions in URLs > >> and reserving an "/about/" URI's semantics -- things which are > >> clearly violating the architecture of the WWW: > >>> http://www.w3.org/TR/webarch/#uri-opacity > >> > >> (Sticking with the naivety:-) So, what's different there from how the > >> base oauth draft registers client_id and shows how that can be used > >> in a GET request? [1] > > > > Big difference. The base draft specifies its own endpoints as part of a > complete API package for obtaining authorization. These parameters are > scoped only for the endpoints defined and not for any others. There is no > possibility of conflict because the specification defines the entire name= space. >=20 > I guess that might be a big difference, not sure. Where is that aspect (a > complete API package) described in the oauth base spec or elsewhere? http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-3 This section defines the two server and one client endpoints required by OA= uth. Those opting to deploy these resources must abide by their syntax whic= h completely defines their URI query parameters. > I also don't recall mention of API packages in the other responses on thi= s > thread, so I'm not sure if that's a wide-spread opinion or if there's > disagreement about it. This should be pretty standard API approach, whereas the full scope of quer= y parameters are defined as a set and are not expect to overlap with any ot= hers on the API resources. By adopting the API, the developer buys into the= namespace definition. However, when using OAuth for authentication of exis= ting API endpoints that have otherwise nothing to do with OAuth, there is a= namespace collision. =20 > > OTOH, the bearer spec is applied to *any* web resources using OAuth > authentication where some other namespace definition must exist. >=20 > Seems like a fair point. But like I said above, I'm unsure if that's just= a matter > of degree or not. (Maybe the base spec is "a little bit pregnant" in this > respect? ;-) This isn't a matter of degree. The basic assumption is that providers suppo= rting OAuth bearer authentication will be required to understand this query= parameter and therefore, cannot use it to avoid any client confusion. EH =20 > S >=20 > > EH > > > >> Ta, > >> S. > >> > >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-25#page-24 > >> (bottom of page) > >> > >> > >>> > >>> Cheers, > >>> > >>> > >>> On 13/04/2012, at 4:20 PM, Stephen Farrell wrote: > >>> > >>>> > >>>> > >>>> On 04/13/2012 08:43 AM, Ned Freed wrote: > >>>>> I certainly don't object to doing that. In fact I don't object to > >>>>> dropping this nasty hack from the document, although perhaps > >>>>> documenting it as *not* standardized and explaining why it sucks > >>>>> would > >> be even better. > >>>> > >>>> So I've a possibly naive question: > >>>> > >>>> Why is it harmful to standardise a parameter name for use in query > >>>> strings? > >>>> > >>>> Note: I'm not asking if access_token is a good or bad name for one > >>>> of those, nor how exactly to standardise one well or badly, nor who > >>>> should do that, but it seems from the comments here that some folks > >>>> are against the idea of standardising anything after the authority > >>>> is a bad idea, and I don't get why exactly that might be the case. > >>>> > >>>> Thanks, > >>>> S. > >>>> > >>> > >>> -- > >>> Mark Nottingham > >>> http://www.mnot.net/ > >>> > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > From Michael.Jones@microsoft.com Mon Apr 16 15:07: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 8F1C911E808A for ; Mon, 16 Apr 2012 15:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.912 X-Spam-Level: X-Spam-Status: No, score=-3.912 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1iGtN5lnqRk for ; Mon, 16 Apr 2012 15:07:37 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5530111E80B6 for ; Mon, 16 Apr 2012 15:07:37 -0700 (PDT) Received: from mail60-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 16 Apr 2012 22:07:36 +0000 Received: from mail60-va3 (localhost [127.0.0.1]) by mail60-va3-R.bigfish.com (Postfix) with ESMTP id DC1106066B; Mon, 16 Apr 2012 22:07:35 +0000 (UTC) X-SpamScore: -37 X-BigFish: VS-37(zzbb2dI9371I542M1432N98dK4015Izz1202hzz8275ch1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail60-va3: 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=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail60-va3 (localhost.localdomain [127.0.0.1]) by mail60-va3 (MessageSwitch) id 1334614053221913_5987; Mon, 16 Apr 2012 22:07:33 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.245]) by mail60-va3.bigfish.com (Postfix) with ESMTP id 2F8FD3A00E2; Mon, 16 Apr 2012 22:07:33 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 16 Apr 2012 22:07:30 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0283.004; Mon, 16 Apr 2012 22:07:11 +0000 From: Mike Jones To: Eran Hammer , Stephen Farrell Thread-Topic: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer Thread-Index: AQHNHBvuMnl7M5Co1kKHc7Fh8opwWpaeAOKw Date: Mon, 16 Apr 2012 22:07:11 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436648789A@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <4F8B346E.5040300@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEB0E5@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FEB0E5@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Pete Resnick , Mark Nottingham , Ned Freed , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 22:07:38 -0000 I'll note that RFC 5849, which defines two such query parameters: oauth_to= ken and oauth_verifier, doesn't seem to have created any problems in practi= ce by doing so. -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Eran Hammer Sent: Monday, April 16, 2012 2:57 PM To: Stephen Farrell Cc: Pete Resnick; Mark Nottingham; Ned Freed; Apps Discuss; draft-ietf-oaut= h-v2-bearer.all@tools.ietf.org Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oaut= h-v2-bearer > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Sunday, April 15, 2012 1:50 PM > To: Eran Hammer > Cc: Mark Nottingham; Pete Resnick; Ned Freed; draft-ietf-oauth-v2-=20 > bearer.all@tools.ietf.org; Apps Discuss > Subject: Re: [apps-discuss] Reserved URI query parameter in=20 > draft-ietf- oauth-v2-bearer >=20 >=20 > Hi Eran, >=20 > On 04/15/2012 07:31 AM, Eran Hammer wrote: > > > > > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-=20 > >> bounces@ietf.org] On Behalf Of Stephen Farrell > >> Sent: Friday, April 13, 2012 3:36 PM > >> To: Mark Nottingham > >> Cc: Pete Resnick; Ned Freed; > >> draft-ietf-oauth-v2-bearer.all@tools.ietf.org; > >> Apps Discuss > >> Subject: Re: [apps-discuss] Reserved URI query parameter in > >> draft-ietf- oauth-v2-bearer > >> > >> > >> > >> On 04/13/2012 10:24 PM, Mark Nottingham wrote: > >>> Because it's a name space that is managed and owned by the=20 > >>> authority of > >> the URI, not any standards organisation. > >>> > >>> I.e. we tell them how the URI is structured, not what to put into it. > >>> > >>> We made *one* exception for this in .well-known as an escape valve=20 > >>> for > >> abuse. If we continue allowing this kind of abuse, we'll have=20 > >> little defence against things like standardising filename=20 > >> extensions in URLs and reserving an "/about/" URI's semantics --=20 > >> things which are clearly violating the architecture of the WWW: > >>> http://www.w3.org/TR/webarch/#uri-opacity > >> > >> (Sticking with the naivety:-) So, what's different there from how=20 > >> the base oauth draft registers client_id and shows how that can be=20 > >> used in a GET request? [1] > > > > Big difference. The base draft specifies its own endpoints as part=20 > > of a > complete API package for obtaining authorization. These parameters are=20 > scoped only for the endpoints defined and not for any others. There is=20 > no possibility of conflict because the specification defines the entire n= amespace. >=20 > I guess that might be a big difference, not sure. Where is that aspect=20 > (a complete API package) described in the oauth base spec or elsewhere? http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-3 This section defines the two server and one client endpoints required by OA= uth. Those opting to deploy these resources must abide by their syntax whic= h completely defines their URI query parameters. > I also don't recall mention of API packages in the other responses on=20 > this thread, so I'm not sure if that's a wide-spread opinion or if=20 > there's disagreement about it. This should be pretty standard API approach, whereas the full scope of quer= y parameters are defined as a set and are not expect to overlap with any ot= hers on the API resources. By adopting the API, the developer buys into the= namespace definition. However, when using OAuth for authentication of exis= ting API endpoints that have otherwise nothing to do with OAuth, there is a= namespace collision. =20 > > OTOH, the bearer spec is applied to *any* web resources using OAuth > authentication where some other namespace definition must exist. >=20 > Seems like a fair point. But like I said above, I'm unsure if that's=20 > just a matter of degree or not. (Maybe the base spec is "a little bit=20 > pregnant" in this respect? ;-) This isn't a matter of degree. The basic assumption is that providers suppo= rting OAuth bearer authentication will be required to understand this query= parameter and therefore, cannot use it to avoid any client confusion. EH =20 > S >=20 > > EH > > > >> Ta, > >> S. > >> > >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-25#page-24 > >> (bottom of page) > >> > >> > >>> > >>> Cheers, > >>> > >>> > >>> On 13/04/2012, at 4:20 PM, Stephen Farrell wrote: > >>> > >>>> > >>>> > >>>> On 04/13/2012 08:43 AM, Ned Freed wrote: > >>>>> I certainly don't object to doing that. In fact I don't object=20 > >>>>> to dropping this nasty hack from the document, although perhaps=20 > >>>>> documenting it as *not* standardized and explaining why it sucks=20 > >>>>> would > >> be even better. > >>>> > >>>> So I've a possibly naive question: > >>>> > >>>> Why is it harmful to standardise a parameter name for use in=20 > >>>> query strings? > >>>> > >>>> Note: I'm not asking if access_token is a good or bad name for=20 > >>>> one of those, nor how exactly to standardise one well or badly,=20 > >>>> nor who should do that, but it seems from the comments here that=20 > >>>> some folks are against the idea of standardising anything after=20 > >>>> the authority is a bad idea, and I don't get why exactly that might = be the case. > >>>> > >>>> Thanks, > >>>> S. > >>>> > >>> > >>> -- > >>> Mark Nottingham > >>> http://www.mnot.net/ > >>> > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From tbray@textuality.com Mon Apr 16 15:33: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 619CA21F85C4 for ; Mon, 16 Apr 2012 15:33:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzxTXidSt8R7 for ; Mon, 16 Apr 2012 15:33:01 -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 8028D21F85C0 for ; Mon, 16 Apr 2012 15:33:01 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so3234367obb.31 for ; Mon, 16 Apr 2012 15:33:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=Jh9eoJumgfbsUh1osrXq8WpUdu6PbdFr+qyHpxHP3S0=; b=SZ2d2sNwFOsmGY/v06Qh0FCQ9/KlinZ15ortlqgUi4VU9HhQH6AplT79pWxls+0WYu A0v4j9wuh7lBZnnjTm8mTZGX3K4fHKIPRYPZkMdgPakpElv4Sp10UO1HRfjfD1ceoVd5 aN6fGD4n1hSQ6aCMQJX4pQL5AssclS8dBwn1ybTWBj/3cV1QbyQWS69wRUBHUrD0J2x5 tJmbDtFegoh1eUzNrw8+hbVJ1jdbZ5p+XA8sjYbhMEj1UQJNtR30eFwFgSLbKIjXc9oJ KATBYpaG5dn5DJLtc+850XvzWsC065yhvONtx/TsfAD8jiN0JSkL4wFnBnDQAoqwgBii YfXw== MIME-Version: 1.0 Received: by 10.182.113.42 with SMTP id iv10mr18448763obb.18.1334615581037; Mon, 16 Apr 2012 15:33:01 -0700 (PDT) Received: by 10.182.29.6 with HTTP; Mon, 16 Apr 2012 15:33:00 -0700 (PDT) X-Originating-IP: [2620:0:1000:2104:a518:3c4a:d054:5bd6] In-Reply-To: <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> Date: Mon, 16 Apr 2012 15:33:00 -0700 Message-ID: From: Tim Bray To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkHwglji8krW6MGMZPoPpmw6ECHFNxTSHC59HS3w8tj3D3y9TB3w8NEiv4ZWtrtuJ4uR8As Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 22:33:02 -0000 What is the deployment status of these two specs? Is either deployed much at all? -T On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy w= rote: >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.or= g] On Behalf Of Stephen Farrell >> Sent: Friday, April 13, 2012 9:23 AM >> To: oauth@ietf.org WG >> Cc: Apps Discuss >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discove= ry (SWD) >> >> So Hannes and Derek and I have been discussing this with the Apps ADs >> and Apps-area WG chairs. I've also read the docs now, and after all >> that we've decided that this topic (what to do with swd and webfinger) >> is best handled in the apps area and not in the oauth WG. >> >> The logic for that is that 1) the two proposals are doing the same >> thing and we don't want two different standards for that, b) this is >> not an oauth-specific thing nor is it a general security thing, and c) >> there is clearly already interest in the topic in the apps area so its >> reasonable for the oauth wg to use that when its ready. >> >> The appsawg chairs and apps ADs are ok with the work being done there. >> >> So:- >> >> - I've asked the oauth chairs to take doing work on swd >> =A0 out of the proposed new charter >> - It may be that you want to add something saying that >> =A0 oauth will use the results of work in the applications >> =A0 area on a web discovery protocol as a basis for doing >> =A0 the dynamic client registration work here >> - Discussion of webfinger and swd should move over to >> =A0 the apps-discuss list >> - Note: this is not picking one or the other approach, >> =A0 the plan is that the apps area will do any selection >> =A0 needed and figure out the best starting point for a >> =A0 standards-track RFC on web discovery and we'll use their >> =A0 fine work for doing more with oauth. > > Thank you Stephen, I think. =A0:-) > > So the discussion on apps-discuss now should be focused on which of the t= wo should be the basis for forward progress. =A0I've placed both documents = in "Call for Adoption" state in the datatracker for appsawg. > > Let the games begin. > > -MSK > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ned.freed@mrochek.com Mon Apr 16 18:17: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 2739521F856C for ; Mon, 16 Apr 2012 18:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlrSZ4jTFVQ4 for ; Mon, 16 Apr 2012 18:17:28 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 173BD21F84EE for ; Mon, 16 Apr 2012 18:17:28 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEE9DYKUZK00YE5X@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 16 Apr 2012 18:17:22 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Mon, 16 Apr 2012 18:17:15 -0700 (PDT) Message-id: <01OEE9DUSD8400ZUIL@mauve.mrochek.com> Date: Mon, 16 Apr 2012 17:53:12 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 16 Apr 2012 09:33:46 +0100" <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> To: Jeni Tennison Cc: Ned Freed , apps-discuss@ietf.org, tony+mtsuffix@maillennium.att.com, Julian Reschke , Noah Mendelsohn , john+ietf@jck.com, "www-tag@w3.org List" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 01:17:29 -0000 > Hi Ned, all, > Here is a set of concrete suggestions for amendments to > draft-ietf-appsawg-media-type-reg that I hope might focus discussion. Basically > they > * create a specific section in the media type registration template for information about fragment identifier processing and provide some high-level guidance about what should go there > * create a section within the structured syntax suffix registration template for discussions of generic processing of fragment identifiers across media types that use that structured syntax This seems very reasonable. > I think there'd then be scope for a separate document that on all the details > about prioritising between overlapping fragment identifier schemes and so on, > but no need for that to be referenced from draft-ietf-appsawg-media-type-reg. I agree. This whole space is messy and guidance would be useful. > Thanks for your consideration, > Jeni > --- > 1. Add a new section 'Fragment Identifier Recommendations' (before the current 4.11 Additional Information) which says: In keeping with the other sections, I'm going to call this "Fragment Identifier Requirements". > Media type registrations SHOULD specify how applications should interpret > fragment identifiers [RFC3986] within the media type. Two issues here. First, a SHOULD means reviewers will have to push back on registrations that don't include fragment identifier specifications. (SHOULD is "MUST unless you have a good reason not to".) That's excessive at this point. Second, "within the media type" doesn't make sense to me. Fragment identifiers can be internal, I guess, but the common uses are external. > Media types SHOULD adopt fragment identifier schemes that are used with > other similar media types, to facilitate content negotiation across them. > In particular, media types that use a named structured syntax with a > registered "+suffix" SHOULD adopt any and all fragment identifier schemes > defined within the structured syntax suffix registration. I expanded on this a little because I think there are a lot of uses besides content negotiation. The final result for this addition is: Media type registrations can specify how applications should interpret fragment identifiers [RFC 3986] associated with the media type. Media types SHOULD adopt fragment identifier schemes that are used with other similar media types, to facilitate access and content negotiation across multiple types. In particular, media types that use a named structured syntax with a registered "+suffix" SHOULD adopt any and all fragment identifier schemes defined within the structured syntax suffix registration. > 2. Remove the last bullet point from the list in 4.11 Additional Information, namely: > o Information about how fragment/anchor identifiers [RFC3986] are > constructed for use in conjunction with this media type. Removed. > 3. In 5.7 Registration Template: > a. Add a section 'Fragment identifier considerations' > b. Remove the entry 'URI fragment/anchor identifier(s):' under Additional information Added a and removed b. > 4. Within 6.2 Structured Syntax Suffix Registration Template add a new section: > Fragment identifier considerations > Generic processing of fragment identifiers for any type employing this > syntax should be described here. Added. I'll wait a day or so for additional comments, then post a revised draft with these changes. I note that this raises the issue of what to do about fragment identifiers in the initial suffix registry document. Fragment identifiers don't really make sense for most of the suffixes defined there. The exceptions I see are +xml and +json. +json seems simple enough - refer to draft-ietf-appsawg-json-pointer-01. +xml is a bigger issue. This is a document to populate the registry; it is not the place to define how fragment identifiers for XML work. But RFC 3023 section 5 seems a bit dated. And waiting for a revision for RFC 3023 when there isn't even an I-D doesn't sound like a good idea. So dated or not, I guess a reference to RFC 3023 is as good as it gets for now. Ned From derhoermi@gmx.net Mon Apr 16 19:09: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 8B4EF11E80F7 for ; Mon, 16 Apr 2012 19:09:08 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsz8aNYw-O9K for ; Mon, 16 Apr 2012 19:09:03 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 486ED11E80A2 for ; Mon, 16 Apr 2012 19:09:02 -0700 (PDT) Received: (qmail invoked by alias); 17 Apr 2012 02:09:01 -0000 Received: from dslb-094-223-198-121.pools.arcor-ip.net (EHLO HIVE) [94.223.198.121] by mail.gmx.net (mp039) with SMTP; 17 Apr 2012 04:09:01 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18nJ89bgIknu5wZRK57hH3I6DGobLik7c2t9VEJ85 InAP1ThdczNj45 From: Bjoern Hoehrmann To: Jeni Tennison Date: Tue, 17 Apr 2012 04:09:12 +0200 Message-ID: <3kjpo79jo1mvg2dtqf19hl5i3lrrfm5eb5@hive.bjoern.hoehrmann.de> References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> In-Reply-To: <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "www-tag@w3.org List" , apps-discuss@ietf.org Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 02:09:08 -0000 * Jeni Tennison wrote: >--- > >1. Add a new section 'Fragment Identifier Recommendations' (before the current 4.11 Additional Information) which says: > > Media type registrations SHOULD specify how applications should interpret > fragment identifiers [RFC3986] within the media type. I don't see how this would affect people who don't care about any frag- ment identifier semantics of their media types other than putting "n/a" in the template. > Media types SHOULD adopt fragment identifier schemes that are used with > other similar media types, to facilitate content negotiation across them. There are no "fragment identifier schemes", that would have to be de- fined, and it's rather unclear what "similar" is. Is XSL FO similar to PDF and should thus allow, say, #page=13? This also does not seem to address a problem that we actually have, people do not register types with very similar yet different "fragment identifier schemes", and if they did so, that would very likely be for good reasons. I also do not agree with the "content negotiation" rationale. > In particular, media types that use a named structured syntax with a > registered "+suffix" SHOULD adopt any and all fragment identifier schemes > defined within the structured syntax suffix registration. This is a layering violation. If the specification for the "+suffix" syntax wants to require "sub-types" to do so then it can. There is no reason to have this as part of the generic registration rules. This would also imply that these "sub-types" have to do something special to meet the requirement, rather than just having this by definition, by virtue of following the "+suffix" convention. I see no reason why the "+suffix" specification would make this SHOULD rather than MUST. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From stpeter@stpeter.im Mon Apr 16 20:00: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 C8C5911E808A for ; Mon, 16 Apr 2012 20:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Fv6w2hOw9qf for ; Mon, 16 Apr 2012 20:00:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 22DD211E8076 for ; Mon, 16 Apr 2012 20:00:26 -0700 (PDT) Received: by stpeter.im (Postfix, from userid 1006) id 5FABD4005B; Mon, 16 Apr 2012 21:14:34 -0600 (MDT) Date: Mon, 16 Apr 2012 21:14:34 -0600 From: Peter Saint-Andre To: Ned Freed Message-ID: <20120417031434.GA6746@stpeter.im> References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01OEE9DUSD8400ZUIL@mauve.mrochek.com> Jabber-ID: stpeter@jabber.org User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: Jeni Tennison , apps-discuss@ietf.org, tony+mtsuffix@maillennium.att.com, Julian Reschke , Noah Mendelsohn , john+ietf@jck.com, "www-tag@w3.org List" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 03:00:26 -0000 On Mon, Apr 16, 2012 at 05:53:12PM -0700, Ned Freed wrote: > > Hi Ned, all, > > > Here is a set of concrete suggestions for amendments to > > draft-ietf-appsawg-media-type-reg that I hope might focus discussion. Basically > > they > > > * create a specific section in the media type registration template for information about fragment identifier processing and provide some high-level guidance about what should go there > > > * create a section within the structured syntax suffix registration template for discussions of generic processing of fragment identifiers across media types that use that structured syntax > > This seems very reasonable. > > > I think there'd then be scope for a separate document that on all the details > > about prioritising between overlapping fragment identifier schemes and so on, > > but no need for that to be referenced from draft-ietf-appsawg-media-type-reg. > > I agree. This whole space is messy and guidance would be useful. > > > Thanks for your consideration, > > > Jeni > > > --- > > > 1. Add a new section 'Fragment Identifier Recommendations' (before the current 4.11 Additional Information) which says: > > In keeping with the other sections, I'm going to call this "Fragment Identifier > Requirements". > > > Media type registrations SHOULD specify how applications should interpret > > fragment identifiers [RFC3986] within the media type. > > Two issues here. First, a SHOULD means reviewers will have to push back on > registrations that don't include fragment identifier specifications. (SHOULD is > "MUST unless you have a good reason not to".) That's excessive at this point. > > Second, "within the media type" doesn't make sense to me. Fragment identifiers > can be internal, I guess, but the common uses are external. > > > Media types SHOULD adopt fragment identifier schemes that are used with > > other similar media types, to facilitate content negotiation across them. > > In particular, media types that use a named structured syntax with a > > registered "+suffix" SHOULD adopt any and all fragment identifier schemes > > defined within the structured syntax suffix registration. > > I expanded on this a little because I think there are a lot of uses besides > content negotiation. The final result for this addition is: > > Media type registrations can specify how applications should interpret > fragment identifiers [RFC 3986] associated with the media type. > > Media types SHOULD adopt fragment identifier schemes that are used with > other similar media types, to facilitate access and content negotiation across > multiple types. In particular, media types that use a named structured syntax > with a registered "+suffix" SHOULD adopt any and all fragment identifier > schemes defined within the structured syntax suffix registration. > > > 2. Remove the last bullet point from the list in 4.11 Additional Information, namely: > > > o Information about how fragment/anchor identifiers [RFC3986] are > > constructed for use in conjunction with this media type. > > Removed. > > > 3. In 5.7 Registration Template: > > > a. Add a section 'Fragment identifier considerations' > > b. Remove the entry 'URI fragment/anchor identifier(s):' under Additional information > > Added a and removed b. > > > 4. Within 6.2 Structured Syntax Suffix Registration Template add a new section: > > > Fragment identifier considerations > > Generic processing of fragment identifiers for any type employing this > > syntax should be described here. > > Added. > > I'll wait a day or so for additional comments, then post a revised draft > with these changes. That all looks good to me. > I note that this raises the issue of what to do about fragment identifiers in > the initial suffix registry document. Fragment identifiers don't really make > sense for most of the suffixes defined there. The exceptions I see are +xml and > +json. +json seems simple enough - refer to draft-ietf-appsawg-json-pointer-01. > > +xml is a bigger issue. This is a document to populate the registry; it is not > the place to define how fragment identifiers for XML work. But RFC 3023 section > 5 seems a bit dated. And waiting for a revision for RFC 3023 when there isn't > even an I-D doesn't sound like a good idea. So dated or not, I guess a > reference to RFC 3023 is as good as it gets for now. Agreed. /psa From ned.freed@mrochek.com Mon Apr 16 22:59: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 F0CD921F84C3 for ; Mon, 16 Apr 2012 22:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Co4B2NqDMkGm for ; Mon, 16 Apr 2012 22:59:26 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9A221F84DF for ; Mon, 16 Apr 2012 22:59:26 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEEJ8KJDY8018VA8@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 16 Apr 2012 22:59:21 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Mon, 16 Apr 2012 22:59:15 -0700 (PDT) Message-id: <01OEEJ8HHY8800ZUIL@mauve.mrochek.com> Date: Mon, 16 Apr 2012 22:56:42 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 16 Apr 2012 16:49:20 +0000" <9452079D1A51524AA5749AD23E0039280F37B9@exch-mbx901.corp.cloudmark.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <4F8C43AC.10005@stpeter.im> <9452079D1A51524AA5749AD23E0039280F37B9@exch-mbx901.corp.cloudmark.com> To: "Murray S. Kucherawy" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 05:59:27 -0000 > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Peter Saint-Andre > > Sent: Monday, April 16, 2012 9:07 AM > > To: Ned Freed > > Cc: Jeni Tennison; apps-discuss@ietf.org; > > tony+mtsuffix@maillennium.att.com; Julian Reschke; Noah Mendelsohn; > > john+ietf@jck.com; www-tag@w3.org List > > Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type > > Specifications and Registration Procedures > > > > > If you want to put this stuff in an RFC, it needs to one that's on the > > > regular standards track. And that means it needs to be in a different > > > document. All you can put in this document are the registration rules > > > for specifying a fragment identifier. Nothing more. > > > > Ned is right: this document defines best practices for *registering* > > media types. We all might want to more clearly specify the syntax and > > semantics of fragment identifiers, but IMHO that's out of scope for the > > registration procedures per se. > I think I agree. Would it be an appropriate path forward to put that into > another document, and then reference that one from this one as an Informative? While it might be helpful to have such a reference, I don't think it's necessary. And given that it's not required, the issue is timing. I don't see much chance such a document can be generated in a reasonable amount of time. Ned From ned.freed@mrochek.com Mon Apr 16 23:16: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 150AC21F85C2 for ; Mon, 16 Apr 2012 23:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69kxjlGXNWOV for ; Mon, 16 Apr 2012 23:16:48 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7B521F844B for ; Mon, 16 Apr 2012 23:16:48 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEEJU42N8000AKGL@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 16 Apr 2012 23:16:43 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Mon, 16 Apr 2012 23:16:38 -0700 (PDT) Message-id: <01OEEJU1A7HY00ZUIL@mauve.mrochek.com> Date: Mon, 16 Apr 2012 23:00:12 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 17 Apr 2012 04:09:12 +0200" <3kjpo79jo1mvg2dtqf19hl5i3lrrfm5eb5@hive.bjoern.hoehrmann.de> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <3kjpo79jo1mvg2dtqf19hl5i3lrrfm5eb5@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann Cc: apps-discuss@ietf.org, "www-tag@w3.org List" , Jeni Tennison Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 06:16:49 -0000 > * Jeni Tennison wrote: > >--- > > > >1. Add a new section 'Fragment Identifier Recommendations' (before the current 4.11 Additional Information) which says: > > > > Media type registrations SHOULD specify how applications should interpret > > fragment identifiers [RFC3986] within the media type. > I don't see how this would affect people who don't care about any frag- > ment identifier semantics of their media types other than putting "n/a" > in the template. n/a is not a specification. This is effectively saying that all media types SHOULD have fragment identifiers. That's unreasonable. > > Media types SHOULD adopt fragment identifier schemes that are used with > > other similar media types, to facilitate content negotiation across them. > There are no "fragment identifier schemes", that would have to be de- > fined, and it's rather unclear what "similar" is. Is XSL FO similar to > PDF and should thus allow, say, #page=13? Fair point. Nevertheless, encouraging some amount of consistency seems like a good idea. It just doesn't rise to the level of a requirement. > This also does not seem to > address a problem that we actually have, people do not register types > with very similar yet different "fragment identifier schemes", and if > they did so, that would very likely be for good reasons. Actually, if the Wikipedia page on these things can be believed, they do. For example, different fragment id syntaxes for "page N" with what appear to be idential semantics seem to exist. > I also do not > agree with the "content negotiation" rationale. I'm by no means familiar with all content negotiation schemes out there, so I wasn't willing to be categorical about that. That said, I agree it definitely isn't the main rationale. As I see it, the main rationale for specifying fragment identifiers associated with a given type is the obvious one: So that it gets implemented consistently and the ids, you know, actually work when you use them. > > In particular, media types that use a named structured syntax with a > > registered "+suffix" SHOULD adopt any and all fragment identifier schemes > > defined within the structured syntax suffix registration. > This is a layering violation. If the specification for the "+suffix" > syntax wants to require "sub-types" to do so then it can. There is no > reason to have this as part of the generic registration rules. This > would also imply that these "sub-types" have to do something special > to meet the requirement, rather than just having this by definition, > by virtue of following the "+suffix" convention. I see no reason why > the "+suffix" specification would make this SHOULD rather than MUST. Another fair point. But the meta-point here is that whatever rules are associated with the suffix need to be followed by types using that suffix. And it's reasonable to state that here. Based on this feedback, I now have (I'm leaving the XML in this time): Media type registrations can specify how applications should interpret fragment identifiers associated with the media type. Media types are encouraged to adopt fragment identifier schemes that are used with semantically similar media types. In particular, media types that use a named structured syntax with a registered "+suffix" MUST follow whatever fragment identifier rules are given in the structured syntax suffix registration. Ned From julian.reschke@gmx.de Tue Apr 17 00: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 244FF11E80A5 for ; Tue, 17 Apr 2012 00:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.94 X-Spam-Level: X-Spam-Status: No, score=-102.94 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0EoT4nnLZ+9 for ; Tue, 17 Apr 2012 00:15:43 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D1D0921F84D3 for ; Tue, 17 Apr 2012 00:15:42 -0700 (PDT) Received: (qmail invoked by alias); 17 Apr 2012 07:15:41 -0000 Received: from p57A6FAF7.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.250.247] by mail.gmx.net (mp040) with SMTP; 17 Apr 2012 09:15:41 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+CjBsw4NqCCBJw8qiacz54CwqFRHYF4lK5Qd8yU3 zHo8a8/+EUkF0k Message-ID: <4F8D189A.3010304@gmx.de> Date: Tue, 17 Apr 2012 09:15:38 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ned Freed References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> In-Reply-To: <01OEE9DUSD8400ZUIL@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org, Jeni Tennison , tony+mtsuffix@maillennium.att.com, Noah Mendelsohn , john+ietf@jck.com, "www-tag@w3.org List" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 07:15:44 -0000 On 2012-04-17 02:53, Ned Freed wrote: > ... > I note that this raises the issue of what to do about fragment identifiers in > the initial suffix registry document. Fragment identifiers don't really make > sense for most of the suffixes defined there. The exceptions I see are +xml and > +json. +json seems simple enough - refer to draft-ietf-appsawg-json-pointer-01. > ... I think that would be premature. The question has come up several times, and I don't think we are near any kind of even rough consensus about whether the spec should try to define a fragment identifier syntax for "+json" (or even application/json). > +xml is a bigger issue. This is a document to populate the registry; it is not > the place to define how fragment identifiers for XML work. But RFC 3023 section > 5 seems a bit dated. And waiting for a revision for RFC 3023 when there isn't > even an I-D doesn't sound like a good idea. So dated or not, I guess a > reference to RFC 3023 is as good as it gets for now. Indeed. Best regards, Julian From duerst@it.aoyama.ac.jp Tue Apr 17 01: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 DCCAE21F856F for ; Tue, 17 Apr 2012 01:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.091 X-Spam-Level: X-Spam-Status: No, score=-99.091 tagged_above=-999 required=5 tests=[AWL=0.699, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU7boR4mGo+C for ; Tue, 17 Apr 2012 01:53:33 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id C6FDD21F857D for ; Tue, 17 Apr 2012 01:53:32 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q3H8rKBx014963 for ; Tue, 17 Apr 2012 17:53:20 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6e3f_3ae2_c861cb70_886a_11e1_9555_001d096c5782; Tue, 17 Apr 2012 17:53:20 +0900 Received: from [IPv6:::1] ([133.2.210.1]:49506) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 17 Apr 2012 17:53:25 +0900 Message-ID: <4F8D2F7E.1040400@it.aoyama.ac.jp> Date: Tue, 17 Apr 2012 17:53:18 +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: Alexey Melnikov References: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> <4F89AE3A.5050503@isode.com> In-Reply-To: <4F89AE3A.5050503@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: appsdir@ietf.org, S Moonesamy , apps-discuss@ietf.org Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 08:53:37 -0000 On 2012/04/15 2:04, Alexey Melnikov wrote: > On 11/04/2012 10:25, S Moonesamy wrote: >> A review generally list issues as major or minor. I'll use a review >> performed by Ted Hardie as an example ( >> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04847.html ). >> >> >> The reviewer explained why he considered some issues as major. The >> author discussed about the issues with the reviewer ( >> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04859.html ). >> There isn't a clear-cut rule on what is a major or minor issue. It's >> up to the reviewer to make a judgement call. It is up to the >> author(s), or working group, to decide about whether these issues >> should be resolved and how to do so. > For me "major" is something I would have put a DISCUSS for. Then this is a difficult call for somebody who never was an AD :-). About once per draft, I find myself in the situation that I want to say "you would really better have done this in that other way", but don't really expect the authors/WG to actually do it, because it may be too late to change. What I hope is that the authors/WG learn something, and do it the better way next time. I usually classify these as major; I hope that's okay. Regards, Martin. From alexey.melnikov@isode.com Tue Apr 17 02:37: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 424F521F8629; Tue, 17 Apr 2012 02:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.903 X-Spam-Level: X-Spam-Status: No, score=-100.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osMIWvsl9d1M; Tue, 17 Apr 2012 02:37:32 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB7221F858D; Tue, 17 Apr 2012 02:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334655450; d=isode.com; s=selector; i=@isode.com; bh=pTucrosM7eWECC0JW0p87AAlVGhJEiaeEyNpkmAek0o=; 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=Ux71wUNj5ow5sJ4wAcH6KifbiSNMrG5ns9V1fjeBfUp/lOwFz1jbXnVLJxPFCIypdZFqIq v/urzjM5bF0N6AR05uetjtMG4unq5bNhoD9m8WXXQbDScsKNNaq7ykLXf/O2bPjSCbCWne gSxv0jJherVxpjPyJ14a8k2HmjtnnQk=; Received: from [188.28.106.64] (188.28.106.64.threembb.co.uk [188.28.106.64]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 17 Apr 2012 10:37:30 +0100 References: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> <4F89AE3A.5050503@isode.com> <4F8D2F7E.1040400@it.aoyama.ac.jp> In-Reply-To: <4F8D2F7E.1040400@it.aoyama.ac.jp> Message-Id: <4B6A22B5-ABFA-4FF2-B677-AD050D1C789C@isode.com> X-Mailer: iPad Mail (9B176) From: Alexey Melnikov Date: Tue, 17 Apr 2012 10:37:27 +0100 To: =?utf-8?Q?"Martin_J._D=C3=BCrst"?= MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Cc: "appsdir@ietf.org" , S Moonesamy , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 09:37:37 -0000 On 17 Apr 2012, at 09:53, "Martin J. D=C3=BCrst" wr= ote: > On 2012/04/15 2:04, Alexey Melnikov wrote: >> On 11/04/2012 10:25, S Moonesamy wrote: >=20 >>> A review generally list issues as major or minor. I'll use a review >>> performed by Ted Hardie as an example ( >>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04847.html )= . >>>=20 >>>=20 >>> The reviewer explained why he considered some issues as major. The >>> author discussed about the issues with the reviewer ( >>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04859.html )= . >>> There isn't a clear-cut rule on what is a major or minor issue. It's >>> up to the reviewer to make a judgement call. It is up to the >>> author(s), or working group, to decide about whether these issues >>> should be resolved and how to do so. >> For me "major" is something I would have put a DISCUSS for. >=20 > Then this is a difficult call for somebody who never was an AD :-). >=20 > About once per draft, I find myself in the situation that I want to say "y= ou would really better have done this in that other way", but don't really e= xpect the authors/WG to actually do it, because it may be too late to change= . What I hope is that the authors/WG learn something, and do it the better w= ay next time. >=20 > I usually classify these as major; I hope that's okay. It is all a bit subjective, but there is IESG DISCUSS Criteria document whic= h can be used as a guideline. From sm@elandsys.com Tue Apr 17 04:19: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 5192A21F85F9; Tue, 17 Apr 2012 04:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcWi2IOXoZoj; Tue, 17 Apr 2012 04:19:36 -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 4F57C21F860F; Tue, 17 Apr 2012 04:19:36 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.77]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3HBJFE9022137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2012 04:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334661570; i=@elandsys.com; bh=lw1hjyl8wujG+7LEIupZ13u/1XK/Pg8h1vmzKwIARAA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Z22yjg97KdDsMk/EufkYVpg0/XUKXnfVk7JXQT90sFfRr6dXLhrsgpknTwoTgitlM 46+WzNgHJlkvbT95dDLW66PELFwISfxltnzjWOv+hCXl9oaZxu6NhEgWRLoGEsh9Ti kjpyP8w8U4a9XUNqNg9KO3k3UUM3VxPtPpmQQpqs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334661570; i=@elandsys.com; bh=lw1hjyl8wujG+7LEIupZ13u/1XK/Pg8h1vmzKwIARAA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=25hxZ1xu7IdXMS1CXxwpBlpfP+UIdPyLIQSETi13LyrEQRm2K4oHYm9h9yeuHl+G9 J/s8Kvm5Iu4XJScwWSgNE/8AR9ZbWhS1vkmgixO6x7ep9QNXFnzNJCMIl2DYw3g2d9 Mt2mOl9jkTEKb+/tEmji2scmwrmLB1vq3CvCUT8U= Message-Id: <6.2.5.6.2.20120417024022.0a9e7e70@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 17 Apr 2012 04:11:37 -0700 To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= From: S Moonesamy In-Reply-To: <4F8D2F7E.1040400@it.aoyama.ac.jp> References: <6.2.5.6.2.20120411005340.0732caa0@elandnews.com> <4F89AE3A.5050503@isode.com> <4F8D2F7E.1040400@it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: appsdir@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [appsdir] Responding to Applications Area Directorate reviews X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 11:19:41 -0000 Hi Martin, At 01:53 17-04-2012, Martin J. D=FCrst wrote: >Then this is a difficult call for somebody who never was an AD :-). The DISCUSS criteria is documented at=20 http://www.ietf.org/iesg/statement/discuss-criteria.html >About once per draft, I find myself in the=20 >situation that I want to say "you would really=20 >better have done this in that other way", but=20 >don't really expect the authors/WG to actually=20 >do it, because it may be too late to change.=20 >What I hope is that the authors/WG learn=20 >something, and do it the better way next time. > >I usually classify these as major; I hope that's okay. One of the reasons why AppsDir performs early=20 reviews is so that changes can suggested before it is too late to change. If your advice is that "this would really have=20 been done in that other way", it's fine to raise=20 it as an issue. The informality of AppsDir=20 reviews allows AppsDir reviewers wide=20 discretion. As such, such issues can be classified as major. Regards, S. Moonesamy=20 From melvincarvalho@gmail.com Tue Apr 17 07:02: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 6DF6721F84A0 for ; Tue, 17 Apr 2012 07:02: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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FpjKU6-DCeI for ; Tue, 17 Apr 2012 07:02:04 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 11E7621F849A for ; Tue, 17 Apr 2012 07:02:03 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4885169vbb.31 for ; Tue, 17 Apr 2012 07:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HqomG/thcPDokXK9Jmy4k7NaUkMJGYkSMJ7fVbVGysg=; b=eatBtB20s0VGuDFYDsokxCvE9B/EZpc5pc/KMDQDnionatmK769YqMLlttM5YOxK87 4ESXVaWwX6BTAlm6rTOqRajFpS7vonV1Ogl8Kg1nSxPu7Wu18neQHygiE59Z6qqM2lYS 5/bhPmKRfQT7Zs4L8O8HlDEV3J0eE77Kw/00PbZozyZgkE+Vh/Om2GcZ9xDHyj+iAegn 4gHzx0PHHlG4CWXWJG4E8ULPNqYZe1fjhlAfmZMcmHIoajBMonDSyoLDMBz4hpXSWSvq TvmMSixfqjOpx8VIkeLErjLN2qFKxN3Up453r5WcA3xIcgGQotex0BZu+U56ILxYRRPF uu0Q== MIME-Version: 1.0 Received: by 10.220.153.8 with SMTP id i8mr1271276vcw.73.1334671323489; Tue, 17 Apr 2012 07:02:03 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Tue, 17 Apr 2012 07:02:03 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 17 Apr 2012 16:02:03 +0200 Message-ID: From: Melvin Carvalho To: Mike Jones Content-Type: multipart/alternative; boundary=f46d043be06820e3b604bde06286 Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 14:02:09 -0000 --f46d043be06820e3b604bde06286 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 16 April 2012 22:41, Mike Jones wrote: > You can read a lot of the rationale for why Simple Web Discovery was > developed in these posts: http://www.goland.org/simplewebfinger/ > http://www.goland.org/managingfingerservice/ > Thanks for sharing this A couple of points: 1. JSON =3D=3D=3D=3D=3D=3D=3D I think at the time webfinger was created in 2009, XML was the de facto serialization, used in AJAX, SOAP and many other systems. Today I'm hearing more and more, that both developers and publishers, want to work with JSON, rather than, having to support both xml and json. Content negotiation also confuses some publishers. In my view, this is a great simplification that webfinger can learn from SWD. 2. acct: scheme =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The acct: URI scheme has not proved popular, imho, and has added a layer of complexity and confusion. How do we get from acct: to mailto:? When should you use acct: and when mailto: (the spec says acct:user@host may be different from mailto:user@host). What about the forms. How about linked data ecosystems that want to cross link identifiers, do they now have to consider both cases? >From the original post introducing acct: "I don=92t expect everyone to like this idea. I wish I could say I love it, but I am simply content with it." I dont know of anyone in the community (and correct me if this has changed) that really loves acct:, or perhaps even likes the acct: idea. SWD has shown you can do discovery without acct: and I think that's a big plus. One final side note is that this almost becomes trivial when you can do SPARQL queries. "void" is already registered by the W3C with IANA in .well-known in order to discover SPARQL endpoints. It may be overkill in some people's eyes, but Linked Data (which predates webfinger), particularly newer things like JSON LD, are a lot bigger than they were in 2009. In a few years it may become the definitive discovery mechanism anyway. > > BTW, I'll point out that Stephen requested that we move this discussion t= o > the Apps Discuss list, so while I'm replying here, people should follow u= p > there. (Although I'll warn you, the traffic volume there is fierce - eve= n > compared to the OAuth list at its high water marks.) > > -- Mike > > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] > On Behalf Of Peter Saint-Andre > Sent: Monday, April 16, 2012 10:56 AM > To: Murray S. Kucherawy > Cc: Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discover= y > (SWD) > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 4/13/12 11:45 AM, Murray S. Kucherawy wrote: > >> -----Original Message----- From: apps-discuss-bounces@ietf.org > >> [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Stephen Farrell > >> Sent: Friday, April 13, 2012 9:23 AM To: oauth@ietf.org WG Cc: Apps > >> Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple > >> Web Discovery (SWD) > >> > >> So Hannes and Derek and I have been discussing this with the Apps ADs > >> and Apps-area WG chairs. I've also read the docs now, and after all > >> that we've decided that this topic (what to do with swd and > >> webfinger) is best handled in the apps area and not in the oauth WG. > >> > >> The logic for that is that 1) the two proposals are doing the same > >> thing and we don't want two different standards for that, b) this is > >> not an oauth-specific thing nor is it a general security thing, and > >> c) there is clearly already interest in the topic in the apps area so > >> its reasonable for the oauth wg to use that when its ready. > >> > >> The appsawg chairs and apps ADs are ok with the work being done > >> there. > >> > >> So:- > >> > >> - I've asked the oauth chairs to take doing work on swd out of the > >> proposed new charter - It may be that you want to add something > >> saying that oauth will use the results of work in the applications > >> area on a web discovery protocol as a basis for doing the dynamic > >> client registration work here - Discussion of webfinger and swd > >> should move over to the apps-discuss list - > >> Note: this is not picking one or the other approach, the plan is that > >> the apps area will do any selection needed and figure out the best > >> starting point for a standards-track RFC on web discovery and we'll > >> use their fine work for doing more with oauth. > > > > Thank you Stephen, I think. :-) > > > > So the discussion on apps-discuss now should be focused on which of > > the two should be the basis for forward progress. I've placed both > > documents in "Call for Adoption" state in the datatracker for appsawg. > > > > Let the games begin. > > I've just had a chance to review both I-Ds: > > https://datatracker.ietf.org/doc/draft-jones-appsawg-webfinger/ (-03) > > http://datatracker.ietf.org/doc/draft-jones-simple-web-discovery/ (-02) > > Although at a later time I will provide more detailed feedback, I am left > wondering why Simple Web Discovery was developed. It appears to solve the > same problem as WebFinger (which predates SWD by several years as far as = I > can see) in similar ways (/.well-known/ etc.), with a few tweaks and > optimizations (some of which might be premature IMHO). > > Thus I think it would be helpful for the authors of SWD to explain why > they didn't use WebFinger, or provide feedback that would improve WebFing= er > if it didn't address some of their use cases (I note that the more recent > WebFinger I-Ds include some SWD-ish features, such as the "resource" > parameter -- whether that is a good thing remains to be determined). > Although draft-jones-simple-web-discovery does not contain such an > analysis, perhaps someone posted it to the OAUTH WG list or elsewhere, in > which case I apologize for having missed it. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk+MXSIACgkQNL8k5A2w/vzR4ACffCIM6A/RBj/y6RdyiudN+AF2 > deMAoKmuesVvyS8yYVb0sqYXqCJnQF8+ > =3D3OKr > -----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 > --f46d043be06820e3b604bde06286 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 16 April 2012 22:41, Mike Jones <Michael.Jon= es@microsoft.com> wrote:
You can read a lot of the rationale for why Simple Web Discovery was develo= ped in these posts: =A0 =A0 =A0 =A0 =A0http://www.goland.org/simplewebfinger/=
=A0 =A0 =A0 =A0http://www.goland.org/managingfingerservice/


Thanks for sharing this

A couple of points:
1. JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the time webfinger was created in 2= 009, XML was the de facto serialization, used in AJAX, SOAP and many other = systems.=A0 Today I'm hearing more and more, that both developers and p= ublishers, want to work with JSON, rather than, having to support both xml = and json.=A0 Content negotiation also confuses some publishers.=A0 In my vi= ew, this is a great simplification that webfinger can learn from SWD.

2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The a= cct: URI scheme has not proved popular, imho, and has added a layer of comp= lexity and confusion.=A0 How do we get from acct: to mailto:?=A0 When shoul= d you use acct: and when mailto: (the spec says acct:user@host may be diffe= rent from mailto:user@host).=A0 What about= the forms.=A0 How about linked data ecosystems that want to cross link ide= ntifiers, do they now have to consider both cases?=A0

From the original post introducing acct:

"I don=92t expect = everyone to like this idea. I wish I could say I love it, but I am simply c= ontent with it."

I dont know of anyone in the community (and co= rrect me if this has changed) that really loves acct:, or perhaps even like= s the acct: idea.=A0 SWD has shown you can do discovery without acct: and I= think that's a big plus.




One final side note is that this almost becomes trivial whe= n you can do SPARQL queries.=A0 "void" is already registered by t= he W3C with IANA in .well-known in order to discover SPARQL endpoints.=A0 I= t may be overkill in some people's eyes, but Linked Data (which predate= s webfinger), particularly newer things like JSON LD, are a lot bigger than= they were in 2009.=A0 In a few years it may become the definitive discover= y mechanism anyway.
=A0

BTW, I'll point out that Stephen requested that we move this discussion= to the Apps Discuss list, so while I'm replying here, people should fo= llow up there. =A0(Although I'll warn you, the traffic volume there is = fierce - even compared to the OAuth list at its high water marks.)

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

-----Original Message-----
From: apps-discuss-bounces= @ietf.org [mailto:apps= -discuss-bounces@ietf.org] On Behalf Of Peter Saint-Andre
Sent: Monday, April 16, 2012 10:56 AM
To: Murray S. Kucherawy
Cc: Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)

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

On 4/13/12 11:45 AM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: apps-discuss-bounces@ietf.org
>> [mailto:apps-disc= uss-bounces@ietf.org] On Behalf Of Stephen Farrell
>> Sent: Friday, April 13, 2012 9:23 AM To: oauth@ietf.org WG Cc: Apps
>> Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simp= le
>> Web Discovery (SWD)
>>
>> So Hannes and Derek and I have been discussing this with the Apps = ADs
>> and Apps-area WG chairs. I've also read the docs now, and afte= r all
>> that we've decided that this topic (what to do with swd and >> webfinger) is best handled in the apps area and not in the oauth W= G.
>>
>> The logic for that is that 1) the two proposals are doing the same=
>> thing and we don't want two different standards for that, b) t= his is
>> not an oauth-specific thing nor is it a general security thing, an= d
>> c) there is clearly already interest in the topic in the apps area= so
>> its reasonable for the oauth wg to use that when its ready.
>>
>> The appsawg chairs and apps ADs are ok with the work being done >> there.
>>
>> So:-
>>
>> - I've asked the oauth chairs to take doing work on swd out of= the
>> proposed new charter - It may be that you want to add something >> saying that oauth will use the results of work in the applications=
>> area on a web discovery protocol as a basis for doing the dynamic<= br> >> client registration work here - Discussion of webfinger and swd >> should move over to the apps-discuss list -
>> Note: this is not picking one or the other approach, the plan is t= hat
>> the apps area will do any selection needed and figure out the best=
>> starting point for a standards-track RFC on web discovery and we&#= 39;ll
>> use their fine work for doing more with oauth.
>
> Thank you Stephen, I think. =A0:-)
>
> So the discussion on apps-discuss now should be focused on which of > the two should be the basis for forward progress. =A0I've placed b= oth
> documents in "Call for Adoption" state in the datatracker fo= r appsawg.
>
> Let the games begin.

I've just had a chance to review both I-Ds:

https://datatracker.ietf.org/doc/draft-jones-appsawg-web= finger/ (-03)

http://datatracker.ietf.org/doc/draft-jones-simple-web= -discovery/ (-02)

Although at a later time I will provide more detailed feedback, I am left w= ondering why Simple Web Discovery was developed. It appears to solve the sa= me problem as WebFinger (which predates SWD by several years as far as I ca= n see) in similar ways (/.well-known/ etc.), with a few tweaks and optimiza= tions (some of which might be premature IMHO).

Thus I think it would be helpful for the authors of SWD to explain why they= didn't use WebFinger, or provide feedback that would improve WebFinger= if it didn't address some of their use cases (I note that the more rec= ent WebFinger I-Ds include some SWD-ish features, such as the "resourc= e" parameter -- whether that is a good thing remains to be determined)= . Although draft-jones-simple-web-discovery does not contain such an analys= is, perhaps someone posted it to the OAUTH WG list or elsewhere, in which c= ase I apologize for having missed it.

Peter

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

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

iEYEARECAAYFAk+MXSIACgkQNL8k5A2w/vzR4ACffCIM6A/RBj/y6RdyiudN+AF2
deMAoKmuesVvyS8yYVb0sqYXqCJnQF8+
=3D3OKr
-----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

--f46d043be06820e3b604bde06286-- From bobwyman@gmail.com Tue Apr 17 08:06: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 D307711E80AE for ; Tue, 17 Apr 2012 08:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2PLUtAAQWPp for ; Tue, 17 Apr 2012 08:06:06 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5FA11E8080 for ; Tue, 17 Apr 2012 08:06:06 -0700 (PDT) Received: by qcsq13 with SMTP id q13so4706410qcs.31 for ; Tue, 17 Apr 2012 08:06:06 -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=JaaWALncyjkSssjXmLkk/QrZ3D2dkjOExVq0X1LHhNc=; b=vgrUaGy//PrZ9D2I8Hy9dK1K9Ifb7BSDZXf2uCVCkVKqnisqun1q6yxiU81y8+Wh06 5d2iox40/uU6sSKAEUwq4F5dm+A3QXlk5jWektUvNsqdprn14WneejY0arlLYbdMzJso EzuHJ+jAwgxip0MRwoNL+GcuzOur3Btof6v/1rdnf0VEOYoG7DB99qVc55fvXj31RMJe mZycIUMDQtLNs/NwWiUh7IhpWcHkls4w3q27TEhqkHOWnO5J6h3vMKzHXla6II0bnwrT xbejGpxkJbiEBzOcILF6vaRXIxodELX+tkkLh9gCypXq0/cCXSNV+UGyLHGyeGeyFXHY hU3g== MIME-Version: 1.0 Received: by 10.224.101.72 with SMTP id b8mr21170688qao.53.1334675165968; Tue, 17 Apr 2012 08:06:05 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.12.194 with HTTP; Tue, 17 Apr 2012 08:06:05 -0700 (PDT) In-Reply-To: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 17 Apr 2012 11:06:05 -0400 X-Google-Sender-Auth: WW639zbQpXJQ0Qiri7OdlajMSh0 Message-ID: From: Bob Wyman To: Melvin Carvalho Content-Type: multipart/alternative; boundary=20cf30667c2f28775504bde147f2 Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 15:06:11 -0000 --20cf30667c2f28775504bde147f2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Apr 17, 2012 at 10:02 AM, Melvin Carvalho wrote: > I dont know of anyone in the community (and correct me if this has changed) that really loves acct:, or perhaps even likes the acct: idea. Well, I like acct:. I like it precisely because it is NOT that same as mailto:. Acct: provides me a way to identify myself or some other entity without the identifier granting (explicitly or implicitly) any particular capability to those who discover it. Acct: separates the functions of identity from the mechanisms of communication. It allows one to talk about someone without necessarily knowing how to send them mail. This is a good thing! (Even if it irritates some spammers...) I first worked on developing an email and "office automation" system (DEC's ALL-IN-1) over 30 years ago and it has always bothered me that the mere act of assuming an identity in a distributed system implicitly grants anyone who discovers that identity the ability to gain access to my messaging system. Acct: resolves this problem or data leak. Also, Acct: allows services that provide value to the network without providing email services to uniquely identify people and to provide profile services. For instance, as far as I know, you still can't "send email" to a Twitter user. Yet, Twitter identifiers are, in many realms, exceptionally important. I have no idea if Twitter would want to do such a thing, but if they did want to provide WebFinger or profile services, why in the world would we force them to use a mailto: (which implies email support) as a means of identifying their accounts? Would Twitter have to implement email before they could implement WebFinger? Wouldn't it be reasonable to allow Twitter to implement a WebFinger service that mapped from Twitter acct: identifiers to mailto:'s on other services? (I may be acct:bobwyman@twitter.com but receive email as mailto:bob@example.com) If not, why not? The same question holds, of course, for any number of other discussion forums, social networks, etc. that offer services other than email. it is unreasonable to say that only those who implement email can be identity, profile or WebFinger providers. > How do we get from acct: to mailto:? To get from acct: to mailto: using WebFinger, you would have to rely on someone telling you how. Either the mapping would be expressed in the document itself or there would be a link to a service that does, in fact, provide the mapping. Of course, that service could and in many cases should impose some access control when determining who can discover the mailto:that corresponds to a particular acct:. In fact, it would be entirely reasonable that there would be a one to many mapping from acct: to mailto:and thus the acct: to mailto:mapping would be specific to a requestor or group of requestors. While it is useful to me to have a widely known and consistent identity, it is not the case that everyone should know or have access to the same mailbox when sending me messages. (Consider the extreme case of President Obama... Certainly, we'd all like to refer to him with some consistent and broadly known identifier (perhaps: pres_obama@whitehouse.gov") but that doesn't mean that we should all be able to send messages to the same mailbox that his wife or his Chief of Staff uses...) Acct: is a good thing. We've lived with the inadequacies of using mailto:as an identifier far too long. It is time that we separate the mechanisms of "identity" from the mechanisms of any of the specific services that might rely on or leverage identity. A mailto: should be used to send mail. An acct: should be used to name people or entities. These are distinct functions. They should be distinct names (even when they look the same...) Now, you know at least one person who likes acct:. Hopefully, you also understand why. bob wyman On Tue, Apr 17, 2012 at 10:02 AM, Melvin Carvalho wrote: > > > On 16 April 2012 22:41, Mike Jones wrote: > >> You can read a lot of the rationale for why Simple Web Discovery was >> developed in these posts: http://www.goland.org/simplewebfinger= / >> http://www.goland.org/managingfingerservice/ >> > > > Thanks for sharing this > > A couple of points: > > 1. JSON > =3D=3D=3D=3D=3D=3D=3D > > I think at the time webfinger was created in 2009, XML was the de facto > serialization, used in AJAX, SOAP and many other systems. Today I'm > hearing more and more, that both developers and publishers, want to work > with JSON, rather than, having to support both xml and json. Content > negotiation also confuses some publishers. In my view, this is a great > simplification that webfinger can learn from SWD. > > 2. acct: scheme > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The acct: URI scheme has not proved popular, imho, and has added a layer > of complexity and confusion. How do we get from acct: to mailto:? When > should you use acct: and when mailto: (the spec says acct:user@host may > be different from mailto:user@host). What about the forms. How about > linked data ecosystems that want to cross link identifiers, do they now > have to consider both cases? > > From the original post introducing acct: > > "I don=92t expect everyone to like this idea. I wish I could say I love i= t, > but I am simply content with it." > > I dont know of anyone in the community (and correct me if this has > changed) that really loves acct:, or perhaps even likes the acct: idea. > SWD has shown you can do discovery without acct: and I think that's a big > plus. > > > > > One final side note is that this almost becomes trivial when you can do > SPARQL queries. "void" is already registered by the W3C with IANA in > .well-known in order to discover SPARQL endpoints. It may be overkill in > some people's eyes, but Linked Data (which predates webfinger), > particularly newer things like JSON LD, are a lot bigger than they were i= n > 2009. In a few years it may become the definitive discovery mechanism > anyway. > > >> >> BTW, I'll point out that Stephen requested that we move this discussion >> to the Apps Discuss list, so while I'm replying here, people should foll= ow >> up there. (Although I'll warn you, the traffic volume there is fierce - >> even compared to the OAuth list at its high water marks.) >> >> -- Mike >> >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.or= g] >> On Behalf Of Peter Saint-Andre >> Sent: Monday, April 16, 2012 10:56 AM >> To: Murray S. Kucherawy >> Cc: Apps Discuss >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web >> Discovery (SWD) >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 4/13/12 11:45 AM, Murray S. Kucherawy wrote: >> >> -----Original Message----- From: apps-discuss-bounces@ietf.org >> >> [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Stephen Farrell >> >> Sent: Friday, April 13, 2012 9:23 AM To: oauth@ietf.org WG Cc: Apps >> >> Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple >> >> Web Discovery (SWD) >> >> >> >> So Hannes and Derek and I have been discussing this with the Apps ADs >> >> and Apps-area WG chairs. I've also read the docs now, and after all >> >> that we've decided that this topic (what to do with swd and >> >> webfinger) is best handled in the apps area and not in the oauth WG. >> >> >> >> The logic for that is that 1) the two proposals are doing the same >> >> thing and we don't want two different standards for that, b) this is >> >> not an oauth-specific thing nor is it a general security thing, and >> >> c) there is clearly already interest in the topic in the apps area so >> >> its reasonable for the oauth wg to use that when its ready. >> >> >> >> The appsawg chairs and apps ADs are ok with the work being done >> >> there. >> >> >> >> So:- >> >> >> >> - I've asked the oauth chairs to take doing work on swd out of the >> >> proposed new charter - It may be that you want to add something >> >> saying that oauth will use the results of work in the applications >> >> area on a web discovery protocol as a basis for doing the dynamic >> >> client registration work here - Discussion of webfinger and swd >> >> should move over to the apps-discuss list - >> >> Note: this is not picking one or the other approach, the plan is that >> >> the apps area will do any selection needed and figure out the best >> >> starting point for a standards-track RFC on web discovery and we'll >> >> use their fine work for doing more with oauth. >> > >> > Thank you Stephen, I think. :-) >> > >> > So the discussion on apps-discuss now should be focused on which of >> > the two should be the basis for forward progress. I've placed both >> > documents in "Call for Adoption" state in the datatracker for appsawg. >> > >> > Let the games begin. >> >> I've just had a chance to review both I-Ds: >> >> https://datatracker.ietf.org/doc/draft-jones-appsawg-webfinger/ (-03) >> >> http://datatracker.ietf.org/doc/draft-jones-simple-web-discovery/ (-02) >> >> Although at a later time I will provide more detailed feedback, I am lef= t >> wondering why Simple Web Discovery was developed. It appears to solve th= e >> same problem as WebFinger (which predates SWD by several years as far as= I >> can see) in similar ways (/.well-known/ etc.), with a few tweaks and >> optimizations (some of which might be premature IMHO). >> >> Thus I think it would be helpful for the authors of SWD to explain why >> they didn't use WebFinger, or provide feedback that would improve WebFin= ger >> if it didn't address some of their use cases (I note that the more recen= t >> WebFinger I-Ds include some SWD-ish features, such as the "resource" >> parameter -- whether that is a good thing remains to be determined). >> Although draft-jones-simple-web-discovery does not contain such an >> analysis, perhaps someone posted it to the OAUTH WG list or elsewhere, i= n >> which case I apologize for having missed it. >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk+MXSIACgkQNL8k5A2w/vzR4ACffCIM6A/RBj/y6RdyiudN+AF2 >> deMAoKmuesVvyS8yYVb0sqYXqCJnQF8+ >> =3D3OKr >> -----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 >> > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --20cf30667c2f28775504bde147f2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 17, 2012 at 10:02 AM, Melvin Carvalho=A0= <melvincarvalho@gmail.com>=A0wrote:
Well, I like acct:. I like it precisely because it is NOT that same as mail= to:. Acct: provides me a way to identify myself or some other entity withou= t the identifier granting (explicitly or implicitly) any particular capabil= ity to those who discover it. Acct: separates the functions of identity fro= m the mechanisms of communication. It allows one to talk about someone with= out necessarily knowing how to send them mail. This is a good thing! (Even = if it irritates some spammers...)

I first worked on developing an email and "office autom= ation" system (DEC's ALL-IN-1) over 30 years ago and it has always= bothered me that the mere act of assuming an identity in a distributed sys= tem implicitly grants anyone who discovers that identity the ability to gai= n access to my messaging system. Acct: resolves this problem or data leak. = Also, Acct: allows services that provide value to the network without provi= ding email services to uniquely identify people and to provide profile serv= ices. For instance, as far as I know, you still can't "send email&= quot; to a Twitter user. Yet, Twitter identifiers are, in many realms, exce= ptionally important. I have no idea if Twitter would want to do such a thin= g, but if they did want to provide WebFinger or profile services, why in th= e world would we force them to use a mailto: (which implies email support) = as a means of identifying their accounts? Would Twitter have to implement e= mail before they could implement WebFinger? Wouldn't it be reasonable t= o allow Twitter to implement a WebFinger service that mapped from Twitter a= cct: identifiers to mailto:'s on other services? (I may be acct:bobwyman@twitter.com but receiv= e email as mailto:bob@example.com) I= f not, why not? The same question holds, of course, for any number of other= discussion forums, social networks, etc. that offer services other than em= ail. it is unreasonable to say that only those who implement email can be i= dentity, profile or WebFinger providers.

>=A0How do we get from acct: to mailto:?
To get f= rom acct: to mailto: using WebFinger, you would have to rely on someone tel= ling you how. Either the mapping would be expressed in the document itself = or there would be a link to a service that does, in fact, provide the mappi= ng. Of course, that service could and in many cases should impose some acce= ss control when determining who can discover the mailto: that corresponds t= o a particular acct:. In fact, it would be entirely reasonable that there w= ould be a one to many mapping from acct: to mailto: and thus the acct: to m= ailto: mapping would be specific to a requestor or group of requestors.=A0<= /div>
While it is useful to me to have a widely known and consistent identit= y, it is not the case that everyone should know or have access to the same = mailbox when sending me messages. (Consider the extreme case of President O= bama... Certainly, we'd all like to refer to him with some consistent a= nd broadly known identifier (perhaps: pres_obama@whitehouse.gov") but that doesn't mean that= we should all be able to send messages to the same mailbox that his wife o= r his Chief of Staff uses...)

Acct: is a good thing. We've lived with the inadequacies of using m= ailto: as an identifier far too long. It is time that we separate the mecha= nisms of "identity" from the mechanisms of any of the specific se= rvices that might rely on or leverage identity. A mailto: should be used to= send mail. An acct: should be used to name people or entities. These are d= istinct functions. They should be distinct names (even when they look the s= ame...)

Now, you know at least one person who likes acct:. Hopefully, you also = understand why.

bob wyman

O= n Tue, Apr 17, 2012 at 10:02 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:


On 16 April 2012 22:41, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:
You can read a lot of the rationale for why Simple Web Discovery was develo= ped in these posts: =A0 =A0 =A0 =A0 =A0http://www.goland.org/simplewebfinger/=
=A0 =A0 =A0 =A0http://www.goland.org/managingfingerservice/


Thanks for sharing this

A couple of points:=

1. JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the time webfinger was created in 2= 009, XML was the de facto serialization, used in AJAX, SOAP and many other = systems.=A0 Today I'm hearing more and more, that both developers and p= ublishers, want to work with JSON, rather than, having to support both xml = and json.=A0 Content negotiation also confuses some publishers.=A0 In my vi= ew, this is a great simplification that webfinger can learn from SWD.

2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The a= cct: URI scheme has not proved popular, imho, and has added a layer of comp= lexity and confusion.=A0 How do we get from acct: to mailto:?=A0 When shoul= d you use acct: and when mailto: (the spec says acct:user@host may be diffe= rent from mailto:user@host).=A0 What about the forms.=A0 How about linked data ecosystems that want= to cross link identifiers, do they now have to consider both cases?=A0
From the original post introducing acct:

"I don=92t expect = everyone to like this idea. I wish I could say I love it, but I am simply c= ontent with it."

I dont know of anyone in the community (and co= rrect me if this has changed) that really loves acct:, or perhaps even like= s the acct: idea.=A0 SWD has shown you can do discovery without acct: and I= think that's a big plus.




One final side note is that this almost becomes trivial whe= n you can do SPARQL queries.=A0 "void" is already registered by t= he W3C with IANA in .well-known in order to discover SPARQL endpoints.=A0 I= t may be overkill in some people's eyes, but Linked Data (which predate= s webfinger), particularly newer things like JSON LD, are a lot bigger than= they were in 2009.=A0 In a few years it may become the definitive discover= y mechanism anyway.
=A0

BTW, I'll point out that Stephen requested that we move this discussion= to the Apps Discuss list, so while I'm replying here, people should fo= llow up there. =A0(Although I'll warn you, the traffic volume there is = fierce - even compared to the OAuth list at its high water marks.)

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

-----Original Message-----
From: ap= ps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behal= f Of Peter Saint-Andre
Sent: Monday, April 16, 2012 10:56 AM
To: Murray S. Kucherawy
Cc: Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)

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

On 4/13/12 11:45 AM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: apps-discuss-bounces@ietf.org
>> [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Stephen Farrell >> Sent: Friday, April 13, 2012 9:23 AM To: oauth@ietf.org WG Cc: Apps
>> Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simp= le
>> Web Discovery (SWD)
>>
>> So Hannes and Derek and I have been discussing this with the Apps = ADs
>> and Apps-area WG chairs. I've also read the docs now, and afte= r all
>> that we've decided that this topic (what to do with swd and >> webfinger) is best handled in the apps area and not in the oauth W= G.
>>
>> The logic for that is that 1) the two proposals are doing the same=
>> thing and we don't want two different standards for that, b) t= his is
>> not an oauth-specific thing nor is it a general security thing, an= d
>> c) there is clearly already interest in the topic in the apps area= so
>> its reasonable for the oauth wg to use that when its ready.
>>
>> The appsawg chairs and apps ADs are ok with the work being done >> there.
>>
>> So:-
>>
>> - I've asked the oauth chairs to take doing work on swd out of= the
>> proposed new charter - It may be that you want to add something >> saying that oauth will use the results of work in the applications=
>> area on a web discovery protocol as a basis for doing the dynamic<= br> >> client registration work here - Discussion of webfinger and swd >> should move over to the apps-discuss list -
>> Note: this is not picking one or the other approach, the plan is t= hat
>> the apps area will do any selection needed and figure out the best=
>> starting point for a standards-track RFC on web discovery and we&#= 39;ll
>> use their fine work for doing more with oauth.
>
> Thank you Stephen, I think. =A0:-)
>
> So the discussion on apps-discuss now should be focused on which of > the two should be the basis for forward progress. =A0I've placed b= oth
> documents in "Call for Adoption" state in the datatracker fo= r appsawg.
>
> Let the games begin.

I've just had a chance to review both I-Ds:

https://datatracker.ietf.org/doc/draft-jones-appsawg-web= finger/ (-03)

http://datatracker.ietf.org/doc/draft-jones-simple-web= -discovery/ (-02)

Although at a later time I will provide more detailed feedback, I am left w= ondering why Simple Web Discovery was developed. It appears to solve the sa= me problem as WebFinger (which predates SWD by several years as far as I ca= n see) in similar ways (/.well-known/ etc.), with a few tweaks and optimiza= tions (some of which might be premature IMHO).

Thus I think it would be helpful for the authors of SWD to explain why they= didn't use WebFinger, or provide feedback that would improve WebFinger= if it didn't address some of their use cases (I note that the more rec= ent WebFinger I-Ds include some SWD-ish features, such as the "resourc= e" parameter -- whether that is a good thing remains to be determined)= . Although draft-jones-simple-web-discovery does not contain such an analys= is, perhaps someone posted it to the OAUTH WG list or elsewhere, in which c= ase I apologize for having missed it.

Peter

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

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

iEYEARECAAYFAk+MXSIACgkQNL8k5A2w/vzR4ACffCIM6A/RBj/y6RdyiudN+AF2
deMAoKmuesVvyS8yYVb0sqYXqCJnQF8+
=3D3OKr
-----END PGP SIGNATURE-----
_______________________________________________
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


--20cf30667c2f28775504bde147f2-- From ned.freed@mrochek.com Tue Apr 17 08:26: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 ABA5B11E809D for ; Tue, 17 Apr 2012 08:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqSf-QB8qUGj for ; Tue, 17 Apr 2012 08:26:32 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id F3BB111E8080 for ; Tue, 17 Apr 2012 08:26:31 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEF31NDZ9S007A4J@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 17 Apr 2012 08:26:25 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Tue, 17 Apr 2012 08:26:22 -0700 (PDT) Message-id: <01OEF31LICKI00ZUIL@mauve.mrochek.com> Date: Tue, 17 Apr 2012 08:25:28 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 17 Apr 2012 10:21:08 +0100" <67F5F46D-7E56-4B4B-8AEA-2C761D73B863@jenitennison.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <67F5F46D-7E56-4B4B-8AEA-2C761D73B863@jenitennison.com> To: Jeni Tennison Cc: Ned Freed , apps-discuss@ietf.org, tony+mtsuffix@maillennium.att.com, john+ietf@jck.com, "www-tag@w3.org List" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 15:26:32 -0000 > Ned, all, > On 17 Apr 2012, at 01:53, Ned Freed wrote: > > I'll wait a day or so for additional comments, then post a revised draft > > with these changes. > Thank you very much for that. I'll bring the revised text to the attention of > the TAG during the next telcon on Thursday, and raise the other issues that > have been touched on during this discussion, namely: Note that I have already made an additional revision and posted the revised text. There may be additional revisions in fairly short order; I'll post them as I make them. Ned From jeni@jenitennison.com Mon Apr 16 10:30: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 846AB21F86A1 for ; Mon, 16 Apr 2012 10:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEOJwZy0BMx3 for ; Mon, 16 Apr 2012 10:30:54 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC6E21F86A0 for ; Mon, 16 Apr 2012 10:30:53 -0700 (PDT) Received: from cpc19-epso4-2-0-cust100.6-3.cable.virginmedia.com ([86.30.196.101] helo=[192.168.123.64]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SJplM-00089D-W4; Mon, 16 Apr 2012 18:30:53 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Jeni Tennison In-Reply-To: <4F8C43AC.10005@stpeter.im> Date: Mon, 16 Apr 2012 18:30:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3DDE06BC-B80E-43D7-B672-4F2C894D9C17@jenitennison.com> References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <4F8C43AC.10005@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) X-Mailcore-Auth: 9919842 X-Mailcore-Domain: 1066436 X-Mailman-Approved-At: Tue, 17 Apr 2012 08:56:34 -0700 Cc: Ned Freed , apps-discuss@ietf.org, tony+mtsuffix@maillennium.att.com, Julian Reschke , john+ietf@jck.com, "www-tag@w3.org List" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 17:30:55 -0000 Peter, On 16 Apr 2012, at 17:07, Peter Saint-Andre wrote: > Ned is right: this document defines best practices for *registering* > media types. We all might want to more clearly specify the syntax and > semantics of fragment identifiers, but IMHO that's out of scope for = the > registration procedures per se. Please can you advise whether the changes I proposed in [1] fit within = that scope, and if not, what changes would make them do so? Thanks, Jeni [1] http://lists.w3.org/Archives/Public/www-tag/2012Apr/0098.html --=20 Jeni Tennison http://www.jenitennison.com From derek@ihtfp.com Mon Apr 16 12:07:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9DE21F85D8; Mon, 16 Apr 2012 12:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.936 X-Spam-Level: X-Spam-Status: No, score=-101.936 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ME3Af3heGFZ; Mon, 16 Apr 2012 12:07:14 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6E021F85CE; Mon, 16 Apr 2012 12:07:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6FBA52602A6; Mon, 16 Apr 2012 15:07:13 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16559-07; Mon, 16 Apr 2012 15:07:12 -0400 (EDT) Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 5BCC92602A5; Mon, 16 Apr 2012 15:07:12 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3GJ79Ha012606; Mon, 16 Apr 2012 15:07:09 -0400 From: Derek Atkins To: "Murray S. Kucherawy" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> Date: Mon, 16 Apr 2012 15:07:08 -0400 In-Reply-To: <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> (Murray S. Kucherawy's message of "Fri, 13 Apr 2012 17:45:32 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a X-Mailman-Approved-At: Tue, 17 Apr 2012 08:56:34 -0700 Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 19:07:14 -0000 "Murray S. Kucherawy" writes: > Thank you Stephen, I think. :-) > > So the discussion on apps-discuss now should be focused on which of the two should be the basis for forward progress. I've placed both documents in "Call for Adoption" state in the datatracker for appsawg. >From an OAUTH perspective I believe that we should help define the requirements of what this protocol needs to provide (be it webfinger, swd, or yadp (Yet Another Discovery Protocol) -- whatever it's named!) I think there are two main differerences between webfinger and swd: a) whole-document vs. individual attributes b) a perceived authorization model to control access to said attributes In particular I feel there are some specific security requirements that must be bet by the protocol, but I think it's easily accomplished by a small amount of text that effectively says: 1) requestors of the service should authenticate (or be treated as an anonymous user) 2) content returned must be dynamic and dependent on the authorization of the authenticated user. This leaves only the perceived issue of "whole document" vs "individual attribute". If a client ever wants more than one attribute then a whole document approach reduces the number of round trips. However if documents get large that could also affect performance. We might, then, need a way to specify which attributes are requested, but allow for a wildcard to return "everything I am authorized to see". > Let the games begin. Heh. Play ball! > -MSK > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From jeni@jenitennison.com Tue Apr 17 03:57: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 3DC7F21F84A2 for ; Tue, 17 Apr 2012 03:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fizF2IEWwy9u for ; Tue, 17 Apr 2012 03:57:50 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id E4D2521F84B4 for ; Tue, 17 Apr 2012 03:57:49 -0700 (PDT) Received: from [82.132.249.71] (helo=[192.168.43.17]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SK66W-0000tV-DR; Tue, 17 Apr 2012 11:57:48 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jeni Tennison In-Reply-To: <01OEE9DUSD8400ZUIL@mauve.mrochek.com> Date: Tue, 17 Apr 2012 10:21:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <67F5F46D-7E56-4B4B-8AEA-2C761D73B863@jenitennison.com> References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1257) X-Mailcore-Auth: 9919842 X-Mailcore-Domain: 1066436 X-Mailman-Approved-At: Tue, 17 Apr 2012 08:56:34 -0700 Cc: john+ietf@jck.com, tony+mtsuffix@maillennium.att.com, apps-discuss@ietf.org, "www-tag@w3.org List" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 10:57:54 -0000 Ned, all, On 17 Apr 2012, at 01:53, Ned Freed wrote: > I'll wait a day or so for additional comments, then post a revised = draft > with these changes. Thank you very much for that. I'll bring the revised text to the = attention of the TAG during the next telcon on Thursday, and raise the = other issues that have been touched on during this discussion, namely: * the need for an I-D for 3023bis and coordination around the +xml = structured syntax suffix registration * the need for coordination between W3C and IETF over the Media Fragment = URI work * the development of a separate document with guidance about specifying = fragment identifiers for media types Thanks again for your help and sorry for the last-minute nature of these = changes. Cheers, Jeni --=20 Jeni Tennison http://www.jenitennison.com From kevinmarks@gmail.com Mon Apr 16 12:47: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 EAFB321F861F; Mon, 16 Apr 2012 12:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3ImB1JM5IEM; Mon, 16 Apr 2012 12:47:49 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC19421F8627; Mon, 16 Apr 2012 12:47:48 -0700 (PDT) Received: by qcsq13 with SMTP id q13so4096639qcs.31 for ; Mon, 16 Apr 2012 12:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rN4iHozaL+sQF+E4gUhYVhiVdjQMcRDgA+jL5dYO65w=; b=R5O2eEV/zIXkybjzT+4rrcbne15WUDXuOATeR0MCsvBz4W0ouFXWs61ZUCBh0B1hXw g30nolXyjp/Y0Po0JUKHmt2wkAnfoY9BZ5VZGZ6tEghC2S9jTwUN0lyPDyZMnvUHO0nB nhTjtHntbpnyzga0Jj6NyrvUaKLEL20yuUBexNBwkRO5z6PBDLKRoIguEKk3X76hoCEm KKxekxtx0arPgEKZPAxrR+Sk85LEJ4/ZNarZ4sD+Cb3eGWpbHoFtERVyXMPDeZJrQFti VzK9OJmXNWIdFQRl4qaOErjM2/ArSAQEukvquAy0R+qQ+W+lgbbzr5fzeIfTA1LT7gYD 29XQ== MIME-Version: 1.0 Received: by 10.229.136.131 with SMTP id r3mr5203372qct.129.1334605668374; Mon, 16 Apr 2012 12:47:48 -0700 (PDT) Received: by 10.229.38.70 with HTTP; Mon, 16 Apr 2012 12:47:48 -0700 (PDT) In-Reply-To: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> Date: Mon, 16 Apr 2012 12:47:48 -0700 Message-ID: From: Kevin Marks To: Derek Atkins Content-Type: multipart/alternative; boundary=00248c768f9ec75a1104bdd118ce X-Mailman-Approved-At: Tue, 17 Apr 2012 08:56:45 -0700 Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 19:47:50 -0000 --00248c768f9ec75a1104bdd118ce Content-Type: text/plain; charset=UTF-8 On Mon, Apr 16, 2012 at 12:07 PM, Derek Atkins wrote: > > I think there are two main differerences between webfinger and swd: > > a) whole-document vs. individual attributes > b) a perceived authorization model to control access to said attributes > > In particular I feel there are some specific security requirements that > must be bet by the protocol, but I think it's easily accomplished by > a small amount of text that effectively says: > > 1) requestors of the service should authenticate (or be treated as an > anonymous user) > 2) content returned must be dynamic and dependent on the authorization > of the authenticated user. > I think requesters MAY authenticate, not SHOULD. > > This leaves only the perceived issue of "whole document" vs "individual > attribute". If a client ever wants more than one attribute then a whole > document approach reduces the number of round trips. However if > documents get large that could also affect performance. We might, then, > need a way to specify which attributes are requested, but allow for a > wildcard to return "everything I am authorized to see". > Something like the PoCo query model? --00248c768f9ec75a1104bdd118ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 16, 2012 at 12:07 PM, Derek Atki= ns <derek@ihtfp.com= > wrote:
I think there are two main differerences between webfinger and swd:

a) whole-document vs. individual attributes
b) a perceived authorization model to control access to said attributes

In particular I feel there are some specific security requirements that
must be bet by the protocol, but I think it's easily accomplished by a small amount of text that effectively says:

1) requestors of the service should authenticate (or be treated as an
=C2=A0 anonymous user)
2) content returned must be dynamic and dependent on the authorization
=C2=A0 of the authenticated user.

I think r= equesters MAY authenticate, not SHOULD.=C2=A0
=C2=A0

This leaves only the perceived issue of "whole document" vs "= ;individual
attribute". =C2=A0If a client ever wants more than one attribute then = a whole
document approach reduces the number of round trips. =C2=A0However if
documents get large that could also affect performance. =C2=A0We might, the= n,
need a way to specify which attributes are requested, but allow for a
wildcard to return "everything I am authorized to see".

Something like the PoCo query model?=C2=A0
=
--00248c768f9ec75a1104bdd118ce-- From eran@hueniverse.com Tue Apr 17 12:19: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 D955811E80D5 for ; Tue, 17 Apr 2012 12:19:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3OueLEdM8Ia for ; Tue, 17 Apr 2012 12:19:05 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDBB11E80CE for ; Tue, 17 Apr 2012 12:19:05 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id z7K41i0070EuLVk017K4RW; Tue, 17 Apr 2012 12:19:04 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Tue, 17 Apr 2012 12:19:04 -0700 From: Eran Hammer To: Dick Hardt Thread-Topic: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer Thread-Index: AQHNHLofIuyx/camh0qzKFNvw3YPcpafZDIA Date: Tue, 17 Apr 2012 19:19:03 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0@P3PWEX2MB008.ex2.secureserver.net> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> In-Reply-To: <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [63.79.89.152] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0P3PWEX2MB008ex2se_" MIME-Version: 1.0 Cc: Ned Freed , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss , Mark Nottingham , Pete Resnick Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 19:19:07 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0P3PWEX2MB008ex2se_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That has nothing to do with this issue. The protected resources API format = was never part of OAuth at any time. EH From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, April 17, 2012 9:50 AM To: Eran Hammer Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; draft-ietf-o= auth-v2-bearer.all@tools.ietf.org; Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oaut= h-v2-bearer On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote: (Sticking with the naivety:-) So, what's different there from how the base oauth draft registers client_id and shows how that can be used in a GET request? [1] Big difference. The base draft specifies its own endpoints as part of a com= plete API package for obtaining authorization. These parameters are scoped = only for the endpoints defined and not for any others. There is no possibil= ity of conflict because the specification defines the entire namespace. OTOH, the bearer spec is applied to *any* web resources using OAuth authent= ication where some other namespace definition must exist. If we had kept it all in one spec as it had originally been drafted, this w= ould not be an issue, and it would be easier for implementers to understand= . I don't know of anyone looking to implement the bearer spec independent o= f the base spec. (would be interested if anyone does know of an implementat= ion) --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0P3PWEX2MB008ex2se_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That has nothing to do wi= th this issue. The protected resources API format was never part of OAuth a= t any time.

 <= /p>

EH

 <= /p>

From: Dick Har= dt [mailto:dick.hardt@gmail.com]
Sent: Tuesday, April 17, 2012 9:50 AM
To: Eran Hammer
Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; draft= -ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss
Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ie= tf-oauth-v2-bearer

 

 

On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote:



(Sticking with the naivety:-) So, wha= t's different there from how the base

oauth draft registers client_id and s= hows how that can be used in a GET

request? [1]


Big difference. The base draft specifies its own endpoints as part of a com= plete API package for obtaining authorization. These parameters are scoped = only for the endpoints defined and not for any others. There is no possibil= ity of conflict because the specification defines the entire namespace.

OTOH, the bearer spec is applied to *any* web resources using OAuth authent= ication where some other namespace definition must exist.=

 

 

If we had kept it all in one spec as it had original= ly been drafted, this would not be an issue, and it would be easier for imp= lementers to understand. I don't know of anyone looking to implement the be= arer spec independent of the base spec. (would be interested if anyone does know of an implementation)<= /o:p>

 

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0P3PWEX2MB008ex2se_-- From melvincarvalho@gmail.com Tue Apr 17 12:41: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 6080511E80D5 for ; Tue, 17 Apr 2012 12:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLmW+XAruwap for ; Tue, 17 Apr 2012 12:41:53 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA9C11E80D0 for ; Tue, 17 Apr 2012 12:41:52 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5170213vbb.31 for ; Tue, 17 Apr 2012 12:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AN4xXwGVdsJl2t7f4Oy/uBF+6WcPqXdAaJyBbWtatXA=; b=QlT4Uvo1rv2orSSV5phCtvwnR16fm4QUuPnRDYbGadiKSbq2x0lmiB/j5nhE0wINr2 hhUkhg8a9ynazneqGGbkh+pGS9fHR6ARYdanT1MtbmZwHpee2X+jGk9A3E7uB0WeIYY/ JRtyZELdWmY/tmwFYiYrvpsMR0oPNesmvbQ4a4RXzOxvrYZ2/1PdbukW9zqIxCsTNX64 6Owgcw7NVc39/Oy7p6bYMYrT0NiqsDEuzQJCiiNCmzBSrk4fPxlj0U5OTUN4GauL+bEH yvyi/3/FwPuXvkP7BrOhIODmLDGul2zgHD6RHDDiZcKqUxpJ0/lq5ka+uWJOpSMXzZgr 87ag== MIME-Version: 1.0 Received: by 10.220.153.8 with SMTP id i8mr1864863vcw.73.1334691712244; Tue, 17 Apr 2012 12:41:52 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Tue, 17 Apr 2012 12:41:52 -0700 (PDT) In-Reply-To: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 17 Apr 2012 21:41:52 +0200 Message-ID: From: Melvin Carvalho To: Bob Wyman Content-Type: multipart/alternative; boundary=f46d043be068649cb804bde52146 Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 19:41:58 -0000 --f46d043be068649cb804bde52146 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 17 April 2012 17:06, Bob Wyman wrote: > On Tue, Apr 17, 2012 at 10:02 AM, Melvin Carvalho < > melvincarvalho@gmail.com> wrote: > > I dont know of anyone in the community (and correct me if this has > changed) that really loves acct:, or perhaps even likes the acct: idea. > Well, I like acct:. I like it precisely because it is NOT that same as > mailto:. Acct: provides me a way to identify myself or some other entity > without the identifier granting (explicitly or implicitly) any particular > capability to those who discover it. Acct: separates the functions of > identity from the mechanisms of communication. It allows one to talk abou= t > someone without necessarily knowing how to send them mail. This is a good > thing! (Even if it irritates some spammers...) > > I first worked on developing an email and "office automation" system > (DEC's ALL-IN-1) over 30 years ago and it has always bothered me that the > mere act of assuming an identity in a distributed system implicitly grant= s > anyone who discovers that identity the ability to gain access to my > messaging system. Acct: resolves this problem or data leak. Also, Acct: > allows services that provide value to the network without providing email > services to uniquely identify people and to provide profile services. For > instance, as far as I know, you still can't "send email" to a Twitter use= r. > Yet, Twitter identifiers are, in many realms, exceptionally important. I > have no idea if Twitter would want to do such a thing, but if they did wa= nt > to provide WebFinger or profile services, why in the world would we force > them to use a mailto: (which implies email support) as a means of > identifying their accounts? Would Twitter have to implement email before > they could implement WebFinger? Wouldn't it be reasonable to allow Twitte= r > to implement a WebFinger service that mapped from Twitter acct: identifie= rs > to mailto:'s on other services? (I may be acct:bobwyman@twitter.com but > receive email as mailto:bob@example.com) If not, why not? The same > question holds, of course, for any number of other discussion forums, > social networks, etc. that offer services other than email. it is > unreasonable to say that only those who implement email can be identity, > profile or WebFinger providers. > > > How do we get from acct: to mailto:? > To get from acct: to mailto: using WebFinger, you would have to rely on > someone telling you how. Either the mapping would be expressed in the > document itself or there would be a link to a service that does, in fact, > provide the mapping. Of course, that service could and in many cases shou= ld > impose some access control when determining who can discover the mailto:t= hat corresponds to a particular acct:. In fact, it would be entirely > reasonable that there would be a one to many mapping from acct: to mailto= :and thus the acct: to mailto:mapping would be specific to a requestor or g= roup of requestors. > While it is useful to me to have a widely known and consistent identity, > it is not the case that everyone should know or have access to the same > mailbox when sending me messages. (Consider the extreme case of President > Obama... Certainly, we'd all like to refer to him with some consistent an= d > broadly known identifier (perhaps: pres_obama@whitehouse.gov") but that > doesn't mean that we should all be able to send messages to the same > mailbox that his wife or his Chief of Staff uses...) > > Acct: is a good thing. We've lived with the inadequacies of using mailto:= as an identifier far too long. It is time that we separate the mechanisms > of "identity" from the mechanisms of any of the specific services that > might rely on or leverage identity. A mailto: should be used to send > mail. An acct: should be used to name people or entities. These are > distinct functions. They should be distinct names (even when they look th= e > same...) > > Now, you know at least one person who likes acct:. Hopefully, you also > understand why. > Thank you for your comments. I was unaware that anyone actually liked acct:. The question still remains as to whether the extra layer of complexity justifies its inclusion. The other thing I find confusing is: how then do you get from a mailto:identifer, to an acct: identifier? Is it simply string substitution on the scheme e.g. s/^mailto/acct/? From what you have written above this simple substitution seems not guaranteed to work. So, how do you do it correctly, if it is necessary to perform a webfinger lookup? > > bob wyman > > > On Tue, Apr 17, 2012 at 10:02 AM, Melvin Carvalho < > melvincarvalho@gmail.com> wrote: > >> >> >> On 16 April 2012 22:41, Mike Jones wrote: >> >>> You can read a lot of the rationale for why Simple Web Discovery was >>> developed in these posts: >>> http://www.goland.org/simplewebfinger/ >>> http://www.goland.org/managingfingerservice/ >>> >> >> >> Thanks for sharing this >> >> A couple of points: >> >> 1. JSON >> =3D=3D=3D=3D=3D=3D=3D >> >> I think at the time webfinger was created in 2009, XML was the de facto >> serialization, used in AJAX, SOAP and many other systems. Today I'm >> hearing more and more, that both developers and publishers, want to work >> with JSON, rather than, having to support both xml and json. Content >> negotiation also confuses some publishers. In my view, this is a great >> simplification that webfinger can learn from SWD. >> >> 2. acct: scheme >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> The acct: URI scheme has not proved popular, imho, and has added a layer >> of complexity and confusion. How do we get from acct: to mailto:? When >> should you use acct: and when mailto: (the spec says acct:user@host may >> be different from mailto:user@host). What about the forms. How about >> linked data ecosystems that want to cross link identifiers, do they now >> have to consider both cases? >> >> From the original post introducing acct: >> >> "I don=92t expect everyone to like this idea. I wish I could say I love = it, >> but I am simply content with it." >> >> I dont know of anyone in the community (and correct me if this has >> changed) that really loves acct:, or perhaps even likes the acct: idea. >> SWD has shown you can do discovery without acct: and I think that's a bi= g >> plus. >> >> >> >> >> One final side note is that this almost becomes trivial when you can do >> SPARQL queries. "void" is already registered by the W3C with IANA in >> .well-known in order to discover SPARQL endpoints. It may be overkill i= n >> some people's eyes, but Linked Data (which predates webfinger), >> particularly newer things like JSON LD, are a lot bigger than they were = in >> 2009. In a few years it may become the definitive discovery mechanism >> anyway. >> >> >>> >>> BTW, I'll point out that Stephen requested that we move this discussion >>> to the Apps Discuss list, so while I'm replying here, people should fol= low >>> up there. (Although I'll warn you, the traffic volume there is fierce = - >>> even compared to the OAuth list at its high water marks.) >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: apps-discuss-bounces@ietf.org [mailto: >>> apps-discuss-bounces@ietf.org] On Behalf Of Peter Saint-Andre >>> Sent: Monday, April 16, 2012 10:56 AM >>> To: Murray S. Kucherawy >>> Cc: Apps Discuss >>> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web >>> Discovery (SWD) >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 4/13/12 11:45 AM, Murray S. Kucherawy wrote: >>> >> -----Original Message----- From: apps-discuss-bounces@ietf.org >>> >> [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Stephen Farrell >>> >> Sent: Friday, April 13, 2012 9:23 AM To: oauth@ietf.org WG Cc: Apps >>> >> Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple >>> >> Web Discovery (SWD) >>> >> >>> >> So Hannes and Derek and I have been discussing this with the Apps AD= s >>> >> and Apps-area WG chairs. I've also read the docs now, and after all >>> >> that we've decided that this topic (what to do with swd and >>> >> webfinger) is best handled in the apps area and not in the oauth WG. >>> >> >>> >> The logic for that is that 1) the two proposals are doing the same >>> >> thing and we don't want two different standards for that, b) this is >>> >> not an oauth-specific thing nor is it a general security thing, and >>> >> c) there is clearly already interest in the topic in the apps area s= o >>> >> its reasonable for the oauth wg to use that when its ready. >>> >> >>> >> The appsawg chairs and apps ADs are ok with the work being done >>> >> there. >>> >> >>> >> So:- >>> >> >>> >> - I've asked the oauth chairs to take doing work on swd out of the >>> >> proposed new charter - It may be that you want to add something >>> >> saying that oauth will use the results of work in the applications >>> >> area on a web discovery protocol as a basis for doing the dynamic >>> >> client registration work here - Discussion of webfinger and swd >>> >> should move over to the apps-discuss list - >>> >> Note: this is not picking one or the other approach, the plan is tha= t >>> >> the apps area will do any selection needed and figure out the best >>> >> starting point for a standards-track RFC on web discovery and we'll >>> >> use their fine work for doing more with oauth. >>> > >>> > Thank you Stephen, I think. :-) >>> > >>> > So the discussion on apps-discuss now should be focused on which of >>> > the two should be the basis for forward progress. I've placed both >>> > documents in "Call for Adoption" state in the datatracker for appsawg= . >>> > >>> > Let the games begin. >>> >>> I've just had a chance to review both I-Ds: >>> >>> https://datatracker.ietf.org/doc/draft-jones-appsawg-webfinger/ (-03) >>> >>> http://datatracker.ietf.org/doc/draft-jones-simple-web-discovery/ (-02) >>> >>> Although at a later time I will provide more detailed feedback, I am >>> left wondering why Simple Web Discovery was developed. It appears to so= lve >>> the same problem as WebFinger (which predates SWD by several years as f= ar >>> as I can see) in similar ways (/.well-known/ etc.), with a few tweaks a= nd >>> optimizations (some of which might be premature IMHO). >>> >>> Thus I think it would be helpful for the authors of SWD to explain why >>> they didn't use WebFinger, or provide feedback that would improve WebFi= nger >>> if it didn't address some of their use cases (I note that the more rece= nt >>> WebFinger I-Ds include some SWD-ish features, such as the "resource" >>> parameter -- whether that is a good thing remains to be determined). >>> Although draft-jones-simple-web-discovery does not contain such an >>> analysis, perhaps someone posted it to the OAUTH WG list or elsewhere, = in >>> which case I apologize for having missed it. >>> >>> Peter >>> >>> - -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAk+MXSIACgkQNL8k5A2w/vzR4ACffCIM6A/RBj/y6RdyiudN+AF2 >>> deMAoKmuesVvyS8yYVb0sqYXqCJnQF8+ >>> =3D3OKr >>> -----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 >>> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > --f46d043be068649cb804bde52146 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 17 April 2012 17:06, Bob Wyman <bob@wyman.us>= wrote:
On Tue, Apr 17, 2012 at 10:02 AM, Melvin Carvalho=A0= <melvincar= valho@gmail.com>=A0wrote:
>= ;=A0I dont know of anyone in the community (and correct me if this has chan= ged) that really loves acct:, or perhaps even likes the acct: idea.
Well, I like acct:. I like it precisely because it is NOT that same as mail= to:. Acct: provides me a way to identify myself or some other entity withou= t the identifier granting (explicitly or implicitly) any particular capabil= ity to those who discover it. Acct: separates the functions of identity fro= m the mechanisms of communication. It allows one to talk about someone with= out necessarily knowing how to send them mail. This is a good thing! (Even = if it irritates some spammers...)

I first worked on developing an email and "office autom= ation" system (DEC's ALL-IN-1) over 30 years ago and it has always= bothered me that the mere act of assuming an identity in a distributed sys= tem implicitly grants anyone who discovers that identity the ability to gai= n access to my messaging system. Acct: resolves this problem or data leak. = Also, Acct: allows services that provide value to the network without provi= ding email services to uniquely identify people and to provide profile serv= ices. For instance, as far as I know, you still can't "send email&= quot; to a Twitter user. Yet, Twitter identifiers are, in many realms, exce= ptionally important. I have no idea if Twitter would want to do such a thin= g, but if they did want to provide WebFinger or profile services, why in th= e world would we force them to use a mailto: (which implies email support) = as a means of identifying their accounts? Would Twitter have to implement e= mail before they could implement WebFinger? Wouldn't it be reasonable t= o allow Twitter to implement a WebFinger service that mapped from Twitter a= cct: identifiers to mailto:'s on other services? (I may be acct:bobwyman@twitter.= com but receive email as mailto:bob@example.com) If not, why not? The same question holds= , of course, for any number of other discussion forums, social networks, et= c. that offer services other than email. it is unreasonable to say that onl= y those who implement email can be identity, profile or WebFinger providers= .

>=A0How do we get from acct: to ma= ilto:?
To get from acct: to mailto: using WebFinger, you would hav= e to rely on someone telling you how. Either the mapping would be expressed= in the document itself or there would be a link to a service that does, in= fact, provide the mapping. Of course, that service could and in many cases= should impose some access control when determining who can discover the ma= ilto: that corresponds to a particular acct:. In fact, it would be entirely= reasonable that there would be a one to many mapping from acct: to mailto:= and thus the acct: to mailto: mapping would be specific to a requestor or = group of requestors.=A0
While it is useful to me to have a widely known and consistent identit= y, it is not the case that everyone should know or have access to the same = mailbox when sending me messages. (Consider the extreme case of President O= bama... Certainly, we'd all like to refer to him with some consistent a= nd broadly known identifier (perhaps: pres_obama@whitehouse.gov") but that doe= sn't mean that we should all be able to send messages to the same mailb= ox that his wife or his Chief of Staff uses...)

Acct: is a good thing. We've lived with the inadequacies of using m= ailto: as an identifier far too long. It is time that we separate the mecha= nisms of "identity" from the mechanisms of any of the specific se= rvices that might rely on or leverage identity. A mailto: should be used to= send mail. An acct: should be used to name people or entities. These are d= istinct functions. They should be distinct names (even when they look the s= ame...)

Now, you know at least one person who likes acct:. Hopefully, you also = understand why.

Thank you for your comments.=A0 = I was unaware that anyone actually liked acct:.=A0 The question still remai= ns as to whether the extra layer of complexity justifies its inclusion.

The other thing I find confusing is: how then do you get from a mailto:= identifer, to an acct: identifier?=A0 Is it simply string substitution on = the scheme e.g. s/^mailto/acct/?=A0 From what you have written above this s= imple substitution seems not guaranteed to work.=A0 So, how do you do it co= rrectly, if it is necessary to perform a webfinger lookup?
=A0

bob wyman


On Tue, Apr 17, 2012 at 10:02 AM, Melvin= Carvalho <melvincarvalho@gmail.com> wrote:


On 1= 6 April 2012 22:41, Mike Jones <Michael.Jones@microsoft.com&= gt; wrote:
You can read a lot of the rationale for why Simple Web Discovery was develo= ped in these posts: =A0 =A0 =A0 =A0 =A0http://www.goland.org/simplewebfinger/=
=A0 =A0 =A0 =A0http://www.goland.org/managingfingerservice/


Thanks for sharing this

A couple of points:=

1. JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the time webfinger was created in 2= 009, XML was the de facto serialization, used in AJAX, SOAP and many other = systems.=A0 Today I'm hearing more and more, that both developers and p= ublishers, want to work with JSON, rather than, having to support both xml = and json.=A0 Content negotiation also confuses some publishers.=A0 In my vi= ew, this is a great simplification that webfinger can learn from SWD.

2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The a= cct: URI scheme has not proved popular, imho, and has added a layer of comp= lexity and confusion.=A0 How do we get from acct: to mailto:?=A0 When shoul= d you use acct: and when mailto: (the spec says acct:user@host may be diffe= rent from mailto:user@host).=A0 What about the forms.=A0 How about linked data ecosystems that want= to cross link identifiers, do they now have to consider both cases?=A0
From the original post introducing acct:

"I don=92t expect = everyone to like this idea. I wish I could say I love it, but I am simply c= ontent with it."

I dont know of anyone in the community (and co= rrect me if this has changed) that really loves acct:, or perhaps even like= s the acct: idea.=A0 SWD has shown you can do discovery without acct: and I= think that's a big plus.




One final side note is that this almost becomes trivial whe= n you can do SPARQL queries.=A0 "void" is already registered by t= he W3C with IANA in .well-known in order to discover SPARQL endpoints.=A0 I= t may be overkill in some people's eyes, but Linked Data (which predate= s webfinger), particularly newer things like JSON LD, are a lot bigger than= they were in 2009.=A0 In a few years it may become the definitive discover= y mechanism anyway.
=A0

BTW, I'll point out that Stephen requested that we move this discussion= to the Apps Discuss list, so while I'm replying here, people should fo= llow up there. =A0(Although I'll warn you, the traffic volume there is = fierce - even compared to the OAuth list at its high water marks.)

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

-----Original Message-----
From: ap= ps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behal= f Of Peter Saint-Andre
Sent: Monday, April 16, 2012 10:56 AM
To: Murray S. Kucherawy
Cc: Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)

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

On 4/13/12 11:45 AM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: apps-discuss-bounces@ietf.org
>> [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Stephen Farrell >> Sent: Friday, April 13, 2012 9:23 AM To: oauth@ietf.org WG Cc: Apps
>> Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simp= le
>> Web Discovery (SWD)
>>
>> So Hannes and Derek and I have been discussing this with the Apps = ADs
>> and Apps-area WG chairs. I've also read the docs now, and afte= r all
>> that we've decided that this topic (what to do with swd and >> webfinger) is best handled in the apps area and not in the oauth W= G.
>>
>> The logic for that is that 1) the two proposals are doing the same=
>> thing and we don't want two different standards for that, b) t= his is
>> not an oauth-specific thing nor is it a general security thing, an= d
>> c) there is clearly already interest in the topic in the apps area= so
>> its reasonable for the oauth wg to use that when its ready.
>>
>> The appsawg chairs and apps ADs are ok with the work being done >> there.
>>
>> So:-
>>
>> - I've asked the oauth chairs to take doing work on swd out of= the
>> proposed new charter - It may be that you want to add something >> saying that oauth will use the results of work in the applications=
>> area on a web discovery protocol as a basis for doing the dynamic<= br> >> client registration work here - Discussion of webfinger and swd >> should move over to the apps-discuss list -
>> Note: this is not picking one or the other approach, the plan is t= hat
>> the apps area will do any selection needed and figure out the best=
>> starting point for a standards-track RFC on web discovery and we&#= 39;ll
>> use their fine work for doing more with oauth.
>
> Thank you Stephen, I think. =A0:-)
>
> So the discussion on apps-discuss now should be focused on which of > the two should be the basis for forward progress. =A0I've placed b= oth
> documents in "Call for Adoption" state in the datatracker fo= r appsawg.
>
> Let the games begin.

I've just had a chance to review both I-Ds:

https://datatracker.ietf.org/doc/draft-jones-appsawg-web= finger/ (-03)

http://datatracker.ietf.org/doc/draft-jones-simple-web= -discovery/ (-02)

Although at a later time I will provide more detailed feedback, I am left w= ondering why Simple Web Discovery was developed. It appears to solve the sa= me problem as WebFinger (which predates SWD by several years as far as I ca= n see) in similar ways (/.well-known/ etc.), with a few tweaks and optimiza= tions (some of which might be premature IMHO).

Thus I think it would be helpful for the authors of SWD to explain why they= didn't use WebFinger, or provide feedback that would improve WebFinger= if it didn't address some of their use cases (I note that the more rec= ent WebFinger I-Ds include some SWD-ish features, such as the "resourc= e" parameter -- whether that is a good thing remains to be determined)= . Although draft-jones-simple-web-discovery does not contain such an analys= is, perhaps someone posted it to the OAUTH WG list or elsewhere, in which c= ase I apologize for having missed it.

Peter

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

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

iEYEARECAAYFAk+MXSIACgkQNL8k5A2w/vzR4ACffCIM6A/RBj/y6RdyiudN+AF2
deMAoKmuesVvyS8yYVb0sqYXqCJnQF8+
=3D3OKr
-----END PGP SIGNATURE-----
_______________________________________________
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



--f46d043be068649cb804bde52146-- From wmills@yahoo-inc.com Tue Apr 17 13:16: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 C5CA011E80C6 for ; Tue, 17 Apr 2012 13:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.927 X-Spam-Level: X-Spam-Status: No, score=-15.927 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_50=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjXIRSdy3Pe9 for ; Tue, 17 Apr 2012 13:16:19 -0700 (PDT) Received: from nm2.bullet.mail.bf1.yahoo.com (nm2.bullet.mail.bf1.yahoo.com [98.139.212.161]) by ietfa.amsl.com (Postfix) with SMTP id 6ABB511E80BA for ; Tue, 17 Apr 2012 13:16:19 -0700 (PDT) Received: from [98.139.212.145] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 17 Apr 2012 20:16:18 -0000 Received: from [98.139.212.244] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 17 Apr 2012 20:16:18 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 17 Apr 2012 20:16:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 526244.64960.bm@omp1053.mail.bf1.yahoo.com Received: (qmail 86659 invoked by uid 60001); 17 Apr 2012 20:16:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334693778; bh=PNnpQOX9puBtjqfk/qeD/zyxS/7duH02CPA9O+qRIWM=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=V2ZbbRKR0C9KB5QIO1AbTW56X9ZRecj7fRk37Rgg2u9zrxWujXaFu3FC63IDi2wMjnGB9oQM6WLJQUtac8RMdlGSaISdUbUkTCX1v6LUO46FxQnEvdZhOm0HWEBhKhWw4BidooFrf5Vg0+1B1K4UJAhwGX2JVIEVdI+89jC4K2I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tWRcH7ZlnpZFnHqDFtYiVfS5bLRQzsKCHQS9SHDE6jnv7CkYFpcHRm9mFwOCz7A3bBpG3DNPfVBEHqXfvvGIMInoiVUuHISZ3qYM4imORj+kXgpbNuoyWLMRFgMLjOHQ18TNxJVhEFian7Lyjq4Gu65KuUwdYjkamdSRrJwJj70=; X-YMail-OSG: KqcxKpEVM1mhZusYyLYIX895GafqLYciZR8yoP9Prcq6leb 4TOXDA3TTJeknSwZwwL_n8SLimKYo2Kn08PVCCHLc80JYGrqqXOSS0533UUO qJR0OVTXEeOjzEK62sy0OymxW.vkrAyHSsVsgBHTJdzg1.XOAs4B8K3xVTGt Pdwa4XBN4L0pvnYoztFDAYMH1gtF4AGPD2qTvcld0FsldKXPYOK6VxA4rcw. _1BsoYTIMyAGfADxHPdK8MfmItL8g.pIlr_CwCelphi9edpnmbGI1TPN_nC8 AYCsgmtNVxuhF9Era.32ycwwLueRR2X7wRWksQ_Or9xLHKW5zjxLeuEsPWP3 rNuZQ_bgwl3mSxtYbIxIPfTnGUGo6NJrh7ty3CBXdA3cWfxR4YGGNg0sdres 6OpOfcNIUwJDzI5cGEtEcmanaQPsJOzuhaA-- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Tue, 17 Apr 2012 13:16:17 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 Message-ID: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Tue, 17 Apr 2012 13:16:17 -0700 (PDT) From: William Mills To: "apps-discuss@ietf.org" , ddraft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: The IESG Subject: [apps-discuss] APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 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: Tue, 17 Apr 2012 20:16:24 -0000 =0A=0ADocument:=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0 draft-ietf-kitten-gssapi-nami= ng-exts-14=0ATitle: =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0 GSS-API Naming Ext= ensions=0AReviewer:=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0 William J. Mills=0AReview= Date:=A0=A0=A0=A0=A0=A0=A0 =A0 April 17, 2012=0AIETF Last Call Date:=A0 N/= A=0AIESG Telechat Date:=A0=A0 N/A=0A=0A=0ASummary: This draft is nearly rea= dy for publication, some corrections are suggested.=0A=0A=0AMajor Issues: = =0A=0A=0ASection 5, 9th paragraph:=A0 The first sentence is not declarative= enough, "Local implementations or platforms are likely to have sufficient = policy and information to know when contexts can be treated as the same.", = I'd prefer changing "Are likely" to "MUST", and then add "and MUST NOT assu= me different attributes are equivalent" at the end of that sentence.=A0 =0A= =0A=0AMinor Issues:=A0=0A=0ASection 7.6, last paragraph: strike "; this has= been discussed on the KITTEN WG mailing list and the consensus seems to be= that, indeed, that was always the intention".=A0 It's not required to note= WG consensus, and this is implicit in document adoption.=0A=0AGenerally:= =A0 I wonder at the choice of not including ABNF for things like attribute = name, since you're defining a syntax here.=A0 It's well enough defined in t= he text, but I generally think of parseable syntax as being more explicitly= defined with ABNF.=0A=0ANits: =0A=0A=0ASection 3, 3rd paragraph: "follows.= This"needs spaces.=0A=0ASection 9, 3rd para: "asserte" needs a "d".=A0 "Any= additional semantics is always the result of applying policy.", change "is= " to "are". From wmills@yahoo-inc.com Tue Apr 17 13:25: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 A3DB321F844B for ; Tue, 17 Apr 2012 13:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.206 X-Spam-Level: X-Spam-Status: No, score=-17.206 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4fmyaA2EN-z for ; Tue, 17 Apr 2012 13:25:26 -0700 (PDT) Received: from nm29-vm0.bullet.mail.ac4.yahoo.com (nm29-vm0.bullet.mail.ac4.yahoo.com [98.139.52.248]) by ietfa.amsl.com (Postfix) with SMTP id AA07F21F844D for ; Tue, 17 Apr 2012 13:25:26 -0700 (PDT) Received: from [98.139.52.188] by nm29.bullet.mail.ac4.yahoo.com with NNFMP; 17 Apr 2012 20:25:22 -0000 Received: from [98.139.52.184] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 17 Apr 2012 20:25:22 -0000 Received: from [127.0.0.1] by omp1067.mail.ac4.yahoo.com with NNFMP; 17 Apr 2012 20:25:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 917149.93286.bm@omp1067.mail.ac4.yahoo.com Received: (qmail 93281 invoked by uid 60001); 17 Apr 2012 20:25:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334694322; bh=AIP6Q7jI4Ry9rFl33d0smZ27TRIhR3ge3Za0ZAhv3J8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EbVBxolyCbiWEMGWxAXQx/g34N/K1bjenF1ocjA6m9soDLyWJCFup95gjliHCqXRiYbjOARpN/N9MbMaybAueaZI5eZ0rqh1HtFFdEhceyBYZ+1cvq/qMM5FGUldJ7HAEcwArT/uECs2yBATw32wMlGG9O66wMiXZE9SS4C3jCo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WACNg2Tt5e0makuqaYozTW0dsizVo1OXIBPQRVtYuNe/jxNXiv5khIh4rv5fHJZooNnV8hE/WIaDO4ifRFbd9eCN+EeXUqHrLCsDuGdPOooZoKAiXQ2UhCxoaIA3S4HdKb2gtMG/LORTU2bxYOg+994y1aLdBtXAG6UorQ5rO78=; X-YMail-OSG: himyLUMVM1mZhV5HhR8A9aMEcTpp77RP6obRcanBgRWXbaT VrsMsPge4NhJZWDIDM_g0LeSZtki6RFmavY8enz01cWr3Ep2gsKDJnKNIs9v G57IJbM37u9n2fbQRIZxmElCcKBeXc.FaA.1vBGVSORLdVs1M4eZ3XLzpXR1 SGqCT9hocqSBiKxKIESgaThKB4ptM0wyU6Avp3_nH8H3Md9v5yM4wDN1_NE. 9SpSt5wNevTt2P5_9HdGFq7B1ipDBUCKl3pkYy_Vm44YRGEsoXPeqBQEC0_Z 2uJq9.X1iiEPT2YD8DXQPjWlf4nwv03hL5IMWEQKOJtWFL_tYwtmNxi2wlNG Q4onS06RfJCbXnQzJnWtXqf44EGdt4xN1qilU5Wocg4VF_XaBpohMGm6VFzK ar6tSJcZmU8oXfIhoUchReZ9wFoHIvxr6ZPuI94yZX4xVoYS8KsN8j82.Ug- - Received: from [209.131.62.115] by web31809.mail.mud.yahoo.com via HTTP; Tue, 17 Apr 2012 13:25:22 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> Message-ID: <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Tue, 17 Apr 2012 13:25:22 -0700 (PDT) From: William Mills To: "apps-discuss@ietf.org" , draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org In-Reply-To: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-528781310-1334694322=:78096" Cc: The IESG Subject: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 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: Tue, 17 Apr 2012 20:25:30 -0000 ---1395015409-528781310-1334694322=:78096 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable (Resend to the correct addresses)=0A=0A=0A=0ADocument:=A0 =A0=A0=A0 =A0=A0= =A0 =A0=A0 draft-ietf-kitten-gssapi-naming-exts-14=0ATitle: =A0=A0=A0 =A0= =A0=A0 =A0=A0=A0 =A0=A0 GSS-API Naming Extensions=0AReviewer:=A0 =A0=A0=A0 = =A0=A0=A0 =A0=A0 William J. Mills=0AReview Date:=A0=A0=A0=A0=A0=A0=A0 =A0 A= pril 17, 2012=0AIETF Last Call Date:=A0 N/A=0AIESG Telechat Date:=A0=A0 N/A= =0A=0A=0ASummary: This draft is nearly ready for publication, some correcti= ons are suggested.=0A=0A=0AMajor Issues: =0A=0A=0ASection=0A 5, 9th paragra= ph:=A0 The first sentence is not declarative enough, "Local=0A implementati= ons or platforms are likely to have sufficient policy and =0Ainformation to= know when contexts can be treated as the same.", I'd =0Aprefer changing "A= re likely" to "MUST", and then add "and MUST NOT =0Aassume different attrib= utes are equivalent" at the end of that =0Asentence.=A0 =0A=0A=0AMinor Issu= es:=A0=0A=0ASection 7.6, last =0Aparagraph: strike "; this has been discuss= ed on the KITTEN WG mailing =0Alist and the consensus seems to be that, ind= eed, that was always the =0Aintention".=A0 It's not required to note WG con= sensus, and this is =0Aimplicit in document adoption.=0A=0AGenerally:=A0 I = wonder at the choice=0A of not including ABNF for things like attribute nam= e, since you're =0Adefining a syntax here.=A0 It's well enough defined in t= he text, but I =0Agenerally think of parseable syntax as being more explici= tly defined =0Awith ABNF.=0A=0ANits: =0A=0A=0ASection 3, 3rd paragraph: "fo= llows.This"needs spaces.=0A=0ASection=0A 9, 3rd para: "asserte" needs a "d"= .=A0 "Any additional semantics is =0Aalways the result of applying policy."= , change "is" to "are". ---1395015409-528781310-1334694322=:78096 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
(Resend to the correct addresses)

Document:             draft-i= etf-kitten-gssapi-naming-exts-14
Title:       &= nbsp;        GSS-API Naming Extensions
Reviewer= :             William J. Mills=
Review Date:          April 17,= 2012
IETF Last Call Date:  N/A
IESG Telechat Date:   = N/A


Summary: This draft is nearly ready for publication, some co= rrections are suggested.


Major Issues:


Section=0A 5,= 9th paragraph:  The first sentence is not declarative enough, "Local= =0A implementations or platforms are likely to have sufficient policy and = =0Ainformation to know when contexts can be treated as the same.", I'd =0Ap= refer changing "Are likely" to "MUST", and then add "and MUST NOT =0Aassume= different attributes are equivalent" at the end of that =0Asentence. =


Minor Issues: 

Section 7.6, last =0Aparagraph: str= ike "; this has been discussed on the KITTEN WG mailing =0Alist and the con= sensus seems to be that, indeed, that was always the =0Aintention".  I= t's not required to note WG consensus, and this is =0Aimplicit in document = adoption.

Generally:  I wonder at the choice=0A of not includin= g ABNF for things like attribute name, since you're =0Adefining a syntax he= re.  It's well enough defined in the text, but I =0Agenerally think of= parseable syntax as being more explicitly defined =0Awith ABNF.

Nit= s:


Section 3, 3rd paragraph: "follows.This"needs spaces.
Section=0A 9, 3rd para: "asserte" needs a "d".  "Any additional seman= tics is =0Aalways the result of applying policy.", change "is" to "are".
---1395015409-528781310-1334694322=:78096-- From hartmans@mit.edu Tue Apr 17 13:36:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E82711E80A0; Tue, 17 Apr 2012 13:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.987 X-Spam-Level: X-Spam-Status: No, score=-102.987 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eLm5J2CS02P; Tue, 17 Apr 2012 13:36:31 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 985A011E8073; Tue, 17 Apr 2012 13:36:31 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [203.41.199.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A17B72053A; Tue, 17 Apr 2012 16:32:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6EEAD4766; Tue, 17 Apr 2012 16:36:26 -0400 (EDT) From: Sam Hartman To: William Mills References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Tue, 17 Apr 2012 16:36:26 -0400 In-Reply-To: <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> (William Mills's message of "Tue, 17 Apr 2012 13:25:22 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org, "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 20:36:32 -0000 >>>>> "William" == William Mills writes: William> Major Issues: William> Section 5, 9th paragraph: The first sentence is not William> declarative enough, "Local implementations or platforms are William> likely to have sufficient policy and information to know William> when contexts can be treated as the same.", I'd prefer William> changing "Are likely" to "MUST", and then add "and MUST NOT William> assume different attributes are equivalent" at the end of William> that sentence. I'm confused when I read the above proposed change because I don't actually understand its affect. I'm generally against the change because I think the current text actually describes the reality of the situation. I think the proposed text describes something else, and I'm not sure that something else is actually a true statement about how implementations will behave. So, I'd like to understand your proposal better. From bobwyman@gmail.com Tue Apr 17 13:42: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 98A9421F845C for ; Tue, 17 Apr 2012 13:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cypKRcS5e-mJ for ; Tue, 17 Apr 2012 13:42:01 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A87121F845A for ; Tue, 17 Apr 2012 13:42:01 -0700 (PDT) Received: by qcsq13 with SMTP id q13so4959352qcs.31 for ; Tue, 17 Apr 2012 13:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0iJUUmQaE7C89RUDEJ3EdnLNfl/Qfl6pYnsN1KgP1ig=; b=07TspdfqKKT2ezwEYVzBW1+e9e85u7d8UxEAShXNrWIC8SvLBqrALMIdEA7bRAfJzH NEJPP1V1W95kLIq2ScyygefRR73pNTI/09XAsDjND66SOPOeHVf+MmnCvuTcX/gcsR3h ef96UE/v1jcVqLo59CLjsxK5VqG+huZ5FUBaXx9E8ougzdaPTJDs/2QXyXGYg3c7s34U LRacCEKPXa7M/BXgBVizRjog/zsjaOyaN9AjFkPIKqTdhyjKFGv/LpshRKQ2r0gq+FlG 6hf/aqo9MW0KXXA4cwqw0WaubdaOVF9GzgpBRRFAxZ1phb5EXGeG11rXS3OcyAvY/RfV 0e/g== MIME-Version: 1.0 Received: by 10.224.101.72 with SMTP id b8mr179455qao.53.1334695318614; Tue, 17 Apr 2012 13:41:58 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.12.194 with HTTP; Tue, 17 Apr 2012 13:41:57 -0700 (PDT) In-Reply-To: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 17 Apr 2012 16:41:57 -0400 X-Google-Sender-Auth: zZmvl2S2X4qyoO2zcZMG9A815I4 Message-ID: From: Bob Wyman To: Melvin Carvalho Content-Type: multipart/alternative; boundary=20cf30667c2f59721304bde5f812 Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 20:42:06 -0000 --20cf30667c2f59721304bde5f812 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Apr 17, 2012 at 3:41 PM, Melvin Carvalho wrote: > > > On 17 April 2012 17:06, Bob Wyman wrote: > >> On Tue, Apr 17, 2012 at 10:02 AM, Melvin Carvalho < >> melvincarvalho@gmail.com> wrote: >> > I dont know of anyone in the community (and correct me if this has >> changed) that really loves acct:, or perhaps even likes the acct: idea. >> Well, I like acct:. I like it precisely because it is NOT that same as >> mailto:. Acct: provides me a way to identify myself or some other entity >> without the identifier granting (explicitly or implicitly) any particula= r >> capability to those who discover it. Acct: separates the functions of >> identity from the mechanisms of communication. It allows one to talk abo= ut >> someone without necessarily knowing how to send them mail. This is a goo= d >> thing! (Even if it irritates some spammers...) >> >> I first worked on developing an email and "office automation" system >> (DEC's ALL-IN-1) over 30 years ago and it has always bothered me that th= e >> mere act of assuming an identity in a distributed system implicitly gran= ts >> anyone who discovers that identity the ability to gain access to my >> messaging system. Acct: resolves this problem or data leak. Also, Acct: >> allows services that provide value to the network without providing emai= l >> services to uniquely identify people and to provide profile services. Fo= r >> instance, as far as I know, you still can't "send email" to a Twitter us= er. >> Yet, Twitter identifiers are, in many realms, exceptionally important. I >> have no idea if Twitter would want to do such a thing, but if they did w= ant >> to provide WebFinger or profile services, why in the world would we forc= e >> them to use a mailto: (which implies email support) as a means of >> identifying their accounts? Would Twitter have to implement email before >> they could implement WebFinger? Wouldn't it be reasonable to allow Twitt= er >> to implement a WebFinger service that mapped from Twitter acct: identifi= ers >> to mailto:'s on other services? (I may be acct:bobwyman@twitter.com but >> receive email as mailto:bob@example.com) If not, why not? The same >> question holds, of course, for any number of other discussion forums, >> social networks, etc. that offer services other than email. it is >> unreasonable to say that only those who implement email can be identity, >> profile or WebFinger providers. >> >> > How do we get from acct: to mailto:? >> To get from acct: to mailto: using WebFinger, you would have to rely on >> someone telling you how. Either the mapping would be expressed in the >> document itself or there would be a link to a service that does, in fact= , >> provide the mapping. Of course, that service could and in many cases sho= uld >> impose some access control when determining who can discover the mailto:= that corresponds to a particular acct:. In fact, it would be entirely >> reasonable that there would be a one to many mapping from acct: to mailt= o:and thus the acct: to mailto:mapping would be specific to a requestor or = group of requestors. >> While it is useful to me to have a widely known and consistent identity, >> it is not the case that everyone should know or have access to the same >> mailbox when sending me messages. (Consider the extreme case of Presiden= t >> Obama... Certainly, we'd all like to refer to him with some consistent a= nd >> broadly known identifier (perhaps: pres_obama@whitehouse.gov") but that >> doesn't mean that we should all be able to send messages to the same >> mailbox that his wife or his Chief of Staff uses...) >> >> Acct: is a good thing. We've lived with the inadequacies of using mailto= :as an identifier far too long. It is time that we separate the mechanisms >> of "identity" from the mechanisms of any of the specific services that >> might rely on or leverage identity. A mailto: should be used to send >> mail. An acct: should be used to name people or entities. These are >> distinct functions. They should be distinct names (even when they look t= he >> same...) >> >> Now, you know at least one person who likes acct:. Hopefully, you also >> understand why. >> > > Thank you for your comments. I was unaware that anyone actually liked > acct:. The question still remains as to whether the extra layer of > complexity justifies its inclusion. > Distinguishing between "acct:" and "mailto:" isn't really *adding*complexity, rather, it is just recognizing the complexity that actually exists in the system. We all have many identifiers. Some of them are simply unique tokens (SSN, driver's license, passport number) and others are actually the identifiers of proxies that are associated with us for various purposes (i.e. email addresses, postal addresses, telephone numbers.). Certainly, the email address is the most commonly used form of identifier, but that is anecdotal and while it may be convenient, the exclusive reliance on mailto: causes all sorts of problems. For instance, you may know my mailto: but that won't always help you figure out my XMPP address. Similarly, I may wish that you interact with me via Twitter, not email, but if I don't want mail from you while you insist on identifying me via mailto= :, then we can't communicate even if both of us are on Twitter. There is also the interesting problem that is caused by the fact that email addresses are much more ephemeral than are the people who are associated with them. Today, I work for Google, but in 10 years, or three months, who knows? If you want to send me an email in the future, it would be really helpful for you to have some identity such as bobwyman@linkedin.com (even though LinkedIn doesn't provide email accounts...) so that you could use some yet-to-be-implemented LInkedIn WebFinger service to figure out my email address... Asking for acct: doesn't add complexity, it actually makes a great number of things much simpler. The reason is that it gets the set of identifiers that we use to more accurately model the complexity of the real world. > > The other thing I find confusing is: how then do you get from a mailto:id= entifer, to an acct: identifier? Is it simply string substitution on the > scheme e.g. s/^mailto/acct/? > There need be no correlation between an acct: and a mailto: URI. These things are completely orthogonal -- even though they will often appear to be very similar. In order to determine the mailto: associated with an acct: you would need the mapping to be explicitly stated as part of the WebFinger document. Something like the following might do: "subject" : "acct:alice@example.com", "links" : [ { "rel" : "http://webfinger.net/rel/ mailto", "href" : "mailto:alice277@example.com" } ] } Of course, someone might also come up with a SWD-like system that would add a level of indirection here. The WebFinger document would then point to an "Acct2Mailto Mapping Service" that allowed one to authenticate and receive an appropriate mailto: in response to a query. > From what you have written above this simple substitution seems not > guaranteed to work. So, how do you do it correctly, if it is necessary t= o > perform a webfinger lookup? > Yes, to discover information about me, you must do a lookup on the WebFinger discovery service. Certainly, this could be made "simpler." But, as Einstein would have said, the mechanism "should be as simple as possible, but no simpler." Any attempt to make things "simpler" by obscuring the difference between an identifier for a person and the identifier for that person's email inbox is, I believe, an attempt to make things simpler than possible. (i.e. to make it so simple that important information is lost and thus while some things become more simple, others become either hard or impossible.). > >> >> bob wyman >> >> >> On Tue, Apr 17, 2012 at 10:02 AM, Melvin Carvalho < >> melvincarvalho@gmail.com> wrote: >> >>> >>> >>> On 16 April 2012 22:41, Mike Jones wrote: >>> >>>> You can read a lot of the rationale for why Simple Web Discovery was >>>> developed in these posts: >>>> http://www.goland.org/simplewebfinger/ >>>> http://www.goland.org/managingfingerservice/ >>>> >>> >>> >>> Thanks for sharing this >>> >>> A couple of points: >>> >>> 1. JSON >>> =3D=3D=3D=3D=3D=3D=3D >>> >>> I think at the time webfinger was created in 2009, XML was the de facto >>> serialization, used in AJAX, SOAP and many other systems. Today I'm >>> hearing more and more, that both developers and publishers, want to wor= k >>> with JSON, rather than, having to support both xml and json. Content >>> negotiation also confuses some publishers. In my view, this is a great >>> simplification that webfinger can learn from SWD. >>> >>> 2. acct: scheme >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> The acct: URI scheme has not proved popular, imho, and has added a laye= r >>> of complexity and confusion. How do we get from acct: to mailto:? >>> When should you use acct: and when mailto: (the spec says acct:user@hos= tmay be different from mailto: >>> user@host). What about the forms. How about linked data ecosystems >>> that want to cross link identifiers, do they now have to consider both >>> cases? >>> >>> From the original post introducing acct: >>> >>> "I don=92t expect everyone to like this idea. I wish I could say I love >>> it, but I am simply content with it." >>> >>> I dont know of anyone in the community (and correct me if this has >>> changed) that really loves acct:, or perhaps even likes the acct: idea. >>> SWD has shown you can do discovery without acct: and I think that's a b= ig >>> plus. >>> >>> >>> >>> >>> One final side note is that this almost becomes trivial when you can do >>> SPARQL queries. "void" is already registered by the W3C with IANA in >>> .well-known in order to discover SPARQL endpoints. It may be overkill = in >>> some people's eyes, but Linked Data (which predates webfinger), >>> particularly newer things like JSON LD, are a lot bigger than they were= in >>> 2009. In a few years it may become the definitive discovery mechanism >>> anyway. >>> >>> >>>> >>>> BTW, I'll point out that Stephen requested that we move this discussio= n >>>> to the Apps Discuss list, so while I'm replying here, people should fo= llow >>>> up there. (Although I'll warn you, the traffic volume there is fierce= - >>>> even compared to the OAuth list at its high water marks.) >>>> >>>> -- Mike >>>> >>>> -----Original Message----- >>>> From: apps-discuss-bounces@ietf.org [mailto: >>>> apps-discuss-bounces@ietf.org] On Behalf Of Peter Saint-Andre >>>> Sent: Monday, April 16, 2012 10:56 AM >>>> To: Murray S. Kucherawy >>>> Cc: Apps Discuss >>>> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web >>>> Discovery (SWD) >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 4/13/12 11:45 AM, Murray S. Kucherawy wrote: >>>> >> -----Original Message----- From: apps-discuss-bounces@ietf.org >>>> >> [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Stephen Farrell >>>> >> Sent: Friday, April 13, 2012 9:23 AM To: oauth@ietf.org WG Cc: Apps >>>> >> Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simpl= e >>>> >> Web Discovery (SWD) >>>> >> >>>> >> So Hannes and Derek and I have been discussing this with the Apps A= Ds >>>> >> and Apps-area WG chairs. I've also read the docs now, and after all >>>> >> that we've decided that this topic (what to do with swd and >>>> >> webfinger) is best handled in the apps area and not in the oauth WG= . >>>> >> >>>> >> The logic for that is that 1) the two proposals are doing the same >>>> >> thing and we don't want two different standards for that, b) this i= s >>>> >> not an oauth-specific thing nor is it a general security thing, and >>>> >> c) there is clearly already interest in the topic in the apps area = so >>>> >> its reasonable for the oauth wg to use that when its ready. >>>> >> >>>> >> The appsawg chairs and apps ADs are ok with the work being done >>>> >> there. >>>> >> >>>> >> So:- >>>> >> >>>> >> - I've asked the oauth chairs to take doing work on swd out of the >>>> >> proposed new charter - It may be that you want to add something >>>> >> saying that oauth will use the results of work in the applications >>>> >> area on a web discovery protocol as a basis for doing the dynamic >>>> >> client registration work here - Discussion of webfinger and swd >>>> >> should move over to the apps-discuss list - >>>> >> Note: this is not picking one or the other approach, the plan is th= at >>>> >> the apps area will do any selection needed and figure out the best >>>> >> starting point for a standards-track RFC on web discovery and we'll >>>> >> use their fine work for doing more with oauth. >>>> > >>>> > Thank you Stephen, I think. :-) >>>> > >>>> > So the discussion on apps-discuss now should be focused on which of >>>> > the two should be the basis for forward progress. I've placed both >>>> > documents in "Call for Adoption" state in the datatracker for appsaw= g. >>>> > >>>> > Let the games begin. >>>> >>>> I've just had a chance to review both I-Ds: >>>> >>>> https://datatracker.ietf.org/doc/draft-jones-appsawg-webfinger/ (-03) >>>> >>>> http://datatracker.ietf.org/doc/draft-jones-simple-web-discovery/ (-02= ) >>>> >>>> Although at a later time I will provide more detailed feedback, I am >>>> left wondering why Simple Web Discovery was developed. It appears to s= olve >>>> the same problem as WebFinger (which predates SWD by several years as = far >>>> as I can see) in similar ways (/.well-known/ etc.), with a few tweaks = and >>>> optimizations (some of which might be premature IMHO). >>>> >>>> Thus I think it would be helpful for the authors of SWD to explain why >>>> they didn't use WebFinger, or provide feedback that would improve WebF= inger >>>> if it didn't address some of their use cases (I note that the more rec= ent >>>> WebFinger I-Ds include some SWD-ish features, such as the "resource" >>>> parameter -- whether that is a good thing remains to be determined). >>>> Although draft-jones-simple-web-discovery does not contain such an >>>> analysis, perhaps someone posted it to the OAUTH WG list or elsewhere,= in >>>> which case I apologize for having missed it. >>>> >>>> Peter >>>> >>>> - -- >>>> Peter Saint-Andre >>>> https://stpeter.im/ >>>> >>>> >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>>> >>>> iEYEARECAAYFAk+MXSIACgkQNL8k5A2w/vzR4ACffCIM6A/RBj/y6RdyiudN+AF2 >>>> deMAoKmuesVvyS8yYVb0sqYXqCJnQF8+ >>>> =3D3OKr >>>> -----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 >>>> >>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> >> > --20cf30667c2f59721304bde5f812 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 17, 2012 at 3:41 PM, = Melvin Carvalho <melvincarvalho@gmail.com> wrote:


On 17 April 2012 17:06= , Bob Wyman <bob@wyman.us> wrote:
On Tue, Apr 17, 2012 at 10:02 AM, Melvin Carvalho=A0= <melvincar= valho@gmail.com>=A0wrote:
>=A0I dont kn= ow of anyone in the community (and correct me if this has changed) that rea= lly loves acct:, or perhaps even likes the acct: idea.
Well, I like acct:. I like it precisely because it is NOT that same as mail= to:. Acct: provides me a way to identify myself or some other entity withou= t the identifier granting (explicitly or implicitly) any particular capabil= ity to those who discover it. Acct: separates the functions of identity fro= m the mechanisms of communication. It allows one to talk about someone with= out necessarily knowing how to send them mail. This is a good thing! (Even = if it irritates some spammers...)

I first worked on developing an email and "office autom= ation" system (DEC's ALL-IN-1) over 30 years ago and it has always= bothered me that the mere act of assuming an identity in a distributed sys= tem implicitly grants anyone who discovers that identity the ability to gai= n access to my messaging system. Acct: resolves this problem or data leak. = Also, Acct: allows services that provide value to the network without provi= ding email services to uniquely identify people and to provide profile serv= ices. For instance, as far as I know, you still can't "send email&= quot; to a Twitter user. Yet, Twitter identifiers are, in many realms, exce= ptionally important. I have no idea if Twitter would want to do such a thin= g, but if they did want to provide WebFinger or profile services, why in th= e world would we force them to use a mailto: (which implies email support) = as a means of identifying their accounts? Would Twitter have to implement e= mail before they could implement WebFinger? Wouldn't it be reasonable t= o allow Twitter to implement a WebFinger service that mapped from Twitter a= cct: identifiers to mailto:'s on other services? (I may be acct:bobwyman@twitter.= com but receive email as mailto:bob@example.com) If not, why not? The same question holds= , of course, for any number of other discussion forums, social networks, et= c. that offer services other than email. it is unreasonable to say that onl= y those who implement email can be identity, profile or WebFinger providers= .

>=A0How do we get from acct: to mailto:?
To get from acct: to mailto: using WebFinger, you would have to rely on = someone telling you how. Either the mapping would be expressed in the docum= ent itself or there would be a link to a service that does, in fact, provid= e the mapping. Of course, that service could and in many cases should impos= e some access control when determining who can discover the mailto: that co= rresponds to a particular acct:. In fact, it would be entirely reasonable t= hat there would be a one to many mapping from acct: to mailto: and thus the= acct: to mailto: mapping would be specific to a requestor or group of requ= estors.=A0
While it is useful to me to have a widely known and consistent identit= y, it is not the case that everyone should know or have access to the same = mailbox when sending me messages. (Consider the extreme case of President O= bama... Certainly, we'd all like to refer to him with some consistent a= nd broadly known identifier (perhaps: pres_obama@whitehouse.gov") but that doe= sn't mean that we should all be able to send messages to the same mailb= ox that his wife or his Chief of Staff uses...)

Acct: is a good thing. We've lived with the inadequacies of using m= ailto: as an identifier far too long. It is time that we separate the mecha= nisms of "identity" from the mechanisms of any of the specific se= rvices that might rely on or leverage identity. A mailto: should be used to= send mail. An acct: should be used to name people or entities. These are d= istinct functions. They should be distinct names (even when they look the s= ame...)

Now, you know at least one person who likes acct:. Hopefully, you also = understand why.

Thank you for your comment= s.=A0 I was unaware that anyone actually liked acct:.=A0 The question still= remains as to whether the extra layer of complexity justifies its inclusio= n.

Distinguishing between "a= cct:" and "mailto:" isn't really adding complexit= y, rather, it is just recognizing the complexity that actually exists in th= e system. We all have many identifiers. Some of them are simply unique toke= ns (SSN, driver's license, passport number) and others are actually the= identifiers of proxies that are associated with us for various purposes (i= .e. email addresses, postal addresses, telephone numbers.). Certainly, the = email address is the most commonly used form of identifier, but that is ane= cdotal and while it may be convenient, the exclusive reliance on mailto: ca= uses all sorts of problems. For instance, you may know my mailto: but that = won't always help you figure out my XMPP address. Similarly, I may wish= that you interact with me via Twitter, not email, but if I don't want = mail from you while you insist on identifying me via mailto:, then we can&#= 39;t communicate even if both of us are on Twitter. There is also the inter= esting problem that is caused by the fact that email addresses are much mor= e ephemeral than are the people who are associated with them. Today, I work= for Google, but in 10 years, or three months, who knows? If you want to se= nd me an email in the future, it would be really helpful for you to have so= me identity such as bobwyman@linke= din.com (even though LinkedIn doesn't provide email accounts...) so= that you could use some yet-to-be-implemented LInkedIn WebFinger service t= o figure out my email address... Asking for acct: doesn't add complexit= y, it actually makes a great number of things much simpler. The reason is t= hat it gets the set of identifiers that we use to more accurately model the= complexity of the real world.=A0
=A0

The other thing I find confusing is: how then do you get from a mailto:= identifer, to an acct: identifier?=A0 Is it simply string substitution on = the scheme e.g. s/^mailto/acct/?
There need be= no correlation between an acct: and a mailto: URI. These things are comple= tely orthogonal -- even though they will often appear to be very similar. I= n order to determine the mailto: associated with an acct: you would need th= e mapping to be explicitly stated as part of the WebFinger document. Someth= ing like the following might do:

       "subject" : "acct:alice@example.com",
       "links" :
       [
         {
           "rel" : "http://webfinger.net/rel/mailto",
           "href" : "mailto:alice277@example.com"
         }
       ]
     }

Of course, someone might also come up with = a SWD-like system that would add a level of indirection here. The WebFinger= document would then point to an "Acct2Mailto Mapping Service" th= at allowed one to authenticate and receive an appropriate mailto: in respon= se to a query.
=A0
=A0 From what you have written above this simple substitution seems not g= uaranteed to work.=A0 So, how do you do it correctly, if it is necessary to= perform a webfinger lookup?
Yes, to discover information about me, you mu= st do a lookup on the WebFinger discovery service.
=A0
= Certainly, this could be made "simpler." But, as Einstein would h= ave said, the mechanism "should be as simple as possible, but no simpl= er." Any attempt to make things "simpler" by obscuring the d= ifference between an identifier for a person and the identifier for that pe= rson's email inbox is, I believe, an attempt to make things simpler tha= n possible. (i.e. to make it so simple that important information is lost a= nd thus while some things become more simple, others become either hard or = impossible.).

=A0

bob wyman
<= div>

On Tue, Apr 17, 2012 at 10:02 AM, Melvin= Carvalho <melvincarvalho@gmail.com> wrote:


On 1= 6 April 2012 22:41, Mike Jones <Michael.Jones@microsoft.com&= gt; wrote:
You can read a lot of the rationale for why Simple Web Discovery was develo= ped in these posts: =A0 =A0 =A0 =A0 =A0http://www.goland.org/simplewebfinger/=
=A0 =A0 =A0 =A0http://www.goland.org/managingfingerservice/


Thanks for sharing this

A couple of points:=

1. JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the time webfinger was created in 2= 009, XML was the de facto serialization, used in AJAX, SOAP and many other = systems.=A0 Today I'm hearing more and more, that both developers and p= ublishers, want to work with JSON, rather than, having to support both xml = and json.=A0 Content negotiation also confuses some publishers.=A0 In my vi= ew, this is a great simplification that webfinger can learn from SWD.

2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The a= cct: URI scheme has not proved popular, imho, and has added a layer of comp= lexity and confusion.=A0 How do we get from acct: to mailto:?=A0 When shoul= d you use acct: and when mailto: (the spec says acct:user@host may be diffe= rent from mailto:user@host).=A0 What about the forms.=A0 How about linked data ecosystems that want= to cross link identifiers, do they now have to consider both cases?=A0
From the original post introducing acct:

"I don=92t expect = everyone to like this idea. I wish I could say I love it, but I am simply c= ontent with it."

I dont know of anyone in the community (and co= rrect me if this has changed) that really loves acct:, or perhaps even like= s the acct: idea.=A0 SWD has shown you can do discovery without acct: and I= think that's a big plus.




One final side note is that this almost becomes trivial whe= n you can do SPARQL queries.=A0 "void" is already registered by t= he W3C with IANA in .well-known in order to discover SPARQL endpoints.=A0 I= t may be overkill in some people's eyes, but Linked Data (which predate= s webfinger), particularly newer things like JSON LD, are a lot bigger than= they were in 2009.=A0 In a few years it may become the definitive discover= y mechanism anyway.
=A0

BTW, I'll point out that Stephen requested that we move this discussion= to the Apps Discuss list, so while I'm replying here, people should fo= llow up there. =A0(Although I'll warn you, the traffic volume there is = fierce - even compared to the OAuth list at its high water marks.)

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

-----Original Message-----
From: ap= ps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behal= f Of Peter Saint-Andre
Sent: Monday, April 16, 2012 10:56 AM
To: Murray S. Kucherawy
Cc: Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)

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

On 4/13/12 11:45 AM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: apps-discuss-bounces@ietf.org
>> [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Stephen Farrell >> Sent: Friday, April 13, 2012 9:23 AM To: oauth@ietf.org WG Cc: Apps
>> Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simp= le
>> Web Discovery (SWD)
>>
>> So Hannes and Derek and I have been discussing this with the Apps = ADs
>> and Apps-area WG chairs. I've also read the docs now, and afte= r all
>> that we've decided that this topic (what to do with swd and >> webfinger) is best handled in the apps area and not in the oauth W= G.
>>
>> The logic for that is that 1) the two proposals are doing the same=
>> thing and we don't want two different standards for that, b) t= his is
>> not an oauth-specific thing nor is it a general security thing, an= d
>> c) there is clearly already interest in the topic in the apps area= so
>> its reasonable for the oauth wg to use that when its ready.
>>
>> The appsawg chairs and apps ADs are ok with the work being done >> there.
>>
>> So:-
>>
>> - I've asked the oauth chairs to take doing work on swd out of= the
>> proposed new charter - It may be that you want to add something >> saying that oauth will use the results of work in the applications=
>> area on a web discovery protocol as a basis for doing the dynamic<= br> >> client registration work here - Discussion of webfinger and swd >> should move over to the apps-discuss list -
>> Note: this is not picking one or the other approach, the plan is t= hat
>> the apps area will do any selection needed and figure out the best=
>> starting point for a standards-track RFC on web discovery and we&#= 39;ll
>> use their fine work for doing more with oauth.
>
> Thank you Stephen, I think. =A0:-)
>
> So the discussion on apps-discuss now should be focused on which of > the two should be the basis for forward progress. =A0I've placed b= oth
> documents in "Call for Adoption" state in the datatracker fo= r appsawg.
>
> Let the games begin.

I've just had a chance to review both I-Ds:

https://datatracker.ietf.org/doc/draft-jones-appsawg-web= finger/ (-03)

http://datatracker.ietf.org/doc/draft-jones-simple-web= -discovery/ (-02)

Although at a later time I will provide more detailed feedback, I am left w= ondering why Simple Web Discovery was developed. It appears to solve the sa= me problem as WebFinger (which predates SWD by several years as far as I ca= n see) in similar ways (/.well-known/ etc.), with a few tweaks and optimiza= tions (some of which might be premature IMHO).

Thus I think it would be helpful for the authors of SWD to explain why they= didn't use WebFinger, or provide feedback that would improve WebFinger= if it didn't address some of their use cases (I note that the more rec= ent WebFinger I-Ds include some SWD-ish features, such as the "resourc= e" parameter -- whether that is a good thing remains to be determined)= . Although draft-jones-simple-web-discovery does not contain such an analys= is, perhaps someone posted it to the OAUTH WG list or elsewhere, in which c= ase I apologize for having missed it.

Peter

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

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

iEYEARECAAYFAk+MXSIACgkQNL8k5A2w/vzR4ACffCIM6A/RBj/y6RdyiudN+AF2
deMAoKmuesVvyS8yYVb0sqYXqCJnQF8+
=3D3OKr
-----END PGP SIGNATURE-----
_______________________________________________
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




--20cf30667c2f59721304bde5f812-- From wmills@yahoo-inc.com Tue Apr 17 13: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 A275E11E80BA for ; Tue, 17 Apr 2012 13:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.193 X-Spam-Level: X-Spam-Status: No, score=-17.193 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y4kdQnp+aPB for ; Tue, 17 Apr 2012 13:42:14 -0700 (PDT) Received: from nm7.bullet.mail.ac4.yahoo.com (nm7.bullet.mail.ac4.yahoo.com [98.139.52.204]) by ietfa.amsl.com (Postfix) with SMTP id A8EA811E80A0 for ; Tue, 17 Apr 2012 13:42:14 -0700 (PDT) Received: from [98.139.52.196] by nm7.bullet.mail.ac4.yahoo.com with NNFMP; 17 Apr 2012 20:42:10 -0000 Received: from [98.139.52.168] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 17 Apr 2012 20:42:10 -0000 Received: from [127.0.0.1] by omp1051.mail.ac4.yahoo.com with NNFMP; 17 Apr 2012 20:42:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 556284.27826.bm@omp1051.mail.ac4.yahoo.com Received: (qmail 44151 invoked by uid 60001); 17 Apr 2012 20:42:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334695329; bh=jFbi6cbd0XyLUoQS/T3tC5fn5aGlCkyKYNjZMt06CWw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mhVxPwj82HYAv308uCNPbp0FGEStSefe2ANwtg8iLyk9Zm/ZowNXp8sVxdIxb7Q6xSF/snyqY086auyYb3uoUNAkkRTE/956LeWsY8dtHh9qvCjaaHOhFfd3lX6jL9NsNEc03Dll4odh3FvrMWbsgp5qXcM+LyHXQlCrP4Wh1P8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DDBsBg31pPcxIeD5VG+pNC8ZY6GwxR792kQEh6tz6yYvvuiqM5mzjPNPeDiOYbxamgCqTQGibou1AVLd8xsFWPsvetTTCf8/ciF8qqrIaejmGVa1eo937qxkd2Zwx+UjYgRj2v3Z8Ks91GRMZGVds0rBJRVdG5eEF4gGBW7vxak=; X-YMail-OSG: zq0aJQcVM1nd0JWPfT66oV3H0d_0pHFOasmKSSZ7i6AKDL4 FzJR0p3k9tFw0Nt2QToeQpv_Gg2Wk4XYAnseqA6INDQqKiY94iFZcgraKUtA CjTWyn._9iWgnsbXgBHBs5twmQ5f0nexxsw39q_2eNsTU3DED9SPY4vwKlGa 5QB.EXUPDddEe3Rlp0plxey.wa2po4PJAvs0_aI0.R1bGZxynS_GDrTjWlkl nulsOMPIV7CdbmBmt37TOTaujLDT8lgvRG.65A5h9dGyEba0cAZtYp4tavnW zWAhX3SDt9kkq93rwLnQ.GS64MYs.ho2s43MhOYcFeMWT2qIjJl9pC4uGdKt qWYym8xHN.owCgqtFGcARlnEZ02u4PZOCHFu_bfqhESI.zVPzCLAlQ7LvWS7 CDB1_8XWpagwFlKv9noAaEMnU8mjtR4gGTXm5TPdMS50k.EEBZEE- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Tue, 17 Apr 2012 13:42:09 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> Message-ID: <1334695329.43020.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Tue, 17 Apr 2012 13:42:09 -0700 (PDT) From: William Mills To: Sam Hartman In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-1233360273-1334695329=:43020" Cc: "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 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: Tue, 17 Apr 2012 20:42:18 -0000 --1458549034-1233360273-1334695329=:43020 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The key of this for me is "are likely to have sufficient policy and informa= tion".=A0 This is fine in discussion, but I want to see an explicit declara= tion about when an implementation can treat things as equivalent.=0A=0A-bil= l=0A=0A=0A=0A>________________________________=0A> From: Sam Hartman =0A>To: William Mills =0A>Cc: "apps= -discuss@ietf.org" ; draft-ietf-kitten-gssapi-naming= -exts.all@tools.ietf.org; The IESG =0A>Sent: Tuesday, April= 17, 2012 1:36 PM=0A>Subject: Re: Resending: APPSDIR review of draft-ietf-k= itten-gssapi-naming-exts-14=0A> =0A>>>>>> "William" =3D=3D William Mills writes:=0A>=0A>=A0 =A0 William> Major Issues:=0A>=0A>= =0A>=A0 =A0 William> Section 5, 9th paragraph: The first sentence is not=0A= >=A0 =A0 William> declarative enough, "Local implementations or platforms a= re=0A>=A0 =A0 William> likely to have sufficient policy and information to = know=0A>=A0 =A0 William> when contexts can be treated as the same.", I'd pr= efer=0A>=A0 =A0 William> changing "Are likely" to "MUST", and then add "and= MUST NOT=0A>=A0 =A0 William> assume different attributes are equivalent" a= t the end of=0A>=A0 =A0 William> that sentence.=0A>=0A>I'm confused when I = read the above proposed change because I don't=0A>actually understand its a= ffect.=0A>=0A>I'm generally against the change because I think the current = text=0A>actually describes the reality of the situation. I think the propos= ed=0A>text describes something else, and I'm not sure that something else i= s=0A>actually a true statement about how implementations will behave.=0A>So= , I'd like to understand your proposal better.=0A>=0A>=0A> --1458549034-1233360273-1334695329=:43020 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The key of this for me is "are likely to have sufficient policy an= d information".  This is fine in discussion, but I want to see an expl= icit declaration about when an implementation can treat things as equivalen= t.

-bill

From: Sam Hartman <hartmans-ietf@mit.edu>
<= span style=3D"font-weight: bold;">To: William Mills <wmills@yahoo-inc.com>
Cc:= "apps-discuss@ietf.org" <apps-discuss@ietf.org>; draft-ie= tf-kitten-gssapi-naming-exts.all@tools.ietf.org; The IESG <iesg@ietf.org= >
Sent: Tuesday, A= pril 17, 2012 1:36 PM
Subject: Re: Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-e= xts-14

=0A>>>>> "William" =3D=3D Will= iam Mills <wmills@yahoo-inc.com> writes:

   = ; William> Major Issues:


    William> Section 5,= 9th paragraph: The first sentence is not
    William> decl= arative enough, "Local implementations or platforms are
    Wi= lliam> likely to have sufficient policy and information to know
 = ;   William> when contexts can be treated as the same.", I'd prefer=
    William> changing "Are likely" to "MUST", and then add= "and MUST NOT
    William> assume different attributes are= equivalent" at the end of
    William> that sentence.
<= br>I'm confused when I read the above proposed change because I don't
ac= tually understand its affect.

I'm generally against the change becau= se I think the current text
actually describes the reality of the situation. I think the propo= sed
text describes something else, and I'm not sure that something else = is
actually a true statement about how implementations will behave.
S= o, I'd like to understand your proposal better.


<= /blockquote>
--1458549034-1233360273-1334695329=:43020-- From hartmans@mit.edu Tue Apr 17 13:48: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 8482D21F84A1; Tue, 17 Apr 2012 13:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.807 X-Spam-Level: X-Spam-Status: No, score=-102.807 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wM6u6vnnLhas; Tue, 17 Apr 2012 13:48:03 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id B4E7821F84A0; Tue, 17 Apr 2012 13:48:03 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [203.41.199.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 11957207B7; Tue, 17 Apr 2012 16:43:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B037D4766; Tue, 17 Apr 2012 16:48:00 -0400 (EDT) From: Sam Hartman To: William Mills References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> <1334695329.43020.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Tue, 17 Apr 2012 16:48:00 -0400 In-Reply-To: <1334695329.43020.YahooMailNeo@web31812.mail.mud.yahoo.com> (William Mills's message of "Tue, 17 Apr 2012 13:42:09 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 20:48:04 -0000 >>>>> "William" == William Mills writes: William> The key of this for me is "are likely to have sufficient William> policy and information". This is fine in discussion, but I William> want to see an explicit declaration about when an William> implementation can treat things as equivalent. I don't think we can say anything about that. Implementations can treat things as equivalent when they know that it's safe to do so through policy which may be hard-coded, configured or downloaded from somewhere. I think that's an implementation matter outside the scope of the standard. From paulej@packetizer.com Tue Apr 17 14:41: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 4B56811E80AD for ; Tue, 17 Apr 2012 14:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-fJvhftNm+E for ; Tue, 17 Apr 2012 14:41:22 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8816111E80A6 for ; Tue, 17 Apr 2012 14:41:22 -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 q3HLfLUO032427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2012 17:41:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334698881; bh=gJYb6/zWEy6Fb1DMC0Iuld7E1HJAgbsKb83Be7XPhoU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=qHtlhhjcxQ8W27j/NW4RNys4Ghdu5AWjx2l4gBOFnJw+9CAiv+8j+X57eNmXcuLqn 2fInSzatSaPSSiGFHVIfgar+dzFQyOGfYRXlSk0uUIYIQ6+V8zkN8Y6ubWF1o0uiEa s0E48g5iXfz6H+TE5GDvMHvri+94wdfVf4kv68ns= From: "Paul E. Jones" To: "'Mike Jones'" , "'Apps Discuss'" References: <4E1F6AAD24975D4BA5B1680429673943664673CC@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664673CC@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 17 Apr 2012 17:41:37 -0400 Message-ID: <04ca01cd1ce2$de6351d0$9b29f570$@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: AQKPlvkFuMt6EaaXTVuLCqi20s3H0pUafgpg Content-Language: en-us Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 21:41:27 -0000 Mike, et al, Sorry for the belated response. I've been out of the office for a few days. > FEATURE COMPARISON > > RESULT GRANULARITY AND PRIVACY CHARACTERISTICS: SWD returns the resource > location(s) for a specific resource for a specific principal. As > described in the current spec, WebFinger appears to return all resources > for the principal, by default. The example at > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2 > "Retrieving a Person's Contact Information" is telling. As described, > WebFinger usage model seems to be "I'll get everything about you and then > look through it to decide what to do with it." The assumption that > WebFinger information is normally public also appears to be built into the > protocol where the CORS response header "Access-Control-Allow-Origin: *" > is mandated, per http://tools.ietf.org/html/draft-jones-appsawg-webfinger- > 03#section-7. The default privacy characteristics of these approaches > appear to be different. (It's these very same privacy characteristics > that led sysadmins to nearly ubiquitously disabling the fingerd service!) To be clear, WebFinger publishes links to information about people, not the information about a person. So, I might publish a link to my contact information, access to that URL might be protected in some way. Further, the contents returned may vary depending on access rights. In an enterprise, for example, I would expect a response to one's Portable Contacts information to be different than what might be shared externally. However, those decisions are separate from WebFinger: it's policies applied to different resources referenced by WebFinger. In general, WebFinger will provide a complete list of link relations. Again, this might be restricted in some cases (e.g., external vs. internal query), but may not be. > SWD intentionally supports different permissioning on different resources > for particular principals by reusing existing Internet mechanisms - > specifically depending upon whether and how the requester is > authenticated, different discovery requests may or may not be granted. > (In a recent OAuth thread, Blaine Cook pointed out that the set of > resources returned by WebFinger could be filtered using the same > mechanisms, which is true. If that's the intent, I believe that should be > made explicit in the WebFinger document. And yes, we should make the > intention to use Internet authentication mechanisms explicit in the SWD > draft as well.) I think you are saying that /.well-known/simple-web-discovery is a protected resource, correct? As noted above, one could equally protect /.well-known/host-meta and the LRDD resource. There is nothing that restricts the use of various HTTP authorization mechanisms w.r.t. Host Metadata or LRDD. For WebFinger or SWD to be a useful Internet service, though, a provider of information should share some link relations publicly. Still, the choice is up to the provider of that information. > DOCUMENT VERSUS API MODEL, DEPLOYABILITY: WebFinger is built on a > "document model", where a single document is returned that contains > multiple resources for a principal. SWD is built on an "API model", where > the location(s) of a particular resource for a principal are returned. > The problem with the document model is that different parties or services > may be authoritative for different resources for a given principal, and > yet all need the rights to edit or provide portions of the resulting > document. This can hurt deployability, because document edits then need > to be coordinated among parties that may have different rights and > responsibilities. (Just because I can change your avatar doesn't mean > that I should be able to change your mail server.) The document to which you refer is merely the collection of link relations returned about a principal. Whether one queries for a specific link relation ("service") or all link relations, you have the same problem: the link relations and type of link relation related to a principal must be known to the /.well-known/ service. The people involved in defining WebFinger elected to return all link relations by default, allowing the client to select the one(s) it wanted to use. I personally find that very attractive, since I would not have to issue multiple queries to find information stored as vcard, Portable Contacts, etc. If there is a specific link relation of interest, identifying that is trivial. So, both proposals on the table return a "document". The difference is the amount of information (i.e., the number of links) provided by default, I think. > In a recent OAuth thread, Blaine Cook responded to this characterization > by pointing out that the document model and the resource model are > isomorphic, since Web documents can be and often are dynamically composed, > which is certainly true. If a document model is adopted that can return > multiple resources, with different parties having different permissions to > write to those resources, that effectively forces these documents to be > dynamically composed by a service, for security and privacy reasons. Of > course that's doable, but seems less straight-forward to me. With my own WebFinger implementation, all link relations and link relation types are pulled out of a database upon request. Input into that database is an entirely different function separate from WebFinger itself. Are you concerned about how the server learns about link relations, or are you concerned with how a particular web resource referenced by those link relations is updated? These are different steps. It seems that with either SWD or WebFinger, the challenges are the same. > REDIRECT FUNCTIONALITY AND DEPLOYABILTY: SWD includes the ability to > redirect some or all SWD requests to another location (possibly depending > upon the specific resource and principal parameters). Deployers hosting > numerous sites for others told the SWD authors that this functionality is > critical for deployability, as it means that the SWD server for a domain > can live in a location outside the domain. Well, that's the whole point of a link relation. WebFinger does not return user data. Rather, it just points at that user data. Query for information about me and the link relations returned might point to one or more domains. I can change a link relation anytime. If a user's account is moved from one location to another (i.e., his/her WebFinger information moves to a different domain), then a 3xx response might be returned. However, I personally see now value in having a "redirect" at a link relation level when the link relation can be changed and when the target resource (e.g., a URL to my picture) can also return a 3xx. > In the recent OAuth thread, Blaine Cook pointed out that WebFinger can > accomplish this functionality through a different means - by having the > result returned from the first host-meta query direct the second query > another server. As such, I now believe both proposals can accomplish this > goal. There is that (as I also noted above) plus the ability to cross reference user accounts using the "acct" link relation. This is not intended for non-"acct" URI queries, though. Also, I would not use this in place of a 3xx. However, if a user of a social networking service would allow users to discover information about themselves at another social networking service, this could be used. (Today, it's possible to "link" accounts on social networking sites, and this "acct" link relation is there to help automate the sharing of that distributed information.) > NUMBER OF ROUND TRIPS: WebFinger discoveries for user information > normally require both a host-meta query to retrieve the template and then > a second query to retrieve the user's information. This functionality is > achieved in a single SWD query. This was one of the first comments we received between the -00 and -01 drafts of the WebFinger spec. To address that, we introduced the "resource" parameter. This is backward-compatible with the current RFC 6415, but can reduce round-trips. Something to consider is mandating support for the "resource" parameter. It's fairly easy to support, but since there are existing implementations, we may not be able to make support a MUST. However, it would be easier to make this a MUST than to introduce a whole different mechanism like SWD. I view the round-trips for WebFinger to be trivial with or without the resource parameter as compared to SWD. SWD does return a URL in a single request/response exchange. However, what if I want to know several pieces of information? With SWD, I would have to issue multiple requests, one request for each "service". Doing that means the number of round-trips can go up significantly. > In the recent OAuth thread, Blaine Cook argued that caching the first > query result is likely to eliminate the first round trip in many cases. > That's very likely the case for multi-user and multi-tenant service > deployments, but I suspect it's of little help to clients on personal > devices, such as smart phones, using a high-latency channel, when UI > response times are latency-dependent, and when most discoveries ARE first- > time discoveries. I agree that we should try to reduce the roundtrips. We've done that, but we can discuss the strength to apply to the "resource" parameter (SHOULD vs. MUST). > XML AND JSON VERSUS JSON: WebFinger specifies both XML and JSON support, > whereas SWD specifies only JSON. I believe that it's simpler to specify > only one way of doing the same thing, with JSON being chosen because it's > simpler for developers to use than XML (the same decision as made for the > OAuth specs, for what it's worth). One syntax being simpler than another is a matter of opinion. Some prefer XML. I prefer XML personally, but I'll note that I had nothing to do with the decision to use XML in the first place. In RFC 6415, JSON was there as an option. In discussions with folks before and since that RFC was published, there was a strong desire to support JSON. So, we made it mandatory in the WebFinger spec. It is important to note that support for XML and JSON is only a server-side burden, not a client burden. The client can use what it prefers. I think that's significant. The complexity on the server is easily managed. I support both XML and JSON in my implementation and it was hardly no effort at all. > DEFINING SPECIFIC RESOURCES: Besides specifying a discovery protocol, > WebFinger also defines specific resources and kinds of resources to be > used with that protocol: the "acct" URI scheme and the "acct" Link > Relation. I'm happy to have these be considered on their own merits, but > I believe that logically, they should be decoupled from the discovery > protocol into a different document or documents. This perhaps gets at the heart of "what is WebFinger?" We already have a discovery mechanism defined in the IETF. It is RFC 6415. Introducing SWD at this point is throwing out all of the work that has already been done over the past several years. So, why did we introduce WebFinger? We had several reasons: 1) We wanted to focus on the discovery of information about humans, so we introduced the "acct" URI. This has been discussed for a few years, too, and it took a lot of debate to reach some agreement on the use of 'acct' vs 'mailto' vs no URI scheme vs. something else. 2) We wanted to require implementation of JSON 3) Noting that discovery within the enterprise might be different than the public Internet, some wanted to mandate support for CORS (to which we have had only support for thus far) 4) We wanted to allow a user to cross-reference social networking accounts, so we introduced the 'acct' link relation 5) We wanted to optimize the discovery process (thus the "resource" and "rel" parameters) We did this through the WebFinger draft as we viewed all of those as natural extensions to the existing discovery protocol documented in RFC 6415, primarily, but not exclusively, aimed at discovery of information about people. > HANNES' QUESTIONS > > 1) Aren't these two mechanisms solving pretty much the same problem? > > They are solving an overlapping set of problems, but with somewhat > different mechanisms and characteristics. I think they're trying to solve the same problem. > 2) Do we need to have two standards for the same functionality? > > I believe there's consensus that a single standard should suffice > and is preferable. Agreed. > 3) Do you guys have a position or comments regarding either one of them? > > I believe that SWD is a simpler and reasonable base to start with > for standardization. I don't agree one is really simpler than the other. The "document" returned by SWD (dare I say that, since you said that it's not document-oriented... but it does return a document) is simpler, but the protocol is not simpler or more difficult. Both use HTTP to send a request to a known resource to get a pointer to another resource. SWD is more "complex" in that it requires multiple queries to get all desired information. WebFinger is more "complex" in that it might return more information than requested. Personally, I appreciate the more richer document produced by WebFinger. Let me give a couple of examples. Suppose I have three profile pictures that I would like to share with the world. I can share all three via WebFinger in order of preference. The receiving client can choose the first or give the requesting user the option to use whatever picture the requesting user prefers. SWD cannot return three pictures, since it can return only a single response to any request for a given "service" type. Suppose I want to create a profile page like this: https://plus.google.com/u/0/103173924987331945891 The data there all comes from what I've provided Google, but let's suppose this is assembled from multiple sources. To get a my current address, picture, postings, friends, etc., one would have to issue multiple queries using SWD, perhaps with service names that are not supported (thus, a few 404 responses). I could get links to everything via WebFinger, allowing the client to select to use vcard, hcard, portable contacts, or other information it finds in the response. Production of the page would go much faster and would be simpler to implement. If the client is only looking for a very specific link relation (as seems to be the usage examples in SWD), that's easily done in WebFinger. It would only be a matter of looking at the set of returned link relations for the specific one sought. Stepping through an array of link relations is not that complex. > CLOSING > > I'll close by saying that I believe the authors of both proposals believe > that this work is incredibly important for the Internet and we share the > goals of making the resulting solution as simple, as deployable, and as > ubiquitously adopted as possible and of producing it in a timely manner. > I look forward to working with them and the rest of the working group to > make that happen. On this, I think we are all in agreement. This is a very important new technology that we believe has great potential both within an enterprise and on the public Internet. WebFinger has already been implemented as a part of Google+ and I would expect others to follow. I think it's also worth mentioning again that WebFinger is a continuation of work that has spanned years. This work has already resulted in publication of RFC 6415. The current WebFinger draft exists for the reasons I stated above. I do not think we should just discard that effort without serious justification. Paul From Michael.Jones@microsoft.com Tue Apr 17 16:25:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4F321F8497; Tue, 17 Apr 2012 16:25:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvXt4cbaJfsE; Tue, 17 Apr 2012 16:24:57 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 3D53D21F8498; Tue, 17 Apr 2012 16:24:57 -0700 (PDT) Received: from mail197-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Apr 2012 23:24:56 +0000 Received: from mail197-ch1 (localhost [127.0.0.1]) by mail197-ch1-R.bigfish.com (Postfix) with ESMTP id 9A5B6120488; Tue, 17 Apr 2012 23:24:56 +0000 (UTC) X-SpamScore: -35 X-BigFish: VS-35(zz9371Ic89bh542M1432Nc857h98dKzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail197-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=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail197-ch1 (localhost.localdomain [127.0.0.1]) by mail197-ch1 (MessageSwitch) id 1334705093495786_30954; Tue, 17 Apr 2012 23:24:53 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail197-ch1.bigfish.com (Postfix) with ESMTP id 5EB2A4601EB; Tue, 17 Apr 2012 23:24:53 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Apr 2012 23:24:53 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Tue, 17 Apr 2012 23:24:46 +0000 From: Mike Jones To: Blaine Cook , Tim Bray Thread-Topic: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHO0LA6pvK3gX3U+Yi1VN9w4mnZafpy3A Date: Tue, 17 Apr 2012 23:24:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436648BF09@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.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_4E1F6AAD24975D4BA5B16804296739436648BF09TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org WG" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 23:25:02 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436648BF09TK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBrbm93IHRoYXQgNyBvZiB0aGUgOCBwdWJsaWMgcGFydGljaXBhbnRzIGluIHRoZSBjdXJyZW50 IE9wZW5JRCBDb25uZWN0IGludGVyb3AgdGVzdGluZyBoYXZlIGltcGxlbWVudGVkIFNXRCBhdCB0 aGlzIHBvaW50LiAgKEkga25vdyBvZiBzZXZlcmFsIG1vcmUgd2hv4oCZdmUgYnVpbHQgaXQgYXMg d2VsbCBidXQgaGF2ZW7igJl0IGNob3NlbiB0byBtYWtlIHRoZWlyIGludGVyb3AgdGVzdCByZXN1 bHRzIHB1YmxpYyB5ZXQuKSAgVGhlcmUgYXJlIGxpa2VseSBvdGhlciBpbXBsZW1lbnRhdGlvbnMg SeKAmW0gdW5hd2FyZSBvZi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJsYWlu ZSBDb29rDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiAzOjU0IFBNDQpUbzogVGltIEJy YXkNCkNjOiBvYXV0aEBpZXRmLm9yZyBXRzsgYXBwcy1kaXNjdXNzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBbYXBwcy1kaXNjdXNzXSBXZWIgRmluZ2VyIHZzLiBTaW1wbGUgV2Vi IERpc2NvdmVyeSAoU1dEKQ0KDQoNClRoYXQncyBhIHRyaWNreSBxdWVzdGlvbiAtIG1heWJlIG9u ZSBnb29nbGUgY2FuIGhlbHAgYW5zd2VyPyBUaGVyZSBhcmUgYSBidW5jaCBvZiBwcm9qZWN0cyB1 c2luZyB3ZWJmaW5nZXIsIGluY2x1ZGluZyBzdGF0dXMubmV0PGh0dHA6Ly9zdGF0dXMubmV0Piwg b3N0YXR1cyBpbiBnZW5lcmFsLCBkaWFzcG9yYSwgdW5ob3N0ZWQsIGZyZWVkb21ib3goPyksIGFu ZCBJJ20gc3VyZSBvdGhlcnMsIGJ1dCBJIGhhdmUgbm8gaWRlYSBob3cgdGhhdCB0cmFuc2xhdGVz IGludG8gYWN0dWFsIHVzZXJzIG9yIHByb2ZpbGVzLg0KDQpHbWFpbCwgYW9sLCBhbmQgeWFob28g YWxsIHB1dCB1cCB3ZWJmaW5nZXIgZW5kcG9pbnRzLCBidXQgdGhlcmUgaGFzbid0IGJlZW4gbXVj aCBtb3ZlbWVudCwgSSB0aGluayBkdWUgdG8gdGhlIGNoaWNrZW4gYW5kIGVnZyBuYXR1cmUgb2Yg YWRvcHRpb24gYXJvdW5kIGRlY2VudHJhbGl6ZWQgdG9vbHMuDQoNCmIuDQpPbiBBcHIgMTcsIDIw MTIgMTE6MTMgQU0sICJUaW0gQnJheSIgPHRicmF5QHRleHR1YWxpdHkuY29tPG1haWx0bzp0YnJh eUB0ZXh0dWFsaXR5LmNvbT4+IHdyb3RlOg0KV2hhdCBpcyB0aGUgZGVwbG95bWVudCBzdGF0dXMg b2YgdGhlc2UgdHdvIHNwZWNzPyAgSXMgZWl0aGVyIGRlcGxveWVkDQptdWNoIGF0IGFsbD8gIC1U DQoNCk9uIEZyaSwgQXByIDEzLCAyMDEyIGF0IDEwOjQ1IEFNLCBNdXJyYXkgUy4gS3VjaGVyYXd5 IDxtc2tAY2xvdWRtYXJrLmNvbTxtYWlsdG86bXNrQGNsb3VkbWFyay5jb20+PiB3cm90ZToNCj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86 YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFN0ZXBoZW4gRmFycmVsbA0KPj4gU2VudDogRnJpZGF5 LCBBcHJpbCAxMywgMjAxMiA5OjIzIEFNDQo+PiBUbzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9h dXRoQGlldGYub3JnPiBXRw0KPj4gQ2M6IEFwcHMgRGlzY3Vzcw0KPj4gU3ViamVjdDogUmU6IFth cHBzLWRpc2N1c3NdIFtPQVVUSC1XR10gV2ViIEZpbmdlciB2cy4gU2ltcGxlIFdlYiBEaXNjb3Zl cnkgKFNXRCkNCj4+DQo+PiBTbyBIYW5uZXMgYW5kIERlcmVrIGFuZCBJIGhhdmUgYmVlbiBkaXNj dXNzaW5nIHRoaXMgd2l0aCB0aGUgQXBwcyBBRHMNCj4+IGFuZCBBcHBzLWFyZWEgV0cgY2hhaXJz LiBJJ3ZlIGFsc28gcmVhZCB0aGUgZG9jcyBub3csIGFuZCBhZnRlciBhbGwNCj4+IHRoYXQgd2Un dmUgZGVjaWRlZCB0aGF0IHRoaXMgdG9waWMgKHdoYXQgdG8gZG8gd2l0aCBzd2QgYW5kIHdlYmZp bmdlcikNCj4+IGlzIGJlc3QgaGFuZGxlZCBpbiB0aGUgYXBwcyBhcmVhIGFuZCBub3QgaW4gdGhl IG9hdXRoIFdHLg0KPj4NCj4+IFRoZSBsb2dpYyBmb3IgdGhhdCBpcyB0aGF0IDEpIHRoZSB0d28g cHJvcG9zYWxzIGFyZSBkb2luZyB0aGUgc2FtZQ0KPj4gdGhpbmcgYW5kIHdlIGRvbid0IHdhbnQg dHdvIGRpZmZlcmVudCBzdGFuZGFyZHMgZm9yIHRoYXQsIGIpIHRoaXMgaXMNCj4+IG5vdCBhbiBv YXV0aC1zcGVjaWZpYyB0aGluZyBub3IgaXMgaXQgYSBnZW5lcmFsIHNlY3VyaXR5IHRoaW5nLCBh bmQgYykNCj4+IHRoZXJlIGlzIGNsZWFybHkgYWxyZWFkeSBpbnRlcmVzdCBpbiB0aGUgdG9waWMg aW4gdGhlIGFwcHMgYXJlYSBzbyBpdHMNCj4+IHJlYXNvbmFibGUgZm9yIHRoZSBvYXV0aCB3ZyB0 byB1c2UgdGhhdCB3aGVuIGl0cyByZWFkeS4NCj4+DQo+PiBUaGUgYXBwc2F3ZyBjaGFpcnMgYW5k IGFwcHMgQURzIGFyZSBvayB3aXRoIHRoZSB3b3JrIGJlaW5nIGRvbmUgdGhlcmUuDQo+Pg0KPj4g U286LQ0KPj4NCj4+IC0gSSd2ZSBhc2tlZCB0aGUgb2F1dGggY2hhaXJzIHRvIHRha2UgZG9pbmcg d29yayBvbiBzd2QNCj4+ICAgb3V0IG9mIHRoZSBwcm9wb3NlZCBuZXcgY2hhcnRlcg0KPj4gLSBJ dCBtYXkgYmUgdGhhdCB5b3Ugd2FudCB0byBhZGQgc29tZXRoaW5nIHNheWluZyB0aGF0DQo+PiAg IG9hdXRoIHdpbGwgdXNlIHRoZSByZXN1bHRzIG9mIHdvcmsgaW4gdGhlIGFwcGxpY2F0aW9ucw0K Pj4gICBhcmVhIG9uIGEgd2ViIGRpc2NvdmVyeSBwcm90b2NvbCBhcyBhIGJhc2lzIGZvciBkb2lu Zw0KPj4gICB0aGUgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIHdvcmsgaGVyZQ0KPj4gLSBE aXNjdXNzaW9uIG9mIHdlYmZpbmdlciBhbmQgc3dkIHNob3VsZCBtb3ZlIG92ZXIgdG8NCj4+ICAg dGhlIGFwcHMtZGlzY3VzcyBsaXN0DQo+PiAtIE5vdGU6IHRoaXMgaXMgbm90IHBpY2tpbmcgb25l IG9yIHRoZSBvdGhlciBhcHByb2FjaCwNCj4+ICAgdGhlIHBsYW4gaXMgdGhhdCB0aGUgYXBwcyBh cmVhIHdpbGwgZG8gYW55IHNlbGVjdGlvbg0KPj4gICBuZWVkZWQgYW5kIGZpZ3VyZSBvdXQgdGhl IGJlc3Qgc3RhcnRpbmcgcG9pbnQgZm9yIGENCj4+ICAgc3RhbmRhcmRzLXRyYWNrIFJGQyBvbiB3 ZWIgZGlzY292ZXJ5IGFuZCB3ZSdsbCB1c2UgdGhlaXINCj4+ICAgZmluZSB3b3JrIGZvciBkb2lu ZyBtb3JlIHdpdGggb2F1dGguDQo+DQo+IFRoYW5rIHlvdSBTdGVwaGVuLCBJIHRoaW5rLiAgOi0p DQo+DQo+IFNvIHRoZSBkaXNjdXNzaW9uIG9uIGFwcHMtZGlzY3VzcyBub3cgc2hvdWxkIGJlIGZv Y3VzZWQgb24gd2hpY2ggb2YgdGhlIHR3byBzaG91bGQgYmUgdGhlIGJhc2lzIGZvciBmb3J3YXJk IHByb2dyZXNzLiAgSSd2ZSBwbGFjZWQgYm90aCBkb2N1bWVudHMgaW4gIkNhbGwgZm9yIEFkb3B0 aW9uIiBzdGF0ZSBpbiB0aGUgZGF0YXRyYWNrZXIgZm9yIGFwcHNhd2cuDQo+DQo+IExldCB0aGUg Z2FtZXMgYmVnaW4uDQo+DQo+IC1NU0sNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdA0KPiBhcHBzLWRp c2N1c3NAaWV0Zi5vcmc8bWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_4E1F6AAD24975D4BA5B16804296739436648BF09TK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pkkga25vdyB0aGF0IDcgb2YgdGhlIDggcHVibGljIHBhcnRpY2lwYW50cyBpbiB0aGUgY3VycmVu dCBPcGVuSUQgQ29ubmVjdCBpbnRlcm9wIHRlc3RpbmcgaGF2ZSBpbXBsZW1lbnRlZCBTV0QgYXQg dGhpcyBwb2ludC4mbmJzcDsgKEkga25vdyBvZiBzZXZlcmFsIG1vcmUgd2hv4oCZdmUNCiBidWls dCBpdCBhcyB3ZWxsIGJ1dCBoYXZlbuKAmXQgY2hvc2VuIHRvIG1ha2UgdGhlaXIgaW50ZXJvcCB0 ZXN0IHJlc3VsdHMgcHVibGljIHlldC4pJm5ic3A7IFRoZXJlIGFyZSBsaWtlbHkgb3RoZXIgaW1w bGVtZW50YXRpb25zIEnigJltIHVuYXdhcmUgb2YuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0g TWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gb2F1dGgtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPkJsYWluZSBDb29rPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDE3 LCAyMDEyIDM6NTQgUE08YnI+DQo8Yj5Ubzo8L2I+IFRpbSBCcmF5PGJyPg0KPGI+Q2M6PC9iPiBv YXV0aEBpZXRmLm9yZyBXRzsgYXBwcy1kaXNjdXNzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbT0FVVEgtV0ddIFthcHBzLWRpc2N1c3NdIFdlYiBGaW5nZXIgdnMuIFNpbXBsZSBX ZWIgRGlzY292ZXJ5IChTV0QpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5UaGF0J3MgYSB0cmlja3kgcXVlc3Rpb24g LSBtYXliZSBvbmUgZ29vZ2xlIGNhbiBoZWxwIGFuc3dlcj8gVGhlcmUgYXJlIGEgYnVuY2ggb2Yg cHJvamVjdHMgdXNpbmcgd2ViZmluZ2VyLCBpbmNsdWRpbmcNCjxhIGhyZWY9Imh0dHA6Ly9zdGF0 dXMubmV0Ij5zdGF0dXMubmV0PC9hPiwgb3N0YXR1cyBpbiBnZW5lcmFsLCBkaWFzcG9yYSwgdW5o b3N0ZWQsIGZyZWVkb21ib3goPyksIGFuZCBJJ20gc3VyZSBvdGhlcnMsIGJ1dCBJIGhhdmUgbm8g aWRlYSBob3cgdGhhdCB0cmFuc2xhdGVzIGludG8gYWN0dWFsIHVzZXJzIG9yIHByb2ZpbGVzLjxv OnA+PC9vOnA+PC9wPg0KPHA+R21haWwsIGFvbCwgYW5kIHlhaG9vIGFsbCBwdXQgdXAgd2ViZmlu Z2VyIGVuZHBvaW50cywgYnV0IHRoZXJlIGhhc24ndCBiZWVuIG11Y2ggbW92ZW1lbnQsIEkgdGhp bmsgZHVlIHRvIHRoZSBjaGlja2VuIGFuZCBlZ2cgbmF0dXJlIG9mIGFkb3B0aW9uIGFyb3VuZCBk ZWNlbnRyYWxpemVkIHRvb2xzLjxvOnA+PC9vOnA+PC9wPg0KPHA+Yi48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBcHIgMTcsIDIwMTIgMTE6MTMgQU0sICZx dW90O1RpbSBCcmF5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGJyYXlAdGV4dHVhbGl0eS5j b20iIHRhcmdldD0iX2JsYW5rIj50YnJheUB0ZXh0dWFsaXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBpcyB0aGUgZGVwbG95bWVu dCBzdGF0dXMgb2YgdGhlc2UgdHdvIHNwZWNzPyAmbmJzcDtJcyBlaXRoZXIgZGVwbG95ZWQ8YnI+ DQptdWNoIGF0IGFsbD8gJm5ic3A7LVQ8YnI+DQo8YnI+DQpPbiBGcmksIEFwciAxMywgMjAxMiBh dCAxMDo0NSBBTSwgTXVycmF5IFMuIEt1Y2hlcmF3eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1za0Bj bG91ZG1hcmsuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNrQGNsb3VkbWFyay5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsm Z3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFN0 ZXBoZW4gRmFycmVsbDxicj4NCiZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgQXByaWwgMTMsIDIwMTIg OToyMyBBTTxicj4NCiZndDsmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4gV0c8YnI+DQomZ3Q7Jmd0OyBDYzog QXBwcyBEaXNjdXNzPGJyPg0KJmd0OyZndDsgU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFtP QVVUSC1XR10gV2ViIEZpbmdlciB2cy4gU2ltcGxlIFdlYiBEaXNjb3ZlcnkgKFNXRCk8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFNvIEhhbm5lcyBhbmQgRGVyZWsgYW5kIEkgaGF2ZSBiZWVu IGRpc2N1c3NpbmcgdGhpcyB3aXRoIHRoZSBBcHBzIEFEczxicj4NCiZndDsmZ3Q7IGFuZCBBcHBz LWFyZWEgV0cgY2hhaXJzLiBJJ3ZlIGFsc28gcmVhZCB0aGUgZG9jcyBub3csIGFuZCBhZnRlciBh bGw8YnI+DQomZ3Q7Jmd0OyB0aGF0IHdlJ3ZlIGRlY2lkZWQgdGhhdCB0aGlzIHRvcGljICh3aGF0 IHRvIGRvIHdpdGggc3dkIGFuZCB3ZWJmaW5nZXIpPGJyPg0KJmd0OyZndDsgaXMgYmVzdCBoYW5k bGVkIGluIHRoZSBhcHBzIGFyZWEgYW5kIG5vdCBpbiB0aGUgb2F1dGggV0cuPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBUaGUgbG9naWMgZm9yIHRoYXQgaXMgdGhhdCAxKSB0aGUgdHdvIHBy b3Bvc2FscyBhcmUgZG9pbmcgdGhlIHNhbWU8YnI+DQomZ3Q7Jmd0OyB0aGluZyBhbmQgd2UgZG9u J3Qgd2FudCB0d28gZGlmZmVyZW50IHN0YW5kYXJkcyBmb3IgdGhhdCwgYikgdGhpcyBpczxicj4N CiZndDsmZ3Q7IG5vdCBhbiBvYXV0aC1zcGVjaWZpYyB0aGluZyBub3IgaXMgaXQgYSBnZW5lcmFs IHNlY3VyaXR5IHRoaW5nLCBhbmQgYyk8YnI+DQomZ3Q7Jmd0OyB0aGVyZSBpcyBjbGVhcmx5IGFs cmVhZHkgaW50ZXJlc3QgaW4gdGhlIHRvcGljIGluIHRoZSBhcHBzIGFyZWEgc28gaXRzPGJyPg0K Jmd0OyZndDsgcmVhc29uYWJsZSBmb3IgdGhlIG9hdXRoIHdnIHRvIHVzZSB0aGF0IHdoZW4gaXRz IHJlYWR5Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIGFwcHNhd2cgY2hhaXJzIGFu ZCBhcHBzIEFEcyBhcmUgb2sgd2l0aCB0aGUgd29yayBiZWluZyBkb25lIHRoZXJlLjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgU286LTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLSBJ J3ZlIGFza2VkIHRoZSBvYXV0aCBjaGFpcnMgdG8gdGFrZSBkb2luZyB3b3JrIG9uIHN3ZDxicj4N CiZndDsmZ3Q7ICZuYnNwOyBvdXQgb2YgdGhlIHByb3Bvc2VkIG5ldyBjaGFydGVyPGJyPg0KJmd0 OyZndDsgLSBJdCBtYXkgYmUgdGhhdCB5b3Ugd2FudCB0byBhZGQgc29tZXRoaW5nIHNheWluZyB0 aGF0PGJyPg0KJmd0OyZndDsgJm5ic3A7IG9hdXRoIHdpbGwgdXNlIHRoZSByZXN1bHRzIG9mIHdv cmsgaW4gdGhlIGFwcGxpY2F0aW9uczxicj4NCiZndDsmZ3Q7ICZuYnNwOyBhcmVhIG9uIGEgd2Vi IGRpc2NvdmVyeSBwcm90b2NvbCBhcyBhIGJhc2lzIGZvciBkb2luZzxicj4NCiZndDsmZ3Q7ICZu YnNwOyB0aGUgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIHdvcmsgaGVyZTxicj4NCiZndDsm Z3Q7IC0gRGlzY3Vzc2lvbiBvZiB3ZWJmaW5nZXIgYW5kIHN3ZCBzaG91bGQgbW92ZSBvdmVyIHRv PGJyPg0KJmd0OyZndDsgJm5ic3A7IHRoZSBhcHBzLWRpc2N1c3MgbGlzdDxicj4NCiZndDsmZ3Q7 IC0gTm90ZTogdGhpcyBpcyBub3QgcGlja2luZyBvbmUgb3IgdGhlIG90aGVyIGFwcHJvYWNoLDxi cj4NCiZndDsmZ3Q7ICZuYnNwOyB0aGUgcGxhbiBpcyB0aGF0IHRoZSBhcHBzIGFyZWEgd2lsbCBk byBhbnkgc2VsZWN0aW9uPGJyPg0KJmd0OyZndDsgJm5ic3A7IG5lZWRlZCBhbmQgZmlndXJlIG91 dCB0aGUgYmVzdCBzdGFydGluZyBwb2ludCBmb3IgYTxicj4NCiZndDsmZ3Q7ICZuYnNwOyBzdGFu ZGFyZHMtdHJhY2sgUkZDIG9uIHdlYiBkaXNjb3ZlcnkgYW5kIHdlJ2xsIHVzZSB0aGVpcjxicj4N CiZndDsmZ3Q7ICZuYnNwOyBmaW5lIHdvcmsgZm9yIGRvaW5nIG1vcmUgd2l0aCBvYXV0aC48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBUaGFuayB5b3UgU3RlcGhlbiwgSSB0aGluay4gJm5ic3A7Oi0pPGJy Pg0KJmd0Ozxicj4NCiZndDsgU28gdGhlIGRpc2N1c3Npb24gb24gYXBwcy1kaXNjdXNzIG5vdyBz aG91bGQgYmUgZm9jdXNlZCBvbiB3aGljaCBvZiB0aGUgdHdvIHNob3VsZCBiZSB0aGUgYmFzaXMg Zm9yIGZvcndhcmQgcHJvZ3Jlc3MuICZuYnNwO0kndmUgcGxhY2VkIGJvdGggZG9jdW1lbnRzIGlu ICZxdW90O0NhbGwgZm9yIEFkb3B0aW9uJnF1b3Q7IHN0YXRlIGluIHRoZSBkYXRhdHJhY2tlciBm b3IgYXBwc2F3Zy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBMZXQgdGhlIGdhbWVzIGJlZ2luLjxicj4N CiZndDs8YnI+DQomZ3Q7IC1NU0s8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBhcHBzLWRpc2N1c3MgbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+YXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vz czwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739436648BF09TK5EX14MBXC284r_-- From paulej@packetizer.com Tue Apr 17 16:41: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 4C69F11E80E0 for ; Tue, 17 Apr 2012 16:41:41 -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.294, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur8waRqMQGtA for ; Tue, 17 Apr 2012 16:41:36 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id CC14C11E80DE for ; Tue, 17 Apr 2012 16:41:35 -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 q3HNecOw003298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2012 19:40:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334706039; bh=CyAqXUb+DyDrb+H8pOEoI6v0FGpOkgFP4oUIByUY6Y4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Awui0srqeRiY3gUTraEhI/4OqdpzG2fG3Fm/KwE+oWR/ff7fddK2evLbMtg7nmS+m /+coJGrLEws7JwcTVQFsPB1b+2ABOSEt1omXaPlmU8i0ZzDjKAqFkyFDMJH2QatJHB bTH46BfmNXUbFgu3yxoiAhTAZz+zYJxtnoFH7joY= From: "Paul E. Jones" To: "'Derek Atkins'" , "'Murray S. Kucherawy'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> In-Reply-To: Date: Tue, 17 Apr 2012 19:40:54 -0400 Message-ID: <04f601cd1cf3$88ab49d0$9a01dd70$@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: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TpYHDBYQ Content-Language: en-us Cc: 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 23:41:41 -0000 Derek, > This leaves only the perceived issue of "whole document" vs "individual > attribute". If a client ever wants more than one attribute then a whole > document approach reduces the number of round trips. However if documents > get large that could also affect performance. We might, then, need a way > to specify which attributes are requested, but allow for a wildcard to > return "everything I am authorized to see". If the document gets large, you're right that it might be an issue. For this reason, we introduced the "rel" parameter in the most recent WebFinger draft. Like HTML, this is a space-separated list of link relation types. The idea is that the server will filter based on that list. If you want to see it in action, you can issue a query against my ID: $ curl https://packetizer.com/.well-known/host-meta?\ resource=acct%3Apaulej%40packetizer.com or $ curl 'https://packetizer.com/.well-known/host-meta?\ resource=acct%3Apaulej%40packetizer.com&\ rel=vcard+http%3A%2F%2Fwebfinger.net%2Frel%2Favatar' The first example returns the entire XRD document. The second example returns only link relations of type vcard or http://webfinger.net/rel/avatar. To get JSON output, just replace host-meta with host-meta.json as per RFC 6415 (or use an "Accept" header with application/json). Now, I'm still wondering if a resource descriptor document will ever get so large. It does not return information about a user, just pointers to information. So, do we need "rel"? If there is definitely only a certain set of link relations of interest, it's a way to limit the output. I suppose it does not hurt to introduce it; it's the value I question. I'd definitely like input on the utility. Given the claims that SWD is simpler because of the limited information returned, perhaps that lends to the argument that it is useful. Paul From paulej@packetizer.com Tue Apr 17 16:59: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 D788411E80E6 for ; Tue, 17 Apr 2012 16:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlQCVsbOaPcS for ; Tue, 17 Apr 2012 16:59:18 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE5311E80C5 for ; Tue, 17 Apr 2012 16:59:18 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3HNxGkI003777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2012 19:59:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334707157; bh=B6xjNybOlDOhwiz/eNZJMIeeSw3O7AN4mNLFXXRwTS0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=TUxrbUKTG33Ehom83o/sf25Id8r61yppgE3QF49pHSfalzPPISAoTqFFiTqXaI4AQ 23WU4PtqC+8F3ZYL7OJcA6zPahQNwQAkdEEFYR0gfSTdjiR07E51Ug370tgr2pHzug UHZvk386Mb3iq98wMp7qXp6ggRbE+pTWABB3ztTA= From: "Paul E. Jones" To: "'Melvin Carvalho'" , "'Mike Jones'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Date: Tue, 17 Apr 2012 19:59:33 -0400 Message-ID: <04fb01cd1cf6$23131c80$69395580$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04FC_01CD1CD4.9C017C80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0B/rNJdACTlkYtAqzWkh2V9enewA== Content-Language: en-us Cc: 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 23:59:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04FC_01CD1CD4.9C017C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, On "acct:". Humans will usually interchange an acct URI and mailto URI, probably never using either scheme directly in practice. That's natural and expected, if not desired. The intent is that we define something that looks like an email ID, but it's not an email ID. Some services, perhaps Twitter being most notable, do no use email addresses. Yet, you might have an account there. So, user@twitter.com might be used by humans and automated systems would convert that to acct:user@twitter.com. It would not be appropriate to use mailto: since it's not an email ID. We did have a lot of debate about the use of "acct". If you query my WebFinger server, you'll see that it will work without "acct:" prefixed, as that was a suggestion made a year or so ago. It will inspect the input and if it looks like an acct URI, it will assume it is. The "acct" URI will be returned as an alias. However, we should always use some kind of URI scheme to remove the guesswork. The client can often make a very good guess as to whether it's looking for a user account or something else. So, let it tell the server what it is looking for explicitly. We need a URI scheme, because WebFinger can be used to discover all kinds of information related to a given domain, not only user information. It can be used to query information about any URI, be that a web page, a user account, device on the network, etc. If we got rid of "acct", then we would have a system where we sometimes use a URI scheme and sometimes we do not. Results might be inconsistent, as the server may not make the right guess, unless we agreed that absence of a scheme defaults to "acct:". However, I see no reason for the client to be so lazy to not include "acct:". The user might (and probably will) exclude it, but the client code can add it. At this point, I'd argue the "train has left the station" on "acct", too. The current WebFinger spec exists (in part) to formally document that which has adopted; it's not a new thing. Paul A couple of points: 1. JSON ======= I think at the time webfinger was created in 2009, XML was the de facto serialization, used in AJAX, SOAP and many other systems. Today I'm hearing more and more, that both developers and publishers, want to work with JSON, rather than, having to support both xml and json. Content negotiation also confuses some publishers. In my view, this is a great simplification that webfinger can learn from SWD. 2. acct: scheme ============= The acct: URI scheme has not proved popular, imho, and has added a layer of complexity and confusion. How do we get from acct: to mailto:? When should you use acct: and when mailto: (the spec says acct:user@host may be different from mailto:user@host). What about the forms. How about linked data ecosystems that want to cross link identifiers, do they now have to consider both cases? >From the original post introducing acct: "I don't expect everyone to like this idea. I wish I could say I love it, but I am simply content with it." I dont know of anyone in the community (and correct me if this has changed) that really loves acct:, or perhaps even likes the acct: idea. SWD has shown you can do discovery without acct: and I think that's a big plus. One final side note is that this almost becomes trivial when you can do SPARQL queries. "void" is already registered by the W3C with IANA in .well-known in order to discover SPARQL endpoints. It may be overkill in some people's eyes, but Linked Data (which predates webfinger), particularly newer things like JSON LD, are a lot bigger than they were in 2009. In a few years it may become the definitive discovery mechanism anyway. ------=_NextPart_000_04FC_01CD1CD4.9C017C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

On “acct:”…

 

Humans will usually interchange an acct URI and mailto URI, probably = never using either scheme directly in practice.  That’s = natural and expected, if not desired.  The intent is that we define = something that looks like an email ID, but it’s not an email = ID.  Some services, perhaps Twitter being most notable, do no use = email addresses.  Yet, you might have an account there.  So, = user@twitter.com might be used = by humans and automated systems would convert that to = acct:user@twitter.com.  It would not be appropriate to use mailto: = since it’s not an email ID.

 

We did have a lot of debate about the use of = “acct”.  If you query my WebFinger server, you’ll = see that it will work without “acct:” prefixed, as that was = a suggestion made a year or so ago.  It will inspect the input and = if it looks like an acct URI, it will assume it is.  The = “acct” URI will be returned as an alias.  However, we = should always use some kind of URI scheme to remove the guesswork.  = The client can often make a very good guess as to whether it’s = looking for a user account or something else.  So, let it tell the = server what it is looking for explicitly.

 

We need a URI scheme, because WebFinger can be used to discover all = kinds of information related to a given domain, not only user = information.  It can be used to query information about any URI, be = that a web page, a user account, device on the network, etc.  If we = got rid of “acct”, then we would have a system where we = sometimes use a URI scheme and sometimes we do not.  Results might = be inconsistent, as the server may not make the right guess, unless we = agreed that absence of a scheme defaults to “acct:”.  = However, I see no reason for the client to be so lazy to not include = “acct:”.  The user might (and probably will) exclude = it, but the client code can add it.

 

At this point, I’d argue the “train has left the = station” on “acct”, too.  The current WebFinger = spec exists (in part) to formally document that which has adopted; = it’s not a new thing.

 

Paul

 

A couple of points:

1. = JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the time webfinger was = created in 2009, XML was the de facto serialization, used in AJAX, SOAP = and many other systems.  Today I'm hearing more and more, that both = developers and publishers, want to work with JSON, rather than, having = to support both xml and json.  Content negotiation also confuses = some publishers.  In my view, this is a great simplification that = webfinger can learn from SWD.

2. acct: = scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The acct: URI = scheme has not proved popular, imho, and has added a layer of complexity = and confusion.  How do we get from acct: to mailto:?  When = should you use acct: and when mailto: (the spec says acct:user@host may = be different from mailto:user@host).  What about the = forms.  How about linked data ecosystems that want to cross link = identifiers, do they now have to consider both cases? 

From = the original post introducing acct:

"I don’t expect = everyone to like this idea. I wish I could say I love it, but I am = simply content with it."

I dont know of anyone in the = community (and correct me if this has changed) that really loves acct:, = or perhaps even likes the acct: idea.  SWD has shown you can do = discovery without acct: and I think that's a big = plus.




One final side note is that this almost becomes = trivial when you can do SPARQL queries.  "void" is = already registered by the W3C with IANA in .well-known in order to = discover SPARQL endpoints.  It may be overkill in some people's = eyes, but Linked Data (which predates webfinger), particularly newer = things like JSON LD, are a lot bigger than they were in 2009.  In a = few years it may become the definitive discovery mechanism = anyway.

------=_NextPart_000_04FC_01CD1CD4.9C017C80-- From stephen.farrell@cs.tcd.ie Tue Apr 17 17: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 26D1411E80C5 for ; Tue, 17 Apr 2012 17:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Wi9mMDzFiEs for ; Tue, 17 Apr 2012 17:02:32 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB3C11E80E9 for ; Tue, 17 Apr 2012 17:02:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1B96D171475; Wed, 18 Apr 2012 01:02:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334707345; bh=jGqXIg7eKPHfTE ezx6vkBXpwxNk2K0jzvEpmnWiGYdA=; b=YgCQgnl6S20dhAEhndFdcLN0tlQQWY l9NTc878qBJ7f1322/1OwrioFddaVOz3VVuKIqtsK7mB08op2O/aLRXeYNavCeQO YnNLzyIOYm1hLahabe7o8CyVsAlDpCoE+GLvj+dw6HAmf2OmPkUpBtvr5A4+2qwW hNLZFd55jJB7yNU6qzpwB6yYI+H2rEQTjtnF7Bx7sypY+YVuXbtLtuts8w46xglr VUpeg880rau/rnN0+Kbq9QPTxMKuHdzKBg6aUe2Qt0u0YhQoyNtpS4LwPb+P+GEA 65AGt0jBVDaVJzLnIiKHC6Ddkquo65C0OxpZRQ3QyetDNfK9/o6ozT/Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id HGW5DPEDiezu; Wed, 18 Apr 2012 01:02:25 +0100 (IST) Received: from [10.87.48.7] (unknown [86.46.27.58]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 00B73171473; Wed, 18 Apr 2012 01:02:23 +0100 (IST) Message-ID: <4F8E0485.3020105@cs.tcd.ie> Date: Wed, 18 Apr 2012 01:02:13 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <04f601cd1cf3$88ab49d0$9a01dd70$@packetizer.com> In-Reply-To: <04f601cd1cf3$88ab49d0$9a01dd70$@packetizer.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Derek Atkins' , 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 00:02:38 -0000 Hi Paul, There's also the question of privacy. Aggregated information is always more sensitive. Sets of links, in aggregate, do leak private information. So it would seem fair to say that the bigger document approach has the worse privacy problem, at least in the abstract. If it were the case that webfinger made it noticeably harder to partition who knows what about me, then that would be a privacy downside, and not in the abstract, but practically. (Not a sure showstopper, but a thing that needs attention at least.) However, I've no idea how these are envisaged to be deployed, or are being deployed, nor if its (intended to be) easy for a user to create loads of different profiles/documents/whatever or not. So - do you agree this is an issue, that webfinger aggregates (possibly lots of) different pointers related to the same person? And, how significant is that and are there ways to mitigate it, for those who might care? This aspect is essentially ignored by both swd and webfinger drafts as far as I can see, but does seem worse with the latter approach, at least as I understand it. (However, for a bit of balance the string "privacy" does occur in swd, but the term is misused when "confidentiality" was meant:-) I do think user privacy is worth consideration regardless of which approach is taken ultimately. S On 04/18/2012 12:40 AM, Paul E. Jones wrote: > Derek, > >> This leaves only the perceived issue of "whole document" vs "individual >> attribute". If a client ever wants more than one attribute then a whole >> document approach reduces the number of round trips. However if documents >> get large that could also affect performance. We might, then, need a way >> to specify which attributes are requested, but allow for a wildcard to >> return "everything I am authorized to see". > > If the document gets large, you're right that it might be an issue. For > this reason, we introduced the "rel" parameter in the most recent WebFinger > draft. Like HTML, this is a space-separated list of link relation types. > The idea is that the server will filter based on that list. > > If you want to see it in action, you can issue a query against my ID: > $ curl https://packetizer.com/.well-known/host-meta?\ > resource=acct%3Apaulej%40packetizer.com > > or > > $ curl 'https://packetizer.com/.well-known/host-meta?\ > resource=acct%3Apaulej%40packetizer.com&\ > rel=vcard+http%3A%2F%2Fwebfinger.net%2Frel%2Favatar' > > The first example returns the entire XRD document. The second example > returns only link relations of type vcard or > http://webfinger.net/rel/avatar. To get JSON output, just replace host-meta > with host-meta.json as per RFC 6415 (or use an "Accept" header with > application/json). > > Now, I'm still wondering if a resource descriptor document will ever get so > large. It does not return information about a user, just pointers to > information. So, do we need "rel"? If there is definitely only a certain > set of link relations of interest, it's a way to limit the output. I > suppose it does not hurt to introduce it; it's the value I question. I'd > definitely like input on the utility. Given the claims that SWD is simpler > because of the limited information returned, perhaps that lends to the > argument that it is useful. > > Paul > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nico@cryptonector.com Tue Apr 17 18:11:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54E011E807F; Tue, 17 Apr 2012 18:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ua8hX35D8Amd; Tue, 17 Apr 2012 18:11:27 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id E016911E80E7; Tue, 17 Apr 2012 18:11:27 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 569477E4062; Tue, 17 Apr 2012 18:11:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=qW3SnYstvGxbXkljNp/FseMd82jolLzfBWuqRmbhoGyM 9kWcivaWFM6AJ16GOG/Dd5Zv5Vtc8Vgwt7plV6ikWqockg1kkJAjerPDa1WDMWR6 0ZLuOcuGysqf3HdFCfzIe6UaLMV8WAryuvGpSPuN0yGcPf0HjNAt5hrBJeTlSm4= 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:content-transfer-encoding; s= cryptonector.com; bh=i7EKboxRKimWjwF/RIF1DvARCxo=; b=xxXL3jOVbuN 2jdwscuEdAvrp7htcsJMtqZSekVRSqFr4W209tXCCkTTa4EoTJbgY7NOtUoOOLHD VVFFyf+7gn2KyNdm0qRg/5RGAXdyvHOedC5kmAMBaCLXoHwfo/lUopx3VSAIadZL 0qW7RfmnuVyFYGMvNQ1+sJVkSTiV950E= 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 28D3A7E4058; Tue, 17 Apr 2012 18:11:27 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so6236117pbb.31 for ; Tue, 17 Apr 2012 18:11:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.191.35 with SMTP id gv3mr1560566pbc.160.1334711486534; Tue, 17 Apr 2012 18:11:26 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Tue, 17 Apr 2012 18:11:26 -0700 (PDT) In-Reply-To: References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> <1334695329.43020.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Tue, 17 Apr 2012 20:11:26 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 01:11:32 -0000 On Tue, Apr 17, 2012 at 3:48 PM, Sam Hartman wrote: >>>>>> "William" =3D=3D William Mills writes: > > =C2=A0 =C2=A0William> The key of this for me is "are likely to have suffi= cient > =C2=A0 =C2=A0William> policy and information". =C2=A0This is fine in disc= ussion, but I > =C2=A0 =C2=A0William> want to see an explicit declaration about when an > =C2=A0 =C2=A0William> implementation can treat things as equivalent. > > I don't think we can say anything about that. Implementations can treat > things as equivalent when they know that it's safe to do so through > policy which may be hard-coded, configured or downloaded from somewhere. > I think that's an implementation matter outside the scope of the > standard. I agree. I suspect Bill is concerned that lacking "sufficient policy and information" may lead to vulnerabilities, say, in that critical attributes may get ignored. We have no method for indicating attribute criticality in the proposed API, and this is by design. Mechanisms may (and Kerberos, for example, does) have methods for indicating attribute criticality. What must happen is that systems must know how to interpret critical mechanism attributes, but this is already required by mechanism specifications. So I think we're covered, but perhaps we could make this a little more explicit. Nico -- From jpanzer@google.com Tue Apr 17 18:20: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 2012D21F84EE for ; Tue, 17 Apr 2012 18:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.842 X-Spam-Level: X-Spam-Status: No, score=-102.842 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C0bv+d0KLpP for ; Tue, 17 Apr 2012 18:20:11 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8385021F84EC for ; Tue, 17 Apr 2012 18:20:11 -0700 (PDT) Received: by qcsq13 with SMTP id q13so5100445qcs.31 for ; Tue, 17 Apr 2012 18:20:11 -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=6XtXiNcNFwaRLGjopsRRStriawhquEY/y1Y45bVP6QQ=; b=UgsCuEKHoFdB4VeHk2IAebFl4QHaNilm1O/lgXb4c55mon1EWC6ZFG4tJPFlvUvVaQ SVXnAuPQxoYo4Z9HI7rN6GKKymr5a0Qtf7CqgNFxKbCthX7/93y9O3PoXnkjkWkOm07v lwbuLvQtQ2DMf0fSRm60wSwfrpNikN4Zee+HblSjQVcgay6nsXMkGbmQAohpSneZipBO qIbqcU6PHhLrlJE4yEYv0pskSobhJBblIeS7oLMm0JgVldq8UTz3I9l9Zh0o94j3hxdt fGpEgT175RXo3/xeCVKAE3qLaTLW562lPSyttPcamVWd4MqziFoqmQdRPEU/V8WQEj8D jBKg== 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=6XtXiNcNFwaRLGjopsRRStriawhquEY/y1Y45bVP6QQ=; b=MIGYIWS5X22f/LLzfn+LUEZDDnLEd5xMAUgFphg6xchb8DbJUPL6bxNojBleVpFNcI Pi1E8cjznI3vw9TuTUXhBT4WqQYgb/wOhcvYBbIMzNQJ0EAD5U6z1w7BCEpD5F4o7Ebo HHziur+FdB01DUgmoPaid0cpIM9MVUJ0RDeE4S7FolGHMmhEVk8x2IyFwQWymL+oK3b6 uDbJsO2uzVElKMiGcssD0EY/s0UqmF56jqGY23TnS+4hrdo2w9YHJJ2OXDD/bRvmFLyl xr53nK8risCXsw1RPHayf2yBTHDdnJVTXYgSgdKqtvwAPo3sY3acqqvDc/ao7QajfXqy P+mQ== Received: by 10.229.137.79 with SMTP id v15mr97521qct.142.1334712010886; Tue, 17 Apr 2012 18:20:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.137.79 with SMTP id v15mr97511qct.142.1334712010700; Tue, 17 Apr 2012 18:20:10 -0700 (PDT) Received: by 10.229.22.133 with HTTP; Tue, 17 Apr 2012 18:20:10 -0700 (PDT) Received: by 10.229.22.133 with HTTP; Tue, 17 Apr 2012 18:20:10 -0700 (PDT) In-Reply-To: <4F8E0485.3020105@cs.tcd.ie> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <04f601cd1cf3$88ab49d0$9a01dd70$@packetizer.com> <4F8E0485.3020105@cs.tcd.ie> Date: Tue, 17 Apr 2012 18:20:10 -0700 Message-ID: From: John Panzer To: Stephen Farrell Content-Type: multipart/alternative; boundary=00235452f49046792604bde9db02 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkmsolrZElMBJJbE9PMxmvz2HJJkzPoRSNqq/Fd82Ac1CFU87fZpfg2ONrueJynUAe8u8oB3YQ9KFe1pxa+1rQytti/tONYnUzdu/1ELTbUjXV3U3KFvKhGD0NCpV0OcudpFJoNaVu/lR8dtT6vynR3zJas5w== Cc: Derek Atkins , apps-discuss@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 01:20:17 -0000 --00235452f49046792604bde9db02 Content-Type: text/plain; charset=ISO-8859-1 It seems to me there is no difference between the two w.r.t. privacy and aggregation of data, if you grant that webfinger's reliance on separate http auth mechanisms is sufficient to allow access control. On Apr 17, 2012 5:02 PM, "Stephen Farrell" wrote: > > Hi Paul, > > There's also the question of privacy. Aggregated information is > always more sensitive. Sets of links, in aggregate, do leak > private information. > > So it would seem fair to say that the bigger document approach > has the worse privacy problem, at least in the abstract. > > If it were the case that webfinger made it noticeably harder to > partition who knows what about me, then that would be a privacy > downside, and not in the abstract, but practically. (Not a sure > showstopper, but a thing that needs attention at least.) > > However, I've no idea how these are envisaged to be deployed, or > are being deployed, nor if its (intended to be) easy for a user > to create loads of different profiles/documents/whatever or not. > > So - do you agree this is an issue, that webfinger aggregates > (possibly lots of) different pointers related to the same person? > > And, how significant is that and are there ways to mitigate it, > for those who might care? > > This aspect is essentially ignored by both swd and webfinger > drafts as far as I can see, but does seem worse with the latter > approach, at least as I understand it. (However, for a bit of > balance the string "privacy" does occur in swd, but the term > is misused when "confidentiality" was meant:-) > > I do think user privacy is worth consideration regardless of > which approach is taken ultimately. > > S > > On 04/18/2012 12:40 AM, Paul E. Jones wrote: > > Derek, > > > >> This leaves only the perceived issue of "whole document" vs "individual > >> attribute". If a client ever wants more than one attribute then a whole > >> document approach reduces the number of round trips. However if > documents > >> get large that could also affect performance. We might, then, need a > way > >> to specify which attributes are requested, but allow for a wildcard to > >> return "everything I am authorized to see". > > > > If the document gets large, you're right that it might be an issue. For > > this reason, we introduced the "rel" parameter in the most recent > WebFinger > > draft. Like HTML, this is a space-separated list of link relation types. > > The idea is that the server will filter based on that list. > > > > If you want to see it in action, you can issue a query against my ID: > > $ curl https://packetizer.com/.well-known/host-meta?\ > > resource=acct%3Apaulej%40packetizer.com > > > > or > > > > $ curl 'https://packetizer.com/.well-known/host-meta?\ > > resource=acct%3Apaulej%40packetizer.com&\ > > rel=vcard+http%3A%2F%2Fwebfinger.net%2Frel%2Favatar' > > > > The first example returns the entire XRD document. The second example > > returns only link relations of type vcard or > > http://webfinger.net/rel/avatar. To get JSON output, just replace > host-meta > > with host-meta.json as per RFC 6415 (or use an "Accept" header with > > application/json). > > > > Now, I'm still wondering if a resource descriptor document will ever get > so > > large. It does not return information about a user, just pointers to > > information. So, do we need "rel"? If there is definitely only a > certain > > set of link relations of interest, it's a way to limit the output. I > > suppose it does not hurt to introduce it; it's the value I question. I'd > > definitely like input on the utility. Given the claims that SWD is > simpler > > because of the limited information returned, perhaps that lends to the > > argument that it is useful. > > > > 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 > --00235452f49046792604bde9db02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

It seems to me there is no difference between the two w.r.t. privacy and= aggregation of data, if you grant that webfinger's reliance on separat= e http auth mechanisms is sufficient to allow access control.

On Apr 17, 2012 5:02 PM, "Stephen Farrell&q= uot; <ste= phen.farrell@cs.tcd.ie> wrote:

Hi Paul,

There's also the question of privacy. Aggregated information is
always more sensitive. Sets of links, in aggregate, do leak
private information.

So it would seem fair to say that the bigger document approach
has the worse privacy problem, at least in the abstract.

If it were the case that webfinger made it noticeably harder to
partition who knows what about me, then that would be a privacy
downside, and not in the abstract, but practically. (Not a sure
showstopper, but a thing that needs attention at least.)

However, I've no idea how these are envisaged to be deployed, or
are being deployed, nor if its (intended to be) easy for a user
to create loads of different profiles/documents/whatever or not.

So - do you agree this is an issue, that webfinger aggregates
(possibly lots of) different pointers related to the same person?

And, how significant is that and are there ways to mitigate it,
for those who might care?

This aspect is essentially ignored by both swd and webfinger
drafts as far as I can see, but does seem worse with the latter
approach, at least as I understand it. (However, for a bit of
balance the string "privacy" does occur in swd, but the term
is misused when "confidentiality" was meant:-)

I do think user privacy is worth consideration regardless of
which approach is taken ultimately.

S

On 04/18/2012 12:40 AM, Paul E. Jones wrote:
> Derek,
>
>> This leaves only the perceived issue of "whole document"= vs "individual
>> attribute". =A0If a client ever wants more than one attribute= then a whole
>> document approach reduces the number of round trips. =A0However if= documents
>> get large that could also affect performance. =A0We might, then, n= eed a way
>> to specify which attributes are requested, but allow for a wildcar= d to
>> return "everything I am authorized to see".
>
> If the document gets large, you're right that it might be an issue= . =A0For
> this reason, we introduced the "rel" parameter in the most r= ecent WebFinger
> draft. =A0Like HTML, this is a space-separated list of link relation t= ypes.
> The idea is that the server will filter based on that list.
>
> If you want to see it in action, you can issue a query against my ID:<= br> > $ curl https://packetizer.com/.well-known/host-meta?\
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 resource=3Dacc= t%3Apaulej%40packetiz= er.com
>
> or
>
> $ curl 'https://packetizer.com/.well-known/host-meta?\
> =A0 =A0 =A0 =A0 resource=3Dacct%3Apaulej%40packetizer.com&\
> =A0 =A0 =A0 =A0 rel=3Dvcard+http%3A%2F%2Fwebfinger.net%2Frel%2Favatar&= #39;
>
> The first example returns the entire XRD document. =A0The second examp= le
> returns only link relations of type vcard or
> http://w= ebfinger.net/rel/avatar. =A0To get JSON output, just replace host-meta<= br> > with host-meta.json as per RFC 6415 (or use an "Accept" head= er with
> application/json).
>
> Now, I'm still wondering if a resource descriptor document will ev= er get so
> large. =A0It does not return information about a user, just pointers t= o
> information. =A0So, do we need "rel"? =A0If there is definit= ely only a certain
> set of link relations of interest, it's a way to limit the output.= =A0I
> suppose it does not hurt to introduce it; it's the value I questio= n. =A0I'd
> definitely like input on the utility. =A0Given the claims that SWD is = simpler
> because of the limited information returned, perhaps that lends to the=
> argument that it is useful.
>
> Paul
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discus= s@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
--00235452f49046792604bde9db02-- From wmills@yahoo-inc.com Tue Apr 17 18:24: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 43A7121F8546 for ; Tue, 17 Apr 2012 18:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.227 X-Spam-Level: X-Spam-Status: No, score=-17.227 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 196vzn8lbjdz for ; Tue, 17 Apr 2012 18:24:00 -0700 (PDT) Received: from nm22.bullet.mail.bf1.yahoo.com (nm22.bullet.mail.bf1.yahoo.com [98.139.212.181]) by ietfa.amsl.com (Postfix) with SMTP id 1FD5521F8526 for ; Tue, 17 Apr 2012 18:24:00 -0700 (PDT) Received: from [98.139.212.153] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 18 Apr 2012 01:23:59 -0000 Received: from [98.139.212.243] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 18 Apr 2012 01:23:59 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 18 Apr 2012 01:23:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 431510.82430.bm@omp1052.mail.bf1.yahoo.com Received: (qmail 7930 invoked by uid 60001); 18 Apr 2012 01:23:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334712238; bh=aXQ7xV31Dib245kqmx9UIlc7glFeBhI4CyzWB0QDfm4=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CNQOuJYtvjMNlqKKF95bi/fqCRFJto+ZZihMcC+c9IzSmOXHgk0Fb2jh4T+pYUWl74hAy3LvvKsSYTzjYoELfgBHSHQ9qCn2O2sUBoxATXR8N5zB7tn77hid+5sB9+x893FbnJmfPrRtEW24jN18VGlIrcjc80PxQa/0kzSqO0s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=n+9PN1rRgNJSPNKpTP+u3FEDXUoQbcrtUU9J1m9oprhj+rz8GJ4gJfNo1vPvo1XTuf+hYBVWAYcH8kYSQ/9snAE5Ln/ax5CsSm132dHCE67EtMI6oH88oef7XZd8rQ4yolgOyNHVeY2ea4xxc7SApN3RT4du2sfBecLT/ww/QEE=; X-YMail-OSG: z.M3IXMVM1kp41.Kqtbow986f6Los..39tLvNLnAMvKRxi4 l1aEMsPsUuipnc.X6pCpgD6B2BPFr8br3e6BlkxL6ktAP.6vlqzEGG6.ITlM XC7a0bRTuNZCN2FN9wP7Z0Y8k6aqPW89kZWamFtm9q6Y8vWftNJKXAN1pz49 w4aICHCKE_L9y7wPoY534S_mMDStNDi9bRYxb4UTZlC.aSUnshd.SKZJcxvN 9UQ7I74hgdVykzQ9WwnCBloi7bhXuRIp6c0BTfsggrbKaMW9isd78fsAErxZ Mnu1ZKTX7JpfthTnevFZr_adZ.PJ2pUNEXLeUSGIZoxpdmfLDQdNl39kC2g. v50oQDF0zUTlhmJwRxxn384aiWMl3VSgDSTTioPK_yKf_vjUiEKwoQdHBUmW PF6lfR9W52MxY8MZ4oiz5cfKUq_8SS0nfkARMg3GOZNsgeMAv9BQ- Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Tue, 17 Apr 2012 18:23:58 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> <1334695329.43020.YahooMailNeo@web31812.mail.mud.yahoo.com> Message-ID: <1334712238.64475.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Tue, 17 Apr 2012 18:23:58 -0700 (PDT) From: William Mills To: Nico Williams , Sam Hartman In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-1397271504-1334712238=:64475" Cc: "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 01:24:04 -0000 --835683298-1397271504-1334712238=:64475 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OK, if this is covered by the mechanisms (which is something a GSS expert p= robably knows but I did not) then I'm less worried.=A0 Is it then worthwhil= e to add "Systems must know how to interpret critical mechanism attributes,= but this is already required by mechanism specifications." in the section = we're talking about to make it explicit rather than implicit?=0A=0A-bill=0A= =0A=0A=0A=0A>________________________________=0A> From: Nico Williams =0A>To: Sam Hartman =0A>Cc: Willi= am Mills ; "draft-ietf-kitten-gssapi-naming-exts.all@= tools.ietf.org" ; = "apps-discuss@ietf.org" ; The IESG = =0A>Sent: Tuesday, April 17, 2012 6:11 PM=0A>Subject: Re: [apps-discuss] Re= sending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14=0A> =0A>= On Tue, Apr 17, 2012 at 3:48 PM, Sam Hartman wrote:= =0A>>>>>>> "William" =3D=3D William Mills writes:=0A= >>=0A>> =A0 =A0William> The key of this for me is "are likely to have suffi= cient=0A>> =A0 =A0William> policy and information". =A0This is fine in disc= ussion, but I=0A>> =A0 =A0William> want to see an explicit declaration abou= t when an=0A>> =A0 =A0William> implementation can treat things as equivalen= t.=0A>>=0A>> I don't think we can say anything about that. Implementations = can treat=0A>> things as equivalent when they know that it's safe to do so = through=0A>> policy which may be hard-coded, configured or downloaded from = somewhere.=0A>> I think that's an implementation matter outside the scope o= f the=0A>> standard.=0A>=0A>I agree.=A0 I suspect Bill is concerned that la= cking "sufficient policy=0A>and information" may lead to vulnerabilities, s= ay, in that critical=0A>attributes may get ignored.=A0 We have no method fo= r indicating=0A>attribute criticality in the proposed API, and this is by d= esign.=0A>Mechanisms may (and Kerberos, for example, does) have methods for= =0A>indicating attribute criticality.=A0 What must happen is that systems= =0A>must know how to interpret critical mechanism attributes, but this is= =0A>already required by mechanism specifications.=A0 So I think we're=0A>co= vered, but perhaps we could make this a little more explicit.=0A>=0A>Nico= =0A>--=0A>=0A>=0A> --835683298-1397271504-1334712238=:64475 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OK, if this is covered by the mechanisms (which is something a GSS expert= probably knows but I did not) then I'm less worried.  Is it then wort= hwhile to add "Systems must know how to interpret critical mechanism= attributes, but this is already required by mechanism specifications." in = the section we're talking about to make it explicit rather than implicit?

-bill

From: Nico Williams <nico@crypto= nector.com>
To: Sam= Hartman <hartmans-ietf@mit.edu>
Cc: William Mills <wmills@yahoo-inc.com>; "draft-iet= f-kitten-gssapi-naming-exts.all@tools.ietf.org" <draft-ietf-kitten-gssap= i-naming-exts.all@tools.ietf.org>; "apps-discuss@ietf.org" <apps-disc= uss@ietf.org>; The IESG <iesg@ietf.org>
Sent: Tuesday, April 17, 2012 6:11 PM
Subject: Re: [apps-discuss] Res= ending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14

=0AOn Tue, Apr 17, 2012 at 3:48 PM, Sam Hartman <ha= rtmans-ietf@mit.edu> wrote:
>>>>>> "William" = =3D=3D William Mills <wmills@yahoo-inc.com> writes:
><= br>>    William> The key of this for me is "are likely to h= ave sufficient
>    William> policy and information". &n= bsp;This is fine in discussion, but I
>    William> want= to see an explicit declaration about when an
>    William&= gt; implementation can treat things as equivalent.
>
> I don't = think we can say anything about that. Implementations can treat
> thi= ngs as equivalent when they know that it's safe to do so through
> po= licy which may be hard-coded, configured or downloaded from somewhere.
&= gt; I think that's an implementation matter outside the scope of the
> standard.

I = agree.  I suspect Bill is concerned that lacking "sufficient policyand information" may lead to vulnerabilities, say, in that critical
att= ributes may get ignored.  We have no method for indicating
attribut= e criticality in the proposed API, and this is by design.
Mechanisms may= (and Kerberos, for example, does) have methods for
indicating attribute= criticality.  What must happen is that systems
must know how to in= terpret critical mechanism attributes, but this is
already required by m= echanism specifications.  So I think we're
covered, but perhaps we = could make this a little more explicit.

Nico
--


--835683298-1397271504-1334712238=:64475-- From internet-drafts@ietf.org Tue Apr 17 19:42: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 3B25E21F8562; Tue, 17 Apr 2012 19:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCOuur7NxhWY; Tue, 17 Apr 2012 19:42:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D9421F84CD; Tue, 17 Apr 2012 19:42:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120418024250.23160.87216.idtracker@ietfa.amsl.com> Date: Tue, 17 Apr 2012 19:42:50 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 02:42:55 -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 Worki= ng Group of the IETF. Title : Email Greylisting: An Applicability Statement for SMTP Author(s) : Murray S. Kucherawy D. Crocker Filename : draft-ietf-appsawg-greylisting-07.txt Pages : 16 Date : 2012-04-17 This memo describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-07.txt From jyee@afilias.info Tue Apr 17 19:52: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 7F49421F85A4 for ; Tue, 17 Apr 2012 19:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5R93aPqx8BNv for ; Tue, 17 Apr 2012 19:52:20 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFDC21F8440 for ; Tue, 17 Apr 2012 19:52:16 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1SKL0C-00072z-6k for Apps-Discuss@ietf.org; Wed, 18 Apr 2012 02:52:16 +0000 Received: from mail-iy0-f178.google.com ([209.85.210.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1SKL0B-0004PZ-5v for Apps-Discuss@ietf.org; Wed, 18 Apr 2012 02:52:15 +0000 Received: by iakl21 with SMTP id l21so10753876iak.9 for ; Tue, 17 Apr 2012 19:52:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=0YaYtb3A+SA2fPp4i9MenI8l0aLhSZ9G2UBLpTVnPJs=; b=PT7JZsaB68HdGoRaVLhOgyGyOGb2lR1nIilcEpqEdv/PHnF4e+NLR3tBahmA+ETms8 7MlS8AMXsI0d/DtiQaNz9eEGz/gr7OceHEFawvkkL7ydJDxOq95Y0COf/7oE9bIwnaWE UCMX3rsYDgQ1ArR2AqRKs9ECsbZscVrXpFUU0DPb7IA/pUw50qEF8O++eZkp5Kk8ksP5 jEPrNDRiuCBbXoAIO/9TQf4Z6x4ogUMFGjA1yMjN1Di9Cmd0CAKInzpu9PD3QlxSnlq5 tUgP2uXHVbGjG3sj4J2q+rDQRivWuIxYbKnZN8rjm229uIvK2jTuW90T71ltqRQNILtG 4bFA== Received: by 10.50.197.132 with SMTP id iu4mr350866igc.74.1334717535310; Tue, 17 Apr 2012 19:52:15 -0700 (PDT) Received: from [192.168.0.103] (76-10-138-202.dsl.teksavvy.com. [76.10.138.202]) by mx.google.com with ESMTPS id pa6sm34711873igc.12.2012.04.17.19.52.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 19:52:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Joseph Yee Date: Tue, 17 Apr 2012 22:52:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Apps-Discuss@ietf.org, draft-ietf-appsawg-greylisting.all@tools.ietf.org X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnrQg0GK39nsvJp0qSR6AFfmuLDup8ayhgP5rVo3Y/Kncg2Su0YYkqoL0cTxyRfPinHbwCN Subject: [apps-discuss] Fwd: APPSDIR review of draft-ietf-appsawg-greylisting-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: Wed, 18 Apr 2012 02:52:24 -0000 Bad typo in typing apps-discuss, forwarded the original review. Joseph Begin forwarded message: > From: Joseph Yee > Date: April 17, 2012 10:34:22 PM EDT > To: app-discuss@ietf.org, = draft-ietf-appsawg-greylisting.all@tools.ietf.org > Subject: APPSDIR review of draft-ietf-appsawg-greylisting-06 >=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)= . >=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-greylisting-06 > Title: Email Greylisting: An Applicability Statement for SMTP > Reviewer: Joseph Yee > Review Date: April 17, 2012 >=20 >=20 > Summary: This draft is ready for publication as Proposed Standard AS >=20 >=20 > Nits: >=20 > Section 5 Recommendation Point 4 > s/Administrative Domain (ADMD)/Administrative Management Domain = (ADMD)/ >=20 > Section 5 Recommendation Point 7 > s/authetnicated/authenticated/ >=20 >=20 >=20 >=20 From msk@cloudmark.com Tue Apr 17 19:54: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 94C1711E8091 for ; Tue, 17 Apr 2012 19:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.667 X-Spam-Level: X-Spam-Status: No, score=-102.667 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSvZLG5jQ8s1 for ; Tue, 17 Apr 2012 19:54:39 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2150E21F8440 for ; Tue, 17 Apr 2012 19:54:39 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id zEue1i0040ZaKgw01Euexa; Tue, 17 Apr 2012 19:54:38 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=W866pGqk c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=lDLtzceVzjAA:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=ddoUimErAAAA:8 a=ZEAgVxdcAAAA:8 a=b6nfwRhkAAAA:8 a=1ZBiGvamRsUXxnLyL2kA:9 a=CVBWwWt7turbtGh4t-YA:7 a=QEXdDO2ut3YA:10 a=BBlAGKNQKQ8A:10 a=lZB815dzVvQA:10 a=vZh6zi8dUYkA:10 a=RjwTPiaSbNEA:10 a=tY9HFf9YrrEDV8tA:21 a=k5p_6fHFk3q7xyLL:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=TPcEOfShVUlMIZ-73esA:9 a=1CAOaISUg5l0VpXdldcA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=tXsnliwV7b4A:10 a=7a9aNFanojMA:10 a=bpq86B7CLB8A:10 a=H8hBHuawGkQC9Srw:21 a=uTN2_nFSy-wcBptt:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 19:54:38 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHPFR3vuAzKShOkysr2w3xgHGFZaf4OeQ Date: Wed, 18 Apr 2012 02:54:37 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F707F@exch-mbx901.corp.cloudmark.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B16804296739436648BF09@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436648BF09@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280F707Fexchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334717678; bh=Of8bgNxVwYWEKL7WNcgHTdKOaxX4TXic50dZpF/Rudw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=QjokM1ArmSnycrvew+2H1rvjMRGqUxoDQ5AAlaOCHSfDfsSz7zUwj3Sh8Me6i16Ax GNDVH+z0BWHrRCd5G4ZHpgix2d+bf1iPFH/LR0HUsiVIP6mmQAje9clEVfRkLZxLY/ UmL4vlJuZn2yziWwEK0PPxJxy9aU/cbHz1KZX9zU= Cc: "oauth@ietf.org WG" Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 02:54:43 -0000 --_000_9452079D1A51524AA5749AD23E0039280F707Fexchmbx901corpclo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gdGhlcmUgYXJlIHNvbWUgb2YgYm90aC4gIEhvdyB0cmVhY2hlcm91cyBpcyB0aGUgbWlncmF0 aW9uIHBhdGggZnJvbSBTV0QgdG8gV2ViRmluZ2VyLCBmb3IgZXhhbXBsZSwgaW4gY2FzZSBjb25z ZW5zdXMgaXMgdG8gZGV2ZWxvcCBhbmQgbW92ZSBmb3J3YXJkIHdpdGggdGhlIGxhdHRlcj8NCg0K LU1TSw0KDQpGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMt ZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2VudDog VHVlc2RheSwgQXByaWwgMTcsIDIwMTIgNDoyNSBQTQ0KVG86IEJsYWluZSBDb29rOyBUaW0gQnJh eQ0KQ2M6IG9hdXRoQGlldGYub3JnIFdHOyBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbYXBwcy1kaXNjdXNzXSBbT0FVVEgtV0ddIFdlYiBGaW5nZXIgdnMuIFNpbXBsZSBXZWIg RGlzY292ZXJ5IChTV0QpDQoNCkkga25vdyB0aGF0IDcgb2YgdGhlIDggcHVibGljIHBhcnRpY2lw YW50cyBpbiB0aGUgY3VycmVudCBPcGVuSUQgQ29ubmVjdCBpbnRlcm9wIHRlc3RpbmcgaGF2ZSBp bXBsZW1lbnRlZCBTV0QgYXQgdGhpcyBwb2ludC4gIChJIGtub3cgb2Ygc2V2ZXJhbCBtb3JlIHdo b+KAmXZlIGJ1aWx0IGl0IGFzIHdlbGwgYnV0IGhhdmVu4oCZdCBjaG9zZW4gdG8gbWFrZSB0aGVp ciBpbnRlcm9wIHRlc3QgcmVzdWx0cyBwdWJsaWMgeWV0LikgIFRoZXJlIGFyZSBsaWtlbHkgb3Ro ZXIgaW1wbGVtZW50YXRpb25zIEnigJltIHVuYXdhcmUgb2YuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJv bTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4g W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmxhaW5lIENvb2sN ClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDM6NTQgUE0NClRvOiBUaW0gQnJheQ0KQ2M6 IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gV0c7IGFwcHMtZGlzY3Vzc0Bp ZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gW2FwcHMtZGlzY3Vzc10gV2ViIEZpbmdlciB2cy4gU2ltcGxlIFdlYiBEaXNjb3Zlcnkg KFNXRCkNCg0KDQpUaGF0J3MgYSB0cmlja3kgcXVlc3Rpb24gLSBtYXliZSBvbmUgZ29vZ2xlIGNh biBoZWxwIGFuc3dlcj8gVGhlcmUgYXJlIGEgYnVuY2ggb2YgcHJvamVjdHMgdXNpbmcgd2ViZmlu Z2VyLCBpbmNsdWRpbmcgc3RhdHVzLm5ldDxodHRwOi8vc3RhdHVzLm5ldD4sIG9zdGF0dXMgaW4g Z2VuZXJhbCwgZGlhc3BvcmEsIHVuaG9zdGVkLCBmcmVlZG9tYm94KD8pLCBhbmQgSSdtIHN1cmUg b3RoZXJzLCBidXQgSSBoYXZlIG5vIGlkZWEgaG93IHRoYXQgdHJhbnNsYXRlcyBpbnRvIGFjdHVh bCB1c2VycyBvciBwcm9maWxlcy4NCg0KR21haWwsIGFvbCwgYW5kIHlhaG9vIGFsbCBwdXQgdXAg d2ViZmluZ2VyIGVuZHBvaW50cywgYnV0IHRoZXJlIGhhc24ndCBiZWVuIG11Y2ggbW92ZW1lbnQs IEkgdGhpbmsgZHVlIHRvIHRoZSBjaGlja2VuIGFuZCBlZ2cgbmF0dXJlIG9mIGFkb3B0aW9uIGFy b3VuZCBkZWNlbnRyYWxpemVkIHRvb2xzLg0KDQpiLg0KT24gQXByIDE3LCAyMDEyIDExOjEzIEFN LCAiVGltIEJyYXkiIDx0YnJheUB0ZXh0dWFsaXR5LmNvbTxtYWlsdG86dGJyYXlAdGV4dHVhbGl0 eS5jb20+PiB3cm90ZToNCldoYXQgaXMgdGhlIGRlcGxveW1lbnQgc3RhdHVzIG9mIHRoZXNlIHR3 byBzcGVjcz8gIElzIGVpdGhlciBkZXBsb3llZA0KbXVjaCBhdCBhbGw/ICAtVA0KDQpPbiBGcmks IEFwciAxMywgMjAxMiBhdCAxMDo0NSBBTSwgTXVycmF5IFMuIEt1Y2hlcmF3eSA8bXNrQGNsb3Vk bWFyay5jb208bWFpbHRvOm1za0BjbG91ZG1hcmsuY29tPj4gd3JvdGU6DQo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmFwcHMtZGlzY3Vz cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZz5d IE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNCj4+IFNlbnQ6IEZyaWRheSwgQXByaWwgMTMs IDIwMTIgOToyMyBBTQ0KPj4gVG86IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y Zz4gV0cNCj4+IENjOiBBcHBzIERpc2N1c3MNCj4+IFN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNz XSBbT0FVVEgtV0ddIFdlYiBGaW5nZXIgdnMuIFNpbXBsZSBXZWIgRGlzY292ZXJ5IChTV0QpDQo+ Pg0KPj4gU28gSGFubmVzIGFuZCBEZXJlayBhbmQgSSBoYXZlIGJlZW4gZGlzY3Vzc2luZyB0aGlz IHdpdGggdGhlIEFwcHMgQURzDQo+PiBhbmQgQXBwcy1hcmVhIFdHIGNoYWlycy4gSSd2ZSBhbHNv IHJlYWQgdGhlIGRvY3Mgbm93LCBhbmQgYWZ0ZXIgYWxsDQo+PiB0aGF0IHdlJ3ZlIGRlY2lkZWQg dGhhdCB0aGlzIHRvcGljICh3aGF0IHRvIGRvIHdpdGggc3dkIGFuZCB3ZWJmaW5nZXIpDQo+PiBp cyBiZXN0IGhhbmRsZWQgaW4gdGhlIGFwcHMgYXJlYSBhbmQgbm90IGluIHRoZSBvYXV0aCBXRy4N Cj4+DQo+PiBUaGUgbG9naWMgZm9yIHRoYXQgaXMgdGhhdCAxKSB0aGUgdHdvIHByb3Bvc2FscyBh cmUgZG9pbmcgdGhlIHNhbWUNCj4+IHRoaW5nIGFuZCB3ZSBkb24ndCB3YW50IHR3byBkaWZmZXJl bnQgc3RhbmRhcmRzIGZvciB0aGF0LCBiKSB0aGlzIGlzDQo+PiBub3QgYW4gb2F1dGgtc3BlY2lm aWMgdGhpbmcgbm9yIGlzIGl0IGEgZ2VuZXJhbCBzZWN1cml0eSB0aGluZywgYW5kIGMpDQo+PiB0 aGVyZSBpcyBjbGVhcmx5IGFscmVhZHkgaW50ZXJlc3QgaW4gdGhlIHRvcGljIGluIHRoZSBhcHBz IGFyZWEgc28gaXRzDQo+PiByZWFzb25hYmxlIGZvciB0aGUgb2F1dGggd2cgdG8gdXNlIHRoYXQg d2hlbiBpdHMgcmVhZHkuDQo+Pg0KPj4gVGhlIGFwcHNhd2cgY2hhaXJzIGFuZCBhcHBzIEFEcyBh cmUgb2sgd2l0aCB0aGUgd29yayBiZWluZyBkb25lIHRoZXJlLg0KPj4NCj4+IFNvOi0NCj4+DQo+ PiAtIEkndmUgYXNrZWQgdGhlIG9hdXRoIGNoYWlycyB0byB0YWtlIGRvaW5nIHdvcmsgb24gc3dk DQo+PiAgIG91dCBvZiB0aGUgcHJvcG9zZWQgbmV3IGNoYXJ0ZXINCj4+IC0gSXQgbWF5IGJlIHRo YXQgeW91IHdhbnQgdG8gYWRkIHNvbWV0aGluZyBzYXlpbmcgdGhhdA0KPj4gICBvYXV0aCB3aWxs IHVzZSB0aGUgcmVzdWx0cyBvZiB3b3JrIGluIHRoZSBhcHBsaWNhdGlvbnMNCj4+ICAgYXJlYSBv biBhIHdlYiBkaXNjb3ZlcnkgcHJvdG9jb2wgYXMgYSBiYXNpcyBmb3IgZG9pbmcNCj4+ICAgdGhl IGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiB3b3JrIGhlcmUNCj4+IC0gRGlzY3Vzc2lvbiBv ZiB3ZWJmaW5nZXIgYW5kIHN3ZCBzaG91bGQgbW92ZSBvdmVyIHRvDQo+PiAgIHRoZSBhcHBzLWRp c2N1c3MgbGlzdA0KPj4gLSBOb3RlOiB0aGlzIGlzIG5vdCBwaWNraW5nIG9uZSBvciB0aGUgb3Ro ZXIgYXBwcm9hY2gsDQo+PiAgIHRoZSBwbGFuIGlzIHRoYXQgdGhlIGFwcHMgYXJlYSB3aWxsIGRv IGFueSBzZWxlY3Rpb24NCj4+ICAgbmVlZGVkIGFuZCBmaWd1cmUgb3V0IHRoZSBiZXN0IHN0YXJ0 aW5nIHBvaW50IGZvciBhDQo+PiAgIHN0YW5kYXJkcy10cmFjayBSRkMgb24gd2ViIGRpc2NvdmVy eSBhbmQgd2UnbGwgdXNlIHRoZWlyDQo+PiAgIGZpbmUgd29yayBmb3IgZG9pbmcgbW9yZSB3aXRo IG9hdXRoLg0KPg0KPiBUaGFuayB5b3UgU3RlcGhlbiwgSSB0aGluay4gIDotKQ0KPg0KPiBTbyB0 aGUgZGlzY3Vzc2lvbiBvbiBhcHBzLWRpc2N1c3Mgbm93IHNob3VsZCBiZSBmb2N1c2VkIG9uIHdo aWNoIG9mIHRoZSB0d28gc2hvdWxkIGJlIHRoZSBiYXNpcyBmb3IgZm9yd2FyZCBwcm9ncmVzcy4g IEkndmUgcGxhY2VkIGJvdGggZG9jdW1lbnRzIGluICJDYWxsIGZvciBBZG9wdGlvbiIgc3RhdGUg aW4gdGhlIGRhdGF0cmFja2VyIGZvciBhcHBzYXdnLg0KPg0KPiBMZXQgdGhlIGdhbWVzIGJlZ2lu Lg0KPg0KPiAtTVNLDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IGFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCj4gYXBwcy1kaXNjdXNzQGlldGYu b3JnPG1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQo= --_000_9452079D1A51524AA5749AD23E0039280F707Fexchmbx901corpclo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5TbyB0aGVyZSBhcmUgc29tZSBvZiBib3RoLiZuYnNwOyBIb3cgdHJlYWNoZXJv dXMgaXMgdGhlIG1pZ3JhdGlvbiBwYXRoIGZyb20gU1dEIHRvIFdlYkZpbmdlciwgZm9yIGV4YW1w bGUsIGluIGNhc2UgY29uc2Vuc3VzIGlzIHRvIGRldmVsb3AgYW5kIG1vdmUgZm9yd2FyZCB3aXRo DQogdGhlIGxhdHRlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1NU0s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzph cHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBK b25lczxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA0OjI1IFBNPGJy Pg0KPGI+VG86PC9iPiBCbGFpbmUgQ29vazsgVGltIEJyYXk8YnI+DQo8Yj5DYzo8L2I+IG9hdXRo QGlldGYub3JnIFdHOyBhcHBzLWRpc2N1c3NAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFthcHBzLWRpc2N1c3NdIFtPQVVUSC1XR10gV2ViIEZpbmdlciB2cy4gU2ltcGxlIFdlYiBE aXNjb3ZlcnkgKFNXRCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBrbm93IHRo YXQgNyBvZiB0aGUgOCBwdWJsaWMgcGFydGljaXBhbnRzIGluIHRoZSBjdXJyZW50IE9wZW5JRCBD b25uZWN0IGludGVyb3AgdGVzdGluZyBoYXZlIGltcGxlbWVudGVkIFNXRCBhdCB0aGlzIHBvaW50 LiZuYnNwOyAoSSBrbm93IG9mIHNldmVyYWwgbW9yZSB3aG/igJl2ZQ0KIGJ1aWx0IGl0IGFzIHdl bGwgYnV0IGhhdmVu4oCZdCBjaG9zZW4gdG8gbWFrZSB0aGVpciBpbnRlcm9wIHRlc3QgcmVzdWx0 cyBwdWJsaWMgeWV0LikmbmJzcDsgVGhlcmUgYXJlIGxpa2VseSBvdGhlciBpbXBsZW1lbnRhdGlv bnMgSeKAmW0gdW5hd2FyZSBvZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVm PSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CbGFpbmUgQ29vazxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiAzOjU0IFBNPGJyPg0KPGI+VG86PC9iPiBUaW0g QnJheTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0 aEBpZXRmLm9yZzwvYT4gV0c7IDxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmci Pg0KYXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBbYXBwcy1kaXNjdXNzXSBXZWIgRmluZ2VyIHZzLiBTaW1wbGUgV2ViIERpc2NvdmVy eSAoU1dEKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHA+VGhhdCdzIGEgdHJpY2t5IHF1ZXN0aW9uIC0gbWF5YmUgb25l IGdvb2dsZSBjYW4gaGVscCBhbnN3ZXI/IFRoZXJlIGFyZSBhIGJ1bmNoIG9mIHByb2plY3RzIHVz aW5nIHdlYmZpbmdlciwgaW5jbHVkaW5nDQo8YSBocmVmPSJodHRwOi8vc3RhdHVzLm5ldCI+c3Rh dHVzLm5ldDwvYT4sIG9zdGF0dXMgaW4gZ2VuZXJhbCwgZGlhc3BvcmEsIHVuaG9zdGVkLCBmcmVl ZG9tYm94KD8pLCBhbmQgSSdtIHN1cmUgb3RoZXJzLCBidXQgSSBoYXZlIG5vIGlkZWEgaG93IHRo YXQgdHJhbnNsYXRlcyBpbnRvIGFjdHVhbCB1c2VycyBvciBwcm9maWxlcy48bzpwPjwvbzpwPjwv cD4NCjxwPkdtYWlsLCBhb2wsIGFuZCB5YWhvbyBhbGwgcHV0IHVwIHdlYmZpbmdlciBlbmRwb2lu dHMsIGJ1dCB0aGVyZSBoYXNuJ3QgYmVlbiBtdWNoIG1vdmVtZW50LCBJIHRoaW5rIGR1ZSB0byB0 aGUgY2hpY2tlbiBhbmQgZWdnIG5hdHVyZSBvZiBhZG9wdGlvbiBhcm91bmQgZGVjZW50cmFsaXpl ZCB0b29scy48bzpwPjwvbzpwPjwvcD4NCjxwPmIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gQXByIDE3LCAyMDEyIDExOjEzIEFNLCAmcXVvdDtUaW0gQnJh eSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRicmF5QHRleHR1YWxpdHkuY29tIiB0YXJnZXQ9 Il9ibGFuayI+dGJyYXlAdGV4dHVhbGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgaXMgdGhlIGRlcGxveW1lbnQgc3RhdHVzIG9m IHRoZXNlIHR3byBzcGVjcz8gJm5ic3A7SXMgZWl0aGVyIGRlcGxveWVkPGJyPg0KbXVjaCBhdCBh bGw/ICZuYnNwOy1UPGJyPg0KPGJyPg0KT24gRnJpLCBBcHIgMTMsIDIwMTIgYXQgMTA6NDUgQU0s IE11cnJheSBTLiBLdWNoZXJhd3kgJmx0OzxhIGhyZWY9Im1haWx0bzptc2tAY2xvdWRtYXJrLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1za0BjbG91ZG1hcmsuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0K Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyBGcm9tOiA8 YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5hcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJt YWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5hcHBz LWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJl bGw8YnI+DQomZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEFwcmlsIDEzLCAyMDEyIDk6MjMgQU08YnI+ DQomZ3Q7Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+IFdHPGJyPg0KJmd0OyZndDsgQ2M6IEFwcHMgRGlzY3Vz czxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBbT0FVVEgtV0ddIFdl YiBGaW5nZXIgdnMuIFNpbXBsZSBXZWIgRGlzY292ZXJ5IChTV0QpPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBTbyBIYW5uZXMgYW5kIERlcmVrIGFuZCBJIGhhdmUgYmVlbiBkaXNjdXNzaW5n IHRoaXMgd2l0aCB0aGUgQXBwcyBBRHM8YnI+DQomZ3Q7Jmd0OyBhbmQgQXBwcy1hcmVhIFdHIGNo YWlycy4gSSd2ZSBhbHNvIHJlYWQgdGhlIGRvY3Mgbm93LCBhbmQgYWZ0ZXIgYWxsPGJyPg0KJmd0 OyZndDsgdGhhdCB3ZSd2ZSBkZWNpZGVkIHRoYXQgdGhpcyB0b3BpYyAod2hhdCB0byBkbyB3aXRo IHN3ZCBhbmQgd2ViZmluZ2VyKTxicj4NCiZndDsmZ3Q7IGlzIGJlc3QgaGFuZGxlZCBpbiB0aGUg YXBwcyBhcmVhIGFuZCBub3QgaW4gdGhlIG9hdXRoIFdHLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgVGhlIGxvZ2ljIGZvciB0aGF0IGlzIHRoYXQgMSkgdGhlIHR3byBwcm9wb3NhbHMgYXJl IGRvaW5nIHRoZSBzYW1lPGJyPg0KJmd0OyZndDsgdGhpbmcgYW5kIHdlIGRvbid0IHdhbnQgdHdv IGRpZmZlcmVudCBzdGFuZGFyZHMgZm9yIHRoYXQsIGIpIHRoaXMgaXM8YnI+DQomZ3Q7Jmd0OyBu b3QgYW4gb2F1dGgtc3BlY2lmaWMgdGhpbmcgbm9yIGlzIGl0IGEgZ2VuZXJhbCBzZWN1cml0eSB0 aGluZywgYW5kIGMpPGJyPg0KJmd0OyZndDsgdGhlcmUgaXMgY2xlYXJseSBhbHJlYWR5IGludGVy ZXN0IGluIHRoZSB0b3BpYyBpbiB0aGUgYXBwcyBhcmVhIHNvIGl0czxicj4NCiZndDsmZ3Q7IHJl YXNvbmFibGUgZm9yIHRoZSBvYXV0aCB3ZyB0byB1c2UgdGhhdCB3aGVuIGl0cyByZWFkeS48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBhcHBzYXdnIGNoYWlycyBhbmQgYXBwcyBBRHMg YXJlIG9rIHdpdGggdGhlIHdvcmsgYmVpbmcgZG9uZSB0aGVyZS48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IFNvOi08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0gSSd2ZSBhc2tlZCB0 aGUgb2F1dGggY2hhaXJzIHRvIHRha2UgZG9pbmcgd29yayBvbiBzd2Q8YnI+DQomZ3Q7Jmd0OyAm bmJzcDsgb3V0IG9mIHRoZSBwcm9wb3NlZCBuZXcgY2hhcnRlcjxicj4NCiZndDsmZ3Q7IC0gSXQg bWF5IGJlIHRoYXQgeW91IHdhbnQgdG8gYWRkIHNvbWV0aGluZyBzYXlpbmcgdGhhdDxicj4NCiZn dDsmZ3Q7ICZuYnNwOyBvYXV0aCB3aWxsIHVzZSB0aGUgcmVzdWx0cyBvZiB3b3JrIGluIHRoZSBh cHBsaWNhdGlvbnM8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgYXJlYSBvbiBhIHdlYiBkaXNjb3Zlcnkg cHJvdG9jb2wgYXMgYSBiYXNpcyBmb3IgZG9pbmc8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgdGhlIGR5 bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiB3b3JrIGhlcmU8YnI+DQomZ3Q7Jmd0OyAtIERpc2N1 c3Npb24gb2Ygd2ViZmluZ2VyIGFuZCBzd2Qgc2hvdWxkIG1vdmUgb3ZlciB0bzxicj4NCiZndDsm Z3Q7ICZuYnNwOyB0aGUgYXBwcy1kaXNjdXNzIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAtIE5vdGU6IHRo aXMgaXMgbm90IHBpY2tpbmcgb25lIG9yIHRoZSBvdGhlciBhcHByb2FjaCw8YnI+DQomZ3Q7Jmd0 OyAmbmJzcDsgdGhlIHBsYW4gaXMgdGhhdCB0aGUgYXBwcyBhcmVhIHdpbGwgZG8gYW55IHNlbGVj dGlvbjxicj4NCiZndDsmZ3Q7ICZuYnNwOyBuZWVkZWQgYW5kIGZpZ3VyZSBvdXQgdGhlIGJlc3Qg c3RhcnRpbmcgcG9pbnQgZm9yIGE8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgc3RhbmRhcmRzLXRyYWNr IFJGQyBvbiB3ZWIgZGlzY292ZXJ5IGFuZCB3ZSdsbCB1c2UgdGhlaXI8YnI+DQomZ3Q7Jmd0OyAm bmJzcDsgZmluZSB3b3JrIGZvciBkb2luZyBtb3JlIHdpdGggb2F1dGguPGJyPg0KJmd0Ozxicj4N CiZndDsgVGhhbmsgeW91IFN0ZXBoZW4sIEkgdGhpbmsuICZuYnNwOzotKTxicj4NCiZndDs8YnI+ DQomZ3Q7IFNvIHRoZSBkaXNjdXNzaW9uIG9uIGFwcHMtZGlzY3VzcyBub3cgc2hvdWxkIGJlIGZv Y3VzZWQgb24gd2hpY2ggb2YgdGhlIHR3byBzaG91bGQgYmUgdGhlIGJhc2lzIGZvciBmb3J3YXJk IHByb2dyZXNzLiAmbmJzcDtJJ3ZlIHBsYWNlZCBib3RoIGRvY3VtZW50cyBpbiAmcXVvdDtDYWxs IGZvciBBZG9wdGlvbiZxdW90OyBzdGF0ZSBpbiB0aGUgZGF0YXRyYWNrZXIgZm9yIGFwcHNhd2cu PGJyPg0KJmd0Ozxicj4NCiZndDsgTGV0IHRoZSBnYW1lcyBiZWdpbi48YnI+DQomZ3Q7PGJyPg0K Jmd0OyAtTVNLPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDsgYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdDxicj4NCiZndDsg PGEgaHJlZj0ibWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFw cHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3M8L2E+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9452079D1A51524AA5749AD23E0039280F707Fexchmbx901corpclo_-- From paulej@packetizer.com Tue Apr 17 20:14: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 2E9BF11E8076 for ; Tue, 17 Apr 2012 20:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2kMd7FHYCfd for ; Tue, 17 Apr 2012 20:14:38 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8255211E8079 for ; Tue, 17 Apr 2012 20:14:38 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3I3EY0e009104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2012 23:14:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334718875; bh=O9ZRKxpb6zs4OiKlO6+JeajqlfLdxW2Kj+XIcCyJR7A=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=MUIiDgvnHlGwNkcKhOQb3FA7jLqthgJxr4Z2uMKsctLn+U+Bh98+4z1Kdd60Sdolu AbYFjkAbQtlhIXqq9rCdAaSg8H9Rym+nAFThoskKLS1wqRcgzyTK0rlb1MA+CbQSug mnodvoT8B8qNNB0yQBccIAJkSXc8riSG9/SH/n+E= From: "Paul E. Jones" To: "'Stephen Farrell'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <04f601cd1cf3$88ab49d0$9a01dd70$@packetizer.com> <4F8E0485.3020105@cs.tcd.ie> In-Reply-To: <4F8E0485.3020105@cs.tcd.ie> Date: Tue, 17 Apr 2012 23:14:51 -0400 Message-ID: <054b01cd1d11$6ba92870$42fb7950$@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: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGSK4AuATHJkieV8Sp/QA== Content-Language: en-us Cc: 'Derek Atkins' , 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 03:14:43 -0000 Stephen, > There's also the question of privacy. Aggregated information is always > more sensitive. Sets of links, in aggregate, do leak private information. Links should never leak private information. WebFinger should provide links only to information that a user has made publically available or that is protected in some way. > If it were the case that webfinger made it noticeably harder to partition > who knows what about me, then that would be a privacy downside, and not in > the abstract, but practically. (Not a sure showstopper, but a thing that > needs attention at least.) If your private information was shared, I would agree. I think what you are saying is that you are concerned with the fact that if you share information publically in different places (e.g., a photo sharing site, a blog, a file sharing service, a "profile" page) that bringing together pointers to all of that in one place is a concern. Perhaps, but there are two remedies: 1) Don't share everything publically 2) Don't put that information into your account and reported by WebFinger As an example of (2), I choose to report certain information from my Google+ profile page that points to other sites. I'm not so concerned with privacy, since I know people can find anything via Google, anyway. For those concerned with privacy, they ought not do that. Further, if you're so concerned about privacy, don't share anything that is publically accessible. > However, I've no idea how these are envisaged to be deployed, or are being > deployed, nor if its (intended to be) easy for a user to create loads of > different profiles/documents/whatever or not. Google+ is perhaps the best example and most complete example currently. Visit this URL: http://webfingerclient-dclinton.appspot.com/ If you have a gmail address, put in acct:@gmail.com, using your Gmail ID. This will return a set of link relations pointing to information you have shared, all of which would be visible from your Google+ profile page. If you know your Google+ profile ID, you can use that, too. You can query mine using this acct URI: acct:103173924987331945891@gmail.com I do not share certain information and Google allows me to control what information I share. Within an enterprise environment, I would expect a wider range of contact information would normally be shared (business mailing address, phone numbers, email IDs, photo, etc.) The kinds and type of information that would be shared via WebFinger depends on the service, but it should be either set by some policy (e.g., corporate IT policies that are similar to the decisions made for an internal corporate directory) or by the user (e.g., when setting information public or not in an social networking site). > So - do you agree this is an issue, that webfinger aggregates (possibly > lots of) different pointers related to the same person? No, because it does not go out and get information from all over the Internet. A WebFinger profile shares only information you want shared or as dictated by IT policy. A general search engine aggregates information from all over about me and on topics over which I have no control, far more so than WebFinger would. > And, how significant is that and are there ways to mitigate it, for those > who might care? As I said, I think Google+ is a good example to follow. I think that nearly every piece of information on my profile page I can set to "public" or not. Only information marked "public" is exposed via WebFinger. Any use of WebFinger that shared more than as set by policies or by the user would be a misuse and should be addressed by the user community of whatever site of inconsiderate of user privacy. I view this as no different than, say, Google+ putting up a profile page with my private information for the public to see. Whether they see the information via a browser or via WebFinger, I should have control over what's exposed. > This aspect is essentially ignored by both swd and webfinger drafts as far > as I can see, but does seem worse with the latter approach, at least as I > understand it. (However, for a bit of balance the string "privacy" does > occur in swd, but the term is misused when "confidentiality" was meant:-) > > I do think user privacy is worth consideration regardless of which > approach is taken ultimately. Without using the word "privacy" we do discuss that issue a bit in the security section. I'd be happy to add additional text or change it. At the end of the day, though, no standard can dictate privacy issues. We can only provide guidance and reminders about the importance of privacy, which does actually vary from person to person. Paul From eran@hueniverse.com Tue Apr 17 20:23: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 C4BBE11E8076 for ; Tue, 17 Apr 2012 20:23: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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPg2Z-PqVM4k for ; Tue, 17 Apr 2012 20:23:22 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2C011E8075 for ; Tue, 17 Apr 2012 20:23:22 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id zFPM1i0060EuLVk01FPMJY; Tue, 17 Apr 2012 20:23:21 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Tue, 17 Apr 2012 20:23:21 -0700 From: Eran Hammer To: "Murray S. Kucherawy" , "apps-discuss@ietf.org" Thread-Topic: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHQ6eelXXSLZwHUWd2CXBdF+yw5af6sig Date: Wed, 18 Apr 2012 03:23:21 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3A5@P3PWEX2MB008.ex2.secureserver.net> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B16804296739436648BF09@TK5EX14MBXC284.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E0039280F707F@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280F707F@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3A5P3PWEX2MB008ex2se_" MIME-Version: 1.0 Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 03:23:26 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3A5P3PWEX2MB008ex2se_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHJhY3RpY2FsbHkgdmVyeSBsaXR0bGUgaWYgdGhlIGxhdGVzdCBXZWJmaW5nZXIgZHJhZnQgYWRk aXRpb24gYXJlIGFkb3B0ZWQgKGUuZy4gdGhlIHJlc291cmNlIGFuZCByZWwgcXVlcnkgc2hvcnRj dXRzIHdoaWNoIHdlcmUgb3JpZ2luYWxseSBwcm9wb3NlZCBpbiB0aGUgZmlyc3QgT3BlbklEIENv bm5lY3QgcHJvcG9zYWwgYnkgRGF2aWQgUmVjb3Jkb24gYW5kIG15c2VsZikuDQoNCkVIDQoNCkZy b206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgTXVycmF5IFMuIEt1Y2hlcmF3eQ0KU2VudDogVHVlc2RheSwgQXByaWwg MTcsIDIwMTIgNzo1NSBQTQ0KVG86IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KQ2M6IG9hdXRoQGll dGYub3JnIFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBbYXBwcy1kaXNjdXNzXSBXZWIgRmlu Z2VyIHZzLiBTaW1wbGUgV2ViIERpc2NvdmVyeSAoU1dEKQ0KDQpTbyB0aGVyZSBhcmUgc29tZSBv ZiBib3RoLiAgSG93IHRyZWFjaGVyb3VzIGlzIHRoZSBtaWdyYXRpb24gcGF0aCBmcm9tIFNXRCB0 byBXZWJGaW5nZXIsIGZvciBleGFtcGxlLCBpbiBjYXNlIGNvbnNlbnN1cyBpcyB0byBkZXZlbG9w IGFuZCBtb3ZlIGZvcndhcmQgd2l0aCB0aGUgbGF0dGVyPw0KDQotTVNLDQoNCkZyb206IGFwcHMt ZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRm Lm9yZz4gW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOlttYWls dG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgTWlrZSBKb25l cw0KU2VudDogVHVlc2RheSwgQXByaWwgMTcsIDIwMTIgNDoyNSBQTQ0KVG86IEJsYWluZSBDb29r OyBUaW0gQnJheQ0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gV0c7 IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFtPQVVUSC1XR10gV2ViIEZpbmdlciB2cy4gU2ltcGxl IFdlYiBEaXNjb3ZlcnkgKFNXRCkNCg0KSSBrbm93IHRoYXQgNyBvZiB0aGUgOCBwdWJsaWMgcGFy dGljaXBhbnRzIGluIHRoZSBjdXJyZW50IE9wZW5JRCBDb25uZWN0IGludGVyb3AgdGVzdGluZyBo YXZlIGltcGxlbWVudGVkIFNXRCBhdCB0aGlzIHBvaW50LiAgKEkga25vdyBvZiBzZXZlcmFsIG1v cmUgd2hv4oCZdmUgYnVpbHQgaXQgYXMgd2VsbCBidXQgaGF2ZW7igJl0IGNob3NlbiB0byBtYWtl IHRoZWlyIGludGVyb3AgdGVzdCByZXN1bHRzIHB1YmxpYyB5ZXQuKSAgVGhlcmUgYXJlIGxpa2Vs eSBvdGhlciBpbXBsZW1lbnRhdGlvbnMgSeKAmW0gdW5hd2FyZSBvZi4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K DQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCbGFpbmUg Q29vaw0KU2VudDogVHVlc2RheSwgQXByaWwgMTcsIDIwMTIgMzo1NCBQTQ0KVG86IFRpbSBCcmF5 DQpDYzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPiBXRzsgYXBwcy1kaXNj dXNzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBbYXBwcy1kaXNjdXNzXSBXZWIgRmluZ2VyIHZzLiBTaW1wbGUgV2ViIERpc2Nv dmVyeSAoU1dEKQ0KDQoNClRoYXQncyBhIHRyaWNreSBxdWVzdGlvbiAtIG1heWJlIG9uZSBnb29n bGUgY2FuIGhlbHAgYW5zd2VyPyBUaGVyZSBhcmUgYSBidW5jaCBvZiBwcm9qZWN0cyB1c2luZyB3 ZWJmaW5nZXIsIGluY2x1ZGluZyBzdGF0dXMubmV0PGh0dHA6Ly9zdGF0dXMubmV0Piwgb3N0YXR1 cyBpbiBnZW5lcmFsLCBkaWFzcG9yYSwgdW5ob3N0ZWQsIGZyZWVkb21ib3goPyksIGFuZCBJJ20g c3VyZSBvdGhlcnMsIGJ1dCBJIGhhdmUgbm8gaWRlYSBob3cgdGhhdCB0cmFuc2xhdGVzIGludG8g YWN0dWFsIHVzZXJzIG9yIHByb2ZpbGVzLg0KDQpHbWFpbCwgYW9sLCBhbmQgeWFob28gYWxsIHB1 dCB1cCB3ZWJmaW5nZXIgZW5kcG9pbnRzLCBidXQgdGhlcmUgaGFzbid0IGJlZW4gbXVjaCBtb3Zl bWVudCwgSSB0aGluayBkdWUgdG8gdGhlIGNoaWNrZW4gYW5kIGVnZyBuYXR1cmUgb2YgYWRvcHRp b24gYXJvdW5kIGRlY2VudHJhbGl6ZWQgdG9vbHMuDQoNCmIuDQpPbiBBcHIgMTcsIDIwMTIgMTE6 MTMgQU0sICJUaW0gQnJheSIgPHRicmF5QHRleHR1YWxpdHkuY29tPG1haWx0bzp0YnJheUB0ZXh0 dWFsaXR5LmNvbT4+IHdyb3RlOg0KV2hhdCBpcyB0aGUgZGVwbG95bWVudCBzdGF0dXMgb2YgdGhl c2UgdHdvIHNwZWNzPyAgSXMgZWl0aGVyIGRlcGxveWVkDQptdWNoIGF0IGFsbD8gIC1UDQoNCk9u IEZyaSwgQXByIDEzLCAyMDEyIGF0IDEwOjQ1IEFNLCBNdXJyYXkgUy4gS3VjaGVyYXd5IDxtc2tA Y2xvdWRtYXJrLmNvbTxtYWlsdG86bXNrQGNsb3VkbWFyay5jb20+PiB3cm90ZToNCj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86YXBwcy1k aXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYu b3JnPl0gT24gQmVoYWxmIE9mIFN0ZXBoZW4gRmFycmVsbA0KPj4gU2VudDogRnJpZGF5LCBBcHJp bCAxMywgMjAxMiA5OjIzIEFNDQo+PiBUbzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGll dGYub3JnPiBXRw0KPj4gQ2M6IEFwcHMgRGlzY3Vzcw0KPj4gU3ViamVjdDogUmU6IFthcHBzLWRp c2N1c3NdIFtPQVVUSC1XR10gV2ViIEZpbmdlciB2cy4gU2ltcGxlIFdlYiBEaXNjb3ZlcnkgKFNX RCkNCj4+DQo+PiBTbyBIYW5uZXMgYW5kIERlcmVrIGFuZCBJIGhhdmUgYmVlbiBkaXNjdXNzaW5n IHRoaXMgd2l0aCB0aGUgQXBwcyBBRHMNCj4+IGFuZCBBcHBzLWFyZWEgV0cgY2hhaXJzLiBJJ3Zl IGFsc28gcmVhZCB0aGUgZG9jcyBub3csIGFuZCBhZnRlciBhbGwNCj4+IHRoYXQgd2UndmUgZGVj aWRlZCB0aGF0IHRoaXMgdG9waWMgKHdoYXQgdG8gZG8gd2l0aCBzd2QgYW5kIHdlYmZpbmdlcikN Cj4+IGlzIGJlc3QgaGFuZGxlZCBpbiB0aGUgYXBwcyBhcmVhIGFuZCBub3QgaW4gdGhlIG9hdXRo IFdHLg0KPj4NCj4+IFRoZSBsb2dpYyBmb3IgdGhhdCBpcyB0aGF0IDEpIHRoZSB0d28gcHJvcG9z YWxzIGFyZSBkb2luZyB0aGUgc2FtZQ0KPj4gdGhpbmcgYW5kIHdlIGRvbid0IHdhbnQgdHdvIGRp ZmZlcmVudCBzdGFuZGFyZHMgZm9yIHRoYXQsIGIpIHRoaXMgaXMNCj4+IG5vdCBhbiBvYXV0aC1z cGVjaWZpYyB0aGluZyBub3IgaXMgaXQgYSBnZW5lcmFsIHNlY3VyaXR5IHRoaW5nLCBhbmQgYykN Cj4+IHRoZXJlIGlzIGNsZWFybHkgYWxyZWFkeSBpbnRlcmVzdCBpbiB0aGUgdG9waWMgaW4gdGhl IGFwcHMgYXJlYSBzbyBpdHMNCj4+IHJlYXNvbmFibGUgZm9yIHRoZSBvYXV0aCB3ZyB0byB1c2Ug dGhhdCB3aGVuIGl0cyByZWFkeS4NCj4+DQo+PiBUaGUgYXBwc2F3ZyBjaGFpcnMgYW5kIGFwcHMg QURzIGFyZSBvayB3aXRoIHRoZSB3b3JrIGJlaW5nIGRvbmUgdGhlcmUuDQo+Pg0KPj4gU286LQ0K Pj4NCj4+IC0gSSd2ZSBhc2tlZCB0aGUgb2F1dGggY2hhaXJzIHRvIHRha2UgZG9pbmcgd29yayBv biBzd2QNCj4+ICAgb3V0IG9mIHRoZSBwcm9wb3NlZCBuZXcgY2hhcnRlcg0KPj4gLSBJdCBtYXkg YmUgdGhhdCB5b3Ugd2FudCB0byBhZGQgc29tZXRoaW5nIHNheWluZyB0aGF0DQo+PiAgIG9hdXRo IHdpbGwgdXNlIHRoZSByZXN1bHRzIG9mIHdvcmsgaW4gdGhlIGFwcGxpY2F0aW9ucw0KPj4gICBh cmVhIG9uIGEgd2ViIGRpc2NvdmVyeSBwcm90b2NvbCBhcyBhIGJhc2lzIGZvciBkb2luZw0KPj4g ICB0aGUgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIHdvcmsgaGVyZQ0KPj4gLSBEaXNjdXNz aW9uIG9mIHdlYmZpbmdlciBhbmQgc3dkIHNob3VsZCBtb3ZlIG92ZXIgdG8NCj4+ICAgdGhlIGFw cHMtZGlzY3VzcyBsaXN0DQo+PiAtIE5vdGU6IHRoaXMgaXMgbm90IHBpY2tpbmcgb25lIG9yIHRo ZSBvdGhlciBhcHByb2FjaCwNCj4+ICAgdGhlIHBsYW4gaXMgdGhhdCB0aGUgYXBwcyBhcmVhIHdp bGwgZG8gYW55IHNlbGVjdGlvbg0KPj4gICBuZWVkZWQgYW5kIGZpZ3VyZSBvdXQgdGhlIGJlc3Qg c3RhcnRpbmcgcG9pbnQgZm9yIGENCj4+ICAgc3RhbmRhcmRzLXRyYWNrIFJGQyBvbiB3ZWIgZGlz Y292ZXJ5IGFuZCB3ZSdsbCB1c2UgdGhlaXINCj4+ICAgZmluZSB3b3JrIGZvciBkb2luZyBtb3Jl IHdpdGggb2F1dGguDQo+DQo+IFRoYW5rIHlvdSBTdGVwaGVuLCBJIHRoaW5rLiAgOi0pDQo+DQo+ IFNvIHRoZSBkaXNjdXNzaW9uIG9uIGFwcHMtZGlzY3VzcyBub3cgc2hvdWxkIGJlIGZvY3VzZWQg b24gd2hpY2ggb2YgdGhlIHR3byBzaG91bGQgYmUgdGhlIGJhc2lzIGZvciBmb3J3YXJkIHByb2dy ZXNzLiAgSSd2ZSBwbGFjZWQgYm90aCBkb2N1bWVudHMgaW4gIkNhbGwgZm9yIEFkb3B0aW9uIiBz dGF0ZSBpbiB0aGUgZGF0YXRyYWNrZXIgZm9yIGFwcHNhd2cuDQo+DQo+IExldCB0aGUgZ2FtZXMg YmVnaW4uDQo+DQo+IC1NU0sNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdA0KPiBhcHBzLWRpc2N1c3NA aWV0Zi5vcmc8bWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCg== --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3A5P3PWEX2MB008ex2se_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ UHJhY3RpY2FsbHkgdmVyeSBsaXR0bGUgaWYgdGhlIGxhdGVzdCBXZWJmaW5nZXIgZHJhZnQgYWRk aXRpb24gYXJlIGFkb3B0ZWQgKGUuZy4gdGhlIHJlc291cmNlIGFuZCByZWwgcXVlcnkgc2hvcnRj dXRzIHdoaWNoIHdlcmUgb3JpZ2luYWxseSBwcm9wb3NlZCBpbiB0aGUNCiBmaXJzdCBPcGVuSUQg Q29ubmVjdCBwcm9wb3NhbCBieSBEYXZpZCBSZWNvcmRvbiBhbmQgbXlzZWxmKS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkVIPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG9hdXRoLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5NdXJyYXkgUy4gS3VjaGVyYXd5PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IEFwcmlsIDE3LCAyMDEyIDc6NTUgUE08YnI+DQo8Yj5Ubzo8L2I+IGFwcHMtZGlzY3Vzc0BpZXRm Lm9yZzxicj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmcgV0c8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtPQVVUSC1XR10gW2FwcHMtZGlzY3Vzc10gV2ViIEZpbmdlciB2cy4gU2ltcGxlIFdl YiBEaXNjb3ZlcnkgKFNXRCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28gdGhl cmUgYXJlIHNvbWUgb2YgYm90aC4mbmJzcDsgSG93IHRyZWFjaGVyb3VzIGlzIHRoZSBtaWdyYXRp b24gcGF0aCBmcm9tIFNXRCB0byBXZWJGaW5nZXIsIGZvciBleGFtcGxlLCBpbiBjYXNlIGNvbnNl bnN1cyBpcyB0byBkZXZlbG9wIGFuZCBtb3ZlIGZvcndhcmQgd2l0aA0KIHRoZSBsYXR0ZXI/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tTVNLPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ DQo8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmciPmFwcHMtZGlz Y3Vzcy1ib3VuY2VzQGlldGYub3JnPC9hPiA8YSBocmVmPSJtYWlsdG86W21haWx0bzphcHBzLWRp c2N1c3MtYm91bmNlc0BpZXRmLm9yZ10iPg0KW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0Bp ZXRmLm9yZ108L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA0OjI1IFBNPGJyPg0KPGI+VG86PC9iPiBCbGFp bmUgQ29vazsgVGltIEJyYXk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBp ZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+IFdHOyA8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNj dXNzQGlldGYub3JnIj4NCmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFthcHBzLWRpc2N1c3NdIFtPQVVUSC1XR10gV2ViIEZpbmdlciB2cy4gU2ltcGxl IFdlYiBEaXNjb3ZlcnkgKFNXRCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBr bm93IHRoYXQgNyBvZiB0aGUgOCBwdWJsaWMgcGFydGljaXBhbnRzIGluIHRoZSBjdXJyZW50IE9w ZW5JRCBDb25uZWN0IGludGVyb3AgdGVzdGluZyBoYXZlIGltcGxlbWVudGVkIFNXRCBhdCB0aGlz IHBvaW50LiZuYnNwOyAoSSBrbm93IG9mIHNldmVyYWwgbW9yZSB3aG/igJl2ZQ0KIGJ1aWx0IGl0 IGFzIHdlbGwgYnV0IGhhdmVu4oCZdCBjaG9zZW4gdG8gbWFrZSB0aGVpciBpbnRlcm9wIHRlc3Qg cmVzdWx0cyBwdWJsaWMgeWV0LikmbmJzcDsgVGhlcmUgYXJlIGxpa2VseSBvdGhlciBpbXBsZW1l bnRhdGlvbnMgSeKAmW0gdW5hd2FyZSBvZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8 YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CbGFpbmUgQ29vazxicj4NCjxi PlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiAzOjU0IFBNPGJyPg0KPGI+VG86PC9i PiBUaW0gQnJheTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn Ij5vYXV0aEBpZXRmLm9yZzwvYT4gV0c7IDxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0 Zi5vcmciPg0KYXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW09BVVRILVdHXSBbYXBwcy1kaXNjdXNzXSBXZWIgRmluZ2VyIHZzLiBTaW1wbGUgV2ViIERp c2NvdmVyeSAoU1dEKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+VGhhdCdzIGEgdHJpY2t5IHF1ZXN0aW9uIC0gbWF5 YmUgb25lIGdvb2dsZSBjYW4gaGVscCBhbnN3ZXI/IFRoZXJlIGFyZSBhIGJ1bmNoIG9mIHByb2pl Y3RzIHVzaW5nIHdlYmZpbmdlciwgaW5jbHVkaW5nDQo8YSBocmVmPSJodHRwOi8vc3RhdHVzLm5l dCI+c3RhdHVzLm5ldDwvYT4sIG9zdGF0dXMgaW4gZ2VuZXJhbCwgZGlhc3BvcmEsIHVuaG9zdGVk LCBmcmVlZG9tYm94KD8pLCBhbmQgSSdtIHN1cmUgb3RoZXJzLCBidXQgSSBoYXZlIG5vIGlkZWEg aG93IHRoYXQgdHJhbnNsYXRlcyBpbnRvIGFjdHVhbCB1c2VycyBvciBwcm9maWxlcy48bzpwPjwv bzpwPjwvcD4NCjxwPkdtYWlsLCBhb2wsIGFuZCB5YWhvbyBhbGwgcHV0IHVwIHdlYmZpbmdlciBl bmRwb2ludHMsIGJ1dCB0aGVyZSBoYXNuJ3QgYmVlbiBtdWNoIG1vdmVtZW50LCBJIHRoaW5rIGR1 ZSB0byB0aGUgY2hpY2tlbiBhbmQgZWdnIG5hdHVyZSBvZiBhZG9wdGlvbiBhcm91bmQgZGVjZW50 cmFsaXplZCB0b29scy48bzpwPjwvbzpwPjwvcD4NCjxwPmIuPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXByIDE3LCAyMDEyIDExOjEzIEFNLCAmcXVvdDtU aW0gQnJheSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRicmF5QHRleHR1YWxpdHkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+dGJyYXlAdGV4dHVhbGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgaXMgdGhlIGRlcGxveW1lbnQgc3Rh dHVzIG9mIHRoZXNlIHR3byBzcGVjcz8gJm5ic3A7SXMgZWl0aGVyIGRlcGxveWVkPGJyPg0KbXVj aCBhdCBhbGw/ICZuYnNwOy1UPGJyPg0KPGJyPg0KT24gRnJpLCBBcHIgMTMsIDIwMTIgYXQgMTA6 NDUgQU0sIE11cnJheSBTLiBLdWNoZXJhd3kgJmx0OzxhIGhyZWY9Im1haWx0bzptc2tAY2xvdWRt YXJrLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1za0BjbG91ZG1hcmsuY29tPC9hPiZndDsgd3JvdGU6 PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyBG cm9tOiA8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5hcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBo cmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5hcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBTdGVwaGVu IEZhcnJlbGw8YnI+DQomZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEFwcmlsIDEzLCAyMDEyIDk6MjMg QU08YnI+DQomZ3Q7Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+IFdHPGJyPg0KJmd0OyZndDsgQ2M6IEFwcHMg RGlzY3Vzczxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBbT0FVVEgt V0ddIFdlYiBGaW5nZXIgdnMuIFNpbXBsZSBXZWIgRGlzY292ZXJ5IChTV0QpPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBTbyBIYW5uZXMgYW5kIERlcmVrIGFuZCBJIGhhdmUgYmVlbiBkaXNj dXNzaW5nIHRoaXMgd2l0aCB0aGUgQXBwcyBBRHM8YnI+DQomZ3Q7Jmd0OyBhbmQgQXBwcy1hcmVh IFdHIGNoYWlycy4gSSd2ZSBhbHNvIHJlYWQgdGhlIGRvY3Mgbm93LCBhbmQgYWZ0ZXIgYWxsPGJy Pg0KJmd0OyZndDsgdGhhdCB3ZSd2ZSBkZWNpZGVkIHRoYXQgdGhpcyB0b3BpYyAod2hhdCB0byBk byB3aXRoIHN3ZCBhbmQgd2ViZmluZ2VyKTxicj4NCiZndDsmZ3Q7IGlzIGJlc3QgaGFuZGxlZCBp biB0aGUgYXBwcyBhcmVhIGFuZCBub3QgaW4gdGhlIG9hdXRoIFdHLjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgVGhlIGxvZ2ljIGZvciB0aGF0IGlzIHRoYXQgMSkgdGhlIHR3byBwcm9wb3Nh bHMgYXJlIGRvaW5nIHRoZSBzYW1lPGJyPg0KJmd0OyZndDsgdGhpbmcgYW5kIHdlIGRvbid0IHdh bnQgdHdvIGRpZmZlcmVudCBzdGFuZGFyZHMgZm9yIHRoYXQsIGIpIHRoaXMgaXM8YnI+DQomZ3Q7 Jmd0OyBub3QgYW4gb2F1dGgtc3BlY2lmaWMgdGhpbmcgbm9yIGlzIGl0IGEgZ2VuZXJhbCBzZWN1 cml0eSB0aGluZywgYW5kIGMpPGJyPg0KJmd0OyZndDsgdGhlcmUgaXMgY2xlYXJseSBhbHJlYWR5 IGludGVyZXN0IGluIHRoZSB0b3BpYyBpbiB0aGUgYXBwcyBhcmVhIHNvIGl0czxicj4NCiZndDsm Z3Q7IHJlYXNvbmFibGUgZm9yIHRoZSBvYXV0aCB3ZyB0byB1c2UgdGhhdCB3aGVuIGl0cyByZWFk eS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBhcHBzYXdnIGNoYWlycyBhbmQgYXBw cyBBRHMgYXJlIG9rIHdpdGggdGhlIHdvcmsgYmVpbmcgZG9uZSB0aGVyZS48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IFNvOi08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0gSSd2ZSBh c2tlZCB0aGUgb2F1dGggY2hhaXJzIHRvIHRha2UgZG9pbmcgd29yayBvbiBzd2Q8YnI+DQomZ3Q7 Jmd0OyAmbmJzcDsgb3V0IG9mIHRoZSBwcm9wb3NlZCBuZXcgY2hhcnRlcjxicj4NCiZndDsmZ3Q7 IC0gSXQgbWF5IGJlIHRoYXQgeW91IHdhbnQgdG8gYWRkIHNvbWV0aGluZyBzYXlpbmcgdGhhdDxi cj4NCiZndDsmZ3Q7ICZuYnNwOyBvYXV0aCB3aWxsIHVzZSB0aGUgcmVzdWx0cyBvZiB3b3JrIGlu IHRoZSBhcHBsaWNhdGlvbnM8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgYXJlYSBvbiBhIHdlYiBkaXNj b3ZlcnkgcHJvdG9jb2wgYXMgYSBiYXNpcyBmb3IgZG9pbmc8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsg dGhlIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiB3b3JrIGhlcmU8YnI+DQomZ3Q7Jmd0OyAt IERpc2N1c3Npb24gb2Ygd2ViZmluZ2VyIGFuZCBzd2Qgc2hvdWxkIG1vdmUgb3ZlciB0bzxicj4N CiZndDsmZ3Q7ICZuYnNwOyB0aGUgYXBwcy1kaXNjdXNzIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAtIE5v dGU6IHRoaXMgaXMgbm90IHBpY2tpbmcgb25lIG9yIHRoZSBvdGhlciBhcHByb2FjaCw8YnI+DQom Z3Q7Jmd0OyAmbmJzcDsgdGhlIHBsYW4gaXMgdGhhdCB0aGUgYXBwcyBhcmVhIHdpbGwgZG8gYW55 IHNlbGVjdGlvbjxicj4NCiZndDsmZ3Q7ICZuYnNwOyBuZWVkZWQgYW5kIGZpZ3VyZSBvdXQgdGhl IGJlc3Qgc3RhcnRpbmcgcG9pbnQgZm9yIGE8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgc3RhbmRhcmRz LXRyYWNrIFJGQyBvbiB3ZWIgZGlzY292ZXJ5IGFuZCB3ZSdsbCB1c2UgdGhlaXI8YnI+DQomZ3Q7 Jmd0OyAmbmJzcDsgZmluZSB3b3JrIGZvciBkb2luZyBtb3JlIHdpdGggb2F1dGguPGJyPg0KJmd0 Ozxicj4NCiZndDsgVGhhbmsgeW91IFN0ZXBoZW4sIEkgdGhpbmsuICZuYnNwOzotKTxicj4NCiZn dDs8YnI+DQomZ3Q7IFNvIHRoZSBkaXNjdXNzaW9uIG9uIGFwcHMtZGlzY3VzcyBub3cgc2hvdWxk IGJlIGZvY3VzZWQgb24gd2hpY2ggb2YgdGhlIHR3byBzaG91bGQgYmUgdGhlIGJhc2lzIGZvciBm b3J3YXJkIHByb2dyZXNzLiAmbmJzcDtJJ3ZlIHBsYWNlZCBib3RoIGRvY3VtZW50cyBpbiAmcXVv dDtDYWxsIGZvciBBZG9wdGlvbiZxdW90OyBzdGF0ZSBpbiB0aGUgZGF0YXRyYWNrZXIgZm9yIGFw cHNhd2cuPGJyPg0KJmd0Ozxicj4NCiZndDsgTGV0IHRoZSBnYW1lcyBiZWdpbi48YnI+DQomZ3Q7 PGJyPg0KJmd0OyAtTVNLPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsgYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdDxicj4N CiZndDsgPGEgaHJlZj0ibWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3M8L2E+ PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3A5P3PWEX2MB008ex2se_-- From stpeter@stpeter.im Tue Apr 17 20:25: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 5A95511E8076 for ; Tue, 17 Apr 2012 20:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYieSIKx-bbN for ; Tue, 17 Apr 2012 20:24:53 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CAA9311E8075 for ; Tue, 17 Apr 2012 20:24:53 -0700 (PDT) Received: from [192.168.0.3] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3BB4D40058; Tue, 17 Apr 2012 21:39:05 -0600 (MDT) Message-ID: <4F8E3404.5000708@stpeter.im> Date: Tue, 17 Apr 2012 21:24:52 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Eran Hammer References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B16804296739436648BF09@TK5EX14MBXC284.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E0039280F707F@exch-mbx901.corp.cloudmark.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3A5@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3A5@P3PWEX2MB008.ex2.secureserver.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 03:25:05 -0000 Right, at that point the differences appear to be mostly about syntax, not semantics. On 4/17/12 9:23 PM, Eran Hammer wrote: > Practically very little if the latest Webfinger draft addition are > adopted (e.g. the resource and rel query shortcuts which were originally > proposed in the first OpenID Connect proposal by David Recordon and myself). > > > > EH > > > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Murray S. Kucherawy > *Sent:* Tuesday, April 17, 2012 7:55 PM > *To:* apps-discuss@ietf.org > *Cc:* oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web > Discovery (SWD) > > > > So there are some of both. How treacherous is the migration path from > SWD to WebFinger, for example, in case consensus is to develop and move > forward with the latter? > > > > -MSK > > > > *From:*apps-discuss-bounces@ietf.org > > [mailto:apps-discuss-bounces@ietf.org] > *On Behalf Of *Mike Jones > *Sent:* Tuesday, April 17, 2012 4:25 PM > *To:* Blaine Cook; Tim Bray > *Cc:* oauth@ietf.org WG; apps-discuss@ietf.org > > *Subject:* Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > Discovery (SWD) > > > > I know that 7 of the 8 public participants in the current OpenID Connect > interop testing have implemented SWD at this point. (I know of several > more who’ve built it as well but haven’t chosen to make their interop > test results public yet.) There are likely other implementations I’m > unaware of. > > > > -- Mike > > > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] *On Behalf Of *Blaine Cook > *Sent:* Tuesday, April 17, 2012 3:54 PM > *To:* Tim Bray > *Cc:* oauth@ietf.org WG; apps-discuss@ietf.org > > *Subject:* Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web > Discovery (SWD) > > > > That's a tricky question - maybe one google can help answer? There are a > bunch of projects using webfinger, including status.net > , ostatus in general, diaspora, unhosted, > freedombox(?), and I'm sure others, but I have no idea how that > translates into actual users or profiles. > > Gmail, aol, and yahoo all put up webfinger endpoints, but there hasn't > been much movement, I think due to the chicken and egg nature of > adoption around decentralized tools. > > b. > > On Apr 17, 2012 11:13 AM, "Tim Bray" > wrote: > > What is the deployment status of these two specs? Is either deployed > much at all? -T > > On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy > wrote: >>> -----Original Message----- >>> From: apps-discuss-bounces@ietf.org > > [mailto:apps-discuss-bounces@ietf.org > ] On Behalf Of Stephen Farrell >>> Sent: Friday, April 13, 2012 9:23 AM >>> To: oauth@ietf.org WG >>> Cc: Apps Discuss >>> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > Discovery (SWD) >>> >>> So Hannes and Derek and I have been discussing this with the Apps ADs >>> and Apps-area WG chairs. I've also read the docs now, and after all >>> that we've decided that this topic (what to do with swd and webfinger) >>> is best handled in the apps area and not in the oauth WG. >>> >>> The logic for that is that 1) the two proposals are doing the same >>> thing and we don't want two different standards for that, b) this is >>> not an oauth-specific thing nor is it a general security thing, and c) >>> there is clearly already interest in the topic in the apps area so its >>> reasonable for the oauth wg to use that when its ready. >>> >>> The appsawg chairs and apps ADs are ok with the work being done there. >>> >>> So:- >>> >>> - I've asked the oauth chairs to take doing work on swd >>> out of the proposed new charter >>> - It may be that you want to add something saying that >>> oauth will use the results of work in the applications >>> area on a web discovery protocol as a basis for doing >>> the dynamic client registration work here >>> - Discussion of webfinger and swd should move over to >>> the apps-discuss list >>> - Note: this is not picking one or the other approach, >>> the plan is that the apps area will do any selection >>> needed and figure out the best starting point for a >>> standards-track RFC on web discovery and we'll use their >>> fine work for doing more with oauth. >> >> Thank you Stephen, I think. :-) >> >> So the discussion on apps-discuss now should be focused on which of > the two should be the basis for forward progress. I've placed both > documents in "Call for Adoption" state in the datatracker for appsawg. >> >> Let the games begin. >> >> -MSK >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss From eran@hueniverse.com Tue Apr 17 20:28: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 45CA111E80D7 for ; Tue, 17 Apr 2012 20:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYE4uF3b7yJO for ; Tue, 17 Apr 2012 20:28:44 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id E24BC11E80D3 for ; Tue, 17 Apr 2012 20:28:43 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id zFUj1i0010Dcg9U01FUjdW; Tue, 17 Apr 2012 20:28:43 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Tue, 17 Apr 2012 20:28:43 -0700 From: Eran Hammer To: Dick Hardt Thread-Topic: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer Thread-Index: AQHNHLofIuyx/camh0qzKFNvw3YPcpafZDIAgAB5GYCAAA6pQA== Date: Wed, 18 Apr 2012 03:28:43 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3DF@P3PWEX2MB008.ex2.secureserver.net> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0@P3PWEX2MB008.ex2.secureserver.net> <5837DDA7-19DC-4452-BD47-FFF6C674E179@gmail.com> In-Reply-To: <5837DDA7-19DC-4452-BD47-FFF6C674E179@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3DFP3PWEX2MB008ex2se_" MIME-Version: 1.0 Cc: Ned Freed , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss , Mark Nottingham , Pete Resnick Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 03:28:46 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3DFP3PWEX2MB008ex2se_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A site has a bunch of APIs. They want to use OAuth with Bearer tokens. They= can no longer use the access_token parameter for their own use cases becau= se the Bearer token specification creates a conflict. This conflict does no= t exist with the use of the header. It does exist with the use of the body = if they have an access_token parameter already in use. The API format has nothing to do with OAuth, but the use of a query paramet= er leaks into that namespace. This isn't a critical issue. It is a hack - it has always been since it was= introduced in OAuth 1.0. The issue raised was about web architecture in ge= neral and setting a precedence. I don't think it will likely to create real= -world problems, but the same goes for not supporting this use case anymore= (or at least explicitly marking it as deprecated, maybe even demoted to an= appendix documenting historical use). While the violation of the provider namespace is a significant principal, I= want to make sure my view isn't coming off as some severe warning. Either = way, it is not a big deal IMO. EH From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, April 17, 2012 12:32 PM To: Eran Hammer Cc: Dick Hardt; Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; = draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oaut= h-v2-bearer Please elaborate on what the issue is then as protecting API resources is w= hat OAuth is all about. On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote: That has nothing to do with this issue. The protected resources API format = was never part of OAuth at any time. EH From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, April 17, 2012 9:50 AM To: Eran Hammer Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; draft-ietf-o= auth-v2-bearer.all@tools.ietf.org; Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oaut= h-v2-bearer On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote: (Sticking with the naivety:-) So, what's different there from how the base oauth draft registers client_id and shows how that can be used in a GET request? [1] Big difference. The base draft specifies its own endpoints as part of a com= plete API package for obtaining authorization. These parameters are scoped = only for the endpoints defined and not for any others. There is no possibil= ity of conflict because the specification defines the entire namespace. OTOH, the bearer spec is applied to *any* web resources using OAuth authent= ication where some other namespace definition must exist. If we had kept it all in one spec as it had originally been drafted, this w= ould not be an issue, and it would be easier for implementers to understand= . I don't know of anyone looking to implement the bearer spec independent o= f the base spec. (would be interested if anyone does know of an implementat= ion) --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3DFP3PWEX2MB008ex2se_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A site has a bunch of API= s. They want to use OAuth with Bearer tokens. They can no longer use the ac= cess_token parameter for their own use cases because the Bearer token specification creates a conflict. This conflict does not exis= t with the use of the header. It does exist with the use of the body if the= y have an access_token parameter already in use.

 <= /p>

The API format has nothin= g to do with OAuth, but the use of a query parameter leaks into that namesp= ace.

 <= /p>

This isn’t a critic= al issue. It is a hack – it has always been since it was introduced i= n OAuth 1.0. The issue raised was about web architecture in general and setting a precedence. I don’t think it will likely to create rea= l-world problems, but the same goes for not supporting this use case anymor= e (or at least explicitly marking it as deprecated, maybe even demoted to a= n appendix documenting historical use).

 <= /p>

While the violation of th= e provider namespace is a significant principal, I want to make sure my vie= w isn’t coming off as some severe warning. Either way, it is not a big deal IMO.

 <= /p>

EH

 <= /p>

From: Dick Har= dt [mailto:dick.hardt@gmail.com]
Sent: Tuesday, April 17, 2012 12:32 PM
To: Eran Hammer
Cc: Dick Hardt; Stephen Farrell; Mark Nottingham; Pete Resnick; Ned = Freed; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss
Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ie= tf-oauth-v2-bearer

 

Please elaborate on what the issue is then as protec= ting API resources is what OAuth is all about. 

 

On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote:



That has nothing to do wi= th this issue. The protected resources API format was never part of OAuth a= t any time.

 <= /p>

EH

 <= /p>

From: Dick Hardt [mailto:dick.hardt@= gmail.com] 
Sent: Tuesday, Apr= il 17, 2012 9:50 AM
To: Eran Hammer Cc: Stephen Farrel= l; Mark Nottingham; Pete Resnick; Ned Freed; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss
Subject: Re: [apps= -discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer=

 

 

On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote:




(Sticking with the naivety:-) So, wha= t's different there from how the base

oauth draft registers client_id and s= hows how that can be used in a GET

request? [1]


Big difference. The base draft specifies its own endpoints as part of a com= plete API package for obtaining authorization. These parameters are scoped = only for the endpoints defined and not for any others. There is no possibil= ity of conflict because the specification defines the entire namespace.

OTOH, the bearer spec is applied to *any* web resources using OAuth authent= ication where some other namespace definition must exist.=

 

 

If we had kept it all in one spec as it had original= ly been drafted, this would not be an issue, and it would be easier for imp= lementers to understand. I don't know of anyone looking to implement the be= arer spec independent of the base spec. (would be interested if anyone does know of an implementation)<= /o:p>

 

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3DFP3PWEX2MB008ex2se_-- From nico@cryptonector.com Tue Apr 17 20: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 7FAD811E8091; Tue, 17 Apr 2012 20:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReNGNWcECqkU; Tue, 17 Apr 2012 20:33:41 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 77D5911E8093; Tue, 17 Apr 2012 20:33:41 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 2F98E94064; Tue, 17 Apr 2012 20:33:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=euxu8Hl/G6kublP4HVVL1kFQOQaAVKOkLRWlIDSkhgHC 36YpPvLhpfSQ7XbtzW9MJ9IXcy7wDPf4n2pAzlb5XQtwuhVkzZl1ZekbsUBgd4iE rZcZFymjxhjY3Q8VlCU4JoKx2KS0U1i4rAjCKO+9lNNlbQZ9hh90kB+ci4TXmkY= 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:content-transfer-encoding; s= cryptonector.com; bh=SQa251e+w4iC4Jybi3EVBfN3hrU=; b=DTLCBaqlw8r U3tWP7ckQ19K0Yttt8oGWM+7QYcMhx/5eKhQfHumpsI/ZRC5y4W/6IJO7OoGmKNJ U3zdxdVggpM6fjWB0wrrzwx4aSFkc9kOioUO+Rj5qgUHnHVd3koWfVCPQTeRJuMM M+/MA/KU4VgdkCDqU2TUbpJqh9Z+ZLfs= 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-a77.g.dreamhost.com (Postfix) with ESMTPSA id 0DE4E9405E; Tue, 17 Apr 2012 20:33:41 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so6344132pbb.31 for ; Tue, 17 Apr 2012 20:33:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.232 with SMTP id ih8mr2593107pbc.118.1334720020597; Tue, 17 Apr 2012 20:33:40 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Tue, 17 Apr 2012 20:33:40 -0700 (PDT) In-Reply-To: <1334712238.64475.YahooMailNeo@web31804.mail.mud.yahoo.com> References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> <1334695329.43020.YahooMailNeo@web31812.mail.mud.yahoo.com> <1334712238.64475.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Tue, 17 Apr 2012 22:33:40 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Sam Hartman , "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 03:33:45 -0000 On Tue, Apr 17, 2012 at 8:23 PM, William Mills wrote= : > OK, if this is covered by the mechanisms (which is something a GSS expert > probably knows but I did not) then I'm less worried.=C2=A0 Is it then wor= thwhile > to add "Systems must know how to interpret critical mechanism attributes, > but this is already required by mechanism specifications." in the section > we're talking about to make it explicit rather than implicit? Yes. I like the conciseness of the text you propose. The I had in mind was something like this: The manner in which name attributes are conveyed by GSS mechanisms is mechanism-specific. If a GSS mechanism provides a way to indicate criticality then local policy MAY require that any given GSS name attribute be expressed using critical elements of the mechanism. However, criticality is not exposed in this API because criticality is intended to be handled by local policy and the mechanisms. This means that a system that lacks local policy by which to deal with critical mechanism elements conveying name attributes should fail security context establishment when such critical elements are used by the peer. That's quite a mouthful, so I tend to prefer your text. Nico -- From tobias.gondrom@gondrom.org Tue Apr 17 20:40: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 7780221F84CD for ; Tue, 17 Apr 2012 20:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.777 X-Spam-Level: X-Spam-Status: No, score=-96.777 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-O7rxWmY0yk for ; Tue, 17 Apr 2012 20:39:59 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id B4E8911E8076 for ; Tue, 17 Apr 2012 20:39:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=BZG7HHqHaCc2Kb4d5X9Febcsd/MvA+j7AuP/SwlnxylkGPaSyvaJWcQD0nKnQO8HKXA1o067glwgLdJo2lFf7z5rU5IUJHJdCe1oL03nsFRYybmaqIyNQgvS3Bi7b8dI; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type; Received: (qmail 13416 invoked from network); 18 Apr 2012 05:39:46 +0200 Received: from n2028211917.imsbiz.com (HELO ?10.65.1.159?) (202.82.119.17) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Apr 2012 05:39:46 +0200 Message-ID: <4F8E377D.2010601@gondrom.org> Date: Wed, 18 Apr 2012 11:39:41 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org, draft-ietf-krb-wg-des-die-die-die.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------010108090005000106040702" Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-krb-wg-des-die-die-die-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, 18 Apr 2012 03:40:03 -0000 This is a multi-part message in MIME format. --------------010108090005000106040702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-krb-wg-des-die-die-die-04 Title: Deprecate DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos Reviewer: Tobias Gondrom Review Date: April-17 Summary: The document is ok for publication. Major Comment: Agree that we should/must deprecate the weak cryptographic algorithms in Kerberos. However IMHO, I do not agree with the reasoning "to not actively discourage the use of RC4-HMAC" in section 7. I understand that interoperability is of major importance, but at some point a very weak algorithm will give users a false sense of security while exposing them to malicious attacks. And keeping RC4-HMAC supported does also expose the majority of the community (who is not using the deprecated Windows Versions) at possible risks to downgrade attacks. I believe even though the support of the complete Internet community is vital for standards, the support of deprecated (and AFAIK no longer supported OS versions) should not be the deciding argument behind our decisions here. Even old OS can be patched or fixed by the vendor or other service providers and it should not justify to keep a weak algorithm. Best regards, Tobias --------------010108090005000106040702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-krb-wg-des-die-die-die-04
Title: Deprecate DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos
Reviewer: Tobias Gondrom
Review Date: April-17

Summary: The document is ok for publication.

Major Comment:
Agree that we should/must deprecate the weak cryptographic algorithms in Kerberos.
However IMHO, I do not agree with the reasoning "to not actively discourage the use of RC4-HMAC" in section 7.
I understand that interoperability is of major importance, but at some point a very weak algorithm will give users a false sense of security while exposing them to malicious attacks. And keeping RC4-HMAC supported does also expose the majority of the community (who is not using the deprecated Windows Versions) at possible risks to downgrade attacks.

I believe even though the support of the complete Internet community is vital for standards, the support of deprecated (and AFAIK no longer supported OS versions) should not be the deciding argument behind our decisions here. Even old OS can be patched or fixed by the vendor or other service providers and it should not justify to keep a weak algorithm.

Best regards, Tobias


 --------------010108090005000106040702-- From wmills@yahoo-inc.com Tue Apr 17 21:19: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 1047611E8087 for ; Tue, 17 Apr 2012 21:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.255 X-Spam-Level: X-Spam-Status: No, score=-17.255 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDN6E7ylFxw5 for ; Tue, 17 Apr 2012 21:19:54 -0700 (PDT) Received: from nm36-vm5.bullet.mail.bf1.yahoo.com (nm36-vm5.bullet.mail.bf1.yahoo.com [72.30.238.141]) by ietfa.amsl.com (Postfix) with SMTP id 389F611E8083 for ; Tue, 17 Apr 2012 21:19:46 -0700 (PDT) Received: from [98.139.214.32] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 18 Apr 2012 04:19:45 -0000 Received: from [98.139.212.208] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 18 Apr 2012 04:19:45 -0000 Received: from [127.0.0.1] by omp1017.mail.bf1.yahoo.com with NNFMP; 18 Apr 2012 04:19:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 451118.43343.bm@omp1017.mail.bf1.yahoo.com Received: (qmail 78452 invoked by uid 60001); 18 Apr 2012 04:19:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334722784; bh=Y55phEdNMNhoTApEYrWH729OFDSsr8HMwh3pjvuYNJA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HIbI8+ONNhOBkM0OwITCjNL6t0x7Bfg0o0GUUHUmjKu/z548OlpApxAbL9qr6ynPkPjt7IEtyYQlZ0KCq63KZRh/e1LZfmUHkWc/caipG9FsP9mSItwfpefSopecEuJmEUjcltTKTYzrImimfWZmwMGfP1vn+wja78e4RrJgd/4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=d4OhPPBr2j5CxFOHgh8lkoFa+hon6WdBUnBiDEtP/v/dfF38ig/D5/WU69U6hjXu4Iak+KS2KfRfNIGOlo5rldd/V/BNbJD2NjPYVdVxPs8mO/KoOjgiL82OVx3m5D1N4ELXlqudSLDrHRFvw9lkEz2WrQvQxvkszv0GiY4B5YM=; X-YMail-OSG: WxYPFP0VM1kjSqA6VahiHkubVVtmJ27XcP5YL07uXrfi4Jz gKCixt0lcv1ef9R_wy8JkazI5Fgz3jKNJp_oW2k8Alr5Ysr_oSml7ti4FYld aU5LprG8PdmORD6V2w4hrHyBfZ5iPiv1Fyu0PT2vA4EUB5vyVGCjlNCk_Ewc kW1.cBgJDtjAH4rVI67THaoUiTgnRJ_vGy5LQuZbTQFYZubI16RACK3aZt5v EW8DrklTXFOrhpFZaHaKO8TjR5YI6AbSAIXtN3V9JGjz4XiyBkR0zjTNNi02 nzAnSM0wC3Mf_0gNVTieSBieMqCb2ZnQ.1S00jKznh3lCE.m2w3YbypVsdGm 502ru2nD7ndmlEtYng6JTHcMqZ6vcMFh7wK778wDSryl42it3fpBJO5_2yzM yjYVewhOh6UsCBusDqUNPbmoXn5cyWj3.Udx_V72R.MkaG4NanEPs Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Tue, 17 Apr 2012 21:19:44 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> <1334695329.43020.YahooMailNeo@web31812.mail.mud.yahoo.com> <1334712238.64475.YahooMailNeo@web31804.mail.mud.yahoo.com> Message-ID: <1334722784.40057.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 17 Apr 2012 21:19:44 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-1472088225-1334722784=:40057" Cc: Sam Hartman , "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 04:19:58 -0000 --258328648-1472088225-1334722784=:40057 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Now see, now I feel obligated to point out I was quoting you, I just capita= lized the S at the front.=0A=0A=0A=0A=0A>________________________________= =0A> From: Nico Williams =0A>To: William Mills =0A>Cc: Sam Hartman ; "draft-ietf-= kitten-gssapi-naming-exts.all@tools.ietf.org" ; "apps-discuss@ietf.org" ; The IESG =0A>Sent: Tuesday, April 17, 2012 8:33 PM=0A>S= ubject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-g= ssapi-naming-exts-14=0A> =0A>On Tue, Apr 17, 2012 at 8:23 PM, William Mills= wrote:=0A>> OK, if this is covered by the mechanism= s (which is something a GSS expert=0A>> probably knows but I did not) then = I'm less worried.=A0 Is it then worthwhile=0A>> to add "Systems must know h= ow to interpret critical mechanism attributes,=0A>> but this is already req= uired by mechanism specifications." in the section=0A>> we're talking about= to make it explicit rather than implicit?=0A>=0A>Yes.=A0 I like the concis= eness of the text you propose.=A0 The I had in=0A>mind was something like t= his:=0A>=0A>=A0 The manner in which name attributes are conveyed by GSS=0A= >=A0 mechanisms is mechanism-specific.=A0 If a GSS mechanism=0A>=A0 provi= des a way to indicate criticality then local policy MAY=0A>=A0 require tha= t any given GSS name attribute be expressed using=0A>=A0 critical elements= of the mechanism.=A0 However, criticality is not=0A>=A0 exposed in this A= PI because criticality is intended to be handled=0A>=A0 by local policy an= d the mechanisms.=A0 This means that a system=0A>=A0 that lacks local poli= cy by which to deal with critical mechanism=0A>=A0 elements conveying name= attributes should fail security context=0A>=A0 establishment when such cr= itical elements are used by the=0A>=A0 peer.=0A>=0A>That's quite a mouthfu= l, so I tend to prefer your text.=0A>=0A>Nico=0A>--=0A>=0A>=0A> --258328648-1472088225-1334722784=:40057 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Now see, now I feel obligated to point out I was quoting you, I just capi= talized the S at the front.

=
From: Nico Williams <nico@cryptonector.com> To: William Mills <w= mills@yahoo-inc.com>
Cc: Sam Hartman <hartmans-ietf@mit.edu>; "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" <draft-ietf-k= itten-gssapi-naming-exts.all@tools.ietf.org>; "apps-discuss@ietf.org" &l= t;apps-discuss@ietf.org>; The IESG <iesg@ietf.org>
Sent: Tuesday, April 17, 2012 8:33 P= M
Subject: Re: [apps-d= iscuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-1= 4

=0AOn Tue, Apr 17, 2012 at 8:23 PM, William Mills = <wmills@yahoo-inc.com> wrote:
> OK, if this is covered= by the mechanisms (which is something a GSS expert
> probably knows = but I did not) then I'm less worried.  Is it then worthwhile
> t= o add "Systems must know how to interpret critical mechanism attributes,> but this is already required by mechanism specifications." in the sec= tion
> we're talking about to make it explicit rather than implicit?<= br>
Yes.  I like the conciseness of the text you propose.  The= I had in
mind was something like this:

  The manner in whi= ch name attributes are conveyed by GSS
  mechanisms is mechanism-s= pecific.  If a GSS mechanism
  provides a way to indicate cri= ticality then local policy MAY
  require that any given GSS name a= ttribute be expressed using
  critical elements of the mechanism.  However, critic= ality is not
  exposed in this API because criticality is intended= to be handled
  by local policy and the mechanisms.  This me= ans that a system
  that lacks local policy by which to deal with = critical mechanism
  elements conveying name attributes should fai= l security context
  establishment when such critical elements are= used by the
  peer.

That's quite a mouthful, so I tend to = prefer your text.

Nico
--


=
--258328648-1472088225-1334722784=:40057-- From nico@cryptonector.com Tue Apr 17 21:21: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 DB1B811E8083; Tue, 17 Apr 2012 21:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxHrweuBObzt; Tue, 17 Apr 2012 21:21:49 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id EB5A111E8076; Tue, 17 Apr 2012 21:21:48 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id AC5542F4059; Tue, 17 Apr 2012 21:21:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=NuX8loOVBs+Mj8uDhLH2G pB5B+NEGwO2chq08tyw1NcPHXTF2gLiVNLJh67gssV9/FOlFU6mqPbt40QKWd+JJ JJvRxoafTRaPGptmfoTFR1LIfklxEgOoi3MwxbbiO408HoAuPGMSdMZqhDbSxRBc COVYHFWuTPk4ySLoerXXJ8= 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=sl4anCQjPW/8Rpp0lTvq +R92zfU=; b=goJg+S6S9HZJtx2OpS+9npHVRRsvK+c7J0BQD1ICfx6u7AX0AsEt WfqKA2T8yQWShsOR+J5qzkjozbeOUGQEqt8ojNCU2sQHyK188SBVog0JXQqs3nyA TXZcc6IyohMLZgw2ds9jHxGmo+mlUgzwHQX36YkK3flfRoTVfnse69k= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 8A9582F4057; Tue, 17 Apr 2012 21:21:48 -0700 (PDT) Received: by dady13 with SMTP id y13so12791054dad.27 for ; Tue, 17 Apr 2012 21:21:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.219.200 with SMTP id pq8mr3017243pbc.55.1334722908228; Tue, 17 Apr 2012 21:21:48 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Tue, 17 Apr 2012 21:21:48 -0700 (PDT) In-Reply-To: <1334722784.40057.YahooMailNeo@web31808.mail.mud.yahoo.com> References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> <1334695329.43020.YahooMailNeo@web31812.mail.mud.yahoo.com> <1334712238.64475.YahooMailNeo@web31804.mail.mud.yahoo.com> <1334722784.40057.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 17 Apr 2012 23:21:48 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: Sam Hartman , "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 04:21:57 -0000 On Tue, Apr 17, 2012 at 11:19 PM, William Mills wrote: > Now see, now I feel obligated to point out I was quoting you, I just > capitalized the S at the front. Oh, heh. Well, that shows how much attention I was paying! From derhoermi@gmx.net Tue Apr 17 21: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 D892321F8546 for ; Tue, 17 Apr 2012 21:47:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDc-G6biuBJR for ; Tue, 17 Apr 2012 21:47:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 49F1D21F8526 for ; Tue, 17 Apr 2012 21:47:13 -0700 (PDT) Received: (qmail invoked by alias); 18 Apr 2012 04:47:12 -0000 Received: from dslb-094-222-144-125.pools.arcor-ip.net (EHLO HIVE) [94.222.144.125] by mail.gmx.net (mp020) with SMTP; 18 Apr 2012 06:47:12 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18L9eISb1MLNfeTpbv7RrbfepSkM4yT42X1Tn7ZZV 9Uku8m0btP+LRv From: Bjoern Hoehrmann To: Ned Freed Date: Wed, 18 Apr 2012 06:47:24 +0200 Message-ID: References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <3kjpo79jo1mvg2dtqf19hl5i3lrrfm5eb5@hive.bjoern.hoehrmann.de> <01OEEJU1A7HY00ZUIL@mauve.mrochek.com> In-Reply-To: <01OEEJU1A7HY00ZUIL@mauve.mrochek.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org, "www-tag@w3.org List" , Jeni Tennison Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 04:47:21 -0000 * Ned Freed wrote: >> This also does not seem to >> address a problem that we actually have, people do not register types >> with very similar yet different "fragment identifier schemes", and if >> they did so, that would very likely be for good reasons. > >Actually, if the Wikipedia page on these things can be believed, they do. For >example, different fragment id syntaxes for "page N" with what appear to be >idential semantics seem to exist. Yeah, but if you use #page=13 versus #page(13) or some other variation is likely for good reasons, like, you want to use some meta-mechanism like XPointer that allows one but not the other. Would be nice to have some proper statistics. >Based on this feedback, I now have (I'm leaving the XML in this time): > > >Media type registrations can specify how applications should interpret >fragment identifiers associated with the media type. > > > >Media types are encouraged to adopt fragment identifier schemes that are used >with semantically similar media types. In particular, media types that use a >named structured syntax with a registered "+suffix" MUST follow whatever >fragment identifier rules are given in the structured syntax suffix >registration. > This seems reasonable to me, though it would seem better to turn that into a general "+suffix types must follow +suffix rules, whatever they are" requirement. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ned.freed@mrochek.com Tue Apr 17 21:58: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 3F6A821F85A3 for ; Tue, 17 Apr 2012 21:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxlFbFupqfKV for ; Tue, 17 Apr 2012 21:58:19 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C20D621F8584 for ; Tue, 17 Apr 2012 21:58:18 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEFVDX1PHS008YT5@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 17 Apr 2012 21:58:02 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEF9D6O0Q8012404@mauve.mrochek.com>; Tue, 17 Apr 2012 21:57:59 -0700 (PDT) Message-id: <01OEFVDVDRQ8012404@mauve.mrochek.com> Date: Tue, 17 Apr 2012 21:48:44 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 18 Apr 2012 06:47:24 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1 References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <3kjpo79jo1mvg2dtqf19hl5i3lrrfm5eb5@hive.bjoern.hoehrmann.de> <01OEEJU1A7HY00ZUIL@mauve.mrochek.com> To: Bjoern Hoehrmann Cc: apps-discuss@ietf.org, Ned Freed , "www-tag@w3.org List" , Jeni Tennison Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 04:58:20 -0000 > * Ned Freed wrote: > >> This also does not seem to > >> address a problem that we actually have, people do not register types > >> with very similar yet different "fragment identifier schemes", and if > >> they did so, that would very likely be for good reasons. > > > >Actually, if the Wikipedia page on these things can be believed, they do. For > >example, different fragment id syntaxes for "page N" with what appear to be > >idential semantics seem to exist. > Yeah, but if you use #page=13 versus #page(13) or some other variation > is likely for good reasons, like, you want to use some meta-mechanism > like XPointer that allows one but not the other. Would be nice to have > some proper statistics. ... maybe. Having seen so many examples in other places of disrepancies that turned out to be completely superfluous, I'm skeptical. > >Based on this feedback, I now have (I'm leaving the XML in this time): > > > > > >Media type registrations can specify how applications should interpret > >fragment identifiers associated with the media type. > > > > > > > >Media types are encouraged to adopt fragment identifier schemes that are used > >with semantically similar media types. In particular, media types that use a > >named structured syntax with a registered "+suffix" MUST follow whatever > >fragment identifier rules are given in the structured syntax suffix > >registration. > > > This seems reasonable to me, though it would seem better to turn that > into a general "+suffix types must follow +suffix rules, whatever they > are" requirement. Even if we were to insert such a general requirement, I think this one is so important it bears repeating. Especially since it indirectly places limits on what you really want to allow in a fragment identifier description in your suffix registration. If you make this material too restrictive, the result will be that the suffix won't be usable, and I think that's a good thing. Ned From ned.freed@mrochek.com Tue Apr 17 22:05: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 BF63721F85AD for ; Tue, 17 Apr 2012 22:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M510E6CYRz7s for ; Tue, 17 Apr 2012 22:05:07 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6240621F85A7 for ; Tue, 17 Apr 2012 22:05:06 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEFVMK98A8004SEK@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 17 Apr 2012 22:05:00 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEF9D6O0Q8012404@mauve.mrochek.com>; Tue, 17 Apr 2012 22:04:57 -0700 (PDT) Message-id: <01OEFVMIOAU2012404@mauve.mrochek.com> Date: Tue, 17 Apr 2012 22:03:46 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 16 Apr 2012 17:03:46 +0000" <9452079D1A51524AA5749AD23E0039280F383E@exch-mbx901.corp.cloudmark.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII References: <9452079D1A51524AA5749AD23E0039280F383E@exch-mbx901.corp.cloudmark.com> To: "Murray S. Kucherawy" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Call for Adoption: draft-hansen-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 05:05:07 -0000 > We're putting the finishing touches on draft-ietf-appsawg-media-type-regs and > draft-ietf-appsawg-mime-charset-default will complete WGLC this week. In the > mix now (by virtue of a reference from the former) is > draft-hansen-media-type-suffix-regs, and so we'd like to adopt it as a WG > document. > Please indicate your support or objection, and opinions thereto. I strongly prefer processing it as a WG document, especially since the media types registration update now contains a normative reference to it. Ned From laurentwalter.goix@telecomitalia.it Tue Apr 17 22:07: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 CE9F121F85CD for ; Tue, 17 Apr 2012 22:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=0.149, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhYZW4j659ly for ; Tue, 17 Apr 2012 22:07:52 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 895AD21F85C5 for ; Tue, 17 Apr 2012 22:07:51 -0700 (PDT) Content-Type: multipart/mixed; boundary="_646d3576-821c-4ffc-bcac-4dbf0012c07c_" 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.245.1; Wed, 18 Apr 2012 07:07:46 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Wed, 18 Apr 2012 07:07:46 +0200 From: Goix Laurent Walter To: "Paul E. Jones" , 'Melvin Carvalho' , 'Mike Jones' Date: Wed, 18 Apr 2012 07:07:41 +0200 Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0B/rNJdACTlkYtAqzWkh2V9enewIAAWKeg Message-ID: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <04fb01cd1cf6$23131c80$69395580$@packetizer.com> In-Reply-To: <04fb01cd1cf6$23131c80$69395580$@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: 'Apps Discuss' Subject: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 05:07:55 -0000 --_646d3576-821c-4ffc-bcac-4dbf0012c07c_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE52EE05CBE1GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE52EE05CBE1GRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 The acct : URI scheme is needed to give social network users a global ident= ity in the form of 1) a URI and 2) that is compatible with a large majority= of similarly formatted identifiers such as mailto:, sip:, xmpp: etc. each = of them is adapted & linked to its own protocol or sphere of influence and = users may or may not have the same identifier on all these URIs, although t= here may be deployments of service platforms that mix some of these protoco= ls where it make sense unifying the user@domain concept (which again is all= what the user sees). The need for such a URI is also interesting for reuse within data formats f= or exchanging social information, eg in activity streams or opensocial spec= ifications, where identifiers need be URIs. This goes actually beyond the s= cope of webfinger but clearly pertains to the sphere of a social network id= entifier. walter Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Pe= r conto di Paul E. Jones Inviato: mercoled=EC 18 aprile 2012 7.00 A: 'Melvin Carvalho'; 'Mike Jones' Cc: 'Apps Discuss' Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) Melvin, On "acct:"... Humans will usually interchange an acct URI and mailto URI, probably never = using either scheme directly in practice. That's natural and expected, if = not desired. The intent is that we define something that looks like an ema= il ID, but it's not an email ID. Some services, perhaps Twitter being most= notable, do no use email addresses. Yet, you might have an account there.= So, user@twitter.com might be used by humans and= automated systems would convert that to acct:user@twitter.com. It would n= ot be appropriate to use mailto: since it's not an email ID. We did have a lot of debate about the use of "acct". If you query my WebFi= nger server, you'll see that it will work without "acct:" prefixed, as that= was a suggestion made a year or so ago. It will inspect the input and if = it looks like an acct URI, it will assume it is. The "acct" URI will be re= turned as an alias. However, we should always use some kind of URI scheme = to remove the guesswork. The client can often make a very good guess as to= whether it's looking for a user account or something else. So, let it tel= l the server what it is looking for explicitly. We need a URI scheme, because WebFinger can be used to discover all kinds o= f information related to a given domain, not only user information. It can= be used to query information about any URI, be that a web page, a user acc= ount, device on the network, etc. If we got rid of "acct", then we would h= ave a system where we sometimes use a URI scheme and sometimes we do not. = Results might be inconsistent, as the server may not make the right guess, = unless we agreed that absence of a scheme defaults to "acct:". However, I = see no reason for the client to be so lazy to not include "acct:". The use= r might (and probably will) exclude it, but the client code can add it. At this point, I'd argue the "train has left the station" on "acct", too. = The current WebFinger spec exists (in part) to formally document that which= has adopted; it's not a new thing. Paul A couple of points: 1. JSON =3D=3D=3D=3D=3D=3D=3D I think at the time webfinger was created in 2009, XML was the de facto ser= ialization, used in AJAX, SOAP and many other systems. Today I'm hearing m= ore and more, that both developers and publishers, want to work with JSON, = rather than, having to support both xml and json. Content negotiation also= confuses some publishers. In my view, this is a great simplification that= webfinger can learn from SWD. 2. acct: scheme =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The acct: URI scheme has not proved popular, imho, and has added a layer of= complexity and confusion. How do we get from acct: to mailto:? When shou= ld you use acct: and when mailto: (the spec says acct:user@host may be diff= erent from mailto:user@host). What about the forms. How= about linked data ecosystems that want to cross link identifiers, do they = now have to consider both cases? >From the original post introducing acct: "I don't expect everyone to like this idea. I wish I could say I love it, b= ut I am simply content with it." I dont know of anyone in the community (and correct me if this has changed)= that really loves acct:, or perhaps even likes the acct: idea. SWD has sh= own you can do discovery without acct: and I think that's a big plus. One final side note is that this almost becomes trivial when you can do SPA= RQL queries. "void" is already registered by the W3C with IANA in .well-kn= own in order to discover SPARQL endpoints. It may be overkill in some peop= le's eyes, but Linked Data (which predates webfinger), particularly newer t= hings like JSON LD, are a lot bigger than they were in 2009. In a few year= s it may become the definitive discovery mechanism anyway. 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_A09A9E0A4B9C654E8672D1DC003633AE52EE05CBE1GRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1

The acct : URI scheme is needed to give social network = users a global identity in the form of 1) a URI and 2) that is compatible w= ith a large majority of similarly formatted identifiers such as mailto:, sip:, xmpp: e= tc. each of them is adapted & linked to its own protocol or sphere of i= nfluence and users may or may not have the same identifier on all these URI= s, although there may be deployments of service platforms that mix some of these protocols where it make sense = unifying the user@domain concept (which again is all what the user sees).

 

The need for such a URI is also interesting for reuse within= data formats for exchanging social information, eg in activity streams or = opensocial specifications, where identifiers need be URIs. This goes actually beyond = the scope of webfinger but clearly pertains to the sphere of a social netwo= rk identifier.

 

walter

 

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounce= s@ietf.org] Per conto di Paul E. Jones
Inviato: mercoled=EC 18 aprile 2012 7.00
A: 'Melvin Carvalho'; 'Mike Jones'
Cc: 'Apps Discuss'
Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Dis= covery (SWD)

 

Melvin,

 

On “acct:”…

 

Humans will usually interchange an acct URI and mailto URI, = probably never using either scheme directly in practice.  That’s= natural and expected, if not desired.  The intent is that we define something that looks li= ke an email ID, but it’s not an email ID.  Some services, perhap= s Twitter being most notable, do no use email addresses.  Yet, you mig= ht have an account there.  So, user@twitter.com might be used by h= umans and automated systems would convert that to acct:user@twitter.com.&nb= sp; It would not be appropriate to use mailto: since it’s not an emai= l ID.

 

We did have a lot of debate about the use of “acctR= 21;.  If you query my WebFinger server, you’ll see that it will = work without “acct:” prefixed, as that was a suggestion made a year or so ago.  It will inspect the = input and if it looks like an acct URI, it will assume it is.  The = 220;acct” URI will be returned as an alias.  However, we should = always use some kind of URI scheme to remove the guesswork.  The client can often make a very good guess as to whether it’s looki= ng for a user account or something else.  So, let it tell the server w= hat it is looking for explicitly.

 

We need a URI scheme, because WebFinger can be used to disco= ver all kinds of information related to a given domain, not only user infor= mation.  It can be used to query information about any URI, be that a web page, a u= ser account, device on the network, etc.  If we got rid of “acct= ”, then we would have a system where we sometimes use a URI scheme an= d sometimes we do not.  Results might be inconsistent, as the server may not make the right guess, unless we agreed that absence = of a scheme defaults to “acct:”.  However, I see no reason= for the client to be so lazy to not include “acct:”.  The= user might (and probably will) exclude it, but the client code can add it.

 

At this point, I’d argue the “train has left the= station” on “acct”, too.  The current WebFinger spe= c exists (in part) to formally document that which has adopted; it’s not a new thing.

 

Paul

 

A couple of points:

1. JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the time webfinger was created in 2009, XML was the de facto ser= ialization, used in AJAX, SOAP and many other systems.  Today I'm hear= ing more and more, that both developers and publishers, want to work with J= SON, rather than, having to support both xml and json.  Content negotiation also confuses some publishers.&nbs= p; In my view, this is a great simplification that webfinger can learn from= SWD.

2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The acct: URI scheme has not proved popular, imho, and has added a layer of= complexity and confusion.  How do we get from acct: to mailto:? = When should you use acct: and when mailto: (the spec says acct:user@host m= ay be different from mailto:user@host).&nb= sp; What about the forms.  How about linked data ecosystems that want to = cross link identifiers, do they now have to consider both cases? 

>From the original post introducing acct:

"I don’t expect everyone to like this idea. I wish I could say I= love it, but I am simply content with it."

I dont know of anyone in the community (and correct me if this has changed)= that really loves acct:, or perhaps even likes the acct: idea.  SWD h= as shown you can do discovery without acct: and I think that's a big plus.<= br>



One final side note is that this almost becomes trivial when you can do SPA= RQL queries.  "void" is already registered by the W3C with I= ANA in .well-known in order to discover SPARQL endpoints.  It may be o= verkill in some people's eyes, but Linked Data (which predates webfinger), particularly newer things like JSON LD, are a lot big= ger than they were in 2009.  In a few years it may become the definiti= ve discovery mechanism anyway.

= 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_A09A9E0A4B9C654E8672D1DC003633AE52EE05CBE1GRFMBX704BA02_-- --_646d3576-821c-4ffc-bcac-4dbf0012c07c_ 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= --_646d3576-821c-4ffc-bcac-4dbf0012c07c_-- From eran@hueniverse.com Tue Apr 17 22:48: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 0B2D321F85FC for ; Tue, 17 Apr 2012 22:48:08 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwP0D2DRwfCb for ; Tue, 17 Apr 2012 22:48:03 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 831F921F85F9 for ; Tue, 17 Apr 2012 22:48:03 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id zHo31i0010EuLVk01Ho3Aj; Tue, 17 Apr 2012 22:48:03 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Tue, 17 Apr 2012 22:48:02 -0700 From: Eran Hammer To: Peter Saint-Andre Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHRLTaZSrZrlIgUCh6SbaqWWu4pagEvLw Date: Wed, 18 Apr 2012 05:48:02 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE7AD@P3PWEX2MB008.ex2.secureserver.net> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B16804296739436648BF09@TK5EX14MBXC284.redmond.corp.microsoft.com> <9452079D1A51524AA5749AD23E0039280F707F@exch-mbx901.corp.cloudmark.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3A5@P3PWEX2MB008.ex2.secureserver.net> <4F8E3404.5000708@stpeter.im> In-Reply-To: <4F8E3404.5000708@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 05:48:08 -0000 SSB3b3VsZCBoYXZlIGRyb3BwZWQgWE1MIHN1cHBvcnQgZnJvbSB0aGUgaG9zdC1tZXRhIFJGQyBi dXQgYXQgdGhhdCBwb2ludCBpdCB3YXMgaGFyZCB0byBtYWtlIHN1Y2ggY2hhbmdlcy4gTWFraW5n IHN1Y2ggYSBjaGFuZ2Ugbm93IHdpdGggYW4gdXBkYXRlZCBSRkMgYmFzZWQgb24gdGhlIHNhbWUg Zm91bmRhdGlvbiAoZS5nLiB0aGUgZG9jdW1lbnQgKyBxdWVyeSBzaG9ydGN1dCArIExSREQgcmVs YXRpb25zKSBtaWdodCBiZSB0aGUgbW9zdCBpbmNsdXNpdmUgcGF0aCBmb3J3YXJkLg0KDQpFSA0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFBldGVyIFNhaW50LUFuZHJl IFttYWlsdG86c3RwZXRlckBzdHBldGVyLmltXQ0KPiBTZW50OiBUdWVzZGF5LCBBcHJpbCAxNywg MjAxMiA4OjI1IFBNDQo+IFRvOiBFcmFuIEhhbW1lcg0KPiBDYzogTXVycmF5IFMuIEt1Y2hlcmF3 eTsgYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBb T0FVVEgtV0ddIFdlYiBGaW5nZXIgdnMuIFNpbXBsZSBXZWINCj4gRGlzY292ZXJ5IChTV0QpDQo+ IA0KPiBSaWdodCwgYXQgdGhhdCBwb2ludCB0aGUgZGlmZmVyZW5jZXMgYXBwZWFyIHRvIGJlIG1v c3RseSBhYm91dCBzeW50YXgsIG5vdA0KPiBzZW1hbnRpY3MuDQo+IA0KPiBPbiA0LzE3LzEyIDk6 MjMgUE0sIEVyYW4gSGFtbWVyIHdyb3RlOg0KPiA+IFByYWN0aWNhbGx5IHZlcnkgbGl0dGxlIGlm IHRoZSBsYXRlc3QgV2ViZmluZ2VyIGRyYWZ0IGFkZGl0aW9uIGFyZQ0KPiA+IGFkb3B0ZWQgKGUu Zy4gdGhlIHJlc291cmNlIGFuZCByZWwgcXVlcnkgc2hvcnRjdXRzIHdoaWNoIHdlcmUNCj4gPiBv cmlnaW5hbGx5IHByb3Bvc2VkIGluIHRoZSBmaXJzdCBPcGVuSUQgQ29ubmVjdCBwcm9wb3NhbCBi eSBEYXZpZCBSZWNvcmRvbg0KPiBhbmQgbXlzZWxmKS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBFSA0K PiA+DQo+ID4NCj4gPg0KPiA+ICpGcm9tOipvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gKk9uDQo+ID4gQmVoYWxmIE9mICpNdXJyYXkgUy4gS3Vj aGVyYXd5DQo+ID4gKlNlbnQ6KiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA3OjU1IFBNDQo+ID4g KlRvOiogYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+ID4gKkNjOiogb2F1dGhAaWV0Zi5vcmcgV0cN Cj4gPiAqU3ViamVjdDoqIFJlOiBbT0FVVEgtV0ddIFthcHBzLWRpc2N1c3NdIFdlYiBGaW5nZXIg dnMuIFNpbXBsZSBXZWINCj4gPiBEaXNjb3ZlcnkgKFNXRCkNCj4gPg0KPiA+DQo+ID4NCj4gPiBT byB0aGVyZSBhcmUgc29tZSBvZiBib3RoLiAgSG93IHRyZWFjaGVyb3VzIGlzIHRoZSBtaWdyYXRp b24gcGF0aCBmcm9tDQo+ID4gU1dEIHRvIFdlYkZpbmdlciwgZm9yIGV4YW1wbGUsIGluIGNhc2Ug Y29uc2Vuc3VzIGlzIHRvIGRldmVsb3AgYW5kDQo+ID4gbW92ZSBmb3J3YXJkIHdpdGggdGhlIGxh dHRlcj8NCj4gPg0KPiA+DQo+ID4NCj4gPiAtTVNLDQo+ID4NCj4gPg0KPiA+DQo+ID4gKkZyb206 KmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnDQo+ID4gPG1haWx0bzphcHBzLWRpc2N1c3Mt Ym91bmNlc0BpZXRmLm9yZz4NCj4gPiBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYu b3JnXQ0KPiA+IDxtYWlsdG86W21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10+ ICpPbiBCZWhhbGYgT2YgKk1pa2UNCj4gPiBKb25lcw0KPiA+ICpTZW50OiogVHVlc2RheSwgQXBy aWwgMTcsIDIwMTIgNDoyNSBQTQ0KPiA+ICpUbzoqIEJsYWluZSBDb29rOyBUaW0gQnJheQ0KPiA+ ICpDYzoqIG9hdXRoQGlldGYub3JnIDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IFdHOyBhcHBzLWRp c2N1c3NAaWV0Zi5vcmcNCj4gPiA8bWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4NCj4gPiAq U3ViamVjdDoqIFJlOiBbYXBwcy1kaXNjdXNzXSBbT0FVVEgtV0ddIFdlYiBGaW5nZXIgdnMuIFNp bXBsZSBXZWINCj4gPiBEaXNjb3ZlcnkgKFNXRCkNCj4gPg0KPiA+DQo+ID4NCj4gPiBJIGtub3cg dGhhdCA3IG9mIHRoZSA4IHB1YmxpYyBwYXJ0aWNpcGFudHMgaW4gdGhlIGN1cnJlbnQgT3BlbklE DQo+ID4gQ29ubmVjdCBpbnRlcm9wIHRlc3RpbmcgaGF2ZSBpbXBsZW1lbnRlZCBTV0QgYXQgdGhp cyBwb2ludC4gIChJIGtub3cNCj4gPiBvZiBzZXZlcmFsIG1vcmUgd2hv4oCZdmUgYnVpbHQgaXQg YXMgd2VsbCBidXQgaGF2ZW7igJl0IGNob3NlbiB0byBtYWtlDQo+ID4gdGhlaXIgaW50ZXJvcCB0 ZXN0IHJlc3VsdHMgcHVibGljIHlldC4pICBUaGVyZSBhcmUgbGlrZWx5IG90aGVyDQo+ID4gaW1w bGVtZW50YXRpb25zIEnigJltIHVuYXdhcmUgb2YuDQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0g TWlrZQ0KPiA+DQo+ID4NCj4gPg0KPiA+ICpGcm9tOipvYXV0aC1ib3VuY2VzQGlldGYub3JnIDxt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4NCj4gPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKkJsYWluZSBDb29rDQo+ID4gKlNlbnQ6KiBUdWVzZGF5 LCBBcHJpbCAxNywgMjAxMiAzOjU0IFBNDQo+ID4gKlRvOiogVGltIEJyYXkNCj4gPiAqQ2M6KiBv YXV0aEBpZXRmLm9yZyA8bWFpbHRvOm9hdXRoQGlldGYub3JnPiBXRzsgYXBwcy1kaXNjdXNzQGll dGYub3JnDQo+ID4gPG1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQo+ID4gKlN1YmplY3Q6 KiBSZTogW09BVVRILVdHXSBbYXBwcy1kaXNjdXNzXSBXZWIgRmluZ2VyIHZzLiBTaW1wbGUgV2Vi DQo+ID4gRGlzY292ZXJ5IChTV0QpDQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhhdCdzIGEgdHJpY2t5 IHF1ZXN0aW9uIC0gbWF5YmUgb25lIGdvb2dsZSBjYW4gaGVscCBhbnN3ZXI/IFRoZXJlIGFyZQ0K PiA+IGEgYnVuY2ggb2YgcHJvamVjdHMgdXNpbmcgd2ViZmluZ2VyLCBpbmNsdWRpbmcgc3RhdHVz Lm5ldA0KPiA+IDxodHRwOi8vc3RhdHVzLm5ldD4sIG9zdGF0dXMgaW4gZ2VuZXJhbCwgZGlhc3Bv cmEsIHVuaG9zdGVkLA0KPiA+IGZyZWVkb21ib3goPyksIGFuZCBJJ20gc3VyZSBvdGhlcnMsIGJ1 dCBJIGhhdmUgbm8gaWRlYSBob3cgdGhhdA0KPiA+IHRyYW5zbGF0ZXMgaW50byBhY3R1YWwgdXNl cnMgb3IgcHJvZmlsZXMuDQo+ID4NCj4gPiBHbWFpbCwgYW9sLCBhbmQgeWFob28gYWxsIHB1dCB1 cCB3ZWJmaW5nZXIgZW5kcG9pbnRzLCBidXQgdGhlcmUgaGFzbid0DQo+ID4gYmVlbiBtdWNoIG1v dmVtZW50LCBJIHRoaW5rIGR1ZSB0byB0aGUgY2hpY2tlbiBhbmQgZWdnIG5hdHVyZSBvZg0KPiA+ IGFkb3B0aW9uIGFyb3VuZCBkZWNlbnRyYWxpemVkIHRvb2xzLg0KPiA+DQo+ID4gYi4NCj4gPg0K PiA+IE9uIEFwciAxNywgMjAxMiAxMToxMyBBTSwgIlRpbSBCcmF5IiA8dGJyYXlAdGV4dHVhbGl0 eS5jb20NCj4gPiA8bWFpbHRvOnRicmF5QHRleHR1YWxpdHkuY29tPj4gd3JvdGU6DQo+ID4NCj4g PiBXaGF0IGlzIHRoZSBkZXBsb3ltZW50IHN0YXR1cyBvZiB0aGVzZSB0d28gc3BlY3M/ICBJcyBl aXRoZXIgZGVwbG95ZWQNCj4gPiBtdWNoIGF0IGFsbD8gIC1UDQo+ID4NCj4gPiBPbiBGcmksIEFw ciAxMywgMjAxMiBhdCAxMDo0NSBBTSwgTXVycmF5IFMuIEt1Y2hlcmF3eQ0KPiA+IDxtc2tAY2xv dWRtYXJrLmNvbSA8bWFpbHRvOm1za0BjbG91ZG1hcmsuY29tPj4gd3JvdGU6DQo+ID4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTogYXBwcy1kaXNjdXNzLWJvdW5jZXNA aWV0Zi5vcmcNCj4gPiA8bWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPg0KPiA+ IFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiA8bWFpbHRvOmFwcHMt ZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFN0ZXBoZW4gRmFycmVsbA0K PiA+Pj4gU2VudDogRnJpZGF5LCBBcHJpbCAxMywgMjAxMiA5OjIzIEFNDQo+ID4+PiBUbzogb2F1 dGhAaWV0Zi5vcmcgPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gV0cNCj4gPj4+IENjOiBBcHBzIERp c2N1c3MNCj4gPj4+IFN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBbT0FVVEgtV0ddIFdlYiBG aW5nZXIgdnMuIFNpbXBsZSBXZWINCj4gPiBEaXNjb3ZlcnkgKFNXRCkNCj4gPj4+DQo+ID4+PiBT byBIYW5uZXMgYW5kIERlcmVrIGFuZCBJIGhhdmUgYmVlbiBkaXNjdXNzaW5nIHRoaXMgd2l0aCB0 aGUgQXBwcw0KPiA+Pj4gQURzIGFuZCBBcHBzLWFyZWEgV0cgY2hhaXJzLiBJJ3ZlIGFsc28gcmVh ZCB0aGUgZG9jcyBub3csIGFuZCBhZnRlcg0KPiA+Pj4gYWxsIHRoYXQgd2UndmUgZGVjaWRlZCB0 aGF0IHRoaXMgdG9waWMgKHdoYXQgdG8gZG8gd2l0aCBzd2QgYW5kDQo+ID4+PiB3ZWJmaW5nZXIp IGlzIGJlc3QgaGFuZGxlZCBpbiB0aGUgYXBwcyBhcmVhIGFuZCBub3QgaW4gdGhlIG9hdXRoIFdH Lg0KPiA+Pj4NCj4gPj4+IFRoZSBsb2dpYyBmb3IgdGhhdCBpcyB0aGF0IDEpIHRoZSB0d28gcHJv cG9zYWxzIGFyZSBkb2luZyB0aGUgc2FtZQ0KPiA+Pj4gdGhpbmcgYW5kIHdlIGRvbid0IHdhbnQg dHdvIGRpZmZlcmVudCBzdGFuZGFyZHMgZm9yIHRoYXQsIGIpIHRoaXMgaXMNCj4gPj4+IG5vdCBh biBvYXV0aC1zcGVjaWZpYyB0aGluZyBub3IgaXMgaXQgYSBnZW5lcmFsIHNlY3VyaXR5IHRoaW5n LCBhbmQNCj4gPj4+IGMpIHRoZXJlIGlzIGNsZWFybHkgYWxyZWFkeSBpbnRlcmVzdCBpbiB0aGUg dG9waWMgaW4gdGhlIGFwcHMgYXJlYQ0KPiA+Pj4gc28gaXRzIHJlYXNvbmFibGUgZm9yIHRoZSBv YXV0aCB3ZyB0byB1c2UgdGhhdCB3aGVuIGl0cyByZWFkeS4NCj4gPj4+DQo+ID4+PiBUaGUgYXBw c2F3ZyBjaGFpcnMgYW5kIGFwcHMgQURzIGFyZSBvayB3aXRoIHRoZSB3b3JrIGJlaW5nIGRvbmUN Cj4gdGhlcmUuDQo+ID4+Pg0KPiA+Pj4gU286LQ0KPiA+Pj4NCj4gPj4+IC0gSSd2ZSBhc2tlZCB0 aGUgb2F1dGggY2hhaXJzIHRvIHRha2UgZG9pbmcgd29yayBvbiBzd2QNCj4gPj4+ICAgb3V0IG9m IHRoZSBwcm9wb3NlZCBuZXcgY2hhcnRlcg0KPiA+Pj4gLSBJdCBtYXkgYmUgdGhhdCB5b3Ugd2Fu dCB0byBhZGQgc29tZXRoaW5nIHNheWluZyB0aGF0DQo+ID4+PiAgIG9hdXRoIHdpbGwgdXNlIHRo ZSByZXN1bHRzIG9mIHdvcmsgaW4gdGhlIGFwcGxpY2F0aW9ucw0KPiA+Pj4gICBhcmVhIG9uIGEg d2ViIGRpc2NvdmVyeSBwcm90b2NvbCBhcyBhIGJhc2lzIGZvciBkb2luZw0KPiA+Pj4gICB0aGUg ZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIHdvcmsgaGVyZQ0KPiA+Pj4gLSBEaXNjdXNzaW9u IG9mIHdlYmZpbmdlciBhbmQgc3dkIHNob3VsZCBtb3ZlIG92ZXIgdG8NCj4gPj4+ICAgdGhlIGFw cHMtZGlzY3VzcyBsaXN0DQo+ID4+PiAtIE5vdGU6IHRoaXMgaXMgbm90IHBpY2tpbmcgb25lIG9y IHRoZSBvdGhlciBhcHByb2FjaCwNCj4gPj4+ICAgdGhlIHBsYW4gaXMgdGhhdCB0aGUgYXBwcyBh cmVhIHdpbGwgZG8gYW55IHNlbGVjdGlvbg0KPiA+Pj4gICBuZWVkZWQgYW5kIGZpZ3VyZSBvdXQg dGhlIGJlc3Qgc3RhcnRpbmcgcG9pbnQgZm9yIGENCj4gPj4+ICAgc3RhbmRhcmRzLXRyYWNrIFJG QyBvbiB3ZWIgZGlzY292ZXJ5IGFuZCB3ZSdsbCB1c2UgdGhlaXINCj4gPj4+ICAgZmluZSB3b3Jr IGZvciBkb2luZyBtb3JlIHdpdGggb2F1dGguDQo+ID4+DQo+ID4+IFRoYW5rIHlvdSBTdGVwaGVu LCBJIHRoaW5rLiAgOi0pDQo+ID4+DQo+ID4+IFNvIHRoZSBkaXNjdXNzaW9uIG9uIGFwcHMtZGlz Y3VzcyBub3cgc2hvdWxkIGJlIGZvY3VzZWQgb24gd2hpY2ggb2YNCj4gPiB0aGUgdHdvIHNob3Vs ZCBiZSB0aGUgYmFzaXMgZm9yIGZvcndhcmQgcHJvZ3Jlc3MuICBJJ3ZlIHBsYWNlZCBib3RoDQo+ ID4gZG9jdW1lbnRzIGluICJDYWxsIGZvciBBZG9wdGlvbiIgc3RhdGUgaW4gdGhlIGRhdGF0cmFj a2VyIGZvciBhcHBzYXdnLg0KPiA+Pg0KPiA+PiBMZXQgdGhlIGdhbWVzIGJlZ2luLg0KPiA+Pg0K PiA+PiAtTVNLDQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+IGFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCj4gPj4gYXBwcy1kaXNjdXNz QGlldGYub3JnIDxtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnPg0KPiA+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0K From eran@hueniverse.com Tue Apr 17 22:51: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 3FF2121F85FD for ; Tue, 17 Apr 2012 22:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5DHuKYMrmmI for ; Tue, 17 Apr 2012 22:50:55 -0700 (PDT) Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id AD0D421F8607 for ; Tue, 17 Apr 2012 22:50:46 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id zHqm1i0010CJzpC01Hqm9D; Tue, 17 Apr 2012 22:50:46 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Tue, 17 Apr 2012 22:50:46 -0700 From: Eran Hammer To: John Panzer , Stephen Farrell Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHQFrF/0InOfd1UaZVRxjSISCxZagE+ag Date: Wed, 18 Apr 2012 05:50:45 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE8AC@P3PWEX2MB008.ex2.secureserver.net> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <04f601cd1cf3$88ab49d0$9a01dd70$@packetizer.com> <4F8E0485.3020105@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FEE8ACP3PWEX2MB008ex2se_" MIME-Version: 1.0 Cc: Derek Atkins , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 05:51:00 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FEE8ACP3PWEX2MB008ex2se_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with John. While WF makes more information available directly, it i= s often in the form of templates. If you already know the resources you car= e about, and no authentication/authorization layer has been deployed, both = expose the exact same amount of data. Both are dealing (as specified withou= t additional layers) with public data. EH From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of John Panzer Sent: Tuesday, April 17, 2012 6:20 PM To: Stephen Farrell Cc: Derek Atkins; apps-discuss@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) It seems to me there is no difference between the two w.r.t. privacy and ag= gregation of data, if you grant that webfinger's reliance on separate http = auth mechanisms is sufficient to allow access control. On Apr 17, 2012 5:02 PM, "Stephen Farrell" > wrote: Hi Paul, There's also the question of privacy. Aggregated information is always more sensitive. Sets of links, in aggregate, do leak private information. So it would seem fair to say that the bigger document approach has the worse privacy problem, at least in the abstract. If it were the case that webfinger made it noticeably harder to partition who knows what about me, then that would be a privacy downside, and not in the abstract, but practically. (Not a sure showstopper, but a thing that needs attention at least.) However, I've no idea how these are envisaged to be deployed, or are being deployed, nor if its (intended to be) easy for a user to create loads of different profiles/documents/whatever or not. So - do you agree this is an issue, that webfinger aggregates (possibly lots of) different pointers related to the same person? And, how significant is that and are there ways to mitigate it, for those who might care? This aspect is essentially ignored by both swd and webfinger drafts as far as I can see, but does seem worse with the latter approach, at least as I understand it. (However, for a bit of balance the string "privacy" does occur in swd, but the term is misused when "confidentiality" was meant:-) I do think user privacy is worth consideration regardless of which approach is taken ultimately. S On 04/18/2012 12:40 AM, Paul E. Jones wrote: > Derek, > >> This leaves only the perceived issue of "whole document" vs "individual >> attribute". If a client ever wants more than one attribute then a whole >> document approach reduces the number of round trips. However if documen= ts >> get large that could also affect performance. We might, then, need a wa= y >> to specify which attributes are requested, but allow for a wildcard to >> return "everything I am authorized to see". > > If the document gets large, you're right that it might be an issue. For > this reason, we introduced the "rel" parameter in the most recent WebFing= er > draft. Like HTML, this is a space-separated list of link relation types. > The idea is that the server will filter based on that list. > > If you want to see it in action, you can issue a query against my ID: > $ curl https://packetizer.com/.well-known/host-meta?\ > resource=3Dacct%3Apaulej%40packetizer.com > > or > > $ curl 'https://packetizer.com/.well-known/host-meta?\ > resource=3Dacct%3Apaulej%40packetizer.com&\ > rel=3Dvcard+http%3A%2F%2Fwebfinger.net%2Frel%2Favatar' > > The first example returns the entire XRD document. The second example > returns only link relations of type vcard or > http://webfinger.net/rel/avatar. To get JSON output, just replace host-m= eta > with host-meta.json as per RFC 6415 (or use an "Accept" header with > application/json). > > Now, I'm still wondering if a resource descriptor document will ever get = so > large. It does not return information about a user, just pointers to > information. So, do we need "rel"? If there is definitely only a certai= n > set of link relations of interest, it's a way to limit the output. I > suppose it does not hurt to introduce it; it's the value I question. I'd > definitely like input on the utility. Given the claims that SWD is simpl= er > because of the limited information returned, perhaps that lends to the > argument that it is useful. > > 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 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FEE8ACP3PWEX2MB008ex2se_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with John. While = WF makes more information available directly, it is often in the form of te= mplates. If you already know the resources you care about, and no authentication/authorization layer has been deployed, both expose t= he exact same amount of data. Both are dealing (as specified without additi= onal layers) with public data.

 <= /p>

EH

 <= /p>

From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Panzer
Sent: Tuesday, April 17, 2012 6:20 PM
To: Stephen Farrell
Cc: Derek Atkins; apps-discuss@ietf.org
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Dis= covery (SWD)

 

It seems to me there is no difference between the two w.r.t. privacy and= aggregation of data, if you grant that webfinger's reliance on separate ht= tp auth mechanisms is sufficient to allow access control.

On Apr 17, 2012 5:02 PM, "Stephen Farrell"= <stephen= .farrell@cs.tcd.ie> wrote:


Hi Paul,

There's also the question of privacy. Aggregated information is
always more sensitive. Sets of links, in aggregate, do leak
private information.

So it would seem fair to say that the bigger document approach
has the worse privacy problem, at least in the abstract.

If it were the case that webfinger made it noticeably harder to
partition who knows what about me, then that would be a privacy
downside, and not in the abstract, but practically. (Not a sure
showstopper, but a thing that needs attention at least.)

However, I've no idea how these are envisaged to be deployed, or
are being deployed, nor if its (intended to be) easy for a user
to create loads of different profiles/documents/whatever or not.

So - do you agree this is an issue, that webfinger aggregates
(possibly lots of) different pointers related to the same person?

And, how significant is that and are there ways to mitigate it,
for those who might care?

This aspect is essentially ignored by both swd and webfinger
drafts as far as I can see, but does seem worse with the latter
approach, at least as I understand it. (However, for a bit of
balance the string "privacy" does occur in swd, but the term
is misused when "confidentiality" was meant:-)

I do think user privacy is worth consideration regardless of
which approach is taken ultimately.

S

On 04/18/2012 12:40 AM, Paul E. Jones wrote:
> Derek,
>
>> This leaves only the perceived issue of "whole document"= vs "individual
>> attribute".  If a client ever wants more than one attrib= ute then a whole
>> document approach reduces the number of round trips.  However= if documents
>> get large that could also affect performance.  We might, then= , need a way
>> to specify which attributes are requested, but allow for a wildcar= d to
>> return "everything I am authorized to see".
>
> If the document gets large, you're right that it might be an issue. &n= bsp;For
> this reason, we introduced the "rel" parameter in the most r= ecent WebFinger
> draft.  Like HTML, this is a space-separated list of link relatio= n types.
> The idea is that the server will filter based on that list.
>
> If you want to see it in action, you can issue a query against my ID:<= br> > $ curl https://packetizer.com/.well-known/host-meta?\
>                     =         resource=3Dacct%3Apaulej%40packetizer.com
>
> or
>
> $ curl 'https://packetizer.com/.well-known/host-meta?\
>         resource=3Dacct%3Apaulej%40packetizer.com&\
>         rel=3Dvcard+http%3A%2F%2Fwebfinger.net= %2Frel%2Favatar'
>
> The first example returns the entire XRD document.  The second ex= ample
> returns only link relations of type vcard or
> http://w= ebfinger.net/rel/avatar.  To get JSON output, just replace host-me= ta
> with host-meta.json as per RFC 6415 (or use an "Accept" head= er with
> application/json).
>
> Now, I'm still wondering if a resource descriptor document will ever g= et so
> large.  It does not return information about a user, just pointer= s to
> information.  So, do we need "rel"?  If there is d= efinitely only a certain
> set of link relations of interest, it's a way to limit the output. &nb= sp;I
> suppose it does not hurt to introduce it; it's the value I question. &= nbsp;I'd
> definitely like input on the utility.  Given the claims that SWD = is simpler
> because of the limited information returned, perhaps that lends to the=
> argument that it is useful.
>
> Paul
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discus= s@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

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FEE8ACP3PWEX2MB008ex2se_-- From ve7jtb@ve7jtb.com Wed Apr 18 00:12: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 B0E6421F8607 for ; Wed, 18 Apr 2012 00:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhCumVkDe-Wn for ; Wed, 18 Apr 2012 00:12:45 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D1A7221F8616 for ; Wed, 18 Apr 2012 00:12:44 -0700 (PDT) Received: by werb10 with SMTP id b10so5510730wer.31 for ; Wed, 18 Apr 2012 00:12:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=v3vfbKwH+BUqLn8T6tzOqTGA9XxGg78dEuRrY/2mmvI=; b=RexHS7usljE2UR2JsyoesohqYLKx0/yRfhraIKgnuxbeZDSUnYuBLi75bKr5bb+xmN z95AsTO1r7TP04KGL9l+g5PUPJQO44AAif5zvMqw3iP/RyvCOhXQuBuOX5gyOu7kEbjm KAILJMHzRTB2ypeFbKd6wY4x7pZ/vrlOIGPMVyhUZX5Fv4VO2yTD+YjSjy8nK2VEAFDs Toq2BWJ81uehSRnY8lxOvfO+1DpO/3JA5xISyrtQ3/RJMTZASaIC02qxJjFYAvbj1pEy goe2b073iaYcV98R8QTgApAEOgNz+f5wHeNxDtYy2QWadnv3X4nFjTSbgeKIY6vJ2POM rdnA== Received: by 10.180.24.66 with SMTP id s2mr3480817wif.7.1334733163789; Wed, 18 Apr 2012 00:12:43 -0700 (PDT) Received: from [10.6.1.77] (nat-VI.gw1.ush2.tnib.de. [86.110.65.2]) by mx.google.com with ESMTPS id fz9sm32577525wib.3.2012.04.18.00.12.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Apr 2012 00:12:41 -0700 (PDT) References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <04f601cd1cf3$88ab49d0$9a01dd70$@packetizer.com> <4F8E0485.3020105@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE8AC@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE8AC@P3PWEX2MB008.ex2.secureserver.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-E909F96B-9391-4F68-BC62-8C4D65179C01; protocol="application/pkcs7-signature" Message-Id: <56D28A27-11A8-48C4-A49E-492EC02B7918@ve7jtb.com> X-Mailer: iPad Mail (9B176) From: John Bradley Date: Wed, 18 Apr 2012 09:13:01 +0200 To: Eran Hammer X-Gm-Message-State: ALoCoQkNZTaV6ZEIaTKnh6Xa9DYIL1AjuAxGcRgDWI3OiN6hxJmOCswnm5snPMkYMbYXBF/DEHUI Cc: Derek Atkins , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 07:12:50 -0000 --Apple-Mail-E909F96B-9391-4F68-BC62-8C4D65179C01 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-F38281E2-B3E5-4465-AD06-79E72C8D077C --Apple-Mail-F38281E2-B3E5-4465-AD06-79E72C8D077C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I don't think there is any disagreement that without authenticating the requ= ester, both are dealing with public info. The only slight diffrence is that= SWD forces the requester to make multiple requests to get the whole documen= t. The downside to SWD is that it requires a requester to make multiple re= quests to find multiple services. Once we add authenticated access there are likely differing opinions on what= mechinisim is easier to deploy. =46rom a openID connect perspective anything requiring XML parsing is going t= o be a non starter. The irony of me saying that is not lost on me:) John B. Sent from my iPad On 2012-04-18, at 7:50 AM, Eran Hammer wrote: > I agree with John. While WF makes more information available directly, it i= s often in the form of templates. If you already know the resources you care= about, and no authentication/authorization layer has been deployed, both ex= pose the exact same amount of data. Both are dealing (as specified without a= dditional layers) with public data. > =20 > EH > =20 > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]= On Behalf Of John Panzer > Sent: Tuesday, April 17, 2012 6:20 PM > To: Stephen Farrell > Cc: Derek Atkins; apps-discuss@ietf.org > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery= (SWD) > =20 > It seems to me there is no difference between the two w.r.t. privacy and a= ggregation of data, if you grant that webfinger's reliance on separate http a= uth mechanisms is sufficient to allow access control. >=20 > On Apr 17, 2012 5:02 PM, "Stephen Farrell" wro= te: >=20 > Hi Paul, >=20 > There's also the question of privacy. Aggregated information is > always more sensitive. Sets of links, in aggregate, do leak > private information. >=20 > So it would seem fair to say that the bigger document approach > has the worse privacy problem, at least in the abstract. >=20 > If it were the case that webfinger made it noticeably harder to > partition who knows what about me, then that would be a privacy > downside, and not in the abstract, but practically. (Not a sure > showstopper, but a thing that needs attention at least.) >=20 > However, I've no idea how these are envisaged to be deployed, or > are being deployed, nor if its (intended to be) easy for a user > to create loads of different profiles/documents/whatever or not. >=20 > So - do you agree this is an issue, that webfinger aggregates > (possibly lots of) different pointers related to the same person? >=20 > And, how significant is that and are there ways to mitigate it, > for those who might care? >=20 > This aspect is essentially ignored by both swd and webfinger > drafts as far as I can see, but does seem worse with the latter > approach, at least as I understand it. (However, for a bit of > balance the string "privacy" does occur in swd, but the term > is misused when "confidentiality" was meant:-) >=20 > I do think user privacy is worth consideration regardless of > which approach is taken ultimately. >=20 > S >=20 > On 04/18/2012 12:40 AM, Paul E. Jones wrote: > > Derek, > > > >> This leaves only the perceived issue of "whole document" vs "individual= > >> attribute". If a client ever wants more than one attribute then a whol= e > >> document approach reduces the number of round trips. However if docume= nts > >> get large that could also affect performance. We might, then, need a w= ay > >> to specify which attributes are requested, but allow for a wildcard to > >> return "everything I am authorized to see". > > > > If the document gets large, you're right that it might be an issue. For= > > this reason, we introduced the "rel" parameter in the most recent WebFin= ger > > draft. Like HTML, this is a space-separated list of link relation types= . > > The idea is that the server will filter based on that list. > > > > If you want to see it in action, you can issue a query against my ID: > > $ curl https://packetizer.com/.well-known/host-meta?\ > > resource=3Dacct%3Apaulej%40packetizer.com > > > > or > > > > $ curl 'https://packetizer.com/.well-known/host-meta?\ > > resource=3Dacct%3Apaulej%40packetizer.com&\ > > rel=3Dvcard+http%3A%2F%2Fwebfinger.net%2Frel%2Favatar' > > > > The first example returns the entire XRD document. The second example > > returns only link relations of type vcard or > > http://webfinger.net/rel/avatar. To get JSON output, just replace host-= meta > > with host-meta.json as per RFC 6415 (or use an "Accept" header with > > application/json). > > > > Now, I'm still wondering if a resource descriptor document will ever get= so > > large. It does not return information about a user, just pointers to > > information. So, do we need "rel"? If there is definitely only a certa= in > > set of link relations of interest, it's a way to limit the output. I > > suppose it does not hurt to introduce it; it's the value I question. I'= d > > definitely like input on the utility. Given the claims that SWD is simp= ler > > because of the limited information returned, perhaps that lends to the > > argument that it is useful. > > > > 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 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-F38281E2-B3E5-4465-AD06-79E72C8D077C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
I don't think there is any disagreement that without authenticating the requester, both are dealing with public info.  The only slight diffrence is that SWD forces the requester to make multiple requests to get the whole document.   The downside to SWD is that it requires a requester to make multiple requests to find multiple services.

Once we add authenticated access there are likely differing opinions on what mechinisim is easier to deploy.

From a openID connect perspective anything requiring XML parsing is going to be a non starter.
The irony of me saying that is not lost on me:)

 John B.

Sent from my iPad

On 2012-04-18, at 7:50 AM, Eran Hammer <eran@hueniverse.com> wrote:

I agree with John. While WF makes more information available directly, it is often in the form of templates. If you already know the resources you care about, and no authentication/authorization layer has been deployed, both expose the exact same amount of data. Both are dealing (as specified without additional layers) with public data.

 

EH

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Panzer
Sent: Tuesday, April 17, 2012 6:20 PM
To: Stephen Farrell
Cc: Derek Atkins; apps-discuss@ietf.org
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

 

It seems to me there is no difference between the two w.r.t. privacy and aggregation of data, if you grant that webfinger's reliance on separate http auth mechanisms is sufficient to allow access control.

On Apr 17, 2012 5:02 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:


Hi Paul,

There's also the question of privacy. Aggregated information is
always more sensitive. Sets of links, in aggregate, do leak
private information.

So it would seem fair to say that the bigger document approach
has the worse privacy problem, at least in the abstract.

If it were the case that webfinger made it noticeably harder to
partition who knows what about me, then that would be a privacy
downside, and not in the abstract, but practically. (Not a sure
showstopper, but a thing that needs attention at least.)

However, I've no idea how these are envisaged to be deployed, or
are being deployed, nor if its (intended to be) easy for a user
to create loads of different profiles/documents/whatever or not.

So - do you agree this is an issue, that webfinger aggregates
(possibly lots of) different pointers related to the same person?

And, how significant is that and are there ways to mitigate it,
for those who might care?

This aspect is essentially ignored by both swd and webfinger
drafts as far as I can see, but does seem worse with the latter
approach, at least as I understand it. (However, for a bit of
balance the string "privacy" does occur in swd, but the term
is misused when "confidentiality" was meant:-)

I do think user privacy is worth consideration regardless of
which approach is taken ultimately.

S

On 04/18/2012 12:40 AM, Paul E. Jones wrote:
> Derek,
>
>> This leaves only the perceived issue of "whole document" vs "individual
>> attribute".  If a client ever wants more than one attribute then a whole
>> document approach reduces the number of round trips.  However if documents
>> get large that could also affect performance.  We might, then, need a way
>> to specify which attributes are requested, but allow for a wildcard to
>> return "everything I am authorized to see".
>
> If the document gets large, you're right that it might be an issue.  For
> this reason, we introduced the "rel" parameter in the most recent WebFinger
> draft.  Like HTML, this is a space-separated list of link relation types.
> The idea is that the server will filter based on that list.
>
> If you want to see it in action, you can issue a query against my ID:
> $ curl https://packetizer.com/.well-known/host-meta?\
>                             resource=acct%3Apaulej%40packetizer.com
>
> or
>
> $ curl 'https://packetizer.com/.well-known/host-meta?\
>         resource=acct%3Apaulej%40packetizer.com&\
>         rel=vcard+http%3A%2F%2Fwebfinger.net%2Frel%2Favatar'
>
> The first example returns the entire XRD document.  The second example
> returns only link relations of type vcard or
> http://webfinger.net/rel/avatar.  To get JSON output, just replace host-meta
> with host-meta.json as per RFC 6415 (or use an "Accept" header with
> application/json).
>
> Now, I'm still wondering if a resource descriptor document will ever get so
> large.  It does not return information about a user, just pointers to
> information.  So, do we need "rel"?  If there is definitely only a certain
> set of link relations of interest, it's a way to limit the output.  I
> suppose it does not hurt to introduce it; it's the value I question.  I'd
> definitely like input on the utility.  Given the claims that SWD is simpler
> because of the limited information returned, perhaps that lends to the
> argument that it is useful.
>
> 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

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--Apple-Mail-F38281E2-B3E5-4465-AD06-79E72C8D077C-- --Apple-Mail-E909F96B-9391-4F68-BC62-8C4D65179C01 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6 tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d 5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu 9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8 9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL 3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk 4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTgwNzEzMDNaMCMGCSqGSIb3DQEJBDEWBBSCJBeE rcAGVnvW4ZgOcXDE2BuonDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQBXNqLnzgO6jOFyPGtSm3aUR1ZYt2Osw0bLVPQO Z4BXoqN1qxZ6krLMwxx9VG4Pjgx/ENjX5Bl+l3+l1Re9EoFBSLCxgabb8FkjxtRL93rwR4hgNqaC pg54ZloawXOvzCUocZT6/ZlX5vPTKEnTGXZWEnHmQfuDxl97OGoHim/3RzPbnL/TumgNybdZi7Ss jZ+WQt99sgIPX7V4+sZWyOXIxMTX5YKUOr96pKLdAA1Y6IJVWXqQl959RmWbl3l2B28s5kw8xtLt rrgddGf0JN3CPgCV0/OcvpDHGeHzru0EK2FnEANvSVXaorvFGKf1hKQK1Z9Ktjcp90z8nFyDjKCe AAAAAAAA --Apple-Mail-E909F96B-9391-4F68-BC62-8C4D65179C01-- From stephen.farrell@cs.tcd.ie Wed Apr 18 01:16: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 A892B21F8629 for ; Wed, 18 Apr 2012 01:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI0KUjnGmy6C for ; Wed, 18 Apr 2012 01:15:55 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6697F21F8546 for ; Wed, 18 Apr 2012 01:15:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4E6A5171475; Wed, 18 Apr 2012 09:15:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334736948; bh=2CQwZmIeLJ8CpA Kh464dkDKOTJkHDJr+eUV/sbxMBSY=; b=Mfr0aPeVVLeYu0SC4cwphEBh8nzP4R RvwvTOJWGHRsPMCujsTRpw1giZhPspV8Cv3rLXmYO0mL4X5ZZJ9Rg5jOhyKplCcN Za9frvTtu0tb4w3EgDIvii91Elk2kwiGVCThg1SyfdLWc/wxd6zEa1E0ScwT5ilt pNuU6r3cX+y+3skYVbWTH4jfEwcvKaOddpyI+FtUEajUC77/TiDcpgrhUNABVqxA hbVBH5mrPzd1hqw0+oMFe99S+LQx5UA12m63W4IYnDEImL3bwEAGBs09YhLJhpvK +t7W6hPNpRywPgf/lQrQIMEI+zp8R8c0oTmfUG9w8hxqP/A5G7xs9bfA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 1yUKMHwuQSRl; Wed, 18 Apr 2012 09:15:48 +0100 (IST) Received: from [10.87.48.7] (unknown [86.42.27.239]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 55C2F171473; Wed, 18 Apr 2012 09:15:45 +0100 (IST) Message-ID: <4F8E7827.7010003@cs.tcd.ie> Date: Wed, 18 Apr 2012 09:15:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <04f601cd1cf3$88ab49d0$9a01dd70$@packetizer.com> <4F8E0485.3020105@cs.tcd.ie> <054b01cd1d11$6ba92870$42fb7950$@packetizer.com> In-Reply-To: <054b01cd1d11$6ba92870$42fb7950$@packetizer.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Derek Atkins' , 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 08:16:05 -0000 Hiya, On 04/18/2012 04:14 AM, Paul E. Jones wrote: > Stephen, > >> There's also the question of privacy. Aggregated information is always >> more sensitive. Sets of links, in aggregate, do leak private information. > > Links should never leak private information. But collections of links inherently do leak some information in that they can make correlation of one user's actions over multiple services easier. Those correlations can be subtle, as in e.g. the netflix challenge case where timing information in public data was enough. > WebFinger should provide links > only to information that a user has made publically available or that is > protected in some way. However, we know that some links will reveal more than a user knows or wants for some users. Not that there's much we can do about it of course. > >> If it were the case that webfinger made it noticeably harder to partition >> who knows what about me, then that would be a privacy downside, and not in >> the abstract, but practically. (Not a sure showstopper, but a thing that >> needs attention at least.) > > If your private information was shared, I would agree. I think what you are > saying is that you are concerned with the fact that if you share information > publically in different places (e.g., a photo sharing site, a blog, a file > sharing service, a "profile" page) that bringing together pointers to all of > that in one place is a concern. Well s/concern/concern for some users/ - I don't want to over emphasise this (and experience does seem to show that most people could care less;-) I'm fine with most else of what you say below (no point in quibbling too much too early:-), esp. with the conclusion that whatever is done here needs to take account of privacy issues. I don't know if that would result in some protocol element(s) or just some guidance and warning text, but we shouldn't entirely rule out the former at this point. Cheers, S. > Perhaps, but there are two remedies: > 1) Don't share everything publically > 2) Don't put that information into your account and reported by WebFinger > > As an example of (2), I choose to report certain information from my Google+ > profile page that points to other sites. I'm not so concerned with privacy, > since I know people can find anything via Google, anyway. > > For those concerned with privacy, they ought not do that. Further, if > you're so concerned about privacy, don't share anything that is publically > accessible. > >> However, I've no idea how these are envisaged to be deployed, or are being >> deployed, nor if its (intended to be) easy for a user to create loads of >> different profiles/documents/whatever or not. > > Google+ is perhaps the best example and most complete example currently. > Visit this URL: > http://webfingerclient-dclinton.appspot.com/ > > If you have a gmail address, put in acct:@gmail.com, using your Gmail > ID. This will return a set of link relations pointing to information you > have shared, all of which would be visible from your Google+ profile page. > > If you know your Google+ profile ID, you can use that, too. You can query > mine using this acct URI: acct:103173924987331945891@gmail.com > > I do not share certain information and Google allows me to control what > information I share. > > Within an enterprise environment, I would expect a wider range of contact > information would normally be shared (business mailing address, phone > numbers, email IDs, photo, etc.) The kinds and type of information that > would be shared via WebFinger depends on the service, but it should be > either set by some policy (e.g., corporate IT policies that are similar to > the decisions made for an internal corporate directory) or by the user > (e.g., when setting information public or not in an social networking site). > >> So - do you agree this is an issue, that webfinger aggregates (possibly >> lots of) different pointers related to the same person? > > No, because it does not go out and get information from all over the > Internet. A WebFinger profile shares only information you want shared or as > dictated by IT policy. A general search engine aggregates information from > all over about me and on topics over which I have no control, far more so > than WebFinger would. > >> And, how significant is that and are there ways to mitigate it, for those >> who might care? > > As I said, I think Google+ is a good example to follow. I think that nearly > every piece of information on my profile page I can set to "public" or not. > Only information marked "public" is exposed via WebFinger. > > Any use of WebFinger that shared more than as set by policies or by the user > would be a misuse and should be addressed by the user community of whatever > site of inconsiderate of user privacy. I view this as no different than, > say, Google+ putting up a profile page with my private information for the > public to see. Whether they see the information via a browser or via > WebFinger, I should have control over what's exposed. > >> This aspect is essentially ignored by both swd and webfinger drafts as far >> as I can see, but does seem worse with the latter approach, at least as I >> understand it. (However, for a bit of balance the string "privacy" does >> occur in swd, but the term is misused when "confidentiality" was meant:-) >> >> I do think user privacy is worth consideration regardless of which >> approach is taken ultimately. > > Without using the word "privacy" we do discuss that issue a bit in the > security section. I'd be happy to add additional text or change it. At the > end of the day, though, no standard can dictate privacy issues. We can only > provide guidance and reminders about the importance of privacy, which does > actually vary from person to person. > > Paul > > > From lear@cisco.com Wed Apr 18 03:03: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 E6E1E21F860B; Wed, 18 Apr 2012 03:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.551 X-Spam-Level: X-Spam-Status: No, score=-110.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSjCbAm48qpf; Wed, 18 Apr 2012 03:03:48 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC6021F864C; Wed, 18 Apr 2012 03:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=4101; q=dns/txt; s=iport; t=1334743427; x=1335953027; h=message-id:date:from:mime-version:to:cc:subject; bh=tHyI61e7MkncBQIVdBtxG/96hJaIc363xQ73a47fVxA=; b=HpwJeYW0XWvMAQjhCqvKvay5RTeEp5cWdcMWsWid1MgWiMoMkZFajxVW hdHPFfWwNvgFrm12TkQRD5JuWBBXzBUpQrLimAijAmiVAkkKOCRUc6lqV tl5P30IJ5hn6Zmd+c9gnEUVMcVyUuo/1p6Gi+H2vfddVxtyrjiTak8b87 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD+Qjk+Q/khL/2dsb2JhbABEhWarV4EHgiIBEFUBHxANFgsCCwMCAQIBSwEMAQcBAR6HbQuZWY0QkxqPUIEYBJVvgRGNQIFpgmk X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208,217";a="71155034" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 18 Apr 2012 10:03:46 +0000 Received: from ams3-vpn-dhcp4471.cisco.com (ams3-vpn-dhcp4471.cisco.com [10.61.81.118]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3IA3kt3024445; Wed, 18 Apr 2012 10:03:46 GMT Message-ID: <4F8E9182.5030509@cisco.com> Date: Wed, 18 Apr 2012 12:03:46 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , draft-ietf-ippm-reporting-metrics.all@tools.ietf.org X-Enigmail-Version: 1.4 Content-Type: multipart/alternative; boundary="------------030105070703080107000604" Cc: 'IESG' Subject: [apps-discuss] Apps Directorate Review of draft-ietf-ippm-reporting-metrics-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 10:03:55 -0000 This is a multi-part message in MIME format. --------------030105070703080107000604 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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-ippm-reporting-metrics-08 Title: Reporting Metrics: Different Points of View Reviewer: Eliot Lear Review Date: 18 April 2012 IESG Telechat Date: 18 April 2012 Summary: This document is almost ready for publication. Perhaps also in an academic journal ;-) Minor comments: I think the authors should seriously question the intended status of this document. Is this really a BCP? The normative language, as applied, suggests so. See, for instance: > The minimal report on measurements MUST include both Loss and Delay > Metrics. Alternatively, statements like this one should probably be stated in a more matter-of-fact way, especially since it's rather obvious. One additional comment: this work is EXTREMELY DENSE. It is very well referenced, but there a number of new concepts introduced, nearly begging for separate works. One example is introduction of Type-C, where some additional expansion might be helpful to the reader (like me). Nits: Section 6.1: expand first use of acronyms OWAMP and TWAMP. Eliot --------------030105070703080107000604 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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-ippm-reporting-metrics-08
Title: Reporting Metrics: Different Points of View
Reviewer: Eliot Lear
Review Date: 18 April 2012
IESG Telechat Date: 18 April 2012

Summary:

This document is almost ready for publication.  Perhaps also in an academic journal ;-)

Minor comments:

I think the authors should seriously question the intended status of this document.  Is this really a BCP?  The normative language, as applied, suggests so.  See, for instance:
   The minimal report on measurements MUST include both Loss and Delay
   Metrics.

Alternatively, statements like this one should probably be stated in a more matter-of-fact way, especially since it's rather obvious.

One additional comment: this work is EXTREMELY DENSE.  It is very well referenced, but there a number of new concepts introduced, nearly begging for separate works.  One example is introduction of Type-C, where some additional expansion might be helpful to the reader (like me).

Nits:

Section 6.1: expand first use of acronyms OWAMP and TWAMP.

Eliot
--------------030105070703080107000604-- From melvincarvalho@gmail.com Wed Apr 18 03:05: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 455BB21F8659 for ; Wed, 18 Apr 2012 03:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jT6Lm46OZ0ZB for ; Wed, 18 Apr 2012 03:04:55 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A70A421F864D for ; Wed, 18 Apr 2012 03:04:55 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1036103vcb.31 for ; Wed, 18 Apr 2012 03:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V+VQ3NdVsuq1gtMsMdALul2esPyukyBigEB0HF6CI9g=; b=TJjPBsuBTVFS1ug2pD9LfRmJ8Mf9v51bl4H96GCRIb/QtkOu3ukPWREXmNkQ7tJhnH OWS1S3vmB8GT3kxP8g/dprMJhrOkfoFbg7fb+PrpHoQXii7m4lshCnBqTdEqsnLYlANW xHyJfuUMA4mKaX3mQ/GZ5GsptqvEoOR+k1kxfG5Dmj5SREI7dzQFUUOgeTwsPYZ8vegC B2dKV8+TvKBJNWpwT4YwTa6lPhSB/QdTeXwG5DUm7WzdzTMbCYOeYHTbG7xw3jgaW6/p pYFrsdrgnIeRvnx/YVoH4t+eFcCJhripv6AGuK0uM5p9AR/ZlYgBxSL4FaQ0/tS6Eq2v ycbw== MIME-Version: 1.0 Received: by 10.52.37.102 with SMTP id x6mr676700vdj.72.1334743495167; Wed, 18 Apr 2012 03:04:55 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Wed, 18 Apr 2012 03:04:55 -0700 (PDT) In-Reply-To: <04fb01cd1cf6$23131c80$69395580$@packetizer.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <04fb01cd1cf6$23131c80$69395580$@packetizer.com> Date: Wed, 18 Apr 2012 12:04:55 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf3079bb46e54dea04bdf12f12 Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 10:05:00 -0000 --20cf3079bb46e54dea04bdf12f12 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 18 April 2012 01:59, Paul E. Jones wrote: > Melvin,**** > > ** ** > > On =93acct:=94=85**** > > ** ** > > Humans will usually interchange an acct URI and mailto URI, probably neve= r > using either scheme directly in practice. That=92s natural and expected,= if > not desired. The intent is that we define something that looks like an > email ID, but it=92s not an email ID. Some services, perhaps Twitter bei= ng > most notable, do no use email addresses. Yet, you might have an account > there. So, user@twitter.com might be used by humans and automated > systems would convert that to acct:user@twitter.com. It would not be > appropriate to use mailto: since it=92s not an email ID.**** > > ** ** > > We did have a lot of debate about the use of =93acct=94. If you query my > WebFinger server, you=92ll see that it will work without =93acct:=94 pref= ixed, as > that was a suggestion made a year or so ago. It will inspect the input a= nd > if it looks like an acct URI, it will assume it is. The =93acct=94 URI w= ill be > returned as an alias. However, we should always use some kind of URI > scheme to remove the guesswork. The client can often make a very good > guess as to whether it=92s looking for a user account or something else. = So, > let it tell the server what it is looking for explicitly.**** > > ** ** > > We need a URI scheme, because WebFinger can be used to discover all kinds > of information related to a given domain, not only user information. It > can be used to query information about any URI, be that a web page, a use= r > account, device on the network, etc. If we got rid of =93acct=94, then w= e > would have a system where we sometimes use a URI scheme and sometimes we = do > not. Results might be inconsistent, as the server may not make the right > guess, unless we agreed that absence of a scheme defaults to =93acct:=94. > However, I see no reason for the client to be so lazy to not include > =93acct:=94. The user might (and probably will) exclude it, but the clie= nt > code can add it.**** > > ** ** > > At this point, I=92d argue the =93train has left the station=94 on =93acc= t=94, too. > The current WebFinger spec exists (in part) to formally document that whi= ch > has adopted; it=92s not a new thing. > Paul, thank you for your explanation on lookup based on acct: (WebFinger) vs lookup based on mailto: (SWD). I think this is a major difference. The original WebFinger proposal was *supposed* to give extra information about an email address. >From wikipedia: "WebFinger is an Internet protocol that aims to provide information about people by their* E-mail addresses*." >From webfinger.org: "Put your *email address* into the box above, click the button" >From google code (the top hit on google): "making *email addresses* readable again" And perhaps most importantly from the spec, the first example: "Assume you receive an *email *from Bob..." However only SWD here is doing email based discovery (mailto:). WebFinger *now* doing acct: based discovery, which is a departure from the original use case. Im glad that some people have voiced support for acct:, but I still believe that to be a minority. I agree, that the new acct: scheme should for in another document, rather than shoe horned into an email based discovery system. IMHO, it's better to solve one problem (ie email based discovery) simply and well, than to half solve two problems (ie a new uri scheme for identity) in a single attempt. > **** > > ** ** > > Paul**** > > ** ** > > A couple of points: > > 1. JSON > =3D=3D=3D=3D=3D=3D=3D > > I think at the time webfinger was created in 2009, XML was the de facto > serialization, used in AJAX, SOAP and many other systems. Today I'm > hearing more and more, that both developers and publishers, want to work > with JSON, rather than, having to support both xml and json. Content > negotiation also confuses some publishers. In my view, this is a great > simplification that webfinger can learn from SWD. > > 2. acct: scheme > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The acct: URI scheme has not proved popular, imho, and has added a layer > of complexity and confusion. How do we get from acct: to mailto:? When > should you use acct: and when mailto: (the spec says acct:user@host may > be different from mailto:user@host). What about the forms. How about > linked data ecosystems that want to cross link identifiers, do they now > have to consider both cases? > > From the original post introducing acct: > > "I don=92t expect everyone to like this idea. I wish I could say I love i= t, > but I am simply content with it." > > I dont know of anyone in the community (and correct me if this has > changed) that really loves acct:, or perhaps even likes the acct: idea. > SWD has shown you can do discovery without acct: and I think that's a big > plus. > > > > > One final side note is that this almost becomes trivial when you can do > SPARQL queries. "void" is already registered by the W3C with IANA in > .well-known in order to discover SPARQL endpoints. It may be overkill in > some people's eyes, but Linked Data (which predates webfinger), > particularly newer things like JSON LD, are a lot bigger than they were i= n > 2009. In a few years it may become the definitive discovery mechanism > anyway.**** > --20cf3079bb46e54dea04bdf12f12 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 18 April 2012 01:59, Paul E. Jones <paulej@packeti= zer.com> wrote:

Melvin,

=A0

On =93acct:=94=85

=A0<= /p>

Humans will usually in= terchange an acct URI and mailto URI, probably never using either scheme di= rectly in practice.=A0 That=92s natural and expected, if not desired.=A0 Th= e intent is that we define something that looks like an email ID, but it=92= s not an email ID.=A0 Some services, perhaps Twitter being most notable, do= no use email addresses.=A0 Yet, you might have an account there.=A0 So, user@twitter.com mi= ght be used by humans and automated systems would convert that to acct:user@twitter.com= .=A0 It would not be appropriate to use mailto: since it=92s not an ema= il ID.

=A0<= /p>

We did have a lot of d= ebate about the use of =93acct=94.=A0 If you query my WebFinger server, you= =92ll see that it will work without =93acct:=94 prefixed, as that was a sug= gestion made a year or so ago.=A0 It will inspect the input and if it looks= like an acct URI, it will assume it is.=A0 The =93acct=94 URI will be retu= rned as an alias.=A0 However, we should always use some kind of URI scheme = to remove the guesswork.=A0 The client can often make a very good guess as = to whether it=92s looking for a user account or something else.=A0 So, let = it tell the server what it is looking for explicitly.<= /p>

=A0<= /p>

We need a URI scheme, = because WebFinger can be used to discover all kinds of information related = to a given domain, not only user information.=A0 It can be used to query in= formation about any URI, be that a web page, a user account, device on the = network, etc.=A0 If we got rid of =93acct=94, then we would have a system w= here we sometimes use a URI scheme and sometimes we do not.=A0 Results migh= t be inconsistent, as the server may not make the right guess, unless we ag= reed that absence of a scheme defaults to =93acct:=94.=A0 However, I see no= reason for the client to be so lazy to not include =93acct:=94.=A0 The use= r might (and probably will) exclude it, but the client code can add it.<= /u>

=A0<= /p>

At this point, I=92d a= rgue the =93train has left the station=94 on =93acct=94, too.=A0 The curren= t WebFinger spec exists (in part) to formally document that which has adopt= ed; it=92s not a new thing.



Paul, thank you for your explanation = on lookup based on acct: (WebFinger) vs lookup based on mailto: (SWD).
<= br>I think this is a major difference.

The original WebFinger propos= al was *supposed* to give extra information about an email address.

From wikipedia:

"WebFing= er is an Internet protocol that aims to provide information about people by= their E-mail addresses."

From webfinger.org:

"P= ut your email address into the box above, click the button"

From google code (the top hit on google):

"making email addresses readable again"= ;

And perhaps most importantly from the spec, the first example:

<= span style=3D"color:rgb(0,0,153)">"Assume you receive an email = from Bob..."

However only SWD here is doing email based = discovery (mailto:).=A0 WebFinger *now* doing acct: based discovery, which = is a departure from the original use case.=A0

Im glad that some people have voiced support for acct:, but I still bel= ieve that to be a minority.=A0 I agree, that the new acct: scheme should fo= r in another document, rather than shoe horned into an email based discover= y system.=A0

IMHO, it's better to solve one problem (ie email based discovery) s= imply and well, than to half solve two problems (ie a new uri scheme for id= entity) in a single attempt.=A0
=A0

=A0

Paul

=A0

A couple of points:

1. JSON
=3D=3D=3D=3D= =3D=3D=3D

I think at the time webfinger was created in 2009, XML was= the de facto serialization, used in AJAX, SOAP and many other systems.=A0 = Today I'm hearing more and more, that both developers and publishers, w= ant to work with JSON, rather than, having to support both xml and json.=A0= Content negotiation also confuses some publishers.=A0 In my view, this is = a great simplification that webfinger can learn from SWD.

2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The a= cct: URI scheme has not proved popular, imho, and has added a layer of comp= lexity and confusion.=A0 How do we get from acct: to mailto:?=A0 When shoul= d you use acct: and when mailto: (the spec says acct:user@host may be diffe= rent from mailto:user@host).=A0 What about the forms.=A0 How about linked data ecosystems that want= to cross link identifiers, do they now have to consider both cases?=A0
From the original post introducing acct:

"I don=92t expect = everyone to like this idea. I wish I could say I love it, but I am simply c= ontent with it."

I dont know of anyone in the community (and co= rrect me if this has changed) that really loves acct:, or perhaps even like= s the acct: idea.=A0 SWD has shown you can do discovery without acct: and I= think that's a big plus.




One final side note is that this almost becomes trivial whe= n you can do SPARQL queries.=A0 "void" is already registered by t= he W3C with IANA in .well-known in order to discover SPARQL endpoints.=A0 I= t may be overkill in some people's eyes, but Linked Data (which predate= s webfinger), particularly newer things like JSON LD, are a lot bigger than= they were in 2009.=A0 In a few years it may become the definitive discover= y mechanism anyway.


--20cf3079bb46e54dea04bdf12f12-- From derek@ihtfp.com Wed Apr 18 06:47: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 21D4621F8533 for ; Wed, 18 Apr 2012 06:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.962 X-Spam-Level: X-Spam-Status: No, score=-101.962 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCsS+LhMptvz for ; Wed, 18 Apr 2012 06:46:58 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id C69B621F8531 for ; Wed, 18 Apr 2012 06:46:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id DDE152602A5; Wed, 18 Apr 2012 09:46:57 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 28578-06; Wed, 18 Apr 2012 09:46:52 -0400 (EDT) Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 466032600BB; Wed, 18 Apr 2012 09:46:52 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3IDknwP018688; Wed, 18 Apr 2012 09:46:49 -0400 From: Derek Atkins To: John Bradley References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <04f601cd1cf3$88ab49d0$9a01dd70$@packetizer.com> <4F8E0485.3020105@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE8AC@P3PWEX2MB008.ex2.secureserver.net> <56D28A27-11A8-48C4-A49E-492EC02B7918@ve7jtb.com> Date: Wed, 18 Apr 2012 09:46:48 -0400 In-Reply-To: <56D28A27-11A8-48C4-A49E-492EC02B7918@ve7jtb.com> (John Bradley's message of "Wed, 18 Apr 2012 09:13:01 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a X-Mailman-Approved-At: Wed, 18 Apr 2012 08:08:37 -0700 Cc: Derek Atkins , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 13:47:03 -0000 John Bradley writes: > I don't think there is any disagreement that without authenticating the > requester, both are dealing with public info. The only slight diffrence is > that SWD forces the requester to make multiple requests to get the whole > document. The downside to SWD is that it requires a requester to make > multiple requests to find multiple services. Right. > Once we add authenticated access there are likely differing opinions on what > mechinisim is easier to deploy. I issue I would see is how you authorize access to parts of the WF document? How do you specify which resource links are available to which requestors? I don't have an answer to that. I do think SWD might be easier to deploy in a CRUD fashion.. But maybe there's a way to get the best of both worlds, use something crudlike to control the resources, but a master "index" to get the whole document (er, partial document to which you are authorized)? > From a openID connect perspective anything requiring XML parsing is going to > be a non starter. I feel this can be solved by an Accepts header, and suggesting the server implement both XML and JSON. The client can then request whichever format it wants. > The irony of me saying that is not lost on me:) Indeed. :) Especially since this same mechanism request came up in OAUTH and people didn't want it there for some reason. > John B. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From dick.hardt@gmail.com Tue Apr 17 09:49: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 76AF711E8074 for ; Tue, 17 Apr 2012 09:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABfbqZXuKSZ3 for ; Tue, 17 Apr 2012 09:49:57 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id BA98421F8437 for ; Tue, 17 Apr 2012 09:49:57 -0700 (PDT) Received: by dady13 with SMTP id y13so11927623dad.27 for ; Tue, 17 Apr 2012 09:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=bhAnDY5lHdI6I6PY9v4T1KWgZDGL3b6SRSlZMMNci8c=; b=WOPj4SO1EOt6etrvidK6T0L3yMjYeElKxJOla5OUXxl83Fszt2Ff7dQYVK47gB66zk KBs67Zw+Susyi3BG+ptMA8gEMMj9RzL1UeUY+0EPZHXYb6I+lz1hOeA2irpPH+zMvT2I 9GwMlmK45bY8DaVJ8wJST+2DTj7nfFmHlpc6DwEoANTWShdIn+r7zAdKDdt/RKaUOA55 haoO0varpPTS4asfMEWwnxpc7ovAlYHwoULXY3G5mEli6lUV+XajC3/OX1h0bWItegkY xNhD95o7xa/U1/khjZiXUsSFKzjpgrYIrOY2XZ7J9cpLZO9EkAA/pwiFYxGvbH2ygNQD PJ+A== Received: by 10.68.200.162 with SMTP id jt2mr37392290pbc.54.1334681397545; Tue, 17 Apr 2012 09:49:57 -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 it8sm5040425pbc.56.2012.04.17.09.49.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 09:49:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_EA40CF75-8739-4B65-862D-45E3BF551821" From: Dick Hardt In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> Date: Tue, 17 Apr 2012 09:49:53 -0700 Message-Id: <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> To: Eran Hammer X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Wed, 18 Apr 2012 08:08:49 -0700 Cc: Ned Freed , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss , Mark Nottingham , Pete Resnick Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 16:49:58 -0000 --Apple-Mail=_EA40CF75-8739-4B65-862D-45E3BF551821 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote: >> (Sticking with the naivety:-) So, what's different there from how the = base >> oauth draft registers client_id and shows how that can be used in a = GET >> request? [1] >=20 > Big difference. The base draft specifies its own endpoints as part of = a complete API package for obtaining authorization. These parameters are = scoped only for the endpoints defined and not for any others. There is = no possibility of conflict because the specification defines the entire = namespace. >=20 > OTOH, the bearer spec is applied to *any* web resources using OAuth = authentication where some other namespace definition must exist. If we had kept it all in one spec as it had originally been drafted, = this would not be an issue, and it would be easier for implementers to = understand. I don't know of anyone looking to implement the bearer spec = independent of the base spec. (would be interested if anyone does know = of an implementation) --Apple-Mail=_EA40CF75-8739-4B65-862D-45E3BF551821 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
(Sticking with the naivety:-) So, = what's different there from how the base
oauth draft registers client_id and shows how that can be = used in a GET
request? = [1]

Big difference. The base draft specifies its own = endpoints as part of a complete API package for obtaining authorization. = These parameters are scoped only for the endpoints defined and not for = any others. There is no possibility of conflict because the = specification defines the entire namespace.

OTOH, the bearer spec = is applied to *any* web resources using OAuth authentication where some = other namespace definition must = exist.


If we had = kept it all in one spec as it had originally been drafted, this would = not be an issue, and it would be easier for implementers to understand. = I don't know of anyone looking to implement the bearer spec independent = of the base spec. (would be interested if anyone does know of an = implementation)

= --Apple-Mail=_EA40CF75-8739-4B65-862D-45E3BF551821-- From dick.hardt@gmail.com Tue Apr 17 09:53:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD1111E8074 for ; Tue, 17 Apr 2012 09:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bOXp-o6n5Xs for ; Tue, 17 Apr 2012 09:53:01 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 973EF21F8456 for ; Tue, 17 Apr 2012 09:53:01 -0700 (PDT) Received: by dady13 with SMTP id y13so11931790dad.27 for ; Tue, 17 Apr 2012 09:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=N8PzfmKMpUwWreFH/kXES1XAqQquOIb/5prxp+zJCWo=; b=qv/qbNJ2A6AKRzqXaj7Mhzv/Tjns4Ki/Mu1BplS33KvUr+qiZ6IsrGvtIitau2l1bb DE3NfRxo8RrbA5lpSAMcYYRww0ytAlbzyGtH2OVWi9KTdL2/ZQGDoM5x4RYrccozTH2F lQXh+OL/c82sihRetTfBEXbmZDeCGjnTfD55na4fGXa8m0J8junNT9yFxB/c9pcwgant rf/iujt1FNLaG7ORNI5FsR3kwobnhWEykcKDXSSWMyIfHCFbZnIml1+9a2KdT4B+xXh4 QcIWbzAeMiKXBznKV4sT7l2m6s7kd02tn3Qxs8YpEAiUgLM2BQPv2dtizhfP6e/QFq8d GE8w== Received: by 10.68.138.195 with SMTP id qs3mr8753590pbb.91.1334681581441; Tue, 17 Apr 2012 09:53:01 -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 ge1sm15314798pbc.0.2012.04.17.09.52.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 09:53:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_C8C63196-85AD-4D1B-BE2B-7DBB2E0A80D5" From: Dick Hardt In-Reply-To: <1334590326.6719.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Tue, 17 Apr 2012 09:52:57 -0700 Message-Id: <13465EB8-9372-4A2D-8A98-C7B38AA73D13@gmail.com> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <1334590326.6719.YahooMailNeo@web31807.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Wed, 18 Apr 2012 08:09:00 -0700 Cc: Ned Freed , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss , Mark Nottingham , Pete Resnick , Derek Atkins Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 16:53:02 -0000 --Apple-Mail=_C8C63196-85AD-4D1B-BE2B-7DBB2E0A80D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 16, 2012, at 8:32 AM, William Mills wrote: >=20 > A big problem, in my opinion, is that credentials will end up in the = browser history cache when they are included in the URL. This is = significant. Unless an explicit user "sign out" in the browser = invalidates all tokens issued to the browser (this is a significant = revocation requirement and revocations isn't properly solved yet) then = someone sitting down at the machine can recover a credential by looking = in the history. >=20 > Note that enterprise edge proxies that are doing SSL termination may = well see this, but that could be considered "their problem". I have = seen apparent evidence of large companies using egress proxies that = terminate all SSL outbound at their proxy (depressingly evil), and they = frequently get stuff wrong in terms of proxy settings. Bill: to address this issue, an implementation can issue short lived = access_tokens which are refreshed with refresh_tokens. The refresh_token = -> access_token exchange could be server to server and optionally as a = header parameter so that it has stronger protection. -- Dick --Apple-Mail=_C8C63196-85AD-4D1B-BE2B-7DBB2E0A80D5 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Apr 16, 2012, at 8:32 AM, William Mills wrote:


A big problem, in my opinion, is that credentials will end up in the browser history cache when they are included in the URL.  This is significant.  Unless an explicit user "sign out" in the browser invalidates all tokens issued to the browser (this is a significant revocation requirement and revocations isn't properly solved yet) then someone sitting down at the machine can recover a credential by looking in the history.

Note that enterprise edge proxies that are doing SSL termination may well see this, but that could be considered "their problem".  I have seen apparent evidence of large companies using egress proxies that terminate all SSL outbound at their proxy (depressingly evil), and they frequently get stuff wrong in terms of proxy settings.

Bill: to address this issue, an implementation can issue short lived access_tokens which are refreshed with refresh_tokens. The refresh_token -> access_token exchange could be server to server and optionally as a header parameter so that it has stronger protection.

-- Dick

--Apple-Mail=_C8C63196-85AD-4D1B-BE2B-7DBB2E0A80D5-- From dick.hardt@gmail.com Tue Apr 17 12:31: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 7BDD911E80D0 for ; Tue, 17 Apr 2012 12:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFNGSCRUeUsI for ; Tue, 17 Apr 2012 12:31:40 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id CE6BD11E80CD for ; Tue, 17 Apr 2012 12:31:40 -0700 (PDT) Received: by dady13 with SMTP id y13so12163330dad.27 for ; Tue, 17 Apr 2012 12:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=RnfyZfRhd3G5/35ycz6L0HWhh1FZK7rHrcG93zqQ994=; b=jEfW49Hm8IB05Rc9iXbDGyoJPNBzUnUQn7Kqn8xBKdMw/tFSPON2HpsQpw6SYzpZ1X ew6iK80FJZkDHW71F91KKfn1MbxOyBxYG6SU+oNdg7ggoqiwpGsa6+nLVFqs+fGSkULx ETwaxlI2Y1i6Qv6AmrARqqterVqdPSVYCTk8u67e4ET7Bqr/ExAI2FpSl80JZ26WUsjM UgV1SWdbS+wsnynRRI8zzNpxRLilzRKStitNyJRho3ukEyEtFaQsZSqjFwC2S8IZBlW6 TmtvdTJiBbYmKY+6cx9hC8zWeUKcawnWTk58PhNvVr2TBE6NhSrB+7SPvb34XjLyKbKl 4m+g== Received: by 10.68.221.74 with SMTP id qc10mr38538332pbc.80.1334691100456; Tue, 17 Apr 2012 12:31:40 -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 d6sm21474459pbi.23.2012.04.17.12.31.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 12:31:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_1C7B89E6-D572-4511-8453-3326ADAA08CB" From: Dick Hardt In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0@P3PWEX2MB008.ex2.secureserver.net> Date: Tue, 17 Apr 2012 12:31:35 -0700 Message-Id: <5837DDA7-19DC-4452-BD47-FFF6C674E179@gmail.com> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0@P3PWEX2MB008.ex2.secureserver.net> To: Eran Hammer X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Wed, 18 Apr 2012 08:09:12 -0700 Cc: Ned Freed , Apps Discuss , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Mark Nottingham , Pete Resnick , Dick Hardt Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 19:31:41 -0000 --Apple-Mail=_1C7B89E6-D572-4511-8453-3326ADAA08CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please elaborate on what the issue is then as protecting API resources = is what OAuth is all about.=20 On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote: > That has nothing to do with this issue. The protected resources API = format was never part of OAuth at any time. > =20 > EH > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Tuesday, April 17, 2012 9:50 AM > To: Eran Hammer > Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; = draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss > Subject: Re: [apps-discuss] Reserved URI query parameter in = draft-ietf-oauth-v2-bearer > =20 > =20 > On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote: >=20 >=20 > (Sticking with the naivety:-) So, what's different there from how the = base > oauth draft registers client_id and shows how that can be used in a = GET > request? [1] >=20 > Big difference. The base draft specifies its own endpoints as part of = a complete API package for obtaining authorization. These parameters are = scoped only for the endpoints defined and not for any others. There is = no possibility of conflict because the specification defines the entire = namespace. >=20 > OTOH, the bearer spec is applied to *any* web resources using OAuth = authentication where some other namespace definition must exist. > =20 > =20 > If we had kept it all in one spec as it had originally been drafted, = this would not be an issue, and it would be easier for implementers to = understand. I don't know of anyone looking to implement the bearer spec = independent of the base spec. (would be interested if anyone does know = of an implementation) --Apple-Mail=_1C7B89E6-D572-4511-8453-3326ADAA08CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Please elaborate on what the issue is then as = protecting API resources is what OAuth is all = about. 

On Apr 17, 2012, at 12:19 PM, Eran = Hammer wrote:

, apps-discuss@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Apr 2012 22:54:23 -0000 --bcaec554055e80079404bde7d18d Content-Type: text/plain; charset=UTF-8 That's a tricky question - maybe one google can help answer? There are a bunch of projects using webfinger, including status.net, ostatus in general, diaspora, unhosted, freedombox(?), and I'm sure others, but I have no idea how that translates into actual users or profiles. Gmail, aol, and yahoo all put up webfinger endpoints, but there hasn't been much movement, I think due to the chicken and egg nature of adoption around decentralized tools. b. On Apr 17, 2012 11:13 AM, "Tim Bray" wrote: > What is the deployment status of these two specs? Is either deployed > much at all? -T > > On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy > wrote: > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org [mailto: > apps-discuss-bounces@ietf.org] On Behalf Of Stephen Farrell > >> Sent: Friday, April 13, 2012 9:23 AM > >> To: oauth@ietf.org WG > >> Cc: Apps Discuss > >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > Discovery (SWD) > >> > >> So Hannes and Derek and I have been discussing this with the Apps ADs > >> and Apps-area WG chairs. I've also read the docs now, and after all > >> that we've decided that this topic (what to do with swd and webfinger) > >> is best handled in the apps area and not in the oauth WG. > >> > >> The logic for that is that 1) the two proposals are doing the same > >> thing and we don't want two different standards for that, b) this is > >> not an oauth-specific thing nor is it a general security thing, and c) > >> there is clearly already interest in the topic in the apps area so its > >> reasonable for the oauth wg to use that when its ready. > >> > >> The appsawg chairs and apps ADs are ok with the work being done there. > >> > >> So:- > >> > >> - I've asked the oauth chairs to take doing work on swd > >> out of the proposed new charter > >> - It may be that you want to add something saying that > >> oauth will use the results of work in the applications > >> area on a web discovery protocol as a basis for doing > >> the dynamic client registration work here > >> - Discussion of webfinger and swd should move over to > >> the apps-discuss list > >> - Note: this is not picking one or the other approach, > >> the plan is that the apps area will do any selection > >> needed and figure out the best starting point for a > >> standards-track RFC on web discovery and we'll use their > >> fine work for doing more with oauth. > > > > Thank you Stephen, I think. :-) > > > > So the discussion on apps-discuss now should be focused on which of the > two should be the basis for forward progress. I've placed both documents > in "Call for Adoption" state in the datatracker for appsawg. > > > > Let the games begin. > > > > -MSK > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --bcaec554055e80079404bde7d18d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That's a tricky question - maybe one google can help answer? There a= re a bunch of projects using webfinger, including status.net, ostatus in general, diaspora, unhosted, freedombox(?),= and I'm sure others, but I have no idea how that translates into actua= l users or profiles.

Gmail, aol, and yahoo all put up webfinger endpoints, but there hasn'= ;t been much movement, I think due to the chicken and egg nature of adoptio= n around decentralized tools.

b.

On Apr 17, 2012 11:13 AM, "Tim Bray" &= lt;tbray@textuali= ty.com> wrote:
msk@cloudmark.com> wrote:
>> -----Original Message-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]= On Behalf Of Stephen Farrell
>> Sent: Friday, April 13, 2012 9:23 AM
>> To: oauth@ietf= .org WG
>> Cc: Apps Discuss
>> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web D= iscovery (SWD)
>>
>> So Hannes and Derek and I have been discussing this with the Apps = ADs
>> and Apps-area WG chairs. I've also read the docs now, and afte= r all
>> that we've decided that this topic (what to do with swd and we= bfinger)
>> is best handled in the apps area and not in the oauth WG.
>>
>> The logic for that is that 1) the two proposals are doing the same=
>> thing and we don't want two different standards for that, b) t= his is
>> not an oauth-specific thing nor is it a general security thing, an= d c)
>> there is clearly already interest in the topic in the apps area so= its
>> reasonable for the oauth wg to use that when its ready.
>>
>> The appsawg chairs and apps ADs are ok with the work being done th= ere.
>>
>> So:-
>>
>> - I've asked the oauth chairs to take doing work on swd
>> =C2=A0 out of the proposed new charter
>> - It may be that you want to add something saying that
>> =C2=A0 oauth will use the results of work in the applications
>> =C2=A0 area on a web discovery protocol as a basis for doing
>> =C2=A0 the dynamic client registration work here
>> - Discussion of webfinger and swd should move over to
>> =C2=A0 the apps-discuss list
>> - Note: this is not picking one or the other approach,
>> =C2=A0 the plan is that the apps area will do any selection
>> =C2=A0 needed and figure out the best starting point for a
>> =C2=A0 standards-track RFC on web discovery and we'll use thei= r
>> =C2=A0 fine work for doing more with oauth.
>
> Thank you Stephen, I think. =C2=A0:-)
>
> So the discussion on apps-discuss now should be focused on which of th= e two should be the basis for forward progress. =C2=A0I've placed both = documents in "Call for Adoption" state in the datatracker for app= sawg.
>
> Let the games begin.
>
> -MSK
> _______________________________________________
> apps-discuss mailing list
> apps-discus= s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--bcaec554055e80079404bde7d18d-- From wmills@yahoo-inc.com Wed Apr 18 08: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 A6FED21F8534 for ; Wed, 18 Apr 2012 08:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.301 X-Spam-Level: X-Spam-Status: No, score=-17.301 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK8OUMv-2OcW for ; Wed, 18 Apr 2012 08:50:14 -0700 (PDT) Received: from nm18-vm0.bullet.mail.ac4.yahoo.com (nm18-vm0.bullet.mail.ac4.yahoo.com [98.139.53.210]) by ietfa.amsl.com (Postfix) with SMTP id E32F021F85BD for ; Wed, 18 Apr 2012 08:50:13 -0700 (PDT) Received: from [98.139.52.194] by nm18.bullet.mail.ac4.yahoo.com with NNFMP; 18 Apr 2012 15:50:10 -0000 Received: from [98.139.52.158] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 18 Apr 2012 15:50:10 -0000 Received: from [127.0.0.1] by omp1041.mail.ac4.yahoo.com with NNFMP; 18 Apr 2012 15:50:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 24512.44712.bm@omp1041.mail.ac4.yahoo.com Received: (qmail 24154 invoked by uid 60001); 18 Apr 2012 15:50:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334764209; bh=6q/FOgG2qAAwPpMI90BEyQrGh/ZgnDhoFG4QDsQAqcA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=G3QoFA6/vosa0ae3qYbukAk8mUdHzk3inPwIi2mgRmW6awMpYOBdZgCoNqNfl/oJUD1LwaALI0kvvf/c+J+st4TX4H9e9Jd6iX+h7wty8g7k2eNPByVLF7su68HO3slaf4xIf5Akv+m5fitp4kFqHby7z0oUYowxDkCzmq6RIXk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IhMkSmd29jRU3GJaboAaH725aQbWABpVHMDLK769yZlfHEcDEXtToTITTSl5emS0IjI8WYqeso9JV1cVDLjQdwHTC02Z6k/uKL+ClCJ6UseDMxYEODaaG8YrN+7Gn5Yng9i5Rp2X/mYAT8jxJajitrnLpApLrLpo5QayezAjhS8=; X-YMail-OSG: VyHGl4QVM1mk1umyaYWXyJ9iglvmB1J2ucmu_fqTGA27Fhr TTLDOncebjkTo5yvheUYX_u.Bbcx8GPvZjGJEfcebV9jJBF.lMB7EQybOn.K iIcebdPyJkLwaXx8NSk5J86EbNjOTdt67scORf.S.DN9BwFuvyGBqedVFGUz xlFXO6nJ4YhGQzED.NvurYEk30nDA1F1kblUBHuID8w8UqjhzpCos7kdVtKx 4KbkcKcWNLi_dRL5QdOOuQGStBAKuIN5TcEWuS1A.22St6_Tfdho0RM7Tvri 8dwKFbqcYTcRFlIMGemDq1rFoAcspwdkxOLEmdVp7onlZ0gfJ_wBrPGuA_tB jYPUB_jXg_xbG4tPu_psKOCwQVn2wquI1jEp9f00IeUlRawtUbMnBVUxGn5Q ixVrsZ6AhVs1j6oU1P2JZgcgYbHDWZJsewr64k70Hn3Qk_O3WIeQW Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Wed, 18 Apr 2012 08:50:09 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0@P3PWEX2MB008.ex2.secureserver.net> <5837DDA7-19DC-4452-BD47-FFF6C674E179@gmail.com> Message-ID: <1334764209.89788.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Wed, 18 Apr 2012 08:50:09 -0700 (PDT) From: William Mills To: Dick Hardt , Eran Hammer In-Reply-To: <5837DDA7-19DC-4452-BD47-FFF6C674E179@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-1644767845-1334764209=:89788" Cc: Pete Resnick , Mark Nottingham , Ned Freed , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 15:50:18 -0000 --767760015-1644767845-1334764209=:89788 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OAuth 2.0 is different from 1.0(and a) in that it's an auth framework that = deals with getting the tokens, but leaves the use of them to the companion = specs.=A0 I think this is what Eran is driving at, in the purest semantic s= ense.=A0 The OAuth 2.0 API doesn't deal with protected resources at all tho= ugh, and the discussion about query parameters is all about the protected r= esource.=0A=0A=0A=0A=0A=0A=0A>________________________________=0A> From: Di= ck Hardt =0A>To: Eran Hammer = =0A>Cc: Ned Freed ; Apps Discuss ; "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" ; Mark Nottingham ; Pete Resnick <= presnick@qualcomm.com>; Dick Hardt =0A>Sent: Tuesday= , April 17, 2012 12:31 PM=0A>Subject: Re: [apps-discuss] Reserved URI query= parameter in draft-ietf-oauth-v2-bearer=0A> =0A>=0A>Please elaborate on wh= at the issue is then as protecting API resources is what OAuth is all about= .=A0=0A>=0A>=0A>On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote:=0A>=0A>Tha= t has nothing to do with this issue. The protected resources API format was= never part of OAuth at any time.=0A>>=A0=0A>>EH=0A>>=A0=0A>>From:=A0Dick H= ardt [mailto:dick.hardt@gmail.com]=A0=0A>>Sent:=A0Tuesday, April 17, 2012 9= :50 AM=0A>>To:=A0Eran Hammer=0A>>Cc:=A0Stephen Farrell; Mark Nottingham; Pe= te Resnick; Ned Freed;=A0draft-ietf-oauth-v2-bearer.all@tools.ietf.org; App= s Discuss=0A>>Subject:=A0Re: [apps-discuss] Reserved URI query parameter in= draft-ietf-oauth-v2-bearer=0A>>=A0=0A>>=A0=0A>>On Apr 14, 2012, at 11:31 P= M, Eran Hammer wrote:=0A>>=0A>>=0A>>=0A>>(Sticking with the naivety:-) So, = what's different there from how the base=0A>>oauth draft registers client_i= d and shows how that can be used in a GET=0A>>request? [1]=0A>>=0A>>Big dif= ference. The base draft specifies its own endpoints as part of a complete A= PI package for obtaining authorization. These parameters are scoped only fo= r the endpoints defined and not for any others. There is no possibility of = conflict because the specification defines the entire namespace.=0A>>=0A>>O= TOH, the bearer spec is applied to *any* web resources using OAuth authenti= cation where some other namespace definition must exist.=0A>>=A0=0A>>=A0=0A= >>If we had kept it all in one spec as it had originally been drafted, this= would not be an issue, and it would be easier for implementers to understa= nd. I don't know of anyone looking to implement the bearer spec independent= of the base spec. (would be interested if anyone does know of an implement= ation)=0A>=0A>_______________________________________________=0A>apps-discu= ss mailing list=0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/li= stinfo/apps-discuss=0A>=0A>=0A> --767760015-1644767845-1334764209=:89788 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OAuth 2.0 is different from 1.0(and a) in that it's an auth framework tha= t deals with getting the tokens, but leaves the use of them to the companio= n specs.  I think this is what Eran is driving at, in the purest seman= tic sense.  The OAuth 2.0 API doesn't deal with protected resources at= all though, and the discussion about query parameters is all about the pro= tected resource.


From: Dick Ha= rdt <dick.hardt@gmail.com>
= To: Eran Hammer <eran@hueniverse.com>
Cc: Ned Freed <ned.freed@mrochek.com&= gt;; Apps Discuss <apps-discuss@ietf.org>; "draft-ietf-oauth-v2-beare= r.all@tools.ietf.org" <draft-ietf-oauth-v2-bearer.all@tools.ietf.org>= ; Mark Nottingham <mnot@mnot.net>; Pete Resnick <presnick@qualcomm= .com>; Dick Hardt <dick.hardt@gmail.com>
Sent: Tuesday, April 17, 2012 12:31 PM
= Subject: Re: [apps-discuss] R= eserved URI query parameter in draft-ietf-oauth-v2-bearer
=0A
Please elaborate on what the i= ssue is then as protecting API resources is what OAuth is all about. <= div>

On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote:
That has= nothing to do with this issue. The protected resources API format was neve= r part of OAuth at any time.
 
EH
 
= From: Dick Hardt [mailt= o:dick.hardt@gmail.com]&n= bsp;
Sent: Tuesday, April 17, 2012 9:50 AM
To: Eran Hammer
Cc: Stephen Farrel= l; Mark Nottingham; Pete Resnick; Ned Freed; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discus= s
Subject: = ;Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth= -v2-bearer
 
 
On Apr 14, 2012, at= 11:31 PM, Eran Hammer wrote:


(Sticking with the naivety:-) So, wh= at's different there from how the base
oauth draft registers client_id and shows how that can be used in a= GET
request? [1]

Big difference. The base draft speci= fies its own endpoints as part of a complete API package for obtaining auth= orization. These parameters are scoped only for the endpoints defined and n= ot for any others. There is no possibility of conflict because the specific= ation defines the entire namespace.

OTOH, the bearer spec is applied= to *any* web resources using OAuth authentication where some other namespa= ce definition must exist.
 
 
If we had kept it all in one spec as it had original= ly been drafted, this would not be an issue, and it would be easier for imp= lementers to understand. I don't know of anyone looking to implement the be= arer spec independent of the base spec. (would be interested if anyone does= know of an implementation)
=


________________________= _______________________
apps-discuss mailing list
apps-discuss@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/apps-discuss


--767760015-1644767845-1334764209=:89788-- From jpanzer@google.com Wed Apr 18 08:59: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 6919B21F85C3 for ; Wed, 18 Apr 2012 08:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.909 X-Spam-Level: X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YTb-GUrz3NN for ; Wed, 18 Apr 2012 08:59:08 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2854521F85BD for ; Wed, 18 Apr 2012 08:59:07 -0700 (PDT) Received: by qaea16 with SMTP id a16so531504qae.10 for ; Wed, 18 Apr 2012 08:59:07 -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=xFKDGPCwK5N+xNJhS76eQv+/htoMe0enR5SDB19Lw90=; b=imuBQiAk0lUqZWhCNU4JKSdlkWJ3TZmDkdAN9qCuyHZFClEcWw1XEV2iHjYE+JIGhy tFresw26loHdymNUkMa42OnO74nPrQIOEkhO2I/9kibol3CyuTEktd7PfKSlH3jFKoqh toNkXlGFiPEowI554ws9YjKG7vZcNcnV6qdzdrDhyXkc73C/ZMx7MbylCvOiVW/2Thp4 NpZTIb5YloGBfbQOZeYENuXhVz0BY2qmXVPLQ75j4sJYcL42Nhr1cx5MYADTO5/DYbV2 rM08sV+u3GQqIgDht91ViR6jkJhuO9hYejqKTANtn/zyHtU85Fqy1wZb/3bFoV1BaS6k 4pJQ== 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=xFKDGPCwK5N+xNJhS76eQv+/htoMe0enR5SDB19Lw90=; b=nPmObD0kb7PZb60CYqL/pIIf0jEN7IX+dgjgv5JUrloG0C1VXgAnFvrZ8Uxach16Y9 fsdVbYmRIlaeno6FEH3TOR9Qx2BZk3rUdMEHsgZ/wyY9CYATqdaBbNz1trs5U+2XEzdD yZZcTAMLFYByT44NXdNl38BzY6sJPO8DjY3u+2SPBPBbZrHN2TR9wxSG4tHwdwk5mFk2 M3H52MZjanRH8K39N90PXjKapiH/lZwyHaVwaSg+MR3CGpRhZ1k6nuuHHoJXnFoCZ914 pISoafnmVab1+4njgwzZ2oWb1dlwDmp+EwHUXMzn43pOj+VOhEitpNkDMke/31Ha6kNd g0IQ== Received: by 10.224.187.210 with SMTP id cx18mr4366707qab.45.1334764747464; Wed, 18 Apr 2012 08:59:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.187.210 with SMTP id cx18mr4366693qab.45.1334764747302; Wed, 18 Apr 2012 08:59:07 -0700 (PDT) Received: by 10.229.22.133 with HTTP; Wed, 18 Apr 2012 08:59:07 -0700 (PDT) Received: by 10.229.22.133 with HTTP; Wed, 18 Apr 2012 08:59:07 -0700 (PDT) In-Reply-To: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <04fb01cd1cf6$23131c80$69395580$@packetizer.com> Date: Wed, 18 Apr 2012 08:59:07 -0700 Message-ID: From: John Panzer To: Melvin Carvalho Content-Type: multipart/alternative; boundary=485b397dd4bb9f276c04bdf62201 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk1Lo7cIvlEmusW8w0IdLa9DLW6bJ7iyDnxXR9jngrNUwTXhjE7kOUPFjKKmAX2CWbJoIKPYwNRVTwSLcjh94/9lfEH47XQZ/bY58hP7r9/8MZ4nZv6DS2Tizel+/r6z2C+NiYyxG+hjr1QPMLR3i/rougy+g== Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 15:59:12 -0000 --485b397dd4bb9f276c04bdf62201 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Last time I looked, WF takes a URI as input. A mailto: URI is a URI. If someone wants to provide a look up by email address service, WF works fine. It just accepts more than email addresses. What am I missing? On Apr 18, 2012 3:05 AM, "Melvin Carvalho" wrote= : > > > On 18 April 2012 01:59, Paul E. Jones wrote: > >> Melvin,**** >> >> ** ** >> >> On =93acct:=94=85**** >> >> ** ** >> >> Humans will usually interchange an acct URI and mailto URI, probably >> never using either scheme directly in practice. That=92s natural and >> expected, if not desired. The intent is that we define something that >> looks like an email ID, but it=92s not an email ID. Some services, perh= aps >> Twitter being most notable, do no use email addresses. Yet, you might h= ave >> an account there. So, user@twitter.com might be used by humans and >> automated systems would convert that to acct:user@twitter.com. It would >> not be appropriate to use mailto: since it=92s not an email ID.**** >> >> ** ** >> >> We did have a lot of debate about the use of =93acct=94. If you query m= y >> WebFinger server, you=92ll see that it will work without =93acct:=94 pre= fixed, as >> that was a suggestion made a year or so ago. It will inspect the input = and >> if it looks like an acct URI, it will assume it is. The =93acct=94 URI = will be >> returned as an alias. However, we should always use some kind of URI >> scheme to remove the guesswork. The client can often make a very good >> guess as to whether it=92s looking for a user account or something else.= So, >> let it tell the server what it is looking for explicitly.**** >> >> ** ** >> >> We need a URI scheme, because WebFinger can be used to discover all kind= s >> of information related to a given domain, not only user information. It >> can be used to query information about any URI, be that a web page, a us= er >> account, device on the network, etc. If we got rid of =93acct=94, then = we >> would have a system where we sometimes use a URI scheme and sometimes we= do >> not. Results might be inconsistent, as the server may not make the righ= t >> guess, unless we agreed that absence of a scheme defaults to =93acct:=94= . >> However, I see no reason for the client to be so lazy to not include >> =93acct:=94. The user might (and probably will) exclude it, but the cli= ent >> code can add it.**** >> >> ** ** >> >> At this point, I=92d argue the =93train has left the station=94 on =93ac= ct=94, >> too. The current WebFinger spec exists (in part) to formally document t= hat >> which has adopted; it=92s not a new thing. >> > > > Paul, thank you for your explanation on lookup based on acct: (WebFinger) > vs lookup based on mailto: (SWD). > > I think this is a major difference. > > The original WebFinger proposal was *supposed* to give extra information > about an email address. > > From wikipedia: > > "WebFinger is an Internet protocol that aims to provide information about > people by their* E-mail addresses*." > > From webfinger.org: > > "Put your *email address* into the box above, click the button" > > From google code (the top hit on google): > > "making *email addresses* readable again" > > And perhaps most importantly from the spec, the first example: > > "Assume you receive an *email *from Bob..." > > However only SWD here is doing email based discovery (mailto:). > WebFinger *now* doing acct: based discovery, which is a departure from th= e > original use case. > > Im glad that some people have voiced support for acct:, but I still > believe that to be a minority. I agree, that the new acct: scheme should > for in another document, rather than shoe horned into an email based > discovery system. > > IMHO, it's better to solve one problem (ie email based discovery) simply > and well, than to half solve two problems (ie a new uri scheme for > identity) in a single attempt. > > >> **** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> A couple of points: >> >> 1. JSON >> =3D=3D=3D=3D=3D=3D=3D >> >> I think at the time webfinger was created in 2009, XML was the de facto >> serialization, used in AJAX, SOAP and many other systems. Today I'm >> hearing more and more, that both developers and publishers, want to work >> with JSON, rather than, having to support both xml and json. Content >> negotiation also confuses some publishers. In my view, this is a great >> simplification that webfinger can learn from SWD. >> >> 2. acct: scheme >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> The acct: URI scheme has not proved popular, imho, and has added a layer >> of complexity and confusion. How do we get from acct: to mailto:? When >> should you use acct: and when mailto: (the spec says acct:user@host may >> be different from mailto:user@host). What about the forms. How about >> linked data ecosystems that want to cross link identifiers, do they now >> have to consider both cases? >> >> From the original post introducing acct: >> >> "I don=92t expect everyone to like this idea. I wish I could say I love = it, >> but I am simply content with it." >> >> I dont know of anyone in the community (and correct me if this has >> changed) that really loves acct:, or perhaps even likes the acct: idea. >> SWD has shown you can do discovery without acct: and I think that's a bi= g >> plus. >> >> >> >> >> One final side note is that this almost becomes trivial when you can do >> SPARQL queries. "void" is already registered by the W3C with IANA in >> .well-known in order to discover SPARQL endpoints. It may be overkill i= n >> some people's eyes, but Linked Data (which predates webfinger), >> particularly newer things like JSON LD, are a lot bigger than they were = in >> 2009. In a few years it may become the definitive discovery mechanism >> anyway.**** >> > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --485b397dd4bb9f276c04bdf62201 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Last time I looked, WF takes a URI as input.=A0 A mailto: URI is a URI.= =A0 If someone wants to provide a look up by email address service, WF work= s fine.=A0 It just accepts more than email addresses.

What am I missing?

On Apr 18, 2012 3:05 AM, "Melvin Carvalho&q= uot; <melvincarvalho@gmail.c= om> wrote:


On 18 April 2012 01:59, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

=A0

On =93acct:=94=85

=A0<= /p>

Humans will usually in= terchange an acct URI and mailto URI, probably never using either scheme di= rectly in practice.=A0 That=92s natural and expected, if not desired.=A0 Th= e intent is that we define something that looks like an email ID, but it=92= s not an email ID.=A0 Some services, perhaps Twitter being most notable, do= no use email addresses.=A0 Yet, you might have an account there.=A0 So, user@twitter.com mi= ght be used by humans and automated systems would convert that to acct:user@twitter.com= .=A0 It would not be appropriate to use mailto: since it=92s not an ema= il ID.

=A0<= /p>

We did have a lot of d= ebate about the use of =93acct=94.=A0 If you query my WebFinger server, you= =92ll see that it will work without =93acct:=94 prefixed, as that was a sug= gestion made a year or so ago.=A0 It will inspect the input and if it looks= like an acct URI, it will assume it is.=A0 The =93acct=94 URI will be retu= rned as an alias.=A0 However, we should always use some kind of URI scheme = to remove the guesswork.=A0 The client can often make a very good guess as = to whether it=92s looking for a user account or something else.=A0 So, let = it tell the server what it is looking for explicitly.<= /p>

=A0<= /p>

We need a URI scheme, = because WebFinger can be used to discover all kinds of information related = to a given domain, not only user information.=A0 It can be used to query in= formation about any URI, be that a web page, a user account, device on the = network, etc.=A0 If we got rid of =93acct=94, then we would have a system w= here we sometimes use a URI scheme and sometimes we do not.=A0 Results migh= t be inconsistent, as the server may not make the right guess, unless we ag= reed that absence of a scheme defaults to =93acct:=94.=A0 However, I see no= reason for the client to be so lazy to not include =93acct:=94.=A0 The use= r might (and probably will) exclude it, but the client code can add it.<= /u>

=A0<= /p>

At this point, I=92d a= rgue the =93train has left the station=94 on =93acct=94, too.=A0 The curren= t WebFinger spec exists (in part) to formally document that which has adopt= ed; it=92s not a new thing.



Paul, thank you for your explanation = on lookup based on acct: (WebFinger) vs lookup based on mailto: (SWD).
<= br>I think this is a major difference.

The original WebFinger propos= al was *supposed* to give extra information about an email address.

From wikipedia:

"WebFing= er is an Internet protocol that aims to provide information about people by= their E-mail addresses."

From webfinger.org:

"P= ut your email address into the box above, click the button"

From google code (the top hit on google):

"making email addresses readable again"= ;

And perhaps most importantly from the spec, the first example:

<= span style=3D"color:rgb(0,0,153)">"Assume you receive an email = from Bob..."

However only SWD here is doing email based = discovery (mailto:).=A0 WebFinger *now* doing acct: based discovery, which = is a departure from the original use case.=A0

Im glad that some people have voiced support for acct:, but I still bel= ieve that to be a minority.=A0 I agree, that the new acct: scheme should fo= r in another document, rather than shoe horned into an email based discover= y system.=A0

IMHO, it's better to solve one problem (ie email based discovery) s= imply and well, than to half solve two problems (ie a new uri scheme for id= entity) in a single attempt.=A0
=A0

=A0

Paul

=A0

A couple of points:

1. JSON
=3D=3D=3D=3D= =3D=3D=3D

I think at the time webfinger was created in 2009, XML was= the de facto serialization, used in AJAX, SOAP and many other systems.=A0 = Today I'm hearing more and more, that both developers and publishers, w= ant to work with JSON, rather than, having to support both xml and json.=A0= Content negotiation also confuses some publishers.=A0 In my view, this is = a great simplification that webfinger can learn from SWD.

2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The a= cct: URI scheme has not proved popular, imho, and has added a layer of comp= lexity and confusion.=A0 How do we get from acct: to mailto:?=A0 When shoul= d you use acct: and when mailto: (the spec says acct:user@host may be diffe= rent from mailto:user@host).=A0 What about the forms.=A0 How about linked data ecosystems that want= to cross link identifiers, do they now have to consider both cases?=A0
From the original post introducing acct:

"I don=92t expect = everyone to like this idea. I wish I could say I love it, but I am simply c= ontent with it."

I dont know of anyone in the community (and co= rrect me if this has changed) that really loves acct:, or perhaps even like= s the acct: idea.=A0 SWD has shown you can do discovery without acct: and I= think that's a big plus.




One final side note is that this almost becomes trivial whe= n you can do SPARQL queries.=A0 "void" is already registered by t= he W3C with IANA in .well-known in order to discover SPARQL endpoints.=A0 I= t may be overkill in some people's eyes, but Linked Data (which predate= s webfinger), particularly newer things like JSON LD, are a lot bigger than= they were in 2009.=A0 In a few years it may become the definitive discover= y mechanism anyway.



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

--485b397dd4bb9f276c04bdf62201-- From julian.reschke@gmx.de Wed Apr 18 09:54: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 D78A121F85C4 for ; Wed, 18 Apr 2012 09:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.289 X-Spam-Level: X-Spam-Status: No, score=-103.289 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bnb8j1JboBN for ; Wed, 18 Apr 2012 09:54:44 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id CDC9821F85C0 for ; Wed, 18 Apr 2012 09:54:42 -0700 (PDT) Received: (qmail invoked by alias); 18 Apr 2012 16:54:41 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp019) with SMTP; 18 Apr 2012 18:54:41 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+32wxjpJy3c50stayacViJjKId3L3mwkI7LUQG9i 7P3KUtI4Gba+6H Message-ID: <4F8EF1D0.50001@gmx.de> Date: Wed, 18 Apr 2012 18:54:40 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Bill McQuillan References: <20120330125228.15497.35035.idtracker@ietfa.amsl.com> <1271382236.20120330141948@pobox.com> In-Reply-To: <1271382236.20120330141948@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps-Discusssion Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:54:45 -0000 On 2012-03-30 23:19, Bill McQuillan wrote: > In section 3: > > ---------- > In order to improve interoperability with deployed agents, "text/*" > media type registrations SHOULD either > > a. specify that the "charset" parameter is not used for the defined > subtype, because the charset information is transported inside > the payload (such as in "text/xml"), or > b. require explicit unconditional inclusion of the "charset" > parameter eliminating the need for a default value. > > In accordance with option (a), above, registrations for "text/*" > media types that can transport charset information inside the > corresponding payloads (such as "text/html" and "text/xml") SHOULD > NOT specify the use of a "charset" parameter, nor any default value, > in order to avoid conflicting interpretations should the charset > parameter value and the value specified in the payload disagree. > ---------- > > Doesn't option (a) actually mean that a new default charset is > now defined, perhaps called "embedded-ascii", in which all octets > with values less than 128 must have the same meaning as the > correspondding ASCII values and that all octet values greater > than 127 may be ignored? This would allow naively processing a > newly specified text/* type by displaying the content first using > the "embedded-ascii" charset (ignoring non-ascii octets) and, > hopefully, finding, by eye, the actual charset specified within > and then re-displaying the content using that discovered charset. > > For instance how would a newly specified type similar to > text/html with a document using the internal charset of "ebcdic" > be handled? The current specification would deal with this merely > by ensuring that a "charset=ebcdic" appeared in the Content-Type > Mime field and also within the document itself. I'm not sure I understand the question. Types that transport charset information in-line will need to define how to detect it. An example would be the algorithm in http://www.w3.org/TR/xml/#sec-guessing And yes, that works best if the encoding is compatible to US-ASCII (that is, octets 0..127 represent the same characters as in the US-ASCII encoding). Do you think there's something we need to clarify here? Best regards, Julian From julian.reschke@gmx.de Wed Apr 18 09:58: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 49D0721F84EA for ; Wed, 18 Apr 2012 09:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.259 X-Spam-Level: X-Spam-Status: No, score=-103.259 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmlfaOunU3Ua for ; Wed, 18 Apr 2012 09:57:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6030421F84D1 for ; Wed, 18 Apr 2012 09:57:59 -0700 (PDT) Received: (qmail invoked by alias); 18 Apr 2012 16:57:58 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 18 Apr 2012 18:57:58 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX195XLk87dN5VHPtacH1yqg3Z91+bmXwI5xcfKn6rI nlVo9jUZD5Nxhc Message-ID: <4F8EF295.70609@gmx.de> Date: Wed, 18 Apr 2012 18:57:57 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> <01OE2UNN2HJ000ZUIL@mauve.mrochek.com> <4F82B5F6.3050806@gmx.de> <01OE3UQGECV600ZUIL@mauve.mrochek.com> <4F843332.7060705@isode.com> <4F8437E7.1070501@gmx.de> <4F8875D1.1000502@isode.com> <4F887C1C.7050306@gmx.de> In-Reply-To: <4F887C1C.7050306@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 16:58:00 -0000 On 2012-04-13 21:18, Julian Reschke wrote: > On 2012-04-13 20:52, Alexey Melnikov wrote: >> On 10/04/2012 14:38, Julian Reschke wrote: >>> On 2012-04-10 15:18, Alexey Melnikov wrote: >>>> ... >>>>> Not sure I see any need for a normative reference though. >>>> >>>> (I've mentioned my opinion to Julian, but I would like to state it for >>>> the record.) >>>> I think an update to RFC 2616 should have a reference to >>>> draft-ietf-appsawg-mime-default-charset and make it clear that the >>>> previous default was removed. An Informative reference to >>>> draft-ietf-appsawg-mime-default-charset should be fine. >>> >>> HTTPbis *does* make it clear that the default (overriding the base >>> spec) was removed. >>> >>> What's not clear to me is why it would need to reference >>> draft-ietf-appsawg-mime-default-charset. >> People who only read/implemented RFC 2616 need to be told that the rules >> changed. Similarly for people who read/implemented RFC 2046. Navigating >> through the maze of RFCs obsoleting each other is difficult for people >> who don't deal with them on a daily basis (and it is non trivial even >> for people who do). A reference to >> draft-ietf-appsawg-mime-default-charset would help with that. > > I'm still not convinced. > > HTTPbis removes the default, and states so in the "Changes from RFC > 2616" section. How does a reference to > draft-ietf-appsawg-mime-default-charset make things better? > ... Proposal: remove the comment in draft-ietf-appsawg-mime-default-charset. People who feel strongly about httpbis citing draft-ietf-appsawg-mime-default-charset should actually raise this in the HTTPbis WG (I'm editor of both documents so I don't have a *problem* adding the reference, I just don't see what it's good for :-). Best regards, Julian From bobwyman@gmail.com Wed Apr 18 10:38: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 4BBCC21F8474 for ; Wed, 18 Apr 2012 10:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrsThq3rIS3D for ; Wed, 18 Apr 2012 10:37:58 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 83F1721F8484 for ; Wed, 18 Apr 2012 10:37:58 -0700 (PDT) Received: by qaea16 with SMTP id a16so602620qae.10 for ; Wed, 18 Apr 2012 10:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5GtTkDIWoDojeJDsEThQId9z9t3yETKecHWfhNSClJw=; b=RGA7felTZnQcGUOGXPxOv50Yg5e9HJyv/CrF1wT/iL/FsvQFwFza3CXesRGbntxwuU v4Crtlq5eNstHf2hXjjAxm+cjXOiuk8jcPTdyh4UVOPYV/jiIMycX8kAuoonqRz96ern oH1kfjSnkSZqVhu8bytDV3O7jRnl04OQ0mSGsPcsgaD4k8nn1Jbc2SqtdP7yCjTIlKbn 2d3y725l/CUiH+Lkw3mEnlJVVw21y00Rx3GCeZ0aoAlI/dkVKBAXkBkyb22CMm2f+eTM w60ogtREfvcOdI74nByes8Iice0nKUuguvxYx92Y+eWaEH63Me7zKf0UT4pL8vUOmaH6 /XRw== MIME-Version: 1.0 Received: by 10.224.174.143 with SMTP id t15mr4731795qaz.79.1334770678025; Wed, 18 Apr 2012 10:37:58 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.12.194 with HTTP; Wed, 18 Apr 2012 10:37:57 -0700 (PDT) In-Reply-To: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <04fb01cd1cf6$23131c80$69395580$@packetizer.com> Date: Wed, 18 Apr 2012 13:37:57 -0400 X-Google-Sender-Auth: n7Kmu-MsbAeocGPk2it7RNFLAR4 Message-ID: From: Bob Wyman To: John Panzer Content-Type: multipart/alternative; boundary=485b397dd6651eccfc04bdf78420 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 17:38:03 -0000 --485b397dd6651eccfc04bdf78420 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Apr 18, 2012 at 11:59 AM, John Panzer wrote: > Last time I looked, WF takes a URI as input. A mailto: URI is a URI. If > someone wants to provide a look up by email address service, WF works > fine. It just accepts more than email addresses. > Hopefully, a service that provisioned mailto addresses (i.e. a service that provides email) would also include links to corresponding acct: URI's in their WebFinger document and would allow users to specify acct: URI's on services other than the one that serves the mailto: URI. For instance, I might maintain my full WebFinger "profile" on Google, yet, for some bizarre reason, use Yahoo! for email. I'd like people to be able to discover my profile on Google even if I were using Yahoo!'s email service. What am I missing? > On Apr 18, 2012 3:05 AM, "Melvin Carvalho" > wrote: > >> >> >> On 18 April 2012 01:59, Paul E. Jones wrote: >> >>> Melvin,**** >>> >>> ** ** >>> >>> On =93acct:=94=85**** >>> >>> ** ** >>> >>> Humans will usually interchange an acct URI and mailto URI, probably >>> never using either scheme directly in practice. That=92s natural and >>> expected, if not desired. The intent is that we define something that >>> looks like an email ID, but it=92s not an email ID. Some services, per= haps >>> Twitter being most notable, do no use email addresses. Yet, you might = have >>> an account there. So, user@twitter.com might be used by humans and >>> automated systems would convert that to acct:user@twitter.com. It >>> would not be appropriate to use mailto: since it=92s not an email ID.**= ** >>> >>> ** ** >>> >>> We did have a lot of debate about the use of =93acct=94. If you query = my >>> WebFinger server, you=92ll see that it will work without =93acct:=94 pr= efixed, as >>> that was a suggestion made a year or so ago. It will inspect the input= and >>> if it looks like an acct URI, it will assume it is. The =93acct=94 URI= will be >>> returned as an alias. However, we should always use some kind of URI >>> scheme to remove the guesswork. The client can often make a very good >>> guess as to whether it=92s looking for a user account or something else= . So, >>> let it tell the server what it is looking for explicitly.**** >>> >>> ** ** >>> >>> We need a URI scheme, because WebFinger can be used to discover all >>> kinds of information related to a given domain, not only user informati= on. >>> It can be used to query information about any URI, be that a web page, = a >>> user account, device on the network, etc. If we got rid of =93acct=94,= then we >>> would have a system where we sometimes use a URI scheme and sometimes w= e do >>> not. Results might be inconsistent, as the server may not make the rig= ht >>> guess, unless we agreed that absence of a scheme defaults to =93acct:= =94. >>> However, I see no reason for the client to be so lazy to not include >>> =93acct:=94. The user might (and probably will) exclude it, but the cl= ient >>> code can add it.**** >>> >>> ** ** >>> >>> At this point, I=92d argue the =93train has left the station=94 on =93a= cct=94, >>> too. The current WebFinger spec exists (in part) to formally document = that >>> which has adopted; it=92s not a new thing. >>> >> >> >> Paul, thank you for your explanation on lookup based on acct: (WebFinger= ) >> vs lookup based on mailto: (SWD). >> >> I think this is a major difference. >> >> The original WebFinger proposal was *supposed* to give extra information >> about an email address. >> >> From wikipedia: >> >> "WebFinger is an Internet protocol that aims to provide information abou= t >> people by their* E-mail addresses*." >> >> From webfinger.org: >> >> "Put your *email address* into the box above, click the button" >> >> From google code (the top hit on google): >> >> "making *email addresses* readable again" >> >> And perhaps most importantly from the spec, the first example: >> >> "Assume you receive an *email *from Bob..." >> >> However only SWD here is doing email based discovery (mailto:). >> WebFinger *now* doing acct: based discovery, which is a departure from t= he >> original use case. >> >> Im glad that some people have voiced support for acct:, but I still >> believe that to be a minority. I agree, that the new acct: scheme shoul= d >> for in another document, rather than shoe horned into an email based >> discovery system. >> >> IMHO, it's better to solve one problem (ie email based discovery) simply >> and well, than to half solve two problems (ie a new uri scheme for >> identity) in a single attempt. >> >> >>> **** >>> >>> ** ** >>> >>> Paul**** >>> >>> ** ** >>> >>> A couple of points: >>> >>> 1. JSON >>> =3D=3D=3D=3D=3D=3D=3D >>> >>> I think at the time webfinger was created in 2009, XML was the de facto >>> serialization, used in AJAX, SOAP and many other systems. Today I'm >>> hearing more and more, that both developers and publishers, want to wor= k >>> with JSON, rather than, having to support both xml and json. Content >>> negotiation also confuses some publishers. In my view, this is a great >>> simplification that webfinger can learn from SWD. >>> >>> 2. acct: scheme >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> The acct: URI scheme has not proved popular, imho, and has added a laye= r >>> of complexity and confusion. How do we get from acct: to mailto:? >>> When should you use acct: and when mailto: (the spec says acct:user@hos= tmay be different from mailto: >>> user@host). What about the forms. How about linked data ecosystems >>> that want to cross link identifiers, do they now have to consider both >>> cases? >>> >>> From the original post introducing acct: >>> >>> "I don=92t expect everyone to like this idea. I wish I could say I love >>> it, but I am simply content with it." >>> >>> I dont know of anyone in the community (and correct me if this has >>> changed) that really loves acct:, or perhaps even likes the acct: idea. >>> SWD has shown you can do discovery without acct: and I think that's a b= ig >>> plus. >>> >>> >>> >>> >>> One final side note is that this almost becomes trivial when you can do >>> SPARQL queries. "void" is already registered by the W3C with IANA in >>> .well-known in order to discover SPARQL endpoints. It may be overkill = in >>> some people's eyes, but Linked Data (which predates webfinger), >>> particularly newer things like JSON LD, are a lot bigger than they were= in >>> 2009. In a few years it may become the definitive discovery mechanism >>> anyway.**** >>> >> >> >> _______________________________________________ >> 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 > > --485b397dd6651eccfc04bdf78420 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 18, 2012 at 11:59 AM, John P= anzer <jpanzer@g= oogle.com> wrote:

Last time I looked, WF takes a URI as input.=A0 A mailto: URI is a URI.= =A0 If someone wants to provide a look up by email address service, WF work= s fine.=A0 It just accepts more than email addresses.

= Hopefully, a service that provisioned mailto addresses (i.e. a service that= provides email) would also include links to corresponding acct: URI's = in their WebFinger document and would allow users to specify acct: URI'= s on services other than the one that serves the mailto: URI.=A0
For instance, I might maintain my full WebFinger "profile" o= n Google, yet, for some bizarre reason, use Yahoo! for email. I'd like = people to be able to discover my profile on Google even if I were using Yah= oo!'s email service.

What am I missing?

On Apr 18, 2012 3:05 AM, = "Melvin Carvalho" <melvincarvalho@gmail.com> wrote:


On 18 April 2012 01:59, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

=A0

On =93acct:=94=85

=A0<= /p>

Humans will usually in= terchange an acct URI and mailto URI, probably never using either scheme di= rectly in practice.=A0 That=92s natural and expected, if not desired.=A0 Th= e intent is that we define something that looks like an email ID, but it=92= s not an email ID.=A0 Some services, perhaps Twitter being most notable, do= no use email addresses.=A0 Yet, you might have an account there.=A0 So, user@twitter.com mi= ght be used by humans and automated systems would convert that to acct:user@twitter.com= .=A0 It would not be appropriate to use mailto: since it=92s not an ema= il ID.

=A0<= /p>

We did have a lot of d= ebate about the use of =93acct=94.=A0 If you query my WebFinger server, you= =92ll see that it will work without =93acct:=94 prefixed, as that was a sug= gestion made a year or so ago.=A0 It will inspect the input and if it looks= like an acct URI, it will assume it is.=A0 The =93acct=94 URI will be retu= rned as an alias.=A0 However, we should always use some kind of URI scheme = to remove the guesswork.=A0 The client can often make a very good guess as = to whether it=92s looking for a user account or something else.=A0 So, let = it tell the server what it is looking for explicitly.<= /p>

=A0<= /p>

We need a URI scheme, = because WebFinger can be used to discover all kinds of information related = to a given domain, not only user information.=A0 It can be used to query in= formation about any URI, be that a web page, a user account, device on the = network, etc.=A0 If we got rid of =93acct=94, then we would have a system w= here we sometimes use a URI scheme and sometimes we do not.=A0 Results migh= t be inconsistent, as the server may not make the right guess, unless we ag= reed that absence of a scheme defaults to =93acct:=94.=A0 However, I see no= reason for the client to be so lazy to not include =93acct:=94.=A0 The use= r might (and probably will) exclude it, but the client code can add it.<= /u>

=A0<= /p>

At this point, I=92d a= rgue the =93train has left the station=94 on =93acct=94, too.=A0 The curren= t WebFinger spec exists (in part) to formally document that which has adopt= ed; it=92s not a new thing.



Paul, thank you for your explanation = on lookup based on acct: (WebFinger) vs lookup based on mailto: (SWD).
<= br>I think this is a major difference.

The original WebFinger propos= al was *supposed* to give extra information about an email address.

From wikipedia:

"WebFing= er is an Internet protocol that aims to provide information about people by= their E-mail addresses."

From webfinger.org:

"P= ut your email address into the box above, click the button"

From google code (the top hit on google):

"making email addresses readable again"= ;

And perhaps most importantly from the spec, the first example:

<= span style=3D"color:rgb(0,0,153)">"Assume you receive an email = from Bob..."

However only SWD here is doing email based = discovery (mailto:).=A0 WebFinger *now* doing acct: based discovery, which = is a departure from the original use case.=A0

Im glad that some people have voiced support for acct:, but I still bel= ieve that to be a minority.=A0 I agree, that the new acct: scheme should fo= r in another document, rather than shoe horned into an email based discover= y system.=A0

IMHO, it's better to solve one problem (ie email based discovery) s= imply and well, than to half solve two problems (ie a new uri scheme for id= entity) in a single attempt.=A0
=A0

=A0

Paul

=A0

A couple of points:

1. JSON
=3D=3D=3D=3D= =3D=3D=3D

I think at the time webfinger was created in 2009, XML was= the de facto serialization, used in AJAX, SOAP and many other systems.=A0 = Today I'm hearing more and more, that both developers and publishers, w= ant to work with JSON, rather than, having to support both xml and json.=A0= Content negotiation also confuses some publishers.=A0 In my view, this is = a great simplification that webfinger can learn from SWD.

2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The a= cct: URI scheme has not proved popular, imho, and has added a layer of comp= lexity and confusion.=A0 How do we get from acct: to mailto:?=A0 When shoul= d you use acct: and when mailto: (the spec says acct:user@host may be diffe= rent from mailto:user@host).=A0 What about the forms.=A0 How about linked data ecosystems that want= to cross link identifiers, do they now have to consider both cases?=A0
From the original post introducing acct:

"I don=92t expect = everyone to like this idea. I wish I could say I love it, but I am simply c= ontent with it."

I dont know of anyone in the community (and co= rrect me if this has changed) that really loves acct:, or perhaps even like= s the acct: idea.=A0 SWD has shown you can do discovery without acct: and I= think that's a big plus.




One final side note is that this almost becomes trivial whe= n you can do SPARQL queries.=A0 "void" is already registered by t= he W3C with IANA in .well-known in order to discover SPARQL endpoints.=A0 I= t may be overkill in some people's eyes, but Linked Data (which predate= s webfinger), particularly newer things like JSON LD, are a lot bigger than= they were in 2009.=A0 In a few years it may become the definitive discover= y mechanism anyway.



_________________________________________= ______
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


--485b397dd6651eccfc04bdf78420-- From tlyu@mit.edu Wed Apr 18 11: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 06BD621F8537; Wed, 18 Apr 2012 11:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.224 X-Spam-Level: X-Spam-Status: No, score=-104.224 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoPdJ23hLyDd; Wed, 18 Apr 2012 11:02:24 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8DB21F8532; Wed, 18 Apr 2012 11:02:24 -0700 (PDT) X-AuditID: 1209190d-b7fbf6d0000008ba-17-4f8f01af6299 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id B3.80.02234.FA10F8F4; Wed, 18 Apr 2012 14:02:23 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id q3II2LAW029363; Wed, 18 Apr 2012 14:02:22 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q3II2HsB019630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Apr 2012 14:02:18 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id q3II2HtQ029000; Wed, 18 Apr 2012 14:02:17 -0400 (EDT) To: Tobias Gondrom References: <4F8E377D.2010601@gondrom.org> From: Tom Yu Date: Wed, 18 Apr 2012 14:02:17 -0400 In-Reply-To: <4F8E377D.2010601@gondrom.org> (Tobias Gondrom's message of "Wed, 18 Apr 2012 11:39:41 +0800") Message-ID: Lines: 40 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixG6noruesd/fYNF5BYvVL1ewWUx6/4/N YsaficwWtxbMZ3Rg8XhwZz6Tx5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CVcePHROaC2QIV rXPuMjcwTuXtYuTkkBAwkWjvmcQMYYtJXLi3nq2LkYtDSGAfo8T335NYQRJCAhsYJRrP6kAk rjBJ/L8/Haqqi1Hi08Zd7CBVIgL6EgeuH2MDsZkF0iXuXNvI0sXIwSEsECRx+Y8HxCAtib4z 08DCbALSEkcXl4GEWQRUJW48vwPWySmQLXHz3nSwvbwCFhJvpjQygtg8ApwSDz8uY4SIC0qc nPmEBWKTlsSNfy+ZJjAKzkKSmoUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGukV5uZole akrpJkZQEHNK8u5gfHdQ6RCjAAejEg/v12t9/kKsiWXFlbmHGCU5mJREea//BQrxJeWnVGYk FmfEF5XmpBYfYpTgYFYS4V13ASjHm5JYWZValA+TkuZgURLnVdV65yckkJ5YkpqdmlqQWgST leHgUJLgfcrQ7y8kWJSanlqRlplTgpBm4uAEGc4DNPwuSA1vcUFibnFmOkT+FKOilDjvbpCE AEgiozQPrheWZF4xigO9Isx7EqSKB5ig4LpfAQ1mAhqsKAFydXFJIkJKqoFx+6NtU4XObVm7 6Iea4VLu6o/rbAochJN/hL6auu7ijNqbV25dXHNgTh+Pq/VNXZHjHgo8b1XEzFnuC3Z4cJ5Y UXKT41afgK2epoSZo8I3nhMmf6+4RnpzHud5WSOQwp1wO9KW80mIs7SiwYYi56mS2goe1nJN J1suivNfn9ljfODsu4gLjGeUWIozEg21mIuKEwGK4agBDQMAAA== Cc: draft-ietf-krb-wg-des-die-die-die.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-krb-wg-des-die-die-die-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, 18 Apr 2012 18:02:25 -0000 Tobias Gondrom writes: > Major Comment: > Agree that we should/must deprecate the weak cryptographic algorithms > in Kerberos. > However IMHO, I do not agree with the reasoning "to not actively > discourage the use of RC4-HMAC" in section 7. > I understand that interoperability is of major importance, but at some > point a very weak algorithm will give users a false sense of security > while exposing them to malicious attacks. And keeping RC4-HMAC > supported does also expose the majority of the community (who is not > using the deprecated Windows Versions) at possible risks to downgrade > attacks. I believe RC4-HMAC (note: _not_ the 56-bit RC4-HMAC-EXP, which we _are_ deprecating) is stronger than the DES enctypes that we are deprecating. It has a 128-bit keysize, but might be somewhat weaker than AES of the same keysize. I know of no reason yet to characterize RC4-HMAC as "very weak"; it might very well be stronger than triple-DES, which we are not deprecating at this time. Do you believe that RC4-HMAC poses anywhere near the level of risk that single-DES does? If not, I prefer to handle deprecating RC4-HMAC separately so that we avoid confusing the issues. > I believe even though the support of the complete Internet community > is vital for standards, the support of deprecated (and AFAIK no longer > supported OS versions) should not be the deciding argument behind our > decisions here. Even old OS can be patched or fixed by the vendor or > other service providers and it should not justify to keep a weak > algorithm. Extended support is still available for some of the Windows operating systems in question, but I believe Microsoft finds it uneconomical to implement support for new crypto algorithms in these older versions of Windows (which could very well still be around until 2015). RFC 4757 already mentions known weaknesses of RC4-HMAC, and we refer to that RFC in the document's Security Considerations. Do you believe that there should be a stronger warning? From julian.reschke@gmx.de Wed Apr 18 11:26: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 275DC21F84CD for ; Wed, 18 Apr 2012 11:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.923 X-Spam-Level: X-Spam-Status: No, score=-102.923 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0g2s6oKiFyTi for ; Wed, 18 Apr 2012 11:26:48 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E366F21F8476 for ; Wed, 18 Apr 2012 11:26:44 -0700 (PDT) Received: (qmail invoked by alias); 18 Apr 2012 18:26:43 -0000 Received: from p57A6F50E.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.245.14] by mail.gmx.net (mp038) with SMTP; 18 Apr 2012 20:26:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/od4pb3hToC/rVCacCzuPS7LQgO7DvhFvVXb09aT kJRNuvMLL4YAQ/ Message-ID: <4F8F0762.3010509@gmx.de> Date: Wed, 18 Apr 2012 20:26:42 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Carsten Bormann References: <9452079D1A51524AA5749AD23E0039280C9874@exch-mbx901.corp.cloudmark.com> <4F83EF76.3000703@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 18:26:51 -0000 On 2012-04-10 10:54, Carsten Bormann wrote: > On Apr 10, 2012, at 10:29, Julian Reschke wrote: > >> On 2012-04-09 18:57, Carsten Bormann wrote: >>> * Technical summary >>> >>> This is the right thing to do, and should have been done right after the end of the UTF wars. >>> >>> * Editorial issues >>> >>> The document appears to spell out a SHOULD for "text/html" and "text/xml". >>> Does it change the meaning of text/html and text/xml? >> >> No. But it licenses future revisions of these specs to do the right thing. >> >>> Reading more closely, this apparently isn't meant, but there is a potential misunderstanding. >> >> We tried to clarify this in the latest draft. Can you suggest changes? > > (such as "text/html" and "text/xml") > -> > (such as "text/html" and "text/xml" are able to) Done. > And in the start of that paragraph: > > registrations > -> > future registrations Not convinced. This document changes the rules; I think it's pretty clear that it doesn't apply to past registrations. >>> More generally: >>> When looking at a random media type three years from now, how do I find out whether this sentence does apply: >>> It does not change the >>> defaults for any currently registered media type. >> >> The media type definition will have to state the default. > > Yes. > > s/currently// > > Again. maybe Again not convinced. > for text/* media types > -> > for future registrations of text/* media types > > in the same paragraph. See above :-) >>> Even more generally: >>> Who is affected by (needs to read) this specification? >>> Who are the targets of the SHOULDs and MUSTs? >>> How do I find out whether an implementation complies? interoperates? >> >> The audience is people registering media types. >> >> And yes, one could argue this spec needs to RFC2119 keywords. > > I can't parse that last sentence. > > The MUST and the MUST NOT at the end of 3 are clearly meta-specs, and not for registrations either, but for "protocols". > They generate a conflict for existing specs such as RFC 2616 without indication how to resolve that conflict. > I know (the draft is mute about that) that we are fixing 2616, but this draft says nothing about how to handle that kind of conflict. > > Again, adding little words such as "future" might help. > Or maybe the indication that these existing conflicting protocols are unbearable and will all need to be fixed (!?). That's a good question. As we already fixed it in HTTP, is there anything else we need to worry about`? >>> And meta^3: >>> What is the IETF name for specifications that are exclusively intended to remind us not to make a certain class of mistake again when generating future specifications? Which specification wins when such a meta-specification is neglected in a specific specification? >> >> This document updates RFC 2046, I don't think more needs to be done here... > > I'm fine with that, I'm just not fine with the ambiguity resulting from retroactively changing meta-specs that have conflicting specs in force. > I think with the above clarifications in place we might be reaching the point of diminishing returns in managing this specific conflict. > I'm just trying to make the more general point here that you have to be careful in how you rewrite history. > > Grüße, Carsten Best regards, Julian From mnot@mnot.net Wed Apr 18 12:00: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 DE0D811E8080 for ; Wed, 18 Apr 2012 12:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.98 X-Spam-Level: X-Spam-Status: No, score=-105.98 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWAM+Fi8XNye for ; Wed, 18 Apr 2012 11:59:56 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 888FB11E8085 for ; Wed, 18 Apr 2012 11:59:56 -0700 (PDT) Received: from [172.16.11.154] (unknown [12.197.88.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 48CB622E25D; Wed, 18 Apr 2012 14:59:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Mark Nottingham In-Reply-To: <217479C6-A2F8-4A06-A53E-E6BF4D1AB410@gmail.com> Date: Wed, 18 Apr 2012 11:59:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8173C795-AC92-4E54-8D1C-18A88BFE1AC2@mnot.net> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0@P3PWEX2MB008.ex2.secureserver.net> <5837DDA7-19DC-4452-BD47-FFF6C674E179@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3DF@P3PWEX2MB008.ex2.secureserver.net> <217479C6-A2F8-4A06-A53E-E6BF4D1AB410@gmail.com> To: Dick Hardt X-Mailer: Apple Mail (2.1257) Cc: Ned Freed , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss , Pete Resnick Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 19:00:01 -0000 On 18/04/2012, at 10:26 AM, Dick Hardt wrote: > Thanks Eran, I think I understand. >=20 > To restate what you have said, specifying a query parameter as part of = the spec is "bad" web architecture and potentially sets a precedent for = other specifications to reserve a query parameter. Correct? >=20 > The reality is that the world is a messy place. Developers hack the = architecture to accomplish goals not envisioned by the architects. The = architects can accept the reality of the world, or ignore it and lose = their relevance. In my opinion, putting the query parameter mechanism = into an appendix is ignoring the reality of current implementations. = Adding language to the spec that use of the query parameter is not = architecturally ideal, but accepts the reality of the current web would = be far more preferable. =85 Except that AIUI that method has been identified as not good = practice for entirely practical reasons, independent of the = architectural reasons. Putting that aside, there's a large difference between acknowledging and = documenting broad practice that's bad and sanctioning its use to = encourage further abuses. Believe it or not, things like this *do* affect real people -- just not = the "hackers" who are working on OAuth. It affects people who run real = Web sites, because they have to consider what query parameters they can = use in their apps without danger of colliding with OAuth or the future = extensions that mimic it (do you *really* think this is going to be the = Last Authentication Scheme in the World?). It affects the folks who have = to figure out how to graft this mechanism onto existing systems that = already use the parameter name you've chosen. I really don't want to have to go through a list of 50 such "reserved" = query parameters every time I write a new Web app in ten years. Sorry if = having a perspective that's further out than my nose gets me out of the = "hacker" bucket into the dreaded "architect" camp. Deploying and = maintaining extremely large systems over a long period of time has = taught me that it's a good idea. YMMV. Thanks, > =20 > -- Dick >=20 > On Apr 17, 2012, at 8:28 PM, Eran Hammer wrote: >=20 >> A site has a bunch of APIs. They want to use OAuth with Bearer = tokens. They can no longer use the access_token parameter for their own = use cases because the Bearer token specification creates a conflict. = This conflict does not exist with the use of the header. It does exist = with the use of the body if they have an access_token parameter already = in use. >> =20 >> The API format has nothing to do with OAuth, but the use of a query = parameter leaks into that namespace. >> =20 >> This isn=92t a critical issue. It is a hack =96 it has always been = since it was introduced in OAuth 1.0. The issue raised was about web = architecture in general and setting a precedence. I don=92t think it = will likely to create real-world problems, but the same goes for not = supporting this use case anymore (or at least explicitly marking it as = deprecated, maybe even demoted to an appendix documenting historical = use). >> =20 >> While the violation of the provider namespace is a significant = principal, I want to make sure my view isn=92t coming off as some severe = warning. Either way, it is not a big deal IMO. >> =20 >> EH >> =20 >> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >> Sent: Tuesday, April 17, 2012 12:32 PM >> To: Eran Hammer >> Cc: Dick Hardt; Stephen Farrell; Mark Nottingham; Pete Resnick; Ned = Freed; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss >> Subject: Re: [apps-discuss] Reserved URI query parameter in = draft-ietf-oauth-v2-bearer >> =20 >> Please elaborate on what the issue is then as protecting API = resources is what OAuth is all about.=20 >> =20 >> On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote: >>=20 >>=20 >> That has nothing to do with this issue. The protected resources API = format was never part of OAuth at any time. >> =20 >> EH >> =20 >> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >> Sent: Tuesday, April 17, 2012 9:50 AM >> To: Eran Hammer >> Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; = draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss >> Subject: Re: [apps-discuss] Reserved URI query parameter in = draft-ietf-oauth-v2-bearer >> =20 >> =20 >> On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote: >>=20 >>=20 >>=20 >> (Sticking with the naivety:-) So, what's different there from how the = base >> oauth draft registers client_id and shows how that can be used in a = GET >> request? [1] >>=20 >> Big difference. The base draft specifies its own endpoints as part of = a complete API package for obtaining authorization. These parameters are = scoped only for the endpoints defined and not for any others. There is = no possibility of conflict because the specification defines the entire = namespace. >>=20 >> OTOH, the bearer spec is applied to *any* web resources using OAuth = authentication where some other namespace definition must exist. >> =20 >> =20 >> If we had kept it all in one spec as it had originally been drafted, = this would not be an issue, and it would be easier for implementers to = understand. I don't know of anyone looking to implement the bearer spec = independent of the base spec. (would be interested if anyone does know = of an implementation) >=20 -- Mark Nottingham http://www.mnot.net/ From eran@hueniverse.com Wed Apr 18 13:00: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 478A811E80A2 for ; Wed, 18 Apr 2012 13:00:22 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO-bp2bgmI-P for ; Wed, 18 Apr 2012 13:00:18 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id 346FB11E80AA for ; Wed, 18 Apr 2012 13:00:13 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id zY0D1i0010CJzpC01Y0DuQ; Wed, 18 Apr 2012 13:00:13 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Wed, 18 Apr 2012 13:00:12 -0700 From: Eran Hammer To: Mark Nottingham , Dick Hardt Thread-Topic: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer Thread-Index: AQHNHZV1otrfFyWXlUq7MW9t02eB2Jag/voA Date: Wed, 18 Apr 2012 20:00:11 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FEFD38@P3PWEX2MB008.ex2.secureserver.net> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0@P3PWEX2MB008.ex2.secureserver.net> <5837DDA7-19DC-4452-BD47-FFF6C674E179@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3DF@P3PWEX2MB008.ex2.secureserver.net> <217479C6-A2F8-4A06-A53E-E6BF4D1AB410@gmail.com> <8173C795-AC92-4E54-8D1C-18A88BFE1AC2@mnot.net> In-Reply-To: <8173C795-AC92-4E54-8D1C-18A88BFE1AC2@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [63.79.89.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pete Resnick , Ned Freed , Apps Discuss , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 20:00:22 -0000 A good example is the 'callback' query parameter used in JSONP. OAuth 2.0 originally used a 'callback' parameter for its own APIs but we ch= anged it after feedback from Facebook indicated there developers were confu= sed by it and in some cases, that caused conflict with existing frameworks = where 'callback' was always processed automatically. So while OAuth does no= t use JSONP, it had to renamed the parameter to 'redirect_uri' to avoid *po= tential* conflict. EH > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Wednesday, April 18, 2012 12:00 PM > To: Dick Hardt > Cc: Eran Hammer; Stephen Farrell; Pete Resnick; Ned Freed; draft-ietf-oau= th- > v2-bearer.all@tools.ietf.org; Apps Discuss > Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf- > oauth-v2-bearer >=20 >=20 > On 18/04/2012, at 10:26 AM, Dick Hardt wrote: >=20 > > Thanks Eran, I think I understand. > > > > To restate what you have said, specifying a query parameter as part of = the > spec is "bad" web architecture and potentially sets a precedent for other > specifications to reserve a query parameter. Correct? > > > > The reality is that the world is a messy place. Developers hack the > architecture to accomplish goals not envisioned by the architects. The > architects can accept the reality of the world, or ignore it and lose the= ir > relevance. In my opinion, putting the query parameter mechanism into an > appendix is ignoring the reality of current implementations. Adding langu= age > to the spec that use of the query parameter is not architecturally ideal,= but > accepts the reality of the current web would be far more preferable. >=20 > ... Except that AIUI that method has been identified as not good practice= for > entirely practical reasons, independent of the architectural reasons. >=20 > Putting that aside, there's a large difference between acknowledging and > documenting broad practice that's bad and sanctioning its use to encourag= e > further abuses. >=20 > Believe it or not, things like this *do* affect real people -- just not t= he > "hackers" who are working on OAuth. It affects people who run real Web > sites, because they have to consider what query parameters they can use i= n > their apps without danger of colliding with OAuth or the future extension= s > that mimic it (do you *really* think this is going to be the Last Authent= ication > Scheme in the World?). It affects the folks who have to figure out how to > graft this mechanism onto existing systems that already use the parameter > name you've chosen. >=20 > I really don't want to have to go through a list of 50 such "reserved" qu= ery > parameters every time I write a new Web app in ten years. Sorry if having= a > perspective that's further out than my nose gets me out of the "hacker" > bucket into the dreaded "architect" camp. Deploying and maintaining > extremely large systems over a long period of time has taught me that it'= s a > good idea. YMMV. >=20 > Thanks, >=20 > > > > -- Dick > > > > On Apr 17, 2012, at 8:28 PM, Eran Hammer wrote: > > > >> A site has a bunch of APIs. They want to use OAuth with Bearer tokens. > They can no longer use the access_token parameter for their own use cases > because the Bearer token specification creates a conflict. This conflict = does > not exist with the use of the header. It does exist with the use of the b= ody if > they have an access_token parameter already in use. > >> > >> The API format has nothing to do with OAuth, but the use of a query > parameter leaks into that namespace. > >> > >> This isn't a critical issue. It is a hack - it has always been since i= t was > introduced in OAuth 1.0. The issue raised was about web architecture in > general and setting a precedence. I don't think it will likely to create = real- > world problems, but the same goes for not supporting this use case anymor= e > (or at least explicitly marking it as deprecated, maybe even demoted to a= n > appendix documenting historical use). > >> > >> While the violation of the provider namespace is a significant princip= al, I > want to make sure my view isn't coming off as some severe warning. Either > way, it is not a big deal IMO. > >> > >> EH > >> > >> From: Dick Hardt [mailto:dick.hardt@gmail.com] > >> Sent: Tuesday, April 17, 2012 12:32 PM > >> To: Eran Hammer > >> Cc: Dick Hardt; Stephen Farrell; Mark Nottingham; Pete Resnick; Ned > >> Freed; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss > >> Subject: Re: [apps-discuss] Reserved URI query parameter in > >> draft-ietf-oauth-v2-bearer > >> > >> Please elaborate on what the issue is then as protecting API resources= is > what OAuth is all about. > >> > >> On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote: > >> > >> > >> That has nothing to do with this issue. The protected resources API fo= rmat > was never part of OAuth at any time. > >> > >> EH > >> > >> From: Dick Hardt [mailto:dick.hardt@gmail.com] > >> Sent: Tuesday, April 17, 2012 9:50 AM > >> To: Eran Hammer > >> Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; > >> draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss > >> Subject: Re: [apps-discuss] Reserved URI query parameter in > >> draft-ietf-oauth-v2-bearer > >> > >> > >> On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote: > >> > >> > >> > >> (Sticking with the naivety:-) So, what's different there from how the > >> base oauth draft registers client_id and shows how that can be used > >> in a GET request? [1] > >> > >> Big difference. The base draft specifies its own endpoints as part of = a > complete API package for obtaining authorization. These parameters are > scoped only for the endpoints defined and not for any others. There is no > possibility of conflict because the specification defines the entire name= space. > >> > >> OTOH, the bearer spec is applied to *any* web resources using OAuth > authentication where some other namespace definition must exist. > >> > >> > >> If we had kept it all in one spec as it had originally been drafted, > >> this would not be an issue, and it would be easier for implementers > >> to understand. I don't know of anyone looking to implement the bearer > >> spec independent of the base spec. (would be interested if anyone > >> does know of an implementation) > > >=20 > -- > Mark Nottingham > http://www.mnot.net/ >=20 >=20 >=20 From iesg-secretary@ietf.org Wed Apr 18 13:57: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 0B62A11E8097; Wed, 18 Apr 2012 13:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dy71WJeIqVi6; Wed, 18 Apr 2012 13:57:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC5E11E8095; Wed, 18 Apr 2012 13:57:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120418205730.17453.64115.idtracker@ietfa.amsl.com> Date: Wed, 18 Apr 2012 13:57:30 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (The "about" URI Scheme) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 20:57:35 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'The "about" URI Scheme' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-05-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the "about" URI scheme, which is widely used by web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-about-uri-scheme/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-about-uri-scheme/ballot/ No IPR declarations have been submitted directly on this I-D. From mnot@mnot.net Wed Apr 18 14: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 6D97D11E8091 for ; Wed, 18 Apr 2012 14:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh1RZ3ZBAAdY for ; Wed, 18 Apr 2012 14:11:22 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id DF95011E8097 for ; Wed, 18 Apr 2012 14:11:21 -0700 (PDT) Received: from [192.168.195.134] (unknown [204.16.154.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 80BCD50A6C; Wed, 18 Apr 2012 17:11:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <3E66A1C7-97B7-43FE-A851-791F33C4A372@gmail.com> Date: Wed, 18 Apr 2012 14:11:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <075265B2-9C33-40D6-B9F7-707027502850@mnot.net> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0@P3PWEX2MB008.ex2.secureserver.net> <5837DDA7-19DC-4452-BD47-FFF6C674E179@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3DF@P3PWEX2MB008.ex2.secureserver.net> <217479C6-A2F8-4A06-A53E-E6BF4D1AB410@gmail.com> <8173C795-AC92-4E54-8D1C-18A88BFE1AC2@mnot.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEFD38@P3PWEX2MB008.ex2.secureserver.net> <3E66A1C7-97B7-43FE-A851-791F33C4A372@gmail.com> To: Dick Hardt X-Mailer: Apple Mail (2.1257) Cc: Ned Freed , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss , Pete Resnick Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 21:11:26 -0000 On 18/04/2012, at 1:49 PM, Dick Hardt wrote: >=20 > Mark: >=20 > Would you point me to where this is bad practice as opposed to bad web = architecture? What are you looking for here? > This is the only way to pass the parameter if doing JSONP -- there is = no access to the headers.=20 >=20 > Many sites with substantial security expertise (Google, Facebook, = LinkedIn, Foursquare) have chosen to use the query parameter as opposed = to the header - both methods have been documented in the drafts since = the beginning. Clearly from a practical point of view the implementors = have chosen to use the query parameter.=20 >=20 > When I use the term hack, I am referring to people building things = independent of specs because they are needing unspecified functionality. = I am not talking about some hackers. >=20 > Having been building systems for some time, I fully appreciate the = long term issues with name spaces, and having a query parameter is not = the ideal solution, but given where the world is now, using a query = parameter is what everyone is choosing -- and I have yet to hear a good = reason why it is a bad solution -- and there is no known alternative to = working with JSONP. >=20 > All the OAuth 2 deployments I have seen have been to fresh URLs where = name collision with oath_token is a non issue. Calling it the parameter = "token" would clearly be less than ideal, and lead to the issues that = JSONP has with "callback" >=20 > Reserved words is one of those nasty gotchas that many languages have, = that have been solved by prefix hacks such as leading underscores etc. = or leading 'x-' I understand all of that. This thread has been about the difference = between documenting this kind of practice as a necessarily ~evil and = recommending it (with the voice of the IETF). >=20 > -- Dick >=20 > On Apr 18, 2012, at 1:00 PM, Eran Hammer wrote: >=20 >> A good example is the 'callback' query parameter used in JSONP. >>=20 >> OAuth 2.0 originally used a 'callback' parameter for its own APIs but = we changed it after feedback from Facebook indicated there developers = were confused by it and in some cases, that caused conflict with = existing frameworks where 'callback' was always processed automatically. = So while OAuth does not use JSONP, it had to renamed the parameter to = 'redirect_uri' to avoid *potential* conflict. >>=20 >> EH >>=20 >>> -----Original Message----- >>> From: Mark Nottingham [mailto:mnot@mnot.net] >>> Sent: Wednesday, April 18, 2012 12:00 PM >>> To: Dick Hardt >>> Cc: Eran Hammer; Stephen Farrell; Pete Resnick; Ned Freed; = draft-ietf-oauth- >>> v2-bearer.all@tools.ietf.org; Apps Discuss >>> Subject: Re: [apps-discuss] Reserved URI query parameter in = draft-ietf- >>> oauth-v2-bearer >>>=20 >>>=20 >>> On 18/04/2012, at 10:26 AM, Dick Hardt wrote: >>>=20 >>>> Thanks Eran, I think I understand. >>>>=20 >>>> To restate what you have said, specifying a query parameter as part = of the >>> spec is "bad" web architecture and potentially sets a precedent for = other >>> specifications to reserve a query parameter. Correct? >>>>=20 >>>> The reality is that the world is a messy place. Developers hack the >>> architecture to accomplish goals not envisioned by the architects. = The >>> architects can accept the reality of the world, or ignore it and = lose their >>> relevance. In my opinion, putting the query parameter mechanism into = an >>> appendix is ignoring the reality of current implementations. Adding = language >>> to the spec that use of the query parameter is not architecturally = ideal, but >>> accepts the reality of the current web would be far more preferable. >>>=20 >>> ... Except that AIUI that method has been identified as not good = practice for >>> entirely practical reasons, independent of the architectural = reasons. >>>=20 >>> Putting that aside, there's a large difference between acknowledging = and >>> documenting broad practice that's bad and sanctioning its use to = encourage >>> further abuses. >>>=20 >>> Believe it or not, things like this *do* affect real people -- just = not the >>> "hackers" who are working on OAuth. It affects people who run real = Web >>> sites, because they have to consider what query parameters they can = use in >>> their apps without danger of colliding with OAuth or the future = extensions >>> that mimic it (do you *really* think this is going to be the Last = Authentication >>> Scheme in the World?). It affects the folks who have to figure out = how to >>> graft this mechanism onto existing systems that already use the = parameter >>> name you've chosen. >>>=20 >>> I really don't want to have to go through a list of 50 such = "reserved" query >>> parameters every time I write a new Web app in ten years. Sorry if = having a >>> perspective that's further out than my nose gets me out of the = "hacker" >>> bucket into the dreaded "architect" camp. Deploying and maintaining >>> extremely large systems over a long period of time has taught me = that it's a >>> good idea. YMMV. >>>=20 >>> Thanks, >>>=20 >>>>=20 >>>> -- Dick >>>>=20 >>>> On Apr 17, 2012, at 8:28 PM, Eran Hammer wrote: >>>>=20 >>>>> A site has a bunch of APIs. They want to use OAuth with Bearer = tokens. >>> They can no longer use the access_token parameter for their own use = cases >>> because the Bearer token specification creates a conflict. This = conflict does >>> not exist with the use of the header. It does exist with the use of = the body if >>> they have an access_token parameter already in use. >>>>>=20 >>>>> The API format has nothing to do with OAuth, but the use of a = query >>> parameter leaks into that namespace. >>>>>=20 >>>>> This isn't a critical issue. It is a hack - it has always been = since it was >>> introduced in OAuth 1.0. The issue raised was about web architecture = in >>> general and setting a precedence. I don't think it will likely to = create real- >>> world problems, but the same goes for not supporting this use case = anymore >>> (or at least explicitly marking it as deprecated, maybe even demoted = to an >>> appendix documenting historical use). >>>>>=20 >>>>> While the violation of the provider namespace is a significant = principal, I >>> want to make sure my view isn't coming off as some severe warning. = Either >>> way, it is not a big deal IMO. >>>>>=20 >>>>> EH >>>>>=20 >>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>>>> Sent: Tuesday, April 17, 2012 12:32 PM >>>>> To: Eran Hammer >>>>> Cc: Dick Hardt; Stephen Farrell; Mark Nottingham; Pete Resnick; = Ned >>>>> Freed; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss >>>>> Subject: Re: [apps-discuss] Reserved URI query parameter in >>>>> draft-ietf-oauth-v2-bearer >>>>>=20 >>>>> Please elaborate on what the issue is then as protecting API = resources is >>> what OAuth is all about. >>>>>=20 >>>>> On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote: >>>>>=20 >>>>>=20 >>>>> That has nothing to do with this issue. The protected resources = API format >>> was never part of OAuth at any time. >>>>>=20 >>>>> EH >>>>>=20 >>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>>>> Sent: Tuesday, April 17, 2012 9:50 AM >>>>> To: Eran Hammer >>>>> Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; >>>>> draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss >>>>> Subject: Re: [apps-discuss] Reserved URI query parameter in >>>>> draft-ietf-oauth-v2-bearer >>>>>=20 >>>>>=20 >>>>> On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> (Sticking with the naivety:-) So, what's different there from how = the >>>>> base oauth draft registers client_id and shows how that can be = used >>>>> in a GET request? [1] >>>>>=20 >>>>> Big difference. The base draft specifies its own endpoints as part = of a >>> complete API package for obtaining authorization. These parameters = are >>> scoped only for the endpoints defined and not for any others. There = is no >>> possibility of conflict because the specification defines the entire = namespace. >>>>>=20 >>>>> OTOH, the bearer spec is applied to *any* web resources using = OAuth >>> authentication where some other namespace definition must exist. >>>>>=20 >>>>>=20 >>>>> If we had kept it all in one spec as it had originally been = drafted, >>>>> this would not be an issue, and it would be easier for = implementers >>>>> to understand. I don't know of anyone looking to implement the = bearer >>>>> spec independent of the base spec. (would be interested if anyone >>>>> does know of an implementation) >>>>=20 >>>=20 >>> -- >>> Mark Nottingham >>> http://www.mnot.net/ >>>=20 >>>=20 >>>=20 >>=20 >=20 -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Apr 18 14:43:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F89711E8094 for ; Wed, 18 Apr 2012 14:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4mYVOvVZWtx for ; Wed, 18 Apr 2012 14:43:00 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id C8F8121E8011 for ; Wed, 18 Apr 2012 14:42:59 -0700 (PDT) Received: from [10.31.73.218] (unknown [166.205.138.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 35E9850A6C; Wed, 18 Apr 2012 17:42:51 -0400 (EDT) References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0@P3PWEX2MB008.ex2.secureserver.net> <5837DDA7-19DC-4452-BD47-FFF6C674E179@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3DF@P3PWEX2MB008.ex2.secureserver.net> <217479C6-A2F8-4A06-A53E-E6BF4D1AB410@gmail.com> <8173C795-AC92-4E54-8D1C-18A88BFE1AC2@mnot.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEFD38@P3PWEX2MB008.ex2.secureserver.net> <3E66A1C7-97B7-43FE-A851-791F33C4A372@gmail.com> <075265B2-9C33-40D6-B9F7-707027502850@mnot.net> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B179) From: Mark Nottingham Date: Wed, 18 Apr 2012 14:42:48 -0700 To: Dick Hardt Cc: Ned Freed , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Apps Discuss , Pete Resnick Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 21:43:00 -0000 On 18/04/2012, at 2:33 PM, Dick Hardt wrote: >=20 > I have have read people proposing dropping it from the spec or pushing it t= o an Appendix. I agree the that the security issues need to be documented an= d the architectural issues called out. I think dropping it form the spec or p= ushing it to an appendix is a disservice to implementors and sends a message= that the IETF is not in touch with the realities of the web. I'm not sure why an appendix or separate document is a problem, but the hear= t of the current discussion is the language we put around it, not where it l= ives.=20= From paulej@packetizer.com Wed Apr 18 15:03: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 F2ED111E80A0 for ; Wed, 18 Apr 2012 15:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYTte3gtEkxb for ; Wed, 18 Apr 2012 15:03:28 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 404D611E809D for ; Wed, 18 Apr 2012 15:03:28 -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 q3IM3Pnk010242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Apr 2012 18:03:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334786607; bh=jUWRgBSNQnp6qae4uoFufBDbo6M2aaQ1Hz/Rf7ltHaQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=BtdHAIhAatAtRtL8+WTxWAsmiytvy29qmXGijZPCKX53zfoi49BELvAi9QHxlo4O7 OLgCAku6ktQxwLgDlxQZYLEIDEutbdy6JmFqXiYBT98EzyRJYw3K8oDbgA5qiEDDVi bJib9s7BmKxTEbQOCcUqnRGfFOGxGwkjSycYC6M4= From: "Paul E. Jones" To: "'Melvin Carvalho'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <04fb01cd1cf6$23131c80$69395580$@packetizer.com> In-Reply-To: Date: Wed, 18 Apr 2012 18:03:44 -0400 Message-ID: <069501cd1daf$20087580$60196080$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0696_01CD1D8D.98F83510" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0B/rNJdACTlkYtAqzWkh0CKCokFwIKVUEBldXKQJA= Content-Language: en-us Cc: 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 22:03:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0696_01CD1D8D.98F83510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, WebFinger does discovery on any URI. It might be "http", "mailto", "ftp", or "acct". So, it's not entirely correct to say that WebFinger does not do discovery using email addresses. I could change my server code pretty easily to accommodate mailto. Use of mailto was something discussed at length. As others pointed out, it was not necessarily favored by all, but it was recognized to be insufficient for some situations. Most importantly, nobody other than us geeks knows what the heck a "mailto" is. But, we do recognize that social sites like Twitter have accounts. Thus, after the lengthy debate that took place in several places, it was decided to go with "acct". It actually does have a useful purpose. And its construction is made to look similar to "mailto" so that the a user would just enter what they consider to be an "email" address, including things we know are not like user@twitter.com. Using "mailto" is technically incorrect, but users never have to know or care about that. Behind the scenes, we use "acct". I would personally never show an end user "acct:paulej@packetizer.com". Rather, I would just tell people that their account ID is "paulej@packetizer.com". That may or may not be their address. Query a Twitter account and it might return an email address that differs (if Twitter were to share that info). Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Wednesday, April 18, 2012 6:05 AM To: Paul E. Jones Cc: Mike Jones; Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) On 18 April 2012 01:59, Paul E. Jones wrote: Melvin, On "acct:". Humans will usually interchange an acct URI and mailto URI, probably never using either scheme directly in practice. That's natural and expected, if not desired. The intent is that we define something that looks like an email ID, but it's not an email ID. Some services, perhaps Twitter being most notable, do no use email addresses. Yet, you might have an account there. So, user@twitter.com might be used by humans and automated systems would convert that to acct:user@twitter.com . It would not be appropriate to use mailto: since it's not an email ID. We did have a lot of debate about the use of "acct". If you query my WebFinger server, you'll see that it will work without "acct:" prefixed, as that was a suggestion made a year or so ago. It will inspect the input and if it looks like an acct URI, it will assume it is. The "acct" URI will be returned as an alias. However, we should always use some kind of URI scheme to remove the guesswork. The client can often make a very good guess as to whether it's looking for a user account or something else. So, let it tell the server what it is looking for explicitly. We need a URI scheme, because WebFinger can be used to discover all kinds of information related to a given domain, not only user information. It can be used to query information about any URI, be that a web page, a user account, device on the network, etc. If we got rid of "acct", then we would have a system where we sometimes use a URI scheme and sometimes we do not. Results might be inconsistent, as the server may not make the right guess, unless we agreed that absence of a scheme defaults to "acct:". However, I see no reason for the client to be so lazy to not include "acct:". The user might (and probably will) exclude it, but the client code can add it. At this point, I'd argue the "train has left the station" on "acct", too. The current WebFinger spec exists (in part) to formally document that which has adopted; it's not a new thing. Paul, thank you for your explanation on lookup based on acct: (WebFinger) vs lookup based on mailto: (SWD). I think this is a major difference. The original WebFinger proposal was *supposed* to give extra information about an email address. >From wikipedia: "WebFinger is an Internet protocol that aims to provide information about people by their E-mail addresses." >From webfinger.org: "Put your email address into the box above, click the button" >From google code (the top hit on google): "making email addresses readable again" And perhaps most importantly from the spec, the first example: "Assume you receive an email from Bob..." However only SWD here is doing email based discovery (mailto:). WebFinger *now* doing acct: based discovery, which is a departure from the original use case. Im glad that some people have voiced support for acct:, but I still believe that to be a minority. I agree, that the new acct: scheme should for in another document, rather than shoe horned into an email based discovery system. IMHO, it's better to solve one problem (ie email based discovery) simply and well, than to half solve two problems (ie a new uri scheme for identity) in a single attempt. Paul A couple of points: 1. JSON ======= I think at the time webfinger was created in 2009, XML was the de facto serialization, used in AJAX, SOAP and many other systems. Today I'm hearing more and more, that both developers and publishers, want to work with JSON, rather than, having to support both xml and json. Content negotiation also confuses some publishers. In my view, this is a great simplification that webfinger can learn from SWD. 2. acct: scheme ============= The acct: URI scheme has not proved popular, imho, and has added a layer of complexity and confusion. How do we get from acct: to mailto:? When should you use acct: and when mailto: (the spec says acct:user@host may be different from mailto:user@host). What about the forms. How about linked data ecosystems that want to cross link identifiers, do they now have to consider both cases? >From the original post introducing acct: "I don't expect everyone to like this idea. I wish I could say I love it, but I am simply content with it." I dont know of anyone in the community (and correct me if this has changed) that really loves acct:, or perhaps even likes the acct: idea. SWD has shown you can do discovery without acct: and I think that's a big plus. One final side note is that this almost becomes trivial when you can do SPARQL queries. "void" is already registered by the W3C with IANA in .well-known in order to discover SPARQL endpoints. It may be overkill in some people's eyes, but Linked Data (which predates webfinger), particularly newer things like JSON LD, are a lot bigger than they were in 2009. In a few years it may become the definitive discovery mechanism anyway. ------=_NextPart_000_0696_01CD1D8D.98F83510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

WebFinger does discovery on any URI.  It might be = “http”, “mailto”, “ftp”, or = “acct”.  So, it’s not entirely correct to say = that WebFinger does not do discovery using email addresses.  I = could change my server code pretty easily to accommodate = mailto.

 

Use of mailto was something discussed at length.  As others = pointed out, it was not necessarily favored by all, but it was = recognized to be insufficient for some situations.  Most = importantly, nobody other than us geeks knows what the heck a = “mailto” is.  But, we do recognize that social sites = like Twitter have accounts.  Thus, after the lengthy debate that = took place in several places, it was decided to go with = “acct”.  It actually does have a useful purpose.  = And its construction is made to look similar to “mailto” so = that the a user would just enter what they consider to be an = “email” address, including things we know are not like = user@twitter.com.  Using “mailto” is technically = incorrect, but users never have to know or care about that.  Behind = the scenes, we use “acct”.  I would personally never = show an end user “acct:paulej@packetizer.com”.  Rather, = I would just tell people that their account ID is = “paulej@packetizer.com”.  That may or may not be their = address.  Query a Twitter account and it might return an email = address that differs (if Twitter were to share that = info).

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Wednesday, April 18, 2012 6:05 AM
To: Paul E. = Jones
Cc: Mike Jones; Apps Discuss
Subject: Re: = [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)

 

 

On 18 April 2012 01:59, Paul E. Jones <paulej@packetizer.com> = wrote:

Melvin,

 

On “acct:”…

 

Humans will usually interchange an acct URI and mailto URI, probably = never using either scheme directly in practice.  That’s = natural and expected, if not desired.  The intent is that we define = something that looks like an email ID, but it’s not an email = ID.  Some services, perhaps Twitter being most notable, do no use = email addresses.  Yet, you might have an account there.  So, = user@twitter.com might be used by humans and = automated systems would convert that to acct:user@twitter.com.  It would not be = appropriate to use mailto: since it’s not an email = ID.

 

We did have a lot of debate about the use of = “acct”.  If you query my WebFinger server, you’ll = see that it will work without “acct:” prefixed, as that was = a suggestion made a year or so ago.  It will inspect the input and = if it looks like an acct URI, it will assume it is.  The = “acct” URI will be returned as an alias.  However, we = should always use some kind of URI scheme to remove the guesswork.  = The client can often make a very good guess as to whether it’s = looking for a user account or something else.  So, let it tell the = server what it is looking for explicitly.

 

We need a URI scheme, because WebFinger can be used to discover all = kinds of information related to a given domain, not only user = information.  It can be used to query information about any URI, be = that a web page, a user account, device on the network, etc.  If we = got rid of “acct”, then we would have a system where we = sometimes use a URI scheme and sometimes we do not.  Results might = be inconsistent, as the server may not make the right guess, unless we = agreed that absence of a scheme defaults to “acct:”.  = However, I see no reason for the client to be so lazy to not include = “acct:”.  The user might (and probably will) exclude = it, but the client code can add it.

 

At this point, I’d argue the “train has left the = station” on “acct”, too.  The current WebFinger = spec exists (in part) to formally document that which has adopted; = it’s not a new thing.



Paul, thank you for your explanation on lookup = based on acct: (WebFinger) vs lookup based on mailto: (SWD).

I = think this is a major difference.

The original WebFinger proposal = was *supposed* to give extra information about an email = address.

From wikipedia:

"WebFinger is an Internet protocol that = aims to provide information about people by their E-mail = addresses."

From webfinger.org:

"Put your email address into the = box above, click the button"

From google code (the = top hit on google):

"making = email addresses readable again"

And perhaps = most importantly from the spec, the first example:

"Assume you receive an email from = Bob..."

However only SWD here is doing email based = discovery (mailto:).  WebFinger *now* doing = acct: based discovery, which is a departure from the original use = case. 

Im glad that some people have voiced support for = acct:, but I still believe that to be a minority.  I agree, that = the new acct: scheme should for in another document, rather than shoe = horned into an email based discovery system. 

IMHO, it's = better to solve one problem (ie email based discovery) simply and well, = than to half solve two problems (ie a new uri scheme for identity) in a = single attempt. 
 

 

Paul

 

A couple of = points:

1. JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the = time webfinger was created in 2009, XML was the de facto serialization, = used in AJAX, SOAP and many other systems.  Today I'm hearing more = and more, that both developers and publishers, want to work with JSON, = rather than, having to support both xml and json.  Content = negotiation also confuses some publishers.  In my view, this is a = great simplification that webfinger can learn from SWD.

2. acct: = scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The acct: URI = scheme has not proved popular, imho, and has added a layer of complexity = and confusion.  How do we get from acct: to mailto:?  When = should you use acct: and when mailto: (the spec says acct:user@host may = be different from mailto:user@host).  What about the forms.  How = about linked data ecosystems that want to cross link identifiers, do = they now have to consider both cases? 

From the original = post introducing acct:

"I don’t expect everyone to = like this idea. I wish I could say I love it, but I am simply content = with it."

I dont know of anyone in the community (and = correct me if this has changed) that really loves acct:, or perhaps even = likes the acct: idea.  SWD has shown you can do discovery without = acct: and I think that's a big plus.




One final side = note is that this almost becomes trivial when you can do SPARQL = queries.  "void" is already registered by the W3C with = IANA in .well-known in order to discover SPARQL endpoints.  It may = be overkill in some people's eyes, but Linked Data (which predates = webfinger), particularly newer things like JSON LD, are a lot bigger = than they were in 2009.  In a few years it may become the = definitive discovery mechanism = anyway.

 

------=_NextPart_000_0696_01CD1D8D.98F83510-- From john-ietf@jck.com Wed Apr 18 18:10: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 EF81711E80AE for ; Wed, 18 Apr 2012 18:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYYB8TWrVAOj for ; Wed, 18 Apr 2012 18:10:32 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 14E1511E80AD for ; Wed, 18 Apr 2012 18:10:32 -0700 (PDT) Received: from localhost ([::1] helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SKfoY-00017N-PH; Wed, 18 Apr 2012 21:05:39 -0400 Date: Wed, 18 Apr 2012 21:10:24 -0400 From: John C Klensin To: Ned Freed , "Murray S. Kucherawy" Message-ID: <8EF170975AE57842F498814A@JcK-HP8200.jck.com> In-Reply-To: <01OEFVMIOAU2012404@mauve.mrochek.com> References: <9452079D1A51524AA5749AD23E0039280F383E@exch-mbx901.corp.cloudmark.com> <01OEFVMIOAU2012404@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Call for Adoption: draft-hansen-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 01:10:37 -0000 +1 --On Tuesday, April 17, 2012 22:03 -0700 Ned Freed wrote: >> We're putting the finishing touches on >> draft-ietf-appsawg-media-type-regs and >> draft-ietf-appsawg-mime-charset-default will complete WGLC >> this week. In the mix now (by virtue of a reference from the >> former) is draft-hansen-media-type-suffix-regs, and so we'd >> like to adopt it as a WG document. > >> Please indicate your support or objection, and opinions >> thereto. > > I strongly prefer processing it as a WG document, especially > since the media types registration update now contains a > normative reference to it. > > Ned > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From internet-drafts@ietf.org Wed Apr 18 18:46: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 5186611E80B6; Wed, 18 Apr 2012 18:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCi7U6C5aea8; Wed, 18 Apr 2012 18:46:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53FC11E80AD; Wed, 18 Apr 2012 18:46:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120419014643.15202.39328.idtracker@ietfa.amsl.com> Date: Wed, 18 Apr 2012 18:46:43 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-hansen-media-type-suffix-regs-02.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, 19 Apr 2012 01:46:48 -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 Worki= ng Group of the IETF. Title : Additional Media Type Structured Syntax Suffixes Author(s) : Tony Hansen Filename : draft-hansen-media-type-suffix-regs-02.txt Pages : 7 Date : 2012-04-18 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hansen-media-type-suffix-regs-02.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-hansen-media-type-suffix-regs-02.t= xt From laurentwalter.goix@telecomitalia.it Wed Apr 18 20:34: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 5A73B11E807F for ; Wed, 18 Apr 2012 20:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuCzl-o1u9mB for ; Wed, 18 Apr 2012 20:34:41 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id A586E11E8075 for ; Wed, 18 Apr 2012 20:34:40 -0700 (PDT) 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.245.1; Thu, 19 Apr 2012 05:34:31 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Thu, 19 Apr 2012 05:34:31 +0200 From: Goix Laurent Walter To: Erik Wilde Date: Thu, 19 Apr 2012 05:34:13 +0200 Thread-Topic: draft-wilde-profile-link-01 published Thread-Index: Ac0boBGMCyMtL112Qnep8+g0jMKpZQBoMjvA Message-ID: References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <4F8B2231.1090300@berkeley.edu> <4F8BB227.2050904@berkeley.edu> <4F8BC5F8.8080800@berkeley.edu> In-Reply-To: <4F8BC5F8.8080800@berkeley.edu> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AllB E+ZS H9q5 Me1J RJ84 aejF ahHm a6oF cuxK dToF f8Wu gC6P iI21 ioAV mSSb m9/1; 3; YQBwAHAAcwAtAGQAaQBzAGMAdQBzAHMAQABpAGUAdABmAC4AbwByAGcAOwBkAHIAZQB0AEAAYgBlAHIAawBlAGwAZQB5AC4AZQBkAHUAOwByAGUAcwB0AC0AZABpAHMAYwB1AHMAcwBAAHkAYQBoAG8AbwBnAHIAbwB1AHAAcwAuAGMAbwBtAA==; Sosha1_v1; 7; {B0FEDE5A-AF2D-428E-BC69-9F974BC1E29B}; bABhAHUAcgBlAG4AdAB3AGEAbAB0AGUAcgAuAGcAbwBpAHgAQAB0AGUAbABlAGMAbwBtAGkAdABhAGwAaQBhAC4AaQB0AA==; Thu, 19 Apr 2012 03:34:13 GMT; UgA6ACAAZAByAGEAZgB0AC0AdwBpAGwAZABlAC0AcAByAG8AZgBpAGwAZQAtAGwAaQBuAGsALQAwADEAIABwAHUAYgBsAGkAcwBoAGUAZAA= x-cr-puzzleid: {B0FEDE5A-AF2D-428E-BC69-9F974BC1E29B} acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: application-layer protocols , REST Discuss Subject: [apps-discuss] R: draft-wilde-profile-link-01 published X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 03:34:50 -0000 VGhhbmsgeW91IGVyaWsgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbnMuIEluZGVlZCBteSBmaXJzdCBy ZWFkaW5nIG9mIHRoZSBkcmFmdCB3YXMgYmlhc2VkIGludG8gYW5vdGhlciB1bmRlcnN0YW5kaW5n IG9mIHRoZSAicHJvZmlsZSIga2V5d29yZCwgcmVsYXRlZCB0byB1c2VyL3Jlc291cmNlICJwcm9m aWxlIiByZXByZXNlbnRhdGlvbiBmb3JtYXQuIEkgaGF2ZSBub3cgY2xlYXIgdGhhdCB0aGlzIGlz IG5vdCB0aGUgcHVycG9zZSBvZiB0aGlzIGRyYWZ0Lg0KDQpBcyBJIHVuZGVyc3RhbmQgaXQgbm93 IGhpcyBsaW5rIHR5cGUgaXMgdGh1cyB0byBiZSB0eXBpY2FsbHkgaW5jbHVkZWQgaW4gdGhlIGRv Y3VtZW50cyB0aGVtc2VsdmVzIHRvIGJldHRlciBkZXNjcmliZSB0aGVpciBvd24gZm9ybWF0IChq dXN0IGxpa2UgdGhlIGh0bWwgInByb2ZpbGUiIHlvdSBtZW50aW9uZWQpLg0KDQpJIGFtIGJpYXNl ZCBieSB0aGUgY3VycmVudCBkaXNjdXNzaW9uL2FjdGl2aXR5IGdvaW5nIG9uIHdydCByZXNvdXJj ZSBkaXNjb3ZlcnkgKHNlZSB0aHJlYWQgb24gd2ViZmluZ2VyIHZzIHN3ZCkgdGhhdCByZWxpZXMg b24gInNpbWlsYXIiIGxpbmtzIHdpdGhpbiBhIGRlc2NyaXB0b3IgdG8gImRpc2NvdmVyIiBlbmRw b2ludHMgb2YgY2VydGFpbiB0eXBlcyB0byBhY2Nlc3MgZGlmZmVyZW50IGluZm9ybWF0aW9uIHJl bGF0ZWQgdG8gYSB1c2VyLiBPbmUgb2YgdGhlc2UgbGlua3Mgd2hpY2ggaXMgcXVpdGUgcG9wdWxh ciBpcyB0aGUgImh0dHA6Ly93ZWJmaW5nZXIubmV0L3JlbC9wcm9maWxlLXBhZ2UiIHRoYXQgbGlu a3MgdG8gYSB1c2VyIHByb2ZpbGUgZGVzY3JpcHRpb24sIGJ1dCB0aGF0IGRvZXNuJ3QgaW5kaWNh dGUgInlvdXIiIHR5cGUgb2YgcHJvZmlsZS4gSW4gb3RoZXIgd29yZHMgdGhhdCB0eXBlIG9mIGxp bmsgZG9lcyBub3QgYWxsb3cgeW91IHRvIGtub3cgaW4gYWR2YW5jZSB3aGV0aGVyIHRoYXQgcGFn ZSBjb250YWlucyBoY2FyZCBpbmZvcm1hdGlvbiBvciBvdGhlcnMuIEluIHRoZSBkaXNjb3Zlcnkg dXNlIGNhc2UgdGhpcyBpcyB1c2VmdWwgYXMgYmFzZWQgb24gdGhhdCBpbmZvcm1hdGlvbiBJIGNv dWxkIGF2b2lkIGFjY2Vzc2luZyB0aGF0IGVuZHBvaW50IChhbmQgcmVhZCB0aGUgInByb2ZpbGUi IGxpbmsgdHlwZSBpbiBpdCkgdG8gdW5kZXJzdGFuZCB0aGUgc3BlY2lmaWMgdHlwZS9mb3JtYXQg b2YgaW5mb3JtYXRpb24gaXQgY29udGFpbnMuDQoNCndhbHRlcg0KDQo+IC0tLS0tTWVzc2FnZ2lv IG9yaWdpbmFsZS0tLS0tDQo+IERhOiBFcmlrIFdpbGRlIFttYWlsdG86ZHJldEBiZXJrZWxleS5l ZHVdDQo+IEludmlhdG86IGx1bmVkw6wgMTYgYXByaWxlIDIwMTIgMTQuMTENCj4gQTogR29peCBM YXVyZW50IFdhbHRlcg0KPiBDYzogUkVTVCBEaXNjdXNzOyBhcHBsaWNhdGlvbi1sYXllciBwcm90 b2NvbHMNCj4gT2dnZXR0bzogUmU6IGRyYWZ0LXdpbGRlLXByb2ZpbGUtbGluay0wMSBwdWJsaXNo ZWQNCj4NCj4gaGVsbG8gd2FsdGVyLg0KPg0KPiBPbiAyMDEyLTA0LTE2IDA4OjA3ICwgR29peCBM YXVyZW50IFdhbHRlciB3cm90ZToNCj4gPj4gdGhhbmtzIGZvciB0aGUgcG9pbnRlciB0byB3ZWIg ZmluZ2VyLiBpIGFtIHN1cmUgdGhlcmUgYXJlIHF1aXRlIGENCj4gPj4gbnVtYmVyDQo+ID4+IG9m IG90aGVyIGZvcm1hdHMgb3V0IHRoZXJlIHVzaW5nIGh0bWwgcHJvZmlsZXMsIG1heWJlIGl0IHdv dWxkIGJlDQo+ID4+IGludGVyZXN0aW5nIHRvIGNyZWF0ZSBhIHNtYWxsIGxpc3Qgb2YgIndlbGwt a25vd24iIHByb2ZpbGVzLg0KPiA+IFt3YWx0ZXJdIHNvbWUgd29yayBpbiB0aGF0IGRpcmVjdGlv biBoYXMgYmVlbiBhbHJlYWR5IHJlY29yZGVkIGhlcmUNCj4gWzFdIHRoYXQgeW91IG1heSB3YW50 IHRvIGNoZWNrDQo+DQo+IHRoZXNlIGFyZSBsaW5rIHJlbGF0aW9uIHR5cGVzIGFuZCBub3QgcHJv ZmlsZSBpZGVudGlmaWVycywgcmlnaHQ/IGkgYW0NCj4gYSBiaXQgY29uY2VybmVkIHRvIHNlZSBl eHBlY3RlZCBtZWRpYSB0eXBlcyBlbmNvZGVkIGluIGxpbmsgcmVsYXRpb25zLA0KPiBmb3IgZXhh bXBsZSBpJ2QgcHJlZmVyIHRvIHNlZSBhICJjb250YWN0IiBsaW5rIHR5cGUgYW5kIHRoZW4gZ2V0 dGluZyBhDQo+IHZDYXJkIG9yIGFuIHhDYXJkIG9yIEhUTUwtZW1iZWRkZWQgaENhcmQgaXMgdXAg dG8gY29ubmVnIGFuZCB0aHVzIGENCj4gcnVudGltZSBpc3N1ZS4gZG9pbmcgaXQgdGhhdCB3YXkg ZnJlZXMgeW91IGZyb20gaGF2aW5nIHRvIG1pbnQgbmV3IGxpbmsNCj4gcmVsYXRpb24gdHlwZXMg d2hlbiB5b3Ugd2FudCB0byBzdXBwb3J0IG5ldyBtZWRpYSB0eXBlcyAod2hhdCBhYm91dA0KPiBG b2FGDQo+IGNvbnRhY3QgaW5mbywgZm9yIGV4YW1wbGU/KS4NCj4NCj4gPiBbd2FsdGVyXSBtYXli ZSBpIHdhc24ndCBjbGVhciBlbm91Z2ggSSBhcG9sb2dpemUuIEkgd2FzIGluZGVlZA0KPiByZWZl cnJpbmcgdG8gdGhlICJ0eXBlIiBhdHRyaWJ1dGUvcGFyYW1ldGVyIG9mIHRoZSAibGluayINCj4g ZWxlbWVudC9oZWFkZXIsIHdoaWNoIGlzIGFscmVhZHkgZGVmaW5lZCBib3RoIGluIFJGQzU5ODgg YW5kIGluIFhSRCBmb3INCj4gcmVmZXJlbmNpbmcgdGhlIG1lZGlhLXR5cGUgYXNzb2NpYXRlZCB3 aXRoIHRoYXQgbGluay4gSW4gdGhhdCBzZW5zZSBhbg0KPiBoY2FyZCBsaW5rIHJlbCB3b3VsZCB0 eXBpY2FsbHkgYmUgInRleHQvaHRtbCIgd2hpbHN0IGEgcG9jbyNtZQ0KPiByZXByZXNlbnRhdGlv biBvZiB0aGUgInByb2ZpbGUiIGxpbmsgY291bGQgYmUgImFwcGxpY2F0aW9uL2pzb24iLg0KPg0K PiBhbmQgdGhhdCBkb2Vzbid0IHJlYWxseSBoZWxwIGF0IGFsbC4gZm9yIGl0IHRvIGJlIGhlbHBm dWwsIHRoZSBwcm9maWxlDQo+IGRlc2NyaXB0aW9uIGxhbmd1YWdlIHdvdWxkIG5lZWQgdG8gaGF2 ZSBhIG1lZGlhIHR5cGUsIGFuZCB0aGVuIHlvdQ0KPiBjb3VsZA0KPiBpZGVudGlmeSBpdCBieSB0 aGF0LiBhbmQgZ2VuZXJhbGx5IHNwZWFraW5nLCBhICdwcm9maWxlJyBsaW5rIHNob3VsZA0KPiBu b3QNCj4gbmVlZCB0byBiZSBkZXJlZmVyZW5jZWQgdG8gYmUgdXNlZnVsLCBpdCdzIGFuIGlkZW50 aWZpZXIuIHRoYXQgYWxzbw0KPiBtZWFucyB0aGF0IGRlc2lnbmluZyBhbiBlbnZpcm9ubWVudCB3 aGVyZSBydW50aW1lIGxvb2t1cCBvZiB0aGUgcHJvZmlsZQ0KPiBkZXNjcmlwdGlvbiBpcyBuZWNl c3Nhcnkgd291bGQgYmUgYSB2aW9sYXRpb24gb2YgdGhlIHNwZWMsIGJlY2F1c2UNCj4gY2xpZW50 cyB3b3VsZCBub3QgYmUgYWJsZSB0byAidW5kZXJzdGFuZCIgdGhhdCB0aGUgbWVhbmluZyBvZiBh IHByb2ZpbGUNCj4gVVJJIGNoYW5nZXMgb3ZlciB0aW1lLiB0aGlzIGFsbW9zdCBhdXRvbWF0aWNh bGx5IG1lYW5zIHRoYXQgYW55IHVwZGF0ZXMNCj4gaW4gdGhlIHByb2ZpbGUgbmVlZCB0byBkb25l IGJ5IG1pbnRpbmcgYSBuZXcgcHJvZmlsZSBVUkksIGFuZCBpZiBpdCBpcw0KPiBkb25lIGJhY2t3 YXJkcyBjb21wYXRpYmxlLCB0aGVuIHJlcHJlc2VudGF0aW9ucyBjb25mb3JtaW5nIHRvIHRoZSBu ZXcNCj4gcHJvZmlsZSBzaG91bGQgbGlzdCBib3RoIHByb2ZpbGUgdmVyc2lvbnM6DQo+DQo+IDxs aW5rIHJlbD0icHJvZmlsZSIgaHJlZj0iaHR0cDovL21pY3JvZm9ybWF0cy5vcmcvcHJvZmlsZS9o Y2FyZCIvPg0KPiA8bGluayByZWw9InByb2ZpbGUiIGhyZWY9Imh0dHA6Ly9taWNyb2Zvcm1hdHMu b3JnL3Byb2ZpbGUvaGNhcmQvMi4wIi8+DQo+DQo+ID4gSG93ZXZlciBJIGRvIHVuZGVyc3RhbmQg dGhhdCB0aGlzIG1heSBub3QgYmUgZW5vdWdoIGZvciBjb3JyZWN0bHkNCj4gY2hhcmFjdGVyaXpp bmcgdGhlIGZvcm1hdCBvZiB0aGUgc3BlY2lmaWMgcHJvZmlsZSBpbmZvcm1hdGlvbjogaG93DQo+ IHdvdWxkIEkgaW5kaWNhdGUgaW4gZmFjdCB0aGF0IHRoaXMgInByb2ZpbGUiIGxpbmsvd2ViIHBh Z2UgaXMgaGNhcmQtDQo+IGVuYWJsZWQgb3Igbm90IGEgcHJpb3JpPyBTYW1lIGZvciBqc29uOiBw b2NvIGlzIGEgcG9wdWxhciBqc29uIGZvcm1hdA0KPiBmb3IgcmVwcmVzZW50aW5nIHByb2ZpbGUg aW5mbyBidXQgbWF5IG5vdCBiZSB0aGUgb25seSBvbmUuDQo+DQo+IGlmIHRoZXJlIGlzIGEgZm9y bWF0IGZvciBkZXNjcmliaW5nIHByb2ZpbGUgaW5mb3JtYXRpb24sIHRoZW4gaXQgc2hvdWxkDQo+ IGhhdmUgYSBtZWRpYSB0eXBlIGFuZCB0aGVuIHdlYiBjbGllbnRzIGNhbiB1c2UgdGhhdCBtZWRp YSB0eXBlLiBqdXN0DQo+IHJlZmVycmluZyB0byBpdCBhcyBKU09OIGlzIG5vdCB2ZXJ5IGhlbHBm dWwuIGJ1dCBldmVuIGlmIHRoZXJlIHdhcyBzdWNoDQo+IGEgbWVkaWEgdHlwZSwgaXQgd291bGQg bm90IGNoYW5nZSB0aGUgZmFjdCB0aGF0IHRoZSB3YXkgaG93ICdwcm9maWxlJw0KPiBpcw0KPiBk cmFmdGVkIHJpZ2h0IG5vdywgcnVudGltZSBhY2Nlc3MgdG8gcHJvZmlsZSBkZXNjcmlwdGlvbnMg aXMgbm90IHBhcnQNCj4gb2YNCj4gdGhlIGRlc2lnbjsgY2xpZW50cyBjb21wYXJlIHN1cHBvcnRl ZCBwcm9maWxlIFVSSXMgdG8gdGhlIHByb2ZpbGVzIHRoZXkNCj4gZmluZCBpbiBhIHJlcHJlc2Vu dGF0aW9uLCBhbmQgdGhlbiBkZWNpZGUgd2hhdCB0byBkby4NCj4NCj4gPiBNeSBwb2ludCBpcyBJ IG1heSBoYXZlIHRoZSBmb2xsb3dpbmcgeHJkIGF0IHRoaXMgc3RhZ2Ugd2l0aCB0aGUNCj4gcHJv ZmlsZSByZWwgbGlua3M6DQo+ID4gPExpbmsgcmVsPSJwcm9maWxlIiB0eXBlPSJ0ZXh0L2h0bWwi DQo+IGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbS9wcm9maWxlcy9qb2UiIC8+DQo+ID4gPExpbmsg cmVsPSJwcm9maWxlIiB0eXBlPSJ0ZXh0L2h0bWwiDQo+IGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNv bS9wcm9maWxlcy9qb2UvaGNhcmQiIC8+DQo+ID4gPExpbmsgcmVsPSJwcm9maWxlIiB0eXBlPSJh cHBsaWNhdGlvbi9qc29uIg0KPiBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vcHJvZmlsZXMvam9l L3BvY28iIC8+DQo+ID4gLi4ud2l0aG91dCBhbnkgY2xlYXIgdmlldyBvbiB3aGljaCAicHJvZmls ZSIgcHJvdmlkZXMgd2hpY2ggZm9ybWF0Lg0KPiA+IEkgaG9wZSBJIGhhdmUgY2xhcmlmaWVkIG15 IHBvaW50IGhlcmUgYW5kIHdlbGNvbWUgeW91ciBmZWVkYmFjayBvbg0KPiB0aGlzLg0KPg0KPiBu b3cgaSBhbSBnZXR0aW5nIHRoZSBpbXByZXNzaW9uIHRoYXQgeW91J3JlIGhhdmluZyBzb21lIG1p c2NvbmNlcHRpb25zDQo+IGFib3V0IHByb2ZpbGUuIHByb2ZpbGUgbGlua3MgYXJlIG5vdCBpbnRl bmRlZCB0byBsaW5rIHRvIHBhcnRpY3VsYXINCj4gcmVzb3VyY2UgdGhhdCBjb250YWlucyBkYXRh IG9mIGludGVyZXN0IHRvIHRoZSBjbGllbnQuIGluIHlvdXIgZXhhbXBsZSwNCj4gdGhlIHBhZ2Ug d291bGQgYmUgYWJvdXQgam9lLCBhbmQgam9lIG1pZ2h0IGRlY2lkZSB0byBlbWJlZCBoaXMNCj4g aW5mb3JtYXRpb24gdXNpbmcgaGNhcmQsIGFuZCB0aGVuIHRoZSBwYWdlIHdvdWxkIHNheQ0KPg0K PiA8bGluayByZWw9InByb2ZpbGUiIGhyZWY9Imh0dHA6Ly9taWNyb2Zvcm1hdHMub3JnL3Byb2Zp bGUvaGNhcmQiLz4NCj4NCj4gYW5kIGNsaWVudHMgY291bGQgZXh0cmFjdCBqb2UncyBoY2FyZCBp bmZvIGZyb20gdGhlIHBhZ2Ugd2l0aG91dCBldmVyDQo+IGFjY2Vzc2luZyBodHRwOi8vbWljcm9m b3JtYXRzLm9yZy9wcm9maWxlL2hjYXJkOyB0aGV5IHdvdWxkIHNpbXBseSBzZWUNCj4gdGhhdCBV UkkgYW5kIHRoZW4sIGlmIHRoZXkgc3VwcG9ydGVkIGhDYXJkLCB1bmRlcnN0YW5kIHRoYXQgdGhl IHBhZ2UNCj4gY29udGFpbiBlbWJlZGRlZCBoQ2FyZCBpbmZvcm1hdGlvbi4NCj4NCj4gaSBob3Bl IHRoYXQgY2xhcmlmaWVzIHRoaW5ncyBhIGJpdC4gY2hlZXJzLA0KPg0KPiBkcmV0Lg0KPg0KPiAt LQ0KPiBlcmlrIHdpbGRlIHwgbWFpbHRvOmRyZXRAYmVya2VsZXkuZWR1ICAtICB0ZWw6KzEtNTEw LTIwNjEwNzkgfA0KPiAgICAgICAgICAgICB8IFVDIEJlcmtlbGV5ICAtICBTY2hvb2wgb2YgSW5m b3JtYXRpb24gKElTY2hvb2wpIHwNCj4gICAgICAgICAgICAgfCBodHRwOi8vZHJldC5uZXQvbmV0 ZHJldCBodHRwOi8vdHdpdHRlci5jb20vZHJldCB8DQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1 b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUg aW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBk ZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmln b3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3Vt ZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVk aWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBk aXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlz IGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRl bmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBw cmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFp bCwgVGhhbmtzLg0KDQo= From pelle@kodfabrik.se Wed Apr 18 23:52: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 C8DD811E808A for ; Wed, 18 Apr 2012 23:52:51 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RonFVk2RYt4R for ; Wed, 18 Apr 2012 23:52:40 -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 70F1D11E8076 for ; Wed, 18 Apr 2012 23:52:38 -0700 (PDT) Received: by lbgc1 with SMTP id c1so1947019lbg.31 for ; Wed, 18 Apr 2012 23:52:38 -0700 (PDT) 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=JAkUElcPt6ZoR+Xf8lkYr+5dDA3DLvPCZVqr0iADp0s=; b=ewa92m2+GVBCHq/CTbQUrtTiy6BD/ah8tVxbmo3n1uirCV1XNxXdbpbclNMagHn2g6 CDJgkUeT5rtoVYRtFwyta7sksj7VyWKyj7B57BB4GKze8T/qsgaaJ04iGnIZLUk7eEXy FjBpVsvQnvMg10rKeKEuD1qlt1U4y3dIX4K8YIblK4WzY1GcQLoyj7LqTxQq0GFIFL4I PLaLjf+OufNS6pBVFYTaXLNKiYjAa2DD5/ami8ywr5bE6xUe2UF3EjnDfus/LXSZ9z4l s7MjAc40nU2vm6fyaFiSDB/qtbLlb0gEHUmHVg6ZgjGcIn7HcUScsF2TmgxK4VNicewa UKiA== Received: by 10.152.127.136 with SMTP id ng8mr883625lab.16.1334818357885; Wed, 18 Apr 2012 23:52:37 -0700 (PDT) Received: from [192.168.2.24] (mmx.flattr.net. [95.215.18.2]) by mx.google.com with ESMTPS id x1sm1762408lbj.4.2012.04.18.23.52.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Apr 2012 23:52:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_3CF97BFB-3DC0-411B-9410-3DD3C9B35D04" From: Pelle Wessman In-Reply-To: <069501cd1daf$20087580$60196080$@packetizer.com> Date: Thu, 19 Apr 2012 08:52:33 +0200 Message-Id: <15AB1540-7555-4C02-A29A-AAE0ADA786B3@kodfabrik.se> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <04fb01cd1cf6$23131c80$69395580$@packetizer.com> <069501cd1daf$20087580$60196080$@packetizer.com> To: Paul E. Jones X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnrRnNjWjzxTXS3HzMm1OGOqJtnIz7nPfSyLV7aU9ozNC18fQ+rl7vbgUd0gQtB0JsR+da/ Cc: 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 06:52:51 -0000 --Apple-Mail=_3CF97BFB-3DC0-411B-9410-3DD3C9B35D04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 While WebFinger officially requires an "acct" URI I believe almost all = current implementers accept a "pelle@kodfabrik.se" URI as being the same = as "acct:pelle@kodfabrik.se". Gmail.com does, StatusNet/Identi.ca does, = we at Flattr does. So there is a discrepancy between the WebFinger = specification and real life implementations. Examples: http://www.google.com/s2/webfinger/?q=3Dvoxpelli@gmail.com http://identi.ca/main/xrd?uri=3Dvoxpelli@identi.ca https://flattr.com/xrd/lrdd?uri=3Dvoxpelli@flattr.com Also, speaking from a Flattr-perspective, mail addresses and user = accounts are _not_ the same thing in our system. I myself have the = e-mail pelle@flattr.com but I have the web site account = voxpelli@flattr.com and the web site account pelle@flattr.com doesn't = belong to me but to one of our users. I believe most web sites, at least = the smaller ones, works like this - that the e-mail system and the web = system is completely separated from each other and that the user = identifiers in one can conflict with the identifiers in the other. I would say that a lookup for "mailto:pelle@flattr.com" should return = info about the user behind that e-mail address (if it should return = anything) but that a lookup for "pelle@flattr.com" or = "acct:pelle@flattr.com" should always return data about the web site = user and that clients should be encouraged to use "acct:" to make it = clear that they want the web site's user, but that they shouldn't be = required to do so. / Pelle 19 apr 2012 kl. 00:03 skrev Paul E. Jones: > Melvin, > =20 > WebFinger does discovery on any URI. It might be =93http=94, = =93mailto=94, =93ftp=94, or =93acct=94. So, it=92s not entirely correct = to say that WebFinger does not do discovery using email addresses. I = could change my server code pretty easily to accommodate mailto. > =20 > Use of mailto was something discussed at length. As others pointed = out, it was not necessarily favored by all, but it was recognized to be = insufficient for some situations. Most importantly, nobody other than = us geeks knows what the heck a =93mailto=94 is. But, we do recognize = that social sites like Twitter have accounts. Thus, after the lengthy = debate that took place in several places, it was decided to go with = =93acct=94. It actually does have a useful purpose. And its = construction is made to look similar to =93mailto=94 so that the a user = would just enter what they consider to be an =93email=94 address, = including things we know are not like user@twitter.com. Using =93mailto=94= is technically incorrect, but users never have to know or care about = that. Behind the scenes, we use =93acct=94. I would personally never = show an end user =93acct:paulej@packetizer.com=94. Rather, I would just = tell people that their account ID is =93paulej@packetizer.com=94. That = may or may not be their address. Query a Twitter account and it might = return an email address that differs (if Twitter were to share that = info). > =20 > Paul > =20 > From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]=20 > Sent: Wednesday, April 18, 2012 6:05 AM > To: Paul E. Jones > Cc: Mike Jones; Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD) > =20 > =20 >=20 > On 18 April 2012 01:59, Paul E. Jones wrote: > Melvin, > =20 > On =93acct:=94=85 > =20 > Humans will usually interchange an acct URI and mailto URI, probably = never using either scheme directly in practice. That=92s natural and = expected, if not desired. The intent is that we define something that = looks like an email ID, but it=92s not an email ID. Some services, = perhaps Twitter being most notable, do no use email addresses. Yet, you = might have an account there. So, user@twitter.com might be used by = humans and automated systems would convert that to = acct:user@twitter.com. It would not be appropriate to use mailto: since = it=92s not an email ID. > =20 > We did have a lot of debate about the use of =93acct=94. If you query = my WebFinger server, you=92ll see that it will work without =93acct:=94 = prefixed, as that was a suggestion made a year or so ago. It will = inspect the input and if it looks like an acct URI, it will assume it = is. The =93acct=94 URI will be returned as an alias. However, we = should always use some kind of URI scheme to remove the guesswork. The = client can often make a very good guess as to whether it=92s looking for = a user account or something else. So, let it tell the server what it is = looking for explicitly. > =20 > We need a URI scheme, because WebFinger can be used to discover all = kinds of information related to a given domain, not only user = information. It can be used to query information about any URI, be that = a web page, a user account, device on the network, etc. If we got rid = of =93acct=94, then we would have a system where we sometimes use a URI = scheme and sometimes we do not. Results might be inconsistent, as the = server may not make the right guess, unless we agreed that absence of a = scheme defaults to =93acct:=94. However, I see no reason for the client = to be so lazy to not include =93acct:=94. The user might (and probably = will) exclude it, but the client code can add it. > =20 > At this point, I=92d argue the =93train has left the station=94 on = =93acct=94, too. The current WebFinger spec exists (in part) to = formally document that which has adopted; it=92s not a new thing. >=20 >=20 > Paul, thank you for your explanation on lookup based on acct: = (WebFinger) vs lookup based on mailto: (SWD). >=20 > I think this is a major difference. >=20 > The original WebFinger proposal was *supposed* to give extra = information about an email address. >=20 > =46rom wikipedia: >=20 > "WebFinger is an Internet protocol that aims to provide information = about people by their E-mail addresses." >=20 > =46rom webfinger.org: >=20 > "Put your email address into the box above, click the button" >=20 > =46rom google code (the top hit on google): >=20 > "making email addresses readable again" >=20 > And perhaps most importantly from the spec, the first example: >=20 > "Assume you receive an email from Bob..." >=20 > However only SWD here is doing email based discovery (mailto:). = WebFinger *now* doing acct: based discovery, which is a departure from = the original use case. =20 >=20 > Im glad that some people have voiced support for acct:, but I still = believe that to be a minority. I agree, that the new acct: scheme = should for in another document, rather than shoe horned into an email = based discovery system. =20 >=20 > IMHO, it's better to solve one problem (ie email based discovery) = simply and well, than to half solve two problems (ie a new uri scheme = for identity) in a single attempt. =20 > =20 > =20 > Paul > =20 > A couple of points: >=20 > 1. JSON > =3D=3D=3D=3D=3D=3D=3D >=20 > I think at the time webfinger was created in 2009, XML was the de = facto serialization, used in AJAX, SOAP and many other systems. Today = I'm hearing more and more, that both developers and publishers, want to = work with JSON, rather than, having to support both xml and json. = Content negotiation also confuses some publishers. In my view, this is = a great simplification that webfinger can learn from SWD. >=20 > 2. acct: scheme > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The acct: URI scheme has not proved popular, imho, and has added a = layer of complexity and confusion. How do we get from acct: to mailto:? = When should you use acct: and when mailto: (the spec says = acct:user@host may be different from mailto:user@host). What about the = forms. How about linked data ecosystems that want to cross link = identifiers, do they now have to consider both cases? =20 >=20 > =46rom the original post introducing acct: >=20 > "I don=92t expect everyone to like this idea. I wish I could say I = love it, but I am simply content with it." >=20 > I dont know of anyone in the community (and correct me if this has = changed) that really loves acct:, or perhaps even likes the acct: idea. = SWD has shown you can do discovery without acct: and I think that's a = big plus. >=20 >=20 >=20 >=20 > One final side note is that this almost becomes trivial when you can = do SPARQL queries. "void" is already registered by the W3C with IANA in = .well-known in order to discover SPARQL endpoints. It may be overkill = in some people's eyes, but Linked Data (which predates webfinger), = particularly newer things like JSON LD, are a lot bigger than they were = in 2009. In a few years it may become the definitive discovery = mechanism anyway. > =20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_3CF97BFB-3DC0-411B-9410-3DD3C9B35D04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
While WebFinger officially requires an "acct" = URI I believe almost all current implementers accept a "pelle@kodfabrik.se" URI as being = the same as "acct:pelle@kodfabrik.se". Gmail.com does, StatusNet/Identi.ca does, = we at Flattr does. So there is a discrepancy between the WebFinger = specification and real life = implementations.

Examples:

http:/= /www.google.com/s2/webfinger/?q=3Dvoxpelli@gmail.com

Al= so, speaking from a Flattr-perspective, mail addresses and user accounts = are _not_ the same thing in our system. I myself have the e-mail pelle@flattr.com but I have the web = site account voxpelli@flattr.com and the web = site account pelle@flattr.com = doesn't belong to me but to one of our users. I believe most web sites, = at least the smaller ones, works like this - that the e-mail system and = the web system is completely separated from each other and that the user = identifiers in one can conflict with the identifiers in the = other.

I would say that a lookup for "mailto:pelle@flattr.com" should = return info about the user behind that e-mail address (if it should = return anything) but that a lookup for "pelle@flattr.com" or = "acct:pelle@flattr.com" should always return data about the web site = user and that clients should be encouraged to use "acct:" to make it = clear that they want the web site's user, but that they shouldn't be = required to do so.

/ = Pelle


19 apr 2012 kl. 00:03 skrev Paul = E. Jones:

 any URI.  It might be = =93http=94, =93mailto=94, =93ftp=94, or =93acct=94.  So, it=92s not = entirely correct to say that WebFinger does not do discovery using email = addresses.  I could change my server code pretty easily to = accommodate mailto.
 
Use of mailto was something = discussed at length.  As others pointed out, it was not necessarily = favored by all, but it was recognized to be insufficient for some = situations.  Most importantly, nobody other than us geeks knows = what the heck a =93mailto=94 is.  But, we do recognize that social = sites like Twitter have accounts.  Thus, after the lengthy debate = that took place in several places, it was decided to go with = =93acct=94.  It actually does have a useful purpose.  And its = construction is made to look similar to =93mailto=94 so that the a user = would just enter what they consider to be an =93email=94 address, = including things we know are not like user@twitter.com.  Using =93mailto=94 is = technically incorrect, but users never have to know or care about = that.  Behind the scenes, we use =93acct=94.  I would = personally never show an end user =93acct:paulej@packetizer.com=94.  = Rather, I would just tell people that their account ID is =93paulej@packetizer.com=94.  That = may or may not be their address.  Query a Twitter account and it = might return an email address that differs (if Twitter were to share = that info).
 Melvin = Carvalho [mailto:melvincarvalho@gmail.com] 
Sent: Wednesday, April 18, 2012 = 6:05 AM
To: Paul E. = Jones
Cc: Mike= Jones; Apps Discuss
Subject: Re: [apps-discuss] = [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)
 

 

On 18 April 2012 01:59, Paul E. Jones <paulej@packetizer.com> = wrote:
On = =93acct:=94=85
 user@twitter.com might be used by humans and = automated systems would convert that to acct:user@twitter.com.  It = would not be appropriate to use mailto: since it=92s not an email = ID.
We = did have a lot of debate about the use of =93acct=94.  If you query = my WebFinger server, you=92ll see that it will work without =93acct:=94 = prefixed, as that was a suggestion made a year or so ago.  It will = inspect the input and if it looks like an acct URI, it will assume it = is.  The =93acct=94 URI will be returned as an alias.  = However, we should always use some kind of URI scheme to remove the = guesswork.  The client can often make a very good guess as to = whether it=92s looking for a user account or something else.  So, = let it tell the server what it is looking for = explicitly.
We = need a URI scheme, because WebFinger can be used to discover all kinds = of information related to a given domain, not only user = information.  It can be used to query information about any URI, be = that a web page, a user account, device on the network, etc.  If we = got rid of =93acct=94, then we would have a system where we sometimes = use a URI scheme and sometimes we do not.  Results might be = inconsistent, as the server may not make the right guess, unless we = agreed that absence of a scheme defaults to =93acct:=94.  However, = I see no reason for the client to be so lazy to not include = =93acct:=94.  The user might (and probably will) exclude it, but = the client code can add it.
At = this point, I=92d argue the =93train has left the station=94 on =93acct=94= , too.  The current WebFinger spec exists (in part) to formally = document that which has adopted; it=92s not a new = thing.


Paul, = thank you for your explanation on lookup based on acct: (WebFinger) vs = lookup based on mailto: (SWD).

I think this is a major = difference.

The original WebFinger proposal was *supposed* to = give extra information about an email address.

=46rom = wikipedia:

"WebFinger is = an Internet protocol that aims to provide information about people by = their E-mail = addresses."

From webfinger.org:
 email= address into the = box above, click the button"

=46rom google code (the top = hit on google):

 email = addresses readable = again"

And perhaps most importantly from the spec, the = first example:

"Assume = you receive an email from = Bob..."

However only SWD here is doing email based = discovery (mailto:).  WebFinger *now* doing acct: based = discovery, which is a departure from the original use case.  

Im glad that some = people have voiced support for acct:, but I still believe that to be a = minority.  I agree, that the new acct: scheme should for in another = document, rather than shoe horned into an email based discovery = system.  

IMHO, it's better = to solve one problem (ie email based discovery) simply and well, than to = half solve two problems (ie a new uri scheme for identity) in a single = attempt.  
 
A couple of points:

1. JSON
=3D=3D=3D=3D=3D=3D=3D=

I think at the time webfinger was created in 2009, XML was the = de facto serialization, used in AJAX, SOAP and many other systems.  = Today I'm hearing more and more, that both developers and publishers, = want to work with JSON, rather than, having to support both xml and = json.  Content negotiation also confuses some publishers.  In = my view, this is a great simplification that webfinger can learn from = SWD.

2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
The acct: URI scheme has not proved popular, imho, and has added a = layer of complexity and confusion.  How do we get from acct: to = mailto:?  When should you use acct: and when mailto: (the spec says = acct:user@host may be different from mailto: 

=46rom the original = post introducing acct:

"I don=92t expect everyone to like this = idea. I wish I could say I love it, but I am simply content with = it."

I dont know of anyone in the community (and correct me if = this has changed) that really loves acct:, or perhaps even likes the = acct: idea.  SWD has shown you can do discovery without acct: and I = think that's a big plus.




One final side note is that = this almost becomes trivial when you can do SPARQL queries.  "void" = is already registered by the W3C with IANA in .well-known in order to = discover SPARQL endpoints.  It may be overkill in some people's = eyes, but Linked Data (which predates webfinger), particularly newer = things like JSON LD, are a lot bigger than they were in 2009.  In a = few years it may become the definitive discovery mechanism = anyway.
apps-discuss@ietf.org
> media type registrations SHOULD either >> >> a. specify that the "charset" parameter is not used for the defined >> subtype, because the charset information is transported inside >> the payload (such as in "text/xml"), or >> b. require explicit unconditional inclusion of the "charset" >> parameter eliminating the need for a default value. >> >> In accordance with option (a), above, registrations for "text/*" >> media types that can transport charset information inside the >> corresponding payloads (such as "text/html" and "text/xml") SHOULD >> NOT specify the use of a "charset" parameter, nor any default value, >> in order to avoid conflicting interpretations should the charset >> parameter value and the value specified in the payload disagree. >> ---------- >> >> Doesn't option (a) actually mean that a new default charset is >> now defined, perhaps called "embedded-ascii", in which all octets >> with values less than 128 must have the same meaning as the >> correspondding ASCII values and that all octet values greater >> than 127 may be ignored? This would allow naively processing a >> newly specified text/* type by displaying the content first using >> the "embedded-ascii" charset (ignoring non-ascii octets) and, >> hopefully, finding, by eye, the actual charset specified within >> and then re-displaying the content using that discovered charset. >> >> For instance how would a newly specified type similar to >> text/html with a document using the internal charset of "ebcdic" >> be handled? The current specification would deal with this merely >> by ensuring that a "charset=ebcdic" appeared in the Content-Type >> Mime field and also within the document itself. > I'm not sure I understand the question. > Types that transport charset information in-line will need to define how > to detect it. An example would be the algorithm in > http://www.w3.org/TR/xml/#sec-guessing > And yes, that works best if the encoding is compatible to US-ASCII (that > is, octets 0..127 represent the same characters as in the US-ASCII > encoding). > Do you think there's something we need to clarify here? As I understand it, the reason, originally, for having a major type of "text" is that if the minor type is unknown to the end user, it can be treated as "text/plain" and examined by a simple text editor to perhaps discover the content or a hint as to the appropriate application to process it. If the proposal here doesn't have this characteristic, it shouldn't be called "text", IMHO. It should be labeled "application/octet-stream". Now the most straight-forward way to accomplish this capability seems to be that one could examine the content with a text processor that displays octets below 128 as ASCII and, at least, does not self-destruct when it encounters octets above 127. This is different from the previous guarantee of only 7-bit ASCII as the default, but should be handled by many modern text handling programs. Thus my conclusion of the defacto default charset "embedded-ascii" alluded to above. -- Bill McQuillan From julian.reschke@gmx.de Thu Apr 19 01:08: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 6219521F84C5 for ; Thu, 19 Apr 2012 01:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.908 X-Spam-Level: X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQhucaUt7xHE for ; Thu, 19 Apr 2012 01:08:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 022E321F84EB for ; Thu, 19 Apr 2012 01:08:06 -0700 (PDT) Received: (qmail invoked by alias); 19 Apr 2012 08:07:59 -0000 Received: from p57A6F50E.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.245.14] by mail.gmx.net (mp001) with SMTP; 19 Apr 2012 10:07:59 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19XvoRJijxXlkqqE3nbpdzFohmuNGD3Qz2XIr0/zz HiHdrSQtrQMTYD Message-ID: <4F8FC7D7.8010604@gmx.de> Date: Thu, 19 Apr 2012 10:07:51 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Bill McQuillan References: <20120330125228.15497.35035.idtracker@ietfa.amsl.com> <1271382236.20120330141948@pobox.com> <4F8EF1D0.50001@gmx.de> <427958429.20120419005923@pobox.com> In-Reply-To: <427958429.20120419005923@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps-Discusssion Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 08:08:08 -0000 On 2012-04-19 09:59, Bill McQuillan wrote: > > On Wed, 2012-04-18, Julian Reschke wrote: >> On 2012-03-30 23:19, Bill McQuillan wrote: >>> In section 3: >>> >>> ---------- >>> In order to improve interoperability with deployed agents, "text/*" >>> media type registrations SHOULD either >>> >>> a. specify that the "charset" parameter is not used for the defined >>> subtype, because the charset information is transported inside >>> the payload (such as in "text/xml"), or >>> b. require explicit unconditional inclusion of the "charset" >>> parameter eliminating the need for a default value. >>> >>> In accordance with option (a), above, registrations for "text/*" >>> media types that can transport charset information inside the >>> corresponding payloads (such as "text/html" and "text/xml") SHOULD >>> NOT specify the use of a "charset" parameter, nor any default value, >>> in order to avoid conflicting interpretations should the charset >>> parameter value and the value specified in the payload disagree. >>> ---------- >>> >>> Doesn't option (a) actually mean that a new default charset is >>> now defined, perhaps called "embedded-ascii", in which all octets >>> with values less than 128 must have the same meaning as the >>> correspondding ASCII values and that all octet values greater >>> than 127 may be ignored? This would allow naively processing a >>> newly specified text/* type by displaying the content first using >>> the "embedded-ascii" charset (ignoring non-ascii octets) and, >>> hopefully, finding, by eye, the actual charset specified within >>> and then re-displaying the content using that discovered charset. >>> >>> For instance how would a newly specified type similar to >>> text/html with a document using the internal charset of "ebcdic" >>> be handled? The current specification would deal with this merely >>> by ensuring that a "charset=ebcdic" appeared in the Content-Type >>> Mime field and also within the document itself. > >> I'm not sure I understand the question. > >> Types that transport charset information in-line will need to define how >> to detect it. An example would be the algorithm in > >> http://www.w3.org/TR/xml/#sec-guessing > >> And yes, that works best if the encoding is compatible to US-ASCII (that >> is, octets 0..127 represent the same characters as in the US-ASCII >> encoding). > >> Do you think there's something we need to clarify here? > > As I understand it, the reason, originally, for having a major > type of "text" is that if the minor type is unknown to the end > user, it can be treated as "text/plain" and examined by a simple > text editor to perhaps discover the content or a hint as to the > appropriate application to process it. If the proposal here > doesn't have this characteristic, it shouldn't be called "text", > IMHO. It should be labeled "application/octet-stream". The proposal isn't called "text" :-). It just modifies the rules for text/* defaults in new registrations. Also, I do agree that this characteristic is desirable. The proposal IMHO doesn't change anything with respect to that. > Now the most straight-forward way to accomplish this capability > seems to be that one could examine the content with a text > processor that displays octets below 128 as ASCII and, at > least, does not self-destruct when it encounters octets above 127. > > This is different from the previous guarantee of only 7-bit ASCII > as the default, but should be handled by many modern text > handling programs. Thus my conclusion of the defacto default > charset "embedded-ascii" alluded to above. It would be helpful if you could make a concrete change proposal. Your concern seems to be about "a. specify that the "charset" parameter is not used for the defined subtype, because the charset information is transported inside the payload (such as in "text/xml"), or" Do you have a specific change proposal? ...also keep in mind that ASCII-ness of octets 0..127 may be desirable it's not the case today already (think UTF-16). Best regards, Julian From alexey.melnikov@isode.com Thu Apr 19 03:21: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 4336921F85D5; Thu, 19 Apr 2012 03:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.022 X-Spam-Level: X-Spam-Status: No, score=-102.022 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWo9wBOctK3V; Thu, 19 Apr 2012 03:21:02 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 665A821F85D3; Thu, 19 Apr 2012 03:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334830861; d=isode.com; s=selector; i=@isode.com; bh=bYmXXdxOIXci6mrxi8tVVt5P2u/u6Ei68JfnPjLCZ38=; 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=xPuX73rdoGniDorINo/Vj04XLlgew6tcYjtkhX7S2ac8gXBLwjBV8BKvK+QspbULQbiWSd v+H9ApeC0dxGbfR7tivVMm5h8sG3nWY0i64ymDbC1js6C0iLzpIXn02jFWKviD/b3IYzvF IIGiuo78YOnRUSo/B/V6MA1ygpi/u/w=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 19 Apr 2012 11:21:00 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F8F1733.1040407@isode.com> Date: Wed, 18 Apr 2012 20:34:11 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Claudio Allocchio References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-melnikov-smtp-priority-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 10:21:07 -0000 Hi Claudio, Thank you for the review and sorry for the delayed response: I've started writing some replies, but I only now got around to updating my copy of the document. On 28/03/2012 17:12, Claudio Allocchio 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-melnikov-smtp-priority-09 > Title: Simple Mail Transfer Protocol extension for Message Transfer > Priorities > Reviewer: Claudio Allocchio, GARR > Review Date: March 28th 2012 > IETF Last Call Date: 2012-03-28 > IESG Telechat Date: n/a > > Summary: > > In its declared scope, this document provides a mechamism (and > implementation suggestions) in order to enble a "real" priority > delivery service into the global e-mail handling scenario. > > However, it also introduces a concept idea on how to "tunnel" new SMTP > parameters requests via MTAs which do not support and ignore them, > embedding them into e-mail Heders fields. In doing this it breaks the > ideal separation between Envelope (SMTP) and Content (Headers and > bodyparts) in a different a new way than it was done before, because > is causes Headers to be able to modify Envelope parameters. There is > no negative consideration in this, but this feature should also be > stated more explicitly in the introduction. Right. Based on IETF LC feedback and after talking to Apps AD the plan is to split the document into 2: one will describe a pure SMTP extension (with no tunneling) and will be targeted at Proposed Standard. Another one will be an Experimental document that talks about tunneling and gatewaying. So I will have more explicit text about this in the latter document. > > In general the document is well specified, and no major technical > issues are present. However I suggest yet another turn of consideraion > for the state iself of the specification: the WG and many others > propose to go into Standards Track, but in order to do this there are > at least some more exlicit considerations to clarify into the text > itself. Also, it is not easy to guess what will be the adoption level > of this mechanism, That is true. > and the risk introduced by possible inaccurate implementations shall > also be evaluated before going Proposed Standard. Can you be more specific here? A MTA implementation which accepts the PRIORITY parameter and ignores it is not particularly harmful. An implementation that treats higher priority messages as lower priority messages is, well, broken. So I am not entirely sure what are you thinking about here. > Major Issues: > > The first major issue is non-technical. The e-mail service via SMTP > (and gateways and other related transport protocols) is best-effort, > often first-in/first-out based. And by itself, e-mail is a non > real-time service, In practice I might disagree with you on that, although I see your point. > like a chat, or text broadcast services: it is delivered into a > mailbox where the recipient will read it at his/her will. Although > many mail clients now uses a push-like model, delivering messages on > "always on" devices, the proposed new service extension aims to > provide differentiated service among messages. As correctly stated > into the document iself, there is a parallel between this and network > transport level services, where packets are prioritised. But also in > this case, the proposed mechanism will start to produce benefits only > when congestion in some parts of the mail transport system exists. > When congestion does not exist, the mechanisms will not result in > better service. This is not a drawback, but it should be stated more > explicitly in the document. Maybe expanding it into the 5.4 section, > where comparison with RFC2474 and RFC2205 are done. Good point. I will add some text about that. > > The other major issue to consider is the global trust model which is > needed to implement the mechanisms. There are suggestions in the > specification on how to enhance security when tunnelling across non > supporting MTAs, for example, but in the document there are also other > suggestions which consider the extension applicable easily only within > restricted trusted communities. This extension pretty much requires establishing of some trust between a sender and a recipient. I will make sure this is clear in the document. Some relevant text is already in the Security Considerations, but I will make it stronger. > This apparently contradictory point shall be explained better. If this > specification is going Proposed Standard, it shall be crystal clear > about these scenarios, because implementers who did not take part in > the original discussion will implement it, and thus all > pre-assupmtions made during the discussion process of the > specification discussion will not be available for them. > > Minor Issues: > > There is no discussion (explicit) about how this specification > interacts/interferes with anti-spam techniques like graylisting / > whitelisting. Section 5.1 suggests that shorter retry times shall be > used for higher priority messages, but it does not mention at all > graylisting, for example. This should be explicitly mentioned, and > some guidance / suggestion given, to ensure a coherent behaviour. As this extension requires some form of trust relationship and authentication (whether using SMTP AUTH, TLS, IP address whitelist, etc.), then greylisting should be disabled. But if you think this should be explicitly mentioned, I can mention it. > The sentence in section 2 "The most important reason for emails to be > delayed is a transient error response from the next MTA to which the > email must be transferred." should also explicitly refer to the > graylisting case (which also causes often a "reply" message to be > delivered before the original message is). Actually, I would rather delete the whole paragraph, as it doesn't add value to the spec (the definition is not used anywhere). Besides greylisting will cause transient errors. > Section 4.2: why allowing an X-something like X-Priority to be used? Because it is widely used (due to Exchange and some MUAs). > I understand why not "Importance" and why yes "Priority"... but... > Maybe this specification should "update" or even attempt to Obsolete > partially RFC2156? I don't think it would be a good idea to touch RFC 2156. What do you think is broken in it anyway? > Section 4.5: the text say that in case of mailing lists and aliases > the Header parameters tunnelling this specification extension SHOULD > retain the original priority. What about the many implementations > where headers are completely re-written and many parameters just > disappear? Some sentence should be given about this case, too. Can you suggest some specific case? SHOULD is here is exactly to address this kind of case, but I have hard time explaining why it can be violated in general terms. > Section 4.6... not all "non e-mail" environment allow addition of an > "header field"... how do we handle this? Are you talking about the following text: 1. If the destination environment is unable to provide an equivalent of the MT-PRIORITY parameter, the conforming MTA SHOULD behave as if it is relaying to a non-conformant SMTP (Section 4.4). ? (Which would imply adding a header field for tunneling the priority) If yes, I can clarify that this might be an exception. > > Section 9: given the current architecture, I'm very worried this will > ALWAYS happen (different behaviours because different support at > various MX-pointed servers). I'd make the consideration more explicit > and suggest a stronger guidance. Can you suggest an improved text? I've changed "advised" to "strongly advised", but have troubles improving this text. > > Appendix A, B, C are very environment specific. Appendix A and C, > however, seem very specific environment related (the NATO messaging > military convetions for "A" and the USA Civil Protecion service for > "C"). While "B" is really global, beacause it maps OSI X.400 service, > the other two appendix seems too environment specific for an > international standard RFC specification. I would suggest handling at > least "A' and "C" not as appendixes of this document, but as separate > short "mapping specification", also to enable further similar > documents to be published/registered more easily for other environments. As per my comment above, most of these will move to a separate specification about tunneling. Best Regards, Alexey From hartmans@mit.edu Thu Apr 19 06:11: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 C44A721F854F; Thu, 19 Apr 2012 06:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.336 X-Spam-Level: X-Spam-Status: No, score=-103.336 tagged_above=-999 required=5 tests=[AWL=-1.071, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq3ei1hdcLvP; Thu, 19 Apr 2012 06:11:09 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5A24521F84FF; Thu, 19 Apr 2012 06:11:09 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 868342039B; Thu, 19 Apr 2012 09:06:48 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3EA934765; Thu, 19 Apr 2012 09:11:07 -0400 (EDT) From: Sam Hartman To: William Mills References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> <1334695329.43020.YahooMailNeo@web31812.mail.mud.yahoo.com> <1334712238.64475.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Thu, 19 Apr 2012 09:11:07 -0400 In-Reply-To: <1334712238.64475.YahooMailNeo@web31804.mail.mud.yahoo.com> (William Mills's message of "Tue, 17 Apr 2012 18:23:58 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 13:11:09 -0000 >>>>> "William" == William Mills writes: William> OK, if this is covered by the mechanisms (which is William> something a GSS expert probably knows but I did not) then William> I'm less worried. Is it then worthwhile to add "Systems William> must know how to interpret critical mechanism attributes, William> but this is already required by mechanism specifications." William> in the section we're talking about to make it explicit William> rather than implicit? I'm now even more confused. I definitely don't understand how this discussion is about criticality of attributes. From lear@cisco.com Thu Apr 19 06:12: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 0B23121F854F for ; Thu, 19 Apr 2012 06:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.34 X-Spam-Level: X-Spam-Status: No, score=-110.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvsjY-qB8Vgz for ; Thu, 19 Apr 2012 06:12:00 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 83E7E21F84FF for ; Thu, 19 Apr 2012 06:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=3960; q=dns/txt; s=iport; t=1334841120; x=1336050720; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=nGuxxOzzkNgLe9vtV4RGSQ5Dnlb7FH9qmJoTqgfvA0Y=; b=QHKtJNbwgAXZY92QeW/bUk9nSmDs1Skl4vZOTV7XdYeVS44wQJV4tEj3 rUuNIdAXgMiiBXDYBpbnw6JWpVjHNRwwl1Bq9Jqdz3M7U/JjRryQ4sbze szjgHjEXhrSqN/1DACUgT+e+4NgNFAxLgKuHKONFOc026bhR1lLhHCcF6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAI4OkE+Q/khN/2dsb2JhbABDhWWrXIEHggkBAQEDARIBEFUBEAsYAgIFFgsCAgkDAgECAUUGDQEHAQEeh2gFmi2NEJMugS+NdoEYBJVvjlKBaYJp X-IronPort-AV: E=Sophos;i="4.75,446,1330905600"; d="scan'208";a="71278581" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 19 Apr 2012 13:11:59 +0000 Received: from elear-mac.local (ams3-vpn-dhcp4371.cisco.com [10.61.81.18]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3JDBwCP027842; Thu, 19 Apr 2012 13:11:59 GMT Message-ID: <4F900F29.7010900@cisco.com> Date: Thu, 19 Apr 2012 15:12:09 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120410125815.08d5c788@elandnews.com> In-Reply-To: <6.2.5.6.2.20120410125815.08d5c788@elandnews.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-lear-lisp-nerd-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 13:12:05 -0000 Hi SM, Thank you for reviewing draft-lear-lisp-nerd. Here's an update on this draft in response to your review: On 4/10/12 11:58 PM, S Moonesamy wrote: > Hi Eliot, > > draft-lear-lisp-nerd-08 presents an experimental database and a > discussion of methods to transport the mapping of EIDs to RLOCs to > routers in a reliable, scalable, and secure manner. It does not > conflict with any work currently being done in the Applications Area. > Given that it is an Independent Submission, these comments are optional. > > Overall, the draft was an interesting read. I don't the LISP > background to perform an adequate review. I skipped the lengthy > References section due to lack of time. > > In Section 2: > > "Operational functions are split into two components: database updates > and state exchange between ITR and ETR during a communication." > > I suggest expanding ITR and ETR on first use. done. > > In Section 2.1: > > "A NERD is generated by an authority that allocates provider > independent (PI) addresses (e.g., IANA or an RIR) which are used > by sites as EIDs." > > According to draft-ietf-lisp-06 (Section 3), PI addresses are assigned. Correct. > > In Section 2.3: > > "Each region runs a database authority. In this case, provider > independent address space is allocated to either Regional Internet > Registries (RIRs) or to affiliates of such organizations of > network operations guilds (NOGs)." > > I am at a loss here. The draft is talking about PI addresses for a > region. Such assignments are generally through RIRs and NIRs and not > through NOGs. Shouldn't the paragraph be discussing about > registration of entries on a regional basis without resorting to an > apex (see previous paragraph).? This section refers to various approaches that COULD be taken to manage NERDs. One such approach is that RIRs manage them. > > In Section 3: > > "The database name is an ASCII-encoded domain name, as specified in > [RFC5321]" > > Where is that specified in RFC 5321? I used Section 2.3.5. However... > > "This is the name that will appear in the Subject field of > the certificate used to verify the database." > > I suggest taking a look at RFC 6125, specifically Section 2.3. I will modify the text accordingly to use a DNS-ID. > > In Section 4.2: > > "This begs the question: how does a router know to retrieve version > 1105450 in our example above? It cannot. A redirect must be given > by the server to that URI when the router attempts to retrieve > differences from the current version, say, 1105503." > > I understand what you mean. Some readers might consider the above as > underspecified. > > In Section 5.4.1: > > "One possible method of doing this is provided in [RFC4108]" > > Section 3 mentions that Cryptographic Message Syntax was not used as > it is not widely deployed. Doesn't RFC 4108 require CMS? This text has been updated to indicate what was used when the experiment was performed. > > In Section 7: > > "Good old NNTP [RFC0977] itself provides two separate mechanisms > (one push and another pull) to provide a coherent update process." > > RFC 3977 obsoletes RFC 977. Ok. > > In Section 7.1: > > "While the administrative lines may appear to be correct, the > location of name servers may not be. If name servers sit within > PI address space, thus requiring LISP to reach, a circular > dependency is created." > > Wouldn't the service used to resolve the domain names, e.g. for HTTP, > also sit within PI address space? The problem (discussed in Section > 8.1) would also apply to any protocol that relies on DNS. PI doesn't mean routable. > > The little gem in the draft is 'The format of the AFI is specified by > IANA as "Address Family Numbers"'. Corrected as well. Thanks, Eliot From hartmans@mit.edu Thu Apr 19 06: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 2190221F85B8; Thu, 19 Apr 2012 06:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.247 X-Spam-Level: X-Spam-Status: No, score=-103.247 tagged_above=-999 required=5 tests=[AWL=-0.982, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tjl7xiCr3x5X; Thu, 19 Apr 2012 06:49:43 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0E821F85A3; Thu, 19 Apr 2012 06:49:43 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E83642024B; Thu, 19 Apr 2012 09:45:20 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B9DFC4765; Thu, 19 Apr 2012 09:49:39 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> <1334695329.43020.YahooMailNeo@web31812.mail.mud.yahoo.com> <1334712238.64475.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Thu, 19 Apr 2012 09:49:39 -0400 In-Reply-To: (Nico Williams's message of "Tue, 17 Apr 2012 22:33:40 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 13:49:44 -0000 >>>>> "Nico" == Nico Williams writes: Nico> The manner in which name attributes are conveyed by GSS Nico> mechanisms is mechanism-specific. If a GSS mechanism provides Nico> a way to indicate criticality then local policy MAY require Nico> that any given GSS name attribute be expressed using critical Nico> elements of the mechanism. What? I'm not sure I'd expect local policy to be where that gets decided. Nico> However, criticality is not Nico> exposed in this API because criticality is intended to be Nico> handled by local policy and the mechanisms. I disagree with the part of that sentence after because. I don't think we have consensus on why criticality is not part of the API. Nico> This means that a Nico> system that lacks local policy by which to deal with critical Nico> mechanism elements conveying name attributes should fail Nico> security context establishment when such critical elements are Nico> used by the peer. Nico> That's quite a mouthful, so I tend to prefer your text. Probably true but I don't see how this relates to the previous text nor that it is appropriate to add this text to the document at this point in the process. From laurentwalter.goix@telecomitalia.it Thu Apr 19 06:59: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 33BD821F8610 for ; Thu, 19 Apr 2012 06:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.568 X-Spam-Level: X-Spam-Status: No, score=-1.568 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-I2QyGWuwI1 for ; Thu, 19 Apr 2012 06:59:42 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB2B21F85AA for ; Thu, 19 Apr 2012 06:59:41 -0700 (PDT) Content-Type: multipart/mixed; boundary="_c2db4572-d713-4ec1-a412-00335b742a43_" 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.245.1; Thu, 19 Apr 2012 15:59:37 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Thu, 19 Apr 2012 15:59:37 +0200 From: Goix Laurent Walter To: Pelle Wessman , Paul E.Jones Date: Thu, 19 Apr 2012 15:59:34 +0200 Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: Ac0d+Rfy3zKsaijuRxaaC83Mc6YtygAOn2kg Message-ID: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <04fb01cd1cf6$23131c80$69395580$@packetizer.com> <069501cd1daf$20087580$60196080$@packetizer.com> <15AB1540-7555-4C02-A29A-AAE0ADA786B3@kodfabrik.se> In-Reply-To: <15AB1540-7555-4C02-A29A-AAE0ADA786B3@kodfabrik.se> 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: 'Apps Discuss' Subject: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 13:59:49 -0000 --_c2db4572-d713-4ec1-a412-00335b742a43_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE52EE1A704BGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE52EE1A704BGRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Possibly a standard discovery mechanism should rely on some sort of URI and= not a simple token string. URIs representing social network accounts are m= issing so far and at least this type of URI should be discoverable. Optiona= lly I believe any type of other uri may, but with no guarantee. It may be a= matter of permissions, internal db lookups and/or associations or else on = the server to decide whether to provide a meaningful response to it. This i= s somehow already clarified in section 5 of the wf draft. walter Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Pe= r conto di Pelle Wessman Inviato: gioved=EC 19 aprile 2012 13.53 A: Paul E.Jones Cc: 'Apps Discuss' Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) While WebFinger officially requires an "acct" URI I believe almost all curr= ent implementers accept a "pelle@kodfabrik.se" U= RI as being the same as "acct:pelle@kodfabrik.se". Gmail.com does, StatusNet/Identi.ca does, we at Flattr does. So there is a discre= pancy between the WebFinger specification and real life implementations. Examples: http://www.google.com/s2/webfinger/?q=3Dvoxpelli@gmail.com http://identi.ca/main/xrd?uri=3Dvoxpelli@identi.ca https://flattr.com/xrd/lrdd?uri=3Dvoxpelli@flattr.com Also, speaking from a Flattr-perspective, mail addresses and user accounts = are _not_ the same thing in our system. I myself have the e-mail pelle@flat= tr.com but I have the web site account voxpelli@fl= attr.com and the web site account pelle@flattr.= com doesn't belong to me but to one of our users. = I believe most web sites, at least the smaller ones, works like this - that= the e-mail system and the web system is completely separated from each oth= er and that the user identifiers in one can conflict with the identifiers i= n the other. I would say that a lookup for "mailto:pelle@flattr.com" should return info = about the user behind that e-mail address (if it should return anything) bu= t that a lookup for "pelle@flattr.com" or "acct:pe= lle@flattr.com" should always return data about the web site user and that = clients should be encouraged to use "acct:" to make it clear that they want= the web site's user, but that they shouldn't be required to do so. / Pelle 19 apr 2012 kl. 00:03 skrev Paul E. Jones: Melvin, WebFinger does discovery on any URI. It might be "http", "mailto", "ftp", = or "acct". So, it's not entirely correct to say that WebFinger does not do= discovery using email addresses. I could change my server code pretty eas= ily to accommodate mailto. Use of mailto was something discussed at length. As others pointed out, it= was not necessarily favored by all, but it was recognized to be insufficie= nt for some situations. Most importantly, nobody other than us geeks knows= what the heck a "mailto" is. But, we do recognize that social sites like = Twitter have accounts. Thus, after the lengthy debate that took place in s= everal places, it was decided to go with "acct". It actually does have a u= seful purpose. And its construction is made to look similar to "mailto" so= that the a user would just enter what they consider to be an "email" addre= ss, including things we know are not like user@twitter.com. Using "mailto" is technically incorrect, but users never have to= know or care about that. Behind the scenes, we use "acct". I would perso= nally never show an end user "acct:paulej@packetizer.com". Rather, I would= just tell people that their account ID is "paulej@packetizer.com". That may or may not be their address. Query a Twit= ter account and it might return an email address that differs (if Twitter w= ere to share that info). Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Wednesday, April 18, 2012 6:05 AM To: Paul E. Jones Cc: Mike Jones; Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) On 18 April 2012 01:59, Paul E. Jones > wrote: Melvin, On "acct:"... Humans will usually interchange an acct URI and mailto URI, probably never = using either scheme directly in practice. That's natural and expected, if = not desired. The intent is that we define something that looks like an ema= il ID, but it's not an email ID. Some services, perhaps Twitter being most= notable, do no use email addresses. Yet, you might have an account there.= So, user@twitter.com might be used by humans and= automated systems would convert that to acct:user@twitter.com. It would not be appropriate to use mailto: since it's= not an email ID. We did have a lot of debate about the use of "acct". If you query my WebFi= nger server, you'll see that it will work without "acct:" prefixed, as that= was a suggestion made a year or so ago. It will inspect the input and if = it looks like an acct URI, it will assume it is. The "acct" URI will be re= turned as an alias. However, we should always use some kind of URI scheme = to remove the guesswork. The client can often make a very good guess as to= whether it's looking for a user account or something else. So, let it tel= l the server what it is looking for explicitly. We need a URI scheme, because WebFinger can be used to discover all kinds o= f information related to a given domain, not only user information. It can= be used to query information about any URI, be that a web page, a user acc= ount, device on the network, etc. If we got rid of "acct", then we would h= ave a system where we sometimes use a URI scheme and sometimes we do not. = Results might be inconsistent, as the server may not make the right guess, = unless we agreed that absence of a scheme defaults to "acct:". However, I = see no reason for the client to be so lazy to not include "acct:". The use= r might (and probably will) exclude it, but the client code can add it. At this point, I'd argue the "train has left the station" on "acct", too. = The current WebFinger spec exists (in part) to formally document that which= has adopted; it's not a new thing. Paul, thank you for your explanation on lookup based on acct: (WebFinger) v= s lookup based on mailto: (SWD). I think this is a major difference. The original WebFinger proposal was *supposed* to give extra information ab= out an email address. >From wikipedia: "WebFinger is an Internet protocol that aims to provide information about p= eople by their E-mail addresses." >From webfinger.org: "Put your email address into the box above, click the button" >From google code (the top hit on google): "making email addresses readable again" And perhaps most importantly from the spec, the first example: "Assume you receive an email from Bob..." However only SWD here is doing email based discovery (mailto:). WebFinger *now* doing acct: based discovery, which is a departure f= rom the original use case. Im glad that some people have voiced support for acct:, but I still believe= that to be a minority. I agree, that the new acct: scheme should for in a= nother document, rather than shoe horned into an email based discovery syst= em. IMHO, it's better to solve one problem (ie email based discovery) simply an= d well, than to half solve two problems (ie a new uri scheme for identity) = in a single attempt. Paul A couple of points: 1. JSON =3D=3D=3D=3D=3D=3D=3D I think at the time webfinger was created in 2009, XML was the de facto ser= ialization, used in AJAX, SOAP and many other systems. Today I'm hearing m= ore and more, that both developers and publishers, want to work with JSON, = rather than, having to support both xml and json. Content negotiation also= confuses some publishers. In my view, this is a great simplification that= webfinger can learn from SWD. 2. acct: scheme =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The acct: URI scheme has not proved popular, imho, and has added a layer of= complexity and confusion. How do we get from acct: to mailto:? When shou= ld you use acct: and when mailto: (the spec says acct:user@host may be diff= erent from mailto:user@host). What about the forms. How= about linked data ecosystems that want to cross link identifiers, do they = now have to consider both cases? >From the original post introducing acct: "I don't expect everyone to like this idea. I wish I could say I love it, b= ut I am simply content with it." I dont know of anyone in the community (and correct me if this has changed)= that really loves acct:, or perhaps even likes the acct: idea. SWD has sh= own you can do discovery without acct: and I think that's a big plus. One final side note is that this almost becomes trivial when you can do SPA= RQL queries. "void" is already registered by the W3C with IANA in .well-kn= own in order to discover SPARQL endpoints. It may be overkill in some peop= le's eyes, but Linked Data (which predates webfinger), particularly newer t= hings like JSON LD, are a lot bigger than they were in 2009. In a few year= s it may become the definitive discovery mechanism anyway. _______________________________________________ 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_A09A9E0A4B9C654E8672D1DC003633AE52EE1A704BGRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Possibly a standard discovery mechanism should rely on some = sort of URI and not a simple token string. URIs representing social network= accounts are missing so far and at least this type of URI should be discoverable. O= ptionally I believe any type of other uri may, but with no guarantee. It ma= y be a matter of permissions, internal db lookups and/or associations or el= se on the server to decide whether to provide a meaningful response to it. This is somehow already clarified = in section 5 of the wf draft.

 

walter

 

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounce= s@ietf.org] Per conto di Pelle Wessman
Inviato: gioved=EC 19 aprile 2012 13.53
A: Paul E.Jones
Cc: 'Apps Discuss'
Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Dis= covery (SWD)

 

While WebFinger officially requires an "acct&qu= ot; URI I believe almost all current implementers accept a "pelle@kodfabrik.se" URI as being the s= ame as "acct:pelle@kodfabrik.se". Gmail.com does, StatusNet/Identi.ca does, = we at Flattr does. So there is a discrepancy between the WebFinger spe= cification and real life implementations.

 

Examples:

 

 

Also, speaking from a Flattr-perspective, mail addre= sses and user accounts are _not_ the same thing in our system. I myself hav= e the e-mail pelle@flattr.com but I have the web= site account voxpelli@flattr.com and the web = site account pelle@flattr.com doesn't belong to = me but to one of our users. I believe most web sites, at least the smaller = ones, works like this - that the e-mail system and the web system is comple= tely separated from each other and that the user identifiers in one can conflict with the identifiers in the = other.

 

I would say that a lookup for "mailto:pelle@flattr.com" should return info ab= out the user behind that e-mail address (if it should return anything) but = that a lookup for "pelle@flattr.co= m" or "acct:pelle@flattr.com" should always return data about the w= eb site user and that clients should be encouraged to use "acct:"= to make it clear that they want the web site's user, but that they shouldn= 't be required to do so.

 

/ Pelle

 

 

19 apr 2012 kl. 00:03 skrev Paul E. Jones:



Melvin,

 

WebFinger does discovery on any URI.  It might be “http”, “mailto”, “ftp”, or “acc= t”.  So, it’s not entirely correct to say that WebFinger d= oes not do discovery using email addresses.  I could change my server = code pretty easily to accommodate mailto.<= /o:p>

 

Use of mailto was something discussed at length.  As ot= hers pointed out, it was not necessarily favored by all, but it was recogni= zed to be insufficient for some situations.  Most importantly, nobody&nb= sp;other than us geeks knows what the heck a “mailto” is= .  But, we do recognize that social sites like Twitter have accounts.&= nbsp; Thus, after the lengthy debate that took place in several places, it was d= ecided to go with “acct”.  It actually does have a useful = purpose.  And its construction is made to look similar to “mailt= o” so that the a user would just enter what they consider to be an “email” address, including things we know are not like user@twitter.com.  Using “mailto” is technic= ally incorrect, but users never have to know or care about that.  Behi= nd the scenes, we use “acct”.  I would personally never show= an end user “acct:paulej@packetizer.com”.  Rather, I woul= d just tell people that their account ID is “paulej@packetizer.com”.  That may or may no= t be their address.  Query a Twitter account and it might return an email addres= s that differs (if Twitter were to share that info).

 

Paul

 

From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] 
Sent: Wednesday, A= pril 18, 2012 6:05 AM
To: Paul E. Jones<= br> Cc: Mike Jones; Ap= ps Discuss
Subject: Re: [apps= -discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

 

=  

On 18 April 2012 01:59, Paul E.= Jones <paulej@packetizer.com> wrote:

Melvin,

 

On “acct:”…

 

 

We did have a lot of debate about the use of “acctR= 21;.  If you query my WebFinger server, you’ll see that it will = work without “acct:” prefixed, as that was a suggestion made a year or so ago.  It will inspect the = input and if it looks like an acct URI, it will assume it is.  The = 220;acct” URI will be returned as an alias.  However, we should = always use some kind of URI scheme to remove the guesswork.  The client can often make a very good guess as to whether it’s looki= ng for a user account or something else.  So, let it tell the server w= hat it is looking for explicitly.

 

We need a URI scheme, because WebFinger can be used to disco= ver all kinds of information related to a given domain, not only user infor= mation.  It can be used to query information about any URI, be that a web page, a u= ser account, device on the network, etc.  If we got rid of “acct= ”, then we would have a system where we sometimes use a URI scheme an= d sometimes we do not.  Results might be inconsistent, as the server may not make the right guess, unless we agreed that absence = of a scheme defaults to “acct:”.  However, I see no reason= for the client to be so lazy to not include “acct:”.  The= user might (and probably will) exclude it, but the client code can add it.

 

At this point, I’d argue the “train has left the= station” on “acct”, too.  The current WebFinger spe= c exists (in part) to formally document that which has adopted; it’s not a new thing.=



Paul, thank you for your explanation on lookup based on acct: (WebFinger) v= s lookup based on mailto: (SWD).

I think this is a major difference.

The original WebFinger proposal was *supposed* to give extra information ab= out an email address.

>From wikipedia:

"WebFinger is an Internet protocol that = aims to provide information about people by their E-mail addresses."

From webfinger.org:

"Put your email a= ddress into the box a= bove, click the button"

>From google code (the top hit on google):

"making email addresses readable again"

And perhaps most importantly from the spec, the first example:

"Assume you receive an email from Bob..."

However only SWD here is doing email based discovery (mailto:).  WebFinger *now* doing acct: based discovery, wh= ich is a departure from the original use case.  

Im glad that some people have voiced support for acct:, but I still believe= that to be a minority.  I agree, that the new acct: scheme should for= in another document, rather than shoe horned into an email based discovery= system.  

IMHO, it's better to solve one problem (ie email based discovery) simply an= d well, than to half solve two problems (ie a new uri scheme for identity) = in a single attempt.  
 

 

Paul

 

A couple of points:

1. JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the time webfinger was created in 2009, XML was the de facto ser= ialization, used in AJAX, SOAP and many other systems.  Today I'm hear= ing more and more, that both developers and publishers, want to work with J= SON, rather than, having to support both xml and json.  Content negotiation also confuses some publishers.&nbs= p; In my view, this is a great simplification that webfinger can learn from= SWD.

2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The acct: URI scheme has not proved popular, imho, and has added a layer of= complexity and confusion.  How do we get from acct: to mailto:? = When should you use acct: and when mailto: (the spec says acct:user@host m= ay be different from mailto:= user@host).  What about the forms.  How about linked data ecosystems that want to = cross link identifiers, do they now have to consider both cases?  

>From the original post introducing acct:

"I don’t expect everyone to like this idea. I wish I could say I= love it, but I am simply content with it."

I dont know of anyone in the community (and correct me if this has changed)= that really loves acct:, or perhaps even likes the acct: idea.  SWD h= as shown you can do discovery without acct: and I think that's a big plus.<= br>



One final side note is that this almost becomes trivial when you can do SPA= RQL queries.  "void" is already registered by the W3C with I= ANA in .well-known in order to discover SPARQL endpoints.  It may be o= verkill in some people's eyes, but Linked Data (which predates webfinger), particularly newer things like JSON LD, are a lot big= ger than they were in 2009.  In a few years it may become the definiti= ve discovery mechanism anyway.

 

_______________________________= ________________
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_A09A9E0A4B9C654E8672D1DC003633AE52EE1A704BGRFMBX704BA02_-- --_c2db4572-d713-4ec1-a412-00335b742a43_ 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= --_c2db4572-d713-4ec1-a412-00335b742a43_-- From michiel@unhosted.org Thu Apr 19 07:47: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 7DAC121F858F for ; Thu, 19 Apr 2012 07:47:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WT2TBgAmUgam for ; Thu, 19 Apr 2012 07:47:43 -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 C559521F84E1 for ; Thu, 19 Apr 2012 07:47:43 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so8286170pbb.31 for ; Thu, 19 Apr 2012 07:47:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding :x-gm-message-state; bh=aZQnoD+tUp4poA92eXqdg8AVA74CC+WTVAgHqCWkxhc=; b=UPeZDOX1k0GUH69qhhomrlKtFxJilIJBBKzYJLQnrEHxEKMRrAj/XFNhPlpNXTB5Ud SyufrEuS/Zv+Mul1inN66ZVNVUA2+A+4ZbvKsxtzRyTkyebFO5pUo/t3VLp+udFhuq0p ZfDbQNjai9W1RX/DVzLkGun9acoRYlkju4vcaxz8yunUENKAE4iTPCySUlnvoErNFiFD FhxRp22nZHlfHiYnerWbxfrEP2cqwsxKm5Udrq4D2VrfcciPdndKGKRviF5o40dTYMok sWqATdvf54A6TTi6+GGTaNbp4Rs1VEXnXnvOfUAnvN8wNVKTbH3iI79d3cTU2QJe0/m9 yMIw== MIME-Version: 1.0 Received: by 10.68.221.74 with SMTP id qc10mr5087549pbc.80.1334846863620; Thu, 19 Apr 2012 07:47:43 -0700 (PDT) Received: by 10.68.27.138 with HTTP; Thu, 19 Apr 2012 07:47:43 -0700 (PDT) X-Originating-IP: [188.103.78.121] In-Reply-To: <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> Date: Thu, 19 Apr 2012 16:47:43 +0200 Message-ID: From: Michiel de Jong To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnU2LBMDRtA58cvujjTtPDVaxuQA+UcZr+so6dQOxxt1KO10uFlnWWNegY1gLjkaRFLIub7 Subject: [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 14:47:44 -0000 Hi, On Fri, Apr 13, 2012 at 7:45 PM, Murray S. Kucherawy wr= ote: > So the discussion on apps-discuss now should be focused on which of the t= wo should be the basis for forward progress. =A0I've placed both documents = in "Call for Adoption" state in the datatracker for appsawg. > > Let the games begin. > > -MSK Thanks a lot for taking this initiative, and especially everyone who has had to do concessions for this. I had thought that something like this was impossible in standards world, but i was happy to be proved wrong so far. I think this is a true show of the greatness of the open web. So about CORS headers: As one of the people who pushed for cross-origin instead of single-origin webfinger (https://groups.google.com/d/topic/webfinger/kfcVkqBX0tQ/discussion ), a detail that is left out-of-scope in swd, my personal position is the following: - When providing webfinger/swd I will always offer CORS headers (except when on an intranet), and I hope other people will too. - When using webfinger/swd as a relying party i will pretty much always need CORS headers - It's nice if the spec informs implementers of the importance of cross-origin http headers on what is essentially a cross-origin http protocol by its very nature. To give a bit of background, we use the current webfinger here: http://www.w3.org/community/unhosted/wiki/RemoteStorage to announce personal data services (in this case REST storage) to unhosted web apps (also called 'client-side' or 'html5' apps). An unhosted web app is anything that runs entirely in a browser and not on a server, so a chrome packaged app or a w3c widget or things like a javascript-based pacman game in a static web page. Since there is no server involved that can do the webfinger/swd lookup, it needs to be done with a cross-origin XHR call, hence the need for cross-origin headers. - Having said that, the important thing in my eyes is: consensus in itself. and i think no detail of the consensus (acct: or json or partial or private or what have you) can by definition be more important than actually reaching such consensus in the first place. Even if it's not the details we wanted, we'll make it work somehow. We might even need our own specific ways of using the spec for some purposes, maybe some add-on spec or some next version, but pinning down the syntactical compatibility of all relying parties and all providers is important now i think. So however you decide to merge the two specs, as long as it does roughly what it says on the tin, we'll update to the resulting merge. Cheers! Michiel de Jong (from the Unhosted project) From dick.hardt@gmail.com Wed Apr 18 10:15: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 C237D21F8572 for ; Wed, 18 Apr 2012 10:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkNlgvIiBRib for ; Wed, 18 Apr 2012 10:15:24 -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 5F0F921F854D for ; Wed, 18 Apr 2012 10:15:23 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so7150825pbb.31 for ; Wed, 18 Apr 2012 10:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=UCOeTKagB1X5QbRhVir6Mab7kiQSihmZh5DXcTF1Wbo=; b=pDDjgy+GJySkLnDG8Fs2wTgQTZu0BN1EK+2nawT2gQxtYLYPX52Cec00xIBxusbWq8 m7ELY0ezj66kVpwy5yjeh1pPU/HCIWqUaOIxSvGsfEUv12eg6tVzYJTR2oxuVE1zpfJl DgL13FzdNxmoQQW+pW0cOrjLBPdTIfmEemeiDZbYifnv0+nOngbH3icDbxUPn8eLthc4 7pSPEovB+hiVmFVdGJnXTKJgjgxFixPWHlUY2a9t0w1yQ5HqIhmQpRU9H/JM7Gm53mvS fuQ1UeDH5Th8J30vjYZRYUZo3GTe29uKfviPcgmzBGq6SJIB9xD9lmgsqZqsMWxKM1L9 TGZA== Received: by 10.68.224.195 with SMTP id re3mr7678904pbc.90.1334769323046; Wed, 18 Apr 2012 10:15:23 -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 r10sm24218574pbf.22.2012.04.18.10.15.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Apr 2012 10:15:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_8140DBB1-56E7-42A6-8C50-4BA937AF3D3B" From: Dick Hardt In-Reply-To: <1334764209.89788.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Wed, 18 Apr 2012 10:15:18 -0700 Message-Id: References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0@P3PWEX2MB008.ex2.secureserver.net> <5837DDA7-19DC-4452-BD47-FFF6C674E179@gmail.com> <1334764209.89788.YahooMailNeo@web31813.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Thu, 19 Apr 2012 07:48:55 -0700 Cc: Ned Freed , Apps Discuss , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Mark Nottingham , Pete Resnick Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 17:15:26 -0000 --Apple-Mail=_8140DBB1-56E7-42A6-8C50-4BA937AF3D3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 A useful distinction that I had not previously understood, thanks. On Apr 18, 2012, at 8:50 AM, William Mills wrote: > OAuth 2.0 is different from 1.0(and a) in that it's an auth framework = that deals with getting the tokens, but leaves the use of them to the = companion specs. I think this is what Eran is driving at, in the purest = semantic sense. The OAuth 2.0 API doesn't deal with protected resources = at all though, and the discussion about query parameters is all about = the protected resource. >=20 >=20 > From: Dick Hardt > To: Eran Hammer =20 > Cc: Ned Freed ; Apps Discuss = ; "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" = ; Mark Nottingham = ; Pete Resnick ; Dick Hardt = =20 > Sent: Tuesday, April 17, 2012 12:31 PM > Subject: Re: [apps-discuss] Reserved URI query parameter in = draft-ietf-oauth-v2-bearer >=20 > Please elaborate on what the issue is then as protecting API resources = is what OAuth is all about.=20 >=20 > On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote: >=20 >> That has nothing to do with this issue. The protected resources API = format was never part of OAuth at any time. >> =20 >> EH >> =20 >> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >> Sent: Tuesday, April 17, 2012 9:50 AM >> To: Eran Hammer >> Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; = draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss >> Subject: Re: [apps-discuss] Reserved URI query parameter in = draft-ietf-oauth-v2-bearer >> =20 >> =20 >> On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote: >>=20 >>=20 >> (Sticking with the naivety:-) So, what's different there from how the = base >> oauth draft registers client_id and shows how that can be used in a = GET >> request? [1] >>=20 >> Big difference. The base draft specifies its own endpoints as part of = a complete API package for obtaining authorization. These parameters are = scoped only for the endpoints defined and not for any others. There is = no possibility of conflict because the specification defines the entire = namespace. >>=20 >> OTOH, the bearer spec is applied to *any* web resources using OAuth = authentication where some other namespace definition must exist. >> =20 >> =20 >> If we had kept it all in one spec as it had originally been drafted, = this would not be an issue, and it would be easier for implementers to = understand. I don't know of anyone looking to implement the bearer spec = independent of the base spec. (would be interested if anyone does know = of an implementation) >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 --Apple-Mail=_8140DBB1-56E7-42A6-8C50-4BA937AF3D3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 A = useful distinction that I had not previously understood, = thanks.

On Apr 18, 2012, at 8:50 AM, William Mills = wrote:

OAuth 2.0 is different from = 1.0(and a) in that it's an auth framework that deals with getting the = tokens, but leaves the use of them to the companion specs.  I think = this is what Eran is driving at, in the purest semantic sense.  The = OAuth 2.0 API doesn't deal with protected resources at all though, and = the discussion about query parameters is all about the protected = resource.


=
From: Dick Hardt <dick.hardt@gmail.com>
= To: Eran Hammer <eran@hueniverse.com> =
Cc: Ned Freed = <ned.freed@mrochek.com>; = Apps Discuss <apps-discuss@ietf.org>; "draft-ietf-o= auth-v2-bearer.all@tools.ietf.org" <draft-ietf-o= auth-v2-bearer.all@tools.ietf.org>; Mark Nottingham <mnot@mnot.net>; Pete Resnick <presnick@qualcomm.com>; = Dick Hardt <dick.hardt@gmail.com>
= Sent: Tuesday, April = 17, 2012 12:31 PM
Subject: Re: [apps-discuss] Reserved URI query = parameter in draft-ietf-oauth-v2-bearer

Please elaborate on what the issue = is then as protecting API resources is what OAuth is all = about. 

On Apr 17, 2012, at 12:19 PM, Eran = Hammer wrote:

That has nothing to do with this issue. The protected = resources API format was never part of OAuth at any time.
 
EH
 
From: Dick Hardt = [mailto:dick.hardt@gmail.com] 
Sent:<= span class=3D"yiv131443081Apple-converted-space"> Tuesday, = April 17, 2012 9:50 AM
To: Eran = Hammer
Cc: Stephen = Farrell; Mark Nottingham; Pete Resnick; Ned Freed; draft-ietf-oauth-v2-bearer= .all@tools.ietf.org; Apps Discuss
Subject: Re: = [apps-discuss] Reserved URI query parameter in = draft-ietf-oauth-v2-bearer
 
 
On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote:


(Sticking = with the naivety:-) So, what's different there from how the = base
oauth = draft registers client_id and shows how that can be used in a = GET
request? = [1]

Big = difference. The base draft specifies its own endpoints as part of a = complete API package for obtaining authorization. These parameters are = scoped only for the endpoints defined and not for any others. There is = no possibility of conflict because the specification defines the entire = namespace.

OTOH, the bearer spec is applied to *any* web = resources using OAuth authentication where some other namespace = definition must exist.
 
 
If we had kept it all in one = spec as it had originally been drafted, this would not be an issue, and = it would be easier for implementers to understand. I don't know of = anyone looking to implement the bearer spec independent of the base = spec. (would be interested if anyone does know of an = implementation)


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

=

= --Apple-Mail=_8140DBB1-56E7-42A6-8C50-4BA937AF3D3B-- From dick.hardt@gmail.com Wed Apr 18 10:26: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 B9C4711E8091 for ; Wed, 18 Apr 2012 10:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwjvFc-lxUwO for ; Wed, 18 Apr 2012 10:26:08 -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 CB33F11E8081 for ; Wed, 18 Apr 2012 10:26:08 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so7162130pbb.31 for ; Wed, 18 Apr 2012 10:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=faK2jGU2Ubp7s5MjIEpFt6kwYmXyJgzCJbafOz1hvA8=; b=sCPu1OWSEl2TQ7Upp/k3s9b2kO9iUiKnaOcFID8twJ+h05vj9t15woZzuK80R4yAXo jG7JzLn8IzeK1XqHl6WBGhVFqyJeRFT+iYBcDSLqsD6RDAuYY6jDo4i0Xn39ZjdD7NgE TZwmuwIIv1LB/UR8heubGWPrqtCL9DBobhTcTwisq3R8d8T9C8qjwb7rp2C6LcBtKyM9 U9AG8EaldG0W0nnNRoqUJvtKBuXCeb9BVIoC9GsH7P2h1gu+7BXvDQY0dWaPLX7Hrrbz 5WkO7kkG4E3Ya9lw38rY3Mv5yhcr119wUde4prlvEKs9ZcVfypwy0JdjQWu+eW49wrHg wDKg== Received: by 10.68.230.40 with SMTP id sv8mr7863679pbc.124.1334769968528; Wed, 18 Apr 2012 10:26:08 -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 s7sm24234274pbl.31.2012.04.18.10.26.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Apr 2012 10:26:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_E202973B-8F0A-48E1-BD38-B90CCBAAF877" From: Dick Hardt In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3DF@P3PWEX2MB008.ex2.secureserver.net> Date: Wed, 18 Apr 2012 10:26:04 -0700 Message-Id: <217479C6-A2F8-4A06-A53E-E6BF4D1AB410@gmail.com> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0@P3PWEX2MB008.ex2.secureserver.net> <5837DDA7-19DC-4452-BD47-FFF6C674E179@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3DF@P3PWEX2MB008.ex2.secureserver.net> To: Eran Hammer X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Thu, 19 Apr 2012 07:48:55 -0700 Cc: Ned Freed , Apps Discuss , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Mark Nottingham , Pete Resnick Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 17:26:09 -0000 --Apple-Mail=_E202973B-8F0A-48E1-BD38-B90CCBAAF877 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Eran, I think I understand. To restate what you have said, specifying a query parameter as part of = the spec is "bad" web architecture and potentially sets a precedent for = other specifications to reserve a query parameter. Correct? The reality is that the world is a messy place. Developers hack the = architecture to accomplish goals not envisioned by the architects. The = architects can accept the reality of the world, or ignore it and lose = their relevance. In my opinion, putting the query parameter mechanism = into an appendix is ignoring the reality of current implementations. = Adding language to the spec that use of the query parameter is not = architecturally ideal, but accepts the reality of the current web would = be far more preferable. =20 -- Dick On Apr 17, 2012, at 8:28 PM, Eran Hammer wrote: > A site has a bunch of APIs. They want to use OAuth with Bearer tokens. = They can no longer use the access_token parameter for their own use = cases because the Bearer token specification creates a conflict. This = conflict does not exist with the use of the header. It does exist with = the use of the body if they have an access_token parameter already in = use. > =20 > The API format has nothing to do with OAuth, but the use of a query = parameter leaks into that namespace. > =20 > This isn=92t a critical issue. It is a hack =96 it has always been = since it was introduced in OAuth 1.0. The issue raised was about web = architecture in general and setting a precedence. I don=92t think it = will likely to create real-world problems, but the same goes for not = supporting this use case anymore (or at least explicitly marking it as = deprecated, maybe even demoted to an appendix documenting historical = use). > =20 > While the violation of the provider namespace is a significant = principal, I want to make sure my view isn=92t coming off as some severe = warning. Either way, it is not a big deal IMO. > =20 > EH > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Tuesday, April 17, 2012 12:32 PM > To: Eran Hammer > Cc: Dick Hardt; Stephen Farrell; Mark Nottingham; Pete Resnick; Ned = Freed; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss > Subject: Re: [apps-discuss] Reserved URI query parameter in = draft-ietf-oauth-v2-bearer > =20 > Please elaborate on what the issue is then as protecting API resources = is what OAuth is all about.=20 > =20 > On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote: >=20 >=20 > That has nothing to do with this issue. The protected resources API = format was never part of OAuth at any time. > =20 > EH > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Tuesday, April 17, 2012 9:50 AM > To: Eran Hammer > Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; = draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss > Subject: Re: [apps-discuss] Reserved URI query parameter in = draft-ietf-oauth-v2-bearer > =20 > =20 > On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote: >=20 >=20 >=20 > (Sticking with the naivety:-) So, what's different there from how the = base > oauth draft registers client_id and shows how that can be used in a = GET > request? [1] >=20 > Big difference. The base draft specifies its own endpoints as part of = a complete API package for obtaining authorization. These parameters are = scoped only for the endpoints defined and not for any others. There is = no possibility of conflict because the specification defines the entire = namespace. >=20 > OTOH, the bearer spec is applied to *any* web resources using OAuth = authentication where some other namespace definition must exist. > =20 > =20 > If we had kept it all in one spec as it had originally been drafted, = this would not be an issue, and it would be easier for implementers to = understand. I don't know of anyone looking to implement the bearer spec = independent of the base spec. (would be interested if anyone does know = of an implementation) --Apple-Mail=_E202973B-8F0A-48E1-BD38-B90CCBAAF877 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks Eran, I think I = understand.

To restate what you have said, specifying = a query parameter as part of the spec is "bad" web architecture and = potentially sets a precedent for other specifications to reserve a query = parameter. Correct?

The reality is that the = world is a messy place. Developers hack the architecture to accomplish = goals not envisioned by the architects. The architects can accept the = reality of the world, or ignore it and lose their relevance. In my = opinion, putting the query parameter mechanism into an appendix is = ignoring the reality of current implementations. Adding language to the = spec that use of the query parameter is not architecturally ideal, but = accepts the reality of the current web would be far more = preferable.
 
-- = Dick

On Apr 17, 2012, at 8:28 PM, Eran = Hammer wrote:

A = site has a bunch of APIs. They want to use OAuth with Bearer tokens. = They can no longer use the access_token parameter for their own use = cases because the Bearer token specification creates a conflict. This = conflict does not exist with the use of the header. It does exist with = the use of the body if they have an access_token parameter already in = use.
The = API format has nothing to do with OAuth, but the use of a query = parameter leaks into that namespace.
This = isn=92t a critical issue. It is a hack =96 it has always been since it = was introduced in OAuth 1.0. The issue raised was about web architecture = in general and setting a precedence. I don=92t think it will likely to = create real-world problems, but the same goes for not supporting this = use case anymore (or at least explicitly marking it as deprecated, maybe = even demoted to an appendix documenting historical = use).
While = the violation of the provider namespace is a significant principal, I = want to make sure my view isn=92t coming off as some severe warning. = Either way, it is not a big deal IMO.
 Dick = Hardt [mailto:dick.hardt@gmail.com] 
Sent: Tuesday, April 17, 2012 = 12:32 PM
To: Eran = Hammer
Cc: Dick Hardt; Stephen = Farrell; Mark Nottingham; Pete Resnick; Ned Freed; draft-ietf-o= auth-v2-bearer.all@tools.ietf.org; Apps = Discuss
Subject: Re: [apps-discuss] Reserved = URI query parameter in = draft-ietf-oauth-v2-bearer
 
Please elaborate on what = the issue is then as protecting API resources is what OAuth is all = about. 
On Apr 17, 2012, at 12:19 = PM, Eran Hammer wrote:
That = has nothing to do with this issue. The protected resources API format = was never part of OAuth at any = time.
EH

, Mark Nottingham , Pete Resnick Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 20:49:30 -0000 Eran: For most JSONP frameworks, the callback query parameter is magically = inserted, so it is not obvious to developers -> I agree it is a = potential gotcha for developers.=20 For OAuth the same could be true if using a library to insert the = oauth_token query parameter that might conflict with an oauth_query = parameter created by the developer. Much less likely given it is = prefixed with "oath_". In JSONP, using "jsonp_callback" would have = reduced the potential query name conflict. Mark: Would you point me to where this is bad practice as opposed to bad web = architecture? This is the only way to pass the parameter if doing JSONP -- there is no = access to the headers.=20 Many sites with substantial security expertise (Google, Facebook, = LinkedIn, Foursquare) have chosen to use the query parameter as opposed = to the header - both methods have been documented in the drafts since = the beginning. Clearly from a practical point of view the implementors = have chosen to use the query parameter.=20 When I use the term hack, I am referring to people building things = independent of specs because they are needing unspecified functionality. = I am not talking about some hackers. Having been building systems for some time, I fully appreciate the long = term issues with name spaces, and having a query parameter is not the = ideal solution, but given where the world is now, using a query = parameter is what everyone is choosing -- and I have yet to hear a good = reason why it is a bad solution -- and there is no known alternative to = working with JSONP. All the OAuth 2 deployments I have seen have been to fresh URLs where = name collision with oath_token is a non issue. Calling it the parameter = "token" would clearly be less than ideal, and lead to the issues that = JSONP has with "callback" Reserved words is one of those nasty gotchas that many languages have, = that have been solved by prefix hacks such as leading underscores etc. = or leading 'x-' -- Dick On Apr 18, 2012, at 1:00 PM, Eran Hammer wrote: > A good example is the 'callback' query parameter used in JSONP. >=20 > OAuth 2.0 originally used a 'callback' parameter for its own APIs but = we changed it after feedback from Facebook indicated there developers = were confused by it and in some cases, that caused conflict with = existing frameworks where 'callback' was always processed automatically. = So while OAuth does not use JSONP, it had to renamed the parameter to = 'redirect_uri' to avoid *potential* conflict. >=20 > EH >=20 >> -----Original Message----- >> From: Mark Nottingham [mailto:mnot@mnot.net] >> Sent: Wednesday, April 18, 2012 12:00 PM >> To: Dick Hardt >> Cc: Eran Hammer; Stephen Farrell; Pete Resnick; Ned Freed; = draft-ietf-oauth- >> v2-bearer.all@tools.ietf.org; Apps Discuss >> Subject: Re: [apps-discuss] Reserved URI query parameter in = draft-ietf- >> oauth-v2-bearer >>=20 >>=20 >> On 18/04/2012, at 10:26 AM, Dick Hardt wrote: >>=20 >>> Thanks Eran, I think I understand. >>>=20 >>> To restate what you have said, specifying a query parameter as part = of the >> spec is "bad" web architecture and potentially sets a precedent for = other >> specifications to reserve a query parameter. Correct? >>>=20 >>> The reality is that the world is a messy place. Developers hack the >> architecture to accomplish goals not envisioned by the architects. = The >> architects can accept the reality of the world, or ignore it and lose = their >> relevance. In my opinion, putting the query parameter mechanism into = an >> appendix is ignoring the reality of current implementations. Adding = language >> to the spec that use of the query parameter is not architecturally = ideal, but >> accepts the reality of the current web would be far more preferable. >>=20 >> ... Except that AIUI that method has been identified as not good = practice for >> entirely practical reasons, independent of the architectural reasons. >>=20 >> Putting that aside, there's a large difference between acknowledging = and >> documenting broad practice that's bad and sanctioning its use to = encourage >> further abuses. >>=20 >> Believe it or not, things like this *do* affect real people -- just = not the >> "hackers" who are working on OAuth. It affects people who run real = Web >> sites, because they have to consider what query parameters they can = use in >> their apps without danger of colliding with OAuth or the future = extensions >> that mimic it (do you *really* think this is going to be the Last = Authentication >> Scheme in the World?). It affects the folks who have to figure out = how to >> graft this mechanism onto existing systems that already use the = parameter >> name you've chosen. >>=20 >> I really don't want to have to go through a list of 50 such = "reserved" query >> parameters every time I write a new Web app in ten years. Sorry if = having a >> perspective that's further out than my nose gets me out of the = "hacker" >> bucket into the dreaded "architect" camp. Deploying and maintaining >> extremely large systems over a long period of time has taught me that = it's a >> good idea. YMMV. >>=20 >> Thanks, >>=20 >>>=20 >>> -- Dick >>>=20 >>> On Apr 17, 2012, at 8:28 PM, Eran Hammer wrote: >>>=20 >>>> A site has a bunch of APIs. They want to use OAuth with Bearer = tokens. >> They can no longer use the access_token parameter for their own use = cases >> because the Bearer token specification creates a conflict. This = conflict does >> not exist with the use of the header. It does exist with the use of = the body if >> they have an access_token parameter already in use. >>>>=20 >>>> The API format has nothing to do with OAuth, but the use of a query >> parameter leaks into that namespace. >>>>=20 >>>> This isn't a critical issue. It is a hack - it has always been = since it was >> introduced in OAuth 1.0. The issue raised was about web architecture = in >> general and setting a precedence. I don't think it will likely to = create real- >> world problems, but the same goes for not supporting this use case = anymore >> (or at least explicitly marking it as deprecated, maybe even demoted = to an >> appendix documenting historical use). >>>>=20 >>>> While the violation of the provider namespace is a significant = principal, I >> want to make sure my view isn't coming off as some severe warning. = Either >> way, it is not a big deal IMO. >>>>=20 >>>> EH >>>>=20 >>>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>>> Sent: Tuesday, April 17, 2012 12:32 PM >>>> To: Eran Hammer >>>> Cc: Dick Hardt; Stephen Farrell; Mark Nottingham; Pete Resnick; Ned >>>> Freed; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss >>>> Subject: Re: [apps-discuss] Reserved URI query parameter in >>>> draft-ietf-oauth-v2-bearer >>>>=20 >>>> Please elaborate on what the issue is then as protecting API = resources is >> what OAuth is all about. >>>>=20 >>>> On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote: >>>>=20 >>>>=20 >>>> That has nothing to do with this issue. The protected resources API = format >> was never part of OAuth at any time. >>>>=20 >>>> EH >>>>=20 >>>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>>> Sent: Tuesday, April 17, 2012 9:50 AM >>>> To: Eran Hammer >>>> Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; >>>> draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss >>>> Subject: Re: [apps-discuss] Reserved URI query parameter in >>>> draft-ietf-oauth-v2-bearer >>>>=20 >>>>=20 >>>> On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote: >>>>=20 >>>>=20 >>>>=20 >>>> (Sticking with the naivety:-) So, what's different there from how = the >>>> base oauth draft registers client_id and shows how that can be used >>>> in a GET request? [1] >>>>=20 >>>> Big difference. The base draft specifies its own endpoints as part = of a >> complete API package for obtaining authorization. These parameters = are >> scoped only for the endpoints defined and not for any others. There = is no >> possibility of conflict because the specification defines the entire = namespace. >>>>=20 >>>> OTOH, the bearer spec is applied to *any* web resources using OAuth >> authentication where some other namespace definition must exist. >>>>=20 >>>>=20 >>>> If we had kept it all in one spec as it had originally been = drafted, >>>> this would not be an issue, and it would be easier for implementers >>>> to understand. I don't know of anyone looking to implement the = bearer >>>> spec independent of the base spec. (would be interested if anyone >>>> does know of an implementation) >>>=20 >>=20 >> -- >> Mark Nottingham >> http://www.mnot.net/ >>=20 >>=20 >>=20 >=20 From dick.hardt@gmail.com Wed Apr 18 14:33: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 007FA11E8094 for ; Wed, 18 Apr 2012 14:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSj7EruQs-NM for ; Wed, 18 Apr 2012 14:33:16 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8F411E8097 for ; Wed, 18 Apr 2012 14:33:16 -0700 (PDT) Received: by dady13 with SMTP id y13so14353400dad.27 for ; Wed, 18 Apr 2012 14:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=IoyzWbT37Vh64MY8b/RHmJzfDGfIzaveQdMbVO4AuEU=; b=PlzShUFbWS9QbjXZ3Bsw7FOE70eyUcTQTh63Br+6MeWXzE7VBZusLDPRDkAcYvvNlr yE9Gw5Zo6FM5zub+dvjJ4T1goH9e0wnG1ZCYiyPudTcz7/0apfI4VulOEtB/d7SrPECP hf6kTgXegsAcpLDa1DtSqwK5o3fYS+ZOL4rv37zn2B+A6Dx9qRokjVgrMbri45NB/32M r/+54YJhtQXkhOWAaw5u4Q4Uy7/+ut9FX1ELqoIjLqaX2Wm714+T94y+cgv4PV0KCrCv O9VjcIYBV4+88DAthif54FZLPHo1PXUz2Ol0pFnjWi76HMzqnOhth39rsFMff2intEYT qtWQ== Received: by 10.68.138.195 with SMTP id qs3mr9543473pbb.91.1334784796022; Wed, 18 Apr 2012 14:33:16 -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 nt3sm225425pbc.14.2012.04.18.14.33.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Apr 2012 14:33:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <075265B2-9C33-40D6-B9F7-707027502850@mnot.net> Date: Wed, 18 Apr 2012 14:33:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0@P3PWEX2MB008.ex2.secureserver.net> <5837DDA7-19DC-4452-BD47-FFF6C674E179@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3DF@P3PWEX2MB008.ex2.secureserver.net> <217479C6-A2F8-4A06-A53E-E6BF4D1AB410@gmail.com> <8173C795-AC92-4E54-8D1C-18A88BFE1AC2@mnot.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEFD38@P3PWEX2MB008.ex2.secureserver.net> <3E66A1C7-97B7-43FE-A851-791F33C4A372@gmail.com> <075265B2-9C33-40D6-B9F7-707027502850@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Thu, 19 Apr 2012 07:48:55 -0700 Cc: Ned Freed , Apps Discuss , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Pete Resnick Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 21:33:17 -0000 On Apr 18, 2012, at 2:11 PM, Mark Nottingham wrote: >=20 > On 18/04/2012, at 1:49 PM, Dick Hardt wrote: >>=20 >> Mark: >>=20 >> Would you point me to where this is bad practice as opposed to bad = web architecture? >=20 > What are you looking for here? =46rom your comment: > AIUI that method has been identified as not good practice for entirely = practical reasons, independent of the architectural reasons. I looked through the thread and there was discussion comment about the = security issue of the token being part of the URL and being in logs, = caches etc.=20 I was looking for the list or discussion or whatever where this method = had been identified this as not a good practice. I apologize if it is = somewhere obvious that I did not find. It would be a good basis for = documentation per below. >=20 >> This is the only way to pass the parameter if doing JSONP -- there is = no access to the headers.=20 >>=20 >> Many sites with substantial security expertise (Google, Facebook, = LinkedIn, Foursquare) have chosen to use the query parameter as opposed = to the header - both methods have been documented in the drafts since = the beginning. Clearly from a practical point of view the implementors = have chosen to use the query parameter.=20 >>=20 >> When I use the term hack, I am referring to people building things = independent of specs because they are needing unspecified functionality. = I am not talking about some hackers. >>=20 >> Having been building systems for some time, I fully appreciate the = long term issues with name spaces, and having a query parameter is not = the ideal solution, but given where the world is now, using a query = parameter is what everyone is choosing -- and I have yet to hear a good = reason why it is a bad solution -- and there is no known alternative to = working with JSONP. >>=20 >> All the OAuth 2 deployments I have seen have been to fresh URLs where = name collision with oath_token is a non issue. Calling it the parameter = "token" would clearly be less than ideal, and lead to the issues that = JSONP has with "callback" >>=20 >> Reserved words is one of those nasty gotchas that many languages = have, that have been solved by prefix hacks such as leading underscores = etc. or leading 'x-' >=20 > I understand all of that. This thread has been about the difference = between documenting this kind of practice as a necessarily ~evil and = recommending it (with the voice of the IETF). I have have read people proposing dropping it from the spec or pushing = it to an Appendix. I agree the that the security issues need to be = documented and the architectural issues called out. I think dropping it = form the spec or pushing it to an appendix is a disservice to = implementors and sends a message that the IETF is not in touch with the = realities of the web.= From dick.hardt@gmail.com Wed Apr 18 14:52: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 D3FA211E8097 for ; Wed, 18 Apr 2012 14:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG6pOoWTaqtm for ; Wed, 18 Apr 2012 14:52:06 -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 1311611E80A0 for ; Wed, 18 Apr 2012 14:52:04 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so7404405pbb.31 for ; Wed, 18 Apr 2012 14:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=SanuOKxgAMg5MyPl+PAOVefc3TdJiM13++4T1+6mKO4=; b=FcvaiiTQgyDhGQwg3afT5l7Pjm4FUs0jWukF34asPyk7c3bBPMjiboEd48UTmofXSo FijTBfds3mPOq6J9hJeQaH0ZwTyc+WpoBmrTwuFQhEMyFlWyp5W5A61yPh1f+uErGgby wQhnsuBli75t2pteje3M6yKi5IVxXzIaN4967S/UfrrYdD6EKDlo0F+T2UkzcS4wJipS SyefBQkIFMNMMt5DZjRLMe63BoQUE1tlLtYAKn+ZIDnFYUny1HKasZ5HKvCXiDl5tFTA dYUlPGurOHvSvlHrl86vsjqmJ8uYHxprN1AVrVCcNYzv0ISGockT9WTDHt+qcC8Sr1+d jIPg== Received: by 10.68.221.136 with SMTP id qe8mr9694074pbc.108.1334785923576; Wed, 18 Apr 2012 14:52:03 -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 ox2sm253229pbc.55.2012.04.18.14.52.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Apr 2012 14:52:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Wed, 18 Apr 2012 14:51:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <125631DA-2FD1-4EF6-BB40-D6C7A1E13E2F@gmail.com> References: <4F866AC0.3000603@qualcomm.com> <01OE8FW1U53G00ZUIL@mauve.mrochek.com> <82462DAA-5118-4108-AA5C-FBEBBC563D4E@mnot.net> <01OE921YMRSW00ZUIL@mauve.mrochek.com> <4F8898A9.8020806@cs.tcd.ie> <22B64109-DAFD-4F2A-B1DA-5950E732882A@mnot.net> <4F88AA3A.8040401@cs.tcd.ie> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE83A2@P3PWEX2MB008.ex2.secureserver.net> <0608087F-1F83-4D19-9BA2-F2C58ED33F31@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FECDB0@P3PWEX2MB008.ex2.secureserver.net> <5837DDA7-19DC-4452-BD47-FFF6C674E179@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEE3DF@P3PWEX2MB008.ex2.secureserver.net> <217479C6-A2F8-4A06-A53E-E6BF4D1AB410@gmail.com> <8173C795-AC92-4E54-8D1C-18A88BFE1AC2@mnot.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEFD38@P3PWEX2MB008.ex2.secureserver.net> <3E66A1C7-97B7-43FE-A851-791F33C4A372@gmail.com> <075265B2-9C33-40D6-B9F7-707027502850@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Thu, 19 Apr 2012 07:48:55 -0700 Cc: Ned Freed , Apps Discuss , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , Pete Resnick Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2012 21:52:07 -0000 On Apr 18, 2012, at 2:42 PM, Mark Nottingham wrote: >=20 > On 18/04/2012, at 2:33 PM, Dick Hardt wrote: >=20 >>=20 >> I have have read people proposing dropping it from the spec or = pushing it to an Appendix. I agree the that the security issues need to = be documented and the architectural issues called out. I think dropping = it form the spec or pushing it to an appendix is a disservice to = implementors and sends a message that the IETF is not in touch with the = realities of the web. >=20 > I'm not sure why an appendix or separate document is a problem, but = the heart of the current discussion is the language we put around it, = not where it lives. Ease of understanding the RFC for implementers. Having the core spec and = the bearer spec separate is already a speed bump. Harder to understand = specifications are harder to implement correctly. Putting it in an = appendix means people will likely miss it, and be confused when the = widely available examples they see have a query parameter. Does that = answer your question on "why"? -- Dick= From turners@ieca.com Wed Apr 18 14:52: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 C013F21F8471 for ; Wed, 18 Apr 2012 14:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHwACaTzEQph for ; Wed, 18 Apr 2012 14:52:11 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [69.93.154.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6682921F846D for ; Wed, 18 Apr 2012 14:52:09 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id EB8033BEF274E; Wed, 18 Apr 2012 16:51:55 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id DDC953BEF2726 for ; Wed, 18 Apr 2012 16:51:55 -0500 (CDT) Received: from [71.191.9.245] (port=48617 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SKcn5-0003HR-9F; Wed, 18 Apr 2012 16:51:55 -0500 Message-ID: <4F8F377A.4010809@ieca.com> Date: Wed, 18 Apr 2012 17:51:54 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Tom Yu , Tobias Gondrom References: <4F8E377D.2010601@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-71-191-9-245.washdc.east.verizon.net (thunderfish.local) [71.191.9.245]:48617 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 12 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= X-Mailman-Approved-At: Thu, 19 Apr 2012 07:48:55 -0700 Cc: draft-ietf-krb-wg-des-die-die-die.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-krb-wg-des-die-die-die-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, 18 Apr 2012 21:52:12 -0000 On 4/18/12 2:02 PM, Tom Yu wrote: > Tobias Gondrom writes: > >> Major Comment: >> Agree that we should/must deprecate the weak cryptographic algorithms >> in Kerberos. >> However IMHO, I do not agree with the reasoning "to not actively >> discourage the use of RC4-HMAC" in section 7. >> I understand that interoperability is of major importance, but at some >> point a very weak algorithm will give users a false sense of security >> while exposing them to malicious attacks. And keeping RC4-HMAC >> supported does also expose the majority of the community (who is not >> using the deprecated Windows Versions) at possible risks to downgrade >> attacks. > > I believe RC4-HMAC (note: _not_ the 56-bit RC4-HMAC-EXP, which we > _are_ deprecating) is stronger than the DES enctypes that we are > deprecating. It has a 128-bit keysize, but might be somewhat weaker > than AES of the same keysize. I know of no reason yet to characterize > RC4-HMAC as "very weak"; it might very well be stronger than > triple-DES, which we are not deprecating at this time. > > Do you believe that RC4-HMAC poses anywhere near the level of risk > that single-DES does? If not, I prefer to handle deprecating RC4-HMAC > separately so that we avoid confusing the issues. > >> I believe even though the support of the complete Internet community >> is vital for standards, the support of deprecated (and AFAIK no longer >> supported OS versions) should not be the deciding argument behind our >> decisions here. Even old OS can be patched or fixed by the vendor or >> other service providers and it should not justify to keep a weak >> algorithm. > > Extended support is still available for some of the Windows operating > systems in question, but I believe Microsoft finds it uneconomical to > implement support for new crypto algorithms in these older versions of > Windows (which could very well still be around until 2015). > > RFC 4757 already mentions known weaknesses of RC4-HMAC, and we refer > to that RFC in the document's Security Considerations. Do you believe > that there should be a stronger warning? I'm *NOT* a cryptographer. While authoring RFC 6150 (https://datatracker.ietf.org/doc/rfc6150/), we had to come up with some text about RC4-HMAC. Here's what we ended up with: o The RC4-HMAC is supported in Microsoft's Windows 2000 and later versions of Windows for backwards compatibility with Windows 2000. As [RFC4757] stated, RC4-HMAC doesn't rely on the collision resistance property of MD4, but uses it to generate a key from a password, which is then used as input to HMAC-MD5. For an attacker to recover the password from RC4-HMAC, the attacker first needs to recover the key that is used with HMAC- MD5. As noted in [RFC6151], key recovery attacks on HMAC-MD5 are not yet practical. *If* you really need some more text, pointing to RFC 6150/6151 might be enough for this particular point. spt From tony@maillennium.att.com Thu Apr 19 06:35: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 6D27421F8636 for ; Thu, 19 Apr 2012 06:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.307 X-Spam-Level: X-Spam-Status: No, score=-105.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQWwa8++B4l6 for ; Thu, 19 Apr 2012 06:35:35 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id 0771821F863B for ; Thu, 19 Apr 2012 06:35:34 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 6a4109f4.0.1557671.00-288.4324389.nbfkord-smmo03.seg.att.com (envelope-from ); Thu, 19 Apr 2012 13:35:35 +0000 (UTC) X-MXL-Hash: 4f9014a70fbf7ae9-f98784ea2d64bfaaeb46fc789694e2bf880197b5 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 q3JDZXnY013131 for ; Thu, 19 Apr 2012 09:35:34 -0400 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 q3JDZTY0013105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Apr 2012 09:35:30 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Thu, 19 Apr 2012 09:35:07 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3JDZ7BV010669 for ; Thu, 19 Apr 2012 09:35:07 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3JDZ2j9010319 for ; Thu, 19 Apr 2012 09:35:02 -0400 Received: from [130.10.167.85] (vpn-130-10-167-85.vpn.mwst.att.com[130.10.167.85]) by maillennium.att.com (mailgw1) with ESMTP id <20120419133156gw1004oro9e> (Authid: tony); Thu, 19 Apr 2012 13:31:57 +0000 X-Originating-IP: [130.10.167.85] Message-ID: <4F901485.20800@maillennium.att.com> Date: Thu, 19 Apr 2012 09:35:01 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> In-Reply-To: <4F8D189A.3010304@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=w3AnSTxstZUA:10 a=vnNYxAp2wzwA:10 a=yBMqTHKFRa] X-AnalysisOut: [4A:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=2dTlHvqGvJKXRGe4yj0A:9 a=wPNLvfGTeEIA:10] X-Mailman-Approved-At: Thu, 19 Apr 2012 07:48:55 -0700 Cc: apps-discuss@ietf.org, "www-tag@w3.org List" Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 13:35:36 -0000 On 4/17/2012 3:15 AM, Julian Reschke wrote: > On 2012-04-17 02:53, Ned Freed wrote: >> ... >> I note that this raises the issue of what to do about fragment >> identifiers in >> the initial suffix registry document. Fragment identifiers don't >> really make >> sense for most of the suffixes defined there. The exceptions I see are >> +xml and >> +json. +json seems simple enough - refer to >> draft-ietf-appsawg-json-pointer-01. >> ... > > I think that would be premature. > > The question has come up several times, and I don't think we are near > any kind of even rough consensus about whether the spec should try to > define a fragment identifier syntax for "+json" (or even application/json). > >> +xml is a bigger issue. This is a document to populate the registry; >> it is not >> the place to define how fragment identifiers for XML work. But RFC >> 3023 section >> 5 seems a bit dated. And waiting for a revision for RFC 3023 when >> there isn't >> even an I-D doesn't sound like a good idea. So dated or not, I guess a >> reference to RFC 3023 is as good as it gets for now. So, I'm revising my draft where I'm actually *registering* a bunch of these structured suffixes. (draft-hansen-media-type-suffix-reg) What I'm thinking is that the fragment considerations section for each should simply point at the base application/whatever specification. That is, if application/SUFFIX has specific fragment identifiers associated with it, then anything with +SUFFIX (e.g., application/TYPE+SUFFIX) should accept the application/SUFFIX fragment identifiers as well as anything specific to the given media type. So I've added these Fragment identifier considerations sections to the suffixes that have an underlying media type registration. Media types using "+json" MUST accept any fragment identifiers defined for "application/json". Specific media types may identify additional fragment identifier considerations. I have similar text for +fastinfoset, +wbxml and +zip. This way, the definition of fragment identifiers for application/json can progress at its own pace, as can any definitions of fragment identifiers for application/fastinfoset, application/vnd.wap.wbxml and application/zip. In addition, I'm thinking draft-hansen-media-type-suffix-reg should have an IANA considerations note to add the Fragment identifier considerations section for +xml, with text similar to the above. (I think the basic paragraph could use a little wordsmithing, but what I have there should get the right idea across.) Tony Hansen From melvincarvalho@gmail.com Thu Apr 19 07:49: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 64D4021F85FF for ; Thu, 19 Apr 2012 07:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1NMciXM1KUE for ; Thu, 19 Apr 2012 07:49:50 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F94921F8621 for ; Thu, 19 Apr 2012 07:49:50 -0700 (PDT) Received: by yhkk25 with SMTP id k25so5117986yhk.31 for ; Thu, 19 Apr 2012 07:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dztrkkJO1i3eWhOpQxfa/7SFNK5fjDaM0Cj3Jp2g6d8=; b=B16uT0+CJBwmq6X1upQNd6IKRrTzIC1Fcflln1joRsNLVoVmOkWUvUHGv/A84jxFGa vFnaLdy1duO/lqX9SImVerBXozRlvoY1D5u5X5j1ib9/PY8rydM/Z6ao4nVxmA8DoJ6u wB2fpPqtghuKJPQ1M4b9uOGdwKKUo8j+MeRYroko/JBl8nRLpp8UuV1odt+TpuQbQat4 wWaLNCOxGvge2wyyPCcnzlLDeK3YPecRCQUt4kHyzjxijf5kYzG2INNJo2tGgsZlDv5V sOdNay41BidYHn11KljFtoBPWtb/lMsBOTjS7VyRMimz5rXTBYVZ64kQTygcNYYVp4SM i40A== MIME-Version: 1.0 Received: by 10.60.13.196 with SMTP id j4mr3461840oec.14.1334846989925; Thu, 19 Apr 2012 07:49:49 -0700 (PDT) Received: by 10.182.152.102 with HTTP; Thu, 19 Apr 2012 07:49:49 -0700 (PDT) In-Reply-To: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <04fb01cd1cf6$23131c80$69395580$@packetizer.com> <069501cd1daf$20087580$60196080$@packetizer.com> <15AB1540-7555-4C02-A29A-AAE0ADA786B3@kodfabrik.se> Date: Thu, 19 Apr 2012 16:49:49 +0200 Message-ID: From: Melvin Carvalho To: Goix Laurent Walter Content-Type: multipart/alternative; boundary=e89a8ff253d4a9fec704be094829 Cc: Apps Discuss Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 14:49:56 -0000 --e89a8ff253d4a9fec704be094829 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 19 April 2012 15:59, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > Possibly a standard discovery mechanism should rely on some sort of URI > and not a simple token string. URIs representing social network accounts > are missing so far and at least this type of URI should be discoverable. > Optionally I believe any type of other uri may, but with no guarantee. It > may be a matter of permissions, internal db lookups and/or associations o= r > else on the server to decide whether to provide a meaningful response to > it. This is somehow already clarified in section 5 of the wf draft. > Why do you say "URIs representing social accounts are missing so far"? And if so, from which systems? For example, Facebook has a pretty good system for representing their accounts as URIs (open graph protocol), as does SIOC, and people like status.net (inventor of OStatus who have a pretty good FOAF impl.) etc. All of these use HTTP URIs as their machine representation, rather than any proposed acct: scheme, for example. I thought this use case is mainly relevant to the big webmail providers. Email style discovery is missing (apart from the specific case of a public key in GPG), so if you want a full Web sytle solution use void (already registered with IANA). If void is too complex, choose something simpler. SWD seems a simpler solution, at this point, technically. WF may have the lead on adoption, I dont know. Perhaps something can be learnt by each system from each other ... e.g. the JSON vs XML discussion. Merging the best parts from both specs could be a great idea... As for non mailto: URI schemes, that in itself is an interesting problem, perhaps a big topic. To me, xmpp: is a very interesting candidate. Again void can be used for this, but maybe WF/SWD is an interesting thing to deploy. Having a lookup for the tel: scheme would be kind of amazing ... but is a whole problem in itself, including finding the well known location. HTTP discovery is really in advanced stages, with mature deployments, under the W3C / Linked Data. I would personally NOT encourage acct: lookup because it's just too confusing for the average developer, fractures identity, does not provide HTTP style 'follow your nose', and ultimately, will probably not be a long lived identifier, given how quickly the web identity space evolves (just my 2 cents). I think sweet spot here is find the path of least resistance, for a really good discovery system for email addresses. Other schemes *could* be a plus depending on the context, but the most compelling and useful lookup that is filling a gap I think, is mailto: based. **** > > ** ** > > walter**** > > ** ** > > *Da:* apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] > *Per conto di *Pelle Wessman > *Inviato:* gioved=EC 19 aprile 2012 13.53 > *A:* Paul E.Jones > *Cc:* 'Apps Discuss' > *Oggetto:* Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > Discovery (SWD)**** > > ** ** > > While WebFinger officially requires an "acct" URI I believe almost all > current implementers accept a "pelle@kodfabrik.se" URI as being the same > as "acct:pelle@kodfabrik.se". Gmail.com does, StatusNet/Identi.ca does, > we at Flattr does. So there is a discrepancy between the WebFinger > specification and real life implementations.**** > > ** ** > > Examples:**** > > ** ** > > http://www.google.com/s2/webfinger/?q=3Dvoxpelli@gmail.com**** > > http://identi.ca/main/xrd?uri=3Dvoxpelli@identi.ca**** > > https://flattr.com/xrd/lrdd?uri=3Dvoxpelli@flattr.com**** > > ** ** > > Also, speaking from a Flattr-perspective, mail addresses and user account= s > are _not_ the same thing in our system. I myself have the e-mail > pelle@flattr.com but I have the web site account voxpelli@flattr.com and > the web site account pelle@flattr.com doesn't belong to me but to one of > our users. I believe most web sites, at least the smaller ones, works lik= e > this - that the e-mail system and the web system is completely separated > from each other and that the user identifiers in one can conflict with th= e > identifiers in the other.**** > > ** ** > > I would say that a lookup for "mailto:pelle@flattr.com = " > should return info about the user behind that e-mail address (if it shoul= d > return anything) but that a lookup for "pelle@flattr.com" or " > acct:pelle@flattr.com" should always return data about the web site user > and that clients should be encouraged to use "acct:" to make it clear tha= t > they want the web site's user, but that they shouldn't be required to do = so. > **** > > ** ** > > / Pelle**** > > ** ** > > ** ** > > 19 apr 2012 kl. 00:03 skrev Paul E. Jones:**** > > > > **** > > Melvin,**** > > **** > > WebFinger does discovery on *any* URI. It might be =93http=94, =93mailto= =94, > =93ftp=94, or =93acct=94. So, it=92s not entirely correct to say that We= bFinger does > not do discovery using email addresses. I could change my server code > pretty easily to accommodate mailto.**** > > **** > > Use of mailto was something discussed at length. As others pointed out, > it was not necessarily favored by all, but it was recognized to be > insufficient for some situations. Most importantly, *nobody* other than > us geeks knows what the heck a =93mailto=94 is. But, we do recognize tha= t > social sites like Twitter have accounts. Thus, after the lengthy debate > that took place in several places, it was decided to go with =93acct=94. = It > actually does have a useful purpose. And its construction is made to loo= k > similar to =93mailto=94 so that the a user would just enter what they con= sider > to be an =93email=94 address, including things we know are not like > user@twitter.com. Using =93mailto=94 is technically incorrect, but users > never have to know or care about that. Behind the scenes, we use =93acct= =94. > I would personally never show an end user =93acct:paulej@packetizer.com= =94. > Rather, I would just tell people that their account ID is =93 > paulej@packetizer.com=94. That may or may not be their address. Query a > Twitter account and it might return an email address that differs (if > Twitter were to share that info).**** > > **** > > Paul**** > > **** > > *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com] > *Sent:* Wednesday, April 18, 2012 6:05 AM > *To:* Paul E. Jones > *Cc:* Mike Jones; Apps Discuss > *Subject:* Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > Discovery (SWD)**** > > **** > > **** > > On 18 April 2012 01:59, Paul E. Jones wrote:**** > > Melvin,**** > > **** > > On =93acct:=94=85**** > > **** > > Humans will usually interchange an acct URI and mailto URI, probably neve= r > using either scheme directly in practice. That=92s natural and expected,= if > not desired. The intent is that we define something that looks like an > email ID, but it=92s not an email ID. Some services, perhaps Twitter bei= ng > most notable, do no use email addresses. Yet, you might have an account > there. So, user@twitter.com might be used by humans and automated > systems would convert that to acct:user@twitter.com. It would not be > appropriate to use mailto: since it=92s not an email ID.**** > > **** > > We did have a lot of debate about the use of =93acct=94. If you query my > WebFinger server, you=92ll see that it will work without =93acct:=94 pref= ixed, as > that was a suggestion made a year or so ago. It will inspect the input a= nd > if it looks like an acct URI, it will assume it is. The =93acct=94 URI w= ill be > returned as an alias. However, we should always use some kind of URI > scheme to remove the guesswork. The client can often make a very good > guess as to whether it=92s looking for a user account or something else. = So, > let it tell the server what it is looking for explicitly.**** > > **** > > We need a URI scheme, because WebFinger can be used to discover all kinds > of information related to a given domain, not only user information. It > can be used to query information about any URI, be that a web page, a use= r > account, device on the network, etc. If we got rid of =93acct=94, then w= e > would have a system where we sometimes use a URI scheme and sometimes we = do > not. Results might be inconsistent, as the server may not make the right > guess, unless we agreed that absence of a scheme defaults to =93acct:=94. > However, I see no reason for the client to be so lazy to not include > =93acct:=94. The user might (and probably will) exclude it, but the clie= nt > code can add it.**** > > **** > > At this point, I=92d argue the =93train has left the station=94 on =93acc= t=94, too. > The current WebFinger spec exists (in part) to formally document that whi= ch > has adopted; it=92s not a new thing.**** > > > > Paul, thank you for your explanation on lookup based on acct: (WebFinger) > vs lookup based on mailto: (SWD). > > I think this is a major difference. > > The original WebFinger proposal was *supposed* to give extra information > about an email address. > > From wikipedia: > > "WebFinger is an Internet protocol that aims to provide information about > people by their* **E-mail addresses*." > > From webfinger.org: > > "Put your *email address* into the box above, click the button" > > From google code (the top hit on google): > > "making *email addresses* readable again" > > And perhaps most importantly from the spec, the first example: > > "Assume you receive an *email *from Bob..." > > However only SWD here is doing email based discovery (mailto:). > WebFinger *now* doing acct: based discovery, which is a departure from th= e > original use case. > > Im glad that some people have voiced support for acct:, but I still > believe that to be a minority. I agree, that the new acct: scheme should > for in another document, rather than shoe horned into an email based > discovery system. > > IMHO, it's better to solve one problem (ie email based discovery) simply > and well, than to half solve two problems (ie a new uri scheme for > identity) in a single attempt. > **** > > **** > > Paul**** > > **** > > A couple of points: > > 1. JSON > =3D=3D=3D=3D=3D=3D=3D > > I think at the time webfinger was created in 2009, XML was the de facto > serialization, used in AJAX, SOAP and many other systems. Today I'm > hearing more and more, that both developers and publishers, want to work > with JSON, rather than, having to support both xml and json. Content > negotiation also confuses some publishers. In my view, this is a great > simplification that webfinger can learn from SWD. > > 2. acct: scheme > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The acct: URI scheme has not proved popular, imho, and has added a layer > of complexity and confusion. How do we get from acct: to mailto:? When > should you use acct: and when mailto: (the spec says acct:user@host may > be different from mailto:user@host). What about the forms. How about > linked data ecosystems that want to cross link identifiers, do they now > have to consider both cases? > > From the original post introducing acct: > > "I don=92t expect everyone to like this idea. I wish I could say I love i= t, > but I am simply content with it." > > I dont know of anyone in the community (and correct me if this has > changed) that really loves acct:, or perhaps even likes the acct: idea. > SWD has shown you can do discovery without acct: and I think that's a big > plus. > > > > > One final side note is that this almost becomes trivial when you can do > SPARQL queries. "void" is already registered by the W3C with IANA in > .well-known in order to discover SPARQL endpoints. It may be overkill in > some people's eyes, but Linked Data (which predates webfinger), > particularly newer things like JSON LD, are a lot bigger than they were i= n > 2009. In a few years it may become the definitive discovery mechanism > anyway.**** > > **** > > _______________________________________________ > 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 =E8 necessario.* > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --e89a8ff253d4a9fec704be094829 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 19 April 2012 15:59, Goix Laurent Wal= ter <laurentwalter.goix@telecomitalia.it> wrote:

Possibly a= standard discovery mechanism should rely on some sort of URI and not a sim= ple token string. URIs representing social network accounts are missing so far and at least this type of URI should be discoverable. O= ptionally I believe any type of other uri may, but with no guarantee. It ma= y be a matter of permissions, internal db lookups and/or associations or el= se on the server to decide whether to provide a meaningful response to it. This is somehow already clarified = in section 5 of the wf draft.


W= hy do you say "URIs representing social accounts are missing so far&qu= ot;?=A0 And if so, from which systems?=A0

For example, Facebook has a pretty good system for representing their a= ccounts as URIs (open graph protocol), as does SIOC, and people like status.net (inventor of OStatus who have a pret= ty good FOAF impl.) etc.=A0 All of these use HTTP URIs as their machine rep= resentation, rather than any proposed acct: scheme, for example.=A0

I thought this use case is mainly relevant to the big webmail providers= .

Email style discovery is missing (apart from the specific case of = a public key in GPG), so if you want a full Web sytle solution use void (al= ready registered with IANA).=A0 If void is too complex, choose something si= mpler.=A0 SWD seems a simpler solution, at this point, technically.=A0 WF m= ay have the lead on adoption, I dont know.=A0 Perhaps something can be lear= nt by each system from each other ... e.g. the JSON vs XML discussion.=A0 M= erging the best parts from both specs could be a great idea...

As for non mailto: URI schemes, that in itself is an interesting proble= m, perhaps a big topic.=A0 To me, xmpp: is a very interesting candidate.=A0= Again void can be used for this, but maybe WF/SWD is an interesting thing = to deploy.=A0 Having a lookup for the tel: scheme would be kind of amazing = ... but is a whole problem in itself, including finding the well known loca= tion.=A0 HTTP discovery is really in advanced stages, with mature deploymen= ts, under the W3C / Linked Data.=A0 I would personally NOT encourage acct: = lookup because it's just too confusing for the average developer, fract= ures identity, does not provide HTTP style 'follow your nose', and = ultimately, will probably not be a long lived identifier, given how quickly= the web identity space evolves (just my 2 cents).

I think sweet spot here is find the path of least resistance, for a rea= lly good discovery system for email addresses. =A0 Other schemes *could* be= a plus depending on the context, but the most compelling and useful lookup= that is filling a gap I think, is mailto: based.

=A0=

walter<= /u>

=A0

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] Per conto di Pelle Wessman
Inviato: gioved=EC 19 aprile 2012 13.53
A: Paul E.Jones
Cc: 'Apps Discuss'
Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Dis= covery (SWD)

=A0

While WebFinger officially requires an "acct&qu= ot; URI I believe almost all current implementers accept a "pelle@kodfabrik.se" = URI as being the same as "acct:pelle@kodfabrik.se". Gmail.com does, StatusNe= t/Identi.ca does, we at Flattr does. So there is a=A0discrepancy between th= e WebFinger specification and real life implementations.

=A0

Examples:

=A0

=A0

Also, speaking from a Flattr-perspective, mail addre= sses and user accounts are _not_ the same thing in our system. I myself hav= e the e-mail pelle@flattr.com = but I have the web site account voxpelli@flattr.co= m and the web site account pelle@flattr.com = doesn't belong to me but to one of our users. I believe most web sites,= at least the smaller ones, works like this - that the e-mail system and th= e web system is completely separated from each other and that the user identifiers in one can conflict with the identifiers in the = other.

=A0

I would say that a lookup for "mailto:pelle@flattr.com" sho= uld return info about the user behind that e-mail address (if it should ret= urn anything) but that a lookup for "pelle@flattr.com" or "acct= :pelle@flattr.com" should always return data about the web site us= er and that clients should be encouraged to use "acct:" to make i= t clear that they want the web site's user, but that they shouldn't= be required to do so.

=A0

/ Pelle

=A0

=A0

19 apr 2012 kl. 00:03 skrev Paul E. Jones:=



Melvin,

=A0=

WebFinger = does discovery on=A0any=A0URI.=A0 It might= be =93http=94, =93mailto=94, =93ftp=94, or =93acct=94.=A0 So, it=92s not enti= rely correct to say that WebFinger does not do discovery using email addres= ses.=A0 I could change my server code pretty easily to accommodate mailto.<= /span>

=A0=

Use of mai= lto was something discussed at length.=A0 As others pointed out, it was not= necessarily favored by all, but it was recognized to be insufficient for some situations.=A0 Most importantly,=A0nobody=A0other than us geeks knows what the heck a =93mailto=94 is.=A0 B= ut, we do recognize that social sites like Twitter have accounts.=A0 Thus, after the lengthy debate that took place in several places, it was d= ecided to go with =93acct=94.=A0 It actually does have a useful purpose.=A0= And its construction is made to look similar to =93mailto=94 so that the a= user would just enter what they consider to be an =93email=94 address, including things we know are not like=A0<= /span>user@twitter.co= m. =A0Using =93mailto=94 is technically incorrect, but users never have= to know or care about that.=A0 Behind the scenes, we use =93acct=94.=A0 I would personally never show an end use= r =93acct= :paulej@packetizer.com=94.=A0 Rather, I would just tell people that the= ir account ID is =93paulej@packetizer.com=94.=A0 That may or may not be their address.=A0 Query a Twitter account and it might return an email address t= hat differs (if Twitter were to share that info).

=A0=

Paul

=A0=

From:= =A0Melv= in Carvalho [mailto:melvincarvalho@gmail.com]=A0
Sent:=A0Wednesday, April 18, 2012 6:05 AM
To:=A0Paul E. Jones
Cc:=A0Mike Jones; Apps Discuss
Subject:=A0Re: [apps-discuss] [OAUTH-WG] Web Finger vs.= Simple Web Discovery (SWD)

=A0

= =A0

On 18 April 2012 01:59, Paul E.= Jones <paule= j@packetizer.com> wrote:

Melvin,

=A0=

On =93acct= :=94=85

=A0=

Humans wil= l usually interchange an acct URI and mailto URI, probably never using eith= er scheme directly in practice.=A0 That=92s natural and expected, if not desired.=A0 The intent is that we define something that looks like = an email ID, but it=92s not an email ID.=A0 Some services, perhaps Twitter = being most notable, do no use email addresses.=A0 Yet, you might have an ac= count there.=A0 So,=A0user@twitter.com=A0might be used by humans and automated systems would convert that to=A0acct:user@t= witter.com.=A0 It would not be appropriate to use mailto: since it=92s = not an email ID.

=A0=

We did hav= e a lot of debate about the use of =93acct=94.=A0 If you query my WebFinger= server, you=92ll see that it will work without =93acct:=94 prefixed, as that was a suggestion made a year or so ago.=A0 It will inspect the inp= ut and if it looks like an acct URI, it will assume it is.=A0 The =93acct= =94 URI will be returned as an alias.=A0 However, we should always use some= kind of URI scheme to remove the guesswork.=A0 The client can often make a very good guess as to whether it=92s looking f= or a user account or something else.=A0 So, let it tell the server what it = is looking for explicitly.=

=A0=

We need a = URI scheme, because WebFinger can be used to discover all kinds of informat= ion related to a given domain, not only user information.=A0 It can be used to query information about any URI, be that a web page, a u= ser account, device on the network, etc.=A0 If we got rid of =93acct=94, th= en we would have a system where we sometimes use a URI scheme and sometimes= we do not.=A0 Results might be inconsistent, as the server may not make the right guess, unless we agreed that absence = of a scheme defaults to =93acct:=94.=A0 However, I see no reason for the cl= ient to be so lazy to not include =93acct:=94.=A0 The user might (and proba= bly will) exclude it, but the client code can add it.

=A0=

At this po= int, I=92d argue the =93train has left the station=94 on =93acct=94, too.= =A0 The current WebFinger spec exists (in part) to formally document that which has adopted; it=92s not a new thing.<= /u>



Paul, thank you for your explanation on lookup based on acct: (WebFinger) v= s lookup based on mailto: (SWD).

I think this is a major difference.

The original WebFinger proposal was *supposed* to give extra information ab= out an email address.

>From wikipedia:

"WebFinger is an Internet protocol that = aims to provide information about people by their=A0= E-mail addresses."

From=A0webf= inger.org:

"Put your=A0email address=A0into the = box above, click the button"

>From google code (the top hit on google):

"making=A0email addresse= s=A0readable again"

And perhaps most importantly from the spec, the first example:

"Assume you receive an=A0email=A0from Bob..."

However only SWD here is doing email based discovery (mailto:).=A0 W= ebFinger *now* doing acct: based discovery, which is a departure from the o= riginal use case.=A0=A0

Im glad that some people have voiced support for acct:, but I still believe= that to be a minority.=A0 I agree, that the new acct: scheme should for in= another document, rather than shoe horned into an email based discovery sy= stem.=A0=A0

IMHO, it's better to solve one problem (ie email based discovery) simpl= y and well, than to half solve two problems (ie a new uri scheme for identi= ty) in a single attempt.=A0=A0
=A0

=A0=

Paul

=A0=

A couple of points:

1. JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the time webfinger was created in 2009, XML was the de facto ser= ialization, used in AJAX, SOAP and many other systems.=A0 Today I'm hea= ring more and more, that both developers and publishers, want to work with = JSON, rather than, having to support both xml and json.=A0 Content negotiation also confuses some publishers.=A0 In = my view, this is a great simplification that webfinger can learn from SWD.<= br>
2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The acct: URI scheme has not proved popular, imho, and has added a layer of= complexity and confusion.=A0 How do we get from acct: to mailto:?=A0 When = should you use acct: and when mailto: (the spec says acct:user@host may be = different from mailto:user@h= ost).=A0 What about the forms.=A0 How about linked data ecosystems that want to cro= ss link identifiers, do they now have to consider both cases?=A0=A0

>From the original post introducing acct:

"I don=92t expect everyone to like this idea. I wish I could say I lov= e it, but I am simply content with it."

I dont know of anyone in the community (and correct me if this has changed)= that really loves acct:, or perhaps even likes the acct: idea.=A0 SWD has = shown you can do discovery without acct: and I think that's a big plus.=




One final side note is that this almost becomes trivial when you can do SPA= RQL queries.=A0 "void" is already registered by the W3C with IANA= in .well-known in order to discover SPARQL endpoints.=A0 It may be overkil= l in some people's eyes, but Linked Data (which predates webfinger), particularly newer things like JSON LD, are a lot big= ger than they were in 2009.=A0 In a few years it may become the definitive = discovery mechanism anyway.

=A0

_______________________________= ________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /span>

=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=A0is=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 l'ambient= e. Non stampare questa mail se non =E8 necessario.


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


--e89a8ff253d4a9fec704be094829-- From bobwyman@gmail.com Thu Apr 19 08:26: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 1334B21F865C for ; Thu, 19 Apr 2012 08:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5bvY34GifMV for ; Thu, 19 Apr 2012 08:26:45 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4545D21F864D for ; Thu, 19 Apr 2012 08:26:44 -0700 (PDT) Received: by qcsq13 with SMTP id q13so6394546qcs.31 for ; Thu, 19 Apr 2012 08:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IbcnhsIcFIEcsqwutYPKwM1u3bAkjs+cIjvUm0Cq6JQ=; b=x7jFyuXPXM7+7Abi1Tv0mfG39NSjnFo4HNRkT0kAy3+AakaWeFQEYIZB3WqpTUYfZe 4uxlk351AHHrH2q8NTuVxuqL/MGPAdV7z5sE7ZYUIzFkgrGxoka0h3Czpt47Inz65Dlf 2n2j5mmeUfuPFqaXXHzFFXTUw/0VX7jPs8iwXiv+/BsucF43jx+/qlTs5ucg8U/ymYTR SDZliXcmw4NfA+rrs8yDOu35N1bOFPHAinovaQljl86McP/L4b4gdesitaMfWsIg0Dt3 UdkQw1zMKVpAFpRKhZ5vTaBihdN0ifLNRrsOURpBbIqcYK/Dh5QdA1dcZmJtlFjINGmP nohw== MIME-Version: 1.0 Received: by 10.224.101.72 with SMTP id b8mr3531158qao.53.1334849203231; Thu, 19 Apr 2012 08:26:43 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.12.194 with HTTP; Thu, 19 Apr 2012 08:26:40 -0700 (PDT) In-Reply-To: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <04fb01cd1cf6$23131c80$69395580$@packetizer.com> <069501cd1daf$20087580$60196080$@packetizer.com> <15AB1540-7555-4C02-A29A-AAE0ADA786B3@kodfabrik.se> Date: Thu, 19 Apr 2012 11:26:40 -0400 X-Google-Sender-Auth: IQCm24FaOD_F44O5q-iCXGBaYEg Message-ID: From: Bob Wyman To: Melvin Carvalho Content-Type: multipart/alternative; boundary=20cf30667c2f965d8c04be09cc1e Cc: Apps Discuss Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 15:26:51 -0000 --20cf30667c2f965d8c04be09cc1e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Apr 19, 2012 at 10:49 AM, Melvin Carvalho wrote: > > > On 19 April 2012 15:59, Goix Laurent Walter < > laurentwalter.goix@telecomitalia.it> wrote: > >> Possibly a standard discovery mechanism should rely on some sort of URI >> and not a simple token string. URIs representing social network accounts >> are missing so far and at least this type of URI should be discoverable. >> Optionally I believe any type of other uri may, but with no guarantee. I= t >> may be a matter of permissions, internal db lookups and/or associations = or >> else on the server to decide whether to provide a meaningful response to >> it. This is somehow already clarified in section 5 of the wf draft. >> > > Why do you say "URIs representing social accounts are missing so far"? > And if so, from which systems? > > For example, Facebook has a pretty good system for representing their > accounts as URIs (open graph protocol), as does SIOC, and people like > status.net (inventor of OStatus who have a pretty good FOAF impl.) etc. > All of these use HTTP URIs as their machine representation, rather than a= ny > proposed acct: scheme, for example. > > I thought this use case is mainly relevant to the big webmail providers. > > Email style discovery is missing (apart from the specific case of a publi= c > key in GPG), so if you want a full Web sytle solution use void (already > registered with IANA). If void is too complex, choose something simpler. > SWD seems a simpler solution, at this point, technically. WF may have th= e > lead on adoption, I dont know. Perhaps something can be learnt by each > system from each other ... e.g. the JSON vs XML discussion. Merging the > best parts from both specs could be a great idea... > > As for non mailto: URI schemes, that in itself is an interesting problem, > perhaps a big topic. To me, xmpp: is a very interesting candidate. Agai= n > void can be used for this, but maybe WF/SWD is an interesting thing to > deploy. Having a lookup for the tel: scheme would be kind of amazing ... > but is a whole problem in itself, including finding the well known > location. HTTP discovery is really in advanced stages, with mature > deployments, under the W3C / Linked Data. I would personally NOT encoura= ge > acct: lookup because it's just too confusing for the average developer, > fractures identity, does not provide HTTP style 'follow your nose', and > ultimately, will probably not be a long lived identifier, given how quick= ly > the web identity space evolves (just my 2 cents). > > I think sweet spot here is find the path of least resistance, for a reall= y > good discovery system for email addresses. > I'm sure that at least some existing email service providers would be very pleased if the IETF published an RFC that effectively granted to those email providers, by design, the effectively exclusive ability to provide standards-based profile services on the Internet. However, I am utterly convinced that it would be completely inappropriate to adopt a spec that did, in fact, provide such a preference for and advantage to the providers of email services or implementations of any other protocol. There is no technical reason why there should be any binding or connection between the providers of email services and the providers of profile services. There is also, as far as I can see, no logical reason or benefit to insist on such a binding. We are defining protocols that need to last for many years. Even if it is the case that today many people have unwittingly fallen into thinking of email addresses as identifiers of people rather than of their mailboxes, we should be concerned with "what is right" and what people should or will be thinking in five or ten years. *Mailto: identifies mailboxes, not people.* We need acct: in order to better identify the people or other entities with whom mailboxes and other resources may be associated. > Other schemes *could* be a plus depending on the context, but the most > compelling and useful lookup that is filling a gap I think, is mailto:bas= ed. > > **** >> >> ** ** >> >> walter**** >> >> ** ** >> >> *Da:* apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.or= g] >> *Per conto di *Pelle Wessman >> *Inviato:* gioved=EC 19 aprile 2012 13.53 >> *A:* Paul E.Jones >> *Cc:* 'Apps Discuss' >> *Oggetto:* Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web >> Discovery (SWD)**** >> >> ** ** >> >> While WebFinger officially requires an "acct" URI I believe almost all >> current implementers accept a "pelle@kodfabrik.se" URI as being the same >> as "acct:pelle@kodfabrik.se". Gmail.com does, StatusNet/Identi.ca does, >> we at Flattr does. So there is a discrepancy between the WebFinger >> specification and real life implementations.**** >> >> ** ** >> >> Examples:**** >> >> ** ** >> >> http://www.google.com/s2/webfinger/?q=3Dvoxpelli@gmail.com**** >> >> http://identi.ca/main/xrd?uri=3Dvoxpelli@identi.ca**** >> >> https://flattr.com/xrd/lrdd?uri=3Dvoxpelli@flattr.com**** >> >> ** ** >> >> Also, speaking from a Flattr-perspective, mail addresses and user >> accounts are _not_ the same thing in our system. I myself have the e-mai= l >> pelle@flattr.com but I have the web site account voxpelli@flattr.com and >> the web site account pelle@flattr.com doesn't belong to me but to one of >> our users. I believe most web sites, at least the smaller ones, works li= ke >> this - that the e-mail system and the web system is completely separated >> from each other and that the user identifiers in one can conflict with t= he >> identifiers in the other.**** >> >> ** ** >> >> I would say that a lookup for "mailto:pelle@flattr.com " >> should return info about the user behind that e-mail address (if it shou= ld >> return anything) but that a lookup for "pelle@flattr.com" or " >> acct:pelle@flattr.com" should always return data about the web site user >> and that clients should be encouraged to use "acct:" to make it clear th= at >> they want the web site's user, but that they shouldn't be required to do= so. >> **** >> >> ** ** >> >> / Pelle**** >> >> ** ** >> >> ** ** >> >> 19 apr 2012 kl. 00:03 skrev Paul E. Jones:**** >> >> >> >> **** >> >> Melvin,**** >> >> **** >> >> WebFinger does discovery on *any* URI. It might be =93http=94, =93mailt= o=94, >> =93ftp=94, or =93acct=94. So, it=92s not entirely correct to say that W= ebFinger does >> not do discovery using email addresses. I could change my server code >> pretty easily to accommodate mailto.**** >> >> **** >> >> Use of mailto was something discussed at length. As others pointed out, >> it was not necessarily favored by all, but it was recognized to be >> insufficient for some situations. Most importantly, *nobody* other than >> us geeks knows what the heck a =93mailto=94 is. But, we do recognize th= at >> social sites like Twitter have accounts. Thus, after the lengthy debate >> that took place in several places, it was decided to go with =93acct=94.= It >> actually does have a useful purpose. And its construction is made to lo= ok >> similar to =93mailto=94 so that the a user would just enter what they co= nsider >> to be an =93email=94 address, including things we know are not like >> user@twitter.com. Using =93mailto=94 is technically incorrect, but user= s >> never have to know or care about that. Behind the scenes, we use =93acc= t=94. >> I would personally never show an end user =93acct:paulej@packetizer.com= =94. >> Rather, I would just tell people that their account ID is =93 >> paulej@packetizer.com=94. That may or may not be their address. Query = a >> Twitter account and it might return an email address that differs (if >> Twitter were to share that info).**** >> >> **** >> >> Paul**** >> >> **** >> >> *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com] >> *Sent:* Wednesday, April 18, 2012 6:05 AM >> *To:* Paul E. Jones >> *Cc:* Mike Jones; Apps Discuss >> *Subject:* Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web >> Discovery (SWD)**** >> >> **** >> >> **** >> >> On 18 April 2012 01:59, Paul E. Jones wrote:**** >> >> Melvin,**** >> >> **** >> >> On =93acct:=94=85**** >> >> **** >> >> Humans will usually interchange an acct URI and mailto URI, probably >> never using either scheme directly in practice. That=92s natural and >> expected, if not desired. The intent is that we define something that >> looks like an email ID, but it=92s not an email ID. Some services, perh= aps >> Twitter being most notable, do no use email addresses. Yet, you might h= ave >> an account there. So, user@twitter.com might be used by humans and >> automated systems would convert that to acct:user@twitter.com. It would >> not be appropriate to use mailto: since it=92s not an email ID.**** >> >> **** >> >> We did have a lot of debate about the use of =93acct=94. If you query m= y >> WebFinger server, you=92ll see that it will work without =93acct:=94 pre= fixed, as >> that was a suggestion made a year or so ago. It will inspect the input = and >> if it looks like an acct URI, it will assume it is. The =93acct=94 URI = will be >> returned as an alias. However, we should always use some kind of URI >> scheme to remove the guesswork. The client can often make a very good >> guess as to whether it=92s looking for a user account or something else.= So, >> let it tell the server what it is looking for explicitly.**** >> >> **** >> >> We need a URI scheme, because WebFinger can be used to discover all kind= s >> of information related to a given domain, not only user information. It >> can be used to query information about any URI, be that a web page, a us= er >> account, device on the network, etc. If we got rid of =93acct=94, then = we >> would have a system where we sometimes use a URI scheme and sometimes we= do >> not. Results might be inconsistent, as the server may not make the righ= t >> guess, unless we agreed that absence of a scheme defaults to =93acct:=94= . >> However, I see no reason for the client to be so lazy to not include >> =93acct:=94. The user might (and probably will) exclude it, but the cli= ent >> code can add it.**** >> >> **** >> >> At this point, I=92d argue the =93train has left the station=94 on =93ac= ct=94, >> too. The current WebFinger spec exists (in part) to formally document t= hat >> which has adopted; it=92s not a new thing.**** >> >> >> >> Paul, thank you for your explanation on lookup based on acct: (WebFinger= ) >> vs lookup based on mailto: (SWD). >> >> I think this is a major difference. >> >> The original WebFinger proposal was *supposed* to give extra information >> about an email address. >> >> From wikipedia: >> >> "WebFinger is an Internet protocol that aims to provide information abou= t >> people by their* **E-mail addresses*." >> >> From webfinger.org: >> >> "Put your *email address* into the box above, click the button" >> >> From google code (the top hit on google): >> >> "making *email addresses* readable again" >> >> And perhaps most importantly from the spec, the first example: >> >> "Assume you receive an *email *from Bob..." >> >> However only SWD here is doing email based discovery (mailto:). >> WebFinger *now* doing acct: based discovery, which is a departure from t= he >> original use case. >> >> Im glad that some people have voiced support for acct:, but I still >> believe that to be a minority. I agree, that the new acct: scheme shoul= d >> for in another document, rather than shoe horned into an email based >> discovery system. >> >> IMHO, it's better to solve one problem (ie email based discovery) simply >> and well, than to half solve two problems (ie a new uri scheme for >> identity) in a single attempt. >> **** >> >> **** >> >> Paul**** >> >> **** >> >> A couple of points: >> >> 1. JSON >> =3D=3D=3D=3D=3D=3D=3D >> >> I think at the time webfinger was created in 2009, XML was the de facto >> serialization, used in AJAX, SOAP and many other systems. Today I'm >> hearing more and more, that both developers and publishers, want to work >> with JSON, rather than, having to support both xml and json. Content >> negotiation also confuses some publishers. In my view, this is a great >> simplification that webfinger can learn from SWD. >> >> 2. acct: scheme >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> The acct: URI scheme has not proved popular, imho, and has added a layer >> of complexity and confusion. How do we get from acct: to mailto:? When >> should you use acct: and when mailto: (the spec says acct:user@host may >> be different from mailto:user@host). What about the forms. How about >> linked data ecosystems that want to cross link identifiers, do they now >> have to consider both cases? >> >> From the original post introducing acct: >> >> "I don=92t expect everyone to like this idea. I wish I could say I love = it, >> but I am simply content with it." >> >> I dont know of anyone in the community (and correct me if this has >> changed) that really loves acct:, or perhaps even likes the acct: idea. >> SWD has shown you can do discovery without acct: and I think that's a bi= g >> plus. >> >> >> >> >> One final side note is that this almost becomes trivial when you can do >> SPARQL queries. "void" is already registered by the W3C with IANA in >> .well-known in order to discover SPARQL endpoints. It may be overkill i= n >> some people's eyes, but Linked Data (which predates webfinger), >> particularly newer things like JSON LD, are a lot bigger than they were = in >> 2009. In a few years it may become the definitive discovery mechanism >> anyway.**** >> >> **** >> >> _______________________________________________ >> 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 a= nd >> advise the sender by return e-mail, Thanks.* >> *[image: 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 >> >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --20cf30667c2f965d8c04be09cc1e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 19, 2012 at 10:49 AM, Melvin= Carvalho <melvincarvalho@gmail.com> wrote:


On 19 April 2012 15:59= , Goix Laurent Walter <laurentwalter.goix@telecomitalia.= it> wrote:

Possibly a= standard discovery mechanism should rely on some sort of URI and not a sim= ple token string. URIs representing social network accounts are missing so far and at least this type of URI should be discoverable. O= ptionally I believe any type of other uri may, but with no guarantee. It ma= y be a matter of permissions, internal db lookups and/or associations or el= se on the server to decide whether to provide a meaningful response to it. This is somehow already clarified = in section 5 of the wf draft.


Why do you say "URIs representing social accounts are missing so = far"?=A0 And if so, from which systems?=A0

For example, Facebook has a pretty good system for representing their a= ccounts as URIs (open graph protocol), as does SIOC, and people like status.net (inventor of OStat= us who have a pretty good FOAF impl.) etc.=A0 All of these use HTTP URIs as= their machine representation, rather than any proposed acct: scheme, for e= xample.=A0

I thought this use case is mainly relevant to the big webmail providers= .

Email style discovery is missing (apart from the specific case of = a public key in GPG), so if you want a full Web sytle solution use void (al= ready registered with IANA).=A0 If void is too complex, choose something si= mpler.=A0 SWD seems a simpler solution, at this point, technically.=A0 WF m= ay have the lead on adoption, I dont know.=A0 Perhaps something can be lear= nt by each system from each other ... e.g. the JSON vs XML discussion.=A0 M= erging the best parts from both specs could be a great idea...

As for non mailto: URI schemes, that in itself is an interesting proble= m, perhaps a big topic.=A0 To me, xmpp: is a very interesting candidate.=A0= Again void can be used for this, but maybe WF/SWD is an interesting thing = to deploy.=A0 Having a lookup for the tel: scheme would be kind of amazing = ... but is a whole problem in itself, including finding the well known loca= tion.=A0 HTTP discovery is really in advanced stages, with mature deploymen= ts, under the W3C / Linked Data.=A0 I would personally NOT encourage acct: = lookup because it's just too confusing for the average developer, fract= ures identity, does not provide HTTP style 'follow your nose', and = ultimately, will probably not be a long lived identifier, given how quickly= the web identity space evolves (just my 2 cents).

I think sweet spot here is find the path of least resistance, for a rea= lly good discovery system for email addresses.
I'm sure that at least some existing email service providers would be = very pleased if the IETF published an RFC that effectively granted to those= email providers, by design, the effectively exclusive ability to provide s= tandards-based profile services on the Internet. However, I am utterly conv= inced that it would be completely inappropriate to adopt a spec that did, i= n fact, provide such a preference for and advantage to the providers of ema= il services or implementations of any other protocol.

There is no technical reason why there should be any bi= nding or connection between the providers of email services and the provide= rs of profile services. There is also, as far as I can see, no logical reas= on or benefit to insist on such a binding.=A0
We are defining protocols that need to last for many years. Even if it= is the case that today many people have unwittingly fallen into thinking o= f email addresses as identifiers of people rather than of their mailboxes, = we should be concerned with "what is right" and what people shoul= d or will be thinking in five or ten years.

Mailto: identifies mailboxes, not people. We nee= d acct: in order to better identify the people or other entities with whom = mailboxes and other resources may be associated.=A0

=A0
= =A0 Other schemes *could* be a plus depending on the context, but the most = compelling and useful lookup that is filling a gap I think, is mailto: base= d.

=A0=

walter<= /u>

=A0

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] Per conto di Pelle Wessman
Inviato: gioved=EC 19 aprile 2012 13.53
A: Paul E.Jones
Cc: 'Apps Discuss'
Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Dis= covery (SWD)

=A0

While WebFinger officially requires an "acct&qu= ot; URI I believe almost all current implementers accept a "pelle@kodfabrik.se" = URI as being the same as "acct:pelle@kodfabrik.se". Gmail.com does, StatusNe= t/Identi.ca does, we at Flattr does. So there is a=A0discrepancy between th= e WebFinger specification and real life implementations.

=A0

Examples:

=A0

=A0

Also, speaking from a Flattr-perspective, mail addre= sses and user accounts are _not_ the same thing in our system. I myself hav= e the e-mail pelle@flattr.com = but I have the web site account voxpelli@flattr.co= m and the web site account pelle@flattr.com = doesn't belong to me but to one of our users. I believe most web sites,= at least the smaller ones, works like this - that the e-mail system and th= e web system is completely separated from each other and that the user identifiers in one can conflict with the identifiers in the = other.

=A0

I would say that a lookup for "mailto:pelle@flattr.com" sho= uld return info about the user behind that e-mail address (if it should ret= urn anything) but that a lookup for "pelle@flattr.com" or "acct= :pelle@flattr.com" should always return data about the web site us= er and that clients should be encouraged to use "acct:" to make i= t clear that they want the web site's user, but that they shouldn't= be required to do so.

=A0

/ Pelle

=A0

=A0

19 apr 2012 kl. 00:03 skrev Paul E. Jones:=



Melvin,

=A0=

WebFinger = does discovery on=A0any=A0URI.=A0 It might= be =93http=94, =93mailto=94, =93ftp=94, or =93acct=94.=A0 So, it=92s not enti= rely correct to say that WebFinger does not do discovery using email addres= ses.=A0 I could change my server code pretty easily to accommodate mailto.<= /span>

=A0=

Use of mai= lto was something discussed at length.=A0 As others pointed out, it was not= necessarily favored by all, but it was recognized to be insufficient for some situations.=A0 Most importantly,=A0nobody=A0other than us geeks knows what the heck a =93mailto=94 is.=A0 B= ut, we do recognize that social sites like Twitter have accounts.=A0 Thus, after the lengthy debate that took place in several places, it was d= ecided to go with =93acct=94.=A0 It actually does have a useful purpose.=A0= And its construction is made to look similar to =93mailto=94 so that the a= user would just enter what they consider to be an =93email=94 address, including things we know are not like=A0<= /span>user@twitter.co= m. =A0Using =93mailto=94 is technically incorrect, but users never have= to know or care about that.=A0 Behind the scenes, we use =93acct=94.=A0 I would personally never show an end use= r =93acct= :paulej@packetizer.com=94.=A0 Rather, I would just tell people that the= ir account ID is =93paulej@packetizer.com=94.=A0 That may or may not be their address.=A0 Query a Twitter account and it might return an email address t= hat differs (if Twitter were to share that info).

=A0=

Paul

=A0=

From:= =A0Melv= in Carvalho [mailto:melvincarvalho@gmail.com]=A0
Sent:=A0Wednesday, April 18, 2012 6:05 AM
To:=A0Paul E. Jones
Cc:=A0Mike Jones; Apps Discuss
Subject:=A0Re: [apps-discuss] [OAUTH-WG] Web Finger vs.= Simple Web Discovery (SWD)

=A0

= =A0

On 18 April 2012 01:59, Paul E.= Jones <paule= j@packetizer.com> wrote:

Melvin,

=A0=

On =93acct= :=94=85

=A0=

Humans wil= l usually interchange an acct URI and mailto URI, probably never using eith= er scheme directly in practice.=A0 That=92s natural and expected, if not desired.=A0 The intent is that we define something that looks like = an email ID, but it=92s not an email ID.=A0 Some services, perhaps Twitter = being most notable, do no use email addresses.=A0 Yet, you might have an ac= count there.=A0 So,=A0user@twitter.com=A0might be used by humans and automated systems would convert that to=A0acct:user@t= witter.com.=A0 It would not be appropriate to use mailto: since it=92s = not an email ID.

=A0=

We did hav= e a lot of debate about the use of =93acct=94.=A0 If you query my WebFinger= server, you=92ll see that it will work without =93acct:=94 prefixed, as that was a suggestion made a year or so ago.=A0 It will inspect the inp= ut and if it looks like an acct URI, it will assume it is.=A0 The =93acct= =94 URI will be returned as an alias.=A0 However, we should always use some= kind of URI scheme to remove the guesswork.=A0 The client can often make a very good guess as to whether it=92s looking f= or a user account or something else.=A0 So, let it tell the server what it = is looking for explicitly.=

=A0=

We need a = URI scheme, because WebFinger can be used to discover all kinds of informat= ion related to a given domain, not only user information.=A0 It can be used to query information about any URI, be that a web page, a u= ser account, device on the network, etc.=A0 If we got rid of =93acct=94, th= en we would have a system where we sometimes use a URI scheme and sometimes= we do not.=A0 Results might be inconsistent, as the server may not make the right guess, unless we agreed that absence = of a scheme defaults to =93acct:=94.=A0 However, I see no reason for the cl= ient to be so lazy to not include =93acct:=94.=A0 The user might (and proba= bly will) exclude it, but the client code can add it.

=A0=

At this po= int, I=92d argue the =93train has left the station=94 on =93acct=94, too.= =A0 The current WebFinger spec exists (in part) to formally document that which has adopted; it=92s not a new thing.<= /u>



Paul, thank you for your explanation on lookup based on acct: (WebFinger) v= s lookup based on mailto: (SWD).

I think this is a major difference.

The original WebFinger proposal was *supposed* to give extra information ab= out an email address.

>From wikipedia:

"WebFinger is an Internet protocol that = aims to provide information about people by their=A0= E-mail addresses."

From=A0webf= inger.org:

"Put your=A0email address=A0into the = box above, click the button"

>From google code (the top hit on google):

"making=A0email addresse= s=A0readable again"

And perhaps most importantly from the spec, the first example:

"Assume you receive an=A0email=A0from Bob..."

However only SWD here is doing email based discovery (mailto:).=A0 W= ebFinger *now* doing acct: based discovery, which is a departure from the o= riginal use case.=A0=A0

Im glad that some people have voiced support for acct:, but I still believe= that to be a minority.=A0 I agree, that the new acct: scheme should for in= another document, rather than shoe horned into an email based discovery sy= stem.=A0=A0

IMHO, it's better to solve one problem (ie email based discovery) simpl= y and well, than to half solve two problems (ie a new uri scheme for identi= ty) in a single attempt.=A0=A0
=A0

=A0=

Paul

=A0=

A couple of points:

1. JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the time webfinger was created in 2009, XML was the de facto ser= ialization, used in AJAX, SOAP and many other systems.=A0 Today I'm hea= ring more and more, that both developers and publishers, want to work with = JSON, rather than, having to support both xml and json.=A0 Content negotiation also confuses some publishers.=A0 In = my view, this is a great simplification that webfinger can learn from SWD.<= br>
2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The acct: URI scheme has not proved popular, imho, and has added a layer of= complexity and confusion.=A0 How do we get from acct: to mailto:?=A0 When = should you use acct: and when mailto: (the spec says acct:user@host may be = different from mailto:user@h= ost).=A0 What about the forms.=A0 How about linked data ecosystems that want to cro= ss link identifiers, do they now have to consider both cases?=A0=A0

>From the original post introducing acct:

"I don=92t expect everyone to like this idea. I wish I could say I lov= e it, but I am simply content with it."

I dont know of anyone in the community (and correct me if this has changed)= that really loves acct:, or perhaps even likes the acct: idea.=A0 SWD has = shown you can do discovery without acct: and I think that's a big plus.=




One final side note is that this almost becomes trivial when you can do SPA= RQL queries.=A0 "void" is already registered by the W3C with IANA= in .well-known in order to discover SPARQL endpoints.=A0 It may be overkil= l in some people's eyes, but Linked Data (which predates webfinger), particularly newer things like JSON LD, are a lot big= ger than they were in 2009.=A0 In a few years it may become the definitive = discovery mechanism anyway.

=A0

_______________________________= ________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /span>

=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=A0is=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 =E8 necessario.


_______________________________________________
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


--20cf30667c2f965d8c04be09cc1e-- From dick.hardt@gmail.com Thu Apr 19 08: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 58F5621F8459; Thu, 19 Apr 2012 08:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URvRR8MmQGbm; Thu, 19 Apr 2012 08:52:18 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id DA19821F843F; Thu, 19 Apr 2012 08:52:17 -0700 (PDT) Received: by dady13 with SMTP id y13so15856257dad.27 for ; Thu, 19 Apr 2012 08:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=2qIykkL9j9WGZSMITfcXILEyjw+QGxwuMP0RkaimrWY=; b=Yy96WZ7Xw4CKZqmZcIwoVkR8zKxAQq4z4MUPQ95oiGjm4Q0tMO6TF3WhRRB2sb1UG8 SyJbL779Q/zZKUzv2dYTOnxItdVhKtujbIZwbdK/L4hVY/xyh1jPpCIGpaJeKdEOB3zP 9S7Sxf1VjR3bJ5BHEiNibE1tksDknGvPIFgL8vw8YpPlATZEzq4W96KUP835vyRDFi9A YZWErfBsJYofvpg0I5uQTvLF0yCEuxV29d+GMHudn4OjPeITUGBTrXbEUGUuShAc2Ief hU/cKWse82aXVfVDDynnx8av5w57SWlXl5CRucnjVkMCKk2cSd0Pq3vV+qOXWO5yDKMc FeAA== Received: by 10.68.72.138 with SMTP id d10mr5570379pbv.15.1334850737404; Thu, 19 Apr 2012 08:52:17 -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 x1sm2567613pbp.50.2012.04.19.08.52.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 08:52:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_9C12D86B-A145-4A02-8079-077B2860BD29" From: Dick Hardt In-Reply-To: Date: Thu, 19 Apr 2012 08:52:13 -0700 Message-Id: <9B6B7851-5212-4313-88B5-DBBA7BC9BEDC@gmail.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> To: Blaine Cook X-Mailer: Apple Mail (2.1257) Cc: "oauth@ietf.org WG" , apps-discuss@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 15:52:22 -0000 --Apple-Mail=_9C12D86B-A145-4A02-8079-077B2860BD29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A couple months ago I was checking out what was up. The AOL and Yahoo = endpoints no longer worked. The Google one still did. On Apr 17, 2012, at 3:54 PM, Blaine Cook wrote: > That's a tricky question - maybe one google can help answer? There are = a bunch of projects using webfinger, including status.net, ostatus in = general, diaspora, unhosted, freedombox(?), and I'm sure others, but I = have no idea how that translates into actual users or profiles. >=20 > Gmail, aol, and yahoo all put up webfinger endpoints, but there hasn't = been much movement, I think due to the chicken and egg nature of = adoption around decentralized tools. >=20 > b. >=20 > On Apr 17, 2012 11:13 AM, "Tim Bray" wrote: > What is the deployment status of these two specs? Is either deployed > much at all? -T >=20 > On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy = wrote: > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Stephen Farrell > >> Sent: Friday, April 13, 2012 9:23 AM > >> To: oauth@ietf.org WG > >> Cc: Apps Discuss > >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD) > >> > >> So Hannes and Derek and I have been discussing this with the Apps = ADs > >> and Apps-area WG chairs. I've also read the docs now, and after all > >> that we've decided that this topic (what to do with swd and = webfinger) > >> is best handled in the apps area and not in the oauth WG. > >> > >> The logic for that is that 1) the two proposals are doing the same > >> thing and we don't want two different standards for that, b) this = is > >> not an oauth-specific thing nor is it a general security thing, and = c) > >> there is clearly already interest in the topic in the apps area so = its > >> reasonable for the oauth wg to use that when its ready. > >> > >> The appsawg chairs and apps ADs are ok with the work being done = there. > >> > >> So:- > >> > >> - I've asked the oauth chairs to take doing work on swd > >> out of the proposed new charter > >> - It may be that you want to add something saying that > >> oauth will use the results of work in the applications > >> area on a web discovery protocol as a basis for doing > >> the dynamic client registration work here > >> - Discussion of webfinger and swd should move over to > >> the apps-discuss list > >> - Note: this is not picking one or the other approach, > >> the plan is that the apps area will do any selection > >> needed and figure out the best starting point for a > >> standards-track RFC on web discovery and we'll use their > >> fine work for doing more with oauth. > > > > Thank you Stephen, I think. :-) > > > > So the discussion on apps-discuss now should be focused on which of = the two should be the basis for forward progress. I've placed both = documents in "Call for Adoption" state in the datatracker for appsawg. > > > > Let the games begin. > > > > -MSK > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_9C12D86B-A145-4A02-8079-077B2860BD29 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii A couple months ago I was checking out what was up. The AOL and Yahoo endpoints no longer worked. The Google one still did.

On Apr 17, 2012, at 3:54 PM, Blaine Cook wrote:

That's a tricky question - maybe one google can help answer? There are a bunch of projects using webfinger, including status.net, ostatus in general, diaspora, unhosted, freedombox(?), and I'm sure others, but I have no idea how that translates into actual users or profiles.

Gmail, aol, and yahoo all put up webfinger endpoints, but there hasn't been much movement, I think due to the chicken and egg nature of adoption around decentralized tools.

b.

On Apr 17, 2012 11:13 AM, "Tim Bray" <tbray@textuality.com> wrote:
What is the deployment status of these two specs?  Is either deployed
much at all?  -T

On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy <msk@cloudmark.com> wrote:
>> -----Original Message-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Stephen Farrell
>> Sent: Friday, April 13, 2012 9:23 AM
>> To: oauth@ietf.org WG
>> Cc: Apps Discuss
>> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
>>
>> So Hannes and Derek and I have been discussing this with the Apps ADs
>> and Apps-area WG chairs. I've also read the docs now, and after all
>> that we've decided that this topic (what to do with swd and webfinger)
>> is best handled in the apps area and not in the oauth WG.
>>
>> The logic for that is that 1) the two proposals are doing the same
>> thing and we don't want two different standards for that, b) this is
>> not an oauth-specific thing nor is it a general security thing, and c)
>> there is clearly already interest in the topic in the apps area so its
>> reasonable for the oauth wg to use that when its ready.
>>
>> The appsawg chairs and apps ADs are ok with the work being done there.
>>
>> So:-
>>
>> - I've asked the oauth chairs to take doing work on swd
>>   out of the proposed new charter
>> - It may be that you want to add something saying that
>>   oauth will use the results of work in the applications
>>   area on a web discovery protocol as a basis for doing
>>   the dynamic client registration work here
>> - Discussion of webfinger and swd should move over to
>>   the apps-discuss list
>> - Note: this is not picking one or the other approach,
>>   the plan is that the apps area will do any selection
>>   needed and figure out the best starting point for a
>>   standards-track RFC on web discovery and we'll use their
>>   fine work for doing more with oauth.
>
> Thank you Stephen, I think.  :-)
>
> So the discussion on apps-discuss now should be focused on which of the two should be the basis for forward progress.  I've placed both documents in "Call for Adoption" state in the datatracker for appsawg.
>
> Let the games begin.
>
> -MSK
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_9C12D86B-A145-4A02-8079-077B2860BD29-- From wmills@yahoo-inc.com Thu Apr 19 08:58: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 E4BA021F852D for ; Thu, 19 Apr 2012 08:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.32 X-Spam-Level: X-Spam-Status: No, score=-16.32 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 198wohclTmnR for ; Thu, 19 Apr 2012 08:58:23 -0700 (PDT) Received: from nm28-vm4.bullet.mail.ne1.yahoo.com (nm28-vm4.bullet.mail.ne1.yahoo.com [98.138.91.188]) by ietfa.amsl.com (Postfix) with SMTP id D6B0D21F8531 for ; Thu, 19 Apr 2012 08:58:22 -0700 (PDT) Received: from [98.138.90.57] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 19 Apr 2012 15:58:19 -0000 Received: from [98.138.88.235] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 19 Apr 2012 15:58:19 -0000 Received: from [127.0.0.1] by omp1035.mail.ne1.yahoo.com with NNFMP; 19 Apr 2012 15:58:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 156933.65521.bm@omp1035.mail.ne1.yahoo.com Received: (qmail 25417 invoked by uid 60001); 19 Apr 2012 15:58:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334851098; bh=7PIOgANKqQ1UNnC8YIFKqo9LJQmQrFojIEo3RJ+tUJA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Q3QPP+Yaz6bGuoBhw88t+yiaEtHKSXqRnkQzyRzbhvPaJ15wT4V9P9t9u1bZBg/Ey4kOIom+2mOU0+eRy4StNV9jmxs1Xo8pXoOnWw3tlAmMygqm3aOQmW2QFbhllxt9NjW26tqgLhA7vIouTkqBAZ/xUIz0xY8FpVmQX/gXEb8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZxyB3l0xXGy84HuzCCKQhz/QMgucv/LVJib6JV+rYRQtUoam+/1PnnyO+0+OwRurL2UUha8UJEQw2AzUwxy7uALnVfL6jE7c/DOA2HAXM5wQrxuA0uAJ5mCUVkZAccrP5fX4SMO5VSGklUQNJdLpyGHqbtHT105sPZpk5h4fBGE=; X-YMail-OSG: 5zARcTcVM1lFWcQV88T8uqN83cv_iiYSMCWB1kvSIMHBTQ9 ncXnXPgdMBG_Pa51RGd.BZpusuMgDXNYdlMDJ1gdWn_GP_sJARiNTgQUkFVp 0e7SK0GKDecTghVhBwXyQSGKp0Ev0EqOu_sEJLD2ORp946tkijBE96tfeWjE 3m8wJ3HjB7hcXfb_BROSdCibUyCd0Ri7m5tyYOxSTh3sWGr91pahgBLoTdWW mhoI22ss5O54F0sZhzOAcW81MFLel4bii.GJIkAto2Ais7N3im65XiubMF_s DDn8DcuszXnHtS4Ix3CIwX9yxC0zQhx0AAgrjOwhQ3x4qqE5ftouk05ZN5dn aey6nul1O.CO149QTWMHyjESC0s1Hhd47o93VCp7qTjH_Xv7O5L4WJTW7Gpj FG0Xr.ytdv0bq8adkZg0E2IlQsg3_d61EW4FIonSA4E54FUh0iMM- Received: from [209.131.62.115] by web31802.mail.mud.yahoo.com via HTTP; Thu, 19 Apr 2012 08:58:18 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> <1334695329.43020.YahooMailNeo@web31812.mail.mud.yahoo.com> <1334712238.64475.YahooMailNeo@web31804.mail.mud.yahoo.com> Message-ID: <1334851098.14647.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Thu, 19 Apr 2012 08:58:18 -0700 (PDT) From: William Mills To: Sam Hartman In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-393065964-1334851098=:14647" Cc: "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 15:58:27 -0000 ---1036955950-393065964-1334851098=:14647 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable What I am focused on is when attributes are taken to be equivalent.=A0 Not = that they themselves are, but there are security implications if you get it= wrong.=0A=0A=0A=0A=0A>________________________________=0A> From: Sam Hartm= an =0A>To: William Mills =0A>= Cc: Nico Williams ; Sam Hartman ; "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" ; "apps-discuss@ietf.org" ; The IESG =0A>Sent: Thursday, April 19,= 2012 6:11 AM=0A>Subject: Re: [apps-discuss] Resending: APPSDIR review of d= raft-ietf-kitten-gssapi-naming-exts-14=0A> =0A>>>>>> "William" =3D=3D Willi= am Mills writes:=0A>=0A>=A0 =A0 William> OK, if this= is covered by the mechanisms (which is=0A>=A0 =A0 William> something a GSS= expert probably knows but I did not) then=0A>=A0 =A0 William> I'm less wor= ried.=A0 Is it then worthwhile to add "Systems=0A>=A0 =A0 William> must kno= w how to interpret critical mechanism attributes,=0A>=A0 =A0 William> but t= his is already required by mechanism specifications."=0A>=A0 =A0 William> i= n the section we're talking about to make it explicit=0A>=A0 =A0 William> r= ather than implicit?=0A>=0A>I'm now even more confused.=0A>I definitely don= 't understand how this discussion is about criticality=0A>of attributes.=0A= >=0A>=0A> ---1036955950-393065964-1334851098=:14647 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
What I am focused on is when attributes are taken to be equivalent. = Not that they themselves are, but there are security implications if you g= et it wrong.

Fr= om: Sam Hartman <hartmans-ietf@mit.edu>
To: William Mills <wmills@yahoo-inc.c= om>
Cc: Nico Willia= ms <nico@cryptonector.com>; Sam Hartman <hartmans-ietf@mit.edu>; = "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" <draft-ietf-ki= tten-gssapi-naming-exts.all@tools.ietf.org>; "apps-discuss@ietf.org" <= ;apps-discuss@ietf.org>; The IESG <iesg@ietf.org>
Sent: Thursday, April 19, 2012 6:11 A= M
Subject: Re: [apps-d= iscuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-1= 4

=0A>>>>> "William" =3D=3D William M= ills <wmills@yahoo-inc.com> writes:

    Wil= liam> OK, if this is covered by the mechanisms (which is
   = ; William> something a GSS expert probably knows but I did not) then
=     William> I'm less worried.  Is it then worthwhile to = add "Systems
    William> must know how to interpret critic= al mechanism attributes,
    William> but this is already r= equired by mechanism specifications."
    William> in the s= ection we're talking about to make it explicit
    William>= rather than implicit?

I'm now even more confused.
I definitely d= on't understand how this discussion is about criticality
of attributes.<= br>

---1036955950-393065964-1334851098=:14647-- From cweiske@cweiske.de Thu Apr 19 09:14: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 4B5E221F84D8 for ; Thu, 19 Apr 2012 09:14:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucVwu84ZuQWp for ; Thu, 19 Apr 2012 09:14:14 -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 A7B7321F84D5 for ; Thu, 19 Apr 2012 09:14:14 -0700 (PDT) Received: by mail.cweiske.de (Postfix, from userid 65534) id DFD5D10528834; Thu, 19 Apr 2012 18:14:13 +0200 (CEST) Received: from bogo (p54BD75DB.dip.t-dialin.net [84.189.117.219]) (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 6C36F1052867E for ; Thu, 19 Apr 2012 18:14:13 +0200 (CEST) Date: Thu, 19 Apr 2012 18:14:12 +0200 From: Christian Weiske To: apps-discuss@ietf.org Message-ID: <20120419181412.444d93fa@bogo> In-Reply-To: <06aa01cd1dba$b4935750$1dba05f0$@packetizer.com> References: <06aa01cd1dba$b4935750$1dba05f0$@packetizer.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/COVjZ9nSxlH1DGYV7fIPkni"; protocol="application/pgp-signature" Subject: Re: [apps-discuss] WebFinger vs SWD X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 16:16:21 -0000 --Sig_/COVjZ9nSxlH1DGYV7fIPkni Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Paul, > There is a current debate over what the appropriate technology is to > go forward with service discovery. On one hand, we have WebFinger, > which is documented in RFC 6415 and > http://tools.ietf.org/html/draft-jones-appsawg-webfinger. On the > other hand, there is "Simple Web Discovery" (SWD) which appeared on > the scene with a new OpenID protocol called "OpenID Connect". You > can read the draft here: > http://tools.ietf.org/html/draft-jones-simple-web-discovery. >=20 > Personally, I prefer WebFinger, as I suspect most of you do who have > been working in this area for a few years. It would be good to hear > voices of those who support the continued work on WebFinger on the > Applications Area WG list. =20 The big plusses for WebFinger in my eyes are: - WebFinger may be served from static files, while SWD requires an dynamic application behind the URL - It's possible to return multiple data at once with WF, and actually *discover* supported services - with SWD, you have to know the service beforehand. --=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_/COVjZ9nSxlH1DGYV7fIPkni Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk+QOdQACgkQFMhaCCTq+COYCACcD/nqFb5nEZrvo2CDM1aSUASK 6/gAnRVm8NZJB3lycwA0IOzCo/7nOXY9 =+zCW -----END PGP SIGNATURE----- --Sig_/COVjZ9nSxlH1DGYV7fIPkni-- From cweiske@cweiske.de Thu Apr 19 09:15: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 DC84821F8691 for ; Thu, 19 Apr 2012 09:15:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQgWJf1WWaDO for ; Thu, 19 Apr 2012 09:15:37 -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 E603721F8681 for ; Thu, 19 Apr 2012 09:15:35 -0700 (PDT) Received: by mail.cweiske.de (Postfix, from userid 65534) id 25B5010528834; Thu, 19 Apr 2012 18:15:35 +0200 (CEST) Received: from bogo (p54BD75DB.dip.t-dialin.net [84.189.117.219]) (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 C90A41052867E; Thu, 19 Apr 2012 18:15:34 +0200 (CEST) Date: Thu, 19 Apr 2012 18:15:33 +0200 From: Christian Weiske To: Dick Hardt Message-ID: <20120419181533.39c1de8e@bogo> In-Reply-To: <9B6B7851-5212-4313-88B5-DBBA7BC9BEDC@gmail.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9B6B7851-5212-4313-88B5-DBBA7BC9BEDC@gmail.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/h+kt2KuvibScW0Fap.rNwPF"; protocol="application/pgp-signature" Cc: Blaine Cook , "oauth@ietf.org WG" , apps-discuss@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 16:16:25 -0000 --Sig_/h+kt2KuvibScW0Fap.rNwPF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Dick, > > Gmail, aol, and yahoo all put up webfinger endpoints, but there > > hasn't been much movement, I think due to the chicken and egg > > nature of adoption around decentralized tools. > A couple months ago I was checking out what was up. The AOL and Yahoo > endpoints no longer worked. The Google one still did. Yahoo actually still serves the main entry point at http://www.yahoo.com/.well-known/host-meta that gives out the OpenID all accounts can use. --=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_/h+kt2KuvibScW0Fap.rNwPF Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk+QOiUACgkQFMhaCCTq+CO5wwCgqI0nb1SXFYY0PJK4tfAnqgLy o/cAoOsjhfuTZs5IFovzoREhWgVMLbvO =skBE -----END PGP SIGNATURE----- --Sig_/h+kt2KuvibScW0Fap.rNwPF-- From msk@cloudmark.com Thu Apr 19 09:32: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 8C20221F85D7 for ; Thu, 19 Apr 2012 09:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvfEnsoi8nqe for ; Thu, 19 Apr 2012 09:32:17 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA0D21F85D3 for ; Thu, 19 Apr 2012 09:32:17 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id zsY61i0030as01C01sY6ik; Thu, 19 Apr 2012 09:32:06 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=uqmJ_63mYWYA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=wZ4MbW4DGOb2YpNH_mMA:9 a=CjuIK1q_8ugA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 09:32:06 -0700 From: "Murray S. Kucherawy" To: "oauth@ietf.org WG" , Apps Discuss Thread-Topic: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHAQiL3t2BLv+ykaRA2rPEeZvEJaiW2xg Date: Thu, 19 Apr 2012 16:32:06 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334853126; bh=eMMvh5Kly7HPtF+v+F34G6DX6Vs4TSArWlg6xhDRLTQ=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ICHjn2NYso8V8ZPTjsE+wsvrJv7O3Sd5lrXvuKaRK1jBX+Ondf52KansoZsR5cY53 tW7SD/t5SxkkiVptj01RqnNiwjPruw/ZRgc8klzWXiHDWfbmmro6APWfrpaAeaVhxZ j+L2QOx2M2uZEi20vr79d32tT+IcjfWwSKhk+xas= Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 16:32:21 -0000 By all means people should correct me if they think I'm wrong about this, b= ut so far from monitoring the discussion there seems to be general support = for focusing on WebFinger and developing it to meet the needs of those who = have deployed SWD, versus the opposite. Does anyone want to argue the opposite? -MSK, appsawg co-chair From wmills@yahoo-inc.com Thu Apr 19 09:41: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 526C821F86EA for ; Thu, 19 Apr 2012 09:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.218 X-Spam-Level: X-Spam-Status: No, score=-17.218 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34bYsStH-tXx for ; Thu, 19 Apr 2012 09:41:08 -0700 (PDT) Received: from nm39-vm7.bullet.mail.bf1.yahoo.com (nm39-vm7.bullet.mail.bf1.yahoo.com [72.30.239.151]) by ietfa.amsl.com (Postfix) with SMTP id C893821F86E5 for ; Thu, 19 Apr 2012 09:41:06 -0700 (PDT) Received: from [98.139.215.142] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 19 Apr 2012 16:41:06 -0000 Received: from [98.139.212.200] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 19 Apr 2012 16:41:06 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 19 Apr 2012 16:41:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 236684.48078.bm@omp1009.mail.bf1.yahoo.com Received: (qmail 57186 invoked by uid 60001); 19 Apr 2012 16:41:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334853665; bh=CaE44Le6VvGX7T+MpltDrsLIESJiSlHgWlFat5CkBYw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=G2PMZJSCiwZBlGb5xWDnr6KiMxmSLAw5w/5ynOGkt+ia1UB8pnKyn9mlYn29U/BcAfP2oF6/3BJT1RsYFparm8S++1undSun0jvELuaGDtXm5dFuk/6+gLj9CzZc3p4w0Ot/3qN7HlSgdlBBaskIIwFjBetXLJuh5FmpO34ziB8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=k0fWdUN5GjrjZCPNoBCHPBCEdf9JdQchYTH7nBSiL6EWmKiFEDop4SNmD3gs6GFlLjJBqQdGeTRM3yGNIbrueA60ck7pdXeZbLtK/1esTK7TkL2Yr0QoMpZFn+cgOCIWadzkYYjINEyEVZSertKKOiuNXdg4fxDklD0hrCOa+IQ=; X-YMail-OSG: HByvUqIVM1nbChYj.f_4wSABmYXGK7aOJIWFnsCUieJ.bf9 1HEaz3TVN80GW1dMNdXfYYl7WO.4fz3AJ1wEwrErhWBnJel_IQRj_VFksQ6Z EqMEV_RlXLPND_yQNKEgz8q.2yRy8SLA8_HnxxeRQZuxnoJmpgKfgwbFu5sm fl1IYaV2vCU5ShqgKglnBAT7kAdC8jl2z28HFzui7ZD1_n0jfhpst0WOnSl7 S_og6J5rGL3US5Y8hkDnND6KKNyx3PYNZyjLoynpZCgcl3yrOcIjDC1LmXAK yJirnl.Kctt96cYOtAFyHqnGlgSZ1w4p.TKkLEUdmlfaCbTu4L7Ml5UNp_pA TNq5MS2_.uERaaI6_Pi6HBiOPha44BZ5vFea2PDYXzQQqY18HwNHN.obtLLP Y4RYnk2kUSXQR8efVyT_uijkHdF0wBDz9WJy01o6iERXOTmEgTww- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Thu, 19 Apr 2012 09:41:05 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> Message-ID: <1334853665.6573.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Thu, 19 Apr 2012 09:41:05 -0700 (PDT) From: William Mills To: "Murray S. Kucherawy" , "oauth@ietf.org WG" , Apps Discuss In-Reply-To: <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-2129002210-1334853665=:6573" Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 16:41:12 -0000 --1458549034-2129002210-1334853665=:6573 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I would characterize it as two distinct camps, folks that think WF can be u= pdated to do what SWD (growing contingent I think) does and folks that are = invested in SWD.=A0 I haven't seen any movement between those two camps, sp= ecifically that the SWD folks think WF can in fact solve their problem if u= pdated.=0A=0A-bill=0A=0A=0A=0A=0A>________________________________=0A> From= : Murray S. Kucherawy =0A>To: "oauth@ietf.org WG" ; Apps Discuss =0A>Sent: Thursday, April = 19, 2012 9:32 AM=0A>Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. S= imple Web Discovery (SWD)=0A> =0A>By all means people should correct me if = they think I'm wrong about this, but so far from monitoring the discussion = there seems to be general support for focusing on WebFinger and developing = it to meet the needs of those who have deployed SWD, versus the opposite.= =0A>=0A>Does anyone want to argue the opposite?=0A>=0A>-MSK, appsawg co-cha= ir=0A>=0A>_______________________________________________=0A>OAuth mailing = list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>= =0A>=0A> --1458549034-2129002210-1334853665=:6573 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I would characterize it as two distinct camps, folks that think WF can be= updated to do what SWD (growing contingent I think) does and folks that ar= e invested in SWD.  I haven't seen any movement between those two camp= s, specifically that the SWD folks think WF can in fact solve their problem= if updated.

-bill

From: Mu= rray S. Kucherawy <msk@cloudmark.com>
To: "oauth@ietf.org WG" <oauth@ietf.org>; Apps Discuss= <apps-discuss@ietf.org>
S= ent: Thursday, April 19, 2012 9:32 AM
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finge= r vs. Simple Web Discovery (SWD)

=0ABy all means peo= ple should correct me if they think I'm wrong about this, but so far from m= onitoring the discussion there seems to be general support for focusing on = WebFinger and developing it to meet the needs of those who have deployed SW= D, versus the opposite.

Does anyone want to argue the opposite?
<= br>-MSK, appsawg co-chair

__________________________________________= _____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth


--1458549034-2129002210-1334853665=:6573-- From Michael.Jones@microsoft.com Thu Apr 19 09:48: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 5E83721F8554; Thu, 19 Apr 2012 09:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.864 X-Spam-Level: X-Spam-Status: No, score=-3.864 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dzd7rV1X80j3; Thu, 19 Apr 2012 09:48:52 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 75BB221F8557; Thu, 19 Apr 2012 09:48:51 -0700 (PDT) Received: from mail79-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 16:48:51 +0000 Received: from mail79-ch1 (localhost [127.0.0.1]) by mail79-ch1-R.bigfish.com (Postfix) with ESMTP id 0FB4F4E05EB; Thu, 19 Apr 2012 16:48:51 +0000 (UTC) X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail79-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=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail79-ch1 (localhost.localdomain [127.0.0.1]) by mail79-ch1 (MessageSwitch) id 1334854128955743_11163; Thu, 19 Apr 2012 16:48:48 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail79-ch1.bigfish.com (Postfix) with ESMTP id E481E160046; Thu, 19 Apr 2012 16:48:48 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 16:48:47 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Thu, 19 Apr 2012 16:48:46 +0000 From: Mike Jones To: "Murray S. Kucherawy" , "oauth@ietf.org WG" , Apps Discuss Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHkoEkhvICdYO/UKyYU0IRCKljJaiWEsg Date: Thu, 19 Apr 2012 16:48:45 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 16:48:56 -0000 There are two criteria that I would consider to be essential requirements f= or any resulting general-purpose discovery specification: 1. Being able to always discover per-user information with a single GET (m= inimizing user interface latency for mobile devices, etc.) 2. JSON should be required and it should be the only format required (simp= licity and ease of deployment/adoption) SWD already meets those requirements. If the resulting spec meets those re= quirements, it doesn't matter a lot whether we call it WebFinger or Simple = Web Discovery, but I believe that the requirements discussion is probably t= he most productive one to be having at this point - not the starting point = document. -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy Sent: Thursday, April 19, 2012 9:32 AM To: oauth@ietf.org WG; Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) By all means people should correct me if they think I'm wrong about this, b= ut so far from monitoring the discussion there seems to be general support = for focusing on WebFinger and developing it to meet the needs of those who = have deployed SWD, versus the opposite. Does anyone want to argue the opposite? -MSK, appsawg co-chair _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From nico@cryptonector.com Thu Apr 19 09:53: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 D8FB221F8603; Thu, 19 Apr 2012 09:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3PSlRnYT5YJ; Thu, 19 Apr 2012 09:53:52 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id BDB6121F853D; Thu, 19 Apr 2012 09:53:52 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id DF2FD318065; Thu, 19 Apr 2012 09:53:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=GjoFIL8FmqkaVPHY+vd7GzSYwNtsP9fujqJKLzusvrse m4rFdkEgouUZ+ewbjhIqlqBpa/VGKxCiBo2XzTEJtMYn/Ba45suFRa/exl1vR9Js t7pVqHAJKYjQogBTwcpPTl8SJx97/oHCpmdjoY8KHiQqMwqYT2aK7M6a4I2am1o= 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:content-transfer-encoding; s= cryptonector.com; bh=OzQVFPzt/cqLtCU7NYJxOinB/q4=; b=HtG27pfbDTe 7Gf0WXqxtTToiXKx371TEwE5LAXOuUjhFtL2gYzb97WYSNBSpbjvA/g/JiXiDPwH ms0T+j4Ea273QNgM7ElCpoJZD3BDgUM3bPFyRVmpz3T1H35IHFuZ5DJ2zqVIRfYS 4O2vIgp7LwV8XcJ+stZX3tQUQYFtumkc= Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id B0E33318059; Thu, 19 Apr 2012 09:53:51 -0700 (PDT) Received: by pbcuo15 with SMTP id uo15so35092170pbc.25 for ; Thu, 19 Apr 2012 09:53:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.232 with SMTP id ih8mr5596170pbc.118.1334854431300; Thu, 19 Apr 2012 09:53:51 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Thu, 19 Apr 2012 09:53:51 -0700 (PDT) In-Reply-To: References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> <1334695329.43020.YahooMailNeo@web31812.mail.mud.yahoo.com> <1334712238.64475.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Thu, 19 Apr 2012 11:53:51 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 16:53:57 -0000 On Thu, Apr 19, 2012 at 8:49 AM, Sam Hartman wrote: >>>>>> "Nico" =3D=3D Nico Williams writes: > > =C2=A0 =C2=A0Nico> =C2=A0 =C2=A0The manner in which name attributes are c= onveyed by GSS > =C2=A0 =C2=A0Nico> mechanisms is mechanism-specific. =C2=A0If a GSS mecha= nism provides > =C2=A0 =C2=A0Nico> a way to indicate criticality then local policy MAY re= quire > =C2=A0 =C2=A0Nico> that any given GSS name attribute be expressed using c= ritical > =C2=A0 =C2=A0Nico> elements of the mechanism. > > What? > I'm not sure I'd expect local policy to be where that gets decided. > > =C2=A0 =C2=A0Nico> However, criticality is not > =C2=A0 =C2=A0Nico> exposed in this API because criticality is intended to= be > =C2=A0 =C2=A0Nico> handled by local policy and the mechanisms. > > I disagree with the part of that sentence after because. > I don't think we have consensus on why criticality is not part of the > API. Indeed, but criticality is still an existing feature of mechanisms. Obviously a critical element in a ticket or certificate or whatever still needs to be handled correctly, even if the API has no way to indicate it (although we can indicate so much via just the name of the attribute...). That's obvious enough. The implication is that any policy mapping such an element to a name attribute has to exist and be sufficient to satisfy the criticality of the mechanism element. But when a system wants to set a mechanism element corresponding to a given attribute name, how should the system decide whether that mechanism element is to be flagged as critical? Only local policy (or hardcoding, or deriving criticality from the attribute name/prefix) can do that given that the API lacks a way to request or indicate criticality. To me all that goes without saying. It seems obvious. The alternative is to say that none of these name attributes map to critical mechanism elements, but the first part (how to deal with receiving critical elements) remains. Nico -- From melvincarvalho@gmail.com Thu Apr 19 09:54: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 005F921F853D; Thu, 19 Apr 2012 09:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1yA+xiokqPH; Thu, 19 Apr 2012 09:54:06 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7628C21F8621; Thu, 19 Apr 2012 09:54:06 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2238508vcb.31 for ; Thu, 19 Apr 2012 09:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2xtqp7dvoLYhw3dFwgXP4LzL5KIkha366QNUmPh33Y4=; b=gc5Ca/sRrMqoeDiC8kbxzeUHNYgzAFAvT4/ZoeY7EyhyL2GdCK7wqQMbtMG/JfF+uy tbxwDUwzDuUFUh4I1zlKqd7KWGJ5SEBqTvsoYfGylIXr/ao6umAEvtuKyS4gXT+5WJpm aZYbbQ2KsqiVFzA4SOF5VlbMdjdv+YPtwjFzsAWIUiNuM1BNBPEgTtDvIbX9qYIhYr7y O0j2hXrPWe4WC1+flfHTYvYvfArh5vRxewTYXVtPPxXX4fPbmtF14tyPmG+MCUi57b62 oD+/87y0anx075OoyOFwIcW/QLwz10CDAM4HqsPoRCE69nMUCJPRdHMG6LUit4tkUKSp b1oA== MIME-Version: 1.0 Received: by 10.220.153.8 with SMTP id i8mr1487989vcw.73.1334854441552; Thu, 19 Apr 2012 09:54:01 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Thu, 19 Apr 2012 09:54:01 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Thu, 19 Apr 2012 18:54:01 +0200 Message-ID: From: Melvin Carvalho To: Mike Jones Content-Type: multipart/alternative; boundary=f46d043be068d0cb6c04be0b04f6 Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 16:54:11 -0000 --f46d043be068d0cb6c04be0b04f6 Content-Type: text/plain; charset=ISO-8859-1 On 19 April 2012 18:48, Mike Jones wrote: > There are two criteria that I would consider to be essential requirements > for any resulting general-purpose discovery specification: > > 1. Being able to always discover per-user information with a single GET > (minimizing user interface latency for mobile devices, etc.) > > 2. JSON should be required and it should be the only format required > (simplicity and ease of deployment/adoption) > > SWD already meets those requirements. If the resulting spec meets those > requirements, it doesn't matter a lot whether we call it WebFinger or > Simple Web Discovery, but I believe that the requirements discussion is > probably the most productive one to be having at this point - not the > starting point document. > +1 -- Mike > > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of Murray S. Kucherawy > Sent: Thursday, April 19, 2012 9:32 AM > To: oauth@ietf.org WG; Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > By all means people should correct me if they think I'm wrong about this, > but so far from monitoring the discussion there seems to be general support > for focusing on WebFinger and developing it to meet the needs of those who > have deployed SWD, versus the opposite. > > Does anyone want to argue the opposite? > > -MSK, appsawg co-chair > > _______________________________________________ > 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 > --f46d043be068d0cb6c04be0b04f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 19 April 2012 18:48, Mike Jones <Michael.Jon= es@microsoft.com> wrote:
There are two criteria that I would consider to be essential requirements f= or any resulting general-purpose discovery specification:

1. =A0Being able to always discover per-user information with a single GET = (minimizing user interface latency for mobile devices, etc.)

2. =A0JSON should be required and it should be the only format required (si= mplicity and ease of deployment/adoption)

SWD already meets those requirements. =A0If the resulting spec meets those = requirements, it doesn't matter a lot whether we call it WebFinger or S= imple Web Discovery, but I believe that the requirements discussion is prob= ably the most productive one to be having at this point - not the starting = point document.

+1

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

-----Original Message-----
From: apps-discuss-bounces= @ietf.org [mailto:apps= -discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 19, 2012 9:32 AM
To: oauth@= ietf.org WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)

By all means people should co= rrect me if they think I'm wrong about this, but so far from monitoring= the discussion there seems to be general support for focusing on WebFinger= and developing it to meet the needs of those who have deployed SWD, versus= the opposite.

Does anyone want to argue the opposite?

-MSK, appsawg co-chair

_______________________________________________
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

--f46d043be068d0cb6c04be0b04f6-- From jpanzer@google.com Thu Apr 19 09:57: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 BF44021F863E for ; Thu, 19 Apr 2012 09:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ8StinnmK-b for ; Thu, 19 Apr 2012 09:57:36 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5DB21F8621 for ; Thu, 19 Apr 2012 09:57:36 -0700 (PDT) Received: by qcsq13 with SMTP id q13so6470554qcs.31 for ; Thu, 19 Apr 2012 09:57:36 -0700 (PDT) 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-system-of-record; bh=1I6WPJfCXnc5r4Gt2kA3DpK6zu2VMaMoYS53PNMIRFA=; b=fXr0MAcRUhvAFkjI3clckPo7ZbgX6OoCkcanAYzlvX000cGW98UUuTM2AfXXQMKVF8 AVfMjho9rOiD6liMLEOk2/RJPUG7vwVQ+uX/yM6PxOTG64hMkolK0WQvpj6zsWDyF5Bf q7xWuiMCGQ01g/w1RyJerX7hVqAt1fwvOKC3jZ+TpHxBAq4FTlvnmaeCaCOdxLmOKEiA 7r/n36P1ui5fgbfZeWhMVCw+azqwFrDbSPFUheO4wEoWFC9emD2xYcc25D1yaFwNaKXg XLQPzN4rkvMwR2c/L1ekJGY3jN4zIMyJdW8RkTHV8YtI8eGl/OWvamn2MPIRm6rXLcfA 72rQ== 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-system-of-record:x-gm-message-state; bh=1I6WPJfCXnc5r4Gt2kA3DpK6zu2VMaMoYS53PNMIRFA=; b=jdyk5fNzExs4NiB3vZq3p3FoeATWV2LCBo/NnkryXTEdxt/GvzCY/cusbwIyl6PzBK woBKV35BaA5I0DvznIIpGebACS8+Y/V9KBuuzcULivKmJX+sMmIFe9ctKCFWnXpYhlMB xAfYjERkSj//mQGxXs3PVOKp+i/+qdM1KO1IqzM+b9EJpe1GCXJhw80vt/Gm7bRXuQpa zsElOD7lAvrlU62zU2ZUX8hk9M6IwZGBoaPGz+PPQxP+pulStxAVdKXrLo/al3RkgGCX iV7XiOZor1c34GWHAEY1C+2MaThNhdPIvmxL6kE7dDwlik2rPB98huCMbafMyuLR3MVt dPhw== Received: by 10.224.116.5 with SMTP id k5mr4129407qaq.19.1334854655838; Thu, 19 Apr 2012 09:57:35 -0700 (PDT) Received: by 10.224.116.5 with SMTP id k5mr4129393qaq.19.1334854655725; Thu, 19 Apr 2012 09:57:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.22.133 with HTTP; Thu, 19 Apr 2012 09:57:15 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> From: John Panzer Date: Thu, 19 Apr 2012 09:57:15 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=20cf3074d21e94cf5b04be0b11bb X-System-Of-Record: true X-Gm-Message-State: ALoCoQk5LUV3y6NU76cF7QazDFDcKj3xA4p6PQITOQHQ0NSHY2M6xxPE3/a8/+cXARZiTKXvim2K/x1tyWwydlrRSkH2koiZKeYq1mUDmbYZQqS2hQHmEtRoUX2HCaPopb/PHryZSasB0sXXj4MUn0DnhzCs2ig9Xg== Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 16:57:40 -0000 --20cf3074d21e94cf5b04be0b11bb Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 19, 2012 at 9:48 AM, Mike Jones wrote: > There are two criteria that I would consider to be essential requirements > for any resulting general-purpose discovery specification: > > 1. Being able to always discover per-user information with a single GET > (minimizing user interface latency for mobile devices, etc.) > Clarification: Does this requirement still allow HTTP redirects? (Meaning the server is in control of whether there is a single GET or not, basically, but can always ensure a single GET to minimize latency.) > > 2. JSON should be required and it should be the only format required > (simplicity and ease of deployment/adoption) > > I think nobody would argue against JSON support (certainly not me), I think few would argue against making it required. I personally would be okay with actually standardizing on JSON as the only required format as it doesn't preclude anyone from supporting other formats if they wish (for legacy/etc. reasons). > SWD already meets those requirements. If the resulting spec meets those > requirements, it doesn't matter a lot whether we call it WebFinger or > Simple Web Discovery, but I believe that the requirements discussion is > probably the most productive one to be having at this point - not the > starting point document. > > -- Mike > > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of Murray S. Kucherawy > Sent: Thursday, April 19, 2012 9:32 AM > To: oauth@ietf.org WG; Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > By all means people should correct me if they think I'm wrong about this, > but so far from monitoring the discussion there seems to be general support > for focusing on WebFinger and developing it to meet the needs of those who > have deployed SWD, versus the opposite. > > Does anyone want to argue the opposite? > > -MSK, appsawg co-chair > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --20cf3074d21e94cf5b04be0b11bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 19, 2012 at 9:48 AM, Mike Jones <Michael.Jo= nes@microsoft.com> wrote:
There are two criteria that I would consider to be essential requirements f= or any resulting general-purpose discovery specification:

1. =A0Being able to always discover per-user information with a single GET = (minimizing user interface latency for mobile devices, etc.)

Clarification: =A0Does this requirement still allow H= TTP redirects? =A0(Meaning the server is in control of whether there is a s= ingle GET or not, basically, but can always ensure a single GET to minimize= latency.)
=A0

2. =A0JSON should be required and it should be the only format required (si= mplicity and ease of deployment/adoption)


I think nobody would argue against JSO= N support (certainly not me), I think few would argue against making it req= uired. =A0I personally would be okay with actually standardizing on JSON as= the only required format as it doesn't preclude anyone from supporting= other formats if they wish (for legacy/etc. reasons).
=A0
SWD already meets those requirements. =A0If the resulting spec meets those = requirements, it doesn't matter a lot whether we call it WebFinger or S= imple Web Discovery, but I believe that the requirements discussion is prob= ably the most productive one to be having at this point - not the starting = point document.

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

-----Original Message-----
From: apps-discuss-bounces= @ietf.org [mailto:apps= -discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 19, 2012 9:32 AM
To: oauth@= ietf.org WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)

By all means people should co= rrect me if they think I'm wrong about this, but so far from monitoring= the discussion there seems to be general support for focusing on WebFinger= and developing it to meet the needs of those who have deployed SWD, versus= the opposite.

Does anyone want to argue the opposite?

-MSK, appsawg co-chair

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


_______________________= ________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--20cf3074d21e94cf5b04be0b11bb-- From msk@cloudmark.com Thu Apr 19 10:02: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 0F19021F8646 for ; Thu, 19 Apr 2012 10:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9MmCCvRwYvG for ; Thu, 19 Apr 2012 10:02:21 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id B0AAB21F863D for ; Thu, 19 Apr 2012 10:02:21 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id zt2f1i0010ZaKgw01t2fmj; Thu, 19 Apr 2012 10:02:39 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=Vhm4rtfK4QIA:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=yMhMjlubAAAA:8 a=zwOUNh7tUOjHoIInj9UA:9 a=szDEiDA6S8twofwXI_MA:7 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=-AOE9ft50oIA:10 a=SSmOFEACAAAA:8 a=fjQxKX33D8qoFgcPYFMA:9 a=-XqMH-EH7er2g2nBGhQA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=tXsnliwV7b4A:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 10:02:20 -0700 From: "Murray S. Kucherawy" To: "oauth@ietf.org WG" , Apps Discuss Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHk0Wy2pvmKYCykKGt3/ABzAPspaiX67Q Date: Thu, 19 Apr 2012 17:02:20 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FAD6C@exch-mbx901.corp.cloudmark.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280FAD6Cexchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334854959; bh=K76ordO5IAF/WLMQEx42qysVJguy3kaI8hJMkdSKcH0=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=PBdTvaa3J0bL9rXTvBA+INWRaXmWA/IiwqlqYrB0tDPhz+Veo4CVQNZ3EYF1MUSnt 9jh2y/XI7BOmOqjq3LMmMBfOaj5gBkCCbOqLXEB2rcyZZ0gAR4FJGvXIfW90bkmYcN dju76oD7Wgrac93TOQtDxGRuxqHNnCIB7WPNQ9Wk= Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 17:02:26 -0000 --_000_9452079D1A51524AA5749AD23E0039280FAD6Cexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fair enough, carry on. :) From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Thursday, April 19, 2012 9:54 AM To: Mike Jones Cc: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) On 19 April 2012 18:48, Mike Jones > wrote: There are two criteria that I would consider to be essential requirements f= or any resulting general-purpose discovery specification: 1. Being able to always discover per-user information with a single GET (m= inimizing user interface latency for mobile devices, etc.) 2. JSON should be required and it should be the only format required (simp= licity and ease of deployment/adoption) SWD already meets those requirements. If the resulting spec meets those re= quirements, it doesn't matter a lot whether we call it WebFinger or Simple = Web Discovery, but I believe that the requirements discussion is probably t= he most productive one to be having at this point - not the starting point = document. +1 -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org]= On Behalf Of Murray S. Kucherawy Sent: Thursday, April 19, 2012 9:32 AM To: oauth@ietf.org WG; Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) By all means people should correct me if they think I'm wrong about this, b= ut so far from monitoring the discussion there seems to be general support = for focusing on WebFinger and developing it to meet the needs of those who = have deployed SWD, versus the opposite. Does anyone want to argue the opposite? -MSK, appsawg co-chair _______________________________________________ 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 --_000_9452079D1A51524AA5749AD23E0039280FAD6Cexchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Fair enough, carry on.&nb= sp; J

 <= /p>

From: Melvin C= arvalho [mailto:melvincarvalho@gmail.com]
Sent: Thursday, April 19, 2012 9:54 AM
To: Mike Jones
Cc: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Dis= covery (SWD)

 

 

On 19 April 2012 18:48, Mike Jones <Michael.Jones@microsoft.com> wrote= :

There are two criteria that I would consider to be e= ssential requirements for any resulting general-purpose discovery specifica= tion:

1.  Being able to always discover per-user information with a single G= ET (minimizing user interface latency for mobile devices, etc.)

2.  JSON should be required and it should be the only format required = (simplicity and ease of deployment/adoption)

SWD already meets those requirements.  If the resulting spec meets tho= se requirements, it doesn't matter a lot whether we call it WebFinger or Si= mple Web Discovery, but I believe that the requirements discussion is proba= bly the most productive one to be having at this point - not the starting point document.


+1

                    &nbs= p;          -- Mike


-----Original Message-----
From: apps-discuss-bounces= @ietf.org [mailto:apps= -discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 19, 2012 9:32 AM

To: oauth@ietf.org WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)

By all means people should correct me if they think = I'm wrong about this, but so far from monitoring the discussion there seems= to be general support for focusing on WebFinger and developing it to meet = the needs of those who have deployed SWD, versus the opposite.

Does anyone want to argue the opposite?

-MSK, appsawg co-chair

_______________________________________________
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

 

--_000_9452079D1A51524AA5749AD23E0039280FAD6Cexchmbx901corpclo_-- From sm@elandsys.com Thu Apr 19 10:59: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 C460D21F86AD for ; Thu, 19 Apr 2012 10:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5vb6JvfPdj4 for ; Thu, 19 Apr 2012 10:59:31 -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 9205321F867B for ; Thu, 19 Apr 2012 10:59:31 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.236]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3JHxBjk028684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Apr 2012 10:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334858364; i=@elandsys.com; bh=DsokFbrUWwVLKviUUGtxVfVTpPVaOVxQQprMcXV8u94=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=I3gc2+VKxSATxtI+z7dSpdiuJ5gBJ7coI9wyymbHe/z52bQfnVqH+vWQ10NI01qjd LJWWdT1gUBe1JgzsBfnJY2ZMkqRYxS2Y8TJj16hf3wXKDm5SwO3zODj16lP7hPfLsN F5gi/IoIRcLBoBv6vxj1r8Sbqbn2MlUBJMW5KSWI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334858364; i=@elandsys.com; bh=DsokFbrUWwVLKviUUGtxVfVTpPVaOVxQQprMcXV8u94=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=04D13U+OhYbOoFu3PbTIwKzOq00WsBH4n5iwlEIl2Ltg0AT0WWELFFIxx858zpcOe LIJtcjE7eMdwwpvbbA3ZwA+DeK8W1uVNSAxa3QdDYCWfUChxUnYuMXQfoMCwY8NKes /gwsvqORCCfTScmzMWIOCF4vMARK+p8DK8+ymOU0= Message-Id: <6.2.5.6.2.20120419104257.094c4f90@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Apr 2012 10:57:49 -0700 To: Eliot Lear From: S Moonesamy In-Reply-To: <4F900F29.7010900@cisco.com> References: <6.2.5.6.2.20120410125815.08d5c788@elandnews.com> <4F900F29.7010900@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-lear-lisp-nerd-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 17:59:33 -0000 Hi Eliot, At 06:12 19-04-2012, Eliot Lear wrote: > > According to draft-ietf-lisp-06 (Section 3), PI addresses are assigned. I should have explained this. Allocations and assignments are term of art in the RIR world. draft-lear-lisp-nerd-08 uses "allocated". >This section refers to various approaches that COULD be taken to manage >NERDs. One such approach is that RIRs manage them. Ok. > > Where is that specified in RFC 5321? > >I used Section 2.3.5. However... RFC 5321 contains 5324 lines. Given that the draft has nothing to do with SMTP, it may save the reader some time if the section was mentioned. >Corrected as well. The gem I pointed to is that you were correct. It seems that somebody forgot to update the paper trail for 3232 to keep up with the times. BTW, you could use RFC 5280 as a reference for a X.509 certificate. Regards, S. Moonesamy From paulej@packetizer.com Thu Apr 19 11:09: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 9534821F8610 for ; Thu, 19 Apr 2012 11:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVRD5QrrnlvE for ; Thu, 19 Apr 2012 11:09:42 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D542021F85BB for ; Thu, 19 Apr 2012 11:09: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 q3JI9d6u012487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Apr 2012 14:09:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334858980; bh=HFUflrUGlcECIKQQdfqdEYmoUQYCOOe/m/OA6Qtvg8Y=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=uV8bAxDyrl7QwBuiuN+gZ8yU4icpesft38Tx7cmZrOoWWXi34bh1MQulZQ5DrG38I s/RhEyo+Dwv28d1F+Vwo/lnvSylVAFe+Ozx4Wz7uUFP/TXqdPjhv0A6qGC1jG7aZbV x+f8itYWAi9GJv+7N5r3AOZR1GalHgt9jE24v1oc= From: "Paul E. Jones" To: "'Pelle Wessman'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <04fb01cd1cf6$23131c80$69395580$@packetizer.com> <069501cd1daf$20087580$60196080$@packetizer.com> <15AB1540-7555-4C02-A29A-AAE0ADA786B3@kodfabrik.se> In-Reply-To: <15AB1540-7555-4C02-A29A-AAE0ADA786B3@kodfabrik.se> Date: Thu, 19 Apr 2012 14:09:59 -0400 Message-ID: <080d01cd1e57$a2f9f290$e8edd7b0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_080E_01CD1E36.1BEA9C80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0B/rNJdACTlkYtAqzWkh0CKCokFwIKVUEBASLQzuwCKHMIGJW8u0mg Content-Language: en-us Cc: 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 18:09:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_080E_01CD1E36.1BEA9C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Pelle, My own implementation also accepts queries that to not include "acct:". See: https://packetizer.com/.well-known/host-meta.json?resource=paulej@packetizer .com I will return "acct:paulej@packetizer.com" as an alias. The reason this was done was because Blaine (he's quite influential) was arguing for a while that we did not need to use a URI. After some time, I think there was convergence on use of "acct". In any case, I don't think we should look to existing implementations as the way to do it. We need to decide on one approach and put that into the spec. The "mailto" URI may certainly return something, just as any other URI might. However, if we're making a reference to a user's account, we should use "acct" and not "mailto". As noted on the list before, some services may not offer email, yet the user has an account (e.g., Twitter). One's email address (or set of addresses) can always be returned as data when querying a user account. That said, you do present a very interesting use case. I'm surprised a domain would allow two different users to have a name like pelle@flattr.com, where the meaning is truly differentiated only by the URI scheme. That must be a source of confusion and it's not clear how WebFinger could sort that out. My personal opinion is that one should not tell the average user to use mailto: or acct:, as the average user will not understand it; they should not have to understand it. I'm not sure what to suggest in this case. Paul From: Pelle Wessman [mailto:pelle@kodfabrik.se] Sent: Thursday, April 19, 2012 2:53 AM To: Paul E. Jones Cc: 'Melvin Carvalho'; 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) While WebFinger officially requires an "acct" URI I believe almost all current implementers accept a "pelle@kodfabrik.se" URI as being the same as "acct:pelle@kodfabrik.se". Gmail.com does, StatusNet/Identi.ca does, we at Flattr does. So there is a discrepancy between the WebFinger specification and real life implementations. Examples: http://www.google.com/s2/webfinger/?q=voxpelli@gmail.com http://identi.ca/main/xrd?uri=voxpelli@identi.ca https://flattr.com/xrd/lrdd?uri=voxpelli@flattr.com Also, speaking from a Flattr-perspective, mail addresses and user accounts are _not_ the same thing in our system. I myself have the e-mail pelle@flattr.com but I have the web site account voxpelli@flattr.com and the web site account pelle@flattr.com doesn't belong to me but to one of our users. I believe most web sites, at least the smaller ones, works like this - that the e-mail system and the web system is completely separated from each other and that the user identifiers in one can conflict with the identifiers in the other. I would say that a lookup for "mailto:pelle@flattr.com" should return info about the user behind that e-mail address (if it should return anything) but that a lookup for "pelle@flattr.com" or "acct:pelle@flattr.com" should always return data about the web site user and that clients should be encouraged to use "acct:" to make it clear that they want the web site's user, but that they shouldn't be required to do so. / Pelle 19 apr 2012 kl. 00:03 skrev Paul E. Jones: Melvin, WebFinger does discovery on any URI. It might be "http", "mailto", "ftp", or "acct". So, it's not entirely correct to say that WebFinger does not do discovery using email addresses. I could change my server code pretty easily to accommodate mailto. Use of mailto was something discussed at length. As others pointed out, it was not necessarily favored by all, but it was recognized to be insufficient for some situations. Most importantly, nobody other than us geeks knows what the heck a "mailto" is. But, we do recognize that social sites like Twitter have accounts. Thus, after the lengthy debate that took place in several places, it was decided to go with "acct". It actually does have a useful purpose. And its construction is made to look similar to "mailto" so that the a user would just enter what they consider to be an "email" address, including things we know are not like user@twitter.com. Using "mailto" is technically incorrect, but users never have to know or care about that. Behind the scenes, we use "acct". I would personally never show an end user "acct:paulej@packetizer.com". Rather, I would just tell people that their account ID is "paulej@packetizer.com". That may or may not be their address. Query a Twitter account and it might return an email address that differs (if Twitter were to share that info). Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Wednesday, April 18, 2012 6:05 AM To: Paul E. Jones Cc: Mike Jones; Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) On 18 April 2012 01:59, Paul E. Jones wrote: Melvin, On "acct:". Humans will usually interchange an acct URI and mailto URI, probably never using either scheme directly in practice. That's natural and expected, if not desired. The intent is that we define something that looks like an email ID, but it's not an email ID. Some services, perhaps Twitter being most notable, do no use email addresses. Yet, you might have an account there. So, user@twitter.com might be used by humans and automated systems would convert that to acct:user@twitter.com . It would not be appropriate to use mailto: since it's not an email ID. We did have a lot of debate about the use of "acct". If you query my WebFinger server, you'll see that it will work without "acct:" prefixed, as that was a suggestion made a year or so ago. It will inspect the input and if it looks like an acct URI, it will assume it is. The "acct" URI will be returned as an alias. However, we should always use some kind of URI scheme to remove the guesswork. The client can often make a very good guess as to whether it's looking for a user account or something else. So, let it tell the server what it is looking for explicitly. We need a URI scheme, because WebFinger can be used to discover all kinds of information related to a given domain, not only user information. It can be used to query information about any URI, be that a web page, a user account, device on the network, etc. If we got rid of "acct", then we would have a system where we sometimes use a URI scheme and sometimes we do not. Results might be inconsistent, as the server may not make the right guess, unless we agreed that absence of a scheme defaults to "acct:". However, I see no reason for the client to be so lazy to not include "acct:". The user might (and probably will) exclude it, but the client code can add it. At this point, I'd argue the "train has left the station" on "acct", too. The current WebFinger spec exists (in part) to formally document that which has adopted; it's not a new thing. Paul, thank you for your explanation on lookup based on acct: (WebFinger) vs lookup based on mailto: (SWD). I think this is a major difference. The original WebFinger proposal was *supposed* to give extra information about an email address. >From wikipedia: "WebFinger is an Internet protocol that aims to provide information about people by their E-mail addresses." >From webfinger.org: "Put your email address into the box above, click the button" >From google code (the top hit on google): "making email addresses readable again" And perhaps most importantly from the spec, the first example: "Assume you receive an email from Bob..." However only SWD here is doing email based discovery (mailto :). WebFinger *now* doing acct: based discovery, which is a departure from the original use case. Im glad that some people have voiced support for acct:, but I still believe that to be a minority. I agree, that the new acct: scheme should for in another document, rather than shoe horned into an email based discovery system. IMHO, it's better to solve one problem (ie email based discovery) simply and well, than to half solve two problems (ie a new uri scheme for identity) in a single attempt. Paul A couple of points: 1. JSON ======= I think at the time webfinger was created in 2009, XML was the de facto serialization, used in AJAX, SOAP and many other systems. Today I'm hearing more and more, that both developers and publishers, want to work with JSON, rather than, having to support both xml and json. Content negotiation also confuses some publishers. In my view, this is a great simplification that webfinger can learn from SWD. 2. acct: scheme ============= The acct: URI scheme has not proved popular, imho, and has added a layer of complexity and confusion. How do we get from acct: to mailto:? When should you use acct: and when mailto: (the spec says acct:user@host may be different from mailto:user@host). What about the forms. How about linked data ecosystems that want to cross link identifiers, do they now have to consider both cases? >From the original post introducing acct: "I don't expect everyone to like this idea. I wish I could say I love it, but I am simply content with it." I dont know of anyone in the community (and correct me if this has changed) that really loves acct:, or perhaps even likes the acct: idea. SWD has shown you can do discovery without acct: and I think that's a big plus. One final side note is that this almost becomes trivial when you can do SPARQL queries. "void" is already registered by the W3C with IANA in .well-known in order to discover SPARQL endpoints. It may be overkill in some people's eyes, but Linked Data (which predates webfinger), particularly newer things like JSON LD, are a lot bigger than they were in 2009. In a few years it may become the definitive discovery mechanism anyway. _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_080E_01CD1E36.1BEA9C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

--20cf3071d0b61a281104be0ea4dd-- From stpeter@stpeter.im Thu Apr 19 14:16: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 EA10B11E80BE for ; Thu, 19 Apr 2012 14:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE23HbAWDa1J for ; Thu, 19 Apr 2012 14:16:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5594E11E80B8 for ; Thu, 19 Apr 2012 14:16:09 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5E7EB40058; Thu, 19 Apr 2012 15:30:26 -0600 (MDT) Message-ID: <4F908097.9030101@stpeter.im> Date: Thu, 19 Apr 2012 15:16:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Melvin Carvalho References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FF1C6A@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 21:16:10 -0000 [removing oauth@ietf.org] On 4/19/12 3:12 PM, Melvin Carvalho wrote: > It could be a URN eg > > urn:acct:user@host (no new uri scheme needed) No new URI scheme needed, but you'd need a new URN Namespace Identifier. Six of one, half a dozen of the other. Peter -- Peter Saint-Andre https://stpeter.im/ From sm@elandsys.com Thu Apr 19 14:16: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 1682111E80B8; Thu, 19 Apr 2012 14:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQxObidyqPBb; Thu, 19 Apr 2012 14:16:09 -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 9B21411E80BA; Thu, 19 Apr 2012 14:16:09 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.236]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3JLFgXd007870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Apr 2012 14:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334870164; i=@elandsys.com; bh=tmqFeoVo8TS4mbGE7iNnGf5SFs7IacjXLpnZWslwpdQ=; h=Date:To:From:Subject:Cc; b=pW54bv9k2kYGtnHbXdfvzJ9QIXy3w58OeYRoNGZ2Xo4kzQEvdDcd7wMGppD/31P6F O0DIZc/fPOLAV+ZX4RFoB0IemvzSL4qQMqgPqhB1DPFIcaW06UEVRhI+fbfizszL2f KVvTTHVFd9MXdK2isgWlCFP5v2RjU5Adsoc9Rq2E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334870164; i=@elandsys.com; bh=tmqFeoVo8TS4mbGE7iNnGf5SFs7IacjXLpnZWslwpdQ=; h=Date:To:From:Subject:Cc; b=1gC/d5AeOVoypuAf4GKSRDc8kqb8qdoANG8o2DHNHoJjMu05BEB6DrlBBiDngUtpX iyG05eetINoppGwwhQusQ3nnE010xbVx/k96s95P8n/zg/wtWMghkbacSNHN2l9rB8 sApK7wjlbnM8pP8g8Br0krp4J5On0g6DSzuorrEQ= Message-Id: <6.2.5.6.2.20120419130040.0b4ee328@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Apr 2012 14:14:43 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-kucherawy-marf-source-ports.all@tools.ietf.org, marf@ietf.org Subject: [apps-discuss] APPSDIR review of draft-kucherawy-marf-source-ports-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, 19 Apr 2012 21:16:11 -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-kucherawy-marf-source-ports-01 Title: Source Ports in ARF Reports Reviewer: S. Moonesamy Review Date: April 19, 2012 Summary: This document is almost ready for publication as a Proposed Standard. This draft defines and registers an additional header field for use in Abuse Reporting Format reports. The header field carries source port information, which can be useful in IP address sharing scenarios. Minor issues: In Section 3: "A new ARF reporting field called "Source-Port" is defined. When present in a report, it MUST contain the TCP or UDP source port matching the "Source-IP" field in the same report, thereby describing completely the origin of the abuse incident." UDP is not used for SMTP. It's easier just to remove "TCP or UDP". "When any report is generated that includes the "Source-IP" reporting field, this field SHOULD also be present." It's difficult to tell when not to do the above. I suggest replacing SHOULD with RECOMMENDED: it is RECOMMENDED to add this header field. In the Security Considerations section, I suggest referring to RFC 6302. Nits: In the Abstract: "This document registers an additional header field for use in Abuse Reporting Format reports to permit the identification of the source port of the connection involved in an abuse incident." The sentence describes a registration and what the header field does. I suggest breaking the sentence into two parts or keeping it easy: This document defines an additional header field for use in Abuse Reporting Format reports to permit the identification of the source port of the connection involved in an abuse incident. In the Introduction Section: "[ARF] defined the Abuse Reporting Format, a new header message format for use in reporting incidents of email abuse." I suggest removing "new" as it won't be new in a year or two. "header message format" is confusing. I'll suggest: [ARF] defined the Abuse Reporting Format, an extensible format for Email Feedback Reports. These reports are used used to report incidents of email abuse. [ARF] was extended by ... "Although those specifications gave the capability to include the source IP address in the report, the source port was not included I suggest: These specifications provided for the source IP address to be included in a report. As explained in [LOG], the deployment of IP address sharing techniques requires the source port values to be included in reports if unambiguous identification of the origin of abuse is to be achieved. "Accordingly, this memo registers an ARF reporting field to contain this information and provides guidance for its use." I suggest: This document defines ARF reporting field to specify the source port. I don't see much guidance in the draft. The reference to I-D.IETF-MARF-AUTHFAILURE-REPORT should be updated to RFC 5691. In Section 3: 'A new ARF reporting field called "Source-Port" is defined.' That should be header field (see Section 3.2 of RFC 5965). I gather that the intent is to make this an optional header field. I suggest specifying that Section 3.2 is being updated. That should also be done for Section 3.1 of RFC 6591. In Section 4: "Description: TCP or UDP source port from which the reported connection originated" I suggest removing "TCP or UDP". Regards, S. Moonesamy From paulej@packetizer.com Thu Apr 19 14:17: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 DF5B111E80B8 for ; Thu, 19 Apr 2012 14:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0k5Q-UjsbT38 for ; Thu, 19 Apr 2012 14:17:28 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 23CCB11E8073 for ; Thu, 19 Apr 2012 14:17:28 -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 q3JLHQCi018229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Apr 2012 17:17:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334870247; bh=86g95tz7knRnRSCH7Mz30JRhlkzAy0v+ggm70JhpLy0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=pnL+ypZq0daNbdguN47vAva5ppN/ORT04yYcH8bZajuQ7QG4MgiqMwrdLdExEkHLI HwrUAy2+RSTWScwZ+9euu/Mt/V31u6GrnZEGT23n9SeFKiLEJ1dvuwMRrAPAFzII89 PhfAf0MsGyHgjjz/ju62DCGcDL9lAvo0vmVSaNt0= From: "Paul E. Jones" To: "'Bob Wyman'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <04fb01cd1cf6$23131c80$69395580$@packetizer.com> <069501cd1daf$20087580$60196080$@packetizer.com> <15AB1540-7555-4C02-A29A-AAE0ADA786B3@kodfabrik.se> <084401cd1e69$f8ff4250$eafdc6f0$@packetizer.com> In-Reply-To: Date: Thu, 19 Apr 2012 17:17:46 -0400 Message-ID: <087201cd1e71$de687da0$9b3978e0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0873_01CD1E50.575A8720" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0B/rNJdACTlkYtAqzWkh0CKCokFwIKVUEBASLQzuwCKHMIGAI9BikIAS4MPVkBw+S5OgHyDJKolYPqmbA= Content-Language: en-us Cc: 'Apps Discuss' Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 21:17:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0873_01CD1E50.575A8720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bob, =20 We could do that. I changed my WF server code to return a response for = any URI scheme: https://packetizer.com/.well-known/host-meta?resource=3Dfoorbar:paulej@pa= cketi zer.com =20 It returns the canonical form (the acct: URI) as an alias. =20 We could do as do as you suggest and return a correct response only to = URI schemes that are known. I have no objection to that, except that I do = not want users to have to know the URI scheme to use. I do not want the = average user to have to know or care that it=92s a mailto URI or an xmpp URI or whatever. Users deal with identifiers like =93paulej@packetizer.com=94. = That=92s all they should have to worry with. I=92d rather have the WF client = convert that to a canonical form, namely acct:paulej@packetizer.com before = issuing a query.=20 =20 I do think any WF server should respond appropriately to any URI. = However, we should remove the guesswork and I think responding to any scheme (as = my server is now doing) is not quite right. If I visit a remote web site = and want to login using OpenID, I would enter paulej@packetizer.com. The = remote site needs to convert that to something. What is that? I argue that = mailto is a good assumption, but not necessarily correct. XMPP is another good assumption, but may also be incorrect. If we agree to a standard form (acct:) then it removes the guesswork on the client. I like = predictability and consistency. =20 Only when a client really has a specific reason for query using a = different URI like h323:paulej@packetizer.com should it do that, IMO. But, I = agree the server should return an intelligent reply if asked. Paul =20 From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob = Wyman Sent: Thursday, April 19, 2012 4:36 PM To: Paul E. Jones Cc: Melvin Carvalho; Goix Laurent Walter; Apps Discuss Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) =20 =20 On Thu, Apr 19, 2012 at 4:21 PM, Paul E. Jones wrote: Melvin, =20 We could use mailto, but mailto is for email. That refers to one = modality of communication related to a person, but would not represent an = =93account=94 at a domain. Further, it would not be applicable to services like = Twitter. =20 I would make the same argument for XMPP. It is another communication modality for a user at a given domain. =20 In general (though we=92ve seen evidence of at least one exception), paulej@packetizer.com should be an identifier reserved for a specific account. I use that for my XMPP address, my email address, and I would = use that to discover my OpenID URI with WebFinger. No matter what address scheme one starts with, acct:paulej@packetizer.com should return information about = my account and likely pointers (directly or indirectly) to all of the other URIs I use. =20 The generic nature of =93user@domain=94 is perhaps why Blaine was = arguing at one point for no scheme at all. However, we should use a properly formed = URI since WF returns information for a URI, which then leads us to ask = =93what scheme shall we use?=94 Thus, =93acct:=94 was born. It would be legal = to query xmpp:paulej@packetizer.com . = However, that may or may not return a result. Presently, it does not. I most definitely would not expect any WebFinger server to consider every = possible scheme under the sun. =20 It would, I think, be ideal if we could expect that any domain that = provides WebFinger support would allow queries for any protocols also supported = by that domain. Thus, if a domain supports mailto:, xmpp: or foobar: = services in addition to WebFinger, it should probably support queries for = identifiers used by those services, in addition to acct:, but for no others. In = general, I think it also would be good practice to ensure that any query for a protocol other than acct: should return a link to an acct: identifier. =20 =20 Use of mailto: is popular, because so many people use email. Funny = thing is that the OpenID folks at the start were against that, arguing that = email was going to die. They were pretty insistent that OpenID URIs should = look like https://openid.packetizer.com/paulej. And, one could use WF to = query that, too. But, you=92ll get a 404 on my server. I do not want every possible identifier to return a response. =20 IMO, =93acct:=94 is a reasonable compromise. It has a meaning (an = account URI), it=92s communication-protocol neutral (unlike xmpp:, sip:, h323:, = mailto:, http:, etc.), and we=92ve debated this at great length for at least 2 or = 3 years now. People agree =93acct:=94 is not the most appreciated scheme, = but =93mailto:=94 is not an appropriate since that assumes a particular = protocol. Ditto for all other protocol-specific URI schemes. =20 Paul =20 From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]=20 Sent: Thursday, April 19, 2012 10:50 AM To: Goix Laurent Walter Cc: Pelle Wessman; Paul E.Jones; Apps Discuss Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) =20 =20 On 19 April 2012 15:59, Goix Laurent Walter wrote: Possibly a standard discovery mechanism should rely on some sort of URI = and not a simple token string. URIs representing social network accounts are missing so far and at least this type of URI should be discoverable. Optionally I believe any type of other uri may, but with no guarantee. = It may be a matter of permissions, internal db lookups and/or associations = or else on the server to decide whether to provide a meaningful response to = it. This is somehow already clarified in section 5 of the wf draft. Why do you say "URIs representing social accounts are missing so far"? = And if so, from which systems? =20 For example, Facebook has a pretty good system for representing their accounts as URIs (open graph protocol), as does SIOC, and people like status.net (inventor of OStatus who have a pretty good FOAF impl.) etc. = All of these use HTTP URIs as their machine representation, rather than any proposed acct: scheme, for example. =20 I thought this use case is mainly relevant to the big webmail providers. Email style discovery is missing (apart from the specific case of a = public key in GPG), so if you want a full Web sytle solution use void (already registered with IANA). If void is too complex, choose something = simpler. SWD seems a simpler solution, at this point, technically. WF may have = the lead on adoption, I dont know. Perhaps something can be learnt by each system from each other ... e.g. the JSON vs XML discussion. Merging the best parts from both specs could be a great idea... As for non mailto: URI schemes, that in itself is an interesting = problem, perhaps a big topic. To me, xmpp: is a very interesting candidate. = Again void can be used for this, but maybe WF/SWD is an interesting thing to deploy. Having a lookup for the tel: scheme would be kind of amazing = ... but is a whole problem in itself, including finding the well known = location. HTTP discovery is really in advanced stages, with mature deployments, = under the W3C / Linked Data. I would personally NOT encourage acct: lookup because it's just too confusing for the average developer, fractures identity, does not provide HTTP style 'follow your nose', and = ultimately, will probably not be a long lived identifier, given how quickly the web identity space evolves (just my 2 cents). I think sweet spot here is find the path of least resistance, for a = really good discovery system for email addresses. Other schemes *could* be a = plus depending on the context, but the most compelling and useful lookup that = is filling a gap I think, is mailto: based. =20 walter =20 Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = Per conto di Pelle Wessman Inviato: gioved=EC 19 aprile 2012 13.53 A: Paul E.Jones Cc: 'Apps Discuss' Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD) =20 While WebFinger officially requires an "acct" URI I believe almost all current implementers accept a "pelle@kodfabrik.se" URI as being the same = as "acct:pelle@kodfabrik.se ". Gmail.com does, StatusNet/Identi.ca does, we at Flattr does. So there is a = discrepancy between the WebFinger specification and real life implementations. =20 Examples: =20 http://www.google.com/s2/webfinger/?q=3Dvoxpelli@gmail.com http://identi.ca/main/xrd?uri=3Dvoxpelli@identi.ca https://flattr.com/xrd/lrdd?uri=3Dvoxpelli@flattr.com =20 Also, speaking from a Flattr-perspective, mail addresses and user = accounts are _not_ the same thing in our system. I myself have the e-mail pelle@flattr.com but I have the web site account voxpelli@flattr.com and = the web site account pelle@flattr.com doesn't belong to me but to one of our users. I believe most web sites, at least the smaller ones, works like = this - that the e-mail system and the web system is completely separated from each other and that the user identifiers in one can conflict with the identifiers in the other. =20 I would say that a lookup for "mailto:pelle@flattr.com" should return = info about the user behind that e-mail address (if it should return anything) = but that a lookup for "pelle@flattr.com" or "acct:pelle@flattr.com " should always return data about the = web site user and that clients should be encouraged to use "acct:" to make = it clear that they want the web site's user, but that they shouldn't be required to do so. =20 / Pelle =20 =20 19 apr 2012 kl. 00:03 skrev Paul E. Jones: =20 Melvin, =20 WebFinger does discovery on any URI. It might be =93http=94, = =93mailto=94, =93ftp=94, or =93acct=94. So, it=92s not entirely correct to say that WebFinger = does not do discovery using email addresses. I could change my server code pretty easily to accommodate mailto. =20 Use of mailto was something discussed at length. As others pointed out, = it was not necessarily favored by all, but it was recognized to be = insufficient for some situations. Most importantly, nobody other than us geeks knows what the heck a =93mailto=94 is. But, we do recognize that social sites = like Twitter have accounts. Thus, after the lengthy debate that took place = in several places, it was decided to go with =93acct=94. It actually does = have a useful purpose. And its construction is made to look similar to = =93mailto=94 so that the a user would just enter what they consider to be an =93email=94 address, including things we know are not like user@twitter.com. Using =93mailto=94 is technically incorrect, but users never have to know or = care about that. Behind the scenes, we use =93acct=94. I would personally = never show an end user =93acct:paulej@packetizer.com =94. Rather, I would just tell = people that their account ID is =93paulej@packetizer.com=94. That may or may = not be their address. Query a Twitter account and it might return an email = address that differs (if Twitter were to share that info). =20 Paul =20 From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]=20 Sent: Wednesday, April 18, 2012 6:05 AM To: Paul E. Jones Cc: Mike Jones; Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD) =20 =20 On 18 April 2012 01:59, Paul E. Jones wrote: Melvin, =20 On =93acct:=94=85 =20 Humans will usually interchange an acct URI and mailto URI, probably = never using either scheme directly in practice. That=92s natural and = expected, if not desired. The intent is that we define something that looks like an email ID, but it=92s not an email ID. Some services, perhaps Twitter = being most notable, do no use email addresses. Yet, you might have an account there. So, user@twitter.com might be used by humans and automated = systems would convert that to acct:user@twitter.com = . It would not be appropriate to use mailto: since it=92s not an email = ID. =20 We did have a lot of debate about the use of =93acct=94. If you query = my WebFinger server, you=92ll see that it will work without =93acct:=94 = prefixed, as that was a suggestion made a year or so ago. It will inspect the input = and if it looks like an acct URI, it will assume it is. The =93acct=94 URI = will be returned as an alias. However, we should always use some kind of URI = scheme to remove the guesswork. The client can often make a very good guess as = to whether it=92s looking for a user account or something else. So, let it = tell the server what it is looking for explicitly. =20 We need a URI scheme, because WebFinger can be used to discover all = kinds of information related to a given domain, not only user information. It = can be used to query information about any URI, be that a web page, a user = account, device on the network, etc. If we got rid of =93acct=94, then we would = have a system where we sometimes use a URI scheme and sometimes we do not. = Results might be inconsistent, as the server may not make the right guess, = unless we agreed that absence of a scheme defaults to =93acct:=94. However, I see = no reason for the client to be so lazy to not include =93acct:=94. The = user might (and probably will) exclude it, but the client code can add it. =20 At this point, I=92d argue the =93train has left the station=94 on = =93acct=94, too. The current WebFinger spec exists (in part) to formally document that = which has adopted; it=92s not a new thing. Paul, thank you for your explanation on lookup based on acct: = (WebFinger) vs lookup based on mailto: (SWD). I think this is a major difference. The original WebFinger proposal was *supposed* to give extra information about an email address. >From wikipedia: "WebFinger is an Internet protocol that aims to provide information = about people by their E-mail addresses." >From webfinger.org: "Put your email address into the box above, click the button" >From google code (the top hit on google): "making email addresses readable again" And perhaps most importantly from the spec, the first example: "Assume you receive an email from Bob..." However only SWD here is doing email based discovery (mailto:). = WebFinger *now* doing acct: based discovery, which is a departure from the = original use case. =20 Im glad that some people have voiced support for acct:, but I still = believe that to be a minority. I agree, that the new acct: scheme should for in another document, rather than shoe horned into an email based discovery system. =20 IMHO, it's better to solve one problem (ie email based discovery) simply = and well, than to half solve two problems (ie a new uri scheme for identity) = in a single attempt. =20 =20 =20 Paul =20 A couple of points: 1. JSON =3D=3D=3D=3D=3D=3D=3D I think at the time webfinger was created in 2009, XML was the de facto serialization, used in AJAX, SOAP and many other systems. Today I'm = hearing more and more, that both developers and publishers, want to work with = JSON, rather than, having to support both xml and json. Content negotiation = also confuses some publishers. In my view, this is a great simplification = that webfinger can learn from SWD. 2. acct: scheme =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The acct: URI scheme has not proved popular, imho, and has added a layer = of complexity and confusion. How do we get from acct: to mailto:? When = should you use acct: and when mailto: (the spec says acct:user@host may be different from mailto:user@host). What about the forms. How about = linked data ecosystems that want to cross link identifiers, do they now have to consider both cases? =20 >From the original post introducing acct: "I don=92t expect everyone to like this idea. I wish I could say I love = it, but I am simply content with it." I dont know of anyone in the community (and correct me if this has = changed) that really loves acct:, or perhaps even likes the acct: idea. SWD has shown you can do discovery without acct: and I think that's a big plus. One final side note is that this almost becomes trivial when you can do SPARQL queries. "void" is already registered by the W3C with IANA in .well-known in order to discover SPARQL endpoints. It may be overkill = in some people's eyes, but Linked Data (which predates webfinger), = particularly newer things like JSON LD, are a lot bigger than they were in 2009. In = a few years it may become the definitive discovery mechanism anyway. =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 =E8 necessario.=20 _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss =20 _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss =20 ------=_NextPart_000_0873_01CD1E50.575A8720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bob,

 

We could do that.=A0 I changed my WF server code to return a response = for any URI scheme:

https://packetizer.com/.well-known/host-meta?resour= ce=3Dfoorbar:paulej@packetizer.com

 

It returns the canonical form (the acct: URI) as an = alias.

 

We could do as do as you suggest and return a correct response only = to URI schemes that are known.=A0 I have no objection to that, except = that I do not want users to have to know the URI scheme to use.=A0 I do = not want the average user to have to know or care that it’s a = mailto URI or an xmpp URI or whatever.=A0 Users deal with identifiers = like “paulej@packetizer.com”.=A0 That’s all they = should have to worry with.=A0 I’d rather have the WF client = convert that to a canonical form, namely acct:paulej@packetizer.com = before issuing a query.

 

I do think any WF server should respond appropriately to any URI.=A0 = However, we should remove the guesswork and I think responding to any = scheme (as my server is now doing) is not quite right.=A0 If I visit a = remote web site and want to login using OpenID, I would enter paulej@packetizer.com. =A0The = remote site needs to convert that to something.=A0 What is = that?=A0 I argue that mailto is a good assumption, but not necessarily = correct.=A0 XMPP is another good assumption, but may also be incorrect. = If we agree to a standard form (acct:) then it removes the guesswork on = the client.=A0 I like predictability and = consistency.

 

Only when a client really has a specific reason for query using a = different URI like h323:paulej@packetizer.com should it do that, IMO.=A0 = But, I agree the server should return an intelligent reply if = asked.

Paul

 

From:= = bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob = Wyman
Sent: Thursday, April 19, 2012 4:36 PM
To: = Paul E. Jones
Cc: Melvin Carvalho; Goix Laurent Walter; Apps = Discuss
Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger = vs. Simple Web Discovery (SWD)

 

 

On Thu, Apr 19, 2012 at 4:21 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Melvin,

 

We could use mailto, but mailto is for email.  That refers to = one modality of communication related to a person, but would not = represent an “account” at a domain.  Further, it would = not be applicable to services like Twitter.

 

I would make the same argument for XMPP.  It is another = communication modality for a user at a given = domain.

 

In general (though we’ve seen evidence of at least one = exception), paulej@packetizer.com should be an identifier = reserved for a specific account.  I use that for my XMPP address, = my email address, and I would use that to discover my OpenID URI with = WebFinger.  No matter what address scheme one starts with, acct:paulej@packetizer.com should return = information about my account and likely pointers (directly or = indirectly) to all of the other URIs I use.

 

The generic nature of “user@domain” is perhaps why Blaine = was arguing at one point for no scheme at all.  However, we should = use a properly formed URI since WF returns information for a URI, which = then leads us to ask “what scheme shall we use?”  Thus, = “acct:” was born.  It would be legal to query xmpp:paulej@packetizer.com.  However, that = may or may not return a result.  Presently, it does not.  I = most definitely would not expect any WebFinger server to consider every = possible scheme under the sun.

 

It would, I think, be ideal if we could expect that = any domain that provides WebFinger support would allow queries for any = protocols also supported by that domain. Thus, if a domain supports = mailto:, xmpp: or foobar: services in addition to WebFinger, it should = probably support queries for identifiers used by those services, in = addition to acct:, but for no others. In general, I think it also would = be good practice to ensure that any query for a protocol other than = acct: should return a link to an acct: = identifier.

 

 

  Use of mailto: is popular, because so many people use = email.  Funny thing is that the OpenID folks at the start were = against that, arguing that email was going to die.  They were = pretty insistent that OpenID URIs should look like https://openid.packetizer.com/paulej.  And, = one could use WF to query that, too.  But, you’ll get a 404 = on my server.  I do not want every possible identifier to return a = response.

 

IMO, “acct:” is a reasonable compromise.  It has a = meaning (an account URI), it’s communication-protocol neutral = (unlike xmpp:, sip:, h323:, mailto:, http:, etc.), and we’ve = debated this at great length for at least 2 or 3 years now.  People = agree “acct:” is not the most appreciated scheme, but = “mailto:” is not an appropriate since that assumes a = particular protocol.  Ditto for all other protocol-specific URI = schemes.

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Thursday, April 19, 2012 10:50 AM
To: Goix Laurent = Walter
Cc: Pelle Wessman; Paul E.Jones; Apps = Discuss
Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger = vs. Simple Web Discovery (SWD)

 <= /o:p>

 <= /p>

On 19 April = 2012 15:59, Goix Laurent Walter <laurentwalter.goix@telecomitalia.it> = wrote:

Possibly a standard discovery mechanism should rely on some sort of = URI and not a simple token string. URIs representing social network = accounts are missing so far and at least this type of URI should be = discoverable. Optionally I believe any type of other uri may, but with = no guarantee. It may be a matter of permissions, internal db lookups = and/or associations or else on the server to decide whether to provide a = meaningful response to it. This is somehow already clarified in section = 5 of the wf draft.


Why do you = say "URIs representing social accounts are missing so = far"?  And if so, from which systems? 

For = example, Facebook has a pretty good system for representing their = accounts as URIs (open graph protocol), as does SIOC, and people like status.net (inventor of = OStatus who have a pretty good FOAF impl.) etc.  All of these use = HTTP URIs as their machine representation, rather than any proposed = acct: scheme, for example. 

I thought this use case is = mainly relevant to the big webmail providers.

Email style = discovery is missing (apart from the specific case of a public key in = GPG), so if you want a full Web sytle solution use void (already = registered with IANA).  If void is too complex, choose something = simpler.  SWD seems a simpler solution, at this point, = technically.  WF may have the lead on adoption, I dont know.  = Perhaps something can be learnt by each system from each other ... e.g. = the JSON vs XML discussion.  Merging the best parts from both specs = could be a great idea...

As for non mailto: URI schemes, that in = itself is an interesting problem, perhaps a big topic.  To me, = xmpp: is a very interesting candidate.  Again void can be used for = this, but maybe WF/SWD is an interesting thing to deploy.  Having a = lookup for the tel: scheme would be kind of amazing ... but is a whole = problem in itself, including finding the well known location.  HTTP = discovery is really in advanced stages, with mature deployments, under = the W3C / Linked Data.  I would personally NOT encourage acct: = lookup because it's just too confusing for the average developer, = fractures identity, does not provide HTTP style 'follow your nose', and = ultimately, will probably not be a long lived identifier, given how = quickly the web identity space evolves (just my 2 cents).

I think = sweet spot here is find the path of least resistance, for a really good = discovery system for email addresses.   Other schemes *could* be a = plus depending on the context, but the most compelling and useful lookup = that is filling a gap I think, is mailto: = based.

 

walter

 <= /o:p>

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di = Pelle Wessman
Inviato: gioved=EC 19 aprile 2012 = 13.53
A: Paul E.Jones
Cc: 'Apps = Discuss'
Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. = Simple Web Discovery (SWD)

 

While WebFinger officially requires an "acct" URI I = believe almost all current implementers accept a "pelle@kodfabrik.se" URI as being the same as = "acct:pelle@kodfabrik.se". Gmail.com does, = StatusNet/Identi.ca does, we at Flattr does. So there is = a discrepancy between the WebFinger specification and real life = implementations.

 

Examples:

 

Also, speaking from a Flattr-perspective, mail addresses and = user accounts are _not_ the same thing in our system. I myself have the = e-mail pelle@flattr.com but I have the web site account = voxpelli@flattr.com and the web site account pelle@flattr.com = doesn't belong to me but to one of our users. I believe most web sites, = at least the smaller ones, works like this - that the e-mail system and = the web system is completely separated from each other and that the user = identifiers in one can conflict with the identifiers in the = other.

 

I would say that a lookup for "mailto:pelle@flattr.com" should return info = about the user behind that e-mail address (if it should return anything) = but that a lookup for "pelle@flattr.com" or "acct:pelle@flattr.com" should always return = data about the web site user and that clients should be encouraged to = use "acct:" to make it clear that they want the web site's = user, but that they shouldn't be required to do = so.

 

/ Pelle

 

 

19 apr 2012 kl. 00:03 skrev Paul E. = Jones:

 

Melvin,

 

WebFinger does discovery on any URI.  It might = be “http”, “mailto”, “ftp”, or = “acct”.  So, it’s not entirely correct to say = that WebFinger does not do discovery using email addresses.  I = could change my server code pretty easily to accommodate = mailto.

 

Use of mailto was something discussed at length.  As others = pointed out, it was not necessarily favored by all, but it was = recognized to be insufficient for some situations.  Most = importantly, nobody other than us geeks knows what the = heck a “mailto” is.  But, we do recognize that social = sites like Twitter have accounts.  Thus, after the lengthy debate = that took place in several places, it was decided to go with = “acct”.  It actually does have a useful purpose.  = And its construction is made to look similar to “mailto” so = that the a user would just enter what they consider to be an = “email” address, including things we know are not = like user@twitter.com.  Using “mailto” = is technically incorrect, but users never have to know or care about = that.  Behind the scenes, we use “acct”.  I would = personally never show an end user “acct:paulej@packetizer.com”.  Rather, I = would just tell people that their account ID is “paulej@packetizer.com”.  That may or = may not be their address.  Query a Twitter account and it might = return an email address that differs (if Twitter were to share that = info).

 

Paul

 

From:=  Melvin= Carvalho [mailto:melvincarvalho@gmail.com] 
Sent:&nbs= p;Wednesday, April 18, 2012 6:05 AM
To: Paul E. = Jones
Cc: Mike Jones; Apps = Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger = vs. Simple Web Discovery = (SWD)

 <= /o:p>

 <= /p>

On 18 April = 2012 01:59, Paul E. Jones <paulej@packetizer.com> = wrote:

Melvin,

 

On “acct:”…

 

Humans will usually interchange an acct URI and mailto URI, probably = never using either scheme directly in practice.  That’s = natural and expected, if not desired.  The intent is that we define = something that looks like an email ID, but it’s not an email = ID.  Some services, perhaps Twitter being most notable, do no use = email addresses.  Yet, you might have an account there.  = So, user@twitter.com might be used by humans and = automated systems would convert that to acct:user@twitter.com.  It would not be = appropriate to use mailto: since it’s not an email = ID.

 

We did have a lot of debate about the use of = “acct”.  If you query my WebFinger server, you’ll = see that it will work without “acct:” prefixed, as that was = a suggestion made a year or so ago.  It will inspect the input and = if it looks like an acct URI, it will assume it is.  The = “acct” URI will be returned as an alias.  However, we = should always use some kind of URI scheme to remove the guesswork.  = The client can often make a very good guess as to whether it’s = looking for a user account or something else.  So, let it tell the = server what it is looking for = explicitly.

 

We need a URI scheme, because WebFinger can be used to discover all = kinds of information related to a given domain, not only user = information.  It can be used to query information about any URI, be = that a web page, a user account, device on the network, etc.  If we = got rid of “acct”, then we would have a system where we = sometimes use a URI scheme and sometimes we do not.  Results might = be inconsistent, as the server may not make the right guess, unless we = agreed that absence of a scheme defaults to “acct:”.  = However, I see no reason for the client to be so lazy to not include = “acct:”.  The user might (and probably will) exclude = it, but the client code can add it.

 

At this point, I’d argue the “train has left the = station” on “acct”, too.  The current WebFinger = spec exists (in part) to formally document that which has adopted; = it’s not a new = thing.



Paul= , thank you for your explanation on lookup based on acct: (WebFinger) vs = lookup based on mailto: (SWD).

I think this is a major = difference.

The original WebFinger proposal was *supposed* to = give extra information about an email address.

From = wikipedia:

"WebFinger is an = Internet protocol that aims to provide information about people by = their E-mail addresses."

From webfinger.org:

"Put your email = address into the box above, click the = button"

From google code (the top hit on = google):

"making email = addresses readable again"

And perhaps most = importantly from the spec, the first example:

"Assume you receive = an email from Bob..."

However only = SWD here is doing email based discovery (mailto:).  WebFinger *now* doing acct: based = discovery, which is a departure from the original use = case.  

Im glad that some people have voiced support = for acct:, but I still believe that to be a minority.  I agree, = that the new acct: scheme should for in another document, rather than = shoe horned into an email based discovery = system.  

IMHO, it's better to solve one problem (ie = email based discovery) simply and well, than to half solve two problems = (ie a new uri scheme for identity) in a single = attempt.  
 

 

Paul

 

A couple of = points:

1. JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the = time webfinger was created in 2009, XML was the de facto serialization, = used in AJAX, SOAP and many other systems.  Today I'm hearing more = and more, that both developers and publishers, want to work with JSON, = rather than, having to support both xml and json.  Content = negotiation also confuses some publishers.  In my view, this is a = great simplification that webfinger can learn from SWD.

2. acct: = scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The acct: URI = scheme has not proved popular, imho, and has added a layer of complexity = and confusion.  How do we get from acct: to mailto:?  When = should you use acct: and when mailto: (the spec says acct:user@host may = be different from mailto:user@host).  What about the forms.  How = about linked data ecosystems that want to cross link identifiers, do = they now have to consider both cases?  

From the = original post introducing acct:

"I don’t expect = everyone to like this idea. I wish I could say I love it, but I am = simply content with it."

I dont know of anyone in the = community (and correct me if this has changed) that really loves acct:, = or perhaps even likes the acct: idea.  SWD has shown you can do = discovery without acct: and I think that's a big = plus.




One final side note is that this almost becomes = trivial when you can do SPARQL queries.  "void" is = already registered by the W3C with IANA in .well-known in order to = discover SPARQL endpoints.  It may be overkill in some people's = eyes, but Linked Data (which predates webfinger), particularly newer = things like JSON LD, are a lot bigger than they were in 2009.  In a = few years it may become the definitive discovery mechanism = anyway.

 <= /o:p>

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

 

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


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

 <= /o:p>


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

 

------=_NextPart_000_0873_01CD1E50.575A8720-- From melvincarvalho@gmail.com Thu Apr 19 14: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 EE83D11E8076 for ; Thu, 19 Apr 2012 14:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy08t-YtFqnB for ; Thu, 19 Apr 2012 14:21:58 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E26D11E8089 for ; Thu, 19 Apr 2012 14:21:57 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2438199vcb.31 for ; Thu, 19 Apr 2012 14:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HXERJT1g/fIe9ekuALoPId1MZXm1lxltpwfiA3mWgr4=; b=SGmd0oXKe5HN+OZsnkDddyVGL6RFuDoY2a+NZEy5JdnXGxch5paHy9VCr6tLY7z80L O/jerB3VmgE9ryJG8C9FHuvXpyjju70almykMVpHCJvOJkv++m4ip3o9eEzPPCJ2W5SJ xbu5cgK6j7VdIf23Uq0h9m1Wl1MH/nijUMPge6Q5k3mjIHe+yfJRUx3lD+9z9SfOrjo/ 7mq5NuOu/MpxVN86DjoG7/CCbqLGS0EMrVnFQleuhY0VQDx6amBqHsSjdtsSipZ5gygL yIw4TYgABRdL3YiHSiQlw7FDK6l6wAy86JTl8g07abBh2OdcLvWrFDFOS6KxhLUbek8H dUeQ== MIME-Version: 1.0 Received: by 10.220.57.205 with SMTP id d13mr1948919vch.53.1334870517527; Thu, 19 Apr 2012 14:21:57 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Thu, 19 Apr 2012 14:21:57 -0700 (PDT) In-Reply-To: <4F908097.9030101@stpeter.im> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FF1C6A@P3PWEX2MB008.ex2.secureserver.net> <4F908097.9030101@stpeter.im> Date: Thu, 19 Apr 2012 23:21:57 +0200 Message-ID: From: Melvin Carvalho To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=00235445b92204b56604be0ec37c Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 21:21:59 -0000 --00235445b92204b56604be0ec37c Content-Type: text/plain; charset=ISO-8859-1 On 19 April 2012 23:16, Peter Saint-Andre wrote: > [removing oauth@ietf.org] > > On 4/19/12 3:12 PM, Melvin Carvalho wrote: > > > It could be a URN eg > > > > urn:acct:user@host (no new uri scheme needed) > > No new URI scheme needed, but you'd need a new URN Namespace Identifier. > Six of one, half a dozen of the other. > Totally agree with you. Tho part of standardization is deciding when something is more like a name e.g. isbn / uuid or when something should be a protocol e.g. xmpp / http ... > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > --00235445b92204b56604be0ec37c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 19 April 2012 23:16, Peter Saint-Andr= e <stpeter@stpet= er.im> wrote:
[removing oauth@ietf.org]

On 4/19/12 3:12 PM, Melvin Carvalho wrote:

> It could be a URN eg
>
> urn:acct:user@host =A0(no new uri scheme needed)

No new URI scheme needed, but you'd need a new URN Namespace Iden= tifier.
Six of one, half a dozen of the other.

Totally agr= ee with you.=A0 Tho part of standardization is deciding when something is m= ore like a name e.g. isbn / uuid or when something should be a protocol e.g= . xmpp / http ...
=A0

Peter

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


--00235445b92204b56604be0ec37c-- From hartmans@mit.edu Thu Apr 19 16:29: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 0033121E801A; Thu, 19 Apr 2012 16:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.171 X-Spam-Level: X-Spam-Status: No, score=-103.171 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eXjOAzEtvSa; Thu, 19 Apr 2012 16:29:47 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7147F21E8019; Thu, 19 Apr 2012 16:29:47 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 116322053A; Thu, 19 Apr 2012 19:25:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 933B54765; Thu, 19 Apr 2012 19:29:44 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> <1334695329.43020.YahooMailNeo@web31812.mail.mud.yahoo.com> <1334712238.64475.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Thu, 19 Apr 2012 19:29:44 -0400 In-Reply-To: (Nico Williams's message of "Thu, 19 Apr 2012 11:53:51 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2012 23:29:48 -0000 >>>>> "Nico" == Nico Williams writes: Nico> Indeed, but criticality is still an existing feature of Nico> mechanisms. Nico> Obviously a critical element in a ticket or certificate or Nico> whatever still needs to be handled correctly, even if the API Nico> has no way to indicate it (although we can indicate so much Nico> via just the name of the attribute...). That's obvious Nico> enough. The implication is that any policy mapping such an Nico> element to a name attribute has to exist and be sufficient to Nico> satisfy the criticality of the mechanism element. I think the question of how acceptors handle critical elements is open and has never been discussed. Thus is inappropriate to discuss at this point for this document. I'd guess you'd want some API that indicated before accept_sec_context time what critical elements you as an acceptor handle. Or absent such an API do it through policy, but that seems kind of dreadful. I think the question of how to flag an element as critical in a name attribute is dependent on the mechanism--that is documents like draft-ietf-abfab-gss-eap-naming for mechanisms that have critical attributes need to cover that. I.E. that question would be covered in a document describing how Kerberos uses name attributes. I think local policy is a singularly bad place to make that distinction, although I agree we could do that. From msk@cloudmark.com Thu Apr 19 16:45:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C6011E80B8 for ; Thu, 19 Apr 2012 16:45:28 -0700 (PDT) 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=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFo+6aep63bo for ; Thu, 19 Apr 2012 16:45:26 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id A819E11E8073 for ; Thu, 19 Apr 2012 16:45:20 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id zzlY1i0010as01C01zlYq1; Thu, 19 Apr 2012 16:45:38 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=8Ubwy9MkvaUA:10 a=qZODYEWQ6tEA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=BIjOymf5Ok5HHdBGvR8A:9 a=oV2dLa9RXYXS-As4fx4A:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=ttoJ-aqiUlQf1udg:21 a=oHdmo-jlQlrfHaJv:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 16:45:13 -0700 From: "Murray S. Kucherawy" To: S Moonesamy , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] APPSDIR review of draft-kucherawy-marf-source-ports-01 Thread-Index: AQHNHnGo3y/JM+gioU2w2dPJsskiY5aizWlw Date: Thu, 19 Apr 2012 23:45:13 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FB707@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120419130040.0b4ee328@elandnews.com> In-Reply-To: <6.2.5.6.2.20120419130040.0b4ee328@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334879138; bh=KHVWObgYxzM7l4Ml596mRzEO8ic7ARdPPdbrumaMwhw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=KnxJ+k0FaEvx3CJZVpG2QNybc/5e7/lkrfUnw3kDeorxwOwz20uzVHrViOkGzIr1h ZHt2mQR9fMRBWU0SK4RHTmU2P3P4tJoIThZV8SlVfbNiVs1ZTGRZzDMsxhwU6Vtlh9 /pSMgLnRqEd//UdyCQEI6EF1WytrMP4+8UVTo8G8= Cc: "draft-kucherawy-marf-source-ports.all@tools.ietf.org" , "marf@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-kucherawy-marf-source-ports-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, 19 Apr 2012 23:45:28 -0000 Hi SM, thanks for the review! > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of S Moonesamy > Sent: Thursday, April 19, 2012 2:15 PM > To: apps-discuss@ietf.org > Cc: draft-kucherawy-marf-source-ports.all@tools.ietf.org; marf@ietf.org > Subject: [apps-discuss] APPSDIR review of draft-kucherawy-marf-source- > ports-01 >=20 > Minor issues: >=20 > In Section 3: >=20 > "A new ARF reporting field called "Source-Port" is defined. When > present in a report, it MUST contain the TCP or UDP source port > matching the "Source-IP" field in the same report, thereby describing > completely the origin of the abuse incident." >=20 > UDP is not used for SMTP. It's easier just to remove "TCP or UDP". You're right about UDP. I'd prefer to leave TCP in, however. > "When any report is generated that includes the "Source-IP" reporting > field, this field SHOULD also be present." >=20 > It's difficult to tell when not to do the above. I suggest replacing > SHOULD with RECOMMENDED: >=20 > it is RECOMMENDED to add this header field. I think these are semantically the same. We're still left with the questio= n, "When would you not?" The answer is "When you don't have it," I suppose= . I'll reword accordingly. > In the Security Considerations section, I suggest referring to RFC 6302. Good idea; done. > Nits: >=20 > In the Abstract: >=20 > "This document registers an additional header field for use in Abuse > Reporting Format reports to permit the identification of the source > port of the connection involved in an abuse incident." >=20 > The sentence describes a registration and what the header field does. > I suggest breaking the sentence into two parts or keeping it easy: >=20 > This document defines an additional header field for use in Abuse > Reporting Format reports to permit the identification of the source > port of the connection involved in an abuse incident. Done. > In the Introduction Section: >=20 > "[ARF] defined the Abuse Reporting Format, a new header message format > for use in reporting incidents of email abuse." >=20 > I suggest removing "new" as it won't be new in a year or two. "header > message format" is confusing. I'll suggest: >=20 > [ARF] defined the Abuse Reporting Format, an extensible format for > Email Feedback Reports. These reports are used used to report incide= nts > of email abuse. [ARF] was extended by ... Done. > "Although those specifications gave the capability to include > the source IP address in the report, the source port was not > included >=20 > I suggest: >=20 > These specifications provided for the source IP address to be included > in a report. As explained in [LOG], the deployment of IP address > sharing techniques requires the source port values to be included in > reports if unambiguous identification of the origin of abuse is to be > achieved. OK. > "Accordingly, this memo registers an ARF reporting field to contain > this information and provides guidance for its use." >=20 > I suggest: >=20 > This document defines ARF reporting field to specify the source > port. >=20 > I don't see much guidance in the draft. There's some in the next version, based on yours and other feedback. :-) > The reference to I-D.IETF-MARF-AUTHFAILURE-REPORT should be updated to > RFC 5691. Already done in my copy, but yes. > In Section 3: >=20 > 'A new ARF reporting field called "Source-Port" is defined.' >=20 > That should be header field (see Section 3.2 of RFC 5965). I gather > that the intent is to make this an optional header field. I suggest > specifying that Section 3.2 is being updated. That should also be done > for Section 3.1 of RFC 6591. I haven't seen specific section call-outs done in an updating document befo= re, only the "Updates" stuff on the title page. Is this necessary? > In Section 4: >=20 > "Description: TCP or UDP source port from which the reported > connection originated" >=20 > I suggest removing "TCP or UDP". Removed "or UDP". Thanks again, -MSK From hartmans@mit.edu Thu Apr 19 17:19: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 C6E3911E80DC; Thu, 19 Apr 2012 17:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.106 X-Spam-Level: X-Spam-Status: No, score=-103.106 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUO8kwKgwY8w; Thu, 19 Apr 2012 17:19:38 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 016D311E8073; Thu, 19 Apr 2012 17:19:37 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E3DFF2039B; Thu, 19 Apr 2012 20:15:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 297E84765; Thu, 19 Apr 2012 20:19:36 -0400 (EDT) From: Sam Hartman To: Sam Hartman References: <1334693777.42870.YahooMailNeo@web31813.mail.mud.yahoo.com> <1334694322.78096.YahooMailNeo@web31809.mail.mud.yahoo.com> <1334695329.43020.YahooMailNeo@web31812.mail.mud.yahoo.com> <1334712238.64475.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Thu, 19 Apr 2012 20:19:36 -0400 In-Reply-To: (Sam Hartman's message of "Thu, 19 Apr 2012 19:29:44 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "draft-ietf-kitten-gssapi-naming-exts.all@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 00:19:43 -0000 Spoke to Nico on the phone. I'm basically happy with his style of text if rather than policy we say policy and code. From sm@elandsys.com Thu Apr 19 17:55: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 F070C11E80A1; Thu, 19 Apr 2012 17:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfpGhDhQ4dej; Thu, 19 Apr 2012 17:55:11 -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 DD14F11E8073; Thu, 19 Apr 2012 17:55:11 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.193]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3K0somD027173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Apr 2012 17:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334883305; i=@elandsys.com; bh=MBjGV4DN9h3WYRMPscMfJ/JhI+2AhMLqBJkBra6Ik7Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1ua+mcEnwvnWSic1exVQe+x8t+Ay97VsFhAOgpNmpbBDBMnfICSI1lGoCW8J/PjfA D1Bs6pWLdnp36xH3mEnwrvf+zlOrZ9mxVWVpAVMpbpQ5qFrsWfBzYxBU1odkh7zHDI ROraOm8PrYosVWmLmdjlTErArjIkLP8CUWuv6eIg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334883305; i=@elandsys.com; bh=MBjGV4DN9h3WYRMPscMfJ/JhI+2AhMLqBJkBra6Ik7Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qCDBmk5FX+irUDI3kJP+2iXovLNOHEO/xYYnhJtmigA/HWQGtsbUWY34FjyHI1ri5 GS3827Fvp8wur75uHJDxNkKIHZ8PnZbKhDAlEwbj+/IAXVf5r3GqaXBWuhGGIcTkJM Jv1NHsgK7bgNsOuxg7o2Tyn51Bh/C4lf7ryp69dg= Message-Id: <6.2.5.6.2.20120419171013.09a89ba0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Apr 2012 17:54:03 -0700 To: "Murray S. Kucherawy" , apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <9452079D1A51524AA5749AD23E0039280FB707@exch-mbx901.corp.cl oudmark.com> References: <6.2.5.6.2.20120419130040.0b4ee328@elandnews.com> <9452079D1A51524AA5749AD23E0039280FB707@exch-mbx901.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-kucherawy-marf-source-ports.all@tools.ietf.org, marf@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-kucherawy-marf-source-ports-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: Fri, 20 Apr 2012 00:55:13 -0000 Hi Murray, At 16:45 19-04-2012, Murray S. Kucherawy wrote: >Hi SM, thanks for the review! It took 74 minutes, including distractions. :-) >You're right about UDP. I'd prefer to leave TCP in, however. Ok. >I think these are semantically the same. We're still left with the >question, "When would you not?" The answer is "When you don't have >it," I suppose. I'll reword accordingly. I used RECOMMENDED to be in line with RFC 6302. I could not come up with suggested text for that "SHOULD" within the deadline. >There's some in the next version, based on yours and other feedback. :-) I'll do a follow-up if the draft goes to Last Call. BTW, you don't need an update in the Abstract ( -02). >I haven't seen specific section call-outs done in an updating >document before, only the "Updates" stuff on the title page. Is >this necessary? No, as I classified it under nits. This document may be folded in the RFCs it updates at some point. It's easier if it inherits the requirements in those documents. If I am implementing the specifications, it is easier to read and understand. From an IETF perspective, you don't have to worry about all that. BTW, I didn't get into the RFC 6302 angle altogether. Section 13.3 of RFC 6269 discusses about spam in the context of IP address sharing. The issues around IP address sharing are due to the deployment of CGNs. Regards, S. Moonesamy From yaojk@cnnic.cn Thu Apr 19 19: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 6BCBA21F8675 for ; Thu, 19 Apr 2012 19:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.102 X-Spam-Level: X-Spam-Status: No, score=-100.102 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm62buR1h62t for ; Thu, 19 Apr 2012 19:03:57 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id C632F21F866A for ; Thu, 19 Apr 2012 19:03:55 -0700 (PDT) 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; Fri, 20 Apr 2012 10:03:49 +0800 Message-ID: From: "Jiankang YAO" To: , , , Date: Fri, 20 Apr 2012 10:03:48 +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 Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-claise-export-application-info-in-ipfix-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: Fri, 20 Apr 2012 02:03:57 -0000 SSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIEFwcGxpY2F0aW9ucyBBcmVhIERpcmVjdG9yYXRl IHJldmlld2VyIA0KZm9yIHRoaXMgZHJhZnQgKGZvciBiYWNrZ3JvdW5kIG9uIEFwcHNEaXIsIHBs ZWFzZSBzZWUgDQpodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL2FwcC90cmFjL3dpa2kv QXBwbGljYXRpb25zQXJlYURpcmVjdG9yYXRlICkuDQoNClBsZWFzZSByZXNvbHZlIHRoZXNlIGNv bW1lbnRzIGFsb25nIHdpdGggYW55IG90aGVyIExhc3QgQ2FsbCBjb21tZW50cyANCnlvdSBtYXkg cmVjZWl2ZS4gUGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgDQpz aGVwaGVyZCBvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4N Cg0KRG9jdW1lbnQ6IGRyYWZ0LWNsYWlzZS1leHBvcnQtYXBwbGljYXRpb24taW5mby1pbi1pcGZp eC0wNQ0KVGl0bGU6IEV4cG9ydCBvZiBBcHBsaWNhdGlvbiBJbmZvcm1hdGlvbiBpbiBJUEZJWA0K UmV2aWV3ZXI6IEppYW5rYW5nIFlhbw0KUmV2aWV3IERhdGU6IEFwcmlsIDIwLCAyMDEyDQoNClN1 bW1hcnk6ICBUaGlzIGRvY3VtZW50IGlzIGFsbW9zdCByZWFkeSBmb3IgcHVibGljYXRpb24gYXMg YSBJbmZvcm1hdGlvbmFsIFJGQy4NCg0KVGhpcyBkcmFmdCBzcGVjaWZpZXMgYW4gZXh0ZW5zaW9u IHRvIHRoZSBJUEZJWCBpbmZvcm1hdGlvbiBtb2RlbCBzcGVjaWZpZWQgaW4gW1JGQzUxMDJdIHRv IGV4cG9ydCBhcHBsaWNhdGlvbg0KIGluZm9ybWF0aW9uLg0KDQpNaW5vciBpc3N1ZToNCg0KSW4g U2VjdGlvbiA2Og0KDQogICAgICAgICAgNi4gQXBwbGljYXRpb24gSWQgRXhhbXBsZXMuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMjENCiAgICAgICAgICAgNi4xLiBFeGFtcGxlIDE6 IExheWVyIDIgUHJvdG9jb2wuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMjENCiAgICAgICAgICAg Ni4yLiBFeGFtcGxlIDI6IFN0YW5kYXJkaXplZCBJQU5BIExheWVyIDMgUHJvdG9jb2wuLi4uLi4g MjINCiAgICAgICAgICAgNi4zLiBFeGFtcGxlIDM6IFByb3ByaWV0YXJ5IExheWVyIDMgUHJvdG9j b2wuLi4uLi4uLi4uLi4gMjMNCiAgICAgICAgICAgNi40LiBFeGFtcGxlIDQ6IFN0YW5kYXJkaXpl ZCBJQU5BIExheWVyIDQgUG9ydC4uLi4uLi4uLi4gMjUNCiAgICAgICAgICAgNi41LiBFeGFtcGxl IDQ6IExheWVyIDcgQXBwbGljYXRpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMjYNCiAgICAgICAg ICAgNi42LiBFeGFtcGxlOiBwb3J0IE9iZnVzY2F0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4gMjgNCiAgICAgICAgICAgNi43LiBFeGFtcGxlOiBBcHBsaWNhdGlvbiBNYXBwaW5nIE9wdGlv bnMgVGVtcGxhdGUuLi4uLi4gMjkNCiAgICAgICAgICAgNi44LiBFeGFtcGxlOiBBdHRyaWJ1dGVz IFZhbHVlcyBPcHRpb25zIFRlbXBsYXRlIFJlY29yZC4gMzANCg0KDQpDb21tZW50cyA6IFRoaXMg c2VjdGlvbiBpcyBhbGwgYWJvdXQgZXhhbXBsZXMsIGNvdmVyaW5nIDEwIHBhZ2VzLiBJIHN1Z2dl c3QgdG8gbW92ZSBpdCB0byB0aGUgYXBwZW5kaXggb2YgdGhpcyBkb2N1bWVudCBzaW5jZSBpdCBk b2VzIG5vdCBzcGVjaWZ5IGFueXRoaW5nLg0KDQoNCg0KRGlzY3Vzc2lvbiBpc3N1ZToNCg0KIElu IHNlY3Rpb24gMg0KICAgICAiDQogICAgICAgQXBwbGljYXRpb24gY291bGQgYmUgZGVmaW5lZCBh dCBkaWZmZXJlbnQgT1NJIGxheWVycywgZnJvbQ0KICAgICAgbGF5ZXIgMiB0byBsYXllciA3LiBG b3IgZXhhbXBsZTogTGluayBMYXllciBEaXN0cmlidXRpb24NCiAgICAgIFByb3RvY29sIChMTERQ KSBbTExEUF0gaXMgbGF5ZXIgMiBhcHBsaWNhdGlvbiwgSUNNUCBpcyBsYXllcg0KICAgICAgMyBh cHBsaWNhdGlvbiBbSUFOQS1QUk9UT10sIEhUVFAgaXMgbGF5ZXIgNCBhcHBsaWNhdGlvbg0KICAg ICAgW0lBTkEtUE9SVFNdLCBhbmQgc2t5cGUgaXMgbGF5ZXIgNy4gIg0KICAgDQpDb21tZW50czog IEZyb20gbXkgdW5kZXJzdGFuZGluZywgSFRUUCAgaXMgIGEga2luZCBvZiBsYXllciA3IGFwcGxp Y2F0aW9uIGJhc2VkIG9uIE9TSSwgYnV0IGl0IGNhbiBiZSBpZGVudGlmaWVkIGluIGxheWVyIDQu DQpJZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsIEkgc3VnZ2VzdCB0byB0dW5lIHRoZSB0 ZXh0IHRvIHRoZSBmb2xsb3dpbmc6DQoNCiAgICAiDQogICAgICAgQXBwbGljYXRpb24gY291bGQg YmUgaWRlbnRpZmllZCBhdCBkaWZmZXJlbnQgT1NJIGxheWVycywgZnJvbQ0KICAgICAgbGF5ZXIg MiB0byBsYXllciA3LiBGb3IgZXhhbXBsZTogTGluayBMYXllciBEaXN0cmlidXRpb24NCiAgICAg IFByb3RvY29sIChMTERQKSBbTExEUF0gY2FuIGJlIGlkZW50aWZpZWQgaW4gbGF5ZXIgMiwgSUNN UCBpcyBjYW4gYmUgaWRlbnRpZmllZCBpbiBsYXllciAzDQpbSUFOQS1QUk9UT10sIEhUVFAgY2Fu IGJlIGlkZW50aWZpZWQgaW4gbGF5ZXIgNCAgW0lBTkEtUE9SVFNdLCBhbmQgc2t5cGUgY2FuIGJl IGlkZW50aWZpZWQgaW4gbGF5ZXI3LiAiDQoNCkluIHRoZSByZXN0IG9mIGRvY3VtZW50LCBpdCBu ZWVkIHRvIGJlIHR1bmVkIGFjY29yZGluZ2x5IHRvby4NCiAgIA0KICANCg0KDQpOaXRzOg0KDQpT ZWN0aW9uNi41LiB0aXRsZTogIEV4YW1wbGUgNDogTGF5ZXIgNyBBcHBsaWNhdGlvbg0KDQpDaGFu Z2UgaXQgdG8gIkV4YW1wbGUgNTogTGF5ZXIgNyBBcHBsaWNhdGlvbiIgc2luY2Ugc2VjdGlvbiA2 LjQgdGl0bGUgaXMgIiBFeGFtcGxlIDQ6IFN0YW5kYXJkaXplZCBJQU5BIExheWVyIDQgUG9ydCI/ DQoNCg0KSmlhbmthbmcgWWFv From paulej@packetizer.com Thu Apr 19 20:15:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCBA11E80AA; Thu, 19 Apr 2012 20:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB5JhpJJUNTQ; Thu, 19 Apr 2012 20:15:49 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BFB7111E8091; Thu, 19 Apr 2012 20:15:49 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3K3FOei027893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Apr 2012 23:15:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334891726; bh=rqC0GCbqmjz87DbVLUdMN3El0bP0BQKOr8kpRLDxfIQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=FiLSoPbOrVLXkWG/mWfZIGkS0W21qFIyIrxyOiS3atUJHYR5/4ce2/it72pQoBQkW koS7ZfcSKVR7ZOjrurpFYZbSpEn4yAmwoZANbpbbhVWy1UgNVP7yd7ptKj53J3Nsqx DksdbXkT1/Zy/oUyU0CdV5TE/D+nz8jeQMUFoz9w= From: "Paul E. Jones" To: "'Mike Jones'" , "'Murray S. Kucherawy'" , , "'Apps Discuss'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Thu, 19 Apr 2012 23:15:45 -0400 Message-ID: <091401cd1ea3$e159be70$a40d3b50$@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: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTuV7eKz0A== Content-Language: en-us Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 03:15:50 -0000 Mike, > There are two criteria that I would consider to be essential requirements > for any resulting general-purpose discovery specification: > > 1. Being able to always discover per-user information with a single GET > (minimizing user interface latency for mobile devices, etc.) WF can do that. See: $ curl -v https://packetizer.com/.well-known/\ host-meta.json?resource=acct:paulej@packetizer.com > 2. JSON should be required and it should be the only format required > (simplicity and ease of deployment/adoption) See the above example. However, I also support XML with my server. It took me less than 10 minutes to code up both XML and JSON representations. Once the requested format is determined, the requested URI is determined, data is pulled from the database, spitting out the desired format is trivial. Note, and very important note: supporting both XML and JSON would only be a server-side requirement. The client is at liberty to use the format it prefers. I would agree that forcing a client to support both would be unacceptable, but the server? Nothing to it. > SWD already meets those requirements. If the resulting spec meets those > requirements, it doesn't matter a lot whether we call it WebFinger or > Simple Web Discovery, but I believe that the requirements discussion is > probably the most productive one to be having at this point - not the > starting point document. I believe WebFinger meets those requirements. We could debate whether XML should be supported, but I'll note (again) that it is there in RFC 6415. That document isn't all that old and, frankly, it concerns me that we would have a strong preference for format A one week and then Format B the next. We are where we are and I can see reason for asking for JSON, but no good reason to say we should not allow XML (on the server side). Paul From tbray@textuality.com Thu Apr 19 20:41: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 4786311E80E5 for ; Thu, 19 Apr 2012 20:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.144 X-Spam-Level: X-Spam-Status: No, score=-4.144 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQVaHUGuigbM for ; Thu, 19 Apr 2012 20:41:06 -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 5FBD711E80AA for ; Thu, 19 Apr 2012 20:41:06 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so8727833obb.31 for ; Thu, 19 Apr 2012 20:41:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=72b05hnVj00AJvoQL2ukZ5GlCptUCzSUggrGXybI3RU=; b=fcmcPeB7RnhWcs5ncrZ1CDiSvMtdvQJzgGfOyKvmAJ1I3TGdSiIsLyh4TfTahPj5qj 0gat5P72H28UvCvEtsdFxv1YppBWL9Fa6SHGlTP1TxHY4GQ5BXAwCG0vsMxjpv0ANn2k d7PV8ZdcSRDtMydbHAB5reSeGsVXP63K47c0mZxsqskqAX0UAb6f3EpGLMT/6BYtaEpk fVCV7nml0xk9WUXppgdN5mHNAQgCzx8yFAlIm338kEs8Uqt2gM9gYttVwE0VBhASKLQV 6dS5QfLOtV9Uvq0APU/ejVQVErzowDGCntV/mqjg6astXE+trjv6cyggeu1wzzu+vShZ poGw== MIME-Version: 1.0 Received: by 10.60.11.166 with SMTP id r6mr6437960oeb.2.1334893266007; Thu, 19 Apr 2012 20:41:06 -0700 (PDT) Received: by 10.182.29.6 with HTTP; Thu, 19 Apr 2012 20:41:05 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> Date: Thu, 19 Apr 2012 20:41:05 -0700 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkoqRnxV+O0XfFp07ciKAX2c/SXYQ2CeUKMtxO2pJwl+tWEj0MSxOovlaw7kdwF31gNG7Qk Cc: oauth@ietf.org, Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 03:41:07 -0000 No. Supporting two different on-the-wire data formats is actively harmful. Here are two pieces which explain why: - mnot, this month: http://www.mnot.net/blog/2012/04/13/json_or_xml_just_de= cide - Me, back in 2009 Pick one. -T On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones wrot= e: > Mike, > >> There are two criteria that I would consider to be essential requirement= s >> for any resulting general-purpose discovery specification: >> >> 1. =A0Being able to always discover per-user information with a single G= ET >> (minimizing user interface latency for mobile devices, etc.) > > WF can do that. =A0See: > $ curl -v https://packetizer.com/.well-known/\ > =A0 =A0 =A0 =A0 =A0host-meta.json?resource=3Dacct:paulej@packetizer.com > >> 2. =A0JSON should be required and it should be the only format required >> (simplicity and ease of deployment/adoption) > > See the above example. =A0However, I also support XML with my server. =A0= It took > me less than 10 minutes to code up both XML and JSON representations. =A0= Once > the requested format is determined, the requested URI is determined, data= is > pulled from the database, spitting out the desired format is trivial. > > Note, and very important note: supporting both XML and JSON would only be= a > server-side requirement. =A0The client is at liberty to use the format it > prefers. =A0I would agree that forcing a client to support both would be > unacceptable, but the server? =A0Nothing to it. > >> SWD already meets those requirements. =A0If the resulting spec meets tho= se >> requirements, it doesn't matter a lot whether we call it WebFinger or >> Simple Web Discovery, but I believe that the requirements discussion is >> probably the most productive one to be having at this point - not the >> starting point document. > > I believe WebFinger meets those requirements. =A0We could debate whether = XML > should be supported, but I'll note (again) that it is there in RFC 6415. > That document isn't all that old and, frankly, it concerns me that we wou= ld > have a strong preference for format A one week and then Format B the next= . > We are where we are and I can see reason for asking for JSON, but no good > reason to say we should not allow XML (on the server side). > > Paul > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From paulej@packetizer.com Thu Apr 19 22:01: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 51C6721F8441; Thu, 19 Apr 2012 22:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kid846gV3-41; Thu, 19 Apr 2012 22:01:04 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9A421F852D; Thu, 19 Apr 2012 21:43:31 -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 q3K4gl4d030202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 00:42:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334896969; bh=v0AuuV0Q5NlqXAt4TVgoXLPxImzeLDpP1syOQVU5Qt8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Hs8g8HR9CFhhbg3P+SWCBQiLSI/gRTG3s4eh7/9C7GcXYzZvIzpbD9tNBfl9Xl8n6 oSSQMkRIKpQ8SVX9p/6iIS2LCCSaypRAXSutWDbE8UNOqAAH7BP3tbknh+RCA39oMM KXS4j9aseFbTZ3j6gQA+JKerFjQ2UnmfZScI1W/M= From: "Paul E. Jones" To: "'Tim Bray'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> In-Reply-To: Date: Fri, 20 Apr 2012 00:43:08 -0400 Message-ID: <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAIw2f/NldEdewA= Content-Language: en-us Cc: oauth@ietf.org, 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 05:01:05 -0000 Tim, I do not agree that it's harmful. If I removed the WF discussion off the table, I'm still having a hard time buying into everything you said in = the blog post. I implement various web services, largely for my own use. Usually, I implement all of them in XML, JSON, plain text (attribute/value pairs), = AND JavaScript (for JSONP). For simple services, it's not hard. I do it because I sometimes have different wants/desires on the client side. = (For more complex ones, I use XML.) For your point (1): For WebFinger, the format is simple. The XRD and JRD definitions exist = and are clearly defined. I think the definitions of each are natural. It's = not hard to produce both. =20 For your point (2): That's a bias you have against XML, no two ways about it. I tend to = prefer to run XML through a sax-style parser and pull out what I want. But, = doing data binding is reasonable if one is dealing with complex data = structures. WebFinger is not so complex that it would need to be done that way, but = so what if developers did? It's their code. A lot of web services have = been written that way, so let developers choose. You conclude with "use JSON". By that logic, we should send the HTML5 = team back to the drawing board and have then re-write it in JSON. Oh, HTML = is a document format. Complex JSON isn't? I'd argue it is whatever you want = to put in it. In any case, I'm not going to object if the consensus of the group is to abandon XML entirely. I personally do not care which format(s) we use. What bothers me, though, is that we put a stake in the ground a few = years ago and people were happy until *very* recently. Now, we want to pull = it out of the ground and put in a whole new one. Engineering protocols should involve thinking far down the road. I = cannot fault anyone for having selected XML at the outset. I cannot fault = anyone for wanting to add JSON support now for something this simple to = implement on the server. However, what I call dangerous is declaring that JSON = should be the only format for the web, ignoring the significant investment web developers have in XML. The motivation for JSON? Because it works well with JavaScript, in spite of the fact that nobody would want to do an = eval on it, so it has to be parsed like any other format? What about the = next web language? Would we invent a new format for that, too? This is like throwing out a widely deploy authentication protocol and re-inventing that wheel, too. Oh yeah... that would be what was done = with OpenID Connect ;-) Seriously... is there no sense of maintaining backward compatibility and rigidly defining protocols for the long-term? Paul > -----Original Message----- > From: Tim Bray [mailto:tbray@textuality.com] > Sent: Thursday, April 19, 2012 11:41 PM > To: Paul E. Jones > Cc: Mike Jones; Murray S. Kucherawy; oauth@ietf.org; Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery > (SWD) >=20 > No. Supporting two different on-the-wire data formats is actively = harmful. > Here are two pieces which explain why: >=20 > - mnot, this month: > http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide > - Me, back in 2009 >=20 > Pick one. -T >=20 > On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones > wrote: > > Mike, > > > >> There are two criteria that I would consider to be essential > >> requirements for any resulting general-purpose discovery = specification: > >> > >> 1. =A0Being able to always discover per-user information with a = single > >> GET (minimizing user interface latency for mobile devices, etc.) > > > > WF can do that. =A0See: > > $ curl -v https://packetizer.com/.well-known/\ > > =A0 =A0 =A0 =A0 = =A0host-meta.json?resource=3Dacct:paulej@packetizer.com > > > >> 2. =A0JSON should be required and it should be the only format = required > >> (simplicity and ease of deployment/adoption) > > > > See the above example. =A0However, I also support XML with my = server. > > It took me less than 10 minutes to code up both XML and JSON > > representations. =A0Once the requested format is determined, the > > requested URI is determined, data is pulled from the database, = spitting > out the desired format is trivial. > > > > Note, and very important note: supporting both XML and JSON would = only > > be a server-side requirement. =A0The client is at liberty to use the > > format it prefers. =A0I would agree that forcing a client to support > > both would be unacceptable, but the server? =A0Nothing to it. > > > >> SWD already meets those requirements. =A0If the resulting spec = meets > >> those requirements, it doesn't matter a lot whether we call it > >> WebFinger or Simple Web Discovery, but I believe that the > >> requirements discussion is probably the most productive one to be > >> having at this point - not the starting point document. > > > > I believe WebFinger meets those requirements. =A0We could debate = whether > > XML should be supported, but I'll note (again) that it is there in = RFC > 6415. > > That document isn't all that old and, frankly, it concerns me that = we > > would have a strong preference for format A one week and then Format = B > the next. > > We are where we are and I can see reason for asking for JSON, but no > > good reason to say we should not allow XML (on the server side). > > > > Paul > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss From Michael.Jones@microsoft.com Thu Apr 19 22:09: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 BB4EC21F8704; Thu, 19 Apr 2012 22:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.854 X-Spam-Level: X-Spam-Status: No, score=-3.854 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6p22CaNFdeB; Thu, 19 Apr 2012 22:09:56 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id B13AE21F86A7; Thu, 19 Apr 2012 22:09:52 -0700 (PDT) Received: from mail124-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Apr 2012 05:09:51 +0000 Received: from mail124-ch1 (localhost [127.0.0.1]) by mail124-ch1-R.bigfish.com (Postfix) with ESMTP id AF0B82069F; Fri, 20 Apr 2012 05:09:51 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371I542M1432Nzz1202hzz1033IL8275bhz2fh2a8h668h839h944hd25h) 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 Received-SPF: pass (mail124-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=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail124-ch1 (localhost.localdomain [127.0.0.1]) by mail124-ch1 (MessageSwitch) id 1334898590187963_3162; Fri, 20 Apr 2012 05:09:50 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail124-ch1.bigfish.com (Postfix) with ESMTP id 21235100045; Fri, 20 Apr 2012 05:09:50 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Apr 2012 05:09:49 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0283.004; Fri, 20 Apr 2012 05:09:48 +0000 From: Mike Jones To: "Paul E. Jones" , "'Murray S. Kucherawy'" , "oauth@ietf.org" , 'Apps Discuss' Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHqPloXuSZ0jfOECvbryHsEgTK5ajKa7Q Date: Fri, 20 Apr 2012 05:09:48 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> In-Reply-To: <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 05:09:57 -0000 Currently, support for the "resource" parameter is optional, as per the fol= lowing (correct?): Note that support for the "resource" parameter is optional, but strongly RECOMMENDED for improved performance. If a server does not implement the "resource" parameter, then the server's host metadata processing logic remains unchanged from RFC 6415. To truly support 1, this would need to be changed to REQUIRED, correct? -- Mike -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com]=20 Sent: Thursday, April 19, 2012 8:16 PM To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) Mike, > There are two criteria that I would consider to be essential=20 > requirements for any resulting general-purpose discovery specification: >=20 > 1. Being able to always discover per-user information with a single=20 > GET (minimizing user interface latency for mobile devices, etc.) WF can do that. See: $ curl -v https://packetizer.com/.well-known/\ host-meta.json?resource=3Dacct:paulej@packetizer.com =20 > 2. JSON should be required and it should be the only format required=20 > (simplicity and ease of deployment/adoption) See the above example. However, I also support XML with my server. It too= k me less than 10 minutes to code up both XML and JSON representations. On= ce the requested format is determined, the requested URI is determined, dat= a is pulled from the database, spitting out the desired format is trivial. =20 Note, and very important note: supporting both XML and JSON would only be a= server-side requirement. The client is at liberty to use the format it pr= efers. I would agree that forcing a client to support both would be unacce= ptable, but the server? Nothing to it. =20 > SWD already meets those requirements. If the resulting spec meets=20 > those requirements, it doesn't matter a lot whether we call it=20 > WebFinger or Simple Web Discovery, but I believe that the requirements=20 > discussion is probably the most productive one to be having at this=20 > point - not the starting point document. I believe WebFinger meets those requirements. We could debate whether XML = should be supported, but I'll note (again) that it is there in RFC 6415. That document isn't all that old and, frankly, it concerns me that we would= have a strong preference for format A one week and then Format B the next. We are where we are and I can see reason for asking for JSON, but no good r= eason to say we should not allow XML (on the server side). Paul From tbray@textuality.com Thu Apr 19 22:32: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 2224621F872E for ; Thu, 19 Apr 2012 22:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.677 X-Spam-Level: X-Spam-Status: No, score=-3.677 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dhswl2OzTHv0 for ; Thu, 19 Apr 2012 22:32:42 -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 D2D4F21F872B for ; Thu, 19 Apr 2012 22:32:41 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so8838566obb.31 for ; Thu, 19 Apr 2012 22:32:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=xrDORFyJlovEq4/YxpSX574sfol/ig0X/LVK51ConrU=; b=NvzdpPmOMg7C2tvMVk7MJOc3JrTDPXC08XZ/ObJqPr2mKUPtiVbR2yVfl/AScNi7CQ v5fw0qaRBvytatHzCFEcQlUnl784NcluadImRfywCtvnl81kMtl5JfdY/XkCtD5n22KP PkHHmO+yb9kEtZy3BsvIaXSFykr/F9T/8fca6JZUrzQ4f5TsF+AzhI18626h8kOrpzg7 gG68aZhy9SrUKAC2MR/yLtwBAXuLhT8RWBUMXkXoZsRPXSjoytAKFskLI2fd/+XZRH7n a8ayYpjiTZB3Ga5+F1gzyCMNROnog8pJ0vydqF8Y06SLeYsS2raG72CwJ/0/WmtxWilK 1pGQ== MIME-Version: 1.0 Received: by 10.182.225.2 with SMTP id rg2mr6859692obc.2.1334899961439; Thu, 19 Apr 2012 22:32:41 -0700 (PDT) Received: by 10.182.29.6 with HTTP; Thu, 19 Apr 2012 22:32:41 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> Date: Thu, 19 Apr 2012 22:32:41 -0700 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: ALoCoQnL55Itd/YmbBB2jIvJNDNOKbCQ57r9LVLEcuivg1G8wFiIKseVB4nRs0cPaNwhBjQ3pAml Cc: oauth@ietf.org, Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 05:32:43 -0000 Oops, looks like I left off the link to my own remarks about XML&JSON: http://goo.gl/v7Pjr - but they say the same thing, more or less, that MNot did. Your characterizing me as an enemy of XML is amusing, given that my name appears at the top of this document: http://goo.gl/lBjkl The points 1 & 2 you=92re reacting to are from someone else. But we agree that the choice of formats isn=92t crucial. Where we disagree is that we should pick just one, not multiple ones. -T On Thu, Apr 19, 2012 at 9:43 PM, Paul E. Jones wrot= e: > Tim, > > I do not agree that it's harmful. If I removed the WF discussion off the > table, I'm still having a hard time buying into everything you said in th= e > blog post. > > I implement various web services, largely for my own use. =A0Usually, I > implement all of them in XML, JSON, plain text (attribute/value pairs), A= ND > JavaScript (for JSONP). =A0For simple services, it's not hard. =A0I do it > because I sometimes have different wants/desires on the client side. =A0(= For > more complex ones, I use XML.) > > For your point (1): > For WebFinger, the format is simple. =A0The XRD and JRD definitions exist= and > are clearly defined. =A0I think the definitions of each are natural. =A0I= t's not > hard to produce both. > > For your point (2): > That's a bias you have against XML, no two ways about it. =A0I tend to pr= efer > to run XML through a sax-style parser and pull out what I want. =A0But, d= oing > data binding is reasonable if one is dealing with complex data structures= . > WebFinger is not so complex that it would need to be done that way, but s= o > what if developers did? =A0It's their code. =A0A lot of web services have= been > written that way, so let developers choose. > > You conclude with "use JSON". =A0By that logic, we should send the HTML5 = team > back to the drawing board and have then re-write it in JSON. =A0Oh, HTML = is a > document format. =A0Complex JSON isn't? =A0I'd argue it is whatever you w= ant to > put in it. > > In any case, I'm not going to object if the consensus of the group is to > abandon XML entirely. =A0I personally do not care which format(s) we use. > What bothers me, though, is that we put a stake in the ground a few years > ago and people were happy until *very* recently. =A0Now, we want to pull = it > out of the ground and put in a whole new one. > > Engineering protocols should involve thinking far down the road. =A0I can= not > fault anyone for having selected XML at the outset. =A0I cannot fault any= one > for wanting to add JSON support now for something this simple to implemen= t > on the server. =A0However, what I call dangerous is declaring that JSON s= hould > be the only format for the web, ignoring the significant investment web > developers have in XML. =A0The motivation for JSON? =A0Because it works w= ell > with JavaScript, in spite of the fact that nobody would want to do an eva= l > on it, so it has to be parsed like any other format? =A0What about the ne= xt > web language? =A0Would we invent a new format for that, too? > > This is like throwing out a widely deploy authentication protocol and > re-inventing that wheel, too. =A0Oh yeah... that would be what was done w= ith > OpenID Connect ;-) > > Seriously... is there no sense of maintaining backward compatibility and > rigidly defining protocols for the long-term? > > Paul > >> -----Original Message----- >> From: Tim Bray [mailto:tbray@textuality.com] >> Sent: Thursday, April 19, 2012 11:41 PM >> To: Paul E. Jones >> Cc: Mike Jones; Murray S. Kucherawy; oauth@ietf.org; Apps Discuss >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discove= ry >> (SWD) >> >> No. Supporting two different on-the-wire data formats is actively harmfu= l. >> Here are two pieces which explain why: >> >> - mnot, this month: >> http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide >> - Me, back in 2009 >> >> Pick one. -T >> >> On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones >> wrote: >> > Mike, >> > >> >> There are two criteria that I would consider to be essential >> >> requirements for any resulting general-purpose discovery specificatio= n: >> >> >> >> 1. =A0Being able to always discover per-user information with a singl= e >> >> GET (minimizing user interface latency for mobile devices, etc.) >> > >> > WF can do that. =A0See: >> > $ curl -v https://packetizer.com/.well-known/\ >> > =A0 =A0 =A0 =A0 =A0host-meta.json?resource=3Dacct:paulej@packetizer.co= m >> > >> >> 2. =A0JSON should be required and it should be the only format requir= ed >> >> (simplicity and ease of deployment/adoption) >> > >> > See the above example. =A0However, I also support XML with my server. >> > It took me less than 10 minutes to code up both XML and JSON >> > representations. =A0Once the requested format is determined, the >> > requested URI is determined, data is pulled from the database, spittin= g >> out the desired format is trivial. >> > >> > Note, and very important note: supporting both XML and JSON would only >> > be a server-side requirement. =A0The client is at liberty to use the >> > format it prefers. =A0I would agree that forcing a client to support >> > both would be unacceptable, but the server? =A0Nothing to it. >> > >> >> SWD already meets those requirements. =A0If the resulting spec meets >> >> those requirements, it doesn't matter a lot whether we call it >> >> WebFinger or Simple Web Discovery, but I believe that the >> >> requirements discussion is probably the most productive one to be >> >> having at this point - not the starting point document. >> > >> > I believe WebFinger meets those requirements. =A0We could debate wheth= er >> > XML should be supported, but I'll note (again) that it is there in RFC >> 6415. >> > That document isn't all that old and, frankly, it concerns me that we >> > would have a strong preference for format A one week and then Format B >> the next. >> > We are where we are and I can see reason for asking for JSON, but no >> > good reason to say we should not allow XML (on the server side). >> > >> > Paul >> > >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss > From paulej@packetizer.com Thu Apr 19 22:38: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 B990D21F872B; Thu, 19 Apr 2012 22:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-WdaNGhxaBb; Thu, 19 Apr 2012 22:38:48 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D859F21F872A; Thu, 19 Apr 2012 22:38:47 -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 q3K5cN7P032249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 01:38:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334900303; bh=iMhXoylNK0C9bebVHnLyn8y8prDDb3947UYXYdF0tew=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Nsdi+AQNfCFkniA+m8yO9w56GJywtRLxSAUUM9gT8ZuXve6JGPjiCq+M3xh5lbT/C dmWY/SZ7V25Lq623ntZQl4/UV63+j0jydrLL/wIp729gfkfXJwYj8//Dgsj2oPY+jz fqs+FkOhPZuKyF8OWrzp3eoy5i+z0QdVIOheIc+g= From: "Paul E. Jones" To: "'Mike Jones'" , "'Murray S. Kucherawy'" , , "'Apps Discuss'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 20 Apr 2012 01:38:44 -0400 Message-ID: <091d01cd1eb7$da2c7ed0$8e857c70$@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: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAI8MBwxldDdyNA= Content-Language: en-us Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 05:38:48 -0000 That's correct. We could certainly make it mandatory, but the reason it isn't is to maintain backward compatibility with existing deployments. I think we should always think carefully when we decide to make a change that breaks backward-compatibility. This is one change that would do that. Paul > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Friday, April 20, 2012 1:10 AM > To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > Currently, support for the "resource" parameter is optional, as per the > following (correct?): > > Note that support for the "resource" parameter is optional, but > strongly RECOMMENDED for improved performance. If a server does not > implement the "resource" parameter, then the server's host metadata > processing logic remains unchanged from RFC 6415. > > To truly support 1, this would need to be changed to REQUIRED, correct? > > -- Mike > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Thursday, April 19, 2012 8:16 PM > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > Mike, > > > There are two criteria that I would consider to be essential > > requirements for any resulting general-purpose discovery specification: > > > > 1. Being able to always discover per-user information with a single > > GET (minimizing user interface latency for mobile devices, etc.) > > WF can do that. See: > $ curl -v https://packetizer.com/.well-known/\ > host-meta.json?resource=acct:paulej@packetizer.com > > > 2. JSON should be required and it should be the only format required > > (simplicity and ease of deployment/adoption) > > See the above example. However, I also support XML with my server. It > took me less than 10 minutes to code up both XML and JSON representations. > Once the requested format is determined, the requested URI is determined, > data is pulled from the database, spitting out the desired format is > trivial. > > Note, and very important note: supporting both XML and JSON would only be > a server-side requirement. The client is at liberty to use the format it > prefers. I would agree that forcing a client to support both would be > unacceptable, but the server? Nothing to it. > > > SWD already meets those requirements. If the resulting spec meets > > those requirements, it doesn't matter a lot whether we call it > > WebFinger or Simple Web Discovery, but I believe that the requirements > > discussion is probably the most productive one to be having at this > > point - not the starting point document. > > I believe WebFinger meets those requirements. We could debate whether XML > should be supported, but I'll note (again) that it is there in RFC 6415. > That document isn't all that old and, frankly, it concerns me that we > would have a strong preference for format A one week and then Format B the > next. > We are where we are and I can see reason for asking for JSON, but no good > reason to say we should not allow XML (on the server side). > > Paul > > > From paulej@packetizer.com Thu Apr 19 22:48: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 768AD21F8731; Thu, 19 Apr 2012 22:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Amm-9beAGPd; Thu, 19 Apr 2012 22:48:42 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id ACE8121F8730; Thu, 19 Apr 2012 22:48:42 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3K5mdTa032547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 01:48:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334900920; bh=fDhoFqJvC3YpUrdEfZWdn8/Mid0lQrrSJvUesZ083PQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=g/GUnMtcs0wY7SB0zKN4Y33IX9d2rSeljUMMkfQV0YVyym/apDdEUO2GPQKkBKJCO Q9L8I8JzegQN6k7EM+q5Wxysf78llfvTbzbkp4I8morGhdH8FcLpMoD5zl3ef9fqfQ S2HZtyAoC0ddAR2Zr5xShxSGDfjr4qVt5tVn/Yco= From: "Paul E. Jones" To: "'Tim Bray'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> In-Reply-To: Date: Fri, 20 Apr 2012 01:49:00 -0400 Message-ID: <092501cd1eb9$49a31520$dce93f60$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAIw2f/NAUQ5aEgCTYzvFJW0q2ug Content-Language: en-us Cc: oauth@ietf.org, 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 05:48:46 -0000 Tim, I misunderstood. I thought you authored the MNOT blog post. That stood = in quite a contrast to your work on XML. Reading that, I felt like, on a = whim, you threw the baby out with the bathwater and started down a new path, giving no regard to what exists. OK, let me reset me mind dizzy head here... What I do understand is you're suggesting for WF, we should pick one. = It there was any complexity to it, I'd agree with you. But, in all seriousness, producing both XML and JSON for WF is a trivial exercise. = Why not support both and avoid breaking what exists today? Asking servers = to add JSON would be easy enough to do. Paul > -----Original Message----- > From: Tim Bray [mailto:tbray@textuality.com] > Sent: Friday, April 20, 2012 1:33 AM > To: Paul E. Jones > Cc: Mike Jones; Murray S. Kucherawy; oauth@ietf.org; Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery > (SWD) >=20 > Oops, looks like I left off the link to my own remarks about XML&JSON: > http://goo.gl/v7Pjr - but they say the same thing, more or less, that = MNot > did. Your characterizing me as an enemy of XML is amusing, given that = my > name appears at the top of this document: http://goo.gl/lBjkl >=20 > The points 1 & 2 you=92re reacting to are from someone else. But we = agree > that the choice of formats isn=92t crucial. Where we disagree is that = we > should pick just one, not multiple ones. -T >=20 > On Thu, Apr 19, 2012 at 9:43 PM, Paul E. Jones > wrote: > > Tim, > > > > I do not agree that it's harmful. If I removed the WF discussion off > > the table, I'm still having a hard time buying into everything you > > said in the blog post. > > > > I implement various web services, largely for my own use. = =A0Usually, I > > implement all of them in XML, JSON, plain text (attribute/value > > pairs), AND JavaScript (for JSONP). =A0For simple services, it's not > > hard. =A0I do it because I sometimes have different wants/desires on = the > > client side. =A0(For more complex ones, I use XML.) > > > > For your point (1): > > For WebFinger, the format is simple. =A0The XRD and JRD definitions > > exist and are clearly defined. =A0I think the definitions of each = are > > natural. =A0It's not hard to produce both. > > > > For your point (2): > > That's a bias you have against XML, no two ways about it. =A0I tend = to > > prefer to run XML through a sax-style parser and pull out what I = want. > > But, doing data binding is reasonable if one is dealing with complex > data structures. > > WebFinger is not so complex that it would need to be done that way, > > but so what if developers did? =A0It's their code. =A0A lot of web > > services have been written that way, so let developers choose. > > > > You conclude with "use JSON". =A0By that logic, we should send the = HTML5 > > team back to the drawing board and have then re-write it in JSON. = =A0Oh, > > HTML is a document format. =A0Complex JSON isn't? =A0I'd argue it is > > whatever you want to put in it. > > > > In any case, I'm not going to object if the consensus of the group = is > > to abandon XML entirely. =A0I personally do not care which format(s) = we > use. > > What bothers me, though, is that we put a stake in the ground a few > > years ago and people were happy until *very* recently. =A0Now, we = want > > to pull it out of the ground and put in a whole new one. > > > > Engineering protocols should involve thinking far down the road. = =A0I > > cannot fault anyone for having selected XML at the outset. =A0I = cannot > > fault anyone for wanting to add JSON support now for something this > > simple to implement on the server. =A0However, what I call dangerous = is > > declaring that JSON should be the only format for the web, ignoring > > the significant investment web developers have in XML. =A0The = motivation > > for JSON? =A0Because it works well with JavaScript, in spite of the = fact > > that nobody would want to do an eval on it, so it has to be parsed > > like any other format? =A0What about the next web language? =A0Would = we > invent a new format for that, too? > > > > This is like throwing out a widely deploy authentication protocol = and > > re-inventing that wheel, too. =A0Oh yeah... that would be what was = done > > with OpenID Connect ;-) > > > > Seriously... is there no sense of maintaining backward compatibility > > and rigidly defining protocols for the long-term? > > > > Paul > > > >> -----Original Message----- > >> From: Tim Bray [mailto:tbray@textuality.com] > >> Sent: Thursday, April 19, 2012 11:41 PM > >> To: Paul E. Jones > >> Cc: Mike Jones; Murray S. Kucherawy; oauth@ietf.org; Apps Discuss > >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > >> Discovery > >> (SWD) > >> > >> No. Supporting two different on-the-wire data formats is actively > harmful. > >> Here are two pieces which explain why: > >> > >> - mnot, this month: > >> http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide > >> - Me, back in 2009 > >> > >> Pick one. -T > >> > >> On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones > >> > >> wrote: > >> > Mike, > >> > > >> >> There are two criteria that I would consider to be essential > >> >> requirements for any resulting general-purpose discovery > specification: > >> >> > >> >> 1. =A0Being able to always discover per-user information with a > >> >> single GET (minimizing user interface latency for mobile = devices, > >> >> etc.) > >> > > >> > WF can do that. =A0See: > >> > $ curl -v https://packetizer.com/.well-known/\ > >> > =A0 =A0 =A0 =A0 = =A0host-meta.json?resource=3Dacct:paulej@packetizer.com > >> > > >> >> 2. =A0JSON should be required and it should be the only format > >> >> required (simplicity and ease of deployment/adoption) > >> > > >> > See the above example. =A0However, I also support XML with my = server. > >> > It took me less than 10 minutes to code up both XML and JSON > >> > representations. =A0Once the requested format is determined, the > >> > requested URI is determined, data is pulled from the database, > >> > spitting > >> out the desired format is trivial. > >> > > >> > Note, and very important note: supporting both XML and JSON would > >> > only be a server-side requirement. =A0The client is at liberty to = use > >> > the format it prefers. =A0I would agree that forcing a client to > >> > support both would be unacceptable, but the server? =A0Nothing to = it. > >> > > >> >> SWD already meets those requirements. =A0If the resulting spec = meets > >> >> those requirements, it doesn't matter a lot whether we call it > >> >> WebFinger or Simple Web Discovery, but I believe that the > >> >> requirements discussion is probably the most productive one to = be > >> >> having at this point - not the starting point document. > >> > > >> > I believe WebFinger meets those requirements. =A0We could debate > >> > whether XML should be supported, but I'll note (again) that it is > >> > there in RFC > >> 6415. > >> > That document isn't all that old and, frankly, it concerns me = that > >> > we would have a strong preference for format A one week and then > >> > Format B > >> the next. > >> > We are where we are and I can see reason for asking for JSON, but > >> > no good reason to say we should not allow XML (on the server = side). > >> > > >> > Paul > >> > > >> > > >> > _______________________________________________ > >> > apps-discuss mailing list > >> > apps-discuss@ietf.org > >> > https://www.ietf.org/mailman/listinfo/apps-discuss > > From Michael.Jones@microsoft.com Thu Apr 19 22:48: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 D9B2221E8037; Thu, 19 Apr 2012 22:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.845 X-Spam-Level: X-Spam-Status: No, score=-3.845 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAj3L4UVjWI2; Thu, 19 Apr 2012 22:48:58 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id C21C421E8027; Thu, 19 Apr 2012 22:48:56 -0700 (PDT) Received: from mail71-am1-R.bigfish.com (10.3.201.225) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Apr 2012 05:48:55 +0000 Received: from mail71-am1 (localhost [127.0.0.1]) by mail71-am1-R.bigfish.com (Postfix) with ESMTP id BF95B1C046F; Fri, 20 Apr 2012 05:48:55 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371I542M1432Nzz1202hzz1033IL8275bhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail71-am1: 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=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail71-am1 (localhost.localdomain [127.0.0.1]) by mail71-am1 (MessageSwitch) id 1334900933255990_30730; Fri, 20 Apr 2012 05:48:53 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.237]) by mail71-am1.bigfish.com (Postfix) with ESMTP id 3A2443C00B0; Fri, 20 Apr 2012 05:48:53 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Apr 2012 05:48:52 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0283.004; Fri, 20 Apr 2012 05:48:50 +0000 From: Mike Jones To: "Paul E. Jones" , "'Murray S. Kucherawy'" , "oauth@ietf.org" , 'Apps Discuss' Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHqPloXuSZ0jfOECvbryHsEgTK5ajKa7QgAAIvQCAAAHJYA== Date: Fri, 20 Apr 2012 05:48:49 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> In-Reply-To: <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 05:48:59 -0000 To be clear, making this mandatory would break no clients. It would requir= e updating some servers, just as requiring JSON would. This seems like a f= air tradeoff when it makes an appreciable difference in user interface late= ncy in some important scenarios. If you and the other key WebFinger suppor= ters can agree to making "resource" support mandatory and requiring JSON, I= believe we may have a path forward. Cheers, -- Mike -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com]=20 Sent: Thursday, April 19, 2012 10:39 PM To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) That's correct. We could certainly make it mandatory, but the reason it is= n't is to maintain backward compatibility with existing deployments. I think we should always think carefully when we decide to make a change th= at breaks backward-compatibility. This is one change that would do that. Paul > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Friday, April 20, 2012 1:10 AM > To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web=20 > Discovery > (SWD) >=20 > Currently, support for the "resource" parameter is optional, as per=20 > the following (correct?): >=20 > Note that support for the "resource" parameter is optional, but > strongly RECOMMENDED for improved performance. If a server does not > implement the "resource" parameter, then the server's host metadata > processing logic remains unchanged from RFC 6415. >=20 > To truly support 1, this would need to be changed to REQUIRED, correct? >=20 > -- Mike >=20 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Thursday, April 19, 2012 8:16 PM > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web=20 > Discovery > (SWD) >=20 > Mike, >=20 > > There are two criteria that I would consider to be essential=20 > > requirements for any resulting general-purpose discovery specification: > > > > 1. Being able to always discover per-user information with a single=20 > > GET (minimizing user interface latency for mobile devices, etc.) >=20 > WF can do that. See: > $ curl -v https://packetizer.com/.well-known/\ > host-meta.json?resource=3Dacct:paulej@packetizer.com >=20 > > 2. JSON should be required and it should be the only format=20 > > required (simplicity and ease of deployment/adoption) >=20 > See the above example. However, I also support XML with my server. =20 > It took me less than 10 minutes to code up both XML and JSON representati= ons. > Once the requested format is determined, the requested URI is=20 > determined, data is pulled from the database, spitting out the desired=20 > format is trivial. >=20 > Note, and very important note: supporting both XML and JSON would only=20 > be a server-side requirement. The client is at liberty to use the=20 > format it prefers. I would agree that forcing a client to support=20 > both would be unacceptable, but the server? Nothing to it. >=20 > > SWD already meets those requirements. If the resulting spec meets=20 > > those requirements, it doesn't matter a lot whether we call it=20 > > WebFinger or Simple Web Discovery, but I believe that the=20 > > requirements discussion is probably the most productive one to be=20 > > having at this point - not the starting point document. >=20 > I believe WebFinger meets those requirements. We could debate whether=20 > XML should be supported, but I'll note (again) that it is there in RFC 64= 15. > That document isn't all that old and, frankly, it concerns me that we=20 > would have a strong preference for format A one week and then Format B=20 > the next. > We are where we are and I can see reason for asking for JSON, but no=20 > good reason to say we should not allow XML (on the server side). >=20 > Paul >=20 >=20 >=20 From laurentwalter.goix@telecomitalia.it Thu Apr 19 22:49: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 1C6F221E8042; Thu, 19 Apr 2012 22:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fr9VuVIIblLy; Thu, 19 Apr 2012 22:49:00 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 86B8F21E8036; Thu, 19 Apr 2012 22:48:59 -0700 (PDT) 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.245.1; Fri, 20 Apr 2012 07:48:57 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Fri, 20 Apr 2012 07:48:57 +0200 From: Goix Laurent Walter To: Tim Bray , "Paul E. Jones" Date: Fri, 20 Apr 2012 07:48:53 +0200 Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: Ac0etwcb3Q3bCrfsTWmOcjrcvQZQcQAAeLCw Message-ID: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" , Apps Discuss Subject: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 05:49:01 -0000 I also would be in favor of keeping both, for the reasons mentioned. Plus x= ml is traditionally better than json at handling extensions & namespaces th= at may appear throughout future deployments walter > -----Messaggio originale----- > Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] Per conto di Tim Bray > Inviato: venerd=EC 20 aprile 2012 7.33 > A: Paul E. Jones > Cc: oauth@ietf.org; Apps Discuss > Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > Discovery (SWD) > > Oops, looks like I left off the link to my own remarks about XML&JSON: > http://goo.gl/v7Pjr - but they say the same thing, more or less, that > MNot did. Your characterizing me as an enemy of XML is amusing, given > that my name appears at the top of this document: http://goo.gl/lBjkl > > The points 1 & 2 you're reacting to are from someone else. But we > agree that the choice of formats isn't crucial. Where we disagree is > that we should pick just one, not multiple ones. -T > > On Thu, Apr 19, 2012 at 9:43 PM, Paul E. Jones > wrote: > > Tim, > > > > I do not agree that it's harmful. If I removed the WF discussion off > the > > table, I'm still having a hard time buying into everything you said > in the > > blog post. > > > > I implement various web services, largely for my own use. Usually, I > > implement all of them in XML, JSON, plain text (attribute/value > pairs), AND > > JavaScript (for JSONP). For simple services, it's not hard. I do it > > because I sometimes have different wants/desires on the client side. > (For > > more complex ones, I use XML.) > > > > For your point (1): > > For WebFinger, the format is simple. The XRD and JRD definitions > exist and > > are clearly defined. I think the definitions of each are natural. > It's not > > hard to produce both. > > > > For your point (2): > > That's a bias you have against XML, no two ways about it. I tend to > prefer > > to run XML through a sax-style parser and pull out what I want. But, > doing > > data binding is reasonable if one is dealing with complex data > structures. > > WebFinger is not so complex that it would need to be done that way, > but so > > what if developers did? It's their code. A lot of web services have > been > > written that way, so let developers choose. > > > > You conclude with "use JSON". By that logic, we should send the > HTML5 team > > back to the drawing board and have then re-write it in JSON. Oh, > HTML is a > > document format. Complex JSON isn't? I'd argue it is whatever you > want to > > put in it. > > > > In any case, I'm not going to object if the consensus of the group is > to > > abandon XML entirely. I personally do not care which format(s) we > use. > > What bothers me, though, is that we put a stake in the ground a few > years > > ago and people were happy until *very* recently. Now, we want to > pull it > > out of the ground and put in a whole new one. > > > > Engineering protocols should involve thinking far down the road. I > cannot > > fault anyone for having selected XML at the outset. I cannot fault > anyone > > for wanting to add JSON support now for something this simple to > implement > > on the server. However, what I call dangerous is declaring that JSON > should > > be the only format for the web, ignoring the significant investment > web > > developers have in XML. The motivation for JSON? Because it works > well > > with JavaScript, in spite of the fact that nobody would want to do an > eval > > on it, so it has to be parsed like any other format? What about the > next > > web language? Would we invent a new format for that, too? > > > > This is like throwing out a widely deploy authentication protocol and > > re-inventing that wheel, too. Oh yeah... that would be what was done > with > > OpenID Connect ;-) > > > > Seriously... is there no sense of maintaining backward compatibility > and > > rigidly defining protocols for the long-term? > > > > Paul > > > >> -----Original Message----- > >> From: Tim Bray [mailto:tbray@textuality.com] > >> Sent: Thursday, April 19, 2012 11:41 PM > >> To: Paul E. Jones > >> Cc: Mike Jones; Murray S. Kucherawy; oauth@ietf.org; Apps Discuss > >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > Discovery > >> (SWD) > >> > >> No. Supporting two different on-the-wire data formats is actively > harmful. > >> Here are two pieces which explain why: > >> > >> - mnot, this month: > >> http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide > >> - Me, back in 2009 > >> > >> Pick one. -T > >> > >> On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones > > >> wrote: > >> > Mike, > >> > > >> >> There are two criteria that I would consider to be essential > >> >> requirements for any resulting general-purpose discovery > specification: > >> >> > >> >> 1. Being able to always discover per-user information with a > single > >> >> GET (minimizing user interface latency for mobile devices, etc.) > >> > > >> > WF can do that. See: > >> > $ curl -v https://packetizer.com/.well-known/\ > >> > host-meta.json?resource=3Dacct:paulej@packetizer.com > >> > > >> >> 2. JSON should be required and it should be the only format > required > >> >> (simplicity and ease of deployment/adoption) > >> > > >> > See the above example. However, I also support XML with my > server. > >> > It took me less than 10 minutes to code up both XML and JSON > >> > representations. Once the requested format is determined, the > >> > requested URI is determined, data is pulled from the database, > spitting > >> out the desired format is trivial. > >> > > >> > Note, and very important note: supporting both XML and JSON would > only > >> > be a server-side requirement. The client is at liberty to use the > >> > format it prefers. I would agree that forcing a client to support > >> > both would be unacceptable, but the server? Nothing to it. > >> > > >> >> SWD already meets those requirements. If the resulting spec > meets > >> >> those requirements, it doesn't matter a lot whether we call it > >> >> WebFinger or Simple Web Discovery, but I believe that the > >> >> requirements discussion is probably the most productive one to be > >> >> having at this point - not the starting point document. > >> > > >> > I believe WebFinger meets those requirements. We could debate > whether > >> > XML should be supported, but I'll note (again) that it is there in > RFC > >> 6415. > >> > That document isn't all that old and, frankly, it concerns me that > we > >> > would have a strong preference for format A one week and then > Format B > >> the next. > >> > We are where we are and I can see reason for asking for JSON, but > no > >> > good reason to say we should not allow XML (on the server side). > >> > > >> > 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 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 Thu Apr 19 22:55: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 6E34421F8739 for ; Thu, 19 Apr 2012 22:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubK1AIDgcw3Q for ; Thu, 19 Apr 2012 22:54:53 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE5721F8735 for ; Thu, 19 Apr 2012 22:54:52 -0700 (PDT) Content-Type: multipart/mixed; boundary="_9287f097-730c-416a-b128-f8cdcb573bf1_" 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.245.1; Fri, 20 Apr 2012 07:54:48 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Fri, 20 Apr 2012 07:54:48 +0200 From: Goix Laurent Walter To: "Paul E. Jones" , 'Bob Wyman' Date: Fri, 20 Apr 2012 07:54:45 +0200 Thread-Topic: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0B/rNJdACTlkYtAqzWkh0CKCokFwIKVUEBASLQzuwCKHMIGAI9BikIAS4MPVkBw+S5OgHyDJKolYPqmbCAAJPkcA== Message-ID: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <04fb01cd1cf6$23131c80$69395580$@packetizer.com> <069501cd1daf$20087580$60196080$@packetizer.com> <15AB1540-7555-4C02-A29A-AAE0ADA786B3@kodfabrik.se> <084401cd1e69$f8ff4250$eafdc6f0$@packetizer.com> <087201cd1e71$de687da0$9b3978e0$@packetizer.com> In-Reply-To: <087201cd1e71$de687da0$9b3978e0$@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: 'Apps Discuss' Subject: [apps-discuss] R: R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 05:55:05 -0000 --_9287f097-730c-416a-b128-f8cdcb573bf1_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE52EE1A716CGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE52EE1A716CGRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, I would be careful in returning a positive answer to *any* type of uri and = make any statement as such in the spec. I agree that from a formal perspect= ive, anyURI should be supported as parameter value, but the server shall at= least support acct:, and as bob, may answer positively to others if suppor= ted/known to that server. I would further recommends it provides back an er= ror to those URI schemes it does not understand. This actually opens the door to interesting capabilities such as per-URI-sc= heme link rel types. In other words, there may be default rel link types as= sociated to each uri scheme (hopefully without adding much complexity on th= e spec itself). This may help in discovering protocol-specific endpoints of= interest, ie the pop/imap endpoint serving the user's email address, etc l= ink rel types may be prefixed/namespaced in that case so that a query to ma= ilto: could return an additional link rel=3Dmailto:pop for example. Is this meaningful? walter Da: Paul E. Jones [mailto:paulej@packetizer.com] Inviato: gioved=EC 19 aprile 2012 23.18 A: 'Bob Wyman' Cc: 'Melvin Carvalho'; Goix Laurent Walter; 'Apps Discuss' Oggetto: RE: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discove= ry (SWD) Bob, We could do that. I changed my WF server code to return a response for any= URI scheme: https://packetizer.com/.well-known/host-meta?resource=3Dfoorbar:paulej@pack= etizer.com It returns the canonical form (the acct: URI) as an alias. We could do as do as you suggest and return a correct response only to URI = schemes that are known. I have no objection to that, except that I do not = want users to have to know the URI scheme to use. I do not want the averag= e user to have to know or care that it's a mailto URI or an xmpp URI or wha= tever. Users deal with identifiers like "paulej@packetizer.com". That's a= ll they should have to worry with. I'd rather have the WF client convert t= hat to a canonical form, namely acct:paulej@packetizer.com before issuing a= query. I do think any WF server should respond appropriately to any URI. However,= we should remove the guesswork and I think responding to any scheme (as my= server is now doing) is not quite right. If I visit a remote web site and= want to login using OpenID, I would enter paulej@packetizer.com. The remote site needs to convert that to something. = What is that? I argue that mailto is a good assumption, but not necessaril= y correct. XMPP is another good assumption, but may also be incorrect. If = we agree to a standard form (acct:) then it removes the guesswork on the cl= ient. I like predictability and consistency. Only when a client really has a specific reason for query using a different= URI like h323:paulej@packetizer.com should it do that, IMO. But, I agree = the server should return an intelligent reply if asked. Paul From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman Sent: Thursday, April 19, 2012 4:36 PM To: Paul E. Jones Cc: Melvin Carvalho; Goix Laurent Walter; Apps Discuss Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discove= ry (SWD) On Thu, Apr 19, 2012 at 4:21 PM, Paul E. Jones > wrote: Melvin, We could use mailto, but mailto is for email. That refers to one modality = of communication related to a person, but would not represent an "account" = at a domain. Further, it would not be applicable to services like Twitter. I would make the same argument for XMPP. It is another communication modal= ity for a user at a given domain. In general (though we've seen evidence of at least one exception), paulej@p= acketizer.com should be an identifier reserve= d for a specific account. I use that for my XMPP address, my email address= , and I would use that to discover my OpenID URI with WebFinger. No matter= what address scheme one starts with, acct:paulej@packetizer.com should return information about my account and l= ikely pointers (directly or indirectly) to all of the other URIs I use. The generic nature of "user@domain" is perhaps why Blaine was arguing at on= e point for no scheme at all. However, we should use a properly formed URI= since WF returns information for a URI, which then leads us to ask "what s= cheme shall we use?" Thus, "acct:" was born. It would be legal to query x= mpp:paulej@packetizer.com. However, t= hat may or may not return a result. Presently, it does not. I most defini= tely would not expect any WebFinger server to consider every possible schem= e under the sun. It would, I think, be ideal if we could expect that any domain that provide= s WebFinger support would allow queries for any protocols also supported by= that domain. Thus, if a domain supports mailto:, xmpp: or foobar: services= in addition to WebFinger, it should probably support queries for identifie= rs used by those services, in addition to acct:, but for no others. In gene= ral, I think it also would be good practice to ensure that any query for a = protocol other than acct: should return a link to an acct: identifier. Use of mailto: is popular, because so many people use email. Funny thing= is that the OpenID folks at the start were against that, arguing that emai= l was going to die. They were pretty insistent that OpenID URIs should loo= k like https://openid.packetizer.com/paulej. And, one could use WF to quer= y that, too. But, you'll get a 404 on my server. I do not want every poss= ible identifier to return a response. IMO, "acct:" is a reasonable compromise. It has a meaning (an account URI)= , it's communication-protocol neutral (unlike xmpp:, sip:, h323:, mailto:, = http:, etc.), and we've debated this at great length for at least 2 or 3 ye= ars now. People agree "acct:" is not the most appreciated scheme, but "mai= lto:" is not an appropriate since that assumes a particular protocol. Ditt= o for all other protocol-specific URI schemes. Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Thursday, April 19, 2012 10:50 AM To: Goix Laurent Walter Cc: Pelle Wessman; Paul E.Jones; Apps Discuss Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discove= ry (SWD) On 19 April 2012 15:59, Goix Laurent Walter > wrote: Possibly a standard discovery mechanism should rely on some sort of URI and= not a simple token string. URIs representing social network accounts are m= issing so far and at least this type of URI should be discoverable. Optiona= lly I believe any type of other uri may, but with no guarantee. It may be a= matter of permissions, internal db lookups and/or associations or else on = the server to decide whether to provide a meaningful response to it. This i= s somehow already clarified in section 5 of the wf draft. Why do you say "URIs representing social accounts are missing so far"? And= if so, from which systems? For example, Facebook has a pretty good system for representing their accou= nts as URIs (open graph protocol), as does SIOC, and people like status.net= (inventor of OStatus who have a pretty good FOAF impl.)= etc. All of these use HTTP URIs as their machine representation, rather t= han any proposed acct: scheme, for example. I thought this use case is mainly relevant to the big webmail providers. Email style discovery is missing (apart from the specific case of a public = key in GPG), so if you want a full Web sytle solution use void (already reg= istered with IANA). If void is too complex, choose something simpler. SWD= seems a simpler solution, at this point, technically. WF may have the lea= d on adoption, I dont know. Perhaps something can be learnt by each system= from each other ... e.g. the JSON vs XML discussion. Merging the best par= ts from both specs could be a great idea... As for non mailto: URI schemes, that in itself is an interesting problem, p= erhaps a big topic. To me, xmpp: is a very interesting candidate. Again v= oid can be used for this, but maybe WF/SWD is an interesting thing to deplo= y. Having a lookup for the tel: scheme would be kind of amazing ... but is= a whole problem in itself, including finding the well known location. HTT= P discovery is really in advanced stages, with mature deployments, under th= e W3C / Linked Data. I would personally NOT encourage acct: lookup because= it's just too confusing for the average developer, fractures identity, doe= s not provide HTTP style 'follow your nose', and ultimately, will probably = not be a long lived identifier, given how quickly the web identity space ev= olves (just my 2 cents). I think sweet spot here is find the path of least resistance, for a really = good discovery system for email addresses. Other schemes *could* be a plu= s depending on the context, but the most compelling and useful lookup that = is filling a gap I think, is mailto: based. walter Da: apps-discuss-bounces@ietf.org [ma= ilto:apps-discuss-bounces@ietf.org] P= er conto di Pelle Wessman Inviato: gioved=EC 19 aprile 2012 13.53 A: Paul E.Jones Cc: 'Apps Discuss' Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) While WebFinger officially requires an "acct" URI I believe almost all curr= ent implementers accept a "pelle@kodfabrik.se" U= RI as being the same as "acct:pelle@kodfabrik.se". Gmail.com does, StatusNet/Identi.ca does, we at= Flattr does. So there is a discrepancy between the WebFinger specification= and real life implementations. Examples: http://www.google.com/s2/webfinger/?q=3Dvoxpelli@gmail.com http://identi.ca/main/xrd?uri=3Dvoxpelli@identi.ca https://flattr.com/xrd/lrdd?uri=3Dvoxpelli@flattr.com Also, speaking from a Flattr-perspective, mail addresses and user accounts = are _not_ the same thing in our system. I myself have the e-mail pelle@flat= tr.com but I have the web site account voxpelli@fl= attr.com and the web site account pelle@flattr.= com doesn't belong to me but to one of our users. = I believe most web sites, at least the smaller ones, works like this - that= the e-mail system and the web system is completely separated from each oth= er and that the user identifiers in one can conflict with the identifiers i= n the other. I would say that a lookup for "mailto:pelle@flattr.com" should return info = about the user behind that e-mail address (if it should return anything) bu= t that a lookup for "pelle@flattr.com" or "acct:pe= lle@flattr.com" should always return data a= bout the web site user and that clients should be encouraged to use "acct:"= to make it clear that they want the web site's user, but that they shouldn= 't be required to do so. / Pelle 19 apr 2012 kl. 00:03 skrev Paul E. Jones: Melvin, WebFinger does discovery on any URI. It might be "http", "mailto", "ftp", = or "acct". So, it's not entirely correct to say that WebFinger does not do= discovery using email addresses. I could change my server code pretty eas= ily to accommodate mailto. Use of mailto was something discussed at length. As others pointed out, it= was not necessarily favored by all, but it was recognized to be insufficie= nt for some situations. Most importantly, nobody other than us geeks knows= what the heck a "mailto" is. But, we do recognize that social sites like = Twitter have accounts. Thus, after the lengthy debate that took place in s= everal places, it was decided to go with "acct". It actually does have a u= seful purpose. And its construction is made to look similar to "mailto" so= that the a user would just enter what they consider to be an "email" addre= ss, including things we know are not like user@twitter.com. Using "mailto" is technically incorrect, but users never have to= know or care about that. Behind the scenes, we use "acct". I would perso= nally never show an end user "acct:paulej@packetizer.com". Rather, I would just tell people that their account I= D is "paulej@packetizer.com". That may or ma= y not be their address. Query a Twitter account and it might return an ema= il address that differs (if Twitter were to share that info). Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Wednesday, April 18, 2012 6:05 AM To: Paul E. Jones Cc: Mike Jones; Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) On 18 April 2012 01:59, Paul E. Jones > wrote: Melvin, On "acct:"... Humans will usually interchange an acct URI and mailto URI, probably never = using either scheme directly in practice. That's natural and expected, if = not desired. The intent is that we define something that looks like an ema= il ID, but it's not an email ID. Some services, perhaps Twitter being most= notable, do no use email addresses. Yet, you might have an account there.= So, user@twitter.com might be used by humans and= automated systems would convert that to acct:user@twitter.com. It would not be appropriate to use mailto: since it's= not an email ID. We did have a lot of debate about the use of "acct". If you query my WebFi= nger server, you'll see that it will work without "acct:" prefixed, as that= was a suggestion made a year or so ago. It will inspect the input and if = it looks like an acct URI, it will assume it is. The "acct" URI will be re= turned as an alias. However, we should always use some kind of URI scheme = to remove the guesswork. The client can often make a very good guess as to= whether it's looking for a user account or something else. So, let it tel= l the server what it is looking for explicitly. We need a URI scheme, because WebFinger can be used to discover all kinds o= f information related to a given domain, not only user information. It can= be used to query information about any URI, be that a web page, a user acc= ount, device on the network, etc. If we got rid of "acct", then we would h= ave a system where we sometimes use a URI scheme and sometimes we do not. = Results might be inconsistent, as the server may not make the right guess, = unless we agreed that absence of a scheme defaults to "acct:". However, I = see no reason for the client to be so lazy to not include "acct:". The use= r might (and probably will) exclude it, but the client code can add it. At this point, I'd argue the "train has left the station" on "acct", too. = The current WebFinger spec exists (in part) to formally document that which= has adopted; it's not a new thing. Paul, thank you for your explanation on lookup based on acct: (WebFinger) v= s lookup based on mailto: (SWD). I think this is a major difference. The original WebFinger proposal was *supposed* to give extra information ab= out an email address. >From wikipedia: "WebFinger is an Internet protocol that aims to provide information about p= eople by their E-mail addresses." >From webfinger.org: "Put your email address into the box above, click the button" >From google code (the top hit on google): "making email addresses readable again" And perhaps most importantly from the spec, the first example: "Assume you receive an email from Bob..." However only SWD here is doing email based discovery (mailto= :). WebFinger *now* doing acct: based discovery, which is a departure from= the original use case. Im glad that some people have voiced support for acct:, but I still believe= that to be a minority. I agree, that the new acct: scheme should for in a= nother document, rather than shoe horned into an email based discovery syst= em. IMHO, it's better to solve one problem (ie email based discovery) simply an= d well, than to half solve two problems (ie a new uri scheme for identity) = in a single attempt. Paul A couple of points: 1. JSON =3D=3D=3D=3D=3D=3D=3D I think at the time webfinger was created in 2009, XML was the de facto ser= ialization, used in AJAX, SOAP and many other systems. Today I'm hearing m= ore and more, that both developers and publishers, want to work with JSON, = rather than, having to support both xml and json. Content negotiation also= confuses some publishers. In my view, this is a great simplification that= webfinger can learn from SWD. 2. acct: scheme =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The acct: URI scheme has not proved popular, imho, and has added a layer of= complexity and confusion. How do we get from acct: to mailto:? When shou= ld you use acct: and when mailto: (the spec says acct:user@host may be diff= erent from mailto:user@host). What about the forms. How= about linked data ecosystems that want to cross link identifiers, do they = now have to consider both cases? >From the original post introducing acct: "I don't expect everyone to like this idea. I wish I could say I love it, b= ut I am simply content with it." I dont know of anyone in the community (and correct me if this has changed)= that really loves acct:, or perhaps even likes the acct: idea. SWD has sh= own you can do discovery without acct: and I think that's a big plus. One final side note is that this almost becomes trivial when you can do SPA= RQL queries. "void" is already registered by the W3C with IANA in .well-kn= own in order to discover SPARQL endpoints. It may be overkill in some peop= le's eyes, but Linked Data (which predates webfinger), particularly newer t= hings like JSON LD, are a lot bigger than they were in 2009. In a few year= s it may become the definitive discovery mechanism anyway. _______________________________________________ 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. Non stampare questa mail se non =E8 necessario. _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE52EE1A716CGRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Paul,

 

I would be careful in returning a positive answer to *any= * type of uri and make any statement as such in the spec. I agree that = from a formal perspective, anyURI should be supported as parameter value, but the= server shall at least support acct:, and as bob, may answer positively to = others if supported/known to that server. I would further recommends it pro= vides back an error to those URI schemes it does not understand.

 

This actually opens the door to interesting capabilities suc= h as per-URI-scheme link rel types. In other words, there may be default re= l link types associated to each uri scheme (hopefully without adding much complex= ity on the spec itself). This may help in discovering protocol-specific end= points of interest, ie the pop/imap endpoint serving the user’s email= address, etc link rel types may be prefixed/namespaced in that case so that a query to mailto: could return an additional link re= l=3Dmailto:pop for example.

 

Is this meaningful?

walter

 

Da: Paul E. Jones [mailto:paulej@packetizer.com]
Inviato: gioved=EC 19 aprile 2012 23.18
A: 'Bob Wyman'
Cc: 'Melvin Carvalho'; Goix Laurent Walter; 'Apps Discuss'
Oggetto: RE: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD)

 

Bob,

 

We could do that.  I changed my WF server code to retur= n a response for any URI scheme:

https://packetizer.com/.well-known/ho= st-meta?resource=3Dfoorbar:paulej@packetizer.com

 

It returns the canonical form (the acct: URI) as an alias.

 

We could do as do as you suggest and return a correct respon= se only to URI schemes that are known.  I have no objection to that, e= xcept that I do not want users to have to know the URI scheme to use.  I do not = want the average user to have to know or care that it’s a mailto URI = or an xmpp URI or whatever.  Users deal with identifiers like “p= aulej@packetizer.com”.  That’s all they should have to worry with.  I’d rather have the WF client convert that to a ca= nonical form, namely acct:paulej@packetizer.com before issuing a query.

 

I do think any WF server should respond appropriately to any= URI.  However, we should remove the guesswork and I think responding = to any scheme (as my server is now doing) is not quite right.  If I visit a remote = web site and want to login using OpenID, I would enter paulej@packetizer.com.  T= he remote site needs to convert that to something.  What is that?  I argue that mailto is a good a= ssumption, but not necessarily correct.  XMPP is another good assumpti= on, but may also be incorrect. If we agree to a standard form (acct:) then = it removes the guesswork on the client.  I like predictability and consistency.

 

Only when a client really has a specific reason for query us= ing a different URI like h323:paulej@packetizer.com should it do that, IMO.=   But, I agree the server should return an intelligent reply if asked.=

 

Paul

 

From: bobwyman@gmail.com = [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman
Sent: Thursday, April 19, 2012 4:36 PM
To: Paul E. Jones
Cc: Melvin Carvalho; Goix Laurent Walter; Apps Discuss
Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD)

 

=  

On Thu, Apr 19, 2012 at 4:21 PM= , Paul E. Jones <paulej@packeti= zer.com> wrote:

Melvin,

 

We could use mailto, but mailto is for email.  That ref= ers to one modality of communication related to a person, but would not represent an “account” at a= domain.  Further, it would not be applicable to services like Twitter= .

 

I would make the same argument for XMPP.  It is another= communication modality for a user at a given domain.

 

In general (though we’ve seen evidence of at least one= exception), paulej@packetize= r.com should be an identifier reserved for a specific account.  I = use that for my XMPP address, my email address, and I would use that to dis= cover my OpenID URI with WebFinger.  No matter what address scheme one starts with, acct:paulej@packetizer.com should return information about my account a= nd likely pointers (directly or indirectly) to all of the other URIs I use.=

 

The generic nature of “user@domain” is perhaps w= hy Blaine was arguing at one point for no scheme at all.  However, we should use a properly formed URI s= ince WF returns information for a URI, which then leads us to ask “wh= at scheme shall we use?”  Thus, “acct:” was born.&nb= sp; It would be legal to query xmpp:paul= ej@packetizer.com.  However, that may or may not return a result.&= nbsp; Presently, it does not.  I most definitely would not expect any = WebFinger server to consider every possible scheme under the sun.

 

It would, I think, be ideal if = we could expect that any domain that provides WebFinger support would allow= queries for any protocols also supported by that domain. Thus, if a domain= supports mailto:, xmpp: or foobar: services in addition to WebFinger, it should probably support queries for = identifiers used by those services, in addition to acct:, but for no others= . In general, I think it also would be good practice to ensure that any que= ry for a protocol other than acct: should return a link to an acct: identifier.

 

 

  Use of mailto: is popular, because so many people use= email.  Funny thing is that the OpenID folks at the start were against that, arguing that email was go= ing to die.  They were pretty insistent that OpenID URIs should look l= ike https://= openid.packetizer.com/paulej.  And, one could use WF to query that= , too.  But, you’ll get a 404 on my server.  I do not want = every possible identifier to return a response.=

 

IMO, “acct:” is a reasonable compromise.  I= t has a meaning (an account URI), it’s communication-protocol neutral (unlike xmpp:, sip:, h323:, mailto:, http:,= etc.), and we’ve debated this at great length for at least 2 or 3 ye= ars now.  People agree “acct:” is not the most appreciated= scheme, but “mailto:” is not an appropriate since that assumes a particular protocol.  Ditto for all other protocol-specific= URI schemes.

 

Paul

 

From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: Thursday, April 19, 2012 10:50 AM
To: Goix Laurent Walter
Cc: Pelle Wessman; Paul E.Jones; Apps Discuss
Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD)

 

 

On 19 April 2012 15:59, Goix Laurent Walter &= lt;laurentwalter.goix@telecomitalia.it> wrote:

Possibly a standard discovery mechanism should rely on some = sort of URI and not a simple token string. URIs representing social network accounts are missing= so far and at least this type of URI should be discoverable. Optionally I = believe any type of other uri may, but with no guarantee. It may be a matte= r of permissions, internal db lookups and/or associations or else on the server to decide whether to provide a m= eaningful response to it. This is somehow already clarified in section 5 of= the wf draft.


Why do you say "URIs representing social accounts are missing so far&q= uot;?  And if so, from which systems? 

For example, Facebook has a pretty good system for representing their accou= nts as URIs (open graph protocol), as does SIOC, and people like status.net (inventor of= OStatus who have a pretty good FOAF impl.) etc.  All of these use HTT= P URIs as their machine representation, rather than any proposed acct: sche= me, for example. 

I thought this use case is mainly relevant to the big webmail providers.
Email style discovery is missing (apart from the specific case of a public = key in GPG), so if you want a full Web sytle solution use void (already reg= istered with IANA).  If void is too complex, choose something simpler.=   SWD seems a simpler solution, at this point, technically.  WF may have the lead on adoption, I dont know.&n= bsp; Perhaps something can be learnt by each system from each other ... e.g= . the JSON vs XML discussion.  Merging the best parts from both specs = could be a great idea...

As for non mailto: URI schemes, that in itself is an interesting problem, p= erhaps a big topic.  To me, xmpp: is a very interesting candidate.&nbs= p; Again void can be used for this, but maybe WF/SWD is an interesting thin= g to deploy.  Having a lookup for the tel: scheme would be kind of amazing ... but is a whole problem in itself, incl= uding finding the well known location.  HTTP discovery is really in ad= vanced stages, with mature deployments, under the W3C / Linked Data.  = I would personally NOT encourage acct: lookup because it's just too confusing for the average developer, fractures ident= ity, does not provide HTTP style 'follow your nose', and ultimately, will p= robably not be a long lived identifier, given how quickly the web identity = space evolves (just my 2 cents).

I think sweet spot here is find the path of least resistance, for a really = good discovery system for email addresses.   Other schemes *could* be = a plus depending on the context, but the most compelling and useful lookup = that is filling a gap I think, is mailto: based.

 

walter

 

Da: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di Pelle Wessman
Inviato: gioved=EC 19 aprile 2012 13.53
A: Paul E.Jones
Cc: 'Apps Discuss'
Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Dis= covery (SWD)

 

While WebFinger officially requires an "acct" URI I beli= eve almost all current implementers accept a "pelle@kodfabrik.se" URI as being the same as "acct:pelle@kodfabrik.se". Gmail.com does, StatusNe= t/Identi.ca does, we at Flattr does. So there is a discrepancy between= the WebFinger specification and real life implementations.

 

Examples:

 

 

Also, speaking from a Flattr-perspective, mail addresses and user = accounts are _not_ the same thing in our system. I myself have the e-mail pelle@flattr.com = but I have the web site account voxpelli@flattr.co= m and the web site account pelle@flattr.com = doesn't belong to me but to one of our users. I believe most web sites, at = least the smaller ones, works like this - that the e-mail system and the we= b system is completely separated from each other and that the user identifiers in one can conflict with the iden= tifiers in the other.

 

I would say that a lookup for "mailto:pelle@flattr.com" should return inf= o about the user behind that e-mail address (if it should return anything) but that a lookup for "pelle@flattr.com" or "acct:pelle@flattr.com= " should always return data about the web site user and that clients should be encouraged to use "acct:" to make it = clear that they want the web site's user, but that they shouldn't be requir= ed to do so.

 

/ Pelle

 

 

19 apr 2012 kl. 00:03 skrev Paul E. Jones:

 

Melvin,

 

WebFinger does discovery on any URI.  = It might be “http”, “mailto”, “ftp”, or “acct”.  So, it’s not entirely correct to say th= at WebFinger does not do discovery using email addresses.  I could cha= nge my server code pretty easily to accommodate mailto.

 

Use of mailto was something discussed at length.  As ot= hers pointed out, it was not necessarily favored by all, but it was recognized to be insufficient for s= ome situations.  Most importantly, nobody other than = us geeks knows what the heck a “mailto” is.  But, we do re= cognize that social sites like Twitter have accounts.  Thus, after the lengthy debate that took place in several places, it was decided to go= with “acct”.  It actually does have a useful purpose.&nbs= p; And its construction is made to look similar to “mailto” so = that the a user would just enter what they consider to be an “email&#= 8221; address, including things we know are not like user@twitter.com.  Using “ma= ilto” is technically incorrect, but users never have to know or care = about that.  Behind the scenes, we use “acct”.  I wou= ld personally never show an end user “acct:paulej@packetizer.com”.  Rather, = I would just tell people that their account ID is “paulej@packetizer.com”.&= nbsp; That may or may not be their address.  Query a Twitter account and it= might return an email address that differs (if Twitter were to share that = info).

 

Paul

 

From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] 
Sent: Wednesday, April 18, 2012 6:05 AM
To: Paul E. Jones
Cc: Mike Jones; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple We= b Discovery (SWD)

 

 

On 18 April 2012 01:59, Paul E. Jones <paulej@packetizer.c= om> wrote:

Melvin,

 

On “acct:”…

 

Humans will usually interchange an acct URI and mailto URI, = probably never using either scheme directly in practice.  That’s natural and expected, if n= ot desired.  The intent is that we define something that looks like an= email ID, but it’s not an email ID.  Some services, perhaps Twi= tter being most notable, do no use email addresses.  Yet, you might have an account there.  So, user@twitter.com might be used by humans a= nd automated systems would convert that to acct:user@twitter.com.  It would not be appropriate to use mailto: since it’s not an email I= D.

 

We did have a lot of debate about the use of “acctR= 21;.  If you query my WebFinger server, you’ll see that it will work without “acct:” prefixed, a= s that was a suggestion made a year or so ago.  It will inspect the in= put and if it looks like an acct URI, it will assume it is.  The ̶= 0;acct” URI will be returned as an alias.  However, we should al= ways use some kind of URI scheme to remove the guesswork.  The client can = often make a very good guess as to whether it’s looking for a user ac= count or something else.  So, let it tell the server what it is lookin= g for explicitly.

 

We need a URI scheme, because WebFinger can be used to disco= ver all kinds of information related to a given domain, not only user information.  It can be used= to query information about any URI, be that a web page, a user account, de= vice on the network, etc.  If we got rid of “acct”, then w= e would have a system where we sometimes use a URI scheme and sometimes we do not.  Results might be inconsistent, as the serve= r may not make the right guess, unless we agreed that absence of a scheme d= efaults to “acct:”.  However, I see no reason for the clie= nt to be so lazy to not include “acct:”.  The user might (and probably will) exclude it, but the client code can add it.

 

At this point, I’d argue the “train has left the= station” on “acct”, too.  The current WebFinger spec exists (in part) to formally document that which has adopte= d; it’s not a new thing.



Paul, thank you for your explanation on lookup based on acct: (WebFinger) v= s lookup based on mailto: (SWD).

I think this is a major difference.

The original WebFinger proposal was *supposed* to give extra information ab= out an email address.

>From wikipedia:

"WebFinger is an Internet protocol that = aims to provide information about people by their E-mail addresses<= /b>."

From webfinger.org<= /a>:

"Put your email address into the box above, click the= button"

>From google code (the top hit on google):

"making email addresses = ;readable again"

And perhaps most importantly from the spec, the first example:

"Assume you receive an email&nbs= p;from Bob..."

However only SWD here is doing email based discovery (mailto:).  WebFinger *now* doing acct: base= d discovery, which is a departure from the original use case.  
Im glad that some people have voiced support for acct:, but I still believe= that to be a minority.  I agree, that the new acct: scheme should for= in another document, rather than shoe horned into an email based discovery= system.  

IMHO, it's better to solve one problem (ie email based discovery) simply an= d well, than to half solve two problems (ie a new uri scheme for identity) = in a single attempt.  
 

 

Paul

 

A couple of points:

1. JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the time webfinger was created in 2009, XML was the de facto ser= ialization, used in AJAX, SOAP and many other systems.  Today I'm hear= ing more and more, that both developers and publishers, want to work with J= SON, rather than, having to support both xml and json.  Content negotiation also confuses some publishers.&nbs= p; In my view, this is a great simplification that webfinger can learn from= SWD.

2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The acct: URI scheme has not proved popular, imho, and has added a layer of= complexity and confusion.  How do we get from acct: to mailto:? = When should you use acct: and when mailto: (the spec says acct:user@host m= ay be different from mailto:= user@host).  What about the forms.  How about linked data ecosystems that want to = cross link identifiers, do they now have to consider both cases?  = ;

>From the original post introducing acct:

"I don’t expect everyone to like this idea. I wish I could say I= love it, but I am simply content with it."

I dont know of anyone in the community (and correct me if this has changed)= that really loves acct:, or perhaps even likes the acct: idea.  SWD h= as shown you can do discovery without acct: and I think that's a big plus.<= br>



One final side note is that this almost becomes trivial when you can do SPA= RQL queries.  "void" is already registered by the W3C with I= ANA in .well-known in order to discover SPARQL endpoints.  It may be o= verkill in some people's eyes, but Linked Data (which predates webfinger), particularly newer things like JSON LD, are a lot big= ger than they were in 2009.  In a few years it may become the definiti= ve discovery mechanism anyway.

 

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

 

Questo messaggio e i suoi allegati sono indirizzati esclusivame= nte alle persone indicate. La diffusione, copia o qualsiasi altra azione de= rivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortes= emente pregati di darne immediata comunicazione al mittente e di provvedere= alla sua distruzione, Grazie.

This e-mail and a= ny attachments is confidential and may contain privileged informa= tion intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intend= ed 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 =E8 nec= essario.


_______________________________________________
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

 

= 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_A09A9E0A4B9C654E8672D1DC003633AE52EE1A716CGRFMBX704BA02_-- --_9287f097-730c-416a-b128-f8cdcb573bf1_ 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= --_9287f097-730c-416a-b128-f8cdcb573bf1_-- From paulej@packetizer.com Thu Apr 19 23: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 7965421E8036; Thu, 19 Apr 2012 23:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAxrhmVLszKU; Thu, 19 Apr 2012 23:00:13 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 20FF721E8025; Thu, 19 Apr 2012 23:00:13 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3K60BEM000403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 02:00:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334901612; bh=R42V2chsFu3YMfrOM/24Vskuzm5hsMsHQCgm89/IYok=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=d5OcegZgoc9d022t0AnC3XxwEISYfMqY41pT+yarGAc5ynU+oDia/4HWArvaVwM6s pmj7KL2ml96Nqxs+5EEyXgFp4mWWgRCqYODF2Uj8vrzOXwO8TcTO+mkuheRPzl7qS3 OklgTlU9m/CeDJrAzvQxzp8s0QzaBBtoG1ayWPLw= From: "Paul E. Jones" To: "'Goix Laurent Walter'" , "'Tim Bray'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> In-Reply-To: Date: Fri, 20 Apr 2012 02:00:33 -0400 Message-ID: <092701cd1eba$e6447990$b2cd6cb0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAIw2f/NAUQ5aEgCTYzvFAFRPsjalaomNgA= Content-Language: en-us Cc: oauth@ietf.org, 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 06:00:19 -0000 Oh, don't scare people with that ;-) If we do extend the syntax of WF, we should ensure that both formats are extended in a natural way for each format. Backward compatibility = should also be of utmost concern, so changes should never be too drastic. Paul > -----Original Message----- > From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] > Sent: Friday, April 20, 2012 1:49 AM > To: Tim Bray; Paul E. Jones > Cc: oauth@ietf.org; Apps Discuss > Subject: R: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery > (SWD) >=20 > I also would be in favor of keeping both, for the reasons mentioned. = Plus > xml is traditionally better than json at handling extensions & = namespaces > that may appear throughout future deployments >=20 > walter >=20 > > -----Messaggio originale----- > > Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] Per conto di Tim Bray > > Inviato: venerd=EC 20 aprile 2012 7.33 > > A: Paul E. Jones > > Cc: oauth@ietf.org; Apps Discuss > > Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > > Discovery (SWD) > > > > Oops, looks like I left off the link to my own remarks about = XML&JSON: > > http://goo.gl/v7Pjr - but they say the same thing, more or less, = that > > MNot did. Your characterizing me as an enemy of XML is amusing, = given > > that my name appears at the top of this document: = http://goo.gl/lBjkl > > > > The points 1 & 2 you're reacting to are from someone else. But we > > agree that the choice of formats isn't crucial. Where we disagree is > > that we should pick just one, not multiple ones. -T > > > > On Thu, Apr 19, 2012 at 9:43 PM, Paul E. Jones = > > wrote: > > > Tim, > > > > > > I do not agree that it's harmful. If I removed the WF discussion = off > > the > > > table, I'm still having a hard time buying into everything you = said > > in the > > > blog post. > > > > > > I implement various web services, largely for my own use. = Usually, > > > I implement all of them in XML, JSON, plain text (attribute/value > > pairs), AND > > > JavaScript (for JSONP). For simple services, it's not hard. I do > > > it because I sometimes have different wants/desires on the client > side. > > (For > > > more complex ones, I use XML.) > > > > > > For your point (1): > > > For WebFinger, the format is simple. The XRD and JRD definitions > > exist and > > > are clearly defined. I think the definitions of each are natural. > > It's not > > > hard to produce both. > > > > > > For your point (2): > > > That's a bias you have against XML, no two ways about it. I tend = to > > prefer > > > to run XML through a sax-style parser and pull out what I want. > > > But, > > doing > > > data binding is reasonable if one is dealing with complex data > > structures. > > > WebFinger is not so complex that it would need to be done that = way, > > but so > > > what if developers did? It's their code. A lot of web services > > > have > > been > > > written that way, so let developers choose. > > > > > > You conclude with "use JSON". By that logic, we should send the > > HTML5 team > > > back to the drawing board and have then re-write it in JSON. Oh, > > HTML is a > > > document format. Complex JSON isn't? I'd argue it is whatever = you > > want to > > > put in it. > > > > > > In any case, I'm not going to object if the consensus of the group > > > is > > to > > > abandon XML entirely. I personally do not care which format(s) we > > use. > > > What bothers me, though, is that we put a stake in the ground a = few > > years > > > ago and people were happy until *very* recently. Now, we want to > > pull it > > > out of the ground and put in a whole new one. > > > > > > Engineering protocols should involve thinking far down the road. = I > > cannot > > > fault anyone for having selected XML at the outset. I cannot = fault > > anyone > > > for wanting to add JSON support now for something this simple to > > implement > > > on the server. However, what I call dangerous is declaring that > > > JSON > > should > > > be the only format for the web, ignoring the significant = investment > > web > > > developers have in XML. The motivation for JSON? Because it = works > > well > > > with JavaScript, in spite of the fact that nobody would want to do > > > an > > eval > > > on it, so it has to be parsed like any other format? What about = the > > next > > > web language? Would we invent a new format for that, too? > > > > > > This is like throwing out a widely deploy authentication protocol > > > and re-inventing that wheel, too. Oh yeah... that would be what = was > > > done > > with > > > OpenID Connect ;-) > > > > > > Seriously... is there no sense of maintaining backward = compatibility > > and > > > rigidly defining protocols for the long-term? > > > > > > Paul > > > > > >> -----Original Message----- > > >> From: Tim Bray [mailto:tbray@textuality.com] > > >> Sent: Thursday, April 19, 2012 11:41 PM > > >> To: Paul E. Jones > > >> Cc: Mike Jones; Murray S. Kucherawy; oauth@ietf.org; Apps Discuss > > >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > > Discovery > > >> (SWD) > > >> > > >> No. Supporting two different on-the-wire data formats is actively > > harmful. > > >> Here are two pieces which explain why: > > >> > > >> - mnot, this month: > > >> http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide > > >> - Me, back in 2009 > > >> > > >> Pick one. -T > > >> > > >> On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones > > > > >> wrote: > > >> > Mike, > > >> > > > >> >> There are two criteria that I would consider to be essential > > >> >> requirements for any resulting general-purpose discovery > > specification: > > >> >> > > >> >> 1. Being able to always discover per-user information with a > > single > > >> >> GET (minimizing user interface latency for mobile devices, = etc.) > > >> > > > >> > WF can do that. See: > > >> > $ curl -v https://packetizer.com/.well-known/\ > > >> > host-meta.json?resource=3Dacct:paulej@packetizer.com > > >> > > > >> >> 2. JSON should be required and it should be the only format > > required > > >> >> (simplicity and ease of deployment/adoption) > > >> > > > >> > See the above example. However, I also support XML with my > > server. > > >> > It took me less than 10 minutes to code up both XML and JSON > > >> > representations. Once the requested format is determined, the > > >> > requested URI is determined, data is pulled from the database, > > spitting > > >> out the desired format is trivial. > > >> > > > >> > Note, and very important note: supporting both XML and JSON = would > > only > > >> > be a server-side requirement. The client is at liberty to use > > >> > the format it prefers. I would agree that forcing a client to > > >> > support both would be unacceptable, but the server? Nothing to = it. > > >> > > > >> >> SWD already meets those requirements. If the resulting spec > > meets > > >> >> those requirements, it doesn't matter a lot whether we call it > > >> >> WebFinger or Simple Web Discovery, but I believe that the > > >> >> requirements discussion is probably the most productive one to > > >> >> be having at this point - not the starting point document. > > >> > > > >> > I believe WebFinger meets those requirements. We could debate > > whether > > >> > XML should be supported, but I'll note (again) that it is there > > >> > in > > RFC > > >> 6415. > > >> > That document isn't all that old and, frankly, it concerns me > > >> > that > > we > > >> > would have a strong preference for format A one week and then > > Format B > > >> the next. > > >> > We are where we are and I can see reason for asking for JSON, = but > > no > > >> > good reason to say we should not allow XML (on the server = side). > > >> > > > >> > 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 >=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. From paulej@packetizer.com Thu Apr 19 23:07: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 113FA21E8034 for ; Thu, 19 Apr 2012 23:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW4RBlCOLrBN for ; Thu, 19 Apr 2012 23:07:35 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C2E0321E8027 for ; Thu, 19 Apr 2012 23:07:34 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3K67W5b000658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 02:07:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334902053; bh=qMOLYR8yzH4tKqDiY14dSMUdLUsIx294e3ByKHvBf8w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=g77KHLyIL7XlN5AWKisarCJh6DwkyBQM3o0nwbCuHEqy+Y6lY4hb65+rPmJh5CtKQ hqtSHo435XgPS0dzYnT6j3NwrSZiIMkSm+tXW1eiPwCj9oyvxQQVCphwITKD9c8HK4 iHqhxK9bj1j2fevZwn3meEkxLTKLb4C/iZupqIwk= From: "Paul E. Jones" To: "'Goix Laurent Walter'" , "'Bob Wyman'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <04fb01cd1cf6$23131c80$69395580$@packetizer.com> <069501cd1daf$20087580$60196080$@packetizer.com> <15AB1540-7555-4C02-A29A-AAE0ADA786B3@kodfabrik.se> <084401cd1e69$f8ff4250$eafdc6f0$@packetizer.com> <087201cd1e71$de687da0$9b3978e0$@packetizer.com> In-Reply-To: Date: Fri, 20 Apr 2012 02:07:54 -0400 Message-ID: <092c01cd1ebb$ed19c8a0$c74d59e0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_092D_01CD1E9A.660CE390" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0B/rNJdACTlkYtAqzWkh0CKCokFwIKVUEBASLQzuwCKHMIGAI9BikIAS4MPVkBw+S5OgHyDJKoAdCLIaYDBi9D8ZVdzVDQ Content-Language: en-us Cc: 'Apps Discuss' Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 06:07:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_092D_01CD1E9A.660CE390 Content-Type: multipart/alternative; boundary="----=_NextPart_001_092E_01CD1E9A.660CE390" ------=_NextPart_001_092E_01CD1E9A.660CE390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Walter, =20 Yes, I agree with you. A SIP client, for example, might use WebFinger = to find out something about a called SIP user, with WebFinger results that differ from if I were to query the user account for a person. Perhaps = there might be a number of SIP-specific link relations returned. =20 I fully agree with what you said. I don=92t like the code returning a positive answer to any :user@domain. I made the change to = highlight out trivial it is to do, but =85 what=92s the right thing to do? I = still content acct: is the right thing to do when looking for information = about a person. =20 Paul =20 From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]=20 Sent: Friday, April 20, 2012 1:55 AM To: Paul E. Jones; 'Bob Wyman' Cc: 'Melvin Carvalho'; 'Apps Discuss' Subject: R: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD) =20 Paul, =20 I would be careful in returning a positive answer to *any* type of uri = and make any statement as such in the spec. I agree that from a formal perspective, anyURI should be supported as parameter value, but the = server shall at least support acct:, and as bob, may answer positively to = others if supported/known to that server. I would further recommends it provides = back an error to those URI schemes it does not understand. =20 This actually opens the door to interesting capabilities such as per-URI-scheme link rel types. In other words, there may be default rel = link types associated to each uri scheme (hopefully without adding much complexity on the spec itself). This may help in discovering protocol-specific endpoints of interest, ie the pop/imap endpoint = serving the user=92s email address, etc link rel types may be = prefixed/namespaced in that case so that a query to mailto: could return an additional link rel=3Dmailto:pop for example. =20 Is this meaningful? walter =20 Da: Paul E. Jones [mailto:paulej@packetizer.com]=20 Inviato: gioved=EC 19 aprile 2012 23.18 A: 'Bob Wyman' Cc: 'Melvin Carvalho'; Goix Laurent Walter; 'Apps Discuss' Oggetto: RE: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) =20 Bob, =20 We could do that. I changed my WF server code to return a response for = any URI scheme: https://packetizer.com/.well-known/host-meta?resource=3Dfoorbar:paulej@pa= cketi zer.com =20 It returns the canonical form (the acct: URI) as an alias. =20 We could do as do as you suggest and return a correct response only to = URI schemes that are known. I have no objection to that, except that I do = not want users to have to know the URI scheme to use. I do not want the = average user to have to know or care that it=92s a mailto URI or an xmpp URI or whatever. Users deal with identifiers like =93paulej@packetizer.com=94. = That=92s all they should have to worry with. I=92d rather have the WF client = convert that to a canonical form, namely acct:paulej@packetizer.com before = issuing a query.=20 =20 I do think any WF server should respond appropriately to any URI. = However, we should remove the guesswork and I think responding to any scheme (as = my server is now doing) is not quite right. If I visit a remote web site = and want to login using OpenID, I would enter paulej@packetizer.com. The = remote site needs to convert that to something. What is that? I argue that = mailto is a good assumption, but not necessarily correct. XMPP is another good assumption, but may also be incorrect. If we agree to a standard form (acct:) then it removes the guesswork on the client. I like = predictability and consistency. =20 Only when a client really has a specific reason for query using a = different URI like h323:paulej@packetizer.com should it do that, IMO. But, I = agree the server should return an intelligent reply if asked. =20 Paul =20 From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob = Wyman Sent: Thursday, April 19, 2012 4:36 PM To: Paul E. Jones Cc: Melvin Carvalho; Goix Laurent Walter; Apps Discuss Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) =20 =20 On Thu, Apr 19, 2012 at 4:21 PM, Paul E. Jones wrote: Melvin, =20 We could use mailto, but mailto is for email. That refers to one = modality of communication related to a person, but would not represent an = =93account=94 at a domain. Further, it would not be applicable to services like = Twitter. =20 I would make the same argument for XMPP. It is another communication modality for a user at a given domain. =20 In general (though we=92ve seen evidence of at least one exception), paulej@packetizer.com should be an identifier reserved for a specific account. I use that for my XMPP address, my email address, and I would = use that to discover my OpenID URI with WebFinger. No matter what address scheme one starts with, acct:paulej@packetizer.com should return information about = my account and likely pointers (directly or indirectly) to all of the other URIs I use. =20 The generic nature of =93user@domain=94 is perhaps why Blaine was = arguing at one point for no scheme at all. However, we should use a properly formed = URI since WF returns information for a URI, which then leads us to ask = =93what scheme shall we use?=94 Thus, =93acct:=94 was born. It would be legal = to query xmpp:paulej@packetizer.com . = However, that may or may not return a result. Presently, it does not. I most definitely would not expect any WebFinger server to consider every = possible scheme under the sun. =20 It would, I think, be ideal if we could expect that any domain that = provides WebFinger support would allow queries for any protocols also supported = by that domain. Thus, if a domain supports mailto:, xmpp: or foobar: = services in addition to WebFinger, it should probably support queries for = identifiers used by those services, in addition to acct:, but for no others. In = general, I think it also would be good practice to ensure that any query for a protocol other than acct: should return a link to an acct: identifier. =20 =20 Use of mailto: is popular, because so many people use email. Funny = thing is that the OpenID folks at the start were against that, arguing that = email was going to die. They were pretty insistent that OpenID URIs should = look like https://openid.packetizer.com/paulej. And, one could use WF to = query that, too. But, you=92ll get a 404 on my server. I do not want every possible identifier to return a response. =20 IMO, =93acct:=94 is a reasonable compromise. It has a meaning (an = account URI), it=92s communication-protocol neutral (unlike xmpp:, sip:, h323:, = mailto:, http:, etc.), and we=92ve debated this at great length for at least 2 or = 3 years now. People agree =93acct:=94 is not the most appreciated scheme, = but =93mailto:=94 is not an appropriate since that assumes a particular = protocol. Ditto for all other protocol-specific URI schemes. =20 Paul =20 From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]=20 Sent: Thursday, April 19, 2012 10:50 AM To: Goix Laurent Walter Cc: Pelle Wessman; Paul E.Jones; Apps Discuss Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) =20 =20 On 19 April 2012 15:59, Goix Laurent Walter wrote: Possibly a standard discovery mechanism should rely on some sort of URI = and not a simple token string. URIs representing social network accounts are missing so far and at least this type of URI should be discoverable. Optionally I believe any type of other uri may, but with no guarantee. = It may be a matter of permissions, internal db lookups and/or associations = or else on the server to decide whether to provide a meaningful response to = it. This is somehow already clarified in section 5 of the wf draft. Why do you say "URIs representing social accounts are missing so far"? = And if so, from which systems? =20 For example, Facebook has a pretty good system for representing their accounts as URIs (open graph protocol), as does SIOC, and people like status.net (inventor of OStatus who have a pretty good FOAF impl.) etc. = All of these use HTTP URIs as their machine representation, rather than any proposed acct: scheme, for example. =20 I thought this use case is mainly relevant to the big webmail providers. Email style discovery is missing (apart from the specific case of a = public key in GPG), so if you want a full Web sytle solution use void (already registered with IANA). If void is too complex, choose something = simpler. SWD seems a simpler solution, at this point, technically. WF may have = the lead on adoption, I dont know. Perhaps something can be learnt by each system from each other ... e.g. the JSON vs XML discussion. Merging the best parts from both specs could be a great idea... As for non mailto: URI schemes, that in itself is an interesting = problem, perhaps a big topic. To me, xmpp: is a very interesting candidate. = Again void can be used for this, but maybe WF/SWD is an interesting thing to deploy. Having a lookup for the tel: scheme would be kind of amazing = ... but is a whole problem in itself, including finding the well known = location. HTTP discovery is really in advanced stages, with mature deployments, = under the W3C / Linked Data. I would personally NOT encourage acct: lookup because it's just too confusing for the average developer, fractures identity, does not provide HTTP style 'follow your nose', and = ultimately, will probably not be a long lived identifier, given how quickly the web identity space evolves (just my 2 cents). I think sweet spot here is find the path of least resistance, for a = really good discovery system for email addresses. Other schemes *could* be a = plus depending on the context, but the most compelling and useful lookup that = is filling a gap I think, is mailto: based. =20 walter =20 Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = Per conto di Pelle Wessman Inviato: gioved=EC 19 aprile 2012 13.53 A: Paul E.Jones Cc: 'Apps Discuss' Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD) =20 While WebFinger officially requires an "acct" URI I believe almost all current implementers accept a "pelle@kodfabrik.se" URI as being the same = as "acct:pelle@kodfabrik.se ". Gmail.com does, StatusNet/Identi.ca does, we at Flattr does. So there is a = discrepancy between the WebFinger specification and real life implementations. =20 Examples: =20 http://www.google.com/s2/webfinger/?q=3Dvoxpelli@gmail.com http://identi.ca/main/xrd?uri=3Dvoxpelli@identi.ca https://flattr.com/xrd/lrdd?uri=3Dvoxpelli@flattr.com =20 Also, speaking from a Flattr-perspective, mail addresses and user = accounts are _not_ the same thing in our system. I myself have the e-mail pelle@flattr.com but I have the web site account voxpelli@flattr.com and = the web site account pelle@flattr.com doesn't belong to me but to one of our users. I believe most web sites, at least the smaller ones, works like = this - that the e-mail system and the web system is completely separated from each other and that the user identifiers in one can conflict with the identifiers in the other. =20 I would say that a lookup for "mailto:pelle@flattr.com" should return = info about the user behind that e-mail address (if it should return anything) = but that a lookup for "pelle@flattr.com" or "acct:pelle@flattr.com " should always return data about the = web site user and that clients should be encouraged to use "acct:" to make = it clear that they want the web site's user, but that they shouldn't be required to do so. =20 / Pelle =20 =20 19 apr 2012 kl. 00:03 skrev Paul E. Jones: =20 Melvin, =20 WebFinger does discovery on any URI. It might be =93http=94, = =93mailto=94, =93ftp=94, or =93acct=94. So, it=92s not entirely correct to say that WebFinger = does not do discovery using email addresses. I could change my server code pretty easily to accommodate mailto. =20 Use of mailto was something discussed at length. As others pointed out, = it was not necessarily favored by all, but it was recognized to be = insufficient for some situations. Most importantly, nobody other than us geeks knows what the heck a =93mailto=94 is. But, we do recognize that social sites = like Twitter have accounts. Thus, after the lengthy debate that took place = in several places, it was decided to go with =93acct=94. It actually does = have a useful purpose. And its construction is made to look similar to = =93mailto=94 so that the a user would just enter what they consider to be an =93email=94 address, including things we know are not like user@twitter.com. Using =93mailto=94 is technically incorrect, but users never have to know or = care about that. Behind the scenes, we use =93acct=94. I would personally = never show an end user =93acct:paulej@packetizer.com =94. Rather, I would just tell = people that their account ID is =93paulej@packetizer.com=94. That may or may = not be their address. Query a Twitter account and it might return an email = address that differs (if Twitter were to share that info). =20 Paul =20 From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]=20 Sent: Wednesday, April 18, 2012 6:05 AM To: Paul E. Jones Cc: Mike Jones; Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD) =20 =20 On 18 April 2012 01:59, Paul E. Jones wrote: Melvin, =20 On =93acct:=94=85 =20 Humans will usually interchange an acct URI and mailto URI, probably = never using either scheme directly in practice. That=92s natural and = expected, if not desired. The intent is that we define something that looks like an email ID, but it=92s not an email ID. Some services, perhaps Twitter = being most notable, do no use email addresses. Yet, you might have an account there. So, user@twitter.com might be used by humans and automated = systems would convert that to acct:user@twitter.com = . It would not be appropriate to use mailto: since it=92s not an email = ID. =20 We did have a lot of debate about the use of =93acct=94. If you query = my WebFinger server, you=92ll see that it will work without =93acct:=94 = prefixed, as that was a suggestion made a year or so ago. It will inspect the input = and if it looks like an acct URI, it will assume it is. The =93acct=94 URI = will be returned as an alias. However, we should always use some kind of URI = scheme to remove the guesswork. The client can often make a very good guess as = to whether it=92s looking for a user account or something else. So, let it = tell the server what it is looking for explicitly. =20 We need a URI scheme, because WebFinger can be used to discover all = kinds of information related to a given domain, not only user information. It = can be used to query information about any URI, be that a web page, a user = account, device on the network, etc. If we got rid of =93acct=94, then we would = have a system where we sometimes use a URI scheme and sometimes we do not. = Results might be inconsistent, as the server may not make the right guess, = unless we agreed that absence of a scheme defaults to =93acct:=94. However, I see = no reason for the client to be so lazy to not include =93acct:=94. The = user might (and probably will) exclude it, but the client code can add it. =20 At this point, I=92d argue the =93train has left the station=94 on = =93acct=94, too. The current WebFinger spec exists (in part) to formally document that = which has adopted; it=92s not a new thing. Paul, thank you for your explanation on lookup based on acct: = (WebFinger) vs lookup based on mailto: (SWD). I think this is a major difference. The original WebFinger proposal was *supposed* to give extra information about an email address. >From wikipedia: "WebFinger is an Internet protocol that aims to provide information = about people by their E-mail addresses." >From webfinger.org: "Put your email address into the box above, click the button" >From google code (the top hit on google): "making email addresses readable again" And perhaps most importantly from the spec, the first example: "Assume you receive an email from Bob..." However only SWD here is doing email based discovery (mailto:). = WebFinger *now* doing acct: based discovery, which is a departure from the = original use case. =20 Im glad that some people have voiced support for acct:, but I still = believe that to be a minority. I agree, that the new acct: scheme should for in another document, rather than shoe horned into an email based discovery system. =20 IMHO, it's better to solve one problem (ie email based discovery) simply = and well, than to half solve two problems (ie a new uri scheme for identity) = in a single attempt. =20 =20 =20 Paul =20 A couple of points: 1. JSON =3D=3D=3D=3D=3D=3D=3D I think at the time webfinger was created in 2009, XML was the de facto serialization, used in AJAX, SOAP and many other systems. Today I'm = hearing more and more, that both developers and publishers, want to work with = JSON, rather than, having to support both xml and json. Content negotiation = also confuses some publishers. In my view, this is a great simplification = that webfinger can learn from SWD. 2. acct: scheme =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The acct: URI scheme has not proved popular, imho, and has added a layer = of complexity and confusion. How do we get from acct: to mailto:? When = should you use acct: and when mailto: (the spec says acct:user@host may be different from mailto:user@host). What about the forms. How about = linked data ecosystems that want to cross link identifiers, do they now have to consider both cases? =20 >From the original post introducing acct: "I don=92t expect everyone to like this idea. I wish I could say I love = it, but I am simply content with it." I dont know of anyone in the community (and correct me if this has = changed) that really loves acct:, or perhaps even likes the acct: idea. SWD has shown you can do discovery without acct: and I think that's a big plus. One final side note is that this almost becomes trivial when you can do SPARQL queries. "void" is already registered by the W3C with IANA in .well-known in order to discover SPARQL endpoints. It may be overkill = in some people's eyes, but Linked Data (which predates webfinger), = particularly newer things like JSON LD, are a lot bigger than they were in 2009. In = a few years it may become the definitive discovery mechanism anyway. =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 =E8 necessario.=20 _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss =20 _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss =20 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle 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_092E_01CD1E9A.660CE390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Walter,

 

Yes, I agree with you.=A0 A SIP client, for example, might use = WebFinger to find out something about a called SIP user, with WebFinger = results that differ from if I were to query the user account for a = person.=A0 Perhaps there might be a number of SIP-specific link = relations returned.

 

I fully=A0 agree with what you said.=A0 I don’t like the code = returning a positive answer to any <scheme>:user@domain.=A0 I made = the change to highlight out trivial it is to do, but … = what’s the right thing to do?=A0 I still content acct: is the = right thing to do when looking for information about a = person.

 

Paul

 

From:= = Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] =
Sent: Friday, April 20, 2012 1:55 AM
To: Paul E. = Jones; 'Bob Wyman'
Cc: 'Melvin Carvalho'; 'Apps = Discuss'
Subject: R: [apps-discuss] R: [OAUTH-WG] Web Finger = vs. Simple Web Discovery (SWD)

 

Paul,

 

I would be careful in returning a positive answer to *any* = type of uri and make any statement as such in the spec. I agree that = from a formal perspective, anyURI should be supported as parameter = value, but the server shall at least support acct:, and as bob, may = answer positively to others if supported/known to that server. I would = further recommends it provides back an error to those URI schemes it = does not understand.

 

This actually opens the door to interesting capabilities such as = per-URI-scheme link rel types. In other words, there may be default rel = link types associated to each uri scheme (hopefully without adding much = complexity on the spec itself). This may help in discovering = protocol-specific endpoints of interest, ie the pop/imap endpoint = serving the user’s email address, etc link rel types may be = prefixed/namespaced in that case so that a query to mailto: could return = an additional link rel=3Dmailto:pop for = example.

 

Is this meaningful?

walter

 

Da: Paul E. = Jones [mailto:paulej@packetizer.= com]
Inviato: gioved=EC 19 aprile 2012 23.18
A: = 'Bob Wyman'
Cc: 'Melvin Carvalho'; Goix Laurent Walter; 'Apps = Discuss'
Oggetto: RE: [apps-discuss] R: [OAUTH-WG] Web Finger = vs. Simple Web Discovery (SWD)

 

Bob,

 

We could do that.  I changed my WF server code to return a = response for any URI scheme:

https://packetizer.com/.well-known/host-meta?resour= ce=3Dfoorbar:paulej@packetizer.com

 

It returns the canonical form (the acct: URI) as an = alias.

 

We could do as do as you suggest and return a correct response only = to URI schemes that are known.  I have no objection to that, except = that I do not want users to have to know the URI scheme to use.  I = do not want the average user to have to know or care that it’s a = mailto URI or an xmpp URI or whatever.  Users deal with identifiers = like “paulej@packetizer.com”.&n= bsp; That’s all they should have to worry with.  I’d = rather have the WF client convert that to a canonical form, namely = acct:paulej@packetizer.com before issuing a query.

 

I do think any WF server should respond appropriately to any = URI.  However, we should remove the guesswork and I think = responding to any scheme (as my server is now doing) is not quite = right.  If I visit a remote web site and want to login using = OpenID, I would enter paulej@packetizer.com. =  The remote site needs to convert that to something.  = What is that?  I argue that mailto is a good assumption, but not = necessarily correct.  XMPP is another good assumption, but may also = be incorrect. If we agree to a standard form (acct:) then it removes the = guesswork on the client.  I like predictability and = consistency.

 

Only when a client really has a specific reason for query using a = different URI like h323:paulej@packetizer.com should it do that, = IMO.  But, I agree the server should return an intelligent reply if = asked.

 

Paul

 

 

 

On Thu, Apr = 19, 2012 at 4:21 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Melvin,

 

We could use mailto, but mailto is for email.  That refers to = one modality of communication related to a person, but would not = represent an “account” at a domain.  Further, it would = not be applicable to services like Twitter.

 

I would make the same argument for XMPP.  It is another = communication modality for a user at a given domain.

 

In general (though we’ve seen evidence of at least one = exception), paulej@packetizer.com should be an identifier = reserved for a specific account.  I use that for my XMPP address, = my email address, and I would use that to discover my OpenID URI with = WebFinger.  No matter what address scheme one starts with, acct:paulej@packetizer.com should return = information about my account and likely pointers (directly or = indirectly) to all of the other URIs I use.

 

The generic nature of “user@domain” is perhaps why Blaine = was arguing at one point for no scheme at all.  However, we should = use a properly formed URI since WF returns information for a URI, which = then leads us to ask “what scheme shall we use?”  Thus, = “acct:” was born.  It would be legal to query xmpp:paulej@packetizer.com.  However, that = may or may not return a result.  Presently, it does not.  I = most definitely would not expect any WebFinger server to consider every = possible scheme under the sun.

 

It = would, I think, be ideal if we could expect that any domain that = provides WebFinger support would allow queries for any protocols also = supported by that domain. Thus, if a domain supports mailto:, xmpp: or = foobar: services in addition to WebFinger, it should probably support = queries for identifiers used by those services, in addition to acct:, = but for no others. In general, I think it also would be good practice to = ensure that any query for a protocol other than acct: should return a = link to an acct: identifier.

 

 

  Use of mailto: is popular, because so many people use = email.  Funny thing is that the OpenID folks at the start were = against that, arguing that email was going to die.  They were = pretty insistent that OpenID URIs should look like https://openid.packetizer.com/paulej.  And, = one could use WF to query that, too.  But, you’ll get a 404 = on my server.  I do not want every possible identifier to return a = response.

 

IMO, “acct:” is a reasonable compromise.  It has a = meaning (an account URI), it’s communication-protocol neutral = (unlike xmpp:, sip:, h323:, mailto:, http:, etc.), and we’ve = debated this at great length for at least 2 or 3 years now.  People = agree “acct:” is not the most appreciated scheme, but = “mailto:” is not an appropriate since that assumes a = particular protocol.  Ditto for all other protocol-specific URI = schemes.

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Thursday, April 19, 2012 10:50 AM
To: Goix Laurent = Walter
Cc: Pelle Wessman; Paul E.Jones; Apps = Discuss
Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger = vs. Simple Web Discovery (SWD)

 

 

On 19 April = 2012 15:59, Goix Laurent Walter <laurentwalter.goix@telecomitalia.it> = wrote:

Possibly a standard discovery mechanism should rely on some sort of = URI and not a simple token string. URIs representing social network = accounts are missing so far and at least this type of URI should be = discoverable. Optionally I believe any type of other uri may, but with = no guarantee. It may be a matter of permissions, internal db lookups = and/or associations or else on the server to decide whether to provide a = meaningful response to it. This is somehow already clarified in section = 5 of the wf draft.


Why do you = say "URIs representing social accounts are missing so = far"?  And if so, from which systems? 

For = example, Facebook has a pretty good system for representing their = accounts as URIs (open graph protocol), as does SIOC, and people like status.net (inventor of = OStatus who have a pretty good FOAF impl.) etc.  All of these use = HTTP URIs as their machine representation, rather than any proposed = acct: scheme, for example. 

I thought this use case is = mainly relevant to the big webmail providers.

Email style = discovery is missing (apart from the specific case of a public key in = GPG), so if you want a full Web sytle solution use void (already = registered with IANA).  If void is too complex, choose something = simpler.  SWD seems a simpler solution, at this point, = technically.  WF may have the lead on adoption, I dont know.  = Perhaps something can be learnt by each system from each other ... e.g. = the JSON vs XML discussion.  Merging the best parts from both specs = could be a great idea...

As for non mailto: URI schemes, that in = itself is an interesting problem, perhaps a big topic.  To me, = xmpp: is a very interesting candidate.  Again void can be used for = this, but maybe WF/SWD is an interesting thing to deploy.  Having a = lookup for the tel: scheme would be kind of amazing ... but is a whole = problem in itself, including finding the well known location.  HTTP = discovery is really in advanced stages, with mature deployments, under = the W3C / Linked Data.  I would personally NOT encourage acct: = lookup because it's just too confusing for the average developer, = fractures identity, does not provide HTTP style 'follow your nose', and = ultimately, will probably not be a long lived identifier, given how = quickly the web identity space evolves (just my 2 cents).

I think = sweet spot here is find the path of least resistance, for a really good = discovery system for email addresses.   Other schemes *could* be a = plus depending on the context, but the most compelling and useful lookup = that is filling a gap I think, is mailto: based.

 

walter

 

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di = Pelle Wessman
Inviato: gioved=EC 19 aprile 2012 = 13.53
A: Paul E.Jones
Cc: 'Apps = Discuss'
Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. = Simple Web Discovery (SWD)

 

While WebFinger officially requires an "acct" URI I = believe almost all current implementers accept a "pelle@kodfabrik.se" URI as being the same as = "acct:pelle@kodfabrik.se". Gmail.com does, = StatusNet/Identi.ca does, we at Flattr does. So there is = a discrepancy between the WebFinger specification and real life = implementations.

 

Examples:

 

Also, speaking from a Flattr-perspective, mail addresses and = user accounts are _not_ the same thing in our system. I myself have the = e-mail pelle@flattr.com but I have the web site account = voxpelli@flattr.com and the web site account pelle@flattr.com = doesn't belong to me but to one of our users. I believe most web sites, = at least the smaller ones, works like this - that the e-mail system and = the web system is completely separated from each other and that the user = identifiers in one can conflict with the identifiers in the = other.

 

I would say that a lookup for "mailto:pelle@flattr.com" should return info = about the user behind that e-mail address (if it should return anything) = but that a lookup for "pelle@flattr.com" or "acct:pelle@flattr.com" should always return = data about the web site user and that clients should be encouraged to = use "acct:" to make it clear that they want the web site's = user, but that they shouldn't be required to do = so.

 

/ Pelle

 

 

19 apr 2012 kl. 00:03 skrev Paul E. = Jones:

 

Melvin,

 

WebFinger does discovery on any URI.  It might = be “http”, “mailto”, “ftp”, or = “acct”.  So, it’s not entirely correct to say = that WebFinger does not do discovery using email addresses.  I = could change my server code pretty easily to accommodate = mailto.

 

Use of mailto was something discussed at length.  As others = pointed out, it was not necessarily favored by all, but it was = recognized to be insufficient for some situations.  Most = importantly, nobody other than us geeks knows what the = heck a “mailto” is.  But, we do recognize that social = sites like Twitter have accounts.  Thus, after the lengthy debate = that took place in several places, it was decided to go with = “acct”.  It actually does have a useful purpose.  = And its construction is made to look similar to “mailto” so = that the a user would just enter what they consider to be an = “email” address, including things we know are not = like user@twitter.com.  Using “mailto” = is technically incorrect, but users never have to know or care about = that.  Behind the scenes, we use “acct”.  I would = personally never show an end user “acct:paulej@packetizer.com”.  Rather, I = would just tell people that their account ID is “paulej@packetizer.com”.  That may or = may not be their address.  Query a Twitter account and it might = return an email address that differs (if Twitter were to share that = info).

 

Paul

 

From:=  Melvin= Carvalho [mailto:melvincarvalho@gmail.com] 
Sent:&nbs= p;Wednesday, April 18, 2012 6:05 AM
To: Paul E. = Jones
Cc: Mike Jones; Apps = Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger = vs. Simple Web Discovery (SWD)

 

 

On 18 April = 2012 01:59, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

 

On “acct:”…

 

Humans will usually interchange an acct URI and mailto URI, probably = never using either scheme directly in practice.  That’s = natural and expected, if not desired.  The intent is that we define = something that looks like an email ID, but it’s not an email = ID.  Some services, perhaps Twitter being most notable, do no use = email addresses.  Yet, you might have an account there.  = So, user@twitter.com might be used by humans and = automated systems would convert that to acct:user@twitter.com.  It would not be = appropriate to use mailto: since it’s not an email ID.

 

We did have a lot of debate about the use of = “acct”.  If you query my WebFinger server, you’ll = see that it will work without “acct:” prefixed, as that was = a suggestion made a year or so ago.  It will inspect the input and = if it looks like an acct URI, it will assume it is.  The = “acct” URI will be returned as an alias.  However, we = should always use some kind of URI scheme to remove the guesswork.  = The client can often make a very good guess as to whether it’s = looking for a user account or something else.  So, let it tell the = server what it is looking for explicitly.

 

We need a URI scheme, because WebFinger can be used to discover all = kinds of information related to a given domain, not only user = information.  It can be used to query information about any URI, be = that a web page, a user account, device on the network, etc.  If we = got rid of “acct”, then we would have a system where we = sometimes use a URI scheme and sometimes we do not.  Results might = be inconsistent, as the server may not make the right guess, unless we = agreed that absence of a scheme defaults to “acct:”.  = However, I see no reason for the client to be so lazy to not include = “acct:”.  The user might (and probably will) exclude = it, but the client code can add it.

 

At this point, I’d argue the “train has left the = station” on “acct”, too.  The current WebFinger = spec exists (in part) to formally document that which has adopted; = it’s not a new thing.



Paul= , thank you for your explanation on lookup based on acct: (WebFinger) vs = lookup based on mailto: (SWD).

I think this is a major = difference.

The original WebFinger proposal was *supposed* to = give extra information about an email address.

From = wikipedia:

"WebFinger is an = Internet protocol that aims to provide information about people by = their E-mail addresses."

From webfinger.org:

"Put your email = address into the box above, click the = button"

From google code (the top hit on = google):

"making email = addresses readable again"

And perhaps most = importantly from the spec, the first example:

"Assume you receive = an email from Bob..."

However only = SWD here is doing email based discovery (mailto:).  WebFinger *now* doing acct: based = discovery, which is a departure from the original use = case.  

Im glad that some people have voiced support = for acct:, but I still believe that to be a minority.  I agree, = that the new acct: scheme should for in another document, rather than = shoe horned into an email based discovery = system.  

IMHO, it's better to solve one problem (ie = email based discovery) simply and well, than to half solve two problems = (ie a new uri scheme for identity) in a single = attempt.  
 

 

Paul

 

A couple of = points:

1. JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the = time webfinger was created in 2009, XML was the de facto serialization, = used in AJAX, SOAP and many other systems.  Today I'm hearing more = and more, that both developers and publishers, want to work with JSON, = rather than, having to support both xml and json.  Content = negotiation also confuses some publishers.  In my view, this is a = great simplification that webfinger can learn from SWD.

2. acct: = scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The acct: URI = scheme has not proved popular, imho, and has added a layer of complexity = and confusion.  How do we get from acct: to mailto:?  When = should you use acct: and when mailto: (the spec says acct:user@host may = be different from mailto:user@host).  What about the forms.  How = about linked data ecosystems that want to cross link identifiers, do = they now have to consider both cases?  

From the = original post introducing acct:

"I don’t expect = everyone to like this idea. I wish I could say I love it, but I am = simply content with it."

I dont know of anyone in the = community (and correct me if this has changed) that really loves acct:, = or perhaps even likes the acct: idea.  SWD has shown you can do = discovery without acct: and I think that's a big = plus.




One final side note is that this almost becomes = trivial when you can do SPARQL queries.  "void" is = already registered by the W3C with IANA in .well-known in order to = discover SPARQL endpoints.  It may be overkill in some people's = eyes, but Linked Data (which predates webfinger), particularly newer = things like JSON LD, are a lot bigger than they were in 2009.  In a = few years it may become the definitive discovery mechanism anyway.

 

____________= ___________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= span lang=3DFR>

 

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


______________= _________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= span lang=3DFR>

 


______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= span lang=3DFR>

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. =

= This e-mail and any attachments=  is = confidential and may contain privileged information intended for the = addressee(s) only. Dissemination, copying, printing or use by anybody = else is unauthorised. If you are not the intended recipient, please = delete this message and any attachments and advise the sender by return = e-mail, Thanks.

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

 

------=_NextPart_001_092E_01CD1E9A.660CE390-- ------=_NextPart_000_092D_01CD1E9A.660CE390 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_092D_01CD1E9A.660CE390-- From paulej@packetizer.com Thu Apr 19 23:11: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 3F24521F846D; Thu, 19 Apr 2012 23:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR449xjD3dnK; Thu, 19 Apr 2012 23:11:02 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 18F3421F8463; Thu, 19 Apr 2012 23:11:02 -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 q3K6AmnE000772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 02:10:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334902249; bh=othCyOP9etff9WFr1Yh/9mkooo0sN93A+TDF0aO4G0s=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=BZPpSZmWZaqrmnU4JqN46iRUUBwM875yWaPcnAWUX4F7GA5h/jljqGzptzyw75Bev lEBBQO3DU5wKd17sw+LbgD2cK7s7IExIuCfVjXdgpEmhTSzDxdmR9adLuxVB+9nU0m iw2o3FhuiI/XOcxPOcW1/4XayH2nAfE1waPSyUC8= From: "Paul E. Jones" To: "'Mike Jones'" , "'Murray S. Kucherawy'" , , "'Apps Discuss'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 20 Apr 2012 02:11:10 -0400 Message-ID: <094101cd1ebc$61eb06d0$25c11470$@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: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAI8MBwxAc/xlwgBkQ/oMJW13o4g Content-Language: en-us Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 06:11:07 -0000 Mike, Deal. :-) Paul > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Friday, April 20, 2012 1:49 AM > To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > To be clear, making this mandatory would break no clients. It would > require updating some servers, just as requiring JSON would. This seems > like a fair tradeoff when it makes an appreciable difference in user > interface latency in some important scenarios. If you and the other key > WebFinger supporters can agree to making "resource" support mandatory and > requiring JSON, I believe we may have a path forward. > > Cheers, > -- Mike > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Thursday, April 19, 2012 10:39 PM > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > That's correct. We could certainly make it mandatory, but the reason it > isn't is to maintain backward compatibility with existing deployments. > > I think we should always think carefully when we decide to make a change > that breaks backward-compatibility. This is one change that would do > that. > > Paul > > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Friday, April 20, 2012 1:10 AM > > To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > > Discovery > > (SWD) > > > > Currently, support for the "resource" parameter is optional, as per > > the following (correct?): > > > > Note that support for the "resource" parameter is optional, but > > strongly RECOMMENDED for improved performance. If a server does not > > implement the "resource" parameter, then the server's host metadata > > processing logic remains unchanged from RFC 6415. > > > > To truly support 1, this would need to be changed to REQUIRED, correct? > > > > -- Mike > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Thursday, April 19, 2012 8:16 PM > > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > > Discovery > > (SWD) > > > > Mike, > > > > > There are two criteria that I would consider to be essential > > > requirements for any resulting general-purpose discovery > specification: > > > > > > 1. Being able to always discover per-user information with a single > > > GET (minimizing user interface latency for mobile devices, etc.) > > > > WF can do that. See: > > $ curl -v https://packetizer.com/.well-known/\ > > host-meta.json?resource=acct:paulej@packetizer.com > > > > > 2. JSON should be required and it should be the only format > > > required (simplicity and ease of deployment/adoption) > > > > See the above example. However, I also support XML with my server. > > It took me less than 10 minutes to code up both XML and JSON > representations. > > Once the requested format is determined, the requested URI is > > determined, data is pulled from the database, spitting out the desired > > format is trivial. > > > > Note, and very important note: supporting both XML and JSON would only > > be a server-side requirement. The client is at liberty to use the > > format it prefers. I would agree that forcing a client to support > > both would be unacceptable, but the server? Nothing to it. > > > > > SWD already meets those requirements. If the resulting spec meets > > > those requirements, it doesn't matter a lot whether we call it > > > WebFinger or Simple Web Discovery, but I believe that the > > > requirements discussion is probably the most productive one to be > > > having at this point - not the starting point document. > > > > I believe WebFinger meets those requirements. We could debate whether > > XML should be supported, but I'll note (again) that it is there in RFC > 6415. > > That document isn't all that old and, frankly, it concerns me that we > > would have a strong preference for format A one week and then Format B > > the next. > > We are where we are and I can see reason for asking for JSON, but no > > good reason to say we should not allow XML (on the server side). > > > > Paul > > > > > > > > > From gsalguei@cisco.com Thu Apr 19 23:21: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 A3C4221F86D8 for ; Thu, 19 Apr 2012 23:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFfkhJ3niMWv for ; Thu, 19 Apr 2012 23:21:25 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 0B51421F86D5 for ; Thu, 19 Apr 2012 23:21:24 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3K6LNE9015378 for ; Fri, 20 Apr 2012 02:21:23 -0400 (EDT) Received: from rtp-gsalguei-87113.cisco.com (rtp-gsalguei-87113.cisco.com [10.116.61.62]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3K6LM54006329; Fri, 20 Apr 2012 02:21:22 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 20 Apr 2012 02:21:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9E57926E-068A-484B-8D5B-DADF95DA92B3@cisco.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1257) Cc: "oauth@ietf.org" , 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 06:21:28 -0000 Mike -=20 I can get behind this approach. (Note: We already mandated JSON in the current WebFinger spec) Cheers, Gonzalo On Apr 20, 2012, at 1:48 AM, Mike Jones wrote: > To be clear, making this mandatory would break no clients. It would = require updating some servers, just as requiring JSON would. This seems = like a fair tradeoff when it makes an appreciable difference in user = interface latency in some important scenarios. If you and the other key = WebFinger supporters can agree to making "resource" support mandatory = and requiring JSON, I believe we may have a path forward. >=20 > Cheers, > -- Mike >=20 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com]=20 > Sent: Thursday, April 19, 2012 10:39 PM > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD) >=20 > That's correct. We could certainly make it mandatory, but the reason = it isn't is to maintain backward compatibility with existing = deployments. >=20 > I think we should always think carefully when we decide to make a = change that breaks backward-compatibility. This is one change that = would do that. >=20 > Paul >=20 >> -----Original Message----- >> From: Mike Jones [mailto:Michael.Jones@microsoft.com] >> Sent: Friday, April 20, 2012 1:10 AM >> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps = Discuss' >> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web=20 >> Discovery >> (SWD) >>=20 >> Currently, support for the "resource" parameter is optional, as per=20= >> the following (correct?): >>=20 >> Note that support for the "resource" parameter is optional, but >> strongly RECOMMENDED for improved performance. If a server does = not >> implement the "resource" parameter, then the server's host metadata >> processing logic remains unchanged from RFC 6415. >>=20 >> To truly support 1, this would need to be changed to REQUIRED, = correct? >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Paul E. Jones [mailto:paulej@packetizer.com] >> Sent: Thursday, April 19, 2012 8:16 PM >> To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' >> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web=20 >> Discovery >> (SWD) >>=20 >> Mike, >>=20 >>> There are two criteria that I would consider to be essential=20 >>> requirements for any resulting general-purpose discovery = specification: >>>=20 >>> 1. Being able to always discover per-user information with a single=20= >>> GET (minimizing user interface latency for mobile devices, etc.) >>=20 >> WF can do that. See: >> $ curl -v https://packetizer.com/.well-known/\ >> host-meta.json?resource=3Dacct:paulej@packetizer.com >>=20 >>> 2. JSON should be required and it should be the only format=20 >>> required (simplicity and ease of deployment/adoption) >>=20 >> See the above example. However, I also support XML with my server. =20= >> It took me less than 10 minutes to code up both XML and JSON = representations. >> Once the requested format is determined, the requested URI is=20 >> determined, data is pulled from the database, spitting out the = desired=20 >> format is trivial. >>=20 >> Note, and very important note: supporting both XML and JSON would = only=20 >> be a server-side requirement. The client is at liberty to use the=20 >> format it prefers. I would agree that forcing a client to support=20 >> both would be unacceptable, but the server? Nothing to it. >>=20 >>> SWD already meets those requirements. If the resulting spec meets=20= >>> those requirements, it doesn't matter a lot whether we call it=20 >>> WebFinger or Simple Web Discovery, but I believe that the=20 >>> requirements discussion is probably the most productive one to be=20 >>> having at this point - not the starting point document. >>=20 >> I believe WebFinger meets those requirements. We could debate = whether=20 >> XML should be supported, but I'll note (again) that it is there in = RFC 6415. >> That document isn't all that old and, frankly, it concerns me that we=20= >> would have a strong preference for format A one week and then Format = B=20 >> the next. >> We are where we are and I can see reason for asking for JSON, but no=20= >> good reason to say we should not allow XML (on the server side). >>=20 >> Paul >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From ned.freed@mrochek.com Fri Apr 20 00:32: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 2F49B21F8512 for ; Fri, 20 Apr 2012 00:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNaezVLoJG0O for ; Fri, 20 Apr 2012 00:32:07 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFA221F8559 for ; Fri, 20 Apr 2012 00:32:05 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEITCJOYR4000SUH@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 20 Apr 2012 00:32:02 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEGM6GSINK00ZGHB@mauve.mrochek.com>; Fri, 20 Apr 2012 00:31:59 -0700 (PDT) Message-id: <01OEITCHB07U00ZGHB@mauve.mrochek.com> Date: Fri, 20 Apr 2012 00:24:43 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 19 Apr 2012 09:35:01 -0400" <4F901485.20800@maillennium.att.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> To: Tony Hansen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1334907151; bh=6jnIOReFzyTghGraZMAxlCGh7T3u1uW7nLshpkDMmm0=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=UYQNOK/3wyGkTUMgngdJYsK/FR72835TDXGGZgwQfOYJu2mRznDU72beNmOlnq6fd BJrTQY32p4LtfQqavUFQo5Q3gSm2/LjsVPFVw0s5gKXGyIjo0Z0YuYZrSjNH511W7b TQhDivsk+lAjmpRdVRvvVfj/Q8Kp8YltRUeUFPfs= Cc: "www-tag@w3.org List" , apps-discuss@ietf.org Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 07:32:08 -0000 > On 4/17/2012 3:15 AM, Julian Reschke wrote: > > On 2012-04-17 02:53, Ned Freed wrote: > >> ... > >> I note that this raises the issue of what to do about fragment > >> identifiers in > >> the initial suffix registry document. Fragment identifiers don't > >> really make > >> sense for most of the suffixes defined there. The exceptions I see are > >> +xml and > >> +json. +json seems simple enough - refer to > >> draft-ietf-appsawg-json-pointer-01. > >> ... > > > > I think that would be premature. > > > > The question has come up several times, and I don't think we are near > > any kind of even rough consensus about whether the spec should try to > > define a fragment identifier syntax for "+json" (or even application/json). > > > >> +xml is a bigger issue. This is a document to populate the registry; > >> it is not > >> the place to define how fragment identifiers for XML work. But RFC > >> 3023 section > >> 5 seems a bit dated. And waiting for a revision for RFC 3023 when > >> there isn't > >> even an I-D doesn't sound like a good idea. So dated or not, I guess a > >> reference to RFC 3023 is as good as it gets for now. > So, I'm revising my draft where I'm actually *registering* a bunch of > these structured suffixes. (draft-hansen-media-type-suffix-reg) > What I'm thinking is that the fragment considerations section for each > should simply point at the base application/whatever specification. That > is, if application/SUFFIX has specific fragment identifiers associated > with it, then anything with +SUFFIX (e.g., application/TYPE+SUFFIX) > should accept the application/SUFFIX fragment identifiers as well as > anything specific to the given media type. The operative term here is "should". There may be very compelling reasons why you want to support fragment identifiers but not the ones that are normally associated with whatever format your media type uses. For example, suppose you defined some sort of structured image representation using XML. It is entirely possible that the elements of that representation are basically worthless when it comes to referencing parts of the image. So it makes no sense to require support for XPointer-based fragment ids in such a case. Even if such fragment ids were useful for, say, some sort of general editing application for XML, they neverthless would place an undue burden on conforming imlementations of that type. > So I've added these Fragment identifier considerations sections to the > suffixes that have an underlying media type registration. > Media types using "+json" MUST accept any fragment identifiers > defined for "application/json". Specific media types may > identify additional fragment identifier considerations. I like the overall idea but, per the above, MUST is too strong. SHOULD is appropriate here, and I'd capitalize the may in the second sentence. > I have similar text for +fastinfoset, +wbxml and +zip. > This way, the definition of fragment identifiers for application/json > can progress at its own pace, as can any definitions of fragment > identifiers for application/fastinfoset, application/vnd.wap.wbxml and > application/zip. Yes, this is very clever, and entirely apporpriate for an initial registry content document. This is not the place to be defining default fragment identifier mechanisms for suffixes. Doing so is going to require a lot of work, and I expect a fair bit of contention for some of them. > In addition, I'm thinking draft-hansen-media-type-suffix-reg should have > an IANA considerations note to add the Fragment identifier > considerations section for +xml, with text similar to the above. Agreed. Ned From internet-drafts@ietf.org Fri Apr 20 01: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 413DC21F85D6; Fri, 20 Apr 2012 01:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8Wk85NkKefy; Fri, 20 Apr 2012 01:10:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C2621F858E; Fri, 20 Apr 2012 01:10:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120420081043.24043.60587.idtracker@ietfa.amsl.com> Date: Fri, 20 Apr 2012 01:10:43 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-02.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, 20 Apr 2012 08:10:44 -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 Worki= ng Group of the IETF. Title : Forwarded HTTP Extension Author(s) : Andreas Petersson Martin Nilsson Filename : draft-ietf-appsawg-http-forwarded-02.txt Pages : 12 Date : 2012-04-20 This document standardizes an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, e.g., the originating IP address of a request or IP number of the proxy on the user-agent facing interface. Given a trusted path of proxying components, this makes it possible to arrange so that each subsequent component will have access to e.g., all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-http-forwarded-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-http-forwarded-02.txt From pelle@kodfabrik.se Fri Apr 20 01: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 532FC21F867C for ; Fri, 20 Apr 2012 01:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bc+dnRUMNNRz for ; Fri, 20 Apr 2012 01:17:48 -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 6FF9021F8670 for ; Fri, 20 Apr 2012 01:17:46 -0700 (PDT) Received: by lbgc1 with SMTP id c1so2907414lbg.31 for ; Fri, 20 Apr 2012 01:17:45 -0700 (PDT) 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 :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=dMTIlWDQaOvtK1v7UmK7YBWE/FSgqsH8cEW4sCA3Ir8=; b=PgfI/x/iFwzUjiXKg7uvhelvEczZ+57EzeK3bODhk/xY6QBiygiQ3A07+1U77QEw+C 5M7AT03jGSxYN+aHNZT5fbhXT7o6XZCm0Me5OU+nYYxGLSCjvZ7K2KTw5LulAlSCGF04 SWUC77CG6pMOrIAxyL2suzIecEeDDEa9E163VDD8R03fhWRNt88g8iQ7EP5EnHiJ83fG 1Z3QmpcWjW58uuPCeDbXDAc/9NVF9f7ZJiCMGL6wvY8GEJeK6/4ylfG9F1vq8q8EHroB rHcucXQ9b70c19XqI+NJPECrw5v/i5z74eFeJPYC2w6ORVXaPBtYlrsYfeBRjCcFHhbd KaIA== Received: by 10.112.100.68 with SMTP id ew4mr2410975lbb.104.1334909865351; Fri, 20 Apr 2012 01:17:45 -0700 (PDT) Received: from [192.168.2.24] (mmx.flattr.net. [95.215.18.2]) by mx.google.com with ESMTPS id pj20sm5000263lab.13.2012.04.20.01.17.42 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Apr 2012 01:17:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Pelle Wessman In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 20 Apr 2012 10:17:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnNQtMbv/gcamJQNh/WPWlJ8dAmgP+WxP6azW0ZttG/WvjvKSMxerbrrWgGfXdcYS3+19gb Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 08:17:49 -0000 You make "updating some servers" sound easy - from eg. an OStatus = perspective that's everything but easy. StatusNet and others = implementations are deployed on a large amount of servers maintained by = a large amount of users - often individuals hosting their own instances. = As I see it it will be challenging for OStatus to support the = specification this discussion results in if it that breaks backwards = compatibility with all existing deployments. I see no reason to make the resource-parameter mandatory - the benefits = that comes with it makes it an obvious choice for everyone that can = support it and those who can't support it can't support it even if we = make the resource-parameter mandatory. I also personally can see a need for being able to host discovery data = statically from eg. an indie-web perspective - the popularity of Jekyll = like systems and Jekyll hosts like GitHub Pages locks up many domains in = hosts that don't support dynamic pages. To be possible to discover any = information about anything on such domains you would need to support eg. = static host-meta documents. A standard that can't be deployed on a = regular persons site is in my opinion a bad standard. While making it mandatory for all new deployments to support JSON I can = see a problem in making new clients expect all responses to be in JSON. = For backwards compatibility it would at least be good to mention the = existence of XML-data in such a way that clients know that that should = expect at least older WebFinger documents to give XML-responses. / Pelle 20 apr 2012 kl. 07:48 skrev Mike Jones: > To be clear, making this mandatory would break no clients. It would = require updating some servers, just as requiring JSON would. This seems = like a fair tradeoff when it makes an appreciable difference in user = interface latency in some important scenarios. If you and the other key = WebFinger supporters can agree to making "resource" support mandatory = and requiring JSON, I believe we may have a path forward. >=20 > Cheers, > -- Mike >=20 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com]=20 > Sent: Thursday, April 19, 2012 10:39 PM > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD) >=20 > That's correct. We could certainly make it mandatory, but the reason = it isn't is to maintain backward compatibility with existing = deployments. >=20 > I think we should always think carefully when we decide to make a = change that breaks backward-compatibility. This is one change that = would do that. >=20 > Paul >=20 >> -----Original Message----- >> From: Mike Jones [mailto:Michael.Jones@microsoft.com] >> Sent: Friday, April 20, 2012 1:10 AM >> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps = Discuss' >> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web=20 >> Discovery >> (SWD) >>=20 >> Currently, support for the "resource" parameter is optional, as per=20= >> the following (correct?): >>=20 >> Note that support for the "resource" parameter is optional, but >> strongly RECOMMENDED for improved performance. If a server does = not >> implement the "resource" parameter, then the server's host metadata >> processing logic remains unchanged from RFC 6415. >>=20 >> To truly support 1, this would need to be changed to REQUIRED, = correct? >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Paul E. Jones [mailto:paulej@packetizer.com] >> Sent: Thursday, April 19, 2012 8:16 PM >> To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' >> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web=20 >> Discovery >> (SWD) >>=20 >> Mike, >>=20 >>> There are two criteria that I would consider to be essential=20 >>> requirements for any resulting general-purpose discovery = specification: >>>=20 >>> 1. Being able to always discover per-user information with a single=20= >>> GET (minimizing user interface latency for mobile devices, etc.) >>=20 >> WF can do that. See: >> $ curl -v https://packetizer.com/.well-known/\ >> host-meta.json?resource=3Dacct:paulej@packetizer.com >>=20 >>> 2. JSON should be required and it should be the only format=20 >>> required (simplicity and ease of deployment/adoption) >>=20 >> See the above example. However, I also support XML with my server. =20= >> It took me less than 10 minutes to code up both XML and JSON = representations. >> Once the requested format is determined, the requested URI is=20 >> determined, data is pulled from the database, spitting out the = desired=20 >> format is trivial. >>=20 >> Note, and very important note: supporting both XML and JSON would = only=20 >> be a server-side requirement. The client is at liberty to use the=20 >> format it prefers. I would agree that forcing a client to support=20 >> both would be unacceptable, but the server? Nothing to it. >>=20 >>> SWD already meets those requirements. If the resulting spec meets=20= >>> those requirements, it doesn't matter a lot whether we call it=20 >>> WebFinger or Simple Web Discovery, but I believe that the=20 >>> requirements discussion is probably the most productive one to be=20 >>> having at this point - not the starting point document. >>=20 >> I believe WebFinger meets those requirements. We could debate = whether=20 >> XML should be supported, but I'll note (again) that it is there in = RFC 6415. >> That document isn't all that old and, frankly, it concerns me that we=20= >> would have a strong preference for format A one week and then Format = B=20 >> the next. >> We are where we are and I can see reason for asking for JSON, but no=20= >> good reason to say we should not allow XML (on the server side). >>=20 >> Paul >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From julian.reschke@gmx.de Fri Apr 20 01:56: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 AA38721F8568 for ; Fri, 20 Apr 2012 01:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.894 X-Spam-Level: X-Spam-Status: No, score=-102.894 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brpHhETNu2Ui for ; Fri, 20 Apr 2012 01:56:47 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D187E21F868A for ; Fri, 20 Apr 2012 01:56:44 -0700 (PDT) Received: (qmail invoked by alias); 20 Apr 2012 08:50:03 -0000 Received: from p57A6D903.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.217.3] by mail.gmx.net (mp072) with SMTP; 20 Apr 2012 10:50:03 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19QrqtClmRQMjkoIiK1gYuR8iXNJVyIaPhgrEhFpt NPaeq4L1jW+3vI Message-ID: <4F91233A.1000603@gmx.de> Date: Fri, 20 Apr 2012 10:50:02 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Tony Hansen References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> In-Reply-To: <4F901485.20800@maillennium.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "www-tag@w3.org List" , apps-discuss@ietf.org Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 08:56:48 -0000 On 2012-04-19 15:35, Tony Hansen wrote: > ... > So I've added these Fragment identifier considerations sections to the > suffixes that have an underlying media type registration. > > Media types using "+json" MUST accept any fragment identifiers > defined for "application/json". Specific media types may > identify additional fragment identifier considerations. > ... Maybe, to avoid confusion, point out that at the time of publication, there was no fragment identifier syntax for JSON... Best regards, Julian From ht@inf.ed.ac.uk Fri Apr 20 02:09:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C960721F87B2 for ; Fri, 20 Apr 2012 02:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11vDoF621-Py for ; Fri, 20 Apr 2012 02:09:41 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 914C521F879B for ; Fri, 20 Apr 2012 02:09:40 -0700 (PDT) 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 q3K99MgC001341; Fri, 20 Apr 2012 10:09:27 +0100 (BST) 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 q3K99MOw031064; Fri, 20 Apr 2012 10:09:22 +0100 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 q3K99Mn8009853; Fri, 20 Apr 2012 10:09:22 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3K99Ltw009849; Fri, 20 Apr 2012 10:09:21 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Tony Hansen References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 20 Apr 2012 10:09:21 +0100 In-Reply-To: <4F901485.20800@maillennium.att.com> (Tony Hansen's message of "Thu, 19 Apr 2012 09:35:01 -0400") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (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: "www-tag@w3.org List" , apps-discuss@ietf.org Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 09:09:41 -0000 Tony Hansen writes: > So, I'm revising my draft where I'm actually *registering* a bunch of > these structured suffixes. (draft-hansen-media-type-suffix-reg) > > What I'm thinking is that the fragment considerations section for each > should simply point at the base application/whatever > specification. That is, if application/SUFFIX has specific fragment > identifiers associated with it, then anything with +SUFFIX (e.g., > application/TYPE+SUFFIX) should accept the application/SUFFIX fragment > identifiers as well as anything specific to the given media type. > > So I've added these Fragment identifier considerations sections to the > suffixes that have an underlying media type registration. > > Media types using "+json" MUST accept any fragment identifiers > defined for "application/json". Specific media types may > identify additional fragment identifier considerations. > > I have similar text for +fastinfoset, +wbxml and +zip. > > In addition, I'm thinking draft-hansen-media-type-suffix-reg should > have an IANA considerations note to add the Fragment identifier > considerations section for +xml, with text similar to the above. If you go in that direction, please consider the fact that 3023bis _is_ once again under active development, with W3C TAG cooperation, and that something very similar to the following (slightly adapted from the previous editors' draft) will likely appear therein: When a new media type is introduced for an XML-based format, the name of the media type SHOULD end with '+xml'. This convention will allow applications that can process XML generically to detect that the MIME entity is supposed to be an XML document, verify this assumption by invoking some XML processor, and then process the XML document accordingly. Applications may match for types that represent XML MIME entities by comparing the subtype to the pattern '*/*+xml'. XML generic processing is not always appropriate for XML-based media types. For example, authors of some such media types may wish that the types remain entirely opaque except to applications that are specifically designed to deal with that media type. By NOT following the naming convention '+xml', such media types can avoid XML-generic processing. Since generic processing will be useful in many cases, however -- including in some situations that are difficult to predict ahead of time -- those registering media types SHOULD use the '+xml' convention unless they have a particularly compelling reason not to. [1] Note that these paragraphs address _more_ than just fragment identifiers. The level of "generic processing", i.e. processing appropriate to any member of a stuctured-syntax family identified by a +SUFFIX, is I think the appropriate one at which to address the mutual dependency between app/foo and app/bar+foo. ht [1] http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From melvincarvalho@gmail.com Fri Apr 20 07:44: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 1FCBF21F872B; Fri, 20 Apr 2012 07:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTVzThsu0pk8; Fri, 20 Apr 2012 07:44:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC9121F872A; Fri, 20 Apr 2012 07:44:30 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7613430vbb.31 for ; Fri, 20 Apr 2012 07:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2V+R8pNJm2ZGvE8f3fJZJ2gYUWKiOtclUc4urSw3Ja0=; b=gPTWBDlZjBKUisvyglhBKNeADehiSzUA+RIuqkHJw+96V6wYV9lJq5ll18FeMckHb4 YX6Cg+ReSh83uJ9d70yZ6XSZvlfGMhQwp4ZWgvwK3nsc4GNRTN/qunxyyXVT6+lS5Bf2 jkqrI16Jwmro/AlCHuODs3GFxGl3dR9qc7wRyzr5ZpErP3FWFHfQxhtz5C/IvXs98l4W a796zAveRZrmjxH+FbGaZBLRRlbjZQUMk3o6dcs676JjOnf/CUAbow+1VvDe1nuvIIFa G+L9FLqmbE1HUxzKpHDGDe4nimrv2dhagye0dgv3kQ9bZPA1te3y2BqPG/MQLRJcF0Wi DANw== MIME-Version: 1.0 Received: by 10.52.95.147 with SMTP id dk19mr4166162vdb.106.1334933069752; Fri, 20 Apr 2012 07:44:29 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Fri, 20 Apr 2012 07:44:29 -0700 (PDT) In-Reply-To: <4F917545.5080103@mtcc.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> <4F917545.5080103@mtcc.com> Date: Fri, 20 Apr 2012 16:44:29 +0200 Message-ID: From: Melvin Carvalho To: Michael Thomas Content-Type: multipart/alternative; boundary=20cf3071d0b66be78804be1d53e8 Cc: Derek Atkins , oauth@ietf.org, Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 14:44:31 -0000 --20cf3071d0b66be78804be1d53e8 Content-Type: text/plain; charset=ISO-8859-1 On 20 April 2012 16:40, Michael Thomas wrote: > On 04/20/2012 07:17 AM, Derek Atkins wrote: > >> Paul, >> >> "Paul E. Jones" writes: >> >> Tim, >>> >>> I do not agree that it's harmful. If I removed the WF discussion off the >>> table, I'm still having a hard time buying into everything you said in >>> the >>> blog post. >>> >>> I implement various web services, largely for my own use. Usually, I >>> implement all of them in XML, JSON, plain text (attribute/value pairs), >>> AND >>> JavaScript (for JSONP). For simple services, it's not hard. I do it >>> because I sometimes have different wants/desires on the client side. >>> (For >>> more complex ones, I use XML.) >>> >> As an individual (and not the chair of OAUTH) I believe that the server >> should be allowed, no encouraged, to support multiple formats for data >> retrieval. I also believe that clients should be allowed to choose only >> one. I am fine with JSON being Mandatory to Implement. I am NOT okay >> with making it the only one, and I am even less okay with mandating it >> is the ONLY one. I would say MUST JSON, MUST (or possibly SHOULD -- you >> can convince me either way) XML, and MAY for anything else that people >> feel stronly about (although I feel in 2012 XML and JSON are the two >> best). I also feel it is okay to say that a client MUST implement one >> of JSON or XML, and MAY implement more. >> >> >> > Why not MUST ASN.1 while you're at it? JSON has won in case > you'all haven't noticed it. > +1 Also bear in mind that when people say "XML" here, it's a specific subset of XML namely "application/xrd+xml". > Mike > > ______________________________**_________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/**listinfo/oauth > --20cf3071d0b66be78804be1d53e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 20 April 2012 16:40, Michael Thomas <= span dir=3D"ltr"><mike@mtcc.com>= wrote:
On 04/20/2012 07:17 AM, Derek Atkins wrote:
Paul,

"Paul E. Jones"<paulej@packetizer.com> =A0writes:

Tim,

I do not agree that it's harmful. If I removed the WF discussion off th= e
table, I'm still having a hard time buying into everything you said in = the
blog post.

I implement various web services, largely for my own use. =A0Usually, I
implement all of them in XML, JSON, plain text (attribute/value pairs), AND=
JavaScript (for JSONP). =A0For simple services, it's not hard. =A0I do = it
because I sometimes have different wants/desires on the client side. =A0(Fo= r
more complex ones, I use XML.)
As an individual (and not the chair of OAUTH) I believe that the server
should be allowed, no encouraged, to support multiple formats for data
retrieval. =A0I also believe that clients should be allowed to choose only<= br> one. =A0I am fine with JSON being Mandatory to Implement. =A0I am NOT okay<= br> with making it the only one, and I am even less okay with mandating it
is the ONLY one. =A0I would say MUST JSON, MUST (or possibly SHOULD -- you<= br> can convince me either way) XML, and MAY for anything else that people
feel stronly about (although I feel in 2012 XML and JSON are the two
best). =A0I also feel it is okay to say that a client MUST implement one of JSON or XML, and MAY implement more.



Why not MUST ASN.1 while you're at it? JSON has won in case
you'all haven't noticed it.

+1

Als= o bear in mind that when people say "XML" here, it's a specif= ic subset of XML namely "application/xrd+xml".=A0


Mike

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--20cf3071d0b66be78804be1d53e8-- From wmills@yahoo-inc.com Fri Apr 20 07:45: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 7A27721F872A for ; Fri, 20 Apr 2012 07:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.076 X-Spam-Level: X-Spam-Status: No, score=-17.076 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCknyXyCcdnx for ; Fri, 20 Apr 2012 07:45:24 -0700 (PDT) Received: from nm7-vm1.bullet.mail.ne1.yahoo.com (nm7-vm1.bullet.mail.ne1.yahoo.com [98.138.90.250]) by ietfa.amsl.com (Postfix) with SMTP id 34FE421F8764 for ; Fri, 20 Apr 2012 07:45:24 -0700 (PDT) Received: from [98.138.90.56] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 20 Apr 2012 14:45:23 -0000 Received: from [98.138.89.194] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 20 Apr 2012 14:45:23 -0000 Received: from [127.0.0.1] by omp1052.mail.ne1.yahoo.com with NNFMP; 20 Apr 2012 14:45:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 857646.83011.bm@omp1052.mail.ne1.yahoo.com Received: (qmail 66981 invoked by uid 60001); 20 Apr 2012 14:45:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334933123; bh=5RHkXY/BmJVZ7JLRRHQGc7cRREIIW+Cg2HZAwEat2kU=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=tZMTVgnUv+RRzNcXCUmeUY/JYVys5WTXvWWV5q04plGBBCmGz8e77XlPCKBvXe6fbj7tIOSPedlWI8p5FTcTLWvOSAT60TZN+cXV6F2pzQUMeBKNE70+wQmUi2hLP6lvmEq+sEaabZqiPjWfdhjjV5IWOp4zfg5vIKLSoCwTujc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=OovIvBJLbumVCatWVhVi0k8AEp1tpZYV1ye+EjCKDX/wNiy4qmpQyFGg+xs/M1+WbAAFwwHQc/uo5NyY0ytOCRLh9YslPtP480uZHKAa69rlNHrw8I46ckru28nQ45JpEf8AE72uFaieUt+ZA+VlXsop4Xt2boSl7B82vf4HJ5w=; X-YMail-OSG: LOjKxvkVM1kqXD5BDqKzbH2e8IalOMyIzPEHK2KJmFuQF14 MukCJ1Z_KjgicGtiUDSnWwLIZ8mld5jVrb2iNyCPaGpwoiwKJrJEOKm1_d6g Vu2TxOTNhp3tdGGdkQV3KsHbF7uuMPn_i.KJQo2Jl_4qG8Ad_YYvBYLpi1Re rRm9A8ZvXiHM9K59W34pw7RBX9USNDV5J4pNn6muSnZN_1wN777a2k1AC6By 7IpZOg_m.G2SrkiNh6Ih1E0FHeJIuh8yiz1UVmqZiuTdApT5WM3BrjNnugvV vCCKTe5n.xXiTMgyTxXS7l2ISvOnQ_r0_iLYbl865jTaaAb5f4e9mgPY1BAw P5MHgWXDANlNAgKkKWM52QKBfi_WlLP2Woq_wKSIT.M0X5ahsuW1NP1gR0MY ZDf360UN_MDBFqYtwNmc5cA.wTXFKvA-- Received: from [99.31.212.42] by web31803.mail.mud.yahoo.com via HTTP; Fri, 20 Apr 2012 07:45:23 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> Message-ID: <1334933123.53510.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Fri, 20 Apr 2012 07:45:23 -0700 (PDT) From: William Mills To: Mike Jones , "Paul E. Jones" , "'Murray S. Kucherawy'" , "oauth@ietf.org" , 'Apps Discuss' In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1502656925-681895590-1334933123=:53510" Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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, 20 Apr 2012 14:45:25 -0000 --1502656925-681895590-1334933123=:53510 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So you are guaranteeing that there are no clients using WF today?=A0 =0A=0A= =0A=0A=0A>________________________________=0A> From: Mike Jones =0A>To: Paul E. Jones ; 'Murray S.= Kucherawy' ; "oauth@ietf.org" ; 'Apps D= iscuss' =0A>Sent: Thursday, April 19, 2012 10:48 PM= =0A>Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discov= ery (SWD)=0A> =0A>To be clear, making this mandatory would break no clients= .=A0 It would require updating some servers, just as requiring JSON would.= =A0 This seems like a fair tradeoff when it makes an appreciable difference= in user interface latency in some important scenarios.=A0 If you and the o= ther key WebFinger supporters can agree to making "resource" support mandat= ory and requiring JSON, I believe we may have a path forward.=0A>=0A>=A0=A0= =A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 Cheers,=0A>=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 = =A0=A0=A0 -- Mike=0A>=0A>-----Original Message-----=0A>From: Paul E. Jones = [mailto:paulej@packetizer.com] =0A>Sent: Thursday, April 19, 2012 10:39 PM= =0A>To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss'= =0A>Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discov= ery (SWD)=0A>=0A>That's correct.=A0 We could certainly make it mandatory, b= ut the reason it isn't is to maintain backward compatibility with existing = deployments.=0A>=0A>I think we should always think carefully when we decide= to make a change that breaks backward-compatibility.=A0 This is one change= that would do that.=0A>=0A>Paul=0A>=0A>> -----Original Message-----=0A>> F= rom: Mike Jones [mailto:Michael.Jones@microsoft.com]=0A>> Sent: Friday, Apr= il 20, 2012 1:10 AM=0A>> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ie= tf.org; 'Apps Discuss'=0A>> Subject: RE: [apps-discuss] [OAUTH-WG] Web Fing= er vs. Simple Web =0A>> Discovery=0A>> (SWD)=0A>> =0A>> Currently, support = for the "resource" parameter is optional, as per =0A>> the following (corre= ct?):=0A>> =0A>>=A0 =A0 Note that support for the "resource" parameter is o= ptional, but=0A>>=A0 =A0 strongly RECOMMENDED for improved performance.=A0 = If a server does not=0A>>=A0 =A0 implement the "resource" parameter, then t= he server's host metadata=0A>>=A0 =A0 processing logic remains unchanged fr= om RFC 6415.=0A>> =0A>> To truly support 1, this would need to be changed t= o REQUIRED, correct?=0A>> =0A>> =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- = Mike=0A>> =0A>> -----Original Message-----=0A>> From: Paul E. Jones [mailto= :paulej@packetizer.com]=0A>> Sent: Thursday, April 19, 2012 8:16 PM=0A>> To= : Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss'=0A>> Su= bject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web =0A>> Discov= ery=0A>> (SWD)=0A>> =0A>> Mike,=0A>> =0A>> > There are two criteria that I = would consider to be essential =0A>> > requirements for any resulting gener= al-purpose discovery specification:=0A>> >=0A>> > 1.=A0 Being able to alway= s discover per-user information with a single =0A>> > GET (minimizing user = interface latency for mobile devices, etc.)=0A>> =0A>> WF can do that.=A0 S= ee:=0A>> $ curl -v https://packetizer.com/.well-known/\=0A>>=A0 =A0 =A0 =A0= =A0 host-meta.json?resource=3Dacct:paulej@packetizer.com=0A>> =0A>> > 2.= =A0 JSON should be required and it should be the only format =0A>> > requir= ed (simplicity and ease of deployment/adoption)=0A>> =0A>> See the above ex= ample.=A0 However, I also support XML with my server.=A0 =0A>> It took me l= ess than 10 minutes to code up both XML and JSON representations.=0A>> Once= the requested format is determined, the requested URI is =0A>> determined,= data is pulled from the database, spitting out the desired =0A>> format is= trivial.=0A>> =0A>> Note, and very important note: supporting both XML and= JSON would only =0A>> be a server-side requirement.=A0 The client is at li= berty to use the =0A>> format it prefers.=A0 I would agree that forcing a c= lient to support =0A>> both would be unacceptable, but the server?=A0 Nothi= ng to it.=0A>> =0A>> > SWD already meets those requirements.=A0 If the resu= lting spec meets =0A>> > those requirements, it doesn't matter a lot whethe= r we call it =0A>> > WebFinger or Simple Web Discovery, but I believe that = the =0A>> > requirements discussion is probably the most productive one to = be =0A>> > having at this point - not the starting point document.=0A>> =0A= >> I believe WebFinger meets those requirements.=A0 We could debate whether= =0A>> XML should be supported, but I'll note (again) that it is there in R= FC 6415.=0A>> That document isn't all that old and, frankly, it concerns me= that we =0A>> would have a strong preference for format A one week and the= n Format B =0A>> the next.=0A>> We are where we are and I can see reason fo= r asking for JSON, but no =0A>> good reason to say we should not allow XML = (on the server side).=0A>> =0A>> Paul=0A>> =0A>> =0A>> =0A>=0A>=0A>=0A>=0A>= _______________________________________________=0A>OAuth mailing list=0A>OA= uth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A> --1502656925-681895590-1334933123=:53510 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
So you are guaranteeing that there are no clients using WF today?  <= br>

From:<= /b> Mike Jones <Michael.Jones@microsoft.com>
To: Paul E. Jones <paulej@packetizer.com>= ;; 'Murray S. Kucherawy' <msk@cloudmark.com>; "oauth@ietf.org" <oa= uth@ietf.org>; 'Apps Discuss' <apps-discuss@ietf.org>
Sent: Thursday, April 19, 2012 10:= 48 PM
Subject: Re: [OA= UTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)

To be clear, making this mandatory would break no clients.&nbs= p; It would require updating some servers, just as requiring JSON would.&nb= sp; This seems like a fair tradeoff when it makes an appreciable difference= in user interface latency in some important scenarios.  If you and th= e other key WebFinger supporters can agree to making "resource" support man= datory and requiring JSON, I believe we may have a path forward.

&nb= sp;               Ch= eers,
             &nb= sp;  -- Mike

-----Original Message-----
From: Paul E. Jones = [mailto:paulej@packetizer.com]
Sent:= Thursday, April 19, 2012 10:39 PM
To: Mike Jones; 'Murray S. Kucherawy'= ; oauth= @ietf.org; 'Apps Discuss'
Subject: RE: [apps-discuss] [OAUTH-WG] Web= Finger vs. Simple Web Discovery (SWD)

That's correct.  We coul= d certainly make it mandatory, but the reason it isn't is to maintain backw= ard compatibility with existing deployments.

I think we should alway= s think carefully when we decide to make a change that breaks backward-comp= atibility.  This is one change that would do that.

Paul

= > -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Friday, April 20, 2= 012 1:10 AM
> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@iet= f.org; 'Apps Discuss'
> Subject: RE: [apps-discuss] [OAUTH-WG] We= b Finger vs. Simple Web
> Discovery
> (SWD)
>
> C= urrently, support for the "resource" parameter is optional, as per
>= the following (correct?):
>
>    Note that support = for the "resource" parameter is optional, but
>    strongly= RECOMMENDED for improved performance.  If a server does not
>&n= bsp;   implement the "resource" parameter, then the server's host meta= data
>    processing logic remains unchanged from RFC 6415.=
>
> To truly support 1, this would need to be changed to REQU= IRED, correct?
>
>          = ;       -- Mike
>
> -----Original Mes= sage-----
> From: Paul E. Jones [mailto:paulej@packetizer.com]
> Sent: Thursday, April 19, 2012 8:16= PM
> To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discu= ss'
> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple We= b
> Discovery
> (SWD)
>
> Mike,
>
> = > There are two criteria that I would consider to be essential
> = > requirements for any resulting general-purpose discovery specification= :
> >
> > 1.  Being able to always discover per-user= information with a single
> > GET (minimizing user interface lat= ency for mobile devices, etc.)
>
> WF can do that.  See:<= br>> $ curl -v https://packetizer.com/.well-known/\
>    &= nbsp;     host-meta.json?resource=3Dacct:paulej@packetizer.com=
>
> > 2.  JSON should be required and it should b= e the only format
> > required (simplicity and ease of deployment= /adoption)
>
> See the above example.  However, I also su= pport XML with my server. 
> It took me less than 10 minutes to= code up both XML and JSON representations.
> Once the requested form= at is determined, the requested URI is
> determined, data is pulled = from the database, spitting out the desired
> format is trivial.
= >
> Note, and very important note: supporting both XML and JSON w= ould only
> be a server-side requirement.  The client is at lib= erty to use the
> format it prefers.  I would agree that forcin= g a client to support
> both would be unacceptable, but the server?  Nothing to it.
>
> > SWD already meets those= requirements.  If the resulting spec meets
> > those requir= ements, it doesn't matter a lot whether we call it
> > WebFinger = or Simple Web Discovery, but I believe that the
> > requirements = discussion is probably the most productive one to be
> > having a= t this point - not the starting point document.
>
> I believe = WebFinger meets those requirements.  We could debate whether
> = XML should be supported, but I'll note (again) that it is there in RFC 6415= .
> That document isn't all that old and, frankly, it concerns me tha= t we
> would have a strong preference for format A one week and then= Format B
> the next.
> We are where we are and I can see reas= on for asking for JSON, but no
> good reason to say we should not al= low XML (on the server side).
>
> Paul
>
>
>




_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/list= info/oauth


--1502656925-681895590-1334933123=:53510-- From duck@kronkltd.net Fri Apr 20 08:09: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 EBA6721F878E for ; Fri, 20 Apr 2012 08:08:59 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5FOrhrpq9hO for ; Fri, 20 Apr 2012 08:08:58 -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 1BF7121F876D for ; Fri, 20 Apr 2012 08:08:57 -0700 (PDT) Received: by lbgc1 with SMTP id c1so3214577lbg.31 for ; Fri, 20 Apr 2012 08:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kronkltd.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ESOI79YE9OcmZleClSG7tO/QB7+Eko5Q06rZuqjLiZM=; b=JBGu2HEDxkeH3XJvz/2Q3FitMobgo7x6opbGhyJbnyq22j440wZN8loT7du3YVi0C9 VGpuB8Tlyn6w4Cd3VyfZ1Y6lLNgiptJhGClSTmwW6XCQqfa8hDPuOa/iCoSg3n7Elp4E qkaqfqca+w038/tjhmXVga1bdPQGDefWTL/BQ= 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:content-transfer-encoding:x-gm-message-state; bh=ESOI79YE9OcmZleClSG7tO/QB7+Eko5Q06rZuqjLiZM=; b=B52ieKCaexYU7X1O4bOxxr9Ug1RSoauBctIgOzAFILNnrtvER7HIW5YYwEUcEXUSrb PAsI6fjLfAqqIRQ7wAIc751D/0eq1+8cduO10ADNF8Wr3wvxasejcUIE3lFWhPWhG4BS Dnlm3T4xTsdV8UVWHro7fT06wut/xO5ICbuw3mKz4yCM9ezkKOGGIknsFTf/CfvGgWrc PYQFqfuQHodGNro013FH/0/B3ugk2GH6sIfmYsKUMaFEN08tI4JOw9ZAbxb0pXotKKB7 ZDZFEmuDoRf5DTjS/QiBoGEvgwJ7NVT1FUg2qhwS1vbyrdKi8RRo8ea9lZeUSSebht96 uAJA== Received: by 10.152.145.135 with SMTP id su7mr3903416lab.5.1334934536710; Fri, 20 Apr 2012 08:08:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.128.41 with HTTP; Fri, 20 Apr 2012 08:08:34 -0700 (PDT) In-Reply-To: <1334933123.53510.YahooMailNeo@web31803.mail.mud.yahoo.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <1334933123.53510.YahooMailNeo@web31803.mail.mud.yahoo.com> From: Daniel Renfer Date: Fri, 20 Apr 2012 11:08:34 -0400 Message-ID: To: William Mills Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlbhRqcYyDm5bD2HVkEVFJ2V5T5W+gXpCv5blvXnFefgcUlvx7kYw/WvSoc/FDODovkqWCS Cc: "oauth@ietf.org" , Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 15:09:00 -0000 The point is that existing WF clients have been written to not use the resource parameter because in the past, that parameter hasn't been available or hasn't been reliable. If the resource parameter is required, this older method of fetching the host meta and constructing the url to fetch the user meta would still continue to work just as before. Even if the resource parameter were made mandatory today, real world WF clients would still have to account for the possibility of resource queries resulting in an error or incorrect information. Given the number of currently deployed WF-enabled services and the difficulty in upgrading all of them, this is going to be the case for some time. resource parameters should be strongly encouraged, but not required. On Fri, Apr 20, 2012 at 10:45 AM, William Mills wrot= e: > So you are guaranteeing that there are no clients using WF today? > > ________________________________ > From: Mike Jones > To: Paul E. Jones ; 'Murray S. Kucherawy' > ; "oauth@ietf.org" ; 'Apps Discuss' > > Sent: Thursday, April 19, 2012 10:48 PM > Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discover= y > (SWD) > > To be clear, making this mandatory would break no clients.=C2=A0 It would= require > updating some servers, just as requiring JSON would.=C2=A0 This seems lik= e a fair > tradeoff when it makes an appreciable difference in user interface latenc= y > in some important scenarios.=C2=A0 If you and the other key WebFinger sup= porters > can agree to making "resource" support mandatory and requiring JSON, I > believe we may have a path forward. > > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 Cheers, > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 -- Mike > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Thursday, April 19, 2012 10:39 PM > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discover= y > (SWD) > > That's correct.=C2=A0 We could certainly make it mandatory, but the reaso= n it > isn't is to maintain backward compatibility with existing deployments. > > I think we should always think carefully when we decide to make a change > that breaks backward-compatibility.=C2=A0 This is one change that would d= o that. > > Paul > >> -----Original Message----- >> From: Mike Jones [mailto:Michael.Jones@microsoft.com] >> Sent: Friday, April 20, 2012 1:10 AM >> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' >> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web >> Discovery >> (SWD) >> >> Currently, support for the "resource" parameter is optional, as per >> the following (correct?): >> >>=C2=A0 =C2=A0 Note that support for the "resource" parameter is optional,= but >>=C2=A0 =C2=A0 strongly RECOMMENDED for improved performance.=C2=A0 If a s= erver does not >>=C2=A0 =C2=A0 implement the "resource" parameter, then the server's host = metadata >>=C2=A0 =C2=A0 processing logic remains unchanged from RFC 6415. >> >> To truly support 1, this would need to be changed to REQUIRED, correct? >> >> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 -- Mike >> >> -----Original Message----- >> From: Paul E. Jones [mailto:paulej@packetizer.com] >> Sent: Thursday, April 19, 2012 8:16 PM >> To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' >> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web >> Discovery >> (SWD) >> >> Mike, >> >> > There are two criteria that I would consider to be essential >> > requirements for any resulting general-purpose discovery specification= : >> > >> > 1.=C2=A0 Being able to always discover per-user information with a sin= gle >> > GET (minimizing user interface latency for mobile devices, etc.) >> >> WF can do that.=C2=A0 See: >> $ curl -v https://packetizer.com/.well-known/\ >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 host-meta.json?resource=3Dacct:paulej@= packetizer.com >> >> > 2.=C2=A0 JSON should be required and it should be the only format >> > required (simplicity and ease of deployment/adoption) >> >> See the above example.=C2=A0 However, I also support XML with my server. >> It took me less than 10 minutes to code up both XML and JSON >> representations. >> Once the requested format is determined, the requested URI is >> determined, data is pulled from the database, spitting out the desired >> format is trivial. >> >> Note, and very important note: supporting both XML and JSON would only >> be a server-side requirement.=C2=A0 The client is at liberty to use the >> format it prefers.=C2=A0 I would agree that forcing a client to support >> both would be unacceptable, but the server?=C2=A0 Nothing to it. >> >> > SWD already meets those requirements.=C2=A0 If the resulting spec meet= s >> > those requirements, it doesn't matter a lot whether we call it >> > WebFinger or Simple Web Discovery, but I believe that the >> > requirements discussion is probably the most productive one to be >> > having at this point - not the starting point document. >> >> I believe WebFinger meets those requirements.=C2=A0 We could debate whet= her >> XML should be supported, but I'll note (again) that it is there in RFC >> 6415. >> That document isn't all that old and, frankly, it concerns me that we >> would have a strong preference for format A one week and then Format B >> the next. >> We are where we are and I can see reason for asking for JSON, but no >> good reason to say we should not allow XML (on the server side). >> >> Paul >> >> >> > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From tbray@textuality.com Fri Apr 20 08:12: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 D459E21F8771 for ; Fri, 20 Apr 2012 08:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yGsfRHk0Xv2 for ; Fri, 20 Apr 2012 08:12:13 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C854421F8757 for ; Fri, 20 Apr 2012 08:12:13 -0700 (PDT) Received: by yenm5 with SMTP id m5so6006372yen.31 for ; Fri, 20 Apr 2012 08:12:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=XEDLJ0XtvEUOTF03zrcECRBYf36DRhPQ93V57QhHpu4=; b=f9b4j/onPnpdUA8btRFWCDNwqrcyDlU/k8rKwdrb15lWsfLWlIhPjNaQ0W1TsMcGVD paXQ0s5cKMH0AwOAu6LU35TwjDgOo2mbgNrhjswhDlfyaeMPTJxERQbdNVM/SDyW57Ja MnJC+6uE2P9ycX50ZB9lwdwHMHOi3pwNDviRK5pjYhscd3NtEX4YE2pwzCRUJ+6F1hH+ GxCsOtftaifR+RFejP0fif3O+TYgp5/QfvFSzw3Whn+hYM9QLQWNjURJcdh4x6grh0Dx HuY0xgNjNh9rpvBItxuTtP+ODwa5SBMcBBEanu4dbEbrUBQwfLMM8F7KDtuP0LeQQ8WL 8nPA== MIME-Version: 1.0 Received: by 10.60.0.196 with SMTP id 4mr9397405oeg.0.1334934733294; Fri, 20 Apr 2012 08:12:13 -0700 (PDT) Received: by 10.182.204.71 with HTTP; Fri, 20 Apr 2012 08:12:13 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> Date: Fri, 20 Apr 2012 08:12:13 -0700 Message-ID: From: Tim Bray To: Derek Atkins Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkyOcv5spa/FRXlWVlqOF1FbtrRicOr+xec2XR/EjOgtbYnZ7Rm4b4aI/R4y+XP27WpRvCY Cc: oauth@ietf.org, Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 15:12:15 -0000 There's a disconnect here. Mnot and I (at least) have argued that there are very specific problems and costs associated with going multi-format. I=92ve heard lots of people say "Well, I support multi-format=94 but I haven=92t heard any specific responses explaining why those costs and problems aren=92t real, or why the benefits are sufficiently great that we should just accept them. Mnot: JSON or XML: Just Decide http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide tbray: Case Study: Atom and/or JSON http://www.tbray.org/ongoing/When/200x/2009/04/29/Model-and-Syntax#p-1 Would this work better if I summarized the problems here inline in this thread? It may be the pace that people=92s IETF/email workflow is such that they=92re not able comfortably to consult external references? -Tim On Fri, Apr 20, 2012 at 7:17 AM, Derek Atkins wrote: > Paul, > > "Paul E. Jones" writes: > >> Tim, >> >> I do not agree that it's harmful. If I removed the WF discussion off the >> table, I'm still having a hard time buying into everything you said in t= he >> blog post. >> >> I implement various web services, largely for my own use. =A0Usually, I >> implement all of them in XML, JSON, plain text (attribute/value pairs), = AND >> JavaScript (for JSONP). =A0For simple services, it's not hard. =A0I do i= t >> because I sometimes have different wants/desires on the client side. =A0= (For >> more complex ones, I use XML.) > > As an individual (and not the chair of OAUTH) I believe that the server > should be allowed, no encouraged, to support multiple formats for data > retrieval. =A0I also believe that clients should be allowed to choose onl= y > one. =A0I am fine with JSON being Mandatory to Implement. =A0I am NOT oka= y > with making it the only one, and I am even less okay with mandating it > is the ONLY one. =A0I would say MUST JSON, MUST (or possibly SHOULD -- yo= u > can convince me either way) XML, and MAY for anything else that people > feel stronly about (although I feel in 2012 XML and JSON are the two > best). =A0I also feel it is okay to say that a client MUST implement one > of JSON or XML, and MAY implement more. > > > > Note that this is a replay of the historical "MUST Implement" versus > "MUST Use" arguments. =A0Just because the server MUST IMPLEMENT JSON and > XML does not mean that a Client must use both (or even that a client > must implement both). =A0It is perfectly reasonable and generally > acceptable to have a server that provides data in multiple formats > whereas the client only supports a subset and specifies which format(s) > are acceptable. > > > > -derek > > -- > =A0 =A0 =A0 Derek Atkins =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 617-623-3745 > =A0 =A0 =A0 derek@ihtfp.com =A0 =A0 =A0 =A0 =A0 =A0 www.ihtfp.com > =A0 =A0 =A0 Computer and Internet Security Consultant From ve7jtb@ve7jtb.com Fri Apr 20 08:12: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 DB76D21F87A5 for ; Fri, 20 Apr 2012 08:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KesXvTNtV6lx for ; Fri, 20 Apr 2012 08:12:45 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id C92AD21F879C for ; Fri, 20 Apr 2012 08:12:35 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so787245wib.1 for ; Fri, 20 Apr 2012 08:12:34 -0700 (PDT) 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=QfY2UKM7Xfy9xfvybU6+wIXoda53e/iQoIvFqUH+0OY=; b=fnxuEsDp5+J8kRaA+zZ05SN8YbmAnoA+uwuOWhtniw93TyUj1uLxIeHiX7t+h+SrIE FQ6bo7tRHuk8/R7gmAjsF36J+z2pd4Y8e1ByqNx8sBECEt23u8vObkotIjVfA7GJ2BDt 02Aq1ptgGCDiI+vrzHRKArqiSKfM8PcLT89UaaGgU8kO5h1KlVe8JCSt1rjxBtU+1ZJ1 Srq8+IeKYYJgQufpvFVUg+6ErMagPZmjwKZCjkQcS2o2tr579OHRTwIDbfgy/q0w488N ALxJLYusaniGHnTdu5hrI6kXVC7vMdh4EGzO9cS7ZP9yn3DnZfCFJdxzeJY9KVNF8ayj 0BPw== Received: by 10.216.137.30 with SMTP id x30mr3888264wei.34.1334934754555; Fri, 20 Apr 2012 08:12:34 -0700 (PDT) Received: from [10.140.224.153] ([80.187.201.110]) by mx.google.com with ESMTPS id fl2sm9696842wib.2.2012.04.20.08.12.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Apr 2012 08:12:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_9809CEA2-8BA2-410F-97F7-5AAC15EBD820"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <1334933123.53510.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Fri, 20 Apr 2012 17:12:23 +0200 Message-Id: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <1334933123.53510.YahooMailNeo@web31803.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQn5K82iMC0e5AcJaWSEWPIBf2IE6g9lKXkv+K+ttPUgiMKnzx0I7J/Xp6VJ4d2rUxc7LZ5w Cc: "oauth@ietf.org" , 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 15:12:49 -0000 --Apple-Mail=_9809CEA2-8BA2-410F-97F7-5AAC15EBD820 Content-Type: multipart/alternative; boundary="Apple-Mail=_5AF5B7AE-5CDC-4812-BEF4-B1F65C6F129F" --Apple-Mail=_5AF5B7AE-5CDC-4812-BEF4-B1F65C6F129F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 We are not arguing that XML be removed from the server. Only that JSON = be mandatory for the server to support. Others on the list piled on the removing XML argument. =20 I do think there is a legitimate argument that fewer options make for = better interoperability. However Mike and myself are not the ones making that argument. Only that the server MUST support JSON. The other MUST Mike had was getting the JRD with a single get and not = needing to retrieve the host-meta file first to retrieve the template. That is probably the largest design difference. SWD uses a .well-known location as effectively a static template and = only redirects if necessary. Where as Web Finger assumes the overhead of one extra GET on the first = request to add a configurable template. one compromise and perhaps not the best is to leave the current = host-meta mechanism. Add a new SWD endpoint (fixed-template) in .well-known that provides the = service, or is an alias for the host-mata file. A client could try the SWD endpoint (fixed template first and get a = response in one go, or get back a host meta file and take the template = from that and try again. A redirect might be better as that could be cached. ( open to debate) That would make the happy path discovery for web-finger be one GET and = possibly some people happy. The existing clients would get .well known and get the template as they = do now. The single GET could be considered an optimization. If we pick off the issues one at a time I hope we can find solutions. John B. On 2012-04-20, at 4:45 PM, William Mills wrote: > So you are guaranteeing that there are no clients using WF today? =20 >=20 > From: Mike Jones > To: Paul E. Jones ; 'Murray S. Kucherawy' = ; "oauth@ietf.org" ; 'Apps Discuss' = =20 > Sent: Thursday, April 19, 2012 10:48 PM > Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web = Discovery (SWD) >=20 > To be clear, making this mandatory would break no clients. It would = require updating some servers, just as requiring JSON would. This seems = like a fair tradeoff when it makes an appreciable difference in user = interface latency in some important scenarios. If you and the other key = WebFinger supporters can agree to making "resource" support mandatory = and requiring JSON, I believe we may have a path forward. >=20 > Cheers, > -- Mike >=20 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com]=20 > Sent: Thursday, April 19, 2012 10:39 PM > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD) >=20 > That's correct. We could certainly make it mandatory, but the reason = it isn't is to maintain backward compatibility with existing = deployments. >=20 > I think we should always think carefully when we decide to make a = change that breaks backward-compatibility. This is one change that = would do that. >=20 > Paul >=20 > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Friday, April 20, 2012 1:10 AM > > To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps = Discuss' > > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web=20 > > Discovery > > (SWD) > >=20 > > Currently, support for the "resource" parameter is optional, as per=20= > > the following (correct?): > >=20 > > Note that support for the "resource" parameter is optional, but > > strongly RECOMMENDED for improved performance. If a server does = not > > implement the "resource" parameter, then the server's host = metadata > > processing logic remains unchanged from RFC 6415. > >=20 > > To truly support 1, this would need to be changed to REQUIRED, = correct? > >=20 > > -- Mike > >=20 > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Thursday, April 19, 2012 8:16 PM > > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps = Discuss' > > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web=20 > > Discovery > > (SWD) > >=20 > > Mike, > >=20 > > > There are two criteria that I would consider to be essential=20 > > > requirements for any resulting general-purpose discovery = specification: > > > > > > 1. Being able to always discover per-user information with a = single=20 > > > GET (minimizing user interface latency for mobile devices, etc.) > >=20 > > WF can do that. See: > > $ curl -v https://packetizer.com/.well-known/\ > > host-meta.json?resource=3Dacct:paulej@packetizer.com > >=20 > > > 2. JSON should be required and it should be the only format=20 > > > required (simplicity and ease of deployment/adoption) > >=20 > > See the above example. However, I also support XML with my server. =20= > > It took me less than 10 minutes to code up both XML and JSON = representations. > > Once the requested format is determined, the requested URI is=20 > > determined, data is pulled from the database, spitting out the = desired=20 > > format is trivial. > >=20 > > Note, and very important note: supporting both XML and JSON would = only=20 > > be a server-side requirement. The client is at liberty to use the=20= > > format it prefers. I would agree that forcing a client to support=20= > > both would be unacceptable, but the server? Nothing to it. > >=20 > > > SWD already meets those requirements. If the resulting spec meets=20= > > > those requirements, it doesn't matter a lot whether we call it=20 > > > WebFinger or Simple Web Discovery, but I believe that the=20 > > > requirements discussion is probably the most productive one to be=20= > > > having at this point - not the starting point document. > >=20 > > I believe WebFinger meets those requirements. We could debate = whether=20 > > XML should be supported, but I'll note (again) that it is there in = RFC 6415. > > That document isn't all that old and, frankly, it concerns me that = we=20 > > would have a strong preference for format A one week and then Format = B=20 > > the next. > > We are where we are and I can see reason for asking for JSON, but no=20= > > good reason to say we should not allow XML (on the server side). > >=20 > > Paul > >=20 > >=20 > >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_5AF5B7AE-5CDC-4812-BEF4-B1F65C6F129F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 We = are not arguing that XML be removed from the server.  Only that = JSON be mandatory for the server to support.

Others = on the list piled on the removing XML argument. =   

I do think there is a legitimate = argument that fewer options make for better = interoperability.

However Mike and myself are = not the ones making that argument.

Only that = the server MUST support JSON.

The other MUST = Mike had was getting the JRD with a single get and not needing to = retrieve the host-meta file first to retrieve the = template.

That is probably the largest design = difference.

SWD uses a .well-known location as = effectively a static template and only redirects if = necessary.

Where as Web Finger assumes the = overhead of one extra GET on the first request to add a configurable = template.

one compromise and perhaps not the = best is to leave the current host-meta mechanism.
Add a new = SWD endpoint (fixed-template) in .well-known that provides the service, = or is an alias for the host-mata file.

A client = could try the SWD endpoint (fixed template first and get a response in = one go, or get back a  host meta file and take the template from = that and try again.

A redirect might be better = as that could be cached. ( open to debate)

That = would make the happy path discovery for web-finger be one GET and = possibly some people happy.

The existing = clients would get .well known and get the template as they do = now.

The single GET could be considered an = optimization.

If we pick off the issues one at = a time I hope we can find solutions.

John = B.
On 2012-04-20, at 4:45 PM, William Mills = wrote:

So you are guaranteeing that there = are no clients using WF today?  =

From: Mike Jones <Michael.Jones@microsoft.com>
To: Paul E. = Jones <paulej@packetizer.com>; = 'Murray S. Kucherawy' <msk@cloudmark.com>; "oauth@ietf.org" <oauth@ietf.org>; 'Apps Discuss' = <apps-discuss@ietf.org>=
Sent: Thursday, = April 19, 2012 10:48 PM
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. = Simple Web Discovery (SWD)

To be clear, making = this mandatory would break no clients.  It would require updating = some servers, just as requiring JSON would.  This seems like a fair = tradeoff when it makes an appreciable difference in user interface = latency in some important scenarios.  If you and the other key = WebFinger supporters can agree to making "resource" support mandatory = and requiring JSON, I believe we may have a path = forward.

            =     Cheers,
        =         -- Mike

-----Original = Message-----
From: Paul E. Jones [mailto:paulej@packetizer.com] =
Sent: Thursday, April 19, 2012 10:39 PM
To: Mike Jones; 'Murray = S. Kucherawy'; oauth@ietf.org; 'Apps = Discuss'
Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple = Web Discovery (SWD)

That's correct.  We could certainly make = it mandatory, but the reason it isn't is to maintain backward = compatibility with existing deployments.

I think we should always = think carefully when we decide to make a change that breaks = backward-compatibility.  This is one change that would do = that.

Paul

> -----Original Message-----
> From: = Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Friday, April 20, 2012 1:10 AM
> To: Paul E. = Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps = Discuss'
> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. = Simple Web
> Discovery
> (SWD)
>
> Currently, = support for the "resource" parameter is optional, as per
> the = following (correct?):
>
>    Note that support = for the "resource" parameter is optional, but
>    = strongly RECOMMENDED for improved performance.  If a server does = not
>    implement the "resource" parameter, then the = server's host metadata
>    processing logic remains = unchanged from RFC 6415.
>
> To truly support 1, this would = need to be changed to REQUIRED, correct?
>
> =             =     -- Mike
>
> -----Original = Message-----
> From: Paul E. Jones [mailto:paulej@packetizer.com]
> = Sent: Thursday, April 19, 2012 8:16 PM
> To: Mike Jones; 'Murray = S. Kucherawy'; oauth@ietf.org; 'Apps = Discuss'
> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. = Simple Web
> Discovery
> (SWD)
>
> = Mike,
>
> > There are two criteria that I would consider = to be essential
> > requirements for any resulting = general-purpose discovery specification:
> >
> > = 1.  Being able to always discover per-user information with a = single
> > GET (minimizing user interface latency for mobile = devices, etc.)
>
> WF can do that.  See:
> $ = curl -v https://packetizer.com/.well-known/\
>  =         host-meta.json?resource=3Dacct:paulej@packetizer.com
> =
> > 2.  JSON should be required and it should be the only = format
> > required (simplicity and ease of = deployment/adoption)
>
> See the above example.  = However, I also support XML with my server. 
> It took me = less than 10 minutes to code up both XML and JSON = representations.
> Once the requested format is determined, the = requested URI is
> determined, data is pulled from the database, = spitting out the desired
> format is trivial.
>
> = Note, and very important note: supporting both XML and JSON would only =
> be a server-side requirement.  The client is at liberty to = use the
> format it prefers.  I would agree that forcing a = client to support
> both would be unacceptable, but the server?  Nothing to it.
>
> > SWD already meets = those requirements.  If the resulting spec meets
> > = those requirements, it doesn't matter a lot whether we call it
> = > WebFinger or Simple Web Discovery, but I believe that the
> = > requirements discussion is probably the most productive one to be =
> > having at this point - not the starting point = document.
>
> I believe WebFinger meets those = requirements.  We could debate whether
> XML should be = supported, but I'll note (again) that it is there in RFC 6415.
> = That document isn't all that old and, frankly, it concerns me that we =
> would have a strong preference for format A one week and then = Format B
> the next.
> We are where we are and I can see = reason for asking for JSON, but no
> good reason to say we should = not allow XML (on the server side).
>
> Paul
> =
>
> =




_______________________________________________
OAu= th mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
=
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_5AF5B7AE-5CDC-4812-BEF4-B1F65C6F129F-- --Apple-Mail=_9809CEA2-8BA2-410F-97F7-5AAC15EBD820 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy MDE1MTIyNFowIwYJKoZIhvcNAQkEMRYEFOb8elBHYZycKYE2GdEGeOb9JN55MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACYGed00oUEnCA9KbimsVjdvuAt1ArGWZznyhWWIaxvnIw6k/AH10/P8SbUsDWOlRmejudDmA+Mz 5q9LtRBGIxlklfMSzgaeJSa9bcI6z+Lv0bsTCuwowpnLC8WQ4G4lA6U1TvG1/L7jgM6lIMh0H3YH i9vQ7XarAnuc0G27F18OGe3cDPIV0K+/jVM8BskHQVekdV7YKdqHgYb68YTHFg1ERpCXsLS54T1y pLInlIt8sG3Rk0FILwgh7oE4Hj/zDulHSX8AGzLcN7MUYsSWMf5C+Dk1gXMvBXuET5DyqcxuMD2e Cl1VUNAvQT3mZkAj6hMzE7BV8RZCuHRYPXzwHAoAAAAAAAA= --Apple-Mail=_9809CEA2-8BA2-410F-97F7-5AAC15EBD820-- From derek@ihtfp.com Fri Apr 20 07:18: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 674B821F8764; Fri, 20 Apr 2012 07:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.966 X-Spam-Level: X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCxj+m1JRuQl; Fri, 20 Apr 2012 07:18:06 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id EF44721F8630; Fri, 20 Apr 2012 07:18:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 46C452602A6; Fri, 20 Apr 2012 10:17:59 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 10850-07; Fri, 20 Apr 2012 10:17:58 -0400 (EDT) Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 4971526029C; Fri, 20 Apr 2012 10:17:58 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3KEHrLD031999; Fri, 20 Apr 2012 10:17:53 -0400 From: Derek Atkins To: "Paul E. Jones" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> Date: Fri, 20 Apr 2012 10:17:51 -0400 In-Reply-To: <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> (Paul E. Jones's message of "Fri, 20 Apr 2012 00:43:08 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a X-Mailman-Approved-At: Fri, 20 Apr 2012 08:18:01 -0700 Cc: oauth@ietf.org, 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 14:18:08 -0000 Paul, "Paul E. Jones" writes: > Tim, > > I do not agree that it's harmful. If I removed the WF discussion off the > table, I'm still having a hard time buying into everything you said in the > blog post. > > I implement various web services, largely for my own use. Usually, I > implement all of them in XML, JSON, plain text (attribute/value pairs), AND > JavaScript (for JSONP). For simple services, it's not hard. I do it > because I sometimes have different wants/desires on the client side. (For > more complex ones, I use XML.) As an individual (and not the chair of OAUTH) I believe that the server should be allowed, no encouraged, to support multiple formats for data retrieval. I also believe that clients should be allowed to choose only one. I am fine with JSON being Mandatory to Implement. I am NOT okay with making it the only one, and I am even less okay with mandating it is the ONLY one. I would say MUST JSON, MUST (or possibly SHOULD -- you can convince me either way) XML, and MAY for anything else that people feel stronly about (although I feel in 2012 XML and JSON are the two best). I also feel it is okay to say that a client MUST implement one of JSON or XML, and MAY implement more. Note that this is a replay of the historical "MUST Implement" versus "MUST Use" arguments. Just because the server MUST IMPLEMENT JSON and XML does not mean that a Client must use both (or even that a client must implement both). It is perfectly reasonable and generally acceptable to have a server that provides data in multiple formats whereas the client only supports a subset and specifies which format(s) are acceptable. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From jeni@jenitennison.com Fri Apr 20 03: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 A4B4421F8731 for ; Fri, 20 Apr 2012 03:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgYKbt0aiUs2 for ; Fri, 20 Apr 2012 03:31:55 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 647CB21F8732 for ; Fri, 20 Apr 2012 03:31:54 -0700 (PDT) Received: from [82.132.248.239] (helo=[192.168.43.17]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SLB84-0006qV-4R; Fri, 20 Apr 2012 11:31:52 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jeni Tennison In-Reply-To: <01OEITCHB07U00ZGHB@mauve.mrochek.com> Date: Fri, 20 Apr 2012 11:30:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <02811F06-0325-4A0D-AE0D-3B5AF07EAE97@jenitennison.com> References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> <01OEITCHB07U00ZGHB@mauve.mrochek.com> To: Tony Hansen X-Mailer: Apple Mail (2.1257) X-Mailcore-Auth: 9919842 X-Mailcore-Domain: 1066436 X-Mailman-Approved-At: Fri, 20 Apr 2012 08:18:14 -0700 Cc: Ned Freed , "www-tag@w3.org List" , apps-discuss@ietf.org Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 10:31:56 -0000 Hi Tony, On 20 Apr 2012, at 08:24, Ned Freed wrote: >> So I've added these Fragment identifier considerations sections to = the >> suffixes that have an underlying media type registration. >>=20 >> Media types using "+json" MUST accept any fragment identifiers >> defined for "application/json". Specific media types may >> identify additional fragment identifier considerations. >=20 > I like the overall idea but, per the above, MUST is too strong. SHOULD > is appropriate here, and I'd capitalize the may in the second = sentence. I agree with Ned about softening the wording. The other thing that you = could specifically draw out is that fragment identifiers that are = classed as errors in the media type related to the suffix may be = classified as OK within a specific media type. The other (word-smithing) comment I'd make is that it's not enough for = the specific media type to 'accept' fragment identifiers: they should be = processed in the same way as well. So I'd suggest something like: Media types using "+json" SHOULD process any fragment identifiers defined for "application/json" in the same way as defined for that media type. Specific media types MAY identify additional fragment=20 identifier considerations and MAY define processing for fragment=20 identifiers that are classed as errors for "application/json". Cheers, Jeni --=20 Jeni Tennison http://www.jenitennison.com From mike@mtcc.com Fri Apr 20 07:40: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 DE8F021F872E; Fri, 20 Apr 2012 07:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42utq42v3quz; Fri, 20 Apr 2012 07:40:07 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 6F69921F872A; Fri, 20 Apr 2012 07:40:07 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3KEe5JJ011241 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 20 Apr 2012 07:40:06 -0700 Message-ID: <4F917545.5080103@mtcc.com> Date: Fri, 20 Apr 2012 07:40:05 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Derek Atkins References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1459; t=1334932807; x=1335796807; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20[apps-discuss]=20Web=20Fin ger=20vs.=20Simple=20Web=20Discovery=0A=20(SWD) |Sender:=20 |To:=20Derek=20Atkins=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=/UA98CGbu4CjErtF1sSrI0tBxipwAJn0E33Vv19YiG4=; b=aVeKBYv12mUHcSA07k7KUi/iou4aATYTWV1hMiUVRChxa8T50izYkYhrss /daDC8jh1h+EqT8PiXvV31fooKxYLKgY+dgmlRy5mKkWpV5Ouy053dCAeTJP 0a75S2SzV05zJ1SznSABYUQwn2o69nghFQfSVJ/S1n7S+bGu3KfL8=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com X-Mailman-Approved-At: Fri, 20 Apr 2012 08:18:14 -0700 Cc: oauth@ietf.org, 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 14:40:09 -0000 On 04/20/2012 07:17 AM, Derek Atkins wrote: > Paul, > > "Paul E. Jones" writes: > >> Tim, >> >> I do not agree that it's harmful. If I removed the WF discussion off the >> table, I'm still having a hard time buying into everything you said in the >> blog post. >> >> I implement various web services, largely for my own use. Usually, I >> implement all of them in XML, JSON, plain text (attribute/value pairs), AND >> JavaScript (for JSONP). For simple services, it's not hard. I do it >> because I sometimes have different wants/desires on the client side. (For >> more complex ones, I use XML.) > As an individual (and not the chair of OAUTH) I believe that the server > should be allowed, no encouraged, to support multiple formats for data > retrieval. I also believe that clients should be allowed to choose only > one. I am fine with JSON being Mandatory to Implement. I am NOT okay > with making it the only one, and I am even less okay with mandating it > is the ONLY one. I would say MUST JSON, MUST (or possibly SHOULD -- you > can convince me either way) XML, and MAY for anything else that people > feel stronly about (although I feel in 2012 XML and JSON are the two > best). I also feel it is okay to say that a client MUST implement one > of JSON or XML, and MAY implement more. > > Why not MUST ASN.1 while you're at it? JSON has won in case you'all haven't noticed it. Mike From mike@mtcc.com Fri Apr 20 08:12: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 F21F421F87B9; Fri, 20 Apr 2012 08:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpmiMAoPEkvz; Fri, 20 Apr 2012 08:12:45 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 66EF421F87A5; Fri, 20 Apr 2012 08:12:45 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3KFCcFx024031 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 20 Apr 2012 08:12:38 -0700 Message-ID: <4F917CE6.2060904@mtcc.com> Date: Fri, 20 Apr 2012 08:12:38 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Derek Atkins References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1149; t=1334934759; x=1335798759; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20[apps-discuss]=20Web=20Fin ger=20vs.=20Simple=20Web=20Discovery=0A=20(SWD) |Sender:=20 |To:=20Derek=20Atkins=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=gumPh5+dRN4yReAgLh6SWnugtflqzOpFSFW6RL+cqfw=; b=fdI4Qsoh6z0Jv9Xg4oOqQeQgYUhDIDaWrdy1YtNAASkKvnkS3MSi+fiZSl XOT+cRNl8vsrP/SjtPSSKrSKyjwLPyJCaY9Z20U5dseF0vfXR7crjB8Sj6fB ZrfdW0TOujLrZjBbNekx0ip1S1x1cloL4YByVHqCq9clQ8etcOZlo=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com X-Mailman-Approved-At: Fri, 20 Apr 2012 08:18:14 -0700 Cc: oauth@ietf.org, 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 15:12:49 -0000 On 04/20/2012 07:17 AM, Derek Atkins wrote: > Note that this is a replay of the historical "MUST Implement" versus "MUST Use" arguments. Just because the server MUST IMPLEMENT JSON and XML does not mean that a Client must use both (or even that a client must implement both). It is perfectly reasonable and generally acceptable to have a server that provides data in multiple formats whereas the client only supports a subset and specifies which format(s) are acceptable. -derek To Paul's point about how easy it is for a server to support both, I'd retort that it's equally easy for a client to gin up JSON instead of XML. Pity the poor programmer who can't get their head around that gigantic change. On the other hand, having to support XML and JSON is an ongoing maintenance headache server-side. Why do it? There isn't even the dubious religious war like back in the day saying that binary encoded ASN.1 was "better/faster/stacks and cleans dishes" than "human readable" XML. XML is just a clunky and past its prime text encoding at this point. Requiring it smacks of nostalgia to me. Mike From eran@hueniverse.com Fri Apr 20 08:25: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 744FE21F879B for ; Fri, 20 Apr 2012 08:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etyZ0OGS14d3 for ; Fri, 20 Apr 2012 08:25:10 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id DDCD321F878A for ; Fri, 20 Apr 2012 08:25:08 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id 0FR81j0080EuLVk01FR8Rf; Fri, 20 Apr 2012 08:25:08 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Fri, 20 Apr 2012 08:25:08 -0700 From: Eran Hammer To: Daniel Renfer , William Mills Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHweGzEHp1VSTw0S1QHL3sl+515aj0fCQ Date: Fri, 20 Apr 2012 15:25:07 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FF567E@P3PWEX2MB008.ex2.secureserver.net> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <1334933123.53510.YahooMailNeo@web31803.mail.mud.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 15:25:12 -0000 VGhlIGdlbmVyYWwgYXBwcm9hY2ggSSd2ZSB0YWtlbiB3aXRoIGhvc3QtbWV0YSB3YXMgdG8gcHJv dmlkZSBhIGZyYW1ld29yayBhbmQgYWxsb3cgZWFjaCBhcHBsaWNhdGlvbiB0byBtYWtlIGl0cyBj aG9pY2VzIHJlZ2FyZGluZyB3aGF0J3MgcmVxdWlyZWQgYW5kIHdoYXQncyBvcHRpb25hbC4gRm9y IGV4YW1wbGUsIGFuIGFwcGxpY2F0aW9uIHVzaW5nIGhvc3QtbWV0YSBtdXN0IGRlY2lkZSBpZiBp dCByZXF1aXJlcyB0aGUgdXNlIG9mIFRMUyBvciBzdXBwb3J0cyBib3RoIEhUVFAgYW5kIEhUVFBT LiBJdCBtYXkgcmVxdWlyZSB0aGUgYXZhaWxhYmlsaXR5IG9mIEpTT04sIGFuZCBhcyB0aGUgV2Vi RmluZ2VyIGRyYWZ0IHByb3Bvc2VzLCBpdCBtYXkgcmVxdWlyZSBvciBtYWtlIGF2YWlsYWJsZSBh ZGRpdGlvbmFsIHF1ZXJ5IHBhcmFtZXRlcnMuDQoNClRoZXJlIGlzIGEgTE9UIG9mIGhpc3Rvcnkg aGVyZS4gUHJldmlvdXMgdmVyc2lvbnMgaW5jbHVkZWQgZG9jdW1lbnQgc2lnbmF0dXJlcywgYSBu ZXcgaG9zdDogVVJJIHNjaGVtZSwgdXNlIG9mIFhSRCA8U3ViamVjdD4sIGEgd2lkZSByYW5nZSBv ZiBMUkREIHByb2Nlc3NpbmcgcnVsZXMsIG11bHRpcGxlIGxpbmtzIHN1cHBvcnQgZm9yIExSREQg KEhUVFAgaGVhZGVycywgSFRNTCBtYXJrdXAsIGhvc3QtbWV0YSksIHByb2Nlc3NpbmcgcHJpb3Jp dHkgcnVsZXMsIGFuZCBvbiBhbmQgb24uIFRoaXMgYXBwcm9hY2ggZGlkIG5vdCB3b3JrIG91dCBi ZWNhdXNlIHRoZSByZXF1aXJlbWVudHMgb2YgdGhlIGRpZmZlcmVudCBjb21tdW5pdGllcyBpbnZv bHZlZCB3ZXJlIGp1c3QgdG9vIHdpZGUuDQoNCkZvciBleGFtcGxlLCBHb29nbGUgZGlkIG5vdCB3 YW50IHRvIHJlcXVpcmUgVExTIGZvciBob3N0LW1ldGEgYW5kIHdhbnRlZCB0byBkZXZlbG9wIGEg ZG9jdW1lbnQgc2lnbmF0dXJlIG1ldGhvZCBpbnN0ZWFkIGZvciB1c2luZyBpdCB3aXRoIE9wZW5J RCBiZWNhdXNlIChhdCBsZWFzdCBhdCB0aGUgdGltZSksIFRMUyB3YXMgbGltaXRlZCB0byByZXF1 aXJpbmcgYW4gSVAgYWRkcmVzcyBwZXIgaG9zdGVkIGRvbWFpbiB0aGV5IHByb3ZpZGUgdGhpcyBz ZXJ2aWNlIHRvLCBhbmQgdGhleSBqdXN0IGNvdWxkIG5vdCBnZXQgdGhhdCBtYW55IElQIGFkZHJl c3NlcyBmb3IgYWxsIHRoZXNlIFRMUyBjZXJ0aWZpY2F0ZXMuIFRoZSB2YXJpb3VzIHdvcmtpbmcg Z3JvdXBzIGludm9sdmVkIHNwZW50IGFib3V0IDYgbW9udGhzIGp1c3QgZGV2ZWxvcGluZyB0aGlz IGFwcHJvYWNoIGJ1dCBldmVudHVhbGx5IGl0IHdhcyBhYmFuZG9uZWQgZHVlIHRvIGxhY2sgb2Yg aW50ZXJlc3QgYW5kIG90aGVyIG9uZ29pbmcgcHJvamVjdHMuDQoNClRoZSBwb2ludCBpcywgaG9z dC1tZXRhIGJ5IGl0c2VsZiBpcyB1c2VsZXNzLiBJdCBpcyBvbmx5IGEgYmFzaWMgbGF5ZXIgZm9y IGJ1aWxkaW5nIGFjdHVhbCBkaXNjb3Zlcnkgb24gdG9wLCBhcyBkaXNjb3ZlcnkgcmVxdWlyZXMg ZGVjaXNpb25zIGFib3V0IHdoYXQgaW5mb3JtYXRpb24gaXMgYWN0dWFsbHkgYmVpbmcgcmVxdWVz dHMgYW5kIHRoZSBzZWN1cml0eS9wcml2YWN5IGF0dHJpYnV0ZXMgcmVxdWlyZWQuDQoNClRoaXMg cHJvY2VzcyBvZiBwcm9maWxpbmcgY2FuIGJlIGRvbmUgdmVyeSBzcGVjaWZpY2FsbHkgKGUuZy4g T3BlbklEIENvbm5lY3QgY2FuIHVzZSBob3N0LW1ldGEgYnkgcmVxdWlyaW5nIFRMUywgSlNPTiwg YW5kIHRoZSByZXNvdXJjZSBhbmQgcmVsIHBhcmFtZXRlcnMgLSBhbmQgY2FuIGRvIHRoYXQgdG9k YXkpIG9yIHZlcnkgYnJvYWRseSAoZS5nLiB0aGUgYXBwcm9hY2ggdGFrZW4gYnkgdGhlIGN1cnJl bnQgV2ViRmluZ2VyIGRyYWZ0IHRvIGRlZmluZSBhZGRpdGlvbmFsIGdlbmVyYWwgcHVycG9zZSBm ZWF0dXJlcykuDQoNCkknbSBub3QgZXhwZWN0aW5nIGV2ZXJ5b25lIGhlcmUgdG8gaGF2ZSB0aGUg ZnVsbCBiYWNrZ3JvdW5kIG9uIHRoaXMgd29yaywgYnV0IGhvcGVmdWxseSBwZW9wbGUgY2FuIGFw cHJlY2lhdGUgdGhhdCB0aGlzIGhhcyBiZWVuIHdvcmtlZCBvbiBmb3Igb3ZlciA1IHllYXJzIGlu IG11bHRpcGxlIHN0YW5kYXJkcyBib2RpZXMgKElFVEYsIE9BU0lTLCBXM0MpLCBoYXMgYmVlbiBl eHRlbnNpdmVseSByZXZpZXdlZCBhbmQgZGlzY3Vzc2VkIGJ5IHRoZSBXM0MgVEFHLCBldGMuIFdl IGNhbiBvYnZpb3VzbHkgcmVhY2ggb3RoZXIgY29tcHJvbWlzZXMgbm93IHRoYW4gd2VyZSBkZXNp cmVkL3Bvc3NpYmxlIGEgeWVhciBhZ28gd2hlbiB0aGlzIHdvcmsgd2FzIGZpbmFsaXplZCwgYnV0 IGxldCdzIG5vdCBraWQgb3Vyc2VsdmVzIHRoYXQgcmVhY2hpbmcgY29uc2Vuc3VzIG9uIGFub3Ro ZXIgY29tcHJvbWlzZSB3aWxsIGJlIGVhc3kgKG9yIGV2ZW4gcG9zc2libGUpLg0KDQpFSA0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGFwcHMtZGlzY3Vzcy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLQ0KPiBib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgRGFuaWVsIFJlbmZlcg0KPiBTZW50OiBGcmlkYXksIEFwcmlsIDIwLCAyMDEyIDg6 MDkgQU0NCj4gVG86IFdpbGxpYW0gTWlsbHMNCj4gQ2M6IG9hdXRoQGlldGYub3JnOyBBcHBzIERp c2N1c3MNCj4gU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFtPQVVUSC1XR10gV2ViIEZpbmdl ciB2cy4gU2ltcGxlIFdlYg0KPiBEaXNjb3ZlcnkgKFNXRCkNCj4gDQo+IFRoZSBwb2ludCBpcyB0 aGF0IGV4aXN0aW5nIFdGIGNsaWVudHMgaGF2ZSBiZWVuIHdyaXR0ZW4gdG8gbm90IHVzZSB0aGUN Cj4gcmVzb3VyY2UgcGFyYW1ldGVyIGJlY2F1c2UgaW4gdGhlIHBhc3QsIHRoYXQgcGFyYW1ldGVy IGhhc24ndCBiZWVuDQo+IGF2YWlsYWJsZSBvciBoYXNuJ3QgYmVlbiByZWxpYWJsZS4NCj4gDQo+ IElmIHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIgaXMgcmVxdWlyZWQsIHRoaXMgb2xkZXIgbWV0aG9k IG9mIGZldGNoaW5nIHRoZSBob3N0DQo+IG1ldGEgYW5kIGNvbnN0cnVjdGluZyB0aGUgdXJsIHRv IGZldGNoIHRoZSB1c2VyIG1ldGEgd291bGQgc3RpbGwgY29udGludWUgdG8NCj4gd29yayBqdXN0 IGFzIGJlZm9yZS4NCj4gDQo+IEV2ZW4gaWYgdGhlIHJlc291cmNlIHBhcmFtZXRlciB3ZXJlIG1h ZGUgbWFuZGF0b3J5IHRvZGF5LCByZWFsIHdvcmxkIFdGDQo+IGNsaWVudHMgd291bGQgc3RpbGwg aGF2ZSB0byBhY2NvdW50IGZvciB0aGUgcG9zc2liaWxpdHkgb2YgcmVzb3VyY2UgcXVlcmllcw0K PiByZXN1bHRpbmcgaW4gYW4gZXJyb3Igb3IgaW5jb3JyZWN0IGluZm9ybWF0aW9uLiBHaXZlbiB0 aGUgbnVtYmVyIG9mIGN1cnJlbnRseQ0KPiBkZXBsb3llZCBXRi1lbmFibGVkIHNlcnZpY2VzIGFu ZCB0aGUgZGlmZmljdWx0eSBpbiB1cGdyYWRpbmcgYWxsIG9mIHRoZW0sIHRoaXMNCj4gaXMgZ29p bmcgdG8gYmUgdGhlIGNhc2UgZm9yIHNvbWUgdGltZS4NCj4gDQo+IHJlc291cmNlIHBhcmFtZXRl cnMgc2hvdWxkIGJlIHN0cm9uZ2x5IGVuY291cmFnZWQsIGJ1dCBub3QgcmVxdWlyZWQuDQo+IA0K PiBPbiBGcmksIEFwciAyMCwgMjAxMiBhdCAxMDo0NSBBTSwgV2lsbGlhbSBNaWxscyA8d21pbGxz QHlhaG9vLWluYy5jb20+DQo+IHdyb3RlOg0KPiA+IFNvIHlvdSBhcmUgZ3VhcmFudGVlaW5nIHRo YXQgdGhlcmUgYXJlIG5vIGNsaWVudHMgdXNpbmcgV0YgdG9kYXk/DQo+ID4NCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEZyb206IE1pa2UgSm9uZXMgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT4NCj4gPiBUbzogUGF1bCBFLiBKb25lcyA8cGF1bGVqQHBhY2tl dGl6ZXIuY29tPjsgJ011cnJheSBTLiBLdWNoZXJhd3knDQo+ID4gPG1za0BjbG91ZG1hcmsuY29t PjsgIm9hdXRoQGlldGYub3JnIiA8b2F1dGhAaWV0Zi5vcmc+OyAnQXBwcw0KPiBEaXNjdXNzJw0K PiA+IDxhcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQo+ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE5 LCAyMDEyIDEwOjQ4IFBNDQo+ID4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gW2FwcHMtZGlzY3Vz c10gV2ViIEZpbmdlciB2cy4gU2ltcGxlIFdlYg0KPiA+IERpc2NvdmVyeQ0KPiA+IChTV0QpDQo+ ID4NCj4gPiBUbyBiZSBjbGVhciwgbWFraW5nIHRoaXMgbWFuZGF0b3J5IHdvdWxkIGJyZWFrIG5v IGNsaWVudHMuwqAgSXQgd291bGQNCj4gPiByZXF1aXJlIHVwZGF0aW5nIHNvbWUgc2VydmVycywg anVzdCBhcyByZXF1aXJpbmcgSlNPTiB3b3VsZC7CoCBUaGlzDQo+ID4gc2VlbXMgbGlrZSBhIGZh aXIgdHJhZGVvZmYgd2hlbiBpdCBtYWtlcyBhbiBhcHByZWNpYWJsZSBkaWZmZXJlbmNlIGluDQo+ ID4gdXNlciBpbnRlcmZhY2UgbGF0ZW5jeSBpbiBzb21lIGltcG9ydGFudCBzY2VuYXJpb3MuwqAg SWYgeW91IGFuZCB0aGUNCj4gPiBvdGhlciBrZXkgV2ViRmluZ2VyIHN1cHBvcnRlcnMgY2FuIGFn cmVlIHRvIG1ha2luZyAicmVzb3VyY2UiIHN1cHBvcnQNCj4gPiBtYW5kYXRvcnkgYW5kIHJlcXVp cmluZyBKU09OLCBJIGJlbGlldmUgd2UgbWF5IGhhdmUgYSBwYXRoIGZvcndhcmQuDQo+ID4NCj4g PiDCoMKgwqAgwqDCoMKgIMKgwqDCoCDCoMKgwqAgQ2hlZXJzLA0KPiA+IMKgwqDCoCDCoMKgwqAg wqDCoMKgIMKgwqDCoCAtLSBNaWtlDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+IEZyb206IFBhdWwgRS4gSm9uZXMgW21haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb21d DQo+ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE5LCAyMDEyIDEwOjM5IFBNDQo+ID4gVG86IE1p a2UgSm9uZXM7ICdNdXJyYXkgUy4gS3VjaGVyYXd5Jzsgb2F1dGhAaWV0Zi5vcmc7ICdBcHBzIERp c2N1c3MnDQo+ID4gU3ViamVjdDogUkU6IFthcHBzLWRpc2N1c3NdIFtPQVVUSC1XR10gV2ViIEZp bmdlciB2cy4gU2ltcGxlIFdlYg0KPiA+IERpc2NvdmVyeQ0KPiA+IChTV0QpDQo+ID4NCj4gPiBU aGF0J3MgY29ycmVjdC7CoCBXZSBjb3VsZCBjZXJ0YWlubHkgbWFrZSBpdCBtYW5kYXRvcnksIGJ1 dCB0aGUgcmVhc29uDQo+ID4gaXQgaXNuJ3QgaXMgdG8gbWFpbnRhaW4gYmFja3dhcmQgY29tcGF0 aWJpbGl0eSB3aXRoIGV4aXN0aW5nIGRlcGxveW1lbnRzLg0KPiA+DQo+ID4gSSB0aGluayB3ZSBz aG91bGQgYWx3YXlzIHRoaW5rIGNhcmVmdWxseSB3aGVuIHdlIGRlY2lkZSB0byBtYWtlIGENCj4g PiBjaGFuZ2UgdGhhdCBicmVha3MgYmFja3dhcmQtY29tcGF0aWJpbGl0eS7CoCBUaGlzIGlzIG9u ZSBjaGFuZ2UgdGhhdCB3b3VsZA0KPiBkbyB0aGF0Lg0KPiA+DQo+ID4gUGF1bA0KPiA+DQo+ID4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IE1pa2UgSm9uZXMgW21haWx0 bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb21dDQo+ID4+IFNlbnQ6IEZyaWRheSwgQXByaWwg MjAsIDIwMTIgMToxMCBBTQ0KPiA+PiBUbzogUGF1bCBFLiBKb25lczsgJ011cnJheSBTLiBLdWNo ZXJhd3knOyBvYXV0aEBpZXRmLm9yZzsgJ0FwcHMgRGlzY3VzcycNCj4gPj4gU3ViamVjdDogUkU6 IFthcHBzLWRpc2N1c3NdIFtPQVVUSC1XR10gV2ViIEZpbmdlciB2cy4gU2ltcGxlIFdlYg0KPiA+ PiBEaXNjb3ZlcnkNCj4gPj4gKFNXRCkNCj4gPj4NCj4gPj4gQ3VycmVudGx5LCBzdXBwb3J0IGZv ciB0aGUgInJlc291cmNlIiBwYXJhbWV0ZXIgaXMgb3B0aW9uYWwsIGFzIHBlcg0KPiA+PiB0aGUg Zm9sbG93aW5nIChjb3JyZWN0Pyk6DQo+ID4+DQo+ID4+wqAgwqAgTm90ZSB0aGF0IHN1cHBvcnQg Zm9yIHRoZSAicmVzb3VyY2UiIHBhcmFtZXRlciBpcyBvcHRpb25hbCwgYnV0DQo+ID4+wqAgwqAg c3Ryb25nbHkgUkVDT01NRU5ERUQgZm9yIGltcHJvdmVkIHBlcmZvcm1hbmNlLsKgIElmIGEgc2Vy dmVyIGRvZXMNCj4gPj5ub3QNCj4gPj7CoCDCoCBpbXBsZW1lbnQgdGhlICJyZXNvdXJjZSIgcGFy YW1ldGVyLCB0aGVuIHRoZSBzZXJ2ZXIncyBob3N0DQo+ID4+bWV0YWRhdGENCj4gPj7CoCDCoCBw cm9jZXNzaW5nIGxvZ2ljIHJlbWFpbnMgdW5jaGFuZ2VkIGZyb20gUkZDIDY0MTUuDQo+ID4+DQo+ ID4+IFRvIHRydWx5IHN1cHBvcnQgMSwgdGhpcyB3b3VsZCBuZWVkIHRvIGJlIGNoYW5nZWQgdG8g UkVRVUlSRUQsIGNvcnJlY3Q/DQo+ID4+DQo+ID4+IMKgwqDCoCDCoMKgwqAgwqDCoMKgIMKgwqDC oCAtLSBNaWtlDQo+ID4+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZy b206IFBhdWwgRS4gSm9uZXMgW21haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb21dDQo+ID4+IFNl bnQ6IFRodXJzZGF5LCBBcHJpbCAxOSwgMjAxMiA4OjE2IFBNDQo+ID4+IFRvOiBNaWtlIEpvbmVz OyAnTXVycmF5IFMuIEt1Y2hlcmF3eSc7IG9hdXRoQGlldGYub3JnOyAnQXBwcyBEaXNjdXNzJw0K PiA+PiBTdWJqZWN0OiBSRTogW2FwcHMtZGlzY3Vzc10gW09BVVRILVdHXSBXZWIgRmluZ2VyIHZz LiBTaW1wbGUgV2ViDQo+ID4+IERpc2NvdmVyeQ0KPiA+PiAoU1dEKQ0KPiA+Pg0KPiA+PiBNaWtl LA0KPiA+Pg0KPiA+PiA+IFRoZXJlIGFyZSB0d28gY3JpdGVyaWEgdGhhdCBJIHdvdWxkIGNvbnNp ZGVyIHRvIGJlIGVzc2VudGlhbA0KPiA+PiA+IHJlcXVpcmVtZW50cyBmb3IgYW55IHJlc3VsdGlu ZyBnZW5lcmFsLXB1cnBvc2UgZGlzY292ZXJ5IHNwZWNpZmljYXRpb246DQo+ID4+ID4NCj4gPj4g PiAxLsKgIEJlaW5nIGFibGUgdG8gYWx3YXlzIGRpc2NvdmVyIHBlci11c2VyIGluZm9ybWF0aW9u IHdpdGggYQ0KPiA+PiA+IHNpbmdsZSBHRVQgKG1pbmltaXppbmcgdXNlciBpbnRlcmZhY2UgbGF0 ZW5jeSBmb3IgbW9iaWxlIGRldmljZXMsDQo+ID4+ID4gZXRjLikNCj4gPj4NCj4gPj4gV0YgY2Fu IGRvIHRoYXQuwqAgU2VlOg0KPiA+PiAkIGN1cmwgLXYgaHR0cHM6Ly9wYWNrZXRpemVyLmNvbS8u d2VsbC1rbm93bi9cDQo+ID4+wqAgwqAgwqAgwqAgwqAgaG9zdC1tZXRhLmpzb24/cmVzb3VyY2U9 YWNjdDpwYXVsZWpAcGFja2V0aXplci5jb20NCj4gPj4NCj4gPj4gPiAyLsKgIEpTT04gc2hvdWxk IGJlIHJlcXVpcmVkIGFuZCBpdCBzaG91bGQgYmUgdGhlIG9ubHkgZm9ybWF0DQo+ID4+ID4gcmVx dWlyZWQgKHNpbXBsaWNpdHkgYW5kIGVhc2Ugb2YgZGVwbG95bWVudC9hZG9wdGlvbikNCj4gPj4N Cj4gPj4gU2VlIHRoZSBhYm92ZSBleGFtcGxlLsKgIEhvd2V2ZXIsIEkgYWxzbyBzdXBwb3J0IFhN TCB3aXRoIG15IHNlcnZlci4NCj4gPj4gSXQgdG9vayBtZSBsZXNzIHRoYW4gMTAgbWludXRlcyB0 byBjb2RlIHVwIGJvdGggWE1MIGFuZCBKU09ODQo+ID4+IHJlcHJlc2VudGF0aW9ucy4NCj4gPj4g T25jZSB0aGUgcmVxdWVzdGVkIGZvcm1hdCBpcyBkZXRlcm1pbmVkLCB0aGUgcmVxdWVzdGVkIFVS SSBpcw0KPiA+PiBkZXRlcm1pbmVkLCBkYXRhIGlzIHB1bGxlZCBmcm9tIHRoZSBkYXRhYmFzZSwg c3BpdHRpbmcgb3V0IHRoZQ0KPiA+PiBkZXNpcmVkIGZvcm1hdCBpcyB0cml2aWFsLg0KPiA+Pg0K PiA+PiBOb3RlLCBhbmQgdmVyeSBpbXBvcnRhbnQgbm90ZTogc3VwcG9ydGluZyBib3RoIFhNTCBh bmQgSlNPTiB3b3VsZA0KPiA+PiBvbmx5IGJlIGEgc2VydmVyLXNpZGUgcmVxdWlyZW1lbnQuwqAg VGhlIGNsaWVudCBpcyBhdCBsaWJlcnR5IHRvIHVzZQ0KPiA+PiB0aGUgZm9ybWF0IGl0IHByZWZl cnMuwqAgSSB3b3VsZCBhZ3JlZSB0aGF0IGZvcmNpbmcgYSBjbGllbnQgdG8NCj4gPj4gc3VwcG9y dCBib3RoIHdvdWxkIGJlIHVuYWNjZXB0YWJsZSwgYnV0IHRoZSBzZXJ2ZXI/wqAgTm90aGluZyB0 byBpdC4NCj4gPj4NCj4gPj4gPiBTV0QgYWxyZWFkeSBtZWV0cyB0aG9zZSByZXF1aXJlbWVudHMu wqAgSWYgdGhlIHJlc3VsdGluZyBzcGVjIG1lZXRzDQo+ID4+ID4gdGhvc2UgcmVxdWlyZW1lbnRz LCBpdCBkb2Vzbid0IG1hdHRlciBhIGxvdCB3aGV0aGVyIHdlIGNhbGwgaXQNCj4gPj4gPiBXZWJG aW5nZXIgb3IgU2ltcGxlIFdlYiBEaXNjb3ZlcnksIGJ1dCBJIGJlbGlldmUgdGhhdCB0aGUNCj4g Pj4gPiByZXF1aXJlbWVudHMgZGlzY3Vzc2lvbiBpcyBwcm9iYWJseSB0aGUgbW9zdCBwcm9kdWN0 aXZlIG9uZSB0byBiZQ0KPiA+PiA+IGhhdmluZyBhdCB0aGlzIHBvaW50IC0gbm90IHRoZSBzdGFy dGluZyBwb2ludCBkb2N1bWVudC4NCj4gPj4NCj4gPj4gSSBiZWxpZXZlIFdlYkZpbmdlciBtZWV0 cyB0aG9zZSByZXF1aXJlbWVudHMuwqAgV2UgY291bGQgZGViYXRlDQo+ID4+IHdoZXRoZXIgWE1M IHNob3VsZCBiZSBzdXBwb3J0ZWQsIGJ1dCBJJ2xsIG5vdGUgKGFnYWluKSB0aGF0IGl0IGlzDQo+ ID4+IHRoZXJlIGluIFJGQyA2NDE1Lg0KPiA+PiBUaGF0IGRvY3VtZW50IGlzbid0IGFsbCB0aGF0 IG9sZCBhbmQsIGZyYW5rbHksIGl0IGNvbmNlcm5zIG1lIHRoYXQgd2UNCj4gPj4gd291bGQgaGF2 ZSBhIHN0cm9uZyBwcmVmZXJlbmNlIGZvciBmb3JtYXQgQSBvbmUgd2VlayBhbmQgdGhlbiBGb3Jt YXQNCj4gPj4gQiB0aGUgbmV4dC4NCj4gPj4gV2UgYXJlIHdoZXJlIHdlIGFyZSBhbmQgSSBjYW4g c2VlIHJlYXNvbiBmb3IgYXNraW5nIGZvciBKU09OLCBidXQgbm8NCj4gPj4gZ29vZCByZWFzb24g dG8gc2F5IHdlIHNob3VsZCBub3QgYWxsb3cgWE1MIChvbiB0aGUgc2VydmVyIHNpZGUpLg0KPiA+ Pg0KPiA+PiBQYXVsDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE9BdXRo IG1haWxpbmcgbGlzdA0KPiA+IE9BdXRoQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gYXBwcy1kaXNjdXNzIG1h aWxpbmcgbGlzdA0KPiA+IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQo+ID4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gYXBwcy1kaXNjdXNzIG1haWxp bmcgbGlzdA0KPiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCg== From julian.reschke@gmx.de Fri Apr 20 08:31: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 94DC121F8768 for ; Fri, 20 Apr 2012 08:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.232 X-Spam-Level: X-Spam-Status: No, score=-103.232 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyBcM-VaJ48H for ; Fri, 20 Apr 2012 08:31:28 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 36C3D21F8731 for ; Fri, 20 Apr 2012 08:31:27 -0700 (PDT) Received: (qmail invoked by alias); 20 Apr 2012 15:31:26 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.83]) [217.91.35.233] by mail.gmx.net (mp072) with SMTP; 20 Apr 2012 17:31:26 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/vvuZqBdzv5ovy1dM/FBl0QXdF4jCzKY0pnOttpt zdGATuUleEperd Message-ID: <4F91814A.2010606@gmx.de> Date: Fri, 20 Apr 2012 17:31:22 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Michael Thomas References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> <4F917CE6.2060904@mtcc.com> In-Reply-To: <4F917CE6.2060904@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Derek Atkins , oauth@ietf.org, 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 15:31:29 -0000 On 2012-04-20 17:12, Michael Thomas wrote: > ... > To Paul's point about how easy it is for a server to support both, I'd > retort that it's equally easy for a client to gin up JSON instead of XML. > Pity the poor programmer who can't get their head around that gigantic > change. On the other hand, having to support XML and JSON is an ongoing > maintenance headache server-side. Why do it? There isn't even the dubious > religious war like back in the day saying that binary encoded ASN.1 was > "better/faster/stacks and cleans dishes" than "human readable" XML. XML > is just a clunky and past its prime text encoding at this point. > Requiring it > smacks of nostalgia to me. > ... What's sure is that with generalizations like these, you're not going to convince anybody. JSON is simpler than XML. Sometimes it's too simple. In my experience, testing HTTP interfaces that return XML is more pleasant as a browser will actually *display* the response (and allow it to be transformed to HTML client-side), while it will pop up a download dialogue for application/json. Maybe it's time to fix the latter? Best regards, Julian From mike@mtcc.com Fri Apr 20 08:51: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 9265C21F86D3; Fri, 20 Apr 2012 08:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkVDVBpurCip; Fri, 20 Apr 2012 08:51:28 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 96ABE21F86DE; Fri, 20 Apr 2012 08:51:28 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3KFpO3K007622 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 20 Apr 2012 08:51:24 -0700 Message-ID: <4F9185FC.5070406@mtcc.com> Date: Fri, 20 Apr 2012 08:51:24 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Julian Reschke References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> <4F917CE6.2060904@mtcc.com> <4F91814A.2010606@gmx.de> In-Reply-To: <4F91814A.2010606@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2157; t=1334937085; x=1335801085; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[apps-discuss]=20[OAUTH-WG]=20Web=20Fin ger=20vs.=20Simple=20Web=20Discovery=0A=20(SWD) |Sender:=20 |To:=20Julian=20Reschke=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=r4kkUgFtrRlHis/kPLyKpWArS9X6s1F9WzHt/vb/m+k=; b=JvNfuNtRTPZYMlJU3413YfQUZeQcA8zf7oS7wob/JSGzokHCBZ3OW9agBS Hqu4PRLCcxh/rtUduDNxUnoY0UirJVurirRnZp2E0T+KQyIxj5Emz07lT8vs xqXrY6LrFDSKeDc9uo0NTnB16VM/iIXKwyj6mttE2SIPeo1PGVspE=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com X-Mailman-Approved-At: Fri, 20 Apr 2012 09:54:30 -0700 Cc: Derek Atkins , oauth@ietf.org, 'Apps Discuss' Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 15:51:29 -0000 On 04/20/2012 08:31 AM, Julian Reschke wrote: > On 2012-04-20 17:12, Michael Thomas wrote: >> ... >> To Paul's point about how easy it is for a server to support both, I'd >> retort that it's equally easy for a client to gin up JSON instead of XML. >> Pity the poor programmer who can't get their head around that gigantic >> change. On the other hand, having to support XML and JSON is an ongoing >> maintenance headache server-side. Why do it? There isn't even the dubious >> religious war like back in the day saying that binary encoded ASN.1 was >> "better/faster/stacks and cleans dishes" than "human readable" XML. XML >> is just a clunky and past its prime text encoding at this point. >> Requiring it >> smacks of nostalgia to me. >> ... > > What's sure is that with generalizations like these, you're not going to convince anybody. > > JSON is simpler than XML. Sometimes it's too simple. > > In my experience, testing HTTP interfaces that return XML is more pleasant as a browser will actually *display* the response (and allow it to be transformed to HTML client-side), while it will pop up a download dialogue for application/json. Maybe it's time to fix the latter? > It may be a generalization, but it's based on direct experience. I create and use JSON for fairly complex data structures transferred server->client (it's a ski tracking app) and I have never once thought "gosh, I wish that I had the expressiveness of XML here". On the input side of uploading points to the server, I use a home grown XML scheme purely for my own historical reasons and I do often wish that I could get rid of it. The worst of all possible worlds would be to require support for both on the input and output side. Bletch. Just the testing requirements would be onerous. I also know that, oh say, twitter supports XML and JSON in their API. Probably lots of companies do. I'll bet if you asked them now, they'd say they wish they hadn't supported XML at this point because it's nothing more than overhead, keeping some dev and devtest folks gainfully employed. Mike, and I don't have a problem viewing JSON in a browser From barryleiba.mailing.lists@gmail.com Fri Apr 20 10:08: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 37D0721F86E8; Fri, 20 Apr 2012 10:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.906 X-Spam-Level: X-Spam-Status: No, score=-102.906 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF-9ZErsOIve; Fri, 20 Apr 2012 10:08:19 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8C78321F86E5; Fri, 20 Apr 2012 10:08:19 -0700 (PDT) Received: by yhkk25 with SMTP id k25so6096377yhk.31 for ; Fri, 20 Apr 2012 10:08:19 -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=wPGZhrRaP2kv60GW6yTgZU707596FHQZlLIF6qnOZrY=; b=SPHaK65g6BnP0jPRDjLebpVX7gdM4aLJwIL0euZtaE2sMOd6YI/zRpLZXsHAkpTLbC VK3aIbCUTposh3J4Ga2H8BP2nR9YhyxT+wCfGuCjOoPqpWKJvimBjCCyRpYAFgoIYdtz Avs5vZXZBi5SRL5VBC0LvVPAvGaj2gjcOFeO97pjqHsZE0y6LgO83OFTNgXdB9CuOdFb w4JZD+9IcSCb9wGXc2SHBJBigwG8mQ0nWrPHiwix6xJtB2nOKACJwXpHYau0ry1MoP4d vzhWSBjdIE1j/8U2t7tjR3axiBcLDtFk35kjJ6A93S+rBFPe27ut81ldYNsheCiAwysL ng5w== MIME-Version: 1.0 Received: by 10.236.76.133 with SMTP id b5mr6837046yhe.3.1334941699111; Fri, 20 Apr 2012 10:08:19 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.152.14 with HTTP; Fri, 20 Apr 2012 10:08:19 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E0039280FB707@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120419130040.0b4ee328@elandnews.com> <9452079D1A51524AA5749AD23E0039280FB707@exch-mbx901.corp.cloudmark.com> Date: Fri, 20 Apr 2012 13:08:19 -0400 X-Google-Sender-Auth: JcibHHpiXYbiwHri_ACkM64OuxQ Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-kucherawy-marf-source-ports.all@tools.ietf.org" , S Moonesamy , "apps-discuss@ietf.org" , "marf@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-kucherawy-marf-source-ports-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: Fri, 20 Apr 2012 17:08:20 -0000 >> =A0 =A0'A new ARF reporting field called "Source-Port" is defined.' >> >> That should be header field (see Section 3.2 of RFC 5965). =A0I gather >> that the intent is to make this an optional header field. =A0I suggest >> specifying that Section 3.2 is being updated. =A0That should also be don= e >> for Section 3.1 of RFC 6591. > > I haven't seen specific section call-outs done in an updating document be= fore, only > the "Updates" stuff on the title page. =A0Is this necessary? I've seen it occasionally. I think that if the sense in which B updates A is narrow enough that it's easy to specify what's updated, it's quite useful to say what's updated. I doubt you'll get any DISCUSSes if you don't, but anything that will help the reader make better use of both specs is a good thing. Barry From gsalguei@cisco.com Fri Apr 20 10:09: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 332C921F86F0 for ; Fri, 20 Apr 2012 10:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dg0krx7xgux0 for ; Fri, 20 Apr 2012 10:09:52 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id E603421F86EA for ; Fri, 20 Apr 2012 10:09:51 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3KH9msA018508 for ; Fri, 20 Apr 2012 13:09:48 -0400 (EDT) Received: from dhcp-64-102-154-162.cisco.com (dhcp-64-102-154-162.cisco.com [64.102.154.162]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3KH9mLD004542; Fri, 20 Apr 2012 13:09:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: Date: Fri, 20 Apr 2012 13:09:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7F48DDA5-EA3C-45B0-90E0-C39F06748B35@cisco.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> To: Derek Atkins X-Mailer: Apple Mail (2.1257) Cc: oauth@ietf.org, Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 17:09:52 -0000 Derek -=20 On Apr 20, 2012, at 10:17 AM, Derek Atkins wrote: > Paul, >=20 > "Paul E. Jones" writes: >=20 >> Tim, >>=20 >> I do not agree that it's harmful. If I removed the WF discussion off = the >> table, I'm still having a hard time buying into everything you said = in the >> blog post. >>=20 >> I implement various web services, largely for my own use. Usually, I >> implement all of them in XML, JSON, plain text (attribute/value = pairs), AND >> JavaScript (for JSONP). For simple services, it's not hard. I do it >> because I sometimes have different wants/desires on the client side. = (For >> more complex ones, I use XML.) >=20 > As an individual (and not the chair of OAUTH) I believe that the = server > should be allowed, no encouraged, to support multiple formats for data > retrieval. I also believe that clients should be allowed to choose = only > one. I am fine with JSON being Mandatory to Implement. I am NOT okay > with making it the only one, and I am even less okay with mandating it > is the ONLY one. I would say MUST JSON, MUST (or possibly SHOULD -- = you > can convince me either way) XML, and MAY for anything else that people > feel stronly about (although I feel in 2012 XML and JSON are the two > best). I also feel it is okay to say that a client MUST implement one > of JSON or XML, and MAY implement more. >=20 > >=20 > Note that this is a replay of the historical "MUST Implement" versus > "MUST Use" arguments. Just because the server MUST IMPLEMENT JSON and > XML does not mean that a Client must use both (or even that a client > must implement both). It is perfectly reasonable and generally > acceptable to have a server that provides data in multiple formats > whereas the client only supports a subset and specifies which = format(s) > are acceptable. >=20 > >=20 This is the most sensible path forward. A MUST for JSON and XML (I'm = going with a MUST for XML to maintain backwards compatibility with RFC = 6415) on the server side and a client can choose whatever format it = wants. This is the approach taken in the current WebFinger draft. If we = reach consensus that we must mandate a client format (Note: I don't = personally think we need to), then so be it. Cheers, Gonzalo > -derek >=20 > --=20 > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From msk@cloudmark.com Fri Apr 20 10:17: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 1CD5321F866D for ; Fri, 20 Apr 2012 10:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-emclAopiXu for ; Fri, 20 Apr 2012 10:17:11 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7958721F866A for ; Fri, 20 Apr 2012 10:17:11 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 0HGx1j0010as01C01HGxcP; Fri, 20 Apr 2012 10:16:57 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=qZODYEWQ6tEA:10 a=zutiEJmiVI4A:10 a=8nJEP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=6-s60PiWim1u0hFyA74A:9 a=KZxLVw75WxjCe1zenf0A:7 a=wPNLvfGTeEIA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 20 Apr 2012 10:16:38 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" , "marf@ietf.org" Thread-Topic: [apps-discuss] APPSDIR review of draft-kucherawy-marf-source-ports-01 Thread-Index: AQHNHxgvZDroB1XnTE+/NFHqiPdv5paj9F7A Date: Fri, 20 Apr 2012 17:16:37 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FC807@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120419130040.0b4ee328@elandnews.com> <9452079D1A51524AA5749AD23E0039280FB707@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334942217; bh=+/DhjC8FZipLHzsG1c/9jAZhajeSHovA0hZU+5Mc0fU=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=KYbdvXpRw1oNuq+JoGwc11opL2B5LwwY7phZ48E7mgRXnEpv/URKMYEi6B0ZPMsxc ikexUEPRgXld0aNEvFYBI1D2eXl5pgievlfJgXGqKXpK9ohlAEIy7GIFO1G/CfNkpY ki37ILyCG2IEmNybSWLXOGC98azAL3eO/YigXNFg= Subject: Re: [apps-discuss] APPSDIR review of draft-kucherawy-marf-source-ports-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: Fri, 20 Apr 2012 17:17:12 -0000 > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com > [mailto:barryleiba.mailing.lists@gmail.com] On Behalf Of Barry Leiba > Sent: Friday, April 20, 2012 10:08 AM > To: Murray S. Kucherawy > Cc: S Moonesamy; apps-discuss@ietf.org; draft-kucherawy-marf-source- > ports.all@tools.ietf.org; marf@ietf.org > Subject: Re: [apps-discuss] APPSDIR review of draft-kucherawy-marf- > source-ports-01 >=20 > > I haven't seen specific section call-outs done in an updating document > > before, only the "Updates" stuff on the title page. =A0Is this necessar= y? >=20 > I've seen it occasionally. I think that if the sense in which B > updates A is narrow enough that it's easy to specify what's updated, > it's quite useful to say what's updated. I doubt you'll get any > DISCUSSes if you don't, but anything that will help the reader make > better use of both specs is a good thing. Huh, OK. References added. -MSK From ve7jtb@ve7jtb.com Fri Apr 20 10:23: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 0B07321F84D2 for ; Fri, 20 Apr 2012 10:23:17 -0700 (PDT) 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=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSrye6acAKde for ; Fri, 20 Apr 2012 10:23:16 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD91D21F84C9 for ; Fri, 20 Apr 2012 10:23:15 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so6700243wgb.13 for ; Fri, 20 Apr 2012 10:23:14 -0700 (PDT) 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=etiJOJpNjoXe52drxGhqUZ4L+p51A0a3MwpL08du11M=; b=oXKK9H1R3RLg6ZLIbiUh0zDuUG6HASIr6lpovhNYibzu8vVJgQ7ihE7HyK+RmqpZfe PxoU9dBKSotZb2lLvieA5a5zCajGi59pGG8J4EsOQScZulZQIBYoAviZmu0/z9t5dAGh 18H6hBwRPLXuJsTEaK/GHBxH9vWUdlukuBIhoy6S5CFMqnwAcjolWFkV3KBmBw1N5Fxv F890JGoczyp5BPe6M+3JuK1BZWqAnSJQkS430pejTC/R+/rpnkncSkowkoBZZiEJ7AYN nQZ8M1tHtBiV6awePYSIEXbBDTE1T/C3avQirzU2K7Km4LpAyou4VTffRcG8Rfxf5ENp EqNA== Received: by 10.180.105.194 with SMTP id go2mr16941696wib.22.1334942592921; Fri, 20 Apr 2012 10:23:12 -0700 (PDT) Received: from [10.140.224.153] ([80.187.201.110]) by mx.google.com with ESMTPS id fz9sm6854920wib.3.2012.04.20.10.23.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Apr 2012 10:23:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_4D87D0D9-2D96-435C-9F60-A10949B3666A"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <7F48DDA5-EA3C-45B0-90E0-C39F06748B35@cisco.com> Date: Fri, 20 Apr 2012 19:23:06 +0200 Message-Id: <1BE3A02A-7287-4401-8B73-366390CB3676@ve7jtb.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> <7F48DDA5-EA3C-45B0-90E0-C39F06748B35@cisco.com> To: Gonzalo Salgueiro X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmYnOWxf7mvQGjldrRSuHwSdYMueANcZ98sC8iGzCbc0tGN81wRzUvp0BxY7wV3kCRHfxtU Cc: Derek Atkins , oauth@ietf.org, Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 17:23:17 -0000 --Apple-Mail=_4D87D0D9-2D96-435C-9F60-A10949B3666A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would be OK with optional XML support in the server, that way = existing endpoints will continue to work, but new ones are not required = to add something some people feel is cruft. As one of the XRD authors, I do understand the advantages of it. However I don't want to be sentimental, and force people to carry = forward things that won't be used, and may hamper adoption. And Yes I am one of the hard hatred basters that decided to redo openID = on OAuth rather than trying to graft OAuth functionality onto openID 2. = =20 Keeping what's working working is fine, but not forcing people to carry = it forward. John B. On 2012-04-20, at 7:09 PM, Gonzalo Salgueiro wrote: > Derek -=20 >=20 > On Apr 20, 2012, at 10:17 AM, Derek Atkins wrote: >=20 >> Paul, >>=20 >> "Paul E. Jones" writes: >>=20 >>> Tim, >>>=20 >>> I do not agree that it's harmful. If I removed the WF discussion off = the >>> table, I'm still having a hard time buying into everything you said = in the >>> blog post. >>>=20 >>> I implement various web services, largely for my own use. Usually, = I >>> implement all of them in XML, JSON, plain text (attribute/value = pairs), AND >>> JavaScript (for JSONP). For simple services, it's not hard. I do = it >>> because I sometimes have different wants/desires on the client side. = (For >>> more complex ones, I use XML.) >>=20 >> As an individual (and not the chair of OAUTH) I believe that the = server >> should be allowed, no encouraged, to support multiple formats for = data >> retrieval. I also believe that clients should be allowed to choose = only >> one. I am fine with JSON being Mandatory to Implement. I am NOT = okay >> with making it the only one, and I am even less okay with mandating = it >> is the ONLY one. I would say MUST JSON, MUST (or possibly SHOULD -- = you >> can convince me either way) XML, and MAY for anything else that = people >> feel stronly about (although I feel in 2012 XML and JSON are the two >> best). I also feel it is okay to say that a client MUST implement = one >> of JSON or XML, and MAY implement more. >>=20 >> >>=20 >> Note that this is a replay of the historical "MUST Implement" versus >> "MUST Use" arguments. Just because the server MUST IMPLEMENT JSON = and >> XML does not mean that a Client must use both (or even that a client >> must implement both). It is perfectly reasonable and generally >> acceptable to have a server that provides data in multiple formats >> whereas the client only supports a subset and specifies which = format(s) >> are acceptable. >>=20 >> >>=20 >=20 > This is the most sensible path forward. A MUST for JSON and XML (I'm = going with a MUST for XML to maintain backwards compatibility with RFC = 6415) on the server side and a client can choose whatever format it = wants. This is the approach taken in the current WebFinger draft. If we = reach consensus that we must mandate a client format (Note: I don't = personally think we need to), then so be it. >=20 > Cheers, >=20 > Gonzalo >=20 >> -derek >>=20 >> --=20 >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_4D87D0D9-2D96-435C-9F60-A10949B3666A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy MDE3MjMwOFowIwYJKoZIhvcNAQkEMRYEFIiZAm+jiMEDvIdzGgYmiCaMZruoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AAY08T4KttHcJve+xN184vf881siorKcuXOLal3tE2sHF5snCIfXctDakqKf6sblVgjCu6SMt5ma W1YLMZZzPEdsKyz97svgdxjYvMqF64y+MYz6W0H0Vva1MZz6skynHpcRF7n6hsYwzr8F0Lu9VV6Z bIuotFAfLsHtgC1h/nknkzlUk0TNmVPIRZ744nNFdQ6GSZdTLhybblkIMvxdIT9d1qfNBxKUIjq4 gnIDkGdupkrdQ7FrqakKpjslUI+2+yESr9sixie54dcCbKpfmid7w8w18Q05fvRe2KsTnyGOwKwB hJRbFBzK/sZtZ6gU9wRLqDR7BSYOvn7pKxxOm+UAAAAAAAA= --Apple-Mail=_4D87D0D9-2D96-435C-9F60-A10949B3666A-- From gsalguei@cisco.com Fri Apr 20 10:34: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 4385321F866C for ; Fri, 20 Apr 2012 10:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0M6KJXUr2Wt5 for ; Fri, 20 Apr 2012 10:34:42 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 4214621F85C5 for ; Fri, 20 Apr 2012 10:34:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3KHYfsf021096 for ; Fri, 20 Apr 2012 13:34:41 -0400 (EDT) Received: from dhcp-64-102-154-162.cisco.com (dhcp-64-102-154-162.cisco.com [64.102.154.162]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3KHYfiv001935; Fri, 20 Apr 2012 13:34:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: <1BE3A02A-7287-4401-8B73-366390CB3676@ve7jtb.com> Date: Fri, 20 Apr 2012 13:34:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <379ABFA6-E78C-4CD4-B7F7-6E0EC452DF74@cisco.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> <7F48DDA5-EA3C-45B0-90E0-C39F06748B35@cisco.com> <1BE3A02A-7287-4401-8B73-366390CB3676@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1257) Cc: Derek Atkins , oauth@ietf.org, Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 17:34:43 -0000 John -=20 I understand your position, I truly do. I'd even go so far as saying = that a part of me agree with you given the ubiquitousness of JSON. Two = concerns/questions come to mind: - If it is a MUST in 6415, then isn't it simply good protocol design to = maintain that same level of requirement in the discovery protocol based = entirely on it? If the answer is "no", then we can figure something out = but I'm sharing that this was our primary motivation for requiring it in = WebFinger. - Is it alarming to anyone how quickly we go through "flavor of the day" = formats? 6415 was published 6 months ago and we are already ready to = declare the mandatory format there a dinosaur that is now obsolete and = unnecessary? Cheers, Gonzalo On Apr 20, 2012, at 1:23 PM, John Bradley wrote: > I would be OK with optional XML support in the server, that way = existing endpoints will continue to work, but new ones are not required = to add something some people feel is cruft. >=20 > As one of the XRD authors, I do understand the advantages of it. >=20 > However I don't want to be sentimental, and force people to carry = forward things that won't be used, and may hamper adoption. >=20 > And Yes I am one of the hard hatred basters that decided to redo = openID on OAuth rather than trying to graft OAuth functionality onto = openID 2. =20 >=20 > Keeping what's working working is fine, but not forcing people to = carry it forward. >=20 > John B. >=20 > On 2012-04-20, at 7:09 PM, Gonzalo Salgueiro wrote: >=20 >> Derek -=20 >>=20 >> On Apr 20, 2012, at 10:17 AM, Derek Atkins wrote: >>=20 >>> Paul, >>>=20 >>> "Paul E. Jones" writes: >>>=20 >>>> Tim, >>>>=20 >>>> I do not agree that it's harmful. If I removed the WF discussion = off the >>>> table, I'm still having a hard time buying into everything you said = in the >>>> blog post. >>>>=20 >>>> I implement various web services, largely for my own use. Usually, = I >>>> implement all of them in XML, JSON, plain text (attribute/value = pairs), AND >>>> JavaScript (for JSONP). For simple services, it's not hard. I do = it >>>> because I sometimes have different wants/desires on the client = side. (For >>>> more complex ones, I use XML.) >>>=20 >>> As an individual (and not the chair of OAUTH) I believe that the = server >>> should be allowed, no encouraged, to support multiple formats for = data >>> retrieval. I also believe that clients should be allowed to choose = only >>> one. I am fine with JSON being Mandatory to Implement. I am NOT = okay >>> with making it the only one, and I am even less okay with mandating = it >>> is the ONLY one. I would say MUST JSON, MUST (or possibly SHOULD -- = you >>> can convince me either way) XML, and MAY for anything else that = people >>> feel stronly about (although I feel in 2012 XML and JSON are the two >>> best). I also feel it is okay to say that a client MUST implement = one >>> of JSON or XML, and MAY implement more. >>>=20 >>> >>>=20 >>> Note that this is a replay of the historical "MUST Implement" versus >>> "MUST Use" arguments. Just because the server MUST IMPLEMENT JSON = and >>> XML does not mean that a Client must use both (or even that a client >>> must implement both). It is perfectly reasonable and generally >>> acceptable to have a server that provides data in multiple formats >>> whereas the client only supports a subset and specifies which = format(s) >>> are acceptable. >>>=20 >>> >>>=20 >>=20 >> This is the most sensible path forward. A MUST for JSON and XML (I'm = going with a MUST for XML to maintain backwards compatibility with RFC = 6415) on the server side and a client can choose whatever format it = wants. This is the approach taken in the current WebFinger draft. If we = reach consensus that we must mandate a client format (Note: I don't = personally think we need to), then so be it. >>=20 >> Cheers, >>=20 >> Gonzalo >>=20 >>> -derek >>>=20 >>> --=20 >>> Derek Atkins 617-623-3745 >>> derek@ihtfp.com www.ihtfp.com >>> Computer and Internet Security Consultant >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From ve7jtb@ve7jtb.com Fri Apr 20 11:52: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 7B43521F8661 for ; Fri, 20 Apr 2012 11:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG1f3ilO9bR8 for ; Fri, 20 Apr 2012 11:52:38 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1963E21F8659 for ; Fri, 20 Apr 2012 11:52:36 -0700 (PDT) Received: by werb10 with SMTP id b10so7705864wer.31 for ; Fri, 20 Apr 2012 11:52:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=KE5ct838KBuxm1osYo75cK3R/TPIR0gUnJVv4uR5Mx0=; b=Zn/Vc3xPCgiC8tFUiW974pV00b4Ln0WEr2LyRphRVG/P7eS0jOk2z32ExYzcqi7Ctv VpLnk/XkIHykueStdqF3Ky3BIxxBWFULyyGYNCc2w/Rm48Cx/0D+Nx6KpPQ36P7gZ+H0 l4fsVJN8TRQevDmTD/13DmFv2oolJ6bR76KIPfERhjaVwUyO9lPCfWnu7uW3GcRIZr7s iiqKUu2YAu2eatvahp561edx7ApHqxlvnWrRDrmzYztMUYNNcRDLOsfYlhBJBjv55KGF u57isBb1BBUDsdsprcBIuuNRpiXEMAm8laONrGAhqdsYsFLqdcmNab+VV2mr/EDL20p9 HEFg== Received: by 10.216.225.12 with SMTP id y12mr4369328wep.39.1334947956140; Fri, 20 Apr 2012 11:52:36 -0700 (PDT) Received: from [10.38.132.184] (ip-109-43-0-56.web.vodafone.de. [109.43.0.56]) by mx.google.com with ESMTPS id k6sm7414380wie.9.2012.04.20.11.52.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Apr 2012 11:52:25 -0700 (PDT) References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> <7F48DDA5-EA3C-45B0-90E0-C39F06748B35@cisco.com> <1BE3A02A-7287-4401-8B73-366390CB3676@ve7jtb.com> <379ABFA6-E78C-4CD4-B7F7-6E0EC452DF74@cisco.com> In-Reply-To: <379ABFA6-E78C-4CD4-B7F7-6E0EC452DF74@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-09FADAEF-74AD-431C-AF9F-A7EBE6E17A86; protocol="application/pkcs7-signature" Message-Id: X-Mailer: iPhone Mail (9B179) From: John Bradley Date: Fri, 20 Apr 2012 20:52:36 +0200 To: Gonzalo Salgueiro X-Gm-Message-State: ALoCoQmTyp0+ycsOMX8DZVXg8df27HrVYk1d+9myaoZMnqdBAHka969PQWZZ/XjTZ9PgATyg3IoE Cc: Derek Atkins , "oauth@ietf.org" , Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 18:52:38 -0000 --Apple-Mail-09FADAEF-74AD-431C-AF9F-A7EBE6E17A86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 6415 supporting a XML format doesn't require everything that uses it to supp= ort XML.=20 John B =20 Sent from my iPhone On 2012-04-20, at 7:34 PM, Gonzalo Salgueiro wrote: > 6415 --Apple-Mail-09FADAEF-74AD-431C-AF9F-A7EBE6E17A86 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6 tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d 5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu 9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8 9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL 3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk 4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MjAxODUyNDBaMCMGCSqGSIb3DQEJBDEWBBS3PW+P 7TCX0GSF5TS7QqEJp/2mRTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQCG0W7eCX++qaO3iEFiRXbqjwSwq2mHo4dhBz/0 ljD8u1QyobZN0xvlH/VJE5S8CeH1yfLC5yrVCn5kJqaLyPIheTqbri47ip7ofQP0lhCuzod2pqAQ jfEtTeNjH8Y5S9wbRAnizShFum3ee2Mqw1h532BUL+pzBLjBK6RC0pzhnh+MMJ4WXL651r7epT3c rEnl5rnH+n6bhnx6cFbORQpjXYNAYPSeoCxqGi5ITMdbAV1UgxEoGFd+XOmtQ5rxUJIAQcFSBXKz FyP5Z0PYT1VhdbrgTV8odIaa3+GEyJg237wVcAEdqhpPJCGKe7Lr8WiTUa+/iArYtI7IkzWWC9gc AAAAAAAA --Apple-Mail-09FADAEF-74AD-431C-AF9F-A7EBE6E17A86-- From eran@hueniverse.com Fri Apr 20 12:07: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 BE81F21F85C3 for ; Fri, 20 Apr 2012 12:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bumz1KF70GiL for ; Fri, 20 Apr 2012 12:07:07 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id 362C121F85AC for ; Fri, 20 Apr 2012 12:07:07 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id 0K761j0070CJzpC01K76KG; Fri, 20 Apr 2012 12:07:06 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Fri, 20 Apr 2012 12:07:06 -0700 From: Eran Hammer To: John Bradley , Gonzalo Salgueiro Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHybAzEHp1VSTw0S1QHL3sl+515akEidA Date: Fri, 20 Apr 2012 19:07:06 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FF5DAD@P3PWEX2MB008.ex2.secureserver.net> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> <7F48DDA5-EA3C-45B0-90E0-C39F06748B35@cisco.com> <1BE3A02A-7287-4401-8B73-366390CB3676@ve7jtb.com> <379ABFA6-E78C-4CD4-B7F7-6E0EC452DF74@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Derek Atkins , Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 19:07:07 -0000 It does unless updated. 6415 guarantees that if you send a request to /host-meta you will get XML u= nless you ask for JSON, in which case you MIGHT get JSON. It also defined /host-meta.json which MIGHT be supported and if it is, guar= antees JSON. Simplest way forward is to focus on /host-meta.json as 6415 says nothing ab= out having to support /host-meta if you offer /host-meta.json... this is a = bit of a hack but will work. IOW, protocols that want only JSON as required= can mandate /host-meta.json support and allow /host-meta support. This means XML clients will need to understand JSON in case the server does= n't offer the XML default location. EH > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of John Bradley > Sent: Friday, April 20, 2012 11:53 AM > To: Gonzalo Salgueiro > Cc: Derek Atkins; oauth@ietf.org; Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > Discovery (SWD) >=20 > 6415 supporting a XML format doesn't require everything that uses it to > support XML. >=20 > John B >=20 > Sent from my iPhone >=20 > On 2012-04-20, at 7:34 PM, Gonzalo Salgueiro wrote: >=20 > > 6415 From derhoermi@gmx.net Fri Apr 20 12:45: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 95B5011E8079 for ; Fri, 20 Apr 2012 12:45:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHeNsBv5SHnt for ; Fri, 20 Apr 2012 12:45:10 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id BE7B311E8085 for ; Fri, 20 Apr 2012 12:45:09 -0700 (PDT) Received: (qmail invoked by alias); 20 Apr 2012 19:45:07 -0000 Received: from dslb-094-223-212-003.pools.arcor-ip.net (EHLO HIVE) [94.223.212.3] by mail.gmx.net (mp069) with SMTP; 20 Apr 2012 21:45:07 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/kVi4mvtHkmpomU8QC2XD+geZN42hzdEBOkWzmiw apnD6ZkX8FFNVT From: Bjoern Hoehrmann To: Tony Hansen Date: Fri, 20 Apr 2012 21:45:08 +0200 Message-ID: <2ee3p79ijn5orc4i6m85hqfm7ta4vv55mb@hive.bjoern.hoehrmann.de> References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com> <4F87EBD4.90501@gmx.de> <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> In-Reply-To: <4F901485.20800@maillennium.att.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org, www-tag@w3.org Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 19:45:12 -0000 * Tony Hansen wrote: >So I've added these Fragment identifier considerations sections to the >suffixes that have an underlying media type registration. > > Media types using "+json" MUST accept any fragment identifiers > defined for "application/json". Specific media types may > identify additional fragment identifier considerations. This says that "+json" cannot be used for JSON types where fragment identifiers are of any concern since any future specification of the application/json type may override such registrations in incompatible ways. This seems to be missing the point of why we would have "+json" to begin with. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From gffletch@aol.com Fri Apr 20 12: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 25E6621F8638; Fri, 20 Apr 2012 12:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-bRWOA5rpJk; Fri, 20 Apr 2012 12:59:01 -0700 (PDT) Received: from imr-da02.mx.aol.com (imr-da02.mx.aol.com [205.188.105.144]) by ietfa.amsl.com (Postfix) with ESMTP id 1B64F21F8637; Fri, 20 Apr 2012 12:58:59 -0700 (PDT) Received: from mtaout-mb02.r1000.mx.aol.com (mtaout-mb02.r1000.mx.aol.com [172.29.41.66]) by imr-da02.mx.aol.com (8.14.1/8.14.1) with ESMTP id q3KJwQ1A003342; Fri, 20 Apr 2012 15:58:26 -0400 Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 3305CE000141; Fri, 20 Apr 2012 15:58:26 -0400 (EDT) Message-ID: <4F91BFE1.8070803@aol.com> Date: Fri, 20 Apr 2012 15:58:25 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Christian Weiske References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9B6B7851-5212-4313-88B5-DBBA7BC9BEDC@gmail.com> <20120419181533.39c1de8e@bogo> In-Reply-To: <20120419181533.39c1de8e@bogo> Content-Type: multipart/alternative; boundary="------------000302080300090306060402" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1334951906; bh=IU46Pe+rEuVc4QWbmQzjfnPugyqkfojtfoJeCvVJmik=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=PI39DqLwkNVRrBYp0vaLS5X7vYTPqqvi1bgjHsDmlnPIUPoUtgje3BSc0WvljeQBS auyXemj8V8vl3xbVcSKKMqvV7yrOjbc+x6qJDQ0nKw6BVcmQO0VyY/nah/59yMZjCW HlQJTSDMM1gaMqvkNUUjQ7T1nLsB6IzrQN4jYPsY= X-AOL-SCOLL-SCORE: 0:2:448337120:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29424f91bfe27e8c X-AOL-IP: 10.181.186.254 Cc: Blaine Cook , "oauth@ietf.org WG" , apps-discuss@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 19:59:02 -0000 This is a multi-part message in MIME format. --------------000302080300090306060402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit And the AOL is working as well (though it was down for a bit:) On 4/19/12 12:15 PM, Christian Weiske wrote: > Hello Dick, > > >>> Gmail, aol, and yahoo all put up webfinger endpoints, but there >>> hasn't been much movement, I think due to the chicken and egg >>> nature of adoption around decentralized tools. >> A couple months ago I was checking out what was up. The AOL and Yahoo >> endpoints no longer worked. The Google one still did. > Yahoo actually still serves the main entry point at > http://www.yahoo.com/.well-known/host-meta > that gives out the OpenID all accounts can use. > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------000302080300090306060402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit And the AOL is working as well (though it was down for a bit:)

On 4/19/12 12:15 PM, Christian Weiske wrote: 
Hello Dick,



Gmail, aol, and yahoo all put up webfinger endpoints, but there
hasn't been much movement, I think due to the chicken and egg
nature of adoption around decentralized tools.


      

        
A couple months ago I was checking out what was up. The AOL and Yahoo
endpoints no longer worked. The Google one still did.


      

      
Yahoo actually still serves the main entry point at
http://www.yahoo.com/.well-known/host-meta
that gives out the OpenID all accounts can use.



      

      

      

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


    

    

  


--------------000302080300090306060402--

From stephen.farrell@cs.tcd.ie  Fri Apr 20 19:41: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 BE2A311E8096; Fri, 20 Apr 2012 19:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK4wUbdfv091; Fri, 20 Apr 2012 19:41:50 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 22B1411E808A; Fri, 20 Apr 2012 19:41:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C810A17147D; Sat, 21 Apr 2012 03:41:48 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334976104; bh=ICPLx86NWbFknU Qx2u4DGPOjo20qKC3hpjyw39tCNSI=; b=yfUVSBGkmwsfCPuXiPkleb5EJ4QBKs ytMa1hQaQhyrMzT1kIEhzHVBFtqf+leB87TdGDRn+35kgj/LUaiNQvH84A6U4pwm XPWWNWdrCVbSw2Pgy7hBhGkLWc68fyLWg0qLuSgRhv291Z/1SNiah5VWGAw8aDr5 vQu6H+l+DXHKEWl9cQi+QS0aqa2W73TxzJ2XEOgxgxZ2WiylbiyEcs1Mmueu22ji Q52qyjTWmAtFyTLMsDV2r2OBuPcpUmMcwedfwoCSdfN76TUtU3gqAghHkPXtJpR2 Xu/4TOEnvh9NbYSgTclETo48fpvZL8I8wLVL3WCATgvpfrXYxXJZmMkA==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id p6k32XsAcmT6; Sat, 21 Apr 2012 03:41:44 +0100 (IST)
Received: from [1.202.85.154] (unknown [1.202.85.154]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id BF055171474; Sat, 21 Apr 2012 03:41:34 +0100 (IST)
Message-ID: <4F921E53.8030109@cs.tcd.ie>
Date: Sat, 21 Apr 2012 03:41:23 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Michael Thomas 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com>
In-Reply-To: <4F917545.5080103@mtcc.com>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Derek Atkins , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Apr 2012 02:41:54 -0000

On 04/20/2012 03:40 PM, Michael Thomas wrote:
> 
> Why not MUST ASN.1 while you're at it? JSON has won in case
> you'all haven't noticed it.

Well, I also remember when XML won over ASN.1, or
was that some RPC thing? Seems like a new format wins
about every five years or so, once the last winner
gets enough crap added. (JSON pointer seems like the
start of a nice slippery slope to me.)

I've no opinion as to what should be MTI here however,
just a side comment.

S

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

From paulej@packetizer.com  Fri Apr 20 20:17: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 D4DB621E8019 for ; Fri, 20 Apr 2012 20:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.372
X-Spam-Level: 
X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6WelIgXs91e for ; Fri, 20 Apr 2012 20:17:03 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8230921E8011 for ; Fri, 20 Apr 2012 20:17:03 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3L3GwCj006152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 23:16:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334978220; bh=p26J7xDcyZY7XUPBb6uUZJjnSVmssSNYAjhL8Vk55Ys=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=h2Yrfc6OBWJlvOKt/sju1EUv+SoLRPi7YmeRPSS1cbhNicRpqwnEtH890b8pfFHu5 EfxeA2MNj5cTiU9sKE0G42XZMoYUwPGfAbUMd2mQVoKNxVkiJNgldHc9kI1aKH89gA XWj6edY5oAJvMyO7eL2O8laJSN3HgX/w0PRwcxCs=
From: "Paul E. Jones" 
To: "'Pelle Wessman'" , "'Mike Jones'" 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> 
In-Reply-To: 
Date: Fri, 20 Apr 2012 23:17:21 -0400
Message-ID: <0a7001cd1f6d$45561c60$d0025520$@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: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAI8MBwxAc/xlwgBkQ/oMAISbp34laaaM7A=
Content-Language: en-us
Cc: 'Apps Discuss' 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple	Web	Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Apr 2012 03:17:08 -0000

Pelle,

> You make "updating some servers" sound easy - from eg. an OStatus
> perspective that's everything but easy. StatusNet and others
> implementations are deployed on a large amount of servers maintained by a
> large amount of users - often individuals hosting their own instances. As
> I see it it will be challenging for OStatus to support the specification
> this discussion results in if it that breaks backwards compatibility with
> all existing deployments.
> 
> I see no reason to make the resource-parameter mandatory - the benefits
> that comes with it makes it an obvious choice for everyone that can
> support it and those who can't support it can't support it even if we make
> the resource-parameter mandatory.

If the OStatus clients continued to operate as they do, then a change in the
spec would not cause an immediate breakage.  Servers could be updated with
time and clients could follow subsequently.  Is that possible?

In any case, I appreciate the challenge, which is why we made this parameter
optional to support.  That addresses both the forward- and backward-
compatibility issues.

> I also personally can see a need for being able to host discovery data
> statically from eg. an indie-web perspective - the popularity of Jekyll
> like systems and Jekyll hosts like GitHub Pages locks up many domains in
> hosts that don't support dynamic pages. To be possible to discover any
> information about anything on such domains you would need to support eg.
> static host-meta documents. A standard that can't be deployed on a regular
> persons site is in my opinion a bad standard.

If the site is so small, it could ignore what's requested and return a
static page.  The "subject" would not match, but the client should take note
of that.

How would you host LRDD on a static site?  Something like this:
http://example.com/lrdd/acct:user@example.com

That would certainly work and you are right that the "resource" parameter
would prevent that from working.
 
> While making it mandatory for all new deployments to support JSON I can
> see a problem in making new clients expect all responses to be in JSON.
> For backwards compatibility it would at least be good to mention the
> existence of XML-data in such a way that clients know that that should
> expect at least older WebFinger documents to give XML-responses.

I'm still favorable to requiring both XML and JSON on the server.  If this
were extremely complex documents, I might by sympathetic to a concern over
complexity.  But, supporting both formats is fairly simple.

Paul



From paulej@packetizer.com  Fri Apr 20 20:33: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 16EB111E8099; Fri, 20 Apr 2012 20:33:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.379
X-Spam-Level: 
X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJhs2Rhy3thz; Fri, 20 Apr 2012 20:33:46 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id ACFA011E809B; Fri, 20 Apr 2012 20:33:46 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3L3Xjwa006602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 23:33:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334979226; bh=7asx+dAcTcnbVW7JJuWAQg3hlJHRj0hk3THAnh4+8Dc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=pYN08uIQwe6j6ib8tUxCW2AwNvti5R95WfssdLPXGQQF1lu6U7W3lNwJXrtakck4j 1SqncHDRytxxpAlM+W5nCAP2Zv9KKctY8nrbFXlofBWl5q4ulNU2+HbnSFezsf1X+R tJSBjD/Y6Q/TAk/Szw5gS6f5IHjEyMuLnnhRr4w4=
From: "Paul E. Jones" 
To: "'Derek Atkins'" 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net>	<4F8852D0.4020404@cs.tcd.ie>	<9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>		<9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com>	<4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com>	<091401cd1ea3$e159be70$a40d3b50$@packetizer.com>		<091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> 
In-Reply-To: 
Date: Fri, 20 Apr 2012 23:34:08 -0400
Message-ID: <0a7401cd1f6f$9cb98fd0$d62caf70$@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: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAIw2f/NAUQ5aEgCO5nRqZW2qKXg
Content-Language: en-us
Cc: oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Apr 2012 03:33:51 -0000

Derek,

> > I do not agree that it's harmful. If I removed the WF discussion off
> > the table, I'm still having a hard time buying into everything you
> > said in the blog post.
> >
> > I implement various web services, largely for my own use.  Usually, I
> > implement all of them in XML, JSON, plain text (attribute/value
> > pairs), AND JavaScript (for JSONP).  For simple services, it's not
> > hard.  I do it because I sometimes have different wants/desires on the
> > client side.  (For more complex ones, I use XML.)
> 
> As an individual (and not the chair of OAUTH) I believe that the server
> should be allowed, no encouraged, to support multiple formats for data
> retrieval.  I also believe that clients should be allowed to choose only
> one.  I am fine with JSON being Mandatory to Implement.  I am NOT okay
> with making it the only one, and I am even less okay with mandating it is
> the ONLY one.  I would say MUST JSON, MUST (or possibly SHOULD -- you can
> convince me either way) XML, and MAY for anything else that people feel
> stronly about (although I feel in 2012 XML and JSON are the two best).  I
> also feel it is okay to say that a client MUST implement one of JSON or
> XML, and MAY implement more.

I hope I didn't mislead you with my statements.  I definitely was not
suggesting we have more than XML and JSON on the server.  I was merely
pointing out that I've found it fairly simple on the server side to offer
multiple formats.  Spewing data out in some format is trivial, usually.

My preference has been MUST for XML and JSON since 1) XML is already a MUST
in RFC 6415 and we'd have to "break" what is there now to remove the MUST
and 2) people are clearly demanding JSON.
 
> 
> 
> Note that this is a replay of the historical "MUST Implement" versus "MUST
> Use" arguments.  Just because the server MUST IMPLEMENT JSON and XML does
> not mean that a Client must use both (or even that a client must implement
> both).  It is perfectly reasonable and generally acceptable to have a
> server that provides data in multiple formats whereas the client only
> supports a subset and specifies which format(s) are acceptable.
> 
> 

Definitely... clients would only have to implement what they prefer.  Only
the server would be required to implement both.  (Still, there is contention
over requiring both on the server.)

Paul



From paulej@packetizer.com  Fri Apr 20 21:10: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 7BE3521F84CE; Fri, 20 Apr 2012 21:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.385
X-Spam-Level: 
X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li4SsUxLjB7T; Fri, 20 Apr 2012 21:10:54 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 20C3311E8096; Fri, 20 Apr 2012 21:10:54 -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 q3L4AqlP007576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Apr 2012 00:10:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334981453; bh=KDwCeSgGzRvPy3FXQQ+8ar2XSBUKPT0PE4xFuUK9mfg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Q6+xsuLGqdBvPVyzWK+AW9FjgxJrSAwCjqf3nbZLHJDfz53FYCw6iES0LdmHjzOsq xU3nMsKQe1+Yl/r2mDyrCygnBKX8WY3t65Zfwbl+VYzr1CMWPHOX1W3JzufWx037lv Lin3BmgNqUseSdP9M/7LuTtndGdenzKM/EKosevs=
From: "Paul E. Jones" 
To: "'Michael Thomas'" , "'Derek Atkins'" 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917CE6.2060904@mtcc.com>
In-Reply-To: <4F917CE6.2060904@mtcc.com>
Date: Sat, 21 Apr 2012 00:11:15 -0400
Message-ID: <0a7601cd1f74$cc5a26a0$650e73e0$@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: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAIw2f/NAUQ5aEgCO5nRqQE1p72claz9LfA=
Content-Language: en-us
Cc: oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Apr 2012 04:10:58 -0000

Mike,

> On 04/20/2012 07:17 AM, Derek Atkins wrote:
> >  Note that this is a replay of the historical "MUST
> > Implement" versus "MUST Use" arguments. Just because the server MUST
> > IMPLEMENT JSON and XML does not mean that a Client must use both (or
> > even that a client must implement both). It is perfectly reasonable
> > and generally acceptable to have a server that provides data in
> > multiple formats whereas the client only supports a subset and
> > specifies which format(s) are acceptable.  -derek
> 
> To Paul's point about how easy it is for a server to support both, I'd
> retort that it's equally easy for a client to gin up JSON instead of XML.

I don't follow.

I agree I could write a client that could do JSON easily.
I agree I could write a client that could do XML easily.

What is a pain on the client side is conditional code that has to be
followed in order to consume whatever the server wants to send.  The client
should have a single code path knowing it will get what it wants, ether XML
or JSON.

Granted, the server has to have a conditional statement and generate XML or
JSON as requested.  However, generating either is trivial.  Really, I did it
in minutes.  We're not talking about huge complex data structures here with
WebFinger.

> Pity the poor programmer who can't get their head around that gigantic
> change. On the other hand, having to support XML and JSON is an ongoing
> maintenance headache server-side. Why do it?

Would we expect to see a lot of changes to the data structures used by
WebFinger?  That's really the only ongoing maintenance issue.  Don't touch
the code that produces the XML or JSON and there is no ongoing maintenance.

> There isn't even the dubious
> religious war like back in the day saying that binary encoded ASN.1 was
> "better/faster/stacks and cleans dishes" than "human readable" XML.  XML
> is just a clunky and past its prime text encoding at this point. Requiring
> it smacks of nostalgia to me.

I disagree with you on that one.  First, ASN.1 is better for defining
protocols, so long as you stay away from the complex stuff. Basic ASN.1
looks a lot like C and produces C data structures that can be readily read,
decoded, and consumed in C code.  Rarely, rarely do I see decoding issues
when using ASN.1, whereas issues pop up quite often with text protocols,
especially things like SIP where a semi-colon in the wrong place breaks
things.  But, let's not start that debate again ;-)

XML *can* be big and clunky.  As you've well noticed, I can also write
lengthy emails that seem to have more typos as the evening progresses. :-)

However, XML can be a very compact encoding and it's extremely readable.

I just did a query on my server to see the XML vs. JSON output.  The XRD
document provided was 1032 octets.  The JRD document was 1077 octets.
Removing every possible space and making both formats hard as heck to read,
JSON was 837 and XML was 940.  I'm hard pressed to say that's makes much
difference.  Further, I can't read either of them now without some effort.

Considering that a lot of WebFinger use (I suspect) is going to be
server-to-server interaction, XML seems like a reasonable format to retain.
That, and the fact it is already mandatory in RFC 6415 and deployed out
there.

It's not nostalgia for me.  XML is a very well-structured, readable format.
No objection to JSON, but I really don't understand the clamoring for JSON.
I guess more precisely, I don't understand the disdain for XML.  Is it
because people created hideously complex XML data structures and feel pain
for having done that?  XRD is not that kind of document.

Paul



From paulej@packetizer.com  Fri Apr 20 21:24: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 A3FCD11E809D; Fri, 20 Apr 2012 21:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.391
X-Spam-Level: 
X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-iEXiE6iwzY; Fri, 20 Apr 2012 21:24:27 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1047211E8091; Fri, 20 Apr 2012 21:24: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 q3L4O1FV007965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Apr 2012 00:24:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334982243; bh=rq9Qhie9YBoqXCMq5TqCDLkTzRbzBmcowU6iWcZz2EE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=RjKH79HhelwJ1XwkspthT9PjI5y8qLjApQlJK3U49oS2KtIDTge727dwIbHA1k2P6 qpyMk8v0vquUvUaj+7Izz0QnzFf8tEmK7rVu61bRxK7B92260H5jR8UFlOudl3ffpr 9F5g+8Yp97cIijieEC0/QJpZsWeSk1esxeVpiBZc=
From: "Paul E. Jones" 
To: "'Daniel Renfer'" , "'William Mills'" 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <1334933123.53510.YahooMailNeo@web31803.mail.mud.yahoo.com> 
In-Reply-To: 
Date: Sat, 21 Apr 2012 00:24:25 -0400
Message-ID: <0a7801cd1f76$a33d7bd0$e9b87370$@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: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAI8MBwxAc/xlwgBkQ/oMAJ4RBC2AnnCY7eVj8CiwA==
Content-Language: en-us
Cc: oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Apr 2012 04:24:31 -0000

Daniel,

If the resource parameter is required, what would break are new clients =
that rely on it.  Thus, we have a forward-compatibility issue.  That is =
an issue, which is why we made it optional.  (But I've said that.)

I think a question is whether we can accept this "new client" issue as =
an interim situation while servers are upgraded to support the resource =
parameter.  If people feel the answer is "no" then we need to keep it =
optional.  If "yes", we could make it mandatory.

We also have those who want to be able to run WebFinger on static sites. =
 It's hard to ignore that if there are really those who want to do it.

On the SWD side, there is clearly a desire to be able to make a single =
query and get a single response.  I can appreciate that, since otherwise =
one would have to perform two queries and construct the JRD on the =
client side (or at least go sifting through replies looking for the =
proper link relations and values).

Paul

> -----Original Message-----
> From: Daniel Renfer [mailto:duck@kronkltd.net]
> Sent: Friday, April 20, 2012 11:09 AM
> To: William Mills
> Cc: Mike Jones; Paul E. Jones; Murray S. Kucherawy; oauth@ietf.org; =
Apps
> Discuss
> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web =
Discovery
> (SWD)
>=20
> The point is that existing WF clients have been written to not use the
> resource parameter because in the past, that parameter hasn't been
> available or hasn't been reliable.
>=20
> If the resource parameter is required, this older method of fetching =
the
> host meta and constructing the url to fetch the user meta would still
> continue to work just as before.
>=20
> Even if the resource parameter were made mandatory today, real world =
WF
> clients would still have to account for the possibility of resource
> queries resulting in an error or incorrect information. Given the =
number
> of currently deployed WF-enabled services and the difficulty in =
upgrading
> all of them, this is going to be the case for some time.
>=20
> resource parameters should be strongly encouraged, but not required.
>=20
> On Fri, Apr 20, 2012 at 10:45 AM, William Mills 
> wrote:
> > So you are guaranteeing that there are no clients using WF today?
> >
> > ________________________________
> > From: Mike Jones 
> > To: Paul E. Jones ; 'Murray S. Kucherawy'
> > ; "oauth@ietf.org" ; 'Apps =
Discuss'
> > 
> > Sent: Thursday, April 19, 2012 10:48 PM
> > Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web
> > Discovery
> > (SWD)
> >
> > To be clear, making this mandatory would break no clients.  It would
> > require updating some servers, just as requiring JSON would.  This
> > seems like a fair tradeoff when it makes an appreciable difference =
in
> > user interface latency in some important scenarios.  If you and the
> > other key WebFinger supporters can agree to making "resource" =
support
> > mandatory and requiring JSON, I believe we may have a path forward.
> >
> >                 Cheers,
> >                 -- Mike
> >
> > -----Original Message-----
> > From: Paul E. Jones [mailto:paulej@packetizer.com]
> > Sent: Thursday, April 19, 2012 10:39 PM
> > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps =
Discuss'
> > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> > Discovery
> > (SWD)
> >
> > That's correct.  We could certainly make it mandatory, but the =
reason
> > it isn't is to maintain backward compatibility with existing
> deployments.
> >
> > I think we should always think carefully when we decide to make a
> > change that breaks backward-compatibility.  This is one change that
> would do that.
> >
> > Paul
> >
> >> -----Original Message-----
> >> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> >> Sent: Friday, April 20, 2012 1:10 AM
> >> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps
> Discuss'
> >> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> >> Discovery
> >> (SWD)
> >>
> >> Currently, support for the "resource" parameter is optional, as per
> >> the following (correct?):
> >>
> >>    Note that support for the "resource" parameter is optional, but
> >>    strongly RECOMMENDED for improved performance.  If a server does
> >>not
> >>    implement the "resource" parameter, then the server's host
> >>metadata
> >>    processing logic remains unchanged from RFC 6415.
> >>
> >> To truly support 1, this would need to be changed to REQUIRED, =
correct?
> >>
> >>                 -- Mike
> >>
> >> -----Original Message-----
> >> From: Paul E. Jones [mailto:paulej@packetizer.com]
> >> Sent: Thursday, April 19, 2012 8:16 PM
> >> To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps =
Discuss'
> >> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> >> Discovery
> >> (SWD)
> >>
> >> Mike,
> >>
> >> > There are two criteria that I would consider to be essential
> >> > requirements for any resulting general-purpose discovery
> specification:
> >> >
> >> > 1.  Being able to always discover per-user information with a
> >> > single GET (minimizing user interface latency for mobile devices,
> >> > etc.)
> >>
> >> WF can do that.  See:
> >> $ curl -v https://packetizer.com/.well-known/\
> >>          host-meta.json?resource=3Dacct:paulej@packetizer.com
> >>
> >> > 2.  JSON should be required and it should be the only format
> >> > required (simplicity and ease of deployment/adoption)
> >>
> >> See the above example.  However, I also support XML with my server.
> >> It took me less than 10 minutes to code up both XML and JSON
> >> representations.
> >> Once the requested format is determined, the requested URI is
> >> determined, data is pulled from the database, spitting out the
> >> desired format is trivial.
> >>
> >> Note, and very important note: supporting both XML and JSON would
> >> only be a server-side requirement.  The client is at liberty to use
> >> the format it prefers.  I would agree that forcing a client to
> >> support both would be unacceptable, but the server?  Nothing to it.
> >>
> >> > SWD already meets those requirements.  If the resulting spec =
meets
> >> > those requirements, it doesn't matter a lot whether we call it
> >> > WebFinger or Simple Web Discovery, but I believe that the
> >> > requirements discussion is probably the most productive one to be
> >> > having at this point - not the starting point document.
> >>
> >> I believe WebFinger meets those requirements.  We could debate
> >> whether XML should be supported, but I'll note (again) that it is
> >> there in RFC 6415.
> >> That document isn't all that old and, frankly, it concerns me that =
we
> >> would have a strong preference for format A one week and then =
Format
> >> B the next.
> >> We are where we are and I can see reason for asking for JSON, but =
no
> >> good reason to say we should not allow XML (on the server side).
> >>
> >> Paul
> >>
> >>
> >>
> >
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >


From paulej@packetizer.com  Fri Apr 20 21:39: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 3C53611E80A4; Fri, 20 Apr 2012 21:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55A+f-g4vcIQ; Fri, 20 Apr 2012 21:39:09 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 428F611E8096; Fri, 20 Apr 2012 21:39:08 -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 q3L4d7D3008366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Apr 2012 00:39:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334983147; bh=kQyg8yLylLIR5T9g2XktRYKeYgnSFcyhiz5GHdF5ZIU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=jInKwDCk6HeAl+5r8E3VsRdo3jsEo7js62KkEn9avKQXr/AHalN4fz18fi/rYFBbW OfAZMT/K8s8AFWRvTnRJK1QIstjTCseRIdTZsur0JGaq5q1o573BhIFV+TU3GAnkgZ TPy72IMC9wb7c3C4kFDDJXKLTO9TP2NP5ekbvIiI=
From: "Paul E. Jones" 
To: "'Michael Thomas'" , "'Derek Atkins'" 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com>
In-Reply-To: <4F917545.5080103@mtcc.com>
Date: Sat, 21 Apr 2012 00:39:30 -0400
Message-ID: <0a7a01cd1f78$be37b1b0$3aa71510$@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: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAIw2f/NAUQ5aEgCO5nRqQLuh1nulZ9D7dA=
Content-Language: en-us
Cc: oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Apr 2012 04:39:13 -0000

Michael,

> > am NOT okay with making it the only one, and I am even less okay with
> > mandating it is the ONLY one.  I would say MUST JSON, MUST (or
> > possibly SHOULD -- you can convince me either way) XML, and MAY for
> > anything else that people feel stronly about (although I feel in 2012
> > XML and JSON are the two best).  I also feel it is okay to say that a
> > client MUST implement one of JSON or XML, and MAY implement more.
> >
> >
> 
> Why not MUST ASN.1 while you're at it? JSON has won in case you'all
> haven't noticed it.

"Won"? Data formats are not popularity contests.  This is the Internet
Engineering Task Force, not the Internet Entertainment Task Force.  (That
said, a few recent message have been entertaining.)  We should be building
and designing systems for longevity.  XML was absolutely *the* thing just a
few years ago and now JSON is all the rage.  How long will that last before
"the next great thing" comes along?

There are many people who value XML still, in spite a growth in the use of
JSON.

Paul



From ht@inf.ed.ac.uk  Sat Apr 21 08:12: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 0CDD921F85D7 for ; Sat, 21 Apr 2012 08:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.566
X-Spam-Level: 
X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6r8sCi05nfMe for ; Sat, 21 Apr 2012 08:12:29 -0700 (PDT)
Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id E13B921F858B for ; Sat, 21 Apr 2012 08:12:28 -0700 (PDT)
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 q3LFCB5r003390; Sat, 21 Apr 2012 16:12:15 +0100 (BST)
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 q3LFCA6S029865; Sat, 21 Apr 2012 16:12:10 +0100
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 q3LFC9iH024768;  Sat, 21 Apr 2012 16:12:09 +0100
Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3LFC8Xh024764; Sat, 21 Apr 2012 16:12:08 +0100
X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: Bjoern Hoehrmann 
References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com>  <4F87EBD4.90501@gmx.de>  <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> <2ee3p79ijn5orc4i6m85hqfm7ta4vv55mb@hive.bjoern.hoehrmann.de>
From: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Sat, 21 Apr 2012 16:12:08 +0100
In-Reply-To: <2ee3p79ijn5orc4i6m85hqfm7ta4vv55mb@hive.bjoern.hoehrmann.de> (Bjoern Hoehrmann's message of "Fri, 20 Apr 2012 21:45:08 +0200")
Message-ID: 
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (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: www-tag@w3.org, Tony Hansen , apps-discuss@ietf.org
Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Apr 2012 15:12:33 -0000

Bjoern Hoehrmann writes:

> * Tony Hansen wrote:
>>So I've added these Fragment identifier considerations sections to the 
>>suffixes that have an underlying media type registration.
>>
>>     Media types using "+json" MUST accept any fragment identifiers
>>     defined for "application/json". Specific media types may
>>     identify additional fragment identifier considerations.
>
> This says that "+json" cannot be used for JSON types where fragment
> identifiers are of any concern since any future specification of the
> application/json type may override such registrations in incompatible
> ways. This seems to be missing the point of why we would have "+json"
> to begin with.

Or, it implies any update to a syntax schema registration such as
application/json has a responsibility to its "deployed base".  Comes
with the territory.

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 internet-drafts@ietf.org  Sat Apr 21 09:26:54 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE9E21F85CD; Sat, 21 Apr 2012 09:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-ZuXruZzyHB; Sat, 21 Apr 2012 09:26:50 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAD421F85D7; Sat, 21 Apr 2012 09:26:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120421162650.14109.47152.idtracker@ietfa.amsl.com>
Date: Sat, 21 Apr 2012 09:26:50 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-02.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, 21 Apr 2012 16:26: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 Worki=
ng Group of the IETF.

	Title           : Update to MIME regarding Charset Parameter Handling in T=
extual Media Types
	Author(s)       : Alexey Melnikov
                          Julian F. Reschke
	Filename        : draft-ietf-appsawg-mime-default-charset-02.txt
	Pages           : 6
	Date            : 2012-04-21

   This document changes RFC 2046 rules regarding default charset
   parameter values for text/* media types to better align with common
   usage by existing clients and servers.

Editorial Note (To be removed by RFC Editor)

   Discussion of this draft should take place on the Apps Area Working
   Group mailing list (apps-discuss@ietf.org), which is archived at
   .


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-mime-default-charset=
-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-mime-default-charset-=
02.txt


From Michael.Jones@microsoft.com  Sat Apr 21 09:37: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 AA3B321F85D2 for ; Sat, 21 Apr 2012 09:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.379
X-Spam-Level: 
X-Spam-Status: No, score=-5.379 tagged_above=-999 required=5 tests=[AWL=1.220,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mcg2LZoRWVE2 for ; Sat, 21 Apr 2012 09:37:46 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9F45521F8616 for ; Sat, 21 Apr 2012 09:37:46 -0700 (PDT)
Received: from mail167-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Sat, 21 Apr 2012 16:37:46 +0000
Received: from mail167-tx2 (localhost [127.0.0.1])	by mail167-tx2-R.bigfish.com (Postfix) with ESMTP id 04E9F120278; Sat, 21 Apr 2012 16:37:46 +0000 (UTC)
X-SpamScore: -36
X-BigFish: VS-36(zzbb2dI9371I542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25h)
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
Received-SPF: pass (mail167-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 mail167-tx2 (localhost.localdomain [127.0.0.1]) by mail167-tx2 (MessageSwitch) id 13350262637333_14081; Sat, 21 Apr 2012 16:37:43 +0000 (UTC)
Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.247])	by mail167-tx2.bigfish.com (Postfix) with ESMTP id E87FB1A0046; Sat, 21 Apr 2012 16:37:42 +0000 (UTC)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 21 Apr 2012 16:37:41 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0283.004; Sat, 21 Apr 2012 16:37:41 +0000
From: Mike Jones 
To: "Paul E. Jones" , 'Michael Thomas' ,  'Derek Atkins' 
Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
Thread-Index: AQHNH3TGzG4/4A/7x0C5JawAKFEmIJald/WQ
Date: Sat, 21 Apr 2012 16:37:40 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943664920DE@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917CE6.2060904@mtcc.com> <0a7601cd1f74$cc5a26a0$650e73e0$@packetizer.com>
In-Reply-To: <0a7601cd1f74$cc5a26a0$650e73e0$@packetizer.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: 'Apps Discuss' 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery	(SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Apr 2012 16:37:51 -0000

I want to completely agree with what Paul wrote: "What is a pain on the cli=
ent side is conditional code that has to be followed in order to consume wh=
atever the server wants to send.  The client should have a single code path=
 knowing it will get what it wants".

BTW, this is also part of the argument for making the resource parameter re=
quired.  Paul's example of:
	curl -v https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:=
paulej@packetizer.com
should work on all deployments - not just packetizer.com, so clients can re=
ly on it working (and not have to have conditional code to try again in a d=
ifferent way when it doesn't).

As a design principle, to the extent there's any complexity, it should be p=
ushed to the servers, rather than the clients, as clients will vastly outnu=
mber servers.    The solution should be as simple for clients to use as pos=
sible, to facilitate adoption.

				Best wishes,
				-- Mike

(moved OAuth to bcc)	=09

-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Paul E. Jones
Sent: Friday, April 20, 2012 9:11 PM
To: 'Michael Thomas'; 'Derek Atkins'
Cc: oauth@ietf.org; 'Apps Discuss'
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery =
(SWD)

Mike,

> On 04/20/2012 07:17 AM, Derek Atkins wrote:
> >  Note that this is a replay of the historical "MUST=20
> > Implement" versus "MUST Use" arguments. Just because the server MUST=20
> > IMPLEMENT JSON and XML does not mean that a Client must use both (or=20
> > even that a client must implement both). It is perfectly reasonable=20
> > and generally acceptable to have a server that provides data in=20
> > multiple formats whereas the client only supports a subset and=20
> > specifies which format(s) are acceptable.  -derek
>=20
> To Paul's point about how easy it is for a server to support both, I'd=20
> retort that it's equally easy for a client to gin up JSON instead of XML.

I don't follow.

I agree I could write a client that could do JSON easily.
I agree I could write a client that could do XML easily.

What is a pain on the client side is conditional code that has to be follow=
ed in order to consume whatever the server wants to send.  The client shoul=
d have a single code path knowing it will get what it wants, ether XML or J=
SON.

Granted, the server has to have a conditional statement and generate XML or=
 JSON as requested.  However, generating either is trivial.  Really, I did =
it in minutes.  We're not talking about huge complex data structures here w=
ith WebFinger.

> Pity the poor programmer who can't get their head around that gigantic=20
> change. On the other hand, having to support XML and JSON is an=20
> ongoing maintenance headache server-side. Why do it?

Would we expect to see a lot of changes to the data structures used by WebF=
inger?  That's really the only ongoing maintenance issue.  Don't touch the =
code that produces the XML or JSON and there is no ongoing maintenance.

> There isn't even the dubious
> religious war like back in the day saying that binary encoded ASN.1=20
> was "better/faster/stacks and cleans dishes" than "human readable"=20
> XML.  XML is just a clunky and past its prime text encoding at this=20
> point. Requiring it smacks of nostalgia to me.

I disagree with you on that one.  First, ASN.1 is better for defining proto=
cols, so long as you stay away from the complex stuff. Basic ASN.1 looks a =
lot like C and produces C data structures that can be readily read, decoded=
, and consumed in C code.  Rarely, rarely do I see decoding issues when usi=
ng ASN.1, whereas issues pop up quite often with text protocols, especially=
 things like SIP where a semi-colon in the wrong place breaks things.  But,=
 let's not start that debate again ;-)

XML *can* be big and clunky.  As you've well noticed, I can also write leng=
thy emails that seem to have more typos as the evening progresses. :-)

However, XML can be a very compact encoding and it's extremely readable.

I just did a query on my server to see the XML vs. JSON output.  The XRD do=
cument provided was 1032 octets.  The JRD document was 1077 octets.
Removing every possible space and making both formats hard as heck to read,=
 JSON was 837 and XML was 940.  I'm hard pressed to say that's makes much d=
ifference.  Further, I can't read either of them now without some effort.

Considering that a lot of WebFinger use (I suspect) is going to be server-t=
o-server interaction, XML seems like a reasonable format to retain.
That, and the fact it is already mandatory in RFC 6415 and deployed out the=
re.

It's not nostalgia for me.  XML is a very well-structured, readable format.
No objection to JSON, but I really don't understand the clamoring for JSON.
I guess more precisely, I don't understand the disdain for XML.  Is it beca=
use people created hideously complex XML data structures and feel pain for =
having done that?  XRD is not that kind of document.

Paul


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



From nrm@arcanedomain.com  Fri Apr 20 11:54: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 E810E21F8661 for ; Fri, 20 Apr 2012 11:54:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUmo4AIGHtXR for ; Fri, 20 Apr 2012 11:54:45 -0700 (PDT)
Received: from homiemail-a7.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 397D821F8659 for ; Fri, 20 Apr 2012 11:54:45 -0700 (PDT)
Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id B6A9525C063; Fri, 20 Apr 2012 11:54:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=arcanedomain.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s= arcanedomain.com; b=oe18Ibxvvy0IzmHSJ/0DHZT9JhJxgJ5igYkqdH3yunGd dWEinjUzMxtTU0T7onxPTWFEA5UuY1aFMsXal5i5c6XB21EpB0wFZwy0PFB2jcFv 8cVUiK9ptNL8DzKa+2ZoBM0zm8aG+cNHeQAECoogf7SD5AKvHSxpi2oMW3dXAxo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=arcanedomain.com; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s= arcanedomain.com; bh=Fe5g9ltUCaVRy0IHbbaV09L05uE=; b=XgidmI7Ysh9 d2BMAs3omJpTvcF3uM1yCQ/cPdW5Ma015eanMHXghPVhECOlaAZGEKpZwlIWMGrQ 2sNXtx+bd4F28iYkYpwgFER9dQ2DL7CXcj6iaJTxWe8XfyRxbKbAvHwi2kTeRacC hklKEP4rtLDt+lJj9RcXuLj3VRdKtIUU=
Received: from [192.168.1.73] (75.sub-174-227-133.myvzw.com [174.227.133.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: webmaster@arcanedomain.com) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPSA id A518025C06D;  Fri, 20 Apr 2012 11:54:41 -0700 (PDT)
Message-ID: <4F91B0EB.6040304@arcanedomain.com>
Date: Fri, 20 Apr 2012 14:54:35 -0400
From: Noah Mendelsohn 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Henry S. Thompson" 
References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com>  <4F87EBD4.90501@gmx.de>  <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sat, 21 Apr 2012 09:50:45 -0700
Cc: "www-tag@w3.org List" , Tony Hansen , apps-discuss@ietf.org
Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Apr 2012 18:54:46 -0000

On 4/20/2012 5:09 AM, Henry S. Thompson wrote:
> Note that these paragraphs address_more_  than just fragment
> identifiers.  The level of "generic processing", i.e. processing
> appropriate to any member of a stuctured-syntax family identified by a
> +SUFFIX, is I think the appropriate one at which to address the mutual
> dependency between app/foo and app/bar+foo.

Right, I'm happy with that.

In the context of the overall recommendations on media types, I think it's 
worth thinking a bit about the tradeoffs. There are at least two possible 
goals for having each "derived" type accept (at least) the same 
syntax/semantics as the base: 1) it promotes least astonishment for users 
-- things work as you'd expect; 2) you might wish to enable generic processing.

If generic processing is a goal, then it's worth thinking about the 
consequences of SHOULD vs. MUST. If we go with SHOULD, which is OK with me, 
then it might be worth saying:

"Note: if the specification for a derived type provides for a different 
interpretation of some particular fragment identifier(s) than the base 
does, then generic processors may resolve such identifiers incorrectly."

So, SHOULD somewhat undercuts efforts to enable generic processing, insofar 
as it leaves open the possibility of misinterpreting even conforming 
identifiers and content. I think we should either go with MUST, or warn of 
the risk.

Noah

From tony@maillennium.att.com  Fri Apr 20 10:45: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 2991021F8688 for ; Fri, 20 Apr 2012 10:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.307
X-Spam-Level: 
X-Spam-Status: No, score=-105.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALCjCP7br0Hn for ; Fri, 20 Apr 2012 10:45:28 -0700 (PDT)
Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id 46B3521F8692 for ; Fri, 20 Apr 2012 10:45:28 -0700 (PDT)
Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 7b0a19f4.0.2117693.00-445.5874227.nbfkord-smmo03.seg.att.com (envelope-from );  Fri, 20 Apr 2012 17:45:28 +0000 (UTC)
X-MXL-Hash: 4f91a0b87243dc3c-b3b7909fdef5ef377734059613da25f44655b309
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 q3KHjQod015290 for ; Fri, 20 Apr 2012 13:45:27 -0400
Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3KHjNOG014999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Apr 2012 13:45:24 -0400
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Fri, 20 Apr 2012 13:44:51 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3KHip1x001036 for ; Fri, 20 Apr 2012 13:44:51 -0400
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3KHigdH000628 for ; Fri, 20 Apr 2012 13:44:43 -0400
Received: from [135.70.234.24] (vpn-135-70-234-24.vpn.east.att.com[135.70.234.24]) by maillennium.att.com (mailgw1) with ESMTP id <20120420174135gw1004ors4e> (Authid: tony); Fri, 20 Apr 2012 17:41:36 +0000
X-Originating-IP: [135.70.234.24]
Message-ID: <4F91A089.6070308@maillennium.att.com>
Date: Fri, 20 Apr 2012 13:44:41 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com>  <4F87EBD4.90501@gmx.de>  <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> <01OEITCHB07U00ZGHB@mauve.mrochek.com> <02811F06-0325-4A0D-AE0D-3B5AF07EAE97@jenitennison.com>
In-Reply-To: <02811F06-0325-4A0D-AE0D-3B5AF07EAE97@jenitennison.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-RSA-Action: allow
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.20.145]
X-AnalysisOut: [v=1.0 c=1 a=WDaDfJvHXAEA:10 a=vnNYxAp2wzwA:10 a=CRkRB2Q0ku]
X-AnalysisOut: [cA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1]
X-AnalysisOut: [0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=sQJM4-vXpLQEO6AIWr4A:9 a]
X-AnalysisOut: [=wPNLvfGTeEIA:10]
X-Mailman-Approved-At: Sat, 21 Apr 2012 09:51:03 -0700
Cc: "www-tag@w3.org List" , apps-discuss@ietf.org
Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Apr 2012 17:45:29 -0000

On 4/20/2012 6:30 AM, Jeni Tennison and others wrote:
 > ...

Thanks for all the comments.

This is what I've come up with that seems to satisfy the concerns I've 
heard expressed so far:

Media types using "+json" SHOULD process any fragment identifiers 
defined for "application/json" in the same way as defined for that media 
type. (At publication of this document, there is no fragment 
identification syntax defined for "application/json".) Specific media 
types using "+json" MAY identify additional fragment identifier 
considerations, MAY define processing for fragment identifiers that are 
classed as errors for "application/json" and MAY designate fragment 
identifiers defined for "application/json" that SHOULD NOT be used.

Same text for +fastinfoset, +wbxml and +zip. The note I added for +xml 
is similar:

Media types using "+xml" SHOULD process any fragment identifiers defined 
for "application/xml" in the same way as defined for that media type. 
(At publication of this document, the fragment identification syntax 
considerations for "application/xml" are defined in .) Specific media types using "+xml" MAY identify 
additional fragment identifier considerations, MAY define processing for 
fragment identifiers that are classed as errors for "application/xml" 
and MAY designate fragment identifiers defined for "application/xml" 
that SHOULD NOT be used.



	Tony Hansen

From bobwyman@gmail.com  Sat Apr 21 10:15: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 0A0C821F861A; Sat, 21 Apr 2012 10:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.326
X-Spam-Level: 
X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx3xU8hYln08; Sat, 21 Apr 2012 10:14:55 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4B921F8613; Sat, 21 Apr 2012 10:14:55 -0700 (PDT)
Received: by qaea16 with SMTP id a16so899495qae.10 for ; Sat, 21 Apr 2012 10:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Ad8gYKZ/ySi/hvXpf/ubn/oz+o9tqn0KEZsS2oXxLjs=; b=Z+Ad3AgOeZHHvbi8nUmr6863BSyTbRRlChBhggIFVnArXLamH29a2rkW/9HT2IPy2d 3NkE+dY1Yhzx8k/Rr7O2dKPWXw1q0ivOGqY8eJLZ28YYBenHCqDpeFaVc9E98oSxKtnV RqV6NafwKTNpt56RJOrV/x4O8LTwxRTJpj6UMmiN0k8E9Y7GxdsCkvyQxIXDVjidXBYd cPhDwwPlAHerH+5mE7j9DmBw/06hrfaWUM3tGxu6aaspyz95ZKqyREbCrFk9cBoMwkKr z2c/ymiO4IMO7yz1S6BJzg1nHkhXawNg8YnIqzpLDS/DvOTxdDB7P4UaD2w0S0bZFcq1 GjaA==
MIME-Version: 1.0
Received: by 10.229.105.224 with SMTP id u32mr2982622qco.41.1335028494815; Sat, 21 Apr 2012 10:14:54 -0700 (PDT)
Sender: bobwyman@gmail.com
Received: by 10.229.12.194 with HTTP; Sat, 21 Apr 2012 10:14:53 -0700 (PDT)
In-Reply-To: <4F921E53.8030109@cs.tcd.ie>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com> <4F921E53.8030109@cs.tcd.ie>
Date: Sat, 21 Apr 2012 13:14:53 -0400
X-Google-Sender-Auth: 9GJRFmrFiGds-WiqpEn_f2wKcYY
Message-ID: 
From: Bob Wyman 
To: Stephen Farrell 
Content-Type: multipart/alternative; boundary=00235429cd4032d2f804be338bec
Cc: Michael Thomas , Derek Atkins , oauth@ietf.org, Apps Discuss 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Apr 2012 17:15:00 -0000

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

On Fri, Apr 20, 2012 at 10:41 PM, Stephen Farrell  wrote:

>
>
> On 04/20/2012 03:40 PM, Michael Thomas wrote:
> >
> > Why not MUST ASN.1 while you're at it? JSON has won in case
> > you'all haven't noticed it.
>
> Well, I also remember when XML won over ASN.1, or
> was that some RPC thing?

Of course, long before "XML won over ASN.1" ASN.1 won over XML's
predecessor; SGML. Back in the early to mid-80's, when we were defining the
ISO X.4xx and X.5xx standards, the IBM and Unix crowds were pushing SGML as
the alternative to the binary encodings of ASN.1. But, Digital and the
Telcos pushed for the binary encodings and won.

These days, XML is just another encoding for ASN.1 since ASN.1 finally
defined the XML Encoding Rules
(XER)a few years back.

If we had agreed on ASN.1 years ago, we wouldn't be having these encoding
format debates every few years. ASN.1 is an "Abstract Syntax Notation" that
can be mapped to a large number of encoding rules. If we were using ASN.1,
what we would do is define the "schema" or syntax for data abstractly and
then specify the actual encoding as a secondary issue. Given that one
encoding can be translated to another, implementations would be free to use
whatever encoding was most convenient or appropriate for them. But, that
would be a different universe than the one we live in today.

Seems like a new format wins
> about every five years or so, once the last winner
> gets enough crap added. (JSON pointer seems like the
> start of a nice slippery slope to me.)
>
> I've no opinion as to what should be MTI here however,
> just a side comment.
>
> S
>
> >
> > Mike
> > _______________________________________________
> > 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
>

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



On Fri, Apr 20, 2012 at 10:41 PM, Stephe=
n Farrell <stephen.farrell@cs.tcd.ie> wrote:






On 04/20/2012 03:40 PM, Michael Thomas wrote:

>

> Why not MUST ASN.1 while you're at it? JSON has won in case

> you'all haven't noticed it.




Well, I also remember when XML won over ASN.1, or

was that some RPC thing?
Of course, long before "XML =
won over ASN.1" ASN.1 won over XML's predecessor; SGML. Back in th=
e early to mid-80's, when we were defining the ISO X.4xx and X.5xx stan=
dards, the IBM and Unix crowds were pushing SGML as the alternative to the =
binary encodings of ASN.1. But, Digital and the Telcos pushed for the binar=
y encodings and won.



These days, XML is just another encoding for ASN.1 sinc=
e ASN.1 finally defined the XML Encoding Rules (XER) a few years back.=A0



If we had agreed on ASN.1 years ago, we wouldn't be having these e=
ncoding format debates every few years. ASN.1 is an "Abstract Syntax N=
otation" that can be mapped to a large number of encoding rules. If we=
 were using ASN.1, what we would do is define the "schema" or syn=
tax for data abstractly and then specify the actual encoding as a secondary=
 issue. Given that one encoding can be translated to another, implementatio=
ns would be free to use whatever encoding was most convenient or appropriat=
e for them. But, that would be a different universe than the one we live in=
 today.



Seems like a new format wins<=
br>
about every five years or so, once the last winner

gets enough crap added. (JSON pointer seems like the

start of a nice slippery slope to me.)



I've no opinion as to what should be MTI here however,

just a side comment.




S



>

> Mike

> _______________________________________________

> 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





--00235429cd4032d2f804be338bec--

From tbray@textuality.com  Sat Apr 21 12:27: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 9FB2B21F8592 for ; Sat, 21 Apr 2012 12:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.997
X-Spam-Level: 
X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E50+eOyi+nV9 for ; Sat, 21 Apr 2012 12:26:59 -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 A263C21F8584 for ; Sat, 21 Apr 2012 12:26:59 -0700 (PDT)
Received: by obbwd20 with SMTP id wd20so11003036obb.31 for ; Sat, 21 Apr 2012 12:26:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=kfvVYONDB88l0xkjDZL0SwT+s0VmIqgPhG3ydNneKD8=; b=cZFu1Jv+79yqUijZg6K1XeVfGjva+8e9Z359Bb+5x5gRQ0tFiUgkC2eBlpHbfF+20j D/yG+O9Ovdz3PrTOYLxI6wq+MGpVc/JFjYfzUfreHgGVjYDFMBm8zCDfx2h2NRxhbxyT m9YdGLu7jmmuV0qUe8irexg1JsNJsdRxOF/qPqgLL7q7pXYTATYXcOCDDW7ISYWNmlyN zA0grFEZSWj4DdT48HFbStPtrJubFQ26zdxCfgN0CMHnntGVRGH5qYS+bo10QHLn/c0o MLYm79W1qR7T0urItiaUzn8WtH7ob0H5L3dUujWkN4ER/1a+VBql3y5LUUEQlgDC3XDz 69mA==
MIME-Version: 1.0
Received: by 10.60.7.103 with SMTP id i7mr9346188oea.64.1335036419066; Sat, 21 Apr 2012 12:26:59 -0700 (PDT)
Received: by 10.182.204.71 with HTTP; Sat, 21 Apr 2012 12:26:59 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
In-Reply-To: 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com> <4F921E53.8030109@cs.tcd.ie> 
Date: Sat, 21 Apr 2012 12:26:59 -0700
Message-ID: 
From: Tim Bray 
To: Bob Wyman 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlk8fDNzXdGHP3X70qU/tb7daFWgxg1/j8PCOQE37arNv9ms2aZ1Vigp6RH8lXDJe7LP1ZJ
Cc: Michael Thomas , Derek Atkins , oauth@ietf.org, Apps Discuss 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Apr 2012 19:27:03 -0000

That might have happened had there been some free high-quality ASN.1
software, instead of slow buggy parsers that cost $50K to license.
It=92s always seemed to me that one reason XML took off so fast is that
there were fast robust open-source parsers in C and Java before the
spec was even finalized.

But we digress... -T

On Sat, Apr 21, 2012 at 10:14 AM, Bob Wyman  wrote:
>
>
> On Fri, Apr 20, 2012 at 10:41 PM, Stephen Farrell
>  wrote:
>>
>>
>>
>> On 04/20/2012 03:40 PM, Michael Thomas wrote:
>> >
>> > Why not MUST ASN.1 while you're at it? JSON has won in case
>> > you'all haven't noticed it.
>>
>> Well, I also remember when XML won over ASN.1, or
>> was that some RPC thing?
>
> Of course, long before "XML won over ASN.1" ASN.1 won over XML's
> predecessor; SGML. Back in the early to mid-80's, when we were defining t=
he
> ISO X.4xx and X.5xx standards, the IBM and Unix crowds were pushing SGML =
as
> the alternative to the binary encodings of ASN.1. But, Digital and the
> Telcos pushed for the binary encodings and won.
>
> These days, XML is just another encoding for ASN.1 since ASN.1 finally
> defined the XML Encoding Rules (XER) a few years back.
>
> If we had agreed on ASN.1 years ago, we wouldn't be having these encoding
> format debates every few years. ASN.1 is an "Abstract Syntax Notation" th=
at
> can be mapped to a large number of encoding rules. If we were using ASN.1=
,
> what we would do is define the "schema" or syntax for data abstractly and
> then specify the actual encoding as a secondary issue. Given that one
> encoding can be translated to another, implementations would be free to u=
se
> whatever encoding was most convenient or appropriate for them. But, that
> would be a different universe than the one we live in today.
>
>> Seems like a new format wins
>> about every five years or so, once the last winner
>> gets enough crap added. (JSON pointer seems like the
>> start of a nice slippery slope to me.)
>>
>> I've no opinion as to what should be MTI here however,
>> just a side comment.
>>
>> S
>>
>> >
>> > Mike
>> > _______________________________________________
>> > 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 sm@resistor.net  Sat Apr 21 13:34: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 747CD21F8637; Sat, 21 Apr 2012 13:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level: 
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f29x6-OKa4Mg; Sat, 21 Apr 2012 13:34:28 -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 3223121F862F; Sat, 21 Apr 2012 13:34:27 -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 q3LKYGc2026824; Sat, 21 Apr 2012 13:34:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335040463; i=@resistor.net; bh=+5mMhJfFQ4BWMJ8Icp7GVOhBWz4UVJKF4S7+0wYxD8Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vvt5S4ZRrf0bohm8q5ruujMEwBMQ6mR0WdLLI+2lOdNWX2ZQ2FYrF/xA5sdFh2SqT fpnXMrC1PpbC4dAXWB6SwQ3PkQe16TFA3dGCT1PsAcukG8Wordeb5Ywn+iwZ0DirZT CQV+dPuohDzh/1U2cHwSzPk2AJHUawUqwbVFKxoA=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1335040463; i=@resistor.net; bh=+5mMhJfFQ4BWMJ8Icp7GVOhBWz4UVJKF4S7+0wYxD8Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=43RCJtdrZNlO09ztdwQw5OcXR+UC1Ft+TzI0H87KkVJkZxcOq1DQUxGzswycNPqFc nktl7jHmJZPRq0dsTpo6MnheE6iU9BzYSsFE6Wl35h2YIjjGucEW0ZqLnYQwpek3Eu J/TTAEWX8so9Jd37CzUeYtmFljPEMiwo37xlxUVQ=
Message-Id: <6.2.5.6.2.20120421124344.0bc4b0c0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 21 Apr 2012 13:03:53 -0700
To: "Paul E. Jones" 
From: SM 
In-Reply-To: <0a7401cd1f6f$9cb98fd0$d62caf70$@packetizer.com>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <0a7401cd1f6f$9cb98fd0$d62caf70$@packetizer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: oauth@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Apr 2012 20:34:38 -0000

Hi Paul,
At 20:34 20-04-2012, Paul E. Jones wrote:
>My preference has been MUST for XML and JSON since 1) XML is already a MUST
>in RFC 6415 and we'd have to "break" what is there now to remove the MUST
>and 2) people are clearly demanding JSON.

MUST for XML and JSON offers choice but it does make a 
choice.  Encouraging such a polygamous relationship can only end up 
badly.  RFC 6415 was published in October 2011.  Switching 
preferences in less than a year raises some issues about the nature 
of relationships.

Anyway, whether someone break something is not as important as 
picking one option.

Regards,
-sm



From derhoermi@gmx.net  Sat Apr 21 15:03: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 03B9921F865B for ; Sat, 21 Apr 2012 15:03:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHG7zzuRc3jz for ; Sat, 21 Apr 2012 15:03:18 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D088E21F856C for ; Sat, 21 Apr 2012 15:03:17 -0700 (PDT)
Received: (qmail invoked by alias); 21 Apr 2012 22:03:15 -0000
Received: from dslb-094-222-155-205.pools.arcor-ip.net (EHLO HIVE) [94.222.155.205] by mail.gmx.net (mp001) with SMTP; 22 Apr 2012 00:03:15 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/quSlvHtXqRT6B6EkMVwGRIwJvH+RYQCCpC0A062 spPoZy8Uc4RXzJ
From: Bjoern Hoehrmann 
To: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Sun, 22 Apr 2012 00:03:18 +0200
Message-ID: <9ua6p79fh03lm9i7f6l98jorsnu9erqqi1@hive.bjoern.hoehrmann.de>
References:  <4F87EBD4.90501@gmx.de>  <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> <2ee3p79ijn5orc4i6m85hqfm7ta4vv55mb@hive.bjoern.hoehrmann.de> 
In-Reply-To: 
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: www-tag@w3.org, Tony Hansen , apps-discuss@ietf.org
Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Apr 2012 22:03:31 -0000

* Henry S. Thompson wrote:
>Bjoern Hoehrmann writes:
>> * Tony Hansen wrote:
>>>So I've added these Fragment identifier considerations sections to the 
>>>suffixes that have an underlying media type registration.
>>>
>>>     Media types using "+json" MUST accept any fragment identifiers
>>>     defined for "application/json". Specific media types may
>>>     identify additional fragment identifier considerations.
>>
>> This says that "+json" cannot be used for JSON types where fragment
>> identifiers are of any concern since any future specification of the
>> application/json type may override such registrations in incompatible
>> ways. This seems to be missing the point of why we would have "+json"
>> to begin with.
>
>Or, it implies any update to a syntax schema registration such as
>application/json has a responsibility to its "deployed base".  Comes
>with the territory.

Saying that an inferior authority must obey a superior authority does
not imply that the superior authority is limited by choices any such
inferior authorities have made. We might find that taking such choices
into consideration is the responsible thing to do, but that is not what
the text says, and certainly not how authorities tend to operate. Look
no further than the +xml discussions where people do not find they need
to re-define +xml in a manner compatible with all existing +xml types.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From ht@inf.ed.ac.uk  Sat Apr 21 15:09: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 46AAA11E8072 for ; Sat, 21 Apr 2012 15:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.569
X-Spam-Level: 
X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-RtLU618mTL for ; Sat, 21 Apr 2012 15:09:38 -0700 (PDT)
Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8CF11E808A for ; Sat, 21 Apr 2012 15:09:37 -0700 (PDT)
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 q3LM9Kvd007136; Sat, 21 Apr 2012 23:09:20 +0100 (BST)
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 q3LM9Kjn002889; Sat, 21 Apr 2012 23:09:20 +0100
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 q3LM9K87032530;  Sat, 21 Apr 2012 23:09:20 +0100
Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3LM9JGL032526; Sat, 21 Apr 2012 23:09:19 +0100
X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: Bjoern Hoehrmann 
References:  <4F87EBD4.90501@gmx.de>  <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> <2ee3p79ijn5orc4i6m85hqfm7ta4vv55mb@hive.bjoern.hoehrmann.de>  <9ua6p79fh03lm9i7f6l98jorsnu9erqqi1@hive.bjoern.hoehrmann.de>
From: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Sat, 21 Apr 2012 23:09:19 +0100
In-Reply-To: <9ua6p79fh03lm9i7f6l98jorsnu9erqqi1@hive.bjoern.hoehrmann.de> (Bjoern Hoehrmann's message of "Sun, 22 Apr 2012 00:03:18 +0200")
Message-ID: 
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (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: www-tag@w3.org, Tony Hansen , apps-discuss@ietf.org
Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Apr 2012 22:09:42 -0000

Bjoern Hoehrmann writes:

> Saying that an inferior authority must obey a superior authority does
> not imply that the superior authority is limited by choices any such
> inferior authorities have made. We might find that taking such choices
> into consideration is the responsible thing to do, but that is not what
> the text says, and certainly not how authorities tend to operate. Look
> no further than the +xml discussions where people do not find they need
> to re-define +xml in a manner compatible with all existing +xml types.

Actually, we've been continuing to struggle with that, and I _believe_
the next draft of 3023bis will fix that.

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 derhoermi@gmx.net  Sat Apr 21 15:33: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 E441B11E80AC for ; Sat, 21 Apr 2012 15:33:02 -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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cmdpQ4WPd9p for ; Sat, 21 Apr 2012 15:32:58 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 7C06811E80A5 for ; Sat, 21 Apr 2012 15:32:57 -0700 (PDT)
Received: (qmail invoked by alias); 21 Apr 2012 22:32:56 -0000
Received: from dslb-094-222-155-205.pools.arcor-ip.net (EHLO HIVE) [94.222.155.205] by mail.gmx.net (mp001) with SMTP; 22 Apr 2012 00:32:56 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+sqC55V6ysMKJOAbLVt1F54owXpqhqkFYWAljdwf 8unsPxYEHZqCn9
From: Bjoern Hoehrmann 
To: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Sun, 22 Apr 2012 00:32:58 +0200
Message-ID: 
References: <4F87EBD4.90501@gmx.de>  <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> <2ee3p79ijn5orc4i6m85hqfm7ta4vv55mb@hive.bjoern.hoehrmann.de>  <9ua6p79fh03lm9i7f6l98jorsnu9erqqi1@hive.bjoern.hoehrmann.de> 
In-Reply-To: 
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: www-tag@w3.org, Tony Hansen , apps-discuss@ietf.org
Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Apr 2012 22:33:03 -0000

* Henry S. Thompson wrote:
>Bjoern Hoehrmann writes:
>
>> Saying that an inferior authority must obey a superior authority does
>> not imply that the superior authority is limited by choices any such
>> inferior authorities have made. We might find that taking such choices
>> into consideration is the responsible thing to do, but that is not what
>> the text says, and certainly not how authorities tend to operate. Look
>> no further than the +xml discussions where people do not find they need
>> to re-define +xml in a manner compatible with all existing +xml types.
>
>Actually, we've been continuing to struggle with that, [...]

Yes, indeed. That is the problem with the interpretation you proposed.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From sm@resistor.net  Sat Apr 21 15:37: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 DDE6021F8598 for ; Sat, 21 Apr 2012 15:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.529
X-Spam-Level: 
X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXuslAOA67a4 for ; Sat, 21 Apr 2012 15:37:49 -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 8702321F8592 for ; Sat, 21 Apr 2012 15:37:48 -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 q3LMbdBL003664; Sat, 21 Apr 2012 15:37:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335047867; i=@resistor.net; bh=3PIm31nKfyNZ06vKF3SMztg9O7EFVA3Iw22TcVFu/oY=; h=Date:To:From:Subject:Cc; b=JgCYugZkfj+wVIGPm7oxuXQc5EJee9TM7AAkmIBWA9zVDKTZWZGyXJ0nHNwRbFBJH iKEhl1Z/hsYvrM5iqqhYtxG2iY+g3WI1m/UFvycEw/cjGDDdWn2LBcgK7ouGLP+hMP nfpIuNZS4tyAhQnJC/WDGqKTEWqLRO8GYXDHsqCk=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1335047867; i=@resistor.net; bh=3PIm31nKfyNZ06vKF3SMztg9O7EFVA3Iw22TcVFu/oY=; h=Date:To:From:Subject:Cc; b=kn9QE/lWPUoRP/ZMhUuO5xvw6lpwkzlFHF8xMQNxhyMNqmz5rnBVq0Rrh5GdB7/cC /ZMeMSGG+J3JgzrHYcBGP9QKob3fJHAWgzK9o6iGD/vIAEB003r6j9XxgSW1EY9Ldn 9lK8rVuC3XQLDpa59ISne8YhpuplFvug91H9EfdE=
Message-Id: <6.2.5.6.2.20120421143240.07253358@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 21 Apr 2012 15:26:32 -0700
To: Hubert Ryckelynck 
From: SM 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] Comments on draft-hryckelynck-writing-rfcs-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: Sat, 21 Apr 2012 22:37:55 -0000

Hello,

[message copied to apps-discuss@ in case other people would like to 
provide feedback about this proposal]

The initial version of draft-hryckelynck-writing-rfcs-01 was posted 
on April 1.  I wasn't sure whether the date was intentionally 
chosen.  I note that draft-hryckelynck-writing-rfcs is intended to be 
published as Experimental.  Do you have a plan about how long this 
experiment should be run?

In the Abstract Section:

   "Mail Accepted by Previous Sending defines a mechanism by which
    incoming unsollicited mails MAY be rejected or penalized by a MTA if
    their sender address domains has never been a destination for the
    outgoing mails treated by this MTA."

The "MAY" should be written as "may".

In the Introduction Section:

   "Mails with, for example, a pornographic contains are easy to identify
    as mail we MUST intercept."

Some people enjoy pornographic content.  The above requirement 
forbids that.  Is that intentional?

The RFC 2119 key words in the first section should be removed.

In Section 2, you are using a "MUST" before the RFC 2119 boilerplate.

   "These words take their normative meanings only when they
    are presented in ALL UPPERCASE."

That's somewhat unusual.  Is that from RFC 2119 or the author's choice?

In Section 3.1:

   "In the SMTP RFC [RFC5321], you will find a responsability notion."

Shouldn't this be about design instead of philosophy?

In Section 3.2.1:

   "Because of the huge quantity of unsollicited mail and to avoid giving
    more information to those whore are sending them, section 6.2 of RFC
    5321 [RFC5321] permit in practice silent dropping and more and
    more MTA are configured to drop silently those mails."

"whore" looks like a typo.

I note that Section 6.2 of RFC 5321 also says:

   "However, it is extremely dangerous and violates a long tradition and
    community expectations that mail is either delivered or returned. If
    silent message-dropping is misused, it could easily undermine
    confidence in the reliability of the Internet's mail systems."

In Section 3.3.1:

   "But at this time the RFC 5321 [RFC5321]in section 3.6.2 doesn't
    RECOMMENDED any method."

I could not find anything in Section 3.6.2 about Return-path.

In Section 6.2.2:

   "For example, if the MTA receive a mail that SHOULD be dropped because
    it comes from an IP which has a bad reputation."

That sentence could be part of the sentence in the previous paragraph.

In Section 7.1.2.2:

   "When a user wants to be reached by a commercial site, he will only
    have to declare the domain.  This will force commercial site to
    specify clearly which domain they use for their sending."

In the above based upon RFC 706?

In Section 9.2:

   "It is not garantied, when a mail which has a sender address from a
    domain you previously accepted, that this mail really come from this
    domain.  For this purpose you will need other mechanism that could be
    viewed as complementary like SPF [RFC4408] or DKIM [RFC6376]."

What is your opinion about the IESG note at the beginning of RFC 4408?

The "Mail Accepted by Previous Sending" proposal might need some more 
work before it is ready for publication as a RFC.

Regards,
-sm


From ned.freed@mrochek.com  Sat Apr 21 19: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 E7A1821F8478 for ; Sat, 21 Apr 2012 19:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level: 
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jfqy-Mn58UWn for ; Sat, 21 Apr 2012 19:31:32 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C228821F847A for ; Sat, 21 Apr 2012 19:31:32 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OELBFM98I8000IBS@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 21 Apr 2012 19:31:30 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEGM6GSINK00ZGHB@mauve.mrochek.com>; Sat, 21 Apr 2012 19:31:27 -0700 (PDT)
Message-id: <01OELBFKD4W400ZGHB@mauve.mrochek.com>
Date: Sat, 21 Apr 2012 19:20:17 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Fri, 20 Apr 2012 10:09:21 +0100" 
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com>  <4F87EBD4.90501@gmx.de>  <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> 
To: ht@inf.ed.ac.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1335061921; bh=7JwMZ6mlSlyMesySD0s6vHQA/ttWJEF/Hh6g74NxXRQ=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=eV/7jFGb/bztypOTIMIFoTAjYO+i0erHENqo1fXcWX1FyOCLqhPQMM6n6tdQJeCg8 hj3iu9fswWAPy0aBfD2okWE5b6Sg5s3bGDLW47i8b7mrPcRSjZb1pEU7HNEa1bGVuk 6ZNMiKvCcemTdI+JP7vvC/oRH/829xo/sw1U60Uc=
Cc: apps-discuss@ietf.org, Tony Hansen , "www-tag@w3.org List" 
Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type	Specifications and Registration Procedures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Apr 2012 02:31:34 -0000

> Tony Hansen writes:

> > So, I'm revising my draft where I'm actually *registering* a bunch of
> > these structured suffixes. (draft-hansen-media-type-suffix-reg)
> >
> > What I'm thinking is that the fragment considerations section for each
> > should simply point at the base application/whatever
> > specification. That is, if application/SUFFIX has specific fragment
> > identifiers associated with it, then anything with +SUFFIX (e.g.,
> > application/TYPE+SUFFIX) should accept the application/SUFFIX fragment
> > identifiers as well as anything specific to the given media type.
> >
> > So I've added these Fragment identifier considerations sections to the
> > suffixes that have an underlying media type registration.
> >
> >     Media types using "+json" MUST accept any fragment identifiers
> >     defined for "application/json". Specific media types may
> >     identify additional fragment identifier considerations.
> >
> > I have similar text for +fastinfoset, +wbxml and +zip.
> >
> > In addition, I'm thinking draft-hansen-media-type-suffix-reg should
> > have an IANA considerations note to add the Fragment identifier
> > considerations section for +xml, with text similar to the above.

> If you go in that direction, please consider the fact that 3023bis
> _is_ once again under active development, with W3C TAG cooperation,

First of all, given that there has been no I-D posting of a 3023bis "active
development" is a bit of a stretch. There may be something going on inside the
W3C, but 3023 is an IETF RFC, and that means new versions need to be posted as
I-Ds and discussion needs to be happning on an IETF list. I strongly urge
whoever is working on this to see that this happens ASAP.

All that aside, this sort of revision is the reason why Tony is taking this
approach. An 3023bis is necessarily going to contain both a new registration
for application/xml, quite likely including updated information on XML fragment
identifiers. Additionally, since +xml is defined in 3023 and assuming the new
media types registration procedures are in place before 3023bis, 3023bis is
going to have to contain an updated registration for +xml.

> and that something very similar to the following (slightly adapted
> from the previous editors' draft) will likely appear therein:

>   When a new media type is introduced for an XML-based format, the
>   name of the media type SHOULD end with '+xml'. This convention will
>   allow applications that can process XML generically to detect that
>   the MIME entity is supposed to be an XML document, verify this
>   assumption by invoking some XML processor, and then process the XML
>   document accordingly. Applications may match for types that
>   represent XML MIME entities by comparing the subtype to the pattern
>   '*/*+xml'.

>   XML generic processing is not always appropriate for XML-based media
>   types. For example, authors of some such media types may wish that
>   the types remain entirely opaque except to applications that are
>   specifically designed to deal with that media type. By NOT following
>   the naming convention '+xml', such media types can avoid XML-generic
>   processing. Since generic processing will be useful in many cases,
>   however -- including in some situations that are difficult to
>   predict ahead of time -- those registering media types SHOULD use
>   the '+xml' convention unless they have a particularly compelling
>   reason not to. [1]

> Note that these paragraphs address _more_ than just fragment
> identifiers.  The level of "generic processing", i.e. processing
> appropriate to any member of a stuctured-syntax family identified by a
> +SUFFIX, is I think the appropriate one at which to address the mutual
> dependency between app/foo and app/bar+foo.

Of course. And this actually won't be sufficient - as noted above, a
proper +xml registration will also be needed.

				Ned

From ned.freed@mrochek.com  Sat Apr 21 19:32:38 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D0321F847A for ; Sat, 21 Apr 2012 19:32:38 -0700 (PDT)
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.111,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v51cmo52R97q for ; Sat, 21 Apr 2012 19:32:37 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B63C221F8478 for ; Sat, 21 Apr 2012 19:32:37 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OELBGXVCVK000IBS@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 21 Apr 2012 19:32:33 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEGM6GSINK00ZGHB@mauve.mrochek.com>; Sat, 21 Apr 2012 19:32:31 -0700 (PDT)
Message-id: <01OELBGW2MR400ZGHB@mauve.mrochek.com>
Date: Sat, 21 Apr 2012 19:32:03 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Fri, 20 Apr 2012 11:30:54 +0100" <02811F06-0325-4A0D-AE0D-3B5AF07EAE97@jenitennison.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com>  <4F87EBD4.90501@gmx.de>  <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> <01OEITCHB07U00ZGHB@mauve.mrochek.com> <02811F06-0325-4A0D-AE0D-3B5AF07EAE97@jenitennison.com>
To: Jeni Tennison 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1335061985; bh=hlHJi8uzTbtCeRVhJCbH75whbrIabkThjmV2n0iwwRY=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=NBeBtUVtVQrM2jR97xFTnJPzHf77H0o1Eg6vCN82bEHiXq6EaxzkrHctH+rL4Ikz2 kZlmGrq1iZ770DmjddAU5iReCHurjzvy3nEBX/nYlEyF1NYzw7KdjmPOvuXDfpVmTg oTDp/pBY67iAn/7GyvuNyz8iSYotHel2yrI66Xbc=
Cc: "www-tag@w3.org List" , Ned Freed , Tony Hansen , apps-discuss@ietf.org
Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Apr 2012 02:32:38 -0000

> Hi Tony,

> On 20 Apr 2012, at 08:24, Ned Freed wrote:
> >> So I've added these Fragment identifier considerations sections to the
> >> suffixes that have an underlying media type registration.
> >>
> >>     Media types using "+json" MUST accept any fragment identifiers
> >>     defined for "application/json". Specific media types may
> >>     identify additional fragment identifier considerations.
> >
> > I like the overall idea but, per the above, MUST is too strong. SHOULD
> > is appropriate here, and I'd capitalize the may in the second sentence.

> I agree with Ned about softening the wording. The other thing that you could specifically draw out is that fragment identifiers that are classed as errors in the media type related to the suffix may be classified as OK within a specific media type.

> The other (word-smithing) comment I'd make is that it's not enough for the specific media type to 'accept' fragment identifiers: they should be processed in the same way as well.

> So I'd suggest something like:

>     Media types using "+json" SHOULD process any fragment identifiers
>     defined for "application/json" in the same way as defined for that
>     media type. Specific media types MAY identify additional fragment
>     identifier considerations and MAY define processing for fragment
>     identifiers that are classed as errors for "application/json".

I think adding this is a good idea.

				Ned

From ned.freed@mrochek.com  Sat Apr 21 19:34: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 BD2F811E8083 for ; Sat, 21 Apr 2012 19:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Level: 
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYW2jcdW-jUt for ; Sat, 21 Apr 2012 19:34:03 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CB6A621F8478 for ; Sat, 21 Apr 2012 19:34:01 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OELBIP7528000IBS@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 21 Apr 2012 19:33:58 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEGM6GSINK00ZGHB@mauve.mrochek.com>; Sat, 21 Apr 2012 19:33:57 -0700 (PDT)
Message-id: <01OELBIO0RA600ZGHB@mauve.mrochek.com>
Date: Sat, 21 Apr 2012 19:33:25 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Fri, 20 Apr 2012 13:44:41 -0400" <4F91A089.6070308@maillennium.att.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com>  <4F87EBD4.90501@gmx.de>  <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> <01OEITCHB07U00ZGHB@mauve.mrochek.com> <02811F06-0325-4A0D-AE0D-3B5AF07EAE97@jenitennison.com> <4F91A089.6070308@maillennium.att.com>
To: Tony Hansen 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1335062070; bh=43w7QRKZYDE4U4/lI+Jg4DMm5w4SN5me4Iorbp23rbk=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=FWizHAXZFvwltEIvZp1Cz4oZYGLL/CBAsHlY7kjkcTq5xNhHoa21I+bEyPuGKb2Bo QJmUioafIMG1Q9h05hvIovo3mIAam8X2a3tEp41W0uYJasVwvA2YpL0drhXi9Ly74D 0KW+d8B7l++eLJWG6lNIsqc0UduR7Yh1AUCF6upc=
Cc: apps-discuss@ietf.org, "www-tag@w3.org List" 
Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Apr 2012 02:34:03 -0000

> On 4/20/2012 6:30 AM, Jeni Tennison and others wrote:
>  > ...

> Thanks for all the comments.

> This is what I've come up with that seems to satisfy the concerns I've
> heard expressed so far:

> Media types using "+json" SHOULD process any fragment identifiers
> defined for "application/json" in the same way as defined for that media
> type. (At publication of this document, there is no fragment
> identification syntax defined for "application/json".) Specific media
> types using "+json" MAY identify additional fragment identifier
> considerations, MAY define processing for fragment identifiers that are
> classed as errors for "application/json" and MAY designate fragment
> identifiers defined for "application/json" that SHOULD NOT be used.

> Same text for +fastinfoset, +wbxml and +zip. The note I added for +xml
> is similar:

> Media types using "+xml" SHOULD process any fragment identifiers defined
> for "application/xml" in the same way as defined for that media type.
> (At publication of this document, the fragment identification syntax
> considerations for "application/xml" are defined in  target='RFC3023'/>.) Specific media types using "+xml" MAY identify
> additional fragment identifier considerations, MAY define processing for
> fragment identifiers that are classed as errors for "application/xml"
> and MAY designate fragment identifiers defined for "application/xml"
> that SHOULD NOT be used.

AFAICT this covers every point that has been raised.

				Ned

From melvincarvalho@gmail.com  Sat Apr 21 20:09: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 E69D511E808D for ; Sat, 21 Apr 2012 20:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.442
X-Spam-Level: 
X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.156,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZPpCOO0d1nb for ; Sat, 21 Apr 2012 20:09:55 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2EC11E8073 for ; Sat, 21 Apr 2012 20:09:55 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so8573707vbb.31 for ; Sat, 21 Apr 2012 20:09:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CLfErqUBbSF3ueuDvUHz8H66GitlOIZQK9luiIX9r6s=; b=AVrL4GXXTWakxd5Ff4cd5TR42vj0MMN9E5gFF+v/fOpItBvBXGeNhULsABxdDwBIzn v6HD3ogh+78119nTJL2h6/K/sB4tky7UHG3kA1KTuMo1AzeWQAqYNnZ8SwwY+2M8KCA6 3kB/YcFYr3d2ubJyZfqtz0XrPfDcYlz5U5qn9C2vBrSfVIMjDpsqxwYWrZV7td35cRhv Emuv1EWpktHytkWI3cHT2Dd02PNJNc0s0hCKId5Sg0bcmxUxrnDjR5Hg32LoAopM0iab SXbsyQR+wHXk8hF/3MAIUE4k652a5ZagcYne8+UVY111ZMzErGHa+wkKd4zy5rahuvgz Ca0A==
MIME-Version: 1.0
Received: by 10.220.40.73 with SMTP id j9mr4221660vce.63.1335064194404; Sat, 21 Apr 2012 20:09:54 -0700 (PDT)
Received: by 10.52.70.98 with HTTP; Sat, 21 Apr 2012 20:09:54 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664920DE@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917CE6.2060904@mtcc.com> <0a7601cd1f74$cc5a26a0$650e73e0$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664920DE@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Sun, 22 Apr 2012 05:09:54 +0200
Message-ID: 
From: Melvin Carvalho 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=bcaec54eed0a0f510904be3bdb32
Cc: Michael Thomas , Derek Atkins , Apps Discuss 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Apr 2012 03:09:57 -0000

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

On 21 April 2012 18:37, Mike Jones  wrote:

> I want to completely agree with what Paul wrote: "What is a pain on the
> client side is conditional code that has to be followed in order to consume
> whatever the server wants to send.  The client should have a single code
> path knowing it will get what it wants".
>
> BTW, this is also part of the argument for making the resource parameter
> required.  Paul's example of:
>        curl -v
> https://packetizer.com/.well-known/host-meta.json?resource=acct:paulej@packetizer.com
> should work on all deployments - not just packetizer.com, so clients can
> rely on it working (and not have to have conditional code to try again in a
> different way when it doesn't).
>
> As a design principle, to the extent there's any complexity, it should be
> pushed to the servers, rather than the clients, as clients will vastly
> outnumber servers.    The solution should be as simple for clients to use
> as possible, to facilitate adoption.
>

if acct: is to become a new protocol for the internet , I request that it
should be fully documented, and available for review


>                                Best wishes,
>                                -- Mike
>
> (moved OAuth to bcc)
>
> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of Paul E. Jones
> Sent: Friday, April 20, 2012 9:11 PM
> To: 'Michael Thomas'; 'Derek Atkins'
> Cc: oauth@ietf.org; 'Apps Discuss'
> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery
> (SWD)
>
> Mike,
>
> > On 04/20/2012 07:17 AM, Derek Atkins wrote:
> > >  Note that this is a replay of the historical "MUST
> > > Implement" versus "MUST Use" arguments. Just because the server MUST
> > > IMPLEMENT JSON and XML does not mean that a Client must use both (or
> > > even that a client must implement both). It is perfectly reasonable
> > > and generally acceptable to have a server that provides data in
> > > multiple formats whereas the client only supports a subset and
> > > specifies which format(s) are acceptable.  -derek
> >
> > To Paul's point about how easy it is for a server to support both, I'd
> > retort that it's equally easy for a client to gin up JSON instead of XML.
>
> I don't follow.
>
> I agree I could write a client that could do JSON easily.
> I agree I could write a client that could do XML easily.
>
> What is a pain on the client side is conditional code that has to be
> followed in order to consume whatever the server wants to send.  The client
> should have a single code path knowing it will get what it wants, ether XML
> or JSON.
>
> Granted, the server has to have a conditional statement and generate XML
> or JSON as requested.  However, generating either is trivial.  Really, I
> did it in minutes.  We're not talking about huge complex data structures
> here with WebFinger.
>
> > Pity the poor programmer who can't get their head around that gigantic
> > change. On the other hand, having to support XML and JSON is an
> > ongoing maintenance headache server-side. Why do it?
>
> Would we expect to see a lot of changes to the data structures used by
> WebFinger?  That's really the only ongoing maintenance issue.  Don't touch
> the code that produces the XML or JSON and there is no ongoing maintenance.
>
> > There isn't even the dubious
> > religious war like back in the day saying that binary encoded ASN.1
> > was "better/faster/stacks and cleans dishes" than "human readable"
> > XML.  XML is just a clunky and past its prime text encoding at this
> > point. Requiring it smacks of nostalgia to me.
>
> I disagree with you on that one.  First, ASN.1 is better for defining
> protocols, so long as you stay away from the complex stuff. Basic ASN.1
> looks a lot like C and produces C data structures that can be readily read,
> decoded, and consumed in C code.  Rarely, rarely do I see decoding issues
> when using ASN.1, whereas issues pop up quite often with text protocols,
> especially things like SIP where a semi-colon in the wrong place breaks
> things.  But, let's not start that debate again ;-)
>
> XML *can* be big and clunky.  As you've well noticed, I can also write
> lengthy emails that seem to have more typos as the evening progresses. :-)
>
> However, XML can be a very compact encoding and it's extremely readable.
>
> I just did a query on my server to see the XML vs. JSON output.  The XRD
> document provided was 1032 octets.  The JRD document was 1077 octets.
> Removing every possible space and making both formats hard as heck to
> read, JSON was 837 and XML was 940.  I'm hard pressed to say that's makes
> much difference.  Further, I can't read either of them now without some
> effort.
>
> Considering that a lot of WebFinger use (I suspect) is going to be
> server-to-server interaction, XML seems like a reasonable format to retain.
> That, and the fact it is already mandatory in RFC 6415 and deployed out
> there.
>
> It's not nostalgia for me.  XML is a very well-structured, readable format.
> No objection to JSON, but I really don't understand the clamoring for JSON.
> I guess more precisely, I don't understand the disdain for XML.  Is it
> because people created hideously complex XML data structures and feel pain
> for having done that?  XRD is not that kind of document.
>
> 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
>

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



On 21 April 2012 18:37, Mike Jones <Michael.Jon=
es@microsoft.com> wrote:

I want to completely agree with what Paul wrote: "What is a pain on th=
e client side is conditional code that has to be followed in order to consu=
me whatever the server wants to send. =A0The client should have a single co=
de path knowing it will get what it wants".




BTW, this is also part of the argument for making the resource parameter re=
quired. =A0Paul's example of:

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


should work on all deployments - not just packetizer.com, so clients can rely on it working (a=
nd not have to have conditional code to try again in a different way when i=
t doesn't).




As a design principle, to the extent there's any complexity, it should =
be pushed to the servers, rather than the clients, as clients will vastly o=
utnumber servers. =A0 =A0The solution should be as simple for clients to us=
e as possible, to facilitate adoption.



if acct: is to become a new protocol for the internet=
 , I request that it should be fully documented, and available for review




 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Best wishes=
,

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



(moved OAuth to bcc)




-----Original Message-----

From: apps-discuss-bounces=
@ietf.org [mailto:apps=
-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones

Sent: Friday, April 20, 2012 9:11 PM

To: 'Michael Thomas'; 'Derek Atkins'

Cc: oauth@ietf.org; 'Apps Discuss=
'

Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery =
(SWD)




Mike,



> On 04/20/2012 07:17 AM, Derek Atkins wrote:

> > <OAUTH Chair Hat> Note that this is a replay of the histori=
cal "MUST

> > Implement" versus "MUST Use" arguments. Just becau=
se the server MUST

> > IMPLEMENT JSON and XML does not mean that a Client must use both =
(or

> > even that a client must implement both). It is perfectly reasonab=
le

> > and generally acceptable to have a server that provides data in
> > multiple formats whereas the client only supports a subset and
> > specifies which format(s) are acceptable. </OAUTH Char Hat>=
 -derek

>

> To Paul's point about how easy it is for a server to support both,=
 I'd

> retort that it's equally easy for a client to gin up JSON instead =
of XML.



I don't follow.



I agree I could write a client that could do JSON easily.

I agree I could write a client that could do XML easily.



What is a pain on the client side is conditional code that has to be follow=
ed in order to consume whatever the server wants to send. =A0The client sho=
uld have a single code path knowing it will get what it wants, ether XML or=
 JSON.




Granted, the server has to have a conditional statement and generate XML or=
 JSON as requested. =A0However, generating either is trivial. =A0Really, I =
did it in minutes. =A0We're not talking about huge complex data structu=
res here with WebFinger.




> Pity the poor programmer who can't get their head around that giga=
ntic

> change. On the other hand, having to support XML and JSON is an

> ongoing maintenance headache server-side. Why do it?



Would we expect to see a lot of changes to the data structures used by WebF=
inger? =A0That's really the only ongoing maintenance issue. =A0Don'=
t touch the code that produces the XML or JSON and there is no ongoing main=
tenance.




> There isn't even the dubious

> religious war like back in the day saying that binary encoded ASN.1
> was "better/faster/stacks and cleans dishes" than "huma=
n readable"

> XML. =A0XML is just a clunky and past its prime text encoding at this<=
br>
> point. Requiring it smacks of nostalgia to me.



I disagree with you on that one. =A0First, ASN.1 is better for defining pro=
tocols, so long as you stay away from the complex stuff. Basic ASN.1 looks =
a lot like C and produces C data structures that can be readily read, decod=
ed, and consumed in C code. =A0Rarely, rarely do I see decoding issues when=
 using ASN.1, whereas issues pop up quite often with text protocols, especi=
ally things like SIP where a semi-colon in the wrong place breaks things. =
=A0But, let's not start that debate again ;-)




XML *can* be big and clunky. =A0As you've well noticed, I can also writ=
e lengthy emails that seem to have more typos as the evening progresses. :-=
)



However, XML can be a very compact encoding and it's extremely readable=
.



I just did a query on my server to see the XML vs. JSON output. =A0The XRD =
document provided was 1032 octets. =A0The JRD document was 1077 octets.

Removing every possible space and making both formats hard as heck to read,=
 JSON was 837 and XML was 940. =A0I'm hard pressed to say that's ma=
kes much difference. =A0Further, I can't read either of them now withou=
t some effort.




Considering that a lot of WebFinger use (I suspect) is going to be server-t=
o-server interaction, XML seems like a reasonable format to retain.

That, and the fact it is already mandatory in RFC 6415 and deployed out the=
re.



It's not nostalgia for me. =A0XML is a very well-structured, readable f=
ormat.

No objection to JSON, but I really don't understand the clamoring for J=
SON.

I guess more precisely, I don't understand the disdain for XML. =A0Is i=
t because people created hideously complex XML data structures and feel pai=
n for having done that? =A0XRD is not that kind of document.



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





--bcaec54eed0a0f510904be3bdb32--

From paulej@packetizer.com  Sat Apr 21 20:45: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 BFD4821F84CF; Sat, 21 Apr 2012 20:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.727
X-Spam-Level: 
X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doymfko5hrGX; Sat, 21 Apr 2012 20:45:19 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B1B3C21F84C8; Sat, 21 Apr 2012 20:45:19 -0700 (PDT)
Received: from dyn-129.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 q3M3jGDt011397 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 21 Apr 2012 23:45:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335066319; bh=sSlvyVlRZHBxrKkue4EWtHU7V1nlt1K+Sm4tjIy+ecA=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=X5CHxNlxpV3V4oaZbJNjCkQYZbsISYdhmYG5WxJF9G5YfJOjBlE+Pggz63oGdJ3qJ sgaUa4m6HNFU9FSaF4FzfKWsr/1cjyqnMq4o3Usi7Z6ysoa0VrQraThzahV3YcqEDj 8spzivZawFnUFCxoC2hTPsnXzeBdrCYYOZbIjUTU=
User-Agent: Kaiten Mail
In-Reply-To: <6.2.5.6.2.20120421124344.0bc4b0c0@resistor.net>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <0a7401cd1f6f$9cb98fd0$d62caf70$@packetizer.com> <6.2.5.6.2.20120421124344.0bc4b0c0@resistor.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----9E36R68R5PZ2DIB67SRN7WKUNISUQN"
From: "Paul E. Jones" 
Date: Sat, 21 Apr 2012 23:45:14 -0400
To: SM 
Message-ID: <53ebd614-da85-4a82-a4cf-85454577c6ec@email.android.com>
Cc: oauth@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Apr 2012 03:45:20 -0000

------9E36R68R5PZ2DIB67SRN7WKUNISUQN
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

Note that requiring both would only be on the server side. While JSON might be the new hip format, I suspect some will use XML for some time. And there are some link relations that might point to XML content. For certain applications like OpenID Connect, they could get by with JSON only, but I bet many other applications will have to deal with a variety of content types, like hcard, vcard, portable contacts, and others that might use something else.

Paul


-------- Original Message --------
From: SM 
Sent: Sat Apr 21 16:03:53 EDT 2012
To: "Paul E. Jones" 
Cc: oauth@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web  Discovery (SWD)

Hi Paul,
At 20:34 20-04-2012, Paul E. Jones wrote:
>My preference has been MUST for XML and JSON since 1) XML is already a MUST
>in RFC 6415 and we'd have to "break" what is there now to remove the MUST
>and 2) people are clearly demanding JSON.

MUST for XML and JSON offers choice but it does make a 
choice.  Encouraging such a polygamous relationship can only end up 
badly.  RFC 6415 was published in October 2011.  Switching 
preferences in less than a year raises some issues about the nature 
of relationships.

Anyway, whether someone break something is not as important as 
picking one option.

Regards,
-sm



------9E36R68R5PZ2DIB67SRN7WKUNISUQN
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

Note that requiring both would only be on the server side. While JSON might be the new hip format, I suspect some will use XML for some time. And there are some link relations that might point to XML content. For certain applications like OpenID Connect, they could get by with JSON only, but I bet many other applications will have to deal with a variety of content types, like hcard, vcard, portable contacts, and others that might use something else.



Paul




From: SM <sm@resistor.net>

Sent: Sat Apr 21 16:03:53 EDT 2012

To: "Paul E. Jones" <paulej@packetizer.com>

Cc: oauth@ietf.org, apps-discuss@ietf.org

Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web  Discovery (SWD)






Hi Paul,
At 20:34 20-04-2012, Paul E. Jones wrote:
>My preference has been MUST for XML and JSON since 1) XML is already a MUST
>in RFC 6415 and we'd have to "break" what is there now to remove the MUST
>and 2) people are clearly demanding JSON.

MUST for XML and JSON offers choice but it does make a 
choice.  Encouraging such a polygamous relationship can only end up 
badly.  RFC 6415 was published in October 2011.  Switching 
preferences in less than a year raises some issues about the nature 
of relationships.

Anyway, whether someone break something is not as important as 
picking one option.

Regards,
-sm



------9E36R68R5PZ2DIB67SRN7WKUNISUQN--


From paulej@packetizer.com  Sat Apr 21 20:51: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 1F07D11E8097 for ; Sat, 21 Apr 2012 20:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.715
X-Spam-Level: 
X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4VgkPQTQffH for ; Sat, 21 Apr 2012 20:51:11 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A49DA21F851D for ; Sat, 21 Apr 2012 20:51:11 -0700 (PDT)
Received: from dyn-129.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 q3M3p7RM011527 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 21 Apr 2012 23:51:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335066670; bh=iD+/wuBQD8sQO+1jSwtkQSMZYDab+Cb5yomd14Ly/54=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=guYmf03pRb/TU4CMqGi5DRvMLM15i3nRG2/0scNEcrm6HAbUUNIavdkV51JRzf3WY JSAV/REAXOb+vjFXrCk+aM+TxUq20BFD9MUzodJk9bxHGJb4pyaov2g3sYFvom9eRR RR3PiKkJOzBhTVYqbv2eE3VTBNP5HjTIJNmu7XMU=
User-Agent: Kaiten Mail
In-Reply-To: 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917CE6.2060904@mtcc.com> <0a7601cd1f74$cc5a26a0$650e73e0$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664920DE@TK5EX14MBXC284.redmond.corp.microsoft.com> 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----JWII7ZD6XR2ECNEZ1AZPSEHB51NJPN"
From: "Paul E. Jones" 
Date: Sat, 21 Apr 2012 23:51:06 -0400
To: Melvin Carvalho , Mike Jones 
Message-ID: 
Cc: Michael Thomas , Derek Atkins , Apps Discuss 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Apr 2012 03:51:13 -0000

------JWII7ZD6XR2ECNEZ1AZPSEHB51NJPN
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

Melvin,

The acct: URI scheme is not a new protocol, but just a scheme that refers to user accounts. It is documented in the WebFinger draft.

Paul


-------- Original Message --------
From: Melvin Carvalho 
Sent: Sat Apr 21 23:09:54 EDT 2012
To: Mike Jones 
Cc: "Paul E. Jones" , Michael Thomas , Derek Atkins , Apps Discuss 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

On 21 April 2012 18:37, Mike Jones  wrote:

> I want to completely agree with what Paul wrote: "What is a pain on the
> client side is conditional code that has to be followed in order to consume
> whatever the server wants to send.  The client should have a single code
> path knowing it will get what it wants".
>
> BTW, this is also part of the argument for making the resource parameter
> required.  Paul's example of:
>        curl -v
> https://packetizer.com/.well-known/host-meta.json?resource=acct:paulej@packetizer.com
> should work on all deployments - not just packetizer.com, so clients can
> rely on it working (and not have to have conditional code to try again in a
> different way when it doesn't).
>
> As a design principle, to the extent there's any complexity, it should be
> pushed to the servers, rather than the clients, as clients will vastly
> outnumber servers.    The solution should be as simple for clients to use
> as possible, to facilitate adoption.
>

if acct: is to become a new protocol for the internet , I request that it
should be fully documented, and available for review


>                                Best wishes,
>                                -- Mike
>
> (moved OAuth to bcc)
>
> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of Paul E. Jones
> Sent: Friday, April 20, 2012 9:11 PM
> To: 'Michael Thomas'; 'Derek Atkins'
> Cc: oauth@ietf.org; 'Apps Discuss'
> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery
> (SWD)
>
> Mike,
>
> > On 04/20/2012 07:17 AM, Derek Atkins wrote:
> > >  Note that this is a replay of the historical "MUST
> > > Implement" versus "MUST Use" arguments. Just because the server MUST
> > > IMPLEMENT JSON and XML does not mean that a Client must use both (or
> > > even that a client must implement both). It is perfectly reasonable
> > > and generally acceptable to have a server that provides data in
> > > multiple formats whereas the client only supports a subset and
> > > specifies which format(s) are acceptable.  -derek
> >
> > To Paul's point about how easy it is for a server to support both, I'd
> > retort that it's equally easy for a client to gin up JSON instead of XML.
>
> I don't follow.
>
> I agree I could write a client that could do JSON easily.
> I agree I could write a client that could do XML easily.
>
> What is a pain on the client side is conditional code that has to be
> followed in order to consume whatever the server wants to send.  The client
> should have a single code path knowing it will get what it wants, ether XML
> or JSON.
>
> Granted, the server has to have a conditional statement and generate XML
> or JSON as requested.  However, generating either is trivial.  Really, I
> did it in minutes.  We're not talking about huge complex data structures
> here with WebFinger.
>
> > Pity the poor programmer who can't get their head around that gigantic
> > change. On the other hand, having to support XML and JSON is an
> > ongoing maintenance headache server-side. Why do it?
>
> Would we expect to see a lot of changes to the data structures used by
> WebFinger?  That's really the only ongoing maintenance issue.  Don't touch
> the code that produces the XML or JSON and there is no ongoing maintenance.
>
> > There isn't even the dubious
> > religious war like back in the day saying that binary encoded ASN.1
> > was "better/faster/stacks and cleans dishes" than "human readable"
> > XML.  XML is just a clunky and past its prime text encoding at this
> > point. Requiring it smacks of nostalgia to me.
>
> I disagree with you on that one.  First, ASN.1 is better for defining
> protocols, so long as you stay away from the complex stuff. Basic ASN.1
> looks a lot like C and produces C data structures that can be readily read,
> decoded, and consumed in C code.  Rarely, rarely do I see decoding issues
> when using ASN.1, whereas issues pop up quite often with text protocols,
> especially things like SIP where a semi-colon in the wrong place breaks
> things.  But, let's not start that debate again ;-)
>
> XML *can* be big and clunky.  As you've well noticed, I can also write
> lengthy emails that seem to have more typos as the evening progresses. :-)
>
> However, XML can be a very compact encoding and it's extremely readable.
>
> I just did a query on my server to see the XML vs. JSON output.  The XRD
> document provided was 1032 octets.  The JRD document was 1077 octets.
> Removing every possible space and making both formats hard as heck to
> read, JSON was 837 and XML was 940.  I'm hard pressed to say that's makes
> much difference.  Further, I can't read either of them now without some
> effort.
>
> Considering that a lot of WebFinger use (I suspect) is going to be
> server-to-server interaction, XML seems like a reasonable format to retain.
> That, and the fact it is already mandatory in RFC 6415 and deployed out
> there.
>
> It's not nostalgia for me.  XML is a very well-structured, readable format.
> No objection to JSON, but I really don't understand the clamoring for JSON.
> I guess more precisely, I don't understand the disdain for XML.  Is it
> because people created hideously complex XML data structures and feel pain
> for having done that?  XRD is not that kind of document.
>
> 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
>

------JWII7ZD6XR2ECNEZ1AZPSEHB51NJPN
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

Melvin,



The acct: URI scheme is not a new protocol, but just a scheme that refers to user accounts. It is documented in the WebFinger draft.



Paul




From: Melvin Carvalho <melvincarvalho@gmail.com>

Sent: Sat Apr 21 23:09:54 EDT 2012

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: "Paul E. Jones" <paulej@packetizer.com>, Michael Thomas <mike@mtcc.com>, Derek Atkins <derek@ihtfp.com>, Apps Discuss <apps-discuss@ietf.org>

Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)







On 21 April 2012 18:37, Mike Jones <Michael.Jones@microsoft.com> wrote:

I want to completely agree with what Paul wrote: "What is a pain on the client side is conditional code that has to be followed in order to consume whatever the server wants to send.  The client should have a single code path knowing it will get what it wants".




BTW, this is also part of the argument for making the resource parameter required.  Paul's example of:

        curl -v https://packetizer.com/.well-known/host-meta.json?resource=acct:paulej@packetizer.com


should work on all deployments - not just packetizer.com, so clients can rely on it working (and not have to have conditional code to try again in a different way when it doesn't).




As a design principle, to the extent there's any complexity, it should be pushed to the servers, rather than the clients, as clients will vastly outnumber servers.    The solution should be as simple for clients to use as possible, to facilitate adoption.



if acct: is to become a new protocol for the internet , I request that it should be fully documented, and available for review





                                Best wishes,

                                -- Mike



(moved OAuth to bcc)




-----Original Message-----

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones

Sent: Friday, April 20, 2012 9:11 PM

To: 'Michael Thomas'; 'Derek Atkins'

Cc: oauth@ietf.org; 'Apps Discuss'

Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)




Mike,



> On 04/20/2012 07:17 AM, Derek Atkins wrote:

> > <OAUTH Chair Hat> Note that this is a replay of the historical "MUST

> > Implement" versus "MUST Use" arguments. Just because the server MUST

> > IMPLEMENT JSON and XML does not mean that a Client must use both (or

> > even that a client must implement both). It is perfectly reasonable

> > and generally acceptable to have a server that provides data in

> > multiple formats whereas the client only supports a subset and

> > specifies which format(s) are acceptable. </OAUTH Char Hat> -derek

>

> To Paul's point about how easy it is for a server to support both, I'd

> retort that it's equally easy for a client to gin up JSON instead of XML.



I don't follow.



I agree I could write a client that could do JSON easily.

I agree I could write a client that could do XML easily.



What is a pain on the client side is conditional code that has to be followed in order to consume whatever the server wants to send.  The client should have a single code path knowing it will get what it wants, ether XML or JSON.




Granted, the server has to have a conditional statement and generate XML or JSON as requested.  However, generating either is trivial.  Really, I did it in minutes.  We're not talking about huge complex data structures here with WebFinger.




> Pity the poor programmer who can't get their head around that gigantic

> change. On the other hand, having to support XML and JSON is an

> ongoing maintenance headache server-side. Why do it?



Would we expect to see a lot of changes to the data structures used by WebFinger?  That's really the only ongoing maintenance issue.  Don't touch the code that produces the XML or JSON and there is no ongoing maintenance.




> There isn't even the dubious

> religious war like back in the day saying that binary encoded ASN.1

> was "better/faster/stacks and cleans dishes" than "human readable"

> XML.  XML is just a clunky and past its prime text encoding at this

> point. Requiring it smacks of nostalgia to me.



I disagree with you on that one.  First, ASN.1 is better for defining protocols, so long as you stay away from the complex stuff. Basic ASN.1 looks a lot like C and produces C data structures that can be readily read, decoded, and consumed in C code.  Rarely, rarely do I see decoding issues when using ASN.1, whereas issues pop up quite often with text protocols, especially things like SIP where a semi-colon in the wrong place breaks things.  But, let's not start that debate again ;-)




XML *can* be big and clunky.  As you've well noticed, I can also write lengthy emails that seem to have more typos as the evening progresses. :-)



However, XML can be a very compact encoding and it's extremely readable.



I just did a query on my server to see the XML vs. JSON output.  The XRD document provided was 1032 octets.  The JRD document was 1077 octets.

Removing every possible space and making both formats hard as heck to read, JSON was 837 and XML was 940.  I'm hard pressed to say that's makes much difference.  Further, I can't read either of them now without some effort.




Considering that a lot of WebFinger use (I suspect) is going to be server-to-server interaction, XML seems like a reasonable format to retain.

That, and the fact it is already mandatory in RFC 6415 and deployed out there.



It's not nostalgia for me.  XML is a very well-structured, readable format.

No objection to JSON, but I really don't understand the clamoring for JSON.

I guess more precisely, I don't understand the disdain for XML.  Is it because people created hideously complex XML data structures and feel pain for having done that?  XRD is not that kind of document.



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





------JWII7ZD6XR2ECNEZ1AZPSEHB51NJPN--


From ht@inf.ed.ac.uk  Sun Apr 22 03:23: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 A6D9621F85E4 for ; Sun, 22 Apr 2012 03:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.572
X-Spam-Level: 
X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsuASLoMXKw3 for ; Sun, 22 Apr 2012 03:23:48 -0700 (PDT)
Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 830CB21F85DF for ; Sun, 22 Apr 2012 03:23:47 -0700 (PDT)
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 q3MANP45026783; Sun, 22 Apr 2012 11:23:30 +0100 (BST)
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 q3MANPex003425; Sun, 22 Apr 2012 11:23:25 +0100
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 q3MANOsn030633;  Sun, 22 Apr 2012 11:23:24 +0100
Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3MANN2p030629; Sun, 22 Apr 2012 11:23:23 +0100
X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: Ned Freed 
References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com>  <4F87EBD4.90501@gmx.de>  <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com>  <01OELBFKD4W400ZGHB@mauve.mrochek.com>
From: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Sun, 22 Apr 2012 11:23:23 +0100
In-Reply-To: <01OELBFKD4W400ZGHB@mauve.mrochek.com> (Ned Freed's message of "Sat, 21 Apr 2012 19:20:17 -0700 (PDT)")
Message-ID: 
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (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, Tony Hansen , "www-tag@w3.org List" 
Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type	Specifications and Registration Procedures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Apr 2012 10:23:49 -0000

Ned Freed writes:

> First of all, given that there has been no I-D posting of a 3023bis "active
> development" is a bit of a stretch. There may be something going on inside the
> W3C, but 3023 is an IETF RFC, and that means new versions need to be posted as
> I-Ds and discussion needs to be happning on an IETF list. I strongly urge
> whoever is working on this to see that this happens ASAP.

Absolutely -- the 'active development' I refer to is only a few weeks
old, and the goal is to get a new I-D up as soon as possible.

> All that aside, this sort of revision is the reason why Tony is
> taking this approach. An 3023bis is necessarily going to contain
> both a new registration for application/xml, quite likely including
> updated information on XML fragment identifiers. Additionally, since
> +xml is defined in 3023 and assuming the new media types
> registration procedures are in place before 3023bis, 3023bis is
> going to have to contain an updated registration for +xml.

Since +xml is the structured syntax we have the most experience with
to date, I hope we can coordinate the two, so that the experience of
the XML community is not lost.

>> and that something very similar to the following (slightly adapted
>> from the previous editors' draft) will likely appear therein:
>
>>   When a new media type is introduced for an XML-based format, the
>>   name of the media type SHOULD end with '+xml'. This convention will
>>   allow applications that can process XML generically to detect that
>>   the MIME entity is supposed to be an XML document, verify this
>>   assumption by invoking some XML processor, and then process the XML
>>   document accordingly. Applications may match for types that
>>   represent XML MIME entities by comparing the subtype to the pattern
>>   '*/*+xml'.
>
>>   XML generic processing is not always appropriate for XML-based media
>>   types. For example, authors of some such media types may wish that
>>   the types remain entirely opaque except to applications that are
>>   specifically designed to deal with that media type. By NOT following
>>   the naming convention '+xml', such media types can avoid XML-generic
>>   processing. Since generic processing will be useful in many cases,
>>   however -- including in some situations that are difficult to
>>   predict ahead of time -- those registering media types SHOULD use
>>   the '+xml' convention unless they have a particularly compelling
>>   reason not to. [1]
>
>> Note that these paragraphs address _more_ than just fragment
>> identifiers.  The level of "generic processing", i.e. processing
>> appropriate to any member of a stuctured-syntax family identified by a
>> +SUFFIX, is I think the appropriate one at which to address the mutual
>> dependency between app/foo and app/bar+foo.
>
> Of course. And this actually won't be sufficient - as noted above, a
> proper +xml registration will also be needed.

For sure -- 3023 contained one, informally, as it were, in the absence
of official guidance at that time, and 3023bis will do so as well,
coordinated, as I said above, with the new official guidance.

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  Sun Apr 22 03:26: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 7AC6721F85AE for ; Sun, 22 Apr 2012 03:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZEav5bS7bUi for ; Sun, 22 Apr 2012 03:26:03 -0700 (PDT)
Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id BB07521F84EA for ; Sun, 22 Apr 2012 03:26:02 -0700 (PDT)
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 q3MAQ05N026996; Sun, 22 Apr 2012 11:26:00 +0100 (BST)
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 q3MAQ0Jt003451; Sun, 22 Apr 2012 11:26:00 +0100
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 q3MAPxIh030716;  Sun, 22 Apr 2012 11:25:59 +0100
Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3MAPxD3030711; Sun, 22 Apr 2012 11:25:59 +0100
X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: Bjoern Hoehrmann 
References: <4F87EBD4.90501@gmx.de>  <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> <2ee3p79ijn5orc4i6m85hqfm7ta4vv55mb@hive.bjoern.hoehrmann.de>  <9ua6p79fh03lm9i7f6l98jorsnu9erqqi1@hive.bjoern.hoehrmann.de>  
From: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Sun, 22 Apr 2012 11:25:59 +0100
In-Reply-To:  (Bjoern Hoehrmann's message of "Sun, 22 Apr 2012 00:32:58 +0200")
Message-ID: 
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (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: www-tag@w3.org, Tony Hansen , apps-discuss@ietf.org
Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Apr 2012 10:26:03 -0000

Bjoern Hoehrmann writes:

> * Henry S. Thompson wrote:
>>Bjoern Hoehrmann writes:
>>
>>> Saying that an inferior authority must obey a superior authority does
>>> not imply that the superior authority is limited by choices any such
>>> inferior authorities have made. We might find that taking such choices
>>> into consideration is the responsible thing to do, but that is not what
>>> the text says, and certainly not how authorities tend to operate. Look
>>> no further than the +xml discussions where people do not find they need
>>> to re-define +xml in a manner compatible with all existing +xml types.
>>
>>Actually, we've been continuing to struggle with that, [...]
>
> Yes, indeed. That is the problem with the interpretation you proposed.

Sorry I wasn't clear -- by "been continuing to struggle with" I meant
"been working to achieve compatibility with all existing types".

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 internet-drafts@ietf.org  Sun Apr 22 08:18: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 E44F721F85EA; Sun, 22 Apr 2012 08:18:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.414
X-Spam-Level: 
X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiME91wlttMa; Sun, 22 Apr 2012 08:18:59 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3734B21F85E6; Sun, 22 Apr 2012 08:18:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120422151859.4884.91666.idtracker@ietfa.amsl.com>
Date: Sun, 22 Apr 2012 08:18:59 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-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, 22 Apr 2012 15:19:00 -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 Worki=
ng Group of the IETF.

	Title           : Update to MIME regarding Charset Parameter Handling in T=
extual Media Types
	Author(s)       : Alexey Melnikov
                          Julian F. Reschke
	Filename        : draft-ietf-appsawg-mime-default-charset-03.txt
	Pages           : 6
	Date            : 2012-04-22

   This document changes RFC 2046 rules regarding default charset
   parameter values for text/* media types to better align with common
   usage by existing clients and servers.

Editorial Note (To be removed by RFC Editor)

   Discussion of this draft should take place on the Apps Area Working
   Group mailing list (apps-discuss@ietf.org), which is archived at
   .


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-mime-default-charset=
-03.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-mime-default-charset-=
03.txt


From julian.reschke@gmx.de  Sun Apr 22 08: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 5A44621F85F9 for ; Sun, 22 Apr 2012 08:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDpmOu35Ug70 for ; Sun, 22 Apr 2012 08:24:50 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6139F21F85C3 for ; Sun, 22 Apr 2012 08:24:50 -0700 (PDT)
Received: (qmail invoked by alias); 22 Apr 2012 15:24:48 -0000
Received: from p5DD9641C.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.100.28] by mail.gmx.net (mp039) with SMTP; 22 Apr 2012 17:24:48 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18FFJhSn7kFrJsvI3WVU/Wak3xYZlbKk+s7DBcwEF QR1Op9ASfsOXXT
Message-ID: <4F9422A0.9000004@gmx.de>
Date: Sun, 22 Apr 2012 17:24:16 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: internet-drafts@ietf.org
References: <20120422151859.4884.91666.idtracker@ietfa.amsl.com>
In-Reply-To: <20120422151859.4884.91666.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss@ietf.org, i-d-announce@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-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, 22 Apr 2012 15:24:51 -0000

On 2012-04-22 17:18, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF.
> ...

Hi there.

The WGLC for this document ended on Friday.

Draft -02, submitted yesterday, contained a few tiny editorial fixes. 
See 
.

Draft -03, submitted a few minutes ago, clarifies what we ask IANA to do 
(based on AD feedback). See 


Best regards,  Julian

From Claudio.Allocchio@garr.it  Sun Apr 22 08:44: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 564D521F85AD; Sun, 22 Apr 2012 08:44:10 -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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+kPQRt8FcIj; Sun, 22 Apr 2012 08:44:09 -0700 (PDT)
Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA2821F84BF; Sun, 22 Apr 2012 08:44:08 -0700 (PDT)
Received: from mac-allocchio3.garrtest.units.it (mac-allocchio3.garrtest.units.it [140.105.201.3]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q3MFh8nA053088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2012 17:43:13 +0200 (CEST)
X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q3MFh8nA053088
DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=m8oLasa/slmUvwrYvz3fQ084Qg8rdiM31WsRILDgiV/Ftp4RPQJUIRF6wls3PreKo 4Qc6oGl163BRrwiJU47kWdHXL8EWSzoAABZG+9iM2z0S8PoGQHfyRpnGbix6zf+aVjl 1Et7kIoVDOhJUGsAzkWndrPNitcbpv/qjoVna+4=
Date: Sun, 22 Apr 2012 17:43:07 +0200 (CEST)
From: Claudio Allocchio 
X-X-Sender: claudio@mac-allocchio3.garrtest.units.it
To: Alexey Melnikov 
In-Reply-To: <4F8F1733.1040407@isode.com>
Message-ID: 
References:  <4F8F1733.1040407@isode.com>
User-Agent: Alpine 2.02 (OSX 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: draft-melnikov-smtp-priority.all@tools.ietf.org, apps-discuss@ietf.org, iesg@ietf.org
Subject: Re: [apps-discuss] APPSDIR review of draft-melnikov-smtp-priority-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Apr 2012 15:44:10 -0000

Hello Alexey,


On Wed, 18 Apr 2012, Alexey Melnikov wrote:

> Hi Claudio,
> Thank you for the review and sorry for the delayed response: I've started 
> writing some replies, but I only now got around to updating my copy of the 
> document.

no problem, we are all quite busy!

See inline.
>
> On 28/03/2012 17:12, Claudio Allocchio wrote:

>> Summary:
>> 
>> In its declared scope, this document provides a mechamism (and 
>> implementation suggestions) in order to enble a "real" priority delivery 
>> service into the global e-mail handling scenario.
>> 
>> However, it also introduces a concept idea on how to "tunnel" new SMTP 
>> parameters requests via MTAs which do not support and ignore them, 
>> embedding them into e-mail Heders fields. In doing this it breaks the ideal 
>> separation between Envelope (SMTP) and Content (Headers and bodyparts) in a 
>> different a new way than it was done before, because is causes Headers to 
>> be able to modify Envelope parameters. There is no negative consideration 
>> in this, but this feature should also be stated more explicitly in the 
>> introduction.
> Right. Based on IETF LC feedback and after talking to Apps AD the plan is to 
> split the document into 2: one will describe a pure SMTP extension (with no 
> tunneling) and will be targeted at Proposed Standard. Another one will be an 
> Experimental document that talks about tunneling and gatewaying. So I will 
> have more explicit text about this in the latter document.

Very good solution!

>> In general the document is well specified, and no major technical issues 
>> are present. However I suggest yet another turn of consideraion for the 
>> state iself of the specification: the WG and many others propose to go into 
>> Standards Track, but in order to do this there are at least some more 
>> exlicit considerations to clarify into the text itself. Also, it is not 
>> easy to guess what will be the adoption level of this mechanism,
> That is true.
>> and the risk introduced by possible inaccurate implementations shall also 
>> be evaluated before going Proposed Standard.
> Can you be more specific here?
>
> A MTA implementation which accepts the PRIORITY parameter and ignores it is 
> not particularly harmful. An implementation that treats higher priority 
> messages as lower priority messages is, well, broken. So I am not entirely 
> sure what are you thinking about here.

I was considering not specifically the "PRIORITY" case, but in general the 
idea of the parameters tunneling which is introduced. Of course a 
mismatched PRIORITY request is not harmful, but if another more essential 
parameter is tunnelled and lost in transactions (imagine a DSN reuqest for 
example, if somebody decides to use the mechanism to bypass non DSN 
conformat e-mail systems...) then it can be harmful. Thus I was 
considering a possible future scenario, and that's why I was sggesting 
Experimental for the tunnelling mechanism. As you will split documents, my 
suggestion is fully accomplished :-)

>> Major Issues:
>> 
>> The first major issue is non-technical. The e-mail service via SMTP (and 
>> gateways and other related transport protocols) is best-effort, often 
>> first-in/first-out based. And by itself, e-mail is a non real-time service,
> In practice I might disagree with you on that, although I see your point.

I kno people tend to consider e-mail as a real time way to get information 
to somebody... I do it myself... but, theoretically, we cannot complain if 
somebody reads the information one week later :-)

>> like a chat, or text broadcast services: it is delivered into a mailbox 
>> where the recipient will read it at his/her will. Although many mail 
>> clients now uses a push-like model, delivering messages on "always on" 
>> devices, the proposed new service extension aims to provide differentiated 
>> service among messages. As correctly stated into the document iself, there 
>> is a parallel between this and network transport level services, where 
>> packets are prioritised. But also in this case, the proposed mechanism will 
>> start to produce benefits only when congestion in some parts of the mail 
>> transport system exists. When congestion does not exist, the mechanisms 
>> will not result in better service. This is not a drawback, but it should be 
>> stated more explicitly in the document. Maybe expanding it into the 5.4 
>> section, where comparison with RFC2474 and RFC2205 are done.
> Good point. I will add some text about that.

ok.

>> The other major issue to consider is the global trust model which is needed 
>> to implement the mechanisms. There are suggestions in the specification on 
>> how to enhance security when tunnelling across non supporting MTAs, for 
>> example, but in the document there are also other suggestions which 
>> consider the extension applicable easily only within restricted trusted 
>> communities.
> This extension pretty much requires establishing of some trust between a 
> sender and a recipient. I will make sure this is clear in the document. Some 
> relevant text is already in the Security Considerations, but I will make it 
> stronger.

ok.

>> This apparently contradictory point shall be explained better. If this 
>> specification is going Proposed Standard, it shall be crystal clear about 
>> these scenarios, because implementers who did not take part in the original 
>> discussion will implement it, and thus all pre-assupmtions made during the 
>> discussion process of the specification discussion will not be available 
>> for them.
>> 
>> Minor Issues:
>> 
>> There is no discussion (explicit) about how this specification 
>> interacts/interferes with anti-spam techniques like graylisting / 
>> whitelisting. Section 5.1 suggests that shorter retry times shall be used 
>> for higher priority messages, but it does not mention at all graylisting, 
>> for example. This should be explicitly mentioned, and some guidance / 
>> suggestion given, to ensure a coherent behaviour.

> As this extension requires some form of trust relationship and authentication 
> (whether using SMTP AUTH, TLS, IP address whitelist, etc.), then greylisting 
> should be disabled. But if you think this should be explicitly mentioned, I 
> can mention it.

Just expand you sentence above in the document, and that's perfect.

>> The sentence in section 2 "The most important reason for emails to be 
>> delayed is a transient error response from the next MTA to which the email 
>> must be transferred." should also explicitly refer to the graylisting case 
>> (which also causes often a "reply" message to be delivered before the 
>> original message is).

> Actually, I would rather delete the whole paragraph, as it doesn't add value 
> to the spec (the definition is not used anywhere). Besides greylisting will 
> cause transient errors.

ok.

>> Section 4.2: why allowing an X-something like X-Priority to be used?
> Because it is widely used (due to Exchange and some MUAs).

I see the point.

>> I understand why not "Importance" and why yes "Priority"... but...
>> Maybe this specification should "update" or even attempt to Obsolete 
>> partially RFC2156?
> I don't think it would be a good idea to touch RFC 2156. What do you think is 
> broken in it anyway?

Nothing broken technically. It might just lead some confusion... in 
implementers. But it's a minor point, you can ignore my comment and that's 
fine anyhow.

>> Section 4.5: the text say that in case of mailing lists and aliases the 
>> Header parameters tunnelling this specification extension SHOULD retain the 
>> original priority. What about the many implementations where headers are 
>> completely re-written and many parameters just disappear? Some sentence 
>> should be given about this case, too.
> Can you suggest some specific case? SHOULD is here is exactly to address this 
> kind of case, but I have hard time explaining why it can be violated in 
> general terms.

The SHOULD makes existing ML implementaions compliant :-)

Just add that "in some cases, a ML service might result is dropping the 
tunnelling parameter".


>> Section 4.6... not all "non e-mail" environment allow addition of an 
>> "header field"... how do we handle this?
> Are you talking about the following text:
>
>   1.  If the destination environment is unable to provide an equivalent
>       of the MT-PRIORITY parameter, the conforming MTA SHOULD behave as
>       if it is relaying to a non-conformant SMTP (Section 4.4).
>
> ? (Which would imply adding a header field for tunneling the priority)

yes.

> If yes, I can clarify that this might be an exception.

ok.

>> 
>> Section 9: given the current architecture, I'm very worried this will 
>> ALWAYS happen (different behaviours because different support at various 
>> MX-pointed servers). I'd make the consideration more explicit and suggest a 
>> stronger guidance.
> Can you suggest an improved text? I've changed "advised" to "strongly 
> advised", but have troubles improving this text.

true, not easy... something like:

    If multiple DNS MX records are used to specify multiple servers for a
    domain in section 5 of [RFC5321], it is strongly advised that all of
    them support the MT-PRIORITY extension and handles priorities is
    exactly then same way. If one or more server does behave like that,
    (or even when you cannot fully control the servers behaviour or
    configuration), then it is strongly suggested that none of the servers
    support the MT-PRIORITY extension.
    Otherwise, unexpected differences in message delivery speed or even
    rejections can happen during temporary or permanent failures, which
    users might perceive as serious reliability issues.

this makes the comment stronger... maybe to strong... it's up tp you to 
accept or ignore this stronger version. But also your minimal "strongly 
advised" in the original text is already enough.

>> Appendix A, B, C are very environment specific. Appendix A and C, however, 
>> seem very specific environment related (the NATO messaging military 
>> convetions for "A" and the USA Civil Protecion service for "C"). While "B" 
>> is really global, beacause it maps OSI X.400 service, the other two 
>> appendix seems too environment specific for an international standard RFC 
>> specification. I would suggest handling at least "A' and "C"  not as 
>> appendixes of this document, but as separate short "mapping specification", 
>> also to enable further similar documents to be published/registered more 
>> easily for other environments.
> As per my comment above, most of these will move to a separate specification 
> about tunneling.

ok !

>
> Best Regards,
> Alexey
>
>
>

------------------------------------------------------------------------------
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 romeda@gmail.com  Sun Apr 22 14:15: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 D2C2C21F8585 for ; Sun, 22 Apr 2012 14:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.451
X-Spam-Level: 
X-Spam-Status: No, score=-103.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WOmZg1Yuqtl for ; Sun, 22 Apr 2012 14:15:32 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF84A21F8581 for ; Sun, 22 Apr 2012 14:15:31 -0700 (PDT)
Received: by lagj5 with SMTP id j5so9178404lag.31 for ; Sun, 22 Apr 2012 14:15:31 -0700 (PDT)
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=kw9Jpu3590BnZe1exujBrCRf+WQ6drFB63fIoDori58=; b=NN6opMQ50hLEpVb2vLoRki7fGdXH05Lr57ocTu1198tGZX7lTAmHHih/sgAibu9pyK CQc9+L0kWDHloKrp8k76jD+7xLZ05bIBRS2oN1p4FD0F0jRVzfPaoQ6C7iX/j/u6M9c7 0V3zavvRKbGQRBxXWmvLYtSJd9UusgW9PYenAyYxIOOERG0MbS8w4Fp5Khk9Sj52QzrQ 1VFHZdDb8QhCoDByhGkIinobVssFJukkSXbFdt4Pu+xguSiOctgQCepRdFfRekfaQzAx SkwEZNeX92wU+TCiUVq2jOFPv5YX9rfx9SxHVy6wvE79r29y3xVQAn0T8wxbWWZU7tXy bwFw==
Received: by 10.112.85.230 with SMTP id k6mr1100234lbz.49.1335129330974; Sun, 22 Apr 2012 14:15:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.24.229 with HTTP; Sun, 22 Apr 2012 14:15:10 -0700 (PDT)
From: Blaine Cook 
Date: Sun, 22 Apr 2012 22:15:10 +0100
Message-ID: 
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=f46d0401fa11807e5904be4b0527
Subject: [apps-discuss] Webfinger / SWD Issue #1: JSON versus XML
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Apr 2012 21:15:33 -0000

--f46d0401fa11807e5904be4b0527
Content-Type: text/plain; charset=UTF-8

Hi all,

The previous thread got a bit unwieldy, so I'm trying to break apart the
issues so that we can move forward.

First up, the XML versus JSON question. I'm not entirely sure how to get
consensus on the apps-discuss list, but my read has many people either
indifferent or pro-JSON-only. We have advice from two [of the most]
experienced practitioners (Tim Bray and Mark Nottingham) that we should
pick exactly one format. The number of formats shall be one, not two. Three
is right out. We're free to disagree, but I don't get the sense that we do
disagree on the whole. I agree with Tim and Mark on this one.

As for which of the two, despite the fact that they're basically the same,
and Webfinger has a number of *deployed* XRD endpoints for whom we'd be
breaking support, I'd argue for JSON because it's popular, but really
because it's easier to handle programmatically in most production languages
today. JSON is a special kind of hell for building large documents, but for
small packets of regular data, JSON is a great fit and XML is overkill.

Please reply to this message *only* if you're so opposed to SWD/Webfinger
being JSON-only that you're willing to put the whole project on hold to
have your way. If you feel that way, please do reply (no really, this
process only works if people reply with their strongly-held beliefs). :-)

b.

--f46d0401fa11807e5904be4b0527
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,

The previous thread got a bit unwieldy, so I'=
;m trying to break apart the issues so that we can move forward.
=

First up, the XML versus JSON question. I'm not entirely=
 sure how to get consensus on the apps-discuss list, but my read has many p=
eople either indifferent or pro-JSON-only. We have advice from two [of the =
most] experienced practitioners (Tim Bray and Mark Nottingham) that we shou=
ld pick exactly one format. The number of formats shall be one, not two. Th=
ree is right out. We're free to disagree, but I don't get the sense=
 that we do disagree on the whole. I agree with Tim and Mark on this one.




As for which of the two, despite the fact that they'=
;re basically the same, and Webfinger has a number of *deployed* XRD endpoi=
nts for whom we'd be breaking support, I'd argue for JSON because i=
t's popular, but really because it's easier to handle programmatica=
lly in most production languages today. JSON is a special kind of hell for =
building large documents, but for small packets of regular data, JSON is a =
great fit and XML is overkill.





Please reply to this message *only* if you're so op=
posed to SWD/Webfinger being JSON-only that you're willing to put the w=
hole project on hold to have your way. If you feel that way, please do repl=
y (no really, this process only works if people reply with their strongly-h=
eld beliefs). :-)





b.


--f46d0401fa11807e5904be4b0527--

From romeda@gmail.com  Sun Apr 22 14:15: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 DA98E21F85A0 for ; Sun, 22 Apr 2012 14:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.188
X-Spam-Level: 
X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeSKASSZycuX for ; Sun, 22 Apr 2012 14:15:36 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 04D8321F859F for ; Sun, 22 Apr 2012 14:15:35 -0700 (PDT)
Received: by mail-lpp01m010-f44.google.com with SMTP id j5so9178404lag.31 for ; Sun, 22 Apr 2012 14:15:35 -0700 (PDT)
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=QLvuyC0XC8RNPnlyYLEcLJVe29xuwgGYYryeZ0Vtgxo=; b=OYt7IYgIPjA/Nh7+dVzB0zNa81vyQyUT0MV3Y1BzRAvKWO+oBRqD4S47y4iEknAsb1 s3Nzin4j3DEBum9Scz+RNFQooyKyNbhCsU+q1u29BqVIEEp9lI7MWClapP6ThgFeYbaK FiunCivhoC21w9xrVxOLj7xN2gPY+wsDyC6ApUphDKPi/7hgvOOUfWnsipxzx4VlxMaI nJ5y3rGE41mJamI8bAu7eno5O9JYCYbcd8bpe1z6bby2zOynBIQfS9ulXb+3Z8YdZFtI a7yUCOMbsmzGkpH8B61BbdK4J9fWgZFL1kG62wLu4zv6UOPMHQa3UN26VO/LKCgvHpla wjoQ==
Received: by 10.112.37.99 with SMTP id x3mr815090lbj.7.1335129335609; Sun, 22 Apr 2012 14:15:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.24.229 with HTTP; Sun, 22 Apr 2012 14:15:15 -0700 (PDT)
From: Blaine Cook 
Date: Sun, 22 Apr 2012 22:15:15 +0100
Message-ID: 
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=e0cb4efe2f64c73acb04be4b0515
Subject: [apps-discuss] Webfinger / SWD Issue #2: JSON format
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Apr 2012 21:15:37 -0000

--e0cb4efe2f64c73acb04be4b0515
Content-Type: text/plain; charset=UTF-8

As a follow on to Issue #1, we also need to know the specific format to be
used to describe the discovery metadata.

I think [in the unlikely event we choose XML-only] the XML format is easy:
XRD is a good format, one that had lots of attention and is truly about as
simple as we'll ever see (i.e., it's effectively a subset of HTML 
tags).

However, in the more likely event that we choose XML+JSON or JSON-only,
we'll need to decide on a format.

Webfinger uses JRD, while SWD uses a JSON response with a single key,
"locations", that points to an array of locations where the service is
available. Given that (it seems) we want to be able to provide multiple
services per request versus SWD's single service per request, JRD is a
likely candidate.

Are there other response formats we should be considering? Is there already
implicit consensus on using JRD?

b.

--e0cb4efe2f64c73acb04be4b0515
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

As a follow on to Issue #1, we also need to know the specific format to be =
used to describe the discovery metadata.

I think [in the=
 unlikely event we choose XML-only] the XML format is easy: XRD is a good f=
ormat, one that had lots of attention and is truly about as simple as we=
9;ll ever see (i.e., it's effectively a subset of HTML <head> tag=
s).






However, in the more likely event that we choose XML+JS=
ON or JSON-only, we'll need to decide on a format.

=

Webfinger uses JRD, while SWD uses a JSON response with a single key, =
"locations", that points to an array of locations where the servi=
ce is available. Given that (it seems) we want to be able to provide multip=
le services per request versus SWD's single service per request, JRD is=
 a likely candidate.





Are there other response formats we should be consideri=
ng? Is there already implicit consensus on using JRD?

<=
div>b.


--e0cb4efe2f64c73acb04be4b0515--

From romeda@gmail.com  Sun Apr 22 14:15: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 52A2C21F8319 for ; Sun, 22 Apr 2012 14:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.45
X-Spam-Level: 
X-Spam-Status: No, score=-103.45 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uYbR22YGDfw for ; Sun, 22 Apr 2012 14:15:40 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9EA21F85BD for ; Sun, 22 Apr 2012 14:15:39 -0700 (PDT)
Received: by mail-lpp01m010-f44.google.com with SMTP id j5so9178404lag.31 for ; Sun, 22 Apr 2012 14:15:39 -0700 (PDT)
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=U6kEebKzHuP7Es8J7FHMWk3IW6+syBu3dc9OztbEk/w=; b=x4bxpOb4fyHhyxmSfSqXnrQbl8WqgFOZnD69TP7N6SfX9YdpCshWYqZPmLln+Ix3ZX 8o2R7yk2Ew6G4hRKUfMreyd20ECQL9THOu8l1QXIHTq/sEnar0ozUjS0mrN+spALgztD Id1bLOyIOPdEqHV/qu4TMOY0gvueuJ2ksJPayVnQwvk0mTEINmvJ2ML5h5g1+UFc5KXm dmzTApwL0fA6aJqG/oc/RxiFbOlvqlYrQljZiHD9CtXaU6JRpxJLe1AR56PbdkVOBZFr VEdIKI97qR3O0KcMmUvR4diqXYuBGyR7Of9Qo2KwWRVccbHaH4gnQPyQUp6pHDy3fqJP usuQ==
Received: by 10.152.146.163 with SMTP id td3mr8530851lab.25.1335129339843; Sun, 22 Apr 2012 14:15:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.24.229 with HTTP; Sun, 22 Apr 2012 14:15:19 -0700 (PDT)
From: Blaine Cook 
Date: Sun, 22 Apr 2012 22:15:19 +0100
Message-ID: 
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=e89a8f23456707d52604be4b063e
Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Apr 2012 21:15:41 -0000

--e89a8f23456707d52604be4b063e
Content-Type: text/plain; charset=UTF-8

This is the last issue that I've flagged as blocking a new Webfinger / SWD
draft.

Mike suggested that being able to request a user's profile with a single
request (i.e., that the /.well-known/ profile resource should be able to
respond with full profile data immediately, rather than pointing at a
second URL that will fulfil the request) is a requirement for this standard.

I'd like to challenge that requirement. The arguments for a direct
discovery endpoint are:

1. Fewer requests against the server, since we save (in the worst-case) 50%
of requests by bypassing the indirect lookup phase.
2. Lower latency for clients (e.g., mobile clients) owing to the reduced
number of lookups.

The arguments for an indirect discovery endpoint are:

1. Trivial and web-standards friendly deployment for domains that won't
host their own webfinger/swd profile servers, but want to enable accounts
on their domains (e.g., statically hosted sites).
2. A loosening of the requirement that URLs at the bare domain must run
dynamic scripts that respond to requests to the /.well-known/ path.

My opinion is that the approach that SWD has proposed for the redirect is
problematic. First, the format is very similar in form to the HTML "meta
refresh" tag that provided HTTP redirect support from within HTML. That
format has been widely deprecated, and in these more enlightened times, we
just use the 3xx response codes with Location headers, instead.

Secondly, the SWD request format means that for smaller sites, often those
with the least resources, will end up serving static content in a way
that's difficult to cache; certainly, more difficult to cache than just
serving static content. This is due to the request parameters present in
all SWD requests; those request parameters will bust caches.

As for the first argument *for* SWD's approach, I'd suggest we look to DNS,
which uses the same indirection approach for NS records, relying on a
(relatively) very small set of root servers to handle the traffic for the
whole internet. Clearly, this approach works, and webfinger/swd servers are
in a much better position to handle this additional traffic. Most of this
traffic will be heavily cached, especially for the largest providers.

In fact, in terms of real deployments, hosting a script at, e.g.,
google.com/.well-known/simple-web-discovery is much harder than hosting a
script at profiles.google.com/profile.json for all sorts of reasons, so
it's my belief that the first argument is a red herring.

The second argument is legitimate, but only if mobile clients will actually
be making requests to diverse webfinger/swd hosts. Instead, I strongly
believe that we'll see the emergence of DNS-like servers that provide both
profile hosting as well as proxy services. For a mobile client, the optimal
approach will be to use SPDY to connect to a single host that performs
webfinger/swd lookups on the mobile client's behalf, eliminating the
latency concerns.

I offer that the two-step lookup can be implemented without conditionals on
the client, whereas the direct-unless-not approach cannot be implemented
that way (see my earlier curl example for proof). It's simpler, and easier
to explain to the (hopefully many) small site owners who we'd like to
implement this technology.

Thoughts? Am I missing something?

b.

--e89a8f23456707d52604be4b063e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This is the last issue that I've flagged as blocking a new Webfinger / =
SWD draft.

Mike suggested that being able to request a u=
ser's profile with a single request (i.e., that the /.well-known/ profi=
le resource should be able to respond with full profile data immediately, r=
ather than pointing at a second URL that will fulfil the request) is a requ=
irement for this standard.





I'd like to challenge that requirement. The argumen=
ts for a direct discovery endpoint are:

1. Fewer r=
equests against the server, since we save (in the worst-case) 50% of reques=
ts by bypassing the indirect lookup phase.




2. Lower latency for clients (e.g., mobile clients) owing to the reduc=
ed number of lookups.

The arguments for an indirec=
t discovery endpoint are:

1. Trivial and web-stand=
ards friendly deployment for domains that won't host their own webfinge=
r/swd profile servers, but want to enable accounts on their domains (e.g., =
statically hosted sites).




2. A loosening of the requirement that URLs at the bare domain must ru=
n dynamic scripts that respond to requests to the /.well-known/ path.
=


My opinion is that the approach that SWD has proposed f=
or the redirect is problematic. First, the format is very similar in form t=
o the HTML "meta refresh" tag that provided HTTP redirect support=
 from within HTML. That format has been widely deprecated, and in these mor=
e enlightened times, we just use the 3xx response codes with Location heade=
rs, instead.





Secondly, the SWD request format means that for smaller=
 sites, often those with the least resources, will end up serving static co=
ntent in a way that's difficult to cache; certainly, more difficult to =
cache than just serving static content. This is due to the request paramete=
rs present in all SWD requests; those request parameters will bust caches.<=
/div>




As for the first argument *for* SWD's approach, I&#=
39;d suggest we look to DNS, which uses the same indirection approach for N=
S records, relying on a (relatively) very small set of root servers to hand=
le the traffic for the whole internet. Clearly, this approach works, and we=
bfinger/swd servers are in a much better position to handle this additional=
 traffic. Most of this traffic will be heavily cached, especially for the l=
argest providers.





In fact, in terms of real deployments, hosting a script=
 at, e.g., google.com/.well-known/simple-web-discovery is much ha=
rder than hosting a script at profiles.google.com/profile.json for all sorts=
 of reasons, so it's my belief that the first argument is a red herring=
.





The second argument is legitimate, but only if mobile c=
lients will actually be making requests to diverse webfinger/swd hosts. Ins=
tead, I strongly believe that we'll see the emergence of DNS-like serve=
rs that provide both profile hosting as well as proxy services. For a mobil=
e client, the optimal approach will be to use SPDY to connect to a single h=
ost that performs webfinger/swd lookups on the mobile client's behalf, =
eliminating the latency concerns.





I offer that the two-step lookup can be implemented wit=
hout conditionals on the client, whereas the direct-unless-not approach can=
not be implemented that way (see my earlier curl example for proof). It'=
;s simpler, and easier to explain to the (hopefully many) small site owners=
 who we'd like to implement this technology.





Thoughts? Am I missing something?

<=
div>b.


--e89a8f23456707d52604be4b063e--

From internet-drafts@ietf.org  Sun Apr 22 19:59: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 AF1D921F8541; Sun, 22 Apr 2012 19:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.456
X-Spam-Level: 
X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOyWKi2NzXJB; Sun, 22 Apr 2012 19:59:35 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5460121F852D; Sun, 22 Apr 2012 19:59:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120423025935.11479.31244.idtracker@ietfa.amsl.com>
Date: Sun, 22 Apr 2012 19:59:35 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-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, 23 Apr 2012 02:59:35 -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 Worki=
ng Group of the IETF.

	Title           : Email Greylisting: An Applicability Statement for SMTP
	Author(s)       : Murray S. Kucherawy
                          D. Crocker
	Filename        : draft-ietf-appsawg-greylisting-08.txt
	Pages           : 16
	Date            : 2012-04-22

   This memo describes the art of email greylisting, the practice of
   providing temporarily degraded service to unknown email clients as an
   anti-abuse mechanism.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-08.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-08.txt


From msk@cloudmark.com  Sun Apr 22 20:01: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 0860821F84E2 for ; Sun, 22 Apr 2012 20:01:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.641
X-Spam-Level: 
X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLSlKtmAqTpE for ; Sun, 22 Apr 2012 20:01:02 -0700 (PDT)
Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDA821F84DF for ; Sun, 22 Apr 2012 20:01:02 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 1F0g1j0010as01C01F0gwn; Sun, 22 Apr 2012 20:00:40 -0700
X-CMAE-Match: 0
X-CMAE-Score: 0.00
X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=K5wg16F4C6MA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=IliP7Et8Da0G0WdeOhkA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Sun, 22 Apr 2012 20:00:40 -0700
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-08.txt
Thread-Index: AQHNIP0mWalu7bLDpUerUC6LqmSrd5anuGdg
Date: Mon, 23 Apr 2012 03:00:39 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280FECA3@exch-mbx901.corp.cloudmark.com>
References: <20120423025935.11479.31244.idtracker@ietfa.amsl.com>
In-Reply-To: <20120423025935.11479.31244.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [67.160.203.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335150040; bh=R5JCHckLezIiMXR+vI3Zgx2i/iWTatg3ZG9lmZQHUMA=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=tNdSzk77yA5KrQLo5c5bZLBS0vkk06Ui0AcIALzjCMg2LwMPneUKhs1M9uSn3cL4e jbmiiMENlJztXwFV1ToNEre7EbzXqSkZN0hu4030/1ifP8ivit8NP5/aKAi7g8Zp/h mUtUjV8rUi+1/mFpsQYpXHrjdWlPZRwQa0HUNZf0=
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-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, 23 Apr 2012 03:01:03 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of internet-drafts@ietf.org
> Sent: Sunday, April 22, 2012 8:00 PM
> To: i-d-announce@ietf.org
> Cc: apps-discuss@ietf.org
> Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-08.txt
>=20
> 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.
>=20
> 	Title           : Email Greylisting: An Applicability Statement for SMTP
> 	Author(s)       : Murray S. Kucherawy
>                           D. Crocker
> 	Filename        : draft-ietf-appsawg-greylisting-08.txt
> 	Pages           : 16
> 	Date            : 2012-04-22
>=20
>    This memo describes the art of email greylisting, the practice of
>    providing temporarily degraded service to unknown email clients as an
>    anti-abuse mechanism.

Includes minor changes resulting from IESG Evaluation.

-MSK

From Michael.Jones@microsoft.com  Sun Apr 22 21: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 3E70E21E8013 for ; Sun, 22 Apr 2012 21:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.918
X-Spam-Level: 
X-Spam-Status: No, score=-3.918 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiPirxasxwac for ; Sun, 22 Apr 2012 21:11:52 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 46E1621F84D9 for ; Sun, 22 Apr 2012 21:11:51 -0700 (PDT)
Received: from mail18-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 23 Apr 2012 04:11:50 +0000
Received: from mail18-am1 (localhost [127.0.0.1])	by mail18-am1-R.bigfish.com (Postfix) with ESMTP id 834E88042B; Mon, 23 Apr 2012 04:11:50 +0000 (UTC)
X-SpamScore: -51
X-BigFish: VS-51(z21aILz9371Ic89bh1803Mc857hc1dMzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail18-am1: 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=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail18-am1 (localhost.localdomain [127.0.0.1]) by mail18-am1 (MessageSwitch) id 1335154308518425_13249; Mon, 23 Apr 2012 04:11:48 +0000 (UTC)
Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.237])	by mail18-am1.bigfish.com (Postfix) with ESMTP id 70D66320090; Mon, 23 Apr 2012 04:11:48 +0000 (UTC)
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 23 Apr 2012 04:11:45 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0283.004; Mon, 23 Apr 2012 04:11:42 +0000
From: Mike Jones 
To: Blaine Cook , "apps-discuss@ietf.org" 
Thread-Topic: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
Thread-Index: Ac0hBxLR2C6/mgSxQ3GyVp8an5prXA==
Date: Mon, 23 Apr 2012 04:11:41 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366492EE5TK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 04:11:53 -0000

--_000_4E1F6AAD24975D4BA5B168042967394366492EE5TK5EX14MBXC284r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBhZ3JlZSB3aXRoIHlvdXIgZ29hbCBvZiBzaW1wbGljaXR5IGZvciBjbGllbnRzLiAgUGF1bOKA
mXMgZXhhbXBsZSBzZWVtcyBhYm91dCBhcyBzaW1wbGUgYXMgaXQgY2FuIGdldCBmb3IgY2xpZW50
czoNCiAgICAgICAgICAgICAgIGN1cmwgLXYgaHR0cHM6Ly9wYWNrZXRpemVyLmNvbS8ud2VsbC1r
bm93bi9ob3N0LW1ldGEuanNvbj9yZXNvdXJjZT1hY2N0OnBhdWxlakBwYWNrZXRpemVyLmNvbQ0K
SXQgc2hhcmVzIHRoZSBwcm9wZXJ0eSB3aXRoIHlvdXIgZWFybGllciBleGFtcGxlIChiZWxvdykg
dGhhdCBjbGllbnRzIGhhdmUgYSBuby1icmFuY2hlcyBjb2RlIHBhdGggdG8gZG8gZGlzY292ZXJ5
Og0KICAgICAgICAgICAgICAgY3VybCAtcyBodHRwOi8vZXhhbXBsZS5jb20vLndlbGwta25vd24v
aG9zdC1tZXRhfA0KICAgICAgICAgICAgICAgYXdrICIvbHJkZC8sL3RlbXBsYXRlLyJ8dHIgLWQg
J1xuJ3xzZWQgLWUgInMvXi4qdGVtcGxhdGU9J1woW14nXSpcKScuKiQvXDEvInwNCiAgICAgICAg
ICAgICAgIHNlZCAtZSAicy97dXJpfS91c2VyQGV4YW1wbGUuY29tLyJ8eGFyZ3MgY3VybCDigJNz
DQoNCkhvd2V2ZXIsIEkgY2hhbGxlbmdlIHRoZSBhc3N1bXB0aW9uIGluIHlvdXIgbm90ZSBiZWxv
dyB0aGF0IHNlcnZlcnMgdXNpbmcgb25seSBzdGF0aWMgcGFnZXMgbXVzdCBiZSBzdXBwb3J0ZWQu
ICBJIGp1c3QgZG9u4oCZdCBzZWUgdGhlIHJlcXVpcmVtZW50IHRvIGltcGxlbWVudCBhIHF1ZXJ5
IHBhcmFtZXRlciBhcyBiZWluZyBhbiBpbXBlZGltZW50IGluIHByYWN0aWNlLCBldmVuIGZvciBo
b3N0ZWQgZG9tYWlucy4gIEkga25vdyBvZiBubyBob3N0aW5nIGNvbXBhbnkgdGhhdCBkb2VzbuKA
mXQgcHJvdmlkZSBhIG1lYW5zIG9mIHB1dHRpbmcgZXhlY3V0YWJsZSBjb2RlIGJlaGluZCB3ZWIg
cGFnZXMsIGJlIGl0IFBIUCwgUGVybCwgUnVieSwgQVNQLCBKU1AsIGV0Yy4gIEkga25vdyB5b3Xi
gJlyZSB0cnlpbmcgdG8gbWFrZSB0aGUgY2FzZSBmb3Igc3RhdGljIHBhZ2VzLCBidXQgaW4gcHJh
Y3RpY2UsIEkgYmVsaWV2ZSB0aGF0IGR5bmFtaWMgcGFnZXMgYXJlIGFsd2F5cyBlYXNpbHkgYXZh
aWxhYmxlLg0KDQpBc3N1bWluZyB0aGF0IHdl4oCZcmUgaW4gYW4gZWl0aGVyLW9yIHNpdHVhdGlv
biB3aXRoIHJlZ2FyZCB0byBlaXRoZXIgaGF2aW5nIHNpbmdsZS1HRVQgZGlzY292ZXJ5IG9yIHN1
cHBvcnRpbmcgZGlzY292ZXJ5IHVzaW5nIG9ubHkgc3RhdGljIHNlcnZlciBwYWdlcyAoYW5kIEni
gJlkIGxvdmUgdG8gaGF2ZSBzb21lb25lIGRlbW9uc3RyYXRlIHRvIHVzIHRoYXQgd2XigJlyZSBu
b3QpLCBJ4oCZZCB0YWtlIHNpbmdsZS1HRVQgZGlzY292ZXJ5IGZvciBzdXJlLCBhcyBpbiBzb21l
IGNhc2VzLCBpdCBtYWtlcyBhbiBhcHByZWNpYWJsZSBkaWZmZXJlbmNlIGluIHVzZXIgaW50ZXJm
YWNlIGxhdGVuY3ksIGFuZCBwZXIgdGhlIHBhcmFncmFwaCBhYm92ZSwgSSBiZWxpZXZlIHRoYXQg
ZHluYW1pYyBxdWVyaWVzIGNhbiBiZSBpbXBsZW1lbnRlZCBvbiBhbGwgaG9zdGluZyBwbGF0Zm9y
bXMuDQoNCkFzc3VtaW5nIHRoZSBXZWJGaW5nZXIgYXV0aG9ycyBhZ3JlZSwgSeKAmWQgc3VnZ2Vz
dCB0aGF0IGEgbG9naWNhbCBuZXh0IHN0ZXAgd291bGQgYmUgZm9yIGEgLTA0IHZlcnNpb24gb2Yg
ZHJhZnQtam9uZXMtYXBwc2F3Zy13ZWJmaW5nZXIgdG8gYmUgcHVibGlzaGVkIHRoYXQgY2hhbmdl
cyBzdXBwb3J0IGZvciB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIGZyb20gUkVDT01NRU5ERUQgdG8g
UkVRVUlSRUQsIGFzIHRoYXQgY291bGQgcHJvdmlkZSBhIHN0YXJ0aW5nIHBvaW50IGZvciBhIGNv
bW1vbiBkaXNjb3Zlcnkgc3BlYy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpQLlMuICBBcyBsb25nIGFzIGRy
YWZ0LWpvbmVzLWFwcHNhd2ctd2ViZmluZ2VyIGlzIGJlaW5nIHJldmlzZWQsIEnigJlkIGFsc28g
c3VnZ2VzdCBhZGRpbmcgdGV4dCBtYWtpbmcgZXhwbGljaXQgd2hhdCBoYXMgYmVlbiBhbiBpbXBs
aWNpdCBhc3N1bXB0aW9uIGluIGJvdGggV2ViRmluZ2VyIGFuZCBTV0QgLSB0aGF0IGRlcGVuZGlu
ZyB1cG9uIHdoZXRoZXIgYW5kIGhvdyB0aGUgY2xpZW50IGlzIGF1dGhlbnRpY2F0ZWQsIHRoZSBz
ZXQgb2YgcmVzb3VyY2VzIHJldHVybmVkIG1heSB2YXJ5IChhcyBCbGFpbmUgaGFkIHBvaW50ZWQg
b3V0IGVhcmxpZXIpLiAgVGhhdCBjb3VsZCBoZWxwIGRlYWwgd2l0aCBzb21lIG9mIHRoZSBwcml2
YWN5IHBlcmNlcHRpb25zLg0KDQpGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyBb
bWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmxhaW5l
IENvb2sNClNlbnQ6IFN1bmRheSwgQXByaWwgMjIsIDIwMTIgMjoxNSBQTQ0KVG86IGFwcHMtZGlz
Y3Vzc0BpZXRmLm9yZw0KU3ViamVjdDogW2FwcHMtZGlzY3Vzc10gV2ViZmluZ2VyIC8gU1dEIElz
c3VlICMzOiBkaXJlY3QgdmVyc3VzIGluZGlyZWN0IGRpc2NvdmVyeQ0KDQpUaGlzIGlzIHRoZSBs
YXN0IGlzc3VlIHRoYXQgSSd2ZSBmbGFnZ2VkIGFzIGJsb2NraW5nIGEgbmV3IFdlYmZpbmdlciAv
IFNXRCBkcmFmdC4NCg0KTWlrZSBzdWdnZXN0ZWQgdGhhdCBiZWluZyBhYmxlIHRvIHJlcXVlc3Qg
YSB1c2VyJ3MgcHJvZmlsZSB3aXRoIGEgc2luZ2xlIHJlcXVlc3QgKGkuZS4sIHRoYXQgdGhlIC8u
d2VsbC1rbm93bi8gcHJvZmlsZSByZXNvdXJjZSBzaG91bGQgYmUgYWJsZSB0byByZXNwb25kIHdp
dGggZnVsbCBwcm9maWxlIGRhdGEgaW1tZWRpYXRlbHksIHJhdGhlciB0aGFuIHBvaW50aW5nIGF0
IGEgc2Vjb25kIFVSTCB0aGF0IHdpbGwgZnVsZmlsIHRoZSByZXF1ZXN0KSBpcyBhIHJlcXVpcmVt
ZW50IGZvciB0aGlzIHN0YW5kYXJkLg0KDQpJJ2QgbGlrZSB0byBjaGFsbGVuZ2UgdGhhdCByZXF1
aXJlbWVudC4gVGhlIGFyZ3VtZW50cyBmb3IgYSBkaXJlY3QgZGlzY292ZXJ5IGVuZHBvaW50IGFy
ZToNCg0KMS4gRmV3ZXIgcmVxdWVzdHMgYWdhaW5zdCB0aGUgc2VydmVyLCBzaW5jZSB3ZSBzYXZl
IChpbiB0aGUgd29yc3QtY2FzZSkgNTAlIG9mIHJlcXVlc3RzIGJ5IGJ5cGFzc2luZyB0aGUgaW5k
aXJlY3QgbG9va3VwIHBoYXNlLg0KMi4gTG93ZXIgbGF0ZW5jeSBmb3IgY2xpZW50cyAoZS5nLiwg
bW9iaWxlIGNsaWVudHMpIG93aW5nIHRvIHRoZSByZWR1Y2VkIG51bWJlciBvZiBsb29rdXBzLg0K
DQpUaGUgYXJndW1lbnRzIGZvciBhbiBpbmRpcmVjdCBkaXNjb3ZlcnkgZW5kcG9pbnQgYXJlOg0K
DQoxLiBUcml2aWFsIGFuZCB3ZWItc3RhbmRhcmRzIGZyaWVuZGx5IGRlcGxveW1lbnQgZm9yIGRv
bWFpbnMgdGhhdCB3b24ndCBob3N0IHRoZWlyIG93biB3ZWJmaW5nZXIvc3dkIHByb2ZpbGUgc2Vy
dmVycywgYnV0IHdhbnQgdG8gZW5hYmxlIGFjY291bnRzIG9uIHRoZWlyIGRvbWFpbnMgKGUuZy4s
IHN0YXRpY2FsbHkgaG9zdGVkIHNpdGVzKS4NCjIuIEEgbG9vc2VuaW5nIG9mIHRoZSByZXF1aXJl
bWVudCB0aGF0IFVSTHMgYXQgdGhlIGJhcmUgZG9tYWluIG11c3QgcnVuIGR5bmFtaWMgc2NyaXB0
cyB0aGF0IHJlc3BvbmQgdG8gcmVxdWVzdHMgdG8gdGhlIC8ud2VsbC1rbm93bi8gcGF0aC4NCg0K
TXkgb3BpbmlvbiBpcyB0aGF0IHRoZSBhcHByb2FjaCB0aGF0IFNXRCBoYXMgcHJvcG9zZWQgZm9y
IHRoZSByZWRpcmVjdCBpcyBwcm9ibGVtYXRpYy4gRmlyc3QsIHRoZSBmb3JtYXQgaXMgdmVyeSBz
aW1pbGFyIGluIGZvcm0gdG8gdGhlIEhUTUwgIm1ldGEgcmVmcmVzaCIgdGFnIHRoYXQgcHJvdmlk
ZWQgSFRUUCByZWRpcmVjdCBzdXBwb3J0IGZyb20gd2l0aGluIEhUTUwuIFRoYXQgZm9ybWF0IGhh
cyBiZWVuIHdpZGVseSBkZXByZWNhdGVkLCBhbmQgaW4gdGhlc2UgbW9yZSBlbmxpZ2h0ZW5lZCB0
aW1lcywgd2UganVzdCB1c2UgdGhlIDN4eCByZXNwb25zZSBjb2RlcyB3aXRoIExvY2F0aW9uIGhl
YWRlcnMsIGluc3RlYWQuDQoNClNlY29uZGx5LCB0aGUgU1dEIHJlcXVlc3QgZm9ybWF0IG1lYW5z
IHRoYXQgZm9yIHNtYWxsZXIgc2l0ZXMsIG9mdGVuIHRob3NlIHdpdGggdGhlIGxlYXN0IHJlc291
cmNlcywgd2lsbCBlbmQgdXAgc2VydmluZyBzdGF0aWMgY29udGVudCBpbiBhIHdheSB0aGF0J3Mg
ZGlmZmljdWx0IHRvIGNhY2hlOyBjZXJ0YWlubHksIG1vcmUgZGlmZmljdWx0IHRvIGNhY2hlIHRo
YW4ganVzdCBzZXJ2aW5nIHN0YXRpYyBjb250ZW50LiBUaGlzIGlzIGR1ZSB0byB0aGUgcmVxdWVz
dCBwYXJhbWV0ZXJzIHByZXNlbnQgaW4gYWxsIFNXRCByZXF1ZXN0czsgdGhvc2UgcmVxdWVzdCBw
YXJhbWV0ZXJzIHdpbGwgYnVzdCBjYWNoZXMuDQoNCkFzIGZvciB0aGUgZmlyc3QgYXJndW1lbnQg
KmZvciogU1dEJ3MgYXBwcm9hY2gsIEknZCBzdWdnZXN0IHdlIGxvb2sgdG8gRE5TLCB3aGljaCB1
c2VzIHRoZSBzYW1lIGluZGlyZWN0aW9uIGFwcHJvYWNoIGZvciBOUyByZWNvcmRzLCByZWx5aW5n
IG9uIGEgKHJlbGF0aXZlbHkpIHZlcnkgc21hbGwgc2V0IG9mIHJvb3Qgc2VydmVycyB0byBoYW5k
bGUgdGhlIHRyYWZmaWMgZm9yIHRoZSB3aG9sZSBpbnRlcm5ldC4gQ2xlYXJseSwgdGhpcyBhcHBy
b2FjaCB3b3JrcywgYW5kIHdlYmZpbmdlci9zd2Qgc2VydmVycyBhcmUgaW4gYSBtdWNoIGJldHRl
ciBwb3NpdGlvbiB0byBoYW5kbGUgdGhpcyBhZGRpdGlvbmFsIHRyYWZmaWMuIE1vc3Qgb2YgdGhp
cyB0cmFmZmljIHdpbGwgYmUgaGVhdmlseSBjYWNoZWQsIGVzcGVjaWFsbHkgZm9yIHRoZSBsYXJn
ZXN0IHByb3ZpZGVycy4NCg0KSW4gZmFjdCwgaW4gdGVybXMgb2YgcmVhbCBkZXBsb3ltZW50cywg
aG9zdGluZyBhIHNjcmlwdCBhdCwgZS5nLiwgZ29vZ2xlLmNvbS8ud2VsbC1rbm93bi9zaW1wbGUt
d2ViLWRpc2NvdmVyeTxodHRwOi8vZ29vZ2xlLmNvbS8ud2VsbC1rbm93bi9zaW1wbGUtd2ViLWRp
c2NvdmVyeT4gaXMgbXVjaCBoYXJkZXIgdGhhbiBob3N0aW5nIGEgc2NyaXB0IGF0IHByb2ZpbGVz
Lmdvb2dsZS5jb20vcHJvZmlsZS5qc29uPGh0dHA6Ly9wcm9maWxlcy5nb29nbGUuY29tL3Byb2Zp
bGUuanNvbj4gZm9yIGFsbCBzb3J0cyBvZiByZWFzb25zLCBzbyBpdCdzIG15IGJlbGllZiB0aGF0
IHRoZSBmaXJzdCBhcmd1bWVudCBpcyBhIHJlZCBoZXJyaW5nLg0KDQpUaGUgc2Vjb25kIGFyZ3Vt
ZW50IGlzIGxlZ2l0aW1hdGUsIGJ1dCBvbmx5IGlmIG1vYmlsZSBjbGllbnRzIHdpbGwgYWN0dWFs
bHkgYmUgbWFraW5nIHJlcXVlc3RzIHRvIGRpdmVyc2Ugd2ViZmluZ2VyL3N3ZCBob3N0cy4gSW5z
dGVhZCwgSSBzdHJvbmdseSBiZWxpZXZlIHRoYXQgd2UnbGwgc2VlIHRoZSBlbWVyZ2VuY2Ugb2Yg
RE5TLWxpa2Ugc2VydmVycyB0aGF0IHByb3ZpZGUgYm90aCBwcm9maWxlIGhvc3RpbmcgYXMgd2Vs
bCBhcyBwcm94eSBzZXJ2aWNlcy4gRm9yIGEgbW9iaWxlIGNsaWVudCwgdGhlIG9wdGltYWwgYXBw
cm9hY2ggd2lsbCBiZSB0byB1c2UgU1BEWSB0byBjb25uZWN0IHRvIGEgc2luZ2xlIGhvc3QgdGhh
dCBwZXJmb3JtcyB3ZWJmaW5nZXIvc3dkIGxvb2t1cHMgb24gdGhlIG1vYmlsZSBjbGllbnQncyBi
ZWhhbGYsIGVsaW1pbmF0aW5nIHRoZSBsYXRlbmN5IGNvbmNlcm5zLg0KDQpJIG9mZmVyIHRoYXQg
dGhlIHR3by1zdGVwIGxvb2t1cCBjYW4gYmUgaW1wbGVtZW50ZWQgd2l0aG91dCBjb25kaXRpb25h
bHMgb24gdGhlIGNsaWVudCwgd2hlcmVhcyB0aGUgZGlyZWN0LXVubGVzcy1ub3QgYXBwcm9hY2gg
Y2Fubm90IGJlIGltcGxlbWVudGVkIHRoYXQgd2F5IChzZWUgbXkgZWFybGllciBjdXJsIGV4YW1w
bGUgZm9yIHByb29mKS4gSXQncyBzaW1wbGVyLCBhbmQgZWFzaWVyIHRvIGV4cGxhaW4gdG8gdGhl
IChob3BlZnVsbHkgbWFueSkgc21hbGwgc2l0ZSBvd25lcnMgd2hvIHdlJ2QgbGlrZSB0byBpbXBs
ZW1lbnQgdGhpcyB0ZWNobm9sb2d5Lg0KDQpUaG91Z2h0cz8gQW0gSSBtaXNzaW5nIHNvbWV0aGlu
Zz8NCg0KYi4NCg==

--_000_4E1F6AAD24975D4BA5B168042967394366492EE5TK5EX14MBXC284r_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp
bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K
CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s
PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl
eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs
YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu
az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkkgYWdyZWUgd2l0aCB5b3VyIGdvYWwgb2Ygc2ltcGxpY2l0eSBmb3IgY2xpZW50cy4mbmJz
cDsgUGF1bOKAmXMgZXhhbXBsZSBzZWVtcyBhYm91dCBhcyBzaW1wbGUgYXMgaXQgY2FuIGdldCBm
b3IgY2xpZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IGN1cmwgLXYNCjxhIGhyZWY9Imh0dHBzOi8vcGFja2V0aXplci5jb20vLndl
bGwta25vd24vaG9zdC1tZXRhLmpzb24/cmVzb3VyY2U9YWNjdDpwYXVsZWpAcGFja2V0aXplci5j
b20iPg0KaHR0cHM6Ly9wYWNrZXRpemVyLmNvbS8ud2VsbC1rbm93bi9ob3N0LW1ldGEuanNvbj9y
ZXNvdXJjZT1hY2N0OnBhdWxlakBwYWNrZXRpemVyLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+SXQgc2hhcmVzIHRoZSBwcm9wZXJ0eSB3aXRoIHlvdXIgZWFybGllciBleGFt
cGxlIChiZWxvdykgdGhhdCBjbGllbnRzIGhhdmUgYSBuby1icmFuY2hlcyBjb2RlIHBhdGggdG8g
ZG8gZGlzY292ZXJ5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgY3VybCAtcw0KPGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tLy53ZWxs
LWtub3duL2hvc3QtbWV0YXwiPmh0dHA6Ly9leGFtcGxlLmNvbS8ud2VsbC1rbm93bi9ob3N0LW1l
dGF8PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgYXdrICZxdW90Oy9scmRkLywvdGVtcGxhdGUvJnF1b3Q7fHRyIC1kICdcbid8c2Vk
IC1lICZxdW90O3MvXi4qdGVtcGxhdGU9J1woW14nXSpcKScuKiQvXDEvJnF1b3Q7fDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VkIC1l
ICZxdW90O3Mve3VyaX0vdXNlckBleGFtcGxlLmNvbS8mcXVvdDt8eGFyZ3MgY3VybCDigJNzPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5Ib3dldmVyLCBJIGNoYWxsZW5nZSB0aGUgYXNzdW1wdGlvbiBpbiB5b3VyIG5vdGUg
YmVsb3cgdGhhdCBzZXJ2ZXJzIHVzaW5nIG9ubHkgc3RhdGljIHBhZ2VzIG11c3QgYmUgc3VwcG9y
dGVkLiZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5JIGp1c3QgZG9u4oCZdCBzZWUgdGhlIHJlcXVpcmVtZW50IHRvIGltcGxlbWVudCBhIHF1
ZXJ5IHBhcmFtZXRlciBhcyBiZWluZyBhbiBpbXBlZGltZW50IGluIHByYWN0aWNlLCBldmVuIGZv
ciBob3N0ZWQgZG9tYWlucy4mbmJzcDsgSSBrbm93IG9mIG5vIGhvc3RpbmcgY29tcGFueSB0aGF0
IGRvZXNu4oCZdCBwcm92aWRlDQogYSBtZWFucyBvZiBwdXR0aW5nIGV4ZWN1dGFibGUgY29kZSBi
ZWhpbmQgd2ViIHBhZ2VzLCBiZSBpdCBQSFAsIFBlcmwsIFJ1YnksIEFTUCwgSlNQLCBldGMuJm5i
c3A7IEkga25vdyB5b3XigJlyZSB0cnlpbmcgdG8gbWFrZSB0aGUgY2FzZSBmb3Igc3RhdGljIHBh
Z2VzLCBidXQgaW4gcHJhY3RpY2UsIEkgYmVsaWV2ZSB0aGF0IGR5bmFtaWMgcGFnZXMgYXJlIGFs
d2F5cyBlYXNpbHkgYXZhaWxhYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXNzdW1pbmcgdGhhdCB3ZeKAmXJlIGlu
IGFuIGVpdGhlci1vciBzaXR1YXRpb24gd2l0aCByZWdhcmQgdG8gZWl0aGVyIGhhdmluZyBzaW5n
bGUtR0VUIGRpc2NvdmVyeSBvciBzdXBwb3J0aW5nIGRpc2NvdmVyeSB1c2luZyBvbmx5IHN0YXRp
YyBzZXJ2ZXIgcGFnZXMgKGFuZA0KIEnigJlkIGxvdmUgdG8gaGF2ZSBzb21lb25lIGRlbW9uc3Ry
YXRlIHRvIHVzIHRoYXQgd2XigJlyZSBub3QpLCBJ4oCZZCB0YWtlIHNpbmdsZS1HRVQgZGlzY292
ZXJ5IGZvciBzdXJlLCBhcyBpbiBzb21lIGNhc2VzLCBpdCBtYWtlcyBhbiBhcHByZWNpYWJsZSBk
aWZmZXJlbmNlIGluIHVzZXIgaW50ZXJmYWNlIGxhdGVuY3ksIGFuZCBwZXIgdGhlIHBhcmFncmFw
aCBhYm92ZSwgSSBiZWxpZXZlIHRoYXQgZHluYW1pYyBxdWVyaWVzIGNhbiBiZSBpbXBsZW1lbnRl
ZA0KIG9uIGFsbCBob3N0aW5nIHBsYXRmb3Jtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzc3VtaW5nIHRoZSBXZWJG
aW5nZXIgYXV0aG9ycyBhZ3JlZSwgSeKAmWQgc3VnZ2VzdCB0aGF0IGEgbG9naWNhbCBuZXh0IHN0
ZXAgd291bGQgYmUgZm9yIGEgLTA0IHZlcnNpb24gb2YgZHJhZnQtam9uZXMtYXBwc2F3Zy13ZWJm
aW5nZXIgdG8gYmUgcHVibGlzaGVkIHRoYXQNCiBjaGFuZ2VzIHN1cHBvcnQgZm9yIHRoZSByZXNv
dXJjZSBwYXJhbWV0ZXIgZnJvbSBSRUNPTU1FTkRFRCB0byBSRVFVSVJFRCwgYXMgdGhhdCBjb3Vs
ZCBwcm92aWRlIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGEgY29tbW9uIGRpc2NvdmVyeSBzcGVjLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UC5TLiZuYnNwOyBBcyBs
b25nIGFzIGRyYWZ0LWpvbmVzLWFwcHNhd2ctd2ViZmluZ2VyIGlzIGJlaW5nIHJldmlzZWQsIEni
gJlkIGFsc28gc3VnZ2VzdCBhZGRpbmcgdGV4dCBtYWtpbmcgZXhwbGljaXQgd2hhdCBoYXMgYmVl
biBhbiBpbXBsaWNpdCBhc3N1bXB0aW9uIGluIGJvdGggV2ViRmluZ2VyDQogYW5kIFNXRCAtIHRo
YXQgZGVwZW5kaW5nIHVwb24gd2hldGhlciBhbmQgaG93IHRoZSBjbGllbnQgaXMgYXV0aGVudGlj
YXRlZCwgdGhlIHNldCBvZiByZXNvdXJjZXMgcmV0dXJuZWQgbWF5IHZhcnkgKGFzIEJsYWluZSBo
YWQgcG9pbnRlZCBvdXQgZWFybGllcikuJm5ic3A7IFRoYXQgY291bGQgaGVscCBkZWFsIHdpdGgg
c29tZSBvZiB0aGUgcHJpdmFjeSBwZXJjZXB0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86
YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJsYWlu
ZSBDb29rPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgQXByaWwgMjIsIDIwMTIgMjoxNSBQTTxi
cj4NCjxiPlRvOjwvYj4gYXBwcy1kaXNjdXNzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+
IFthcHBzLWRpc2N1c3NdIFdlYmZpbmdlciAvIFNXRCBJc3N1ZSAjMzogZGlyZWN0IHZlcnN1cyBp
bmRpcmVjdCBkaXNjb3Zlcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMg
dGhlIGxhc3QgaXNzdWUgdGhhdCBJJ3ZlIGZsYWdnZWQgYXMgYmxvY2tpbmcgYSBuZXcgV2ViZmlu
Z2VyIC8gU1dEIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+TWlrZSBzdWdnZXN0ZWQgdGhhdCBiZWluZyBhYmxlIHRvIHJlcXVlc3QgYSB1c2VyJ3Mg
cHJvZmlsZSB3aXRoIGEgc2luZ2xlIHJlcXVlc3QgKGkuZS4sIHRoYXQgdGhlIC8ud2VsbC1rbm93
bi8gcHJvZmlsZSByZXNvdXJjZSBzaG91bGQgYmUgYWJsZSB0byByZXNwb25kIHdpdGggZnVsbCBw
cm9maWxlIGRhdGEgaW1tZWRpYXRlbHksIHJhdGhlciB0aGFuIHBvaW50aW5nIGF0IGEgc2Vjb25k
IFVSTCB0aGF0IHdpbGwNCiBmdWxmaWwgdGhlIHJlcXVlc3QpIGlzIGEgcmVxdWlyZW1lbnQgZm9y
IHRoaXMgc3RhbmRhcmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkknZCBsaWtlIHRvIGNoYWxsZW5nZSB0aGF0IHJlcXVpcmVtZW50LiBUaGUg
YXJndW1lbnRzIGZvciBhIGRpcmVjdCBkaXNjb3ZlcnkgZW5kcG9pbnQgYXJlOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBGZXdlciByZXF1
ZXN0cyBhZ2FpbnN0IHRoZSBzZXJ2ZXIsIHNpbmNlIHdlIHNhdmUgKGluIHRoZSB3b3JzdC1jYXNl
KSA1MCUgb2YgcmVxdWVzdHMgYnkgYnlwYXNzaW5nIHRoZSBpbmRpcmVjdCBsb29rdXAgcGhhc2Uu
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBM
b3dlciBsYXRlbmN5IGZvciBjbGllbnRzIChlLmcuLCBtb2JpbGUgY2xpZW50cykgb3dpbmcgdG8g
dGhlIHJlZHVjZWQgbnVtYmVyIG9mIGxvb2t1cHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBhcmd1bWVudHMgZm9yIGFuIGluZGlyZWN0
IGRpc2NvdmVyeSBlbmRwb2ludCBhcmU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuIFRyaXZpYWwgYW5kIHdlYi1zdGFuZGFyZHMgZnJpZW5k
bHkgZGVwbG95bWVudCBmb3IgZG9tYWlucyB0aGF0IHdvbid0IGhvc3QgdGhlaXIgb3duIHdlYmZp
bmdlci9zd2QgcHJvZmlsZSBzZXJ2ZXJzLCBidXQgd2FudCB0byBlbmFibGUgYWNjb3VudHMgb24g
dGhlaXIgZG9tYWlucyAoZS5nLiwgc3RhdGljYWxseSBob3N0ZWQgc2l0ZXMpLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gQSBsb29zZW5pbmcg
b2YgdGhlIHJlcXVpcmVtZW50IHRoYXQgVVJMcyBhdCB0aGUgYmFyZSBkb21haW4gbXVzdCBydW4g
ZHluYW1pYyBzY3JpcHRzIHRoYXQgcmVzcG9uZCB0byByZXF1ZXN0cyB0byB0aGUgLy53ZWxsLWtu
b3duLyBwYXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5NeSBvcGluaW9uIGlzIHRoYXQgdGhlIGFwcHJvYWNoIHRoYXQgU1dEIGhhcyBwcm9w
b3NlZCBmb3IgdGhlIHJlZGlyZWN0IGlzIHByb2JsZW1hdGljLiBGaXJzdCwgdGhlIGZvcm1hdCBp
cyB2ZXJ5IHNpbWlsYXIgaW4gZm9ybSB0byB0aGUgSFRNTCAmcXVvdDttZXRhIHJlZnJlc2gmcXVv
dDsgdGFnIHRoYXQgcHJvdmlkZWQgSFRUUCByZWRpcmVjdCBzdXBwb3J0IGZyb20gd2l0aGluIEhU
TUwuIFRoYXQgZm9ybWF0IGhhcyBiZWVuIHdpZGVseQ0KIGRlcHJlY2F0ZWQsIGFuZCBpbiB0aGVz
ZSBtb3JlIGVubGlnaHRlbmVkIHRpbWVzLCB3ZSBqdXN0IHVzZSB0aGUgM3h4IHJlc3BvbnNlIGNv
ZGVzIHdpdGggTG9jYXRpb24gaGVhZGVycywgaW5zdGVhZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2Vjb25kbHksIHRoZSBTV0QgcmVxdWVz
dCBmb3JtYXQgbWVhbnMgdGhhdCBmb3Igc21hbGxlciBzaXRlcywgb2Z0ZW4gdGhvc2Ugd2l0aCB0
aGUgbGVhc3QgcmVzb3VyY2VzLCB3aWxsIGVuZCB1cCBzZXJ2aW5nIHN0YXRpYyBjb250ZW50IGlu
IGEgd2F5IHRoYXQncyBkaWZmaWN1bHQgdG8gY2FjaGU7IGNlcnRhaW5seSwgbW9yZSBkaWZmaWN1
bHQgdG8gY2FjaGUgdGhhbiBqdXN0IHNlcnZpbmcgc3RhdGljIGNvbnRlbnQuDQogVGhpcyBpcyBk
dWUgdG8gdGhlIHJlcXVlc3QgcGFyYW1ldGVycyBwcmVzZW50IGluIGFsbCBTV0QgcmVxdWVzdHM7
IHRob3NlIHJlcXVlc3QgcGFyYW1ldGVycyB3aWxsIGJ1c3QgY2FjaGVzLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBmb3IgdGhlIGZpcnN0
IGFyZ3VtZW50ICpmb3IqIFNXRCdzIGFwcHJvYWNoLCBJJ2Qgc3VnZ2VzdCB3ZSBsb29rIHRvIERO
Uywgd2hpY2ggdXNlcyB0aGUgc2FtZSBpbmRpcmVjdGlvbiBhcHByb2FjaCBmb3IgTlMgcmVjb3Jk
cywgcmVseWluZyBvbiBhIChyZWxhdGl2ZWx5KSB2ZXJ5IHNtYWxsIHNldCBvZiByb290IHNlcnZl
cnMgdG8gaGFuZGxlIHRoZSB0cmFmZmljIGZvciB0aGUgd2hvbGUgaW50ZXJuZXQuDQogQ2xlYXJs
eSwgdGhpcyBhcHByb2FjaCB3b3JrcywgYW5kIHdlYmZpbmdlci9zd2Qgc2VydmVycyBhcmUgaW4g
YSBtdWNoIGJldHRlciBwb3NpdGlvbiB0byBoYW5kbGUgdGhpcyBhZGRpdGlvbmFsIHRyYWZmaWMu
IE1vc3Qgb2YgdGhpcyB0cmFmZmljIHdpbGwgYmUgaGVhdmlseSBjYWNoZWQsIGVzcGVjaWFsbHkg
Zm9yIHRoZSBsYXJnZXN0IHByb3ZpZGVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gZmFjdCwgaW4gdGVybXMgb2YgcmVhbCBkZXBsb3lt
ZW50cywgaG9zdGluZyBhIHNjcmlwdCBhdCwgZS5nLiwNCjxhIGhyZWY9Imh0dHA6Ly9nb29nbGUu
Y29tLy53ZWxsLWtub3duL3NpbXBsZS13ZWItZGlzY292ZXJ5IiB0YXJnZXQ9Il9ibGFuayI+Z29v
Z2xlLmNvbS8ud2VsbC1rbm93bi9zaW1wbGUtd2ViLWRpc2NvdmVyeTwvYT4gaXMgbXVjaCBoYXJk
ZXIgdGhhbiBob3N0aW5nIGEgc2NyaXB0IGF0DQo8YSBocmVmPSJodHRwOi8vcHJvZmlsZXMuZ29v
Z2xlLmNvbS9wcm9maWxlLmpzb24iIHRhcmdldD0iX2JsYW5rIj5wcm9maWxlcy5nb29nbGUuY29t
L3Byb2ZpbGUuanNvbjwvYT4gZm9yIGFsbCBzb3J0cyBvZiByZWFzb25zLCBzbyBpdCdzIG15IGJl
bGllZiB0aGF0IHRoZSBmaXJzdCBhcmd1bWVudCBpcyBhIHJlZCBoZXJyaW5nLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc2Vjb25kIGFy
Z3VtZW50IGlzIGxlZ2l0aW1hdGUsIGJ1dCBvbmx5IGlmIG1vYmlsZSBjbGllbnRzIHdpbGwgYWN0
dWFsbHkgYmUgbWFraW5nIHJlcXVlc3RzIHRvIGRpdmVyc2Ugd2ViZmluZ2VyL3N3ZCBob3N0cy4g
SW5zdGVhZCwgSSBzdHJvbmdseSBiZWxpZXZlIHRoYXQgd2UnbGwgc2VlIHRoZSBlbWVyZ2VuY2Ug
b2YgRE5TLWxpa2Ugc2VydmVycyB0aGF0IHByb3ZpZGUgYm90aCBwcm9maWxlIGhvc3RpbmcNCiBh
cyB3ZWxsIGFzIHByb3h5IHNlcnZpY2VzLiBGb3IgYSBtb2JpbGUgY2xpZW50LCB0aGUgb3B0aW1h
bCBhcHByb2FjaCB3aWxsIGJlIHRvIHVzZSBTUERZIHRvIGNvbm5lY3QgdG8gYSBzaW5nbGUgaG9z
dCB0aGF0IHBlcmZvcm1zIHdlYmZpbmdlci9zd2QgbG9va3VwcyBvbiB0aGUgbW9iaWxlIGNsaWVu
dCdzIGJlaGFsZiwgZWxpbWluYXRpbmcgdGhlIGxhdGVuY3kgY29uY2VybnMuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgb2ZmZXIgdGhhdCB0
aGUgdHdvLXN0ZXAgbG9va3VwIGNhbiBiZSBpbXBsZW1lbnRlZCB3aXRob3V0IGNvbmRpdGlvbmFs
cyBvbiB0aGUgY2xpZW50LCB3aGVyZWFzIHRoZSBkaXJlY3QtdW5sZXNzLW5vdCBhcHByb2FjaCBj
YW5ub3QgYmUgaW1wbGVtZW50ZWQgdGhhdCB3YXkgKHNlZSBteSBlYXJsaWVyIGN1cmwgZXhhbXBs
ZSBmb3IgcHJvb2YpLiBJdCdzIHNpbXBsZXIsIGFuZCBlYXNpZXIgdG8gZXhwbGFpbiB0bw0KIHRo
ZSAoaG9wZWZ1bGx5IG1hbnkpIHNtYWxsIHNpdGUgb3duZXJzIHdobyB3ZSdkIGxpa2UgdG8gaW1w
bGVtZW50IHRoaXMgdGVjaG5vbG9neS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvdWdodHM/IEFtIEkgbWlzc2luZyBzb21ldGhpbmc/PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmIuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_4E1F6AAD24975D4BA5B168042967394366492EE5TK5EX14MBXC284r_--

From msk@cloudmark.com  Sun Apr 22 22:40: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 9416D21F8559 for ; Sun, 22 Apr 2012 22:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.415
X-Spam-Level: 
X-Spam-Status: No, score=-101.415 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_BELOW=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dG+MdiUahAgb for ; Sun, 22 Apr 2012 22:40:10 -0700 (PDT)
Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5A78921F8552 for ; Sun, 22 Apr 2012 22:40:10 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 1Hg91j0010ZaKgw01Hg9bL; Sun, 22 Apr 2012 22:40:09 -0700
X-CMAE-Match: 0
X-CMAE-Score: 0.00
X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ePc26DvMG94A:10 a=vw5VcccR_g0A:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=1Sm0OzTQm6NuZiD6JywA:9 a=fw4e2_QzWMPskRVf5VAA:7 a=CjuIK1q_8ugA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=1pRwPKKZSpJ0N9xb7YQA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=LdFkGDrDWH2mcjCZERnC4w==:117
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Sun, 22 Apr 2012 22:40:09 -0700
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" , "ima@ietf.org" 
Thread-Topic: AppsDir review of draft-ietf-eai-rfc5721bis
Thread-Index: Ac0hE4tEkHnbRv/ZRPWrgYoADgR2Mw==
Date: Mon, 23 Apr 2012 05:40:08 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280FEE4E@exch-mbx901.corp.cloudmark.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.22.1.153]
Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280FEE4Eexchmbx901corpclo_"
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335159609; bh=U+MzK5P5KEiajicxFQJzpnYlbPy/QCKgZ31Aee5nos8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=UXDWR77g9CQpql4AOKt3keShWKf3g/hbfVqBMqnIBA87UzcLu0uyQ09gJE3Hl5KId bhO8Vab1GauoGn/HrXkigbjPP2qzvFEehYgcb/9MfIpUv09bnSUZ5bhKpZWuSyIj8E 29u8LPc+vTV6EyeJkxGgTyEPEBfzgbkJfgAw1DHw=
Subject: [apps-discuss] AppsDir review of draft-ietf-eai-rfc5721bis
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 05:40:12 -0000

--_000_9452079D1A51524AA5749AD23E0039280FEE4Eexchmbx901corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

[NOTE: This is an early review request received by AppsDir.  We typically r=
eview documents that are in IETF Last Call, so please ignore the boilerplat=
e saying so.]

Please resolve these comments along with any other Last Call comments you m=
ay receive.  Please wait for direction from your document shepherd or AD be=
fore posting a new version of the draft.

Document: draft-ietf-eai-rfc5721bis-04
Title: POP3 Support for UTF-8
Reviewer: Murray S. Kucherawy
Review Date: April 22, 2012
IETF Last Call Date: n/a
IESG Telechat Date: n/a

Summary:
LANG fr
Ce document est presque pret a etre publie en tant qu'un RFC, mais il a que=
lques questions qui devraient etre resolues avant de la publication.
LANG en

Major Issues:

None.

Minor Issues:

1) Section 2: When LANG is issued with no parameters, thus requesting a lis=
t of supported languages, is that list expected to be ordered in any way?
It doesn't really matter, but the document should probably say one way or t=
he other.  If a list order is specified by one of the referenced RFCs, I mi=
ssed it.

2) Section 3.1: "The UTF8 command MAY fail."  This seems to be dangling. Ca=
n you say why, even if it's "for any operational reason" or something that
just sounds less random?

3) It seems to me the second and fifth paragraphs of Section 3.1 could be m=
erged, though that might make the fifth one even larger than it is.  It's
possible the second could simply be dropped in favour of the fifth as the f=
ormer seems to be a subset of the latter.  The authors might also want to
consider splitting the fifth one someplace, perhaps where it starts talking=
 about sizes.

4) Section 5 refers to the "UTF-8" Response Code, when it's actually "UTF8"=
.  This is a bit confusing.

5) Section 3.2: The USER argument to the UTF8 capability tells the client s=
omething about the USER, PASS and APOP commands.  As all of those are
basically authentication/credential commands, perhaps something less specif=
ic like "LOGIN", "AUTH" or "CRED" would be more appropriate?  Otherwise it =
looks more like it only applies to the USER command.

6) This document uses RFC2119 language.  In the Introduction, it says "emai=
l messages may be transmitted".  Suggest s/may/might/ or s/may/could/.

7) Similarly, there's a lot of use of non-caps "may" in Section 3.1.

8) Section 5, last paragraph: s/downconvert/down-convert/, and (alas) rathe=
r than talking about "mood", say something about having the resources to do=
wn-convert where it didn't before or something like that.

Nits:

1) The end of the second paragraph of the introduction is a long sentence t=
hat contains a list of what this document accomplishes.  I suggest turning
it into a bulleted list rather than "This document does A, and B, and C, an=
d D, and ..."

2) There's frequent reference to "UTF-8 headers" where, in at least some ca=
ses, "UTF-8 header fields" is probably more accurate.

3) There's inconsistent use of reference name styles when referring to othe=
r drafts, e.g. [popimap-downgrade] vs. [I-D.ietf-eai-simpledowngrade].  Sug=
gest converting the former to look like the latter.

4) Section 3.1: "Note that even in UTF-8 mode, MIME binary content-transfer=
-encoding is still not permitted."  Can a reference be added to where that'=
s stipulated?

5) Section 6: "The section 2 and 3" and "The section 5" need to be changed =
to just "Sections 2 and 3" and "Section 5", respectively.

6) Section 7: I'm not a fan of normative language in Security Consideration=
s. Normative stuff belongs in earlier sections.  I suggest changing the MUS=
T
in the second paragraph to "are strongly advised to".

7) Section 7: "integrity-protect" should be "protect the integrity of", and=
 there should be a comma after "[RFC2595]".

8) Section 3.1: "high guesses are better than small ones"; "small" should p=
robably be "low".

-MSK

--_000_9452079D1A51524AA5749AD23E0039280FEE4Eexchmbx901corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I have been selected as the Applications Area Direct=
orate (appsdir) reviewer for this draft.  (For background on appsdir, =
please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDi=
rectorate).


 


[NOTE: This is an early review request received by A=
ppsDir.  We typically review documents that are in IETF Last Call, so =
please ignore the boilerplate saying so.]


 


Please resolve these comments along with any other L=
ast Call comments you may receive.  Please wait for direction from you=
r document shepherd or AD before posting a new version of the draft.


 


Document: draft-ietf-eai-rfc5721bis-04

Title: POP3 Support for UTF-8


Reviewer: Murray S. Kucherawy


Review Date: April 22, 2012


IETF Last Call Date: n/a


IESG Telechat Date: n/a


 


Summary:


LANG fr


Ce document est presque pret a etre publie en tant q=
u'un RFC, mais il a quelques questions qui devraient etre resolues avant de=
 la publication.


LANG en


 


Major Issues:


 


None.


 


Minor Issues:


 


1) Section 2: When LANG is issued with no parameters=
, thus requesting a list of supported languages, is that list expected to b=
e ordered in any way?


It doesn't really matter, but the document should pr=
obably say one way or the other.  If a list order is specified by one =
of the referenced RFCs, I missed it.


 


2) Section 3.1: "The UTF8 command MAY fail.&quo=
t;  This seems to be dangling. Can you say why, even if it's "for=
 any operational reason" or something that


just sounds less random?


 


3) It seems to me the second and fifth paragraphs of=
 Section 3.1 could be merged, though that might make the fifth one even lar=
ger than it is.  It's


possible the second could simply be dropped in favou=
r of the fifth as the former seems to be a subset of the latter.  The =
authors might also want to


consider splitting the fifth one someplace, perhaps =
where it starts talking about sizes.


 


4) Section 5 refers to the "UTF-8" Respons=
e Code, when it's actually "UTF8".  This is a bit confusing.=



 


5) Section 3.2: The USER argument to the UTF8 capabi=
lity tells the client something about the USER, PASS and APOP commands.&nbs=
p; As all of those are


basically authentication/credential commands, perhap=
s something less specific like "LOGIN", "AUTH" or "=
;CRED" would be more appropriate?  Otherwise it looks more like i=
t only applies to the USER command.


 


6) This document uses RFC2119 language.  In the=
 Introduction, it says "email messages may be transmitted". =
 Suggest s/may/might/ or s/may/could/.


 


7) Similarly, there's a lot of use of non-caps "=
;may" in Section 3.1.


 


8) Section 5, last paragraph: s/downconvert/down-con=
vert/, and (alas) rather than talking about "mood", say something=
 about having the resources to down-convert where it didn't before or somet=
hing like that.


 


Nits:


 


1) The end of the second paragraph of the introducti=
on is a long sentence that contains a list of what this document accomplish=
es.  I suggest turning


it into a bulleted list rather than "This docum=
ent does A, and B, and C, and D, and ..."


 


2) There's frequent reference to "UTF-8 headers=
" where, in at least some cases, "UTF-8 header fields" is pr=
obably more accurate.


 


3) There's inconsistent use of reference name styles=
 when referring to other drafts, e.g. [popimap-downgrade] vs. [I-D.ietf-eai=
-simpledowngrade].  Suggest converting the former to look like the lat=
ter.


 


4) Section 3.1: "Note that even in UTF-8 mode, =
MIME binary content-transfer-encoding is still not permitted."  C=
an a reference be added to where that's stipulated?


 


5) Section 6: "The section 2 and 3" and &q=
uot;The section 5" need to be changed to just "Sections 2 and 3&q=
uot; and "Section 5", respectively.


 


6) Section 7: I'm not a fan of normative language in=
 Security Considerations. Normative stuff belongs in earlier sections. =
; I suggest changing the MUST


in the second paragraph to "are strongly advise=
d to".


 


7) Section 7: "integrity-protect" should b=
e "protect the integrity of", and there should be a comma after &=
quot;[RFC2595]".


 


8) Section 3.1: "high guesses are better than s=
mall ones"; "small" should probably be "low".=



 


-MSK






--_000_9452079D1A51524AA5749AD23E0039280FEE4Eexchmbx901corpclo_--

From michiel@unhosted.org  Mon Apr 23 00: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 8303B21F8564 for ; Mon, 23 Apr 2012 00:06:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-H8frp2fyEB for ; Mon, 23 Apr 2012 00:06:31 -0700 (PDT)
Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 006F121F8551 for ; Mon, 23 Apr 2012 00:06:30 -0700 (PDT)
Received: by dady13 with SMTP id y13so20971898dad.27 for ; Mon, 23 Apr 2012 00:06:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=R/KbbE5RvhNkO80bOdbUrjU2YaTQPopcTBbvN35e/9c=; b=iqFf/zMR7xRJlYG/rwwwqrpZOgyDpyCr8WxZxD1Olw8eL0GZGENsliPjZr2JxSeTzB fGJDFb6e+tA9NQB5AAVXMvVyL5a2Y1KRVJhurJnQiAI0bkoZZcqfsLsyPVVnILNq1dz2 0JsqdBxnXxYvO3omyejE0kl5/9zf/7UL4ooZgTX+9b3+isA6WfwVAlWJNo1xtJnAubtn v/Lu+/X4hx7UXC81PEvT0+BPs47Y9liCJvhVNqnhch3IZgInqQY4GVpXae7YqP901Yhw bh2YCaqx5ZHreZFsFCnugGVbqvnp5UJcvPSaAx27zQUNm6jRbFKx3yp2AnWCYOaHVwa3 +lJw==
MIME-Version: 1.0
Received: by 10.68.213.73 with SMTP id nq9mr33678784pbc.143.1335164790715; Mon, 23 Apr 2012 00:06:30 -0700 (PDT)
Received: by 10.68.27.138 with HTTP; Mon, 23 Apr 2012 00:06:30 -0700 (PDT)
X-Originating-IP: [83.117.135.113]
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Mon, 23 Apr 2012 09:06:30 +0200
Message-ID: 
From: Michiel de Jong 
To: Mike Jones 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQl6Z7Y7emH+mIaYT+Qvl1FFstSE5K/Fo1Fd/cpFnJo/3GtoitTFLFeWTqkJYuVWxwNN/Pc5
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 07:06:31 -0000

On Mon, Apr 23, 2012 at 6:11 AM, Mike Jones  w=
rote:
> Assuming that we=92re in an either-or situation with regard to either hav=
ing
> single-GET discovery or supporting discovery using only static server pag=
es
> (and I=92d love to have someone demonstrate to us that we=92re not)

We are a typical use case, because over the coming months, we will be
telling 500 or so Dutch university faculties to implement
webfinger/swd, and usually those websites are run by some marketing
office. If the two-hop option disappears then my hope was i could
still use http redirect. So instead of having to host a static page
with a rare MIME type, they will now have to host a http redirect,
which their cms might even have a built-in option for. Wouldn't that
be an elegant way to have an insitu service when possible, but still
be able to do a redirect when facing bureaucracy?

It's just a suggestion, i hope i'm not sounding stupid here, and i
definitely don't want to meddle in the discussion.

Kudos to all of you! I wish the Middle East could be more like the
open web. :) We'll use whatever you guys decide on.


Cheers,
Michiel

From duerst@it.aoyama.ac.jp  Mon Apr 23 00:15: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 DC5EE21F8587 for ; Mon, 23 Apr 2012 00:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.023
X-Spam-Level: 
X-Spam-Status: No, score=-98.023 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG9G63Jd9O2e for ; Mon, 23 Apr 2012 00:15:35 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF2A21F856C for ; Mon, 23 Apr 2012 00:15:35 -0700 (PDT)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q3N7FQSW021253 for ; Mon, 23 Apr 2012 16:15:26 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 138d_84eb_198a27d8_8d14_11e1_bae2_001d096c566a; Mon, 23 Apr 2012 16:15:25 +0900
Received: from [IPv6:::1] ([133.2.210.1]:38331) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Mon, 23 Apr 2012 16:15:25 +0900
Message-ID: <4F95018C.4010806@it.aoyama.ac.jp>
Date: Mon, 23 Apr 2012 16:15: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: Stephen Farrell 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net>	<4F8852D0.4020404@cs.tcd.ie>	<9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>		<9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com>	<4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com>	<091401cd1ea3$e159be70$a40d3b50$@packetizer.com>		<091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>	 <4F917545.5080103@mtcc.com> <4F921E53.8030109@cs.tcd.ie>
In-Reply-To: <4F921E53.8030109@cs.tcd.ie>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Michael Thomas , Derek Atkins , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 07:15:36 -0000

On 2012/04/21 11:41, Stephen Farrell wrote:

> On 04/20/2012 03:40 PM, Michael Thomas wrote:
>>
>> Why not MUST ASN.1 while you're at it? JSON has won in case
>> you'all haven't noticed it.
>
> Well, I also remember when XML won over ASN.1, or
> was that some RPC thing? Seems like a new format wins
> about every five years or so, once the last winner
> gets enough crap added. (JSON pointer seems like the
> start of a nice slippery slope to me.)

There's a bit of that indeed. However, as others have noted, JSON is 
indeed better suited for exchanging *data* between programs, in 
particular between scripting languages, because their main datatypes are 
numbers and strings, and their main data structures are arrays and 
hashes (or whatever they are called).

In contrast to that, XML originated as a document format. It's way 
better than JSON for documents, and for mixed document/data situations, 
but if all you do is exchanging data (structures) between programs, JSON 
wins.

Regards,   Martin.

From iesg-secretary@ietf.org  Mon Apr 23 06:28: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 99C3E21F8633; Mon, 23 Apr 2012 06:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.387
X-Spam-Level: 
X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNvXPtGYbAHI; Mon, 23 Apr 2012 06:28:12 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4B221F8627; Mon, 23 Apr 2012 06:28:12 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120423132812.32410.11259.idtracker@ietfa.amsl.com>
Date: Mon, 23 Apr 2012 06:28:12 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] Last Call:  (Update	to MIME regarding Charset Parameter Handling in Textual Media	Types) to Proposed Standard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Apr 2012 13:28:12 -0000

The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Update to MIME regarding Charset Parameter Handling in Textual Media
   Types'
   as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-05-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document changes RFC 2046 rules regarding default charset
   parameter values for text/* media types to better align with common
   usage by existing clients and servers.

Editorial Note (To be removed by RFC Editor)

   Discussion of this draft should take place on the Apps Area Working
   Group mailing list (apps-discuss@ietf.org), which is archived at
   .




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/ballot/


No IPR declarations have been submitted directly on this I-D.



From simon.perreault@viagenie.ca  Mon Apr 23 06:30: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 BB49B21F84D8 for ; Mon, 23 Apr 2012 06:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pCFPE2nscI2 for ; Mon, 23 Apr 2012 06:30:58 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC1F21F84D6 for ; Mon, 23 Apr 2012 06:30:58 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:117e:5094:eb84:8dcb]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 76F5E41370; Mon, 23 Apr 2012 09:30:57 -0400 (EDT)
Message-ID: <4F955991.2080606@viagenie.ca>
Date: Mon, 23 Apr 2012 09:30:57 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: draft-ietf-appsawg-mime-default-charset@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" 
Subject: [apps-discuss] Default charset in vCard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 13:30:58 -0000

Hi,

I took at look at draft-ietf-appsawg-mime-default-charset-03 to compare 
against what we have in vCard 4.

In vCard 4, we basically say two things:
http://tools.ietf.org/html/rfc6350#section-3.1

1. The charset is always UTF-8.
2. If you use the charset parameter, it MUST be UTF-8.

It looks like it goes against the recommendation in your draft:

    a.  specify that the "charset" parameter is not used for the defined
        subtype, because the charset information is transported inside
        the payload (such as in "text/xml"), or
    b.  require explicit unconditional inclusion of the "charset"
        parameter eliminating the need for a default value.
[...]
    New subtypes of the "text" media type, thus, SHOULD NOT define a
    default "charset" value.  If there is a strong reason to do so
    despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as
    the default.

So, two questions:

- Am I reading this right? Is there actually a conflict?
- Should this be fixed eventually in a vCard 4 bis?

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From robert.cragie@gridmerge.com  Mon Apr 23 07:57: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 4BF9E21F86D7; Mon, 23 Apr 2012 07:57:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO3xKQcPYgBp; Mon, 23 Apr 2012 07:57:37 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 883BC21F86C7; Mon, 23 Apr 2012 07:57:36 -0700 (PDT)
Received: from client-86-29-169-249.brhm-bam-3.adsl.virginmedia.com ([86.29.169.249] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SMKhq-000528-Ig; Mon, 23 Apr 2012 15:57:34 +0100
Message-ID: <4F956E63.80408@gridmerge.com>
Date: Mon, 23 Apr 2012 15:59:47 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: apps-discuss@ietf.org, core 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080306000909040508090609"
X-Authenticated-As: robert.cragie@gridmerge.com
Subject: [apps-discuss] Closing on the application/foo+exi discussion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Apr 2012 14:57:42 -0000

This is a cryptographically signed message in MIME format.

--------------ms080306000909040508090609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

I have read through the many e-mails on the topic and it didn't look=20
like we had closure on this.

I don't see what is wrong with having an 'application/foo+exi' media=20
type. There are already precedents for using this type of syntax. All it =

means is that the schemaId in the EXI options has specific meaning in=20
the 'foo' space and can be used to select a schema for schema-informed=20
EXI, as stated in Zach's draft. The alternative of using media type=20
'application/xml' and content coding 'exi', or media type=20
'application/exi' (equivalent IMHO) means that (assuming no a priori=20
knowledge) schemaId, if present, must be unambiguous, and this basically =

means a URI. This is given as an example in the EXI specification but is =

not mandated. If schemaId is not present, it should mean what it says in =

the EXI specification, i.e. schema-less encoding.

Often in constrained environment, originator and recipient may have=20
schema knowledge a priori and could choose to elide information=20
regarding media type and content coding and, in the case of EXI, EXI=20
options.

Robert



--------------ms080306000909040508090609
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC
BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE
BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w
NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC
VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l
dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO
LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN
NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy
lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq
vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6
hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu
9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G
A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/
BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU
cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk
ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi
54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0
g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd
WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz
Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy
XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi
5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw
FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr
MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS
Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa
Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5
MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY
X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi
QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT
bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX
WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i
Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd
JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB
/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E
UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll
bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH
MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw
JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD
ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf
y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T
4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU
yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE
uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD
AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb
MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh
dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1
OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ
b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd
BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu
MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy
MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh
Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn
zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb
yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS
d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5
5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6
sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb
vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG
A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB
BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50
QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl
LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y
CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ
ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g
k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN
ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a
sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg
TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3
DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQyMzE0NTk0N1owIwYJKoZI
hvcNAQkEMRYEFJ+PDtwuUFgecTYK7Y8jTPtMeK9oMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD
VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG
9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3
BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQCPjUfjhf2SuEwF98xL8RMk
PbfxHqqzdDVWeQWHkCLRH305Ldk1XpuVAGQDyRCGHzf9cEvnqnrNtj/M33WpxjHRMZcaTWoa
iPU73q3R9SeSAtJ+uZk81Vizq5XWzyQMfgT4IdcJYgFoNyN0Z34+ei5wt9AYRRVJGIn3E663
8LhUD87iCZ+F+Cc4hfVqrqnE9V55Sfs+XvegzzTzjgvfgqf0qBQHr4BQmQNg90Hn/ZvHv/v6
/L1O/nWjWS4s+7ZUawozC4vpeZMym4pp3sBAMxnneQZhymNWT9tSYXd/taHgsOhTI6C1/7/x
HYmhpqONRd+xiIp5uU0d2v2uSHwfvL+IAAAAAAAA
--------------ms080306000909040508090609--

From ve7jtb@ve7jtb.com  Mon Apr 23 08:08: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 8C2C721F85E1 for ; Mon, 23 Apr 2012 08:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.529
X-Spam-Level: 
X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qcidxG6fN7o for ; Mon, 23 Apr 2012 08:08:33 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C50F21F85DB for ; Mon, 23 Apr 2012 08:08:32 -0700 (PDT)
Received: by obbwd20 with SMTP id wd20so13115917obb.31 for ; Mon, 23 Apr 2012 08:08:32 -0700 (PDT)
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=N90oTSRTRj8MoVCBT13DSydG64G9jPjvnjaZegtFTt0=; b=VbBj1goK02Uf0Xqsd22FMSHaA1THFa9gqJ/zBRx0f0XlCdnxy8f8Bxvd9uLnxoIQlk MWlYy4IbSDTdfzgRR34p2j2oahTZ8hSrtshILQrz6Qsp9Gi1L1Xix4zs5YYzq20hoW4K A2s5YG6CLH1yyeyszUQtTZwj9MWBZOnNNcDcB2HEJOIHOcRm8DfyxR4tjhOa5+l9XwOn yUG4QofQHRE6CcgFqJXFT6cPwARyVM9gH10wjqiHGrRvLtyLLgFn8kfd1Gs1P3195bsD M++Iofgfa6Ifgch/j/8nEWTmzdO5ZraP5XwmQWFETbxc7j8WY8yV8QrcwIJwP6dAPv+5 LXJg==
Received: by 10.182.155.35 with SMTP id vt3mr4760194obb.63.1335193712549; Mon, 23 Apr 2012 08:08:32 -0700 (PDT)
Received: from [192.168.1.213] (190-20-21-61.baf.movistar.cl. [190.20.21.61]) by mx.google.com with ESMTPS id o6sm13075351oec.11.2012.04.23.08.08.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 08:08:31 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_1AD80774-8599-44E1-B8A3-927A3A2D8C0E"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Mon, 23 Apr 2012 12:08:22 -0300
Message-Id: <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com>
To: Mike Jones 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQmT6ZMK0wERtcGbrm9xz00a3X+wrlrOuQRJZw9YxnP5MMcQ3PmnT8FwVSP8SvVwO6DcZ0gn
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 15:08:36 -0000

--Apple-Mail=_1AD80774-8599-44E1-B8A3-927A3A2D8C0E
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8AB192B8-8C6C-44F3-BE92-8B70968F5157"


--Apple-Mail=_8AB192B8-8C6C-44F3-BE92-8B70968F5157
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Mike,

I think there is less resistance to making resource parameter REQUIRED =
than there is to removing the initial host-meta lookup to get the =
template.

We should probably keep those issues separate.

I agree that supporting indirect discovery of the template via =
host-meta.jason should probably stay.

The question is if their can be an optimization that allows shortcutting =
that step if you know that all you want is web finger.

A possible option for that could be using a fixed template in =
/.well-known/.

That endpoint would return:
a The terminal JRD (like SWD)
b a 3xx redirect to the real endpoint
c a copy of the host-meta.jrd

We would probably only do one of b or c.

c has the advantage of being a static file and you being no worse off =
than having started with host-meta.json.
b is the simplest for the client and only requires common rewriting =
rules.

If the redirect is to the same host you could avoid the overhead of two =
connections by pipelining the requests over the same TCP connection.
SPDY in the future will make that even more efficient.

I will grant Blaine that most openID Connect discovery requests are =
Server to Server,  However there are Apps that are also clients that =
should not be ignored.
I personally like the fixed template with a 3xx redirect and  resource =
parameter returning a JRD due to the simplicity of client coding.

Things needing other sorts of information about the host would still use =
host-meta or host-meta.json.

John B.


On 2012-04-23, at 1:11 AM, Mike Jones wrote:

> I agree with your goal of simplicity for clients.  Paul=92s example =
seems about as simple as it can get for clients:
>                curl -v =
https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paulej@p=
acketizer.com
> It shares the property with your earlier example (below) that clients =
have a no-branches code path to do discovery:
>                curl -s http://example.com/.well-known/host-meta|
>                awk "/lrdd/,/template/"|tr -d '\n'|sed -e =
"s/^.*template=3D'\([^']*\)'.*$/\1/"|
>                sed -e "s/{uri}/user@example.com/"|xargs curl =96s
> =20
> However, I challenge the assumption in your note below that servers =
using only static pages must be supported.  I just don=92t see the =
requirement to implement a query parameter as being an impediment in =
practice, even for hosted domains.  I know of no hosting company that =
doesn=92t provide a means of putting executable code behind web pages, =
be it PHP, Perl, Ruby, ASP, JSP, etc.  I know you=92re trying to make =
the case for static pages, but in practice, I believe that dynamic pages =
are always easily available.
> =20
> Assuming that we=92re in an either-or situation with regard to either =
having single-GET discovery or supporting discovery using only static =
server pages (and I=92d love to have someone demonstrate to us that =
we=92re not), I=92d take single-GET discovery for sure, as in some =
cases, it makes an appreciable difference in user interface latency, and =
per the paragraph above, I believe that dynamic queries can be =
implemented on all hosting platforms.
> =20
> Assuming the WebFinger authors agree, I=92d suggest that a logical =
next step would be for a -04 version of draft-jones-appsawg-webfinger to =
be published that changes support for the resource parameter from =
RECOMMENDED to REQUIRED, as that could provide a starting point for a =
common discovery spec.
> =20
>                                                             -- Mike
> =20
> P.S.  As long as draft-jones-appsawg-webfinger is being revised, I=92d =
also suggest adding text making explicit what has been an implicit =
assumption in both WebFinger and SWD - that depending upon whether and =
how the client is authenticated, the set of resources returned may vary =
(as Blaine had pointed out earlier).  That could help deal with some of =
the privacy perceptions.
> =20
> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of Blaine Cook
> Sent: Sunday, April 22, 2012 2:15 PM
> To: apps-discuss@ietf.org
> Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus =
indirect discovery
> =20
> This is the last issue that I've flagged as blocking a new Webfinger / =
SWD draft.
> =20
> Mike suggested that being able to request a user's profile with a =
single request (i.e., that the /.well-known/ profile resource should be =
able to respond with full profile data immediately, rather than pointing =
at a second URL that will fulfil the request) is a requirement for this =
standard.
> =20
> I'd like to challenge that requirement. The arguments for a direct =
discovery endpoint are:
> =20
> 1. Fewer requests against the server, since we save (in the =
worst-case) 50% of requests by bypassing the indirect lookup phase.
> 2. Lower latency for clients (e.g., mobile clients) owing to the =
reduced number of lookups.
> =20
> The arguments for an indirect discovery endpoint are:
> =20
> 1. Trivial and web-standards friendly deployment for domains that =
won't host their own webfinger/swd profile servers, but want to enable =
accounts on their domains (e.g., statically hosted sites).
> 2. A loosening of the requirement that URLs at the bare domain must =
run dynamic scripts that respond to requests to the /.well-known/ path.
> =20
> My opinion is that the approach that SWD has proposed for the redirect =
is problematic. First, the format is very similar in form to the HTML =
"meta refresh" tag that provided HTTP redirect support from within HTML. =
That format has been widely deprecated, and in these more enlightened =
times, we just use the 3xx response codes with Location headers, =
instead.
> =20
> Secondly, the SWD request format means that for smaller sites, often =
those with the least resources, will end up serving static content in a =
way that's difficult to cache; certainly, more difficult to cache than =
just serving static content. This is due to the request parameters =
present in all SWD requests; those request parameters will bust caches.
> =20
> As for the first argument *for* SWD's approach, I'd suggest we look to =
DNS, which uses the same indirection approach for NS records, relying on =
a (relatively) very small set of root servers to handle the traffic for =
the whole internet. Clearly, this approach works, and webfinger/swd =
servers are in a much better position to handle this additional traffic. =
Most of this traffic will be heavily cached, especially for the largest =
providers.
> =20
> In fact, in terms of real deployments, hosting a script at, e.g., =
google.com/.well-known/simple-web-discovery is much harder than hosting =
a script atprofiles.google.com/profile.json for all sorts of reasons, so =
it's my belief that the first argument is a red herring.
> =20
> The second argument is legitimate, but only if mobile clients will =
actually be making requests to diverse webfinger/swd hosts. Instead, I =
strongly believe that we'll see the emergence of DNS-like servers that =
provide both profile hosting as well as proxy services. For a mobile =
client, the optimal approach will be to use SPDY to connect to a single =
host that performs webfinger/swd lookups on the mobile client's behalf, =
eliminating the latency concerns.
> =20
> I offer that the two-step lookup can be implemented without =
conditionals on the client, whereas the direct-unless-not approach =
cannot be implemented that way (see my earlier curl example for proof). =
It's simpler, and easier to explain to the (hopefully many) small site =
owners who we'd like to implement this technology.
> =20
> Thoughts? Am I missing something?
> =20
> b.
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--Apple-Mail=_8AB192B8-8C6C-44F3-BE92-8B70968F5157
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Mike,

I think there is less =
resistance to making resource parameter REQUIRED than there is to =
removing the initial host-meta lookup to get the =
template.

We should probably keep those issues =
separate.

I agree that supporting indirect =
discovery of the template via host-meta.jason should probably =
stay.

The question is if their can be an =
optimization that allows shortcutting that step if you know that all you =
want is web finger.

A possible option for that =
could be using a fixed template in /.well-known/.

That =
endpoint would return:
a The terminal JRD (like =
SWD)
b a 3xx redirect to the real =
endpoint
c a copy of the =
host-meta.jrd

We would probably only do =
one of b or c.

c has the advantage of being a =
static file and you being no worse off than having started with =
host-meta.json.
b is the simplest for the client and only =
requires common rewriting rules.

If the =
redirect is to the same host you could avoid the overhead of two =
connections by pipelining the requests over the same TCP =
connection.
SPDY in the future will make that even more =
efficient.

I will grant Blaine that most openID =
Connect discovery requests are Server to Server,  However there are =
Apps that are also clients that should not be ignored.
I =
personally like the fixed template with a 3xx redirect and =
 resource parameter returning a JRD due to the simplicity of client =
coding.

Things needing other sorts of =
information about the host would still use host-meta or =
host-meta.json.

John =
B.


On 2012-04-23, at =
1:11 AM, Mike Jones wrote:

I =
agree with your goal of simplicity for clients.  Paul=92s example =
seems about as simple as it can get for =
clients:
 apps-discuss-bounces@ietf.or=
g [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Blaine =
Cook
Sent: Sunday, April 22, 2012 2:15 =
PM
To: apps-discuss@ietf.org
Subj=
ect: [apps-discuss] =
Webfinger / SWD Issue #3: direct versus indirect =
discovery
This is the last issue that =
I've flagged as blocking a new Webfinger / SWD =
draft.
Mike suggested that being =
able to request a user's profile with a single request (i.e., that the =
/.well-known/ profile resource should be able to respond with full =
profile data immediately, rather than pointing at a second URL that will =
fulfil the request) is a requirement for this =
standard.
I'd like to challenge =
that requirement. The arguments for a direct discovery endpoint =
are:
1. Fewer requests against =
the server, since we save (in the worst-case) 50% of requests by =
bypassing the indirect lookup phase.
2. Lower latency for clients (e.g., mobile clients) =
owing to the reduced number of lookups.
 
The arguments for an indirect discovery endpoint =
are:
1. Trivial and =
web-standards friendly deployment for domains that won't host their own =
webfinger/swd profile servers, but want to enable accounts on their =
domains (e.g., statically hosted sites).
2. A loosening of the requirement that URLs at the bare =
domain must run dynamic scripts that respond to requests to the =
/.well-known/ path.
My opinion is that the =
approach that SWD has proposed for the redirect is problematic. First, =
the format is very similar in form to the HTML "meta refresh" tag that =
provided HTTP redirect support from within HTML. That format has been =
widely deprecated, and in these more enlightened times, we just use the =
3xx response codes with Location headers, =
instead.
Secondly, the SWD request =
format means that for smaller sites, often those with the least =
resources, will end up serving static content in a way that's difficult =
to cache; certainly, more difficult to cache than just serving static =
content. This is due to the request parameters present in all SWD =
requests; those request parameters will bust =
caches.
As for the first argument =
*for* SWD's approach, I'd suggest we look to DNS, which uses the same =
indirection approach for NS records, relying on a (relatively) very =
small set of root servers to handle the traffic for the whole internet. =
Clearly, this approach works, and webfinger/swd servers are in a much =
better position to handle this additional traffic. Most of this traffic =
will be heavily cached, especially for the largest =
providers.
apps-discuss@ietf.org
https:/=
/www.ietf.org/mailman/listinfo/apps-discuss

=

--Apple-Mail=_8AB192B8-8C6C-44F3-BE92-8B70968F5157--

--Apple-Mail=_1AD80774-8599-44E1-B8A3-927A3A2D8C0E
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
MzE1MDgyMlowIwYJKoZIhvcNAQkEMRYEFFaUD69T7S4q/Kw8E0tTEai24Yr8MIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AJf4QXq2cQFwU5EcX7yg9yTLrHGKZqFtYeWzHaxV7iTj78rAXEm0bWuJ3d4IPZyDQVXbjbRtdm1M
KOtMIvZeI9uW03sU7CZ30SlHCnZ0pPRS3QNLnibSvJ9GGuvNwwKqDRBquuoMyzBj2ScXtLtflLmV
Yt8t4jVtpzXJM6dZqwBJiNB0IzFX0sqoudTY/DBiBgctVtbMr4UEyftjRAz6su8G/uyAjge3E0C9
phAl3QW/lGcspBVKAeHrAirRBdcBF8kD1SIakZgVgmtc1F9Vl8ni0UW0wH6SIio+ZkC7aL+gwRJh
Rmd8apHDjvFCTP8ih8zGIYtosduTQkYJrg3zErQAAAAAAAA=

--Apple-Mail=_1AD80774-8599-44E1-B8A3-927A3A2D8C0E--

From bobwyman@gmail.com  Mon Apr 23 08:17: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 A6A3721F8672 for ; Mon, 23 Apr 2012 08:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level: 
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.343,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6P20m7gsgVJ for ; Mon, 23 Apr 2012 08:17:23 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB0F121F858B for ; Mon, 23 Apr 2012 08:17:22 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so8411135qcs.31 for ; Mon, 23 Apr 2012 08:17:22 -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=q4izmd+/s6p8GmwQdboBDxSk0qOxVXy/svnGY88Ep2w=; b=iygzssTu9rfFczW+aId3D/AA3foS5K4JARbOFHKHUjNgE6YVSCbKWt7VlMRIfStXPW 4fYTBZcZxejZWm9GjGWkATdJ88Dd4eMWO7z607M2cWetmXAY6QDp++FrSuVmkHMFI2VR LFZxl2uqteLx5lMqRIfZLt+fV+pkGJNHwiT6Yotia6z8/BUAWKDVryjPhE9qhlOTsxZW isAIrBAA5ThNK57q+OIdA2h3b/MEpzvTpRJgY+Pv7kj0Gms1gXdhA54vjnO2u4w7SPYt Ui52ZfemgpWVuu3wRVssosgMMw5PBTbgnMOy6TTufWVkPPQL10zxf1s1i8x2Z2m7zAex lEsQ==
MIME-Version: 1.0
Received: by 10.224.220.142 with SMTP id hy14mr12534272qab.71.1335194242366; Mon, 23 Apr 2012 08:17:22 -0700 (PDT)
Sender: bobwyman@gmail.com
Received: by 10.229.12.194 with HTTP; Mon, 23 Apr 2012 08:17:22 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Mon, 23 Apr 2012 11:17:22 -0400
X-Google-Sender-Auth: fof4c4teZ_xLFVSTnRtkh6xaBtc
Message-ID: 
From: Bob Wyman 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=20cf3074b6e885bf1c04be5a2212
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 15:17:24 -0000

--20cf3074b6e885bf1c04be5a2212
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 23, 2012 at 12:11 AM, Mike Jones w=
rote:

>  I agree with your goal of simplicity for clients.  Paul=92s example seem=
s
> about as simple as it can get for clients:****
>
>                curl -v
> https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paulej@=
packetizer.com
> ****
>
> It shares the property with your earlier example (below) that clients hav=
e
> a no-branches code path to do discovery:****
>
>                curl -s http://example.com/.well-known/host-meta|****
>
>                awk "/lrdd/,/template/"|tr -d '\n'|sed -e
> "s/^.*template=3D'\([^']*\)'.*$/\1/"|****
>
>                sed -e "s/{uri}/user@example.com/"|xargs curl =96s****
>
> ** **
>
> However, I challenge the assumption in your note below that servers using
> only static pages must be supported.  I just don=92t see the requirement =
to
> implement a query parameter as being an impediment in practice, even for
> hosted domains.  I know of no hosting company that doesn=92t provide a me=
ans
> of putting executable code behind web pages, be it PHP, Perl, Ruby, ASP,
> JSP, etc.
>

While "hosting companies" might generally allow "putting executable code
behind web pages," many on the Internet today use blogging sites as their
home sites. In many cases, these blogging sites allow no executable code
other than that which is provided by the blogging platform itself although
they often do allow the creation of static pages required by WebFinger.
Thus, bloggers will often find that they would be able to host their
own identities using WebFinger's static pages but they would not be able to
use the SWD approach (or WF resource) unless and until the blog hosting
site provides such support. Even in the case of those web hosting sites
that support hosting executable code, it should be recognized that the
creation, selection, maintenance and deployment of that executable code
requires technical knowledge greater than that enjoyed by many who have
sites on the Internet. We should not raise the bar to deployment unless
there is a truly compelling reason to do so.

If the kind of discovery we're discussing here is useful, we should do our
best to ensure that it is easily deployed by the widest range of Internet
users and the widest range of systems or devices that can host domains. We
should avoid, wherever possible any complexity that hinders the broadest
adoption or allows discovery to become dependent on the willingness of a
third party to support it.


> I know you=92re trying to make the case for static pages, but in practice=
, I
> believe that dynamic pages are always easily available.****
>
> ** **
>
> Assuming that we=92re in an either-or situation with regard to either hav=
ing
> single-GET discovery or supporting discovery using only static server pag=
es
> (and I=92d love to have someone demonstrate to us that we=92re not), I=92=
d take
> single-GET discovery for sure, as in some cases, it makes an appreciable
> difference in user interface latency, and per the paragraph above, I
> believe that dynamic queries can be implemented on all hosting platforms.=
*
> ***
>
> ** **
>
> Assuming the WebFinger authors agree, I=92d suggest that a logical next s=
tep
> would be for a -04 version of draft-jones-appsawg-webfinger to be publish=
ed
> that changes support for the resource parameter from RECOMMENDED to
> REQUIRED, as that could provide a starting point for a common discovery
> spec.****
>
> ** **
>
>                                                             -- Mike****
>
>   ****
>
> P.S.  As long as draft-jones-appsawg-webfinger is being revised, I=92d al=
so
> suggest adding text making explicit what has been an implicit assumption =
in
> both WebFinger and SWD - that depending upon whether and how the client i=
s
> authenticated, the set of resources returned may vary (as Blaine had
> pointed out earlier).  That could help deal with some of the privacy
> perceptions.****
>
> ** **
>
> *From:* apps-discuss-bounces@ietf.org [mailto:
> apps-discuss-bounces@ietf.org] *On Behalf Of *Blaine Cook
> *Sent:* Sunday, April 22, 2012 2:15 PM
> *To:* apps-discuss@ietf.org
> *Subject:* [apps-discuss] Webfinger / SWD Issue #3: direct versus
> indirect discovery****
>
> ** **
>
> This is the last issue that I've flagged as blocking a new Webfinger / SW=
D
> draft.****
>
> ** **
>
> Mike suggested that being able to request a user's profile with a single
> request (i.e., that the /.well-known/ profile resource should be able to
> respond with full profile data immediately, rather than pointing at a
> second URL that will fulfil the request) is a requirement for this standa=
rd.
> ****
>
> ** **
>
> I'd like to challenge that requirement. The arguments for a direct
> discovery endpoint are:****
>
> ** **
>
> 1. Fewer requests against the server, since we save (in the worst-case)
> 50% of requests by bypassing the indirect lookup phase.****
>
> 2. Lower latency for clients (e.g., mobile clients) owing to the reduced
> number of lookups.****
>
> ** **
>
> The arguments for an indirect discovery endpoint are:****
>
> ** **
>
> 1. Trivial and web-standards friendly deployment for domains that won't
> host their own webfinger/swd profile servers, but want to enable accounts
> on their domains (e.g., statically hosted sites).****
>
> 2. A loosening of the requirement that URLs at the bare domain must run
> dynamic scripts that respond to requests to the /.well-known/ path.****
>
> ** **
>
> My opinion is that the approach that SWD has proposed for the redirect is
> problematic. First, the format is very similar in form to the HTML "meta
> refresh" tag that provided HTTP redirect support from within HTML. That
> format has been widely deprecated, and in these more enlightened times, w=
e
> just use the 3xx response codes with Location headers, instead.****
>
> ** **
>
> Secondly, the SWD request format means that for smaller sites, often thos=
e
> with the least resources, will end up serving static content in a way
> that's difficult to cache; certainly, more difficult to cache than just
> serving static content. This is due to the request parameters present in
> all SWD requests; those request parameters will bust caches.****
>
> ** **
>
> As for the first argument *for* SWD's approach, I'd suggest we look to
> DNS, which uses the same indirection approach for NS records, relying on =
a
> (relatively) very small set of root servers to handle the traffic for the
> whole internet. Clearly, this approach works, and webfinger/swd servers a=
re
> in a much better position to handle this additional traffic. Most of this
> traffic will be heavily cached, especially for the largest providers.****
>
> ** **
>
> In fact, in terms of real deployments, hosting a script at, e.g.,
> google.com/.well-known/simple-web-discovery is much harder than hosting a
> script at profiles.google.com/profile.json for all sorts of reasons, so
> it's my belief that the first argument is a red herring.****
>
> ** **
>
> The second argument is legitimate, but only if mobile clients will
> actually be making requests to diverse webfinger/swd hosts. Instead, I
> strongly believe that we'll see the emergence of DNS-like servers that
> provide both profile hosting as well as proxy services. For a mobile
> client, the optimal approach will be to use SPDY to connect to a single
> host that performs webfinger/swd lookups on the mobile client's behalf,
> eliminating the latency concerns.****
>
> ** **
>
> I offer that the two-step lookup can be implemented without conditionals
> on the client, whereas the direct-unless-not approach cannot be implement=
ed
> that way (see my earlier curl example for proof). It's simpler, and easie=
r
> to explain to the (hopefully many) small site owners who we'd like to
> implement this technology.****
>
> ** **
>
> Thoughts? Am I missing something?****
>
> ** **
>
> b.****
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

--20cf3074b6e885bf1c04be5a2212
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable




On Mon, Apr 2=
3, 2012 at 12:11 AM, Mike Jones <Michael.Jones@microsoft.com=
> wrote:













I agree with your goal of=
 simplicity for clients.=A0 Paul=92s example seems about as simple as it ca=
n get for clients:



=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 curl -v

https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paulej@pa=
cketizer.com


It shares the property wi=
th your earlier example (below) that clients have a no-branches code path t=
o do discovery:



=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 curl -s
h=
ttp://example.com/.well-known/host-meta|


=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 awk "/lrdd/,/template/"|tr -d '\n'|sed=
 -e "s/^.*template=3D'\([^']*\)'.*$/\1/"|



=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 sed -e "s/{uri}/user@example.com/"|xargs curl =96s



=A0<=
/p>

However, I challenge the =
assumption in your note below that servers using only static pages must be =
supported.=A0
I just don=92t see the requirement to imp=
lement a query parameter as being an impediment in practice, even for hoste=
d domains.=A0 I know of no hosting company that doesn=92t provide
 a means of putting executable code behind web pages, be it PHP, Perl, Ruby=
, ASP, JSP, etc.=A0

=
While "hosting companies" might generally allow "putting exe=
cutable code behind web pages," many on the Internet today use bloggin=
g sites as their home sites. In many cases, these blogging sites allow no e=
xecutable code other than that which is provided by the blogging platform i=
tself although they often do allow the creation of static pages required by=
 WebFinger. Thus, bloggers will often find that they would be able to host =
their own=A0identities=A0using WebFinger's static pages but they would =
not be able to use the SWD approach (or WF resource) unless and until the b=
log hosting site provides such support. Even in the case of those web hosti=
ng sites that support hosting executable code, it should be recognized that=
 the creation, selection, maintenance and deployment of that executable cod=
e requires technical knowledge greater than that enjoyed by many who have s=
ites on the Internet. We should not raise the bar to deployment unless ther=
e is a truly compelling reason to do so.



If the kind of discovery we're discussing here is u=
seful, we should do our best to ensure that it is easily deployed by the wi=
dest range of Internet users and the widest range of systems or devices tha=
t can host domains. We should avoid, wherever possible any complexity that =
hinders the broadest adoption or allows discovery to become dependent on th=
e willingness of a third party to support it.


=A0
 I know you=92re trying to make the case for static pages, but in practice=
, I believe that dynamic pages are always easily available.



=A0<=
/p>

Assuming that we=92re in =
an either-or situation with regard to either having single-GET discovery or=
 supporting discovery using only static server pages (and
 I=92d love to have someone demonstrate to us that we=92re not), I=92d take=
 single-GET discovery for sure, as in some cases, it makes an appreciable d=
ifference in user interface latency, and per the paragraph above, I believe=
 that dynamic queries can be implemented
 on all hosting platforms.


=A0<=
/p>

Assuming the WebFinger au=
thors agree, I=92d suggest that a logical next step would be for a -04 vers=
ion of draft-jones-appsawg-webfinger to be published that
 changes support for the resource parameter from RECOMMENDED to REQUIRED, a=
s that could provide a starting point for a common discovery spec.


=A0<=
/p>

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


=A0



P.S.=A0 As long as draft-=
jones-appsawg-webfinger is being revised, I=92d also suggest adding text ma=
king explicit what has been an implicit assumption in both WebFinger
 and SWD - that depending upon whether and how the client is authenticated,=
 the set of resources returned may vary (as Blaine had pointed out earlier)=
.=A0 That could help deal with some of the privacy perceptions.



=A0<=
/p>

From: apps-discuss-bo=
unces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of Blaine Cook

Sent: Sunday, April 22, 2012 2:15 PM

To: apps-=
discuss@ietf.org

Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus indi=
rect discovery


=A0


This is the last issue that I've flagged as bloc=
king a new Webfinger / SWD draft.




=A0






Mike suggested that being able to request a user'=
;s profile with a single request (i.e., that the /.well-known/ profile reso=
urce should be able to respond with full profile data immediately, rather t=
han pointing at a second URL that will
 fulfil the request) is a requirement for this standard.






=A0






I'd like to challenge that requirement. The argu=
ments for a direct discovery endpoint are:






=A0






1. Fewer requests against the server, since we save =
(in the worst-case) 50% of requests by bypassing the indirect lookup phase.=







2. Lower latency for clients (e.g., mobile clients) =
owing to the reduced number of lookups.






=A0






The arguments for an indirect discovery endpoint are=
:






=A0






1. Trivial and web-standards friendly deployment for=
 domains that won't host their own webfinger/swd profile servers, but w=
ant to enable accounts on their domains (e.g., statically hosted sites).=








2. A loosening of the requirement that URLs at the b=
are domain must run dynamic scripts that respond to requests to the /.well-=
known/ path.






=A0






My opinion is that the approach that SWD has propose=
d for the redirect is problematic. First, the format is very similar in for=
m to the HTML "meta refresh" tag that provided HTTP redirect supp=
ort from within HTML. That format has been widely
 deprecated, and in these more enlightened times, we just use the 3xx respo=
nse codes with Location headers, instead.






=A0






Secondly, the SWD request format means that for smal=
ler sites, often those with the least resources, will end up serving static=
 content in a way that's difficult to cache; certainly, more difficult =
to cache than just serving static content.
 This is due to the request parameters present in all SWD requests; those r=
equest parameters will bust caches.






=A0






As for the first argument *for* SWD's approach, =
I'd suggest we look to DNS, which uses the same indirection approach fo=
r NS records, relying on a (relatively) very small set of root servers to h=
andle the traffic for the whole internet.
 Clearly, this approach works, and webfinger/swd servers are in a much bett=
er position to handle this additional traffic. Most of this traffic will be=
 heavily cached, especially for the largest providers.







=A0






In fact, in terms of real deployments, hosting a scr=
ipt at, e.g.,
google.com/.well-known/simple-web-discovery is much harder than h=
osting a script at
profi=
les.google.com/profile.json for all sorts of reasons, so it's my be=
lief that the first argument is a red herring.






=A0






The second argument is legitimate, but only if mobil=
e clients will actually be making requests to diverse webfinger/swd hosts. =
Instead, I strongly believe that we'll see the emergence of DNS-like se=
rvers that provide both profile hosting
 as well as proxy services. For a mobile client, the optimal approach will =
be to use SPDY to connect to a single host that performs webfinger/swd look=
ups on the mobile client's behalf, eliminating the latency concerns.=








=A0






I offer that the two-step lookup can be implemented =
without conditionals on the client, whereas the direct-unless-not approach =
cannot be implemented that way (see my earlier curl example for proof). It&=
#39;s simpler, and easier to explain to
 the (hopefully many) small site owners who we'd like to implement this=
 technology.






=A0






Thoughts? Am I missing something?






=A0






b.









_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--20cf3074b6e885bf1c04be5a2212--

From acmorton@att.com  Sun Apr 22 08:33: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 033C621F85EF; Sun, 22 Apr 2012 08:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.564
X-Spam-Level: 
X-Spam-Status: No, score=-105.564 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1k0yKX5Q8ql; Sun, 22 Apr 2012 08:33:08 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 30F2621F85EA; Sun, 22 Apr 2012 08:33:08 -0700 (PDT)
Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 3b4249f4.0.48075.00-497.127932.nbfkord-smmo06.seg.att.com (envelope-from );  Sun, 22 Apr 2012 15:33:08 +0000 (UTC)
X-MXL-Hash: 4f9424b46bc192ee-67c0defa1ee12293a448d34617114d7fddf9caf1
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 q3MFX7PL001072; Sun, 22 Apr 2012 11:33:07 -0400
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 q3MFX3nw001055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2012 11:33:04 -0400
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor); Sun, 22 Apr 2012 11:32:46 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3MFWkRT015794; Sun, 22 Apr 2012 11:32:46 -0400
Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3MFWd4E015637; Sun, 22 Apr 2012 11:32:41 -0400
Message-Id: <201204221532.q3MFWd4E015637@alpd052.aldc.att.com>
Received: from acmt.att.com (vpn-135-70-90-216.vpn.swst.att.com[135.70.90.216](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120422152929gw1004ortde>; Sun, 22 Apr 2012 15:29:30 +0000
X-Originating-IP: [135.70.90.216]
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sun, 22 Apr 2012 11:33:49 -0400
To: Eliot Lear , "apps-discuss@ietf.org" , draft-ietf-ippm-reporting-metrics.all@tools.ietf.org
From: Al Morton 
In-Reply-To: <4F8E9182.5030509@cisco.com>
References: <4F8E9182.5030509@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-RSA-Action: allow
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.20.145]
X-AnalysisOut: [v=1.0 c=1 a=puFL2sCcuLoA:10 a=vYCYjJk3ffYA:10 a=ofMgfj31e3]
X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8]
X-AnalysisOut: [UMqPvVAA==:17 a=-rt0HHlOy_dhHJYF8zYA:9 a=CjuIK1q_8ugA:10]
X-Mailman-Approved-At: Mon, 23 Apr 2012 08:25:37 -0700
Cc: 'IESG' 
Subject: Re: [apps-discuss] Apps Directorate Review of draft-ietf-ippm-reporting-metrics-08
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Apr 2012 15:33:09 -0000

Hi Eliot,

At 06:03 AM 4/18/2012, Eliot Lear wrote:
>This document is almost ready for publication.  Perhaps also in an 
>academic journal ;-)

Thanks for the compliment, and your review.
replies below,
Al


>Minor comments:
>
>I think the authors should seriously question the intended status of 
>this document.  Is this really a BCP?  The normative language, as 
>applied, suggests so.  See, for instance:
>>    The minimal report on measurements MUST include both Loss and Delay
>>    Metrics.
>
>Alternatively, statements like this one should probably be stated in 
>a more matter-of-fact way, especially since it's rather obvious.

A few 2119 requirements terms slipped into sections 6 and 7,
but are not really needed and will be replaced with lower case terms.


>One additional comment: this work is EXTREMELY DENSE.  It is very 
>well referenced, but there a number of new concepts introduced, 
>nearly begging for separate works.  One example is introduction of 
>Type-C, where some additional expansion might be helpful to the 
>reader (like me).

It will be left for further work on TCP metrics to flesh-out
Type-C, but new references to RFC 3148 and 6349 should help
the reader for now.


>Nits:
>
>Section 6.1: expand first use of acronyms OWAMP and TWAMP.

done.




From david@dbooth.org  Sun Apr 22 08:20: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 9CF7A21F852C for ; Sun, 22 Apr 2012 08:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level: 
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGvtSoGt1Mop for ; Sun, 22 Apr 2012 08:20:54 -0700 (PDT)
Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by ietfa.amsl.com (Postfix) with SMTP id AFE8B21F84EF for ; Sun, 22 Apr 2012 08:20:53 -0700 (PDT)
Received: (qmail 34623 invoked from network); 22 Apr 2012 15:20:15 -0000
Received: from 174.58.10.129 (HELO ?192.168.10.140?) (174.58.10.129) by relay01.pair.com with SMTP; 22 Apr 2012 15:20:15 -0000
X-pair-Authenticated: 174.58.10.129
From: David Booth 
To: Ned Freed 
In-Reply-To: <01OELBIO0RA600ZGHB@mauve.mrochek.com>
References: <4F877CEE.5030107@arcanedomain.com> <01OE8S1I9Z2K00ZUIL@mauve.mrochek.com> <9452079D1A51524AA5749AD23E0039280EF063@exch-mbx901.corp.cloudmark.com>  <4F87EBD4.90501@gmx.de>  <01OEABGEZ8RU00ZUIL@mauve.mrochek.com> <098D7D86-2FF3-4287-800F-5FAB6C0212F2@jenitennison.com> <01OEE9DUSD8400ZUIL@mauve.mrochek.com> <4F8D189A.3010304@gmx.de> <4F901485.20800@maillennium.att.com> <01OEITCHB07U00ZGHB@mauve.mrochek.com> <02811F06-0325-4A0D-AE0D-3B5AF07EAE97@jenitennison.com> <4F91A089.6070308@maillennium.att.com> <01OELBIO0RA600ZGHB@mauve.mrochek.com>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 22 Apr 2012 11:20:51 -0400
Message-ID: <1335108051.2164.43102.camel@dbooth-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 23 Apr 2012 08:26:01 -0700
Cc: apps-discuss@ietf.org, Tony Hansen , "www-tag@w3.org List" 
Subject: Re: [apps-discuss] W3C TAG Comment on Draft Media Type Specifications and Registration Procedures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Apr 2012 15:20:54 -0000

> > Media types using "+json" SHOULD process any fragment identifiers
> > defined for "application/json" in the same way as defined for that media
> > type. 

Please forgive me if I am missing something obvious, but . . .

I find the sentence above ambiguous, as it isn't clear whether the
phrase 'that media type' refers to 'application/json' or 'Media types
using "+json"'.  I suggest being explicit instead of saying "that media
type".

> > Media types using "+xml" SHOULD process any fragment identifiers defined
> > for "application/xml" in the same way as defined for that media type.

Ditto.


-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.


From derek@ihtfp.com  Mon Apr 23 07:54: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 DE84E21F86B6; Mon, 23 Apr 2012 07:54:34 -0700 (PDT)
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.280, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gipAJlU5Nhcd; Mon, 23 Apr 2012 07:54:33 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 4D53121F86D1; Mon, 23 Apr 2012 07:54:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 45D80260299; Mon, 23 Apr 2012 10:54:28 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 29954-03; Mon, 23 Apr 2012 10:54:26 -0400 (EDT)
Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 4158C2601D8; Mon, 23 Apr 2012 10:54:26 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3NEsNRG024957; Mon, 23 Apr 2012 10:54:23 -0400
From: Derek Atkins 
To: Michael Thomas 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com>
Date: Mon, 23 Apr 2012 10:54:21 -0400
In-Reply-To: <4F917545.5080103@mtcc.com> (Michael Thomas's message of "Fri, 20 Apr 2012 07:40:05 -0700")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: Maia Mailguard 1.0.2a
X-Mailman-Approved-At: Mon, 23 Apr 2012 08:26:22 -0700
Cc: Derek Atkins , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 14:54:35 -0000

Michael Thomas  writes:

>
> Why not MUST ASN.1 while you're at it? JSON has won in case
> you'all haven't noticed it.

Well, now that you mention it...   ;-)

But seriously, we're basing this work on an RFC that was just release
six months ago and it requires XML.  Why be so quick to drop something
we just published half a year ago?  So maybe in 6 months we drop JSON
and add the next big thing?  Come on, Mike.

I agree, we should definitely support JSON.  But I also think we should
support XML.  The client can do what it wants, which is where want the
light weight implementation.

> Mike

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From mike@mtcc.com  Mon Apr 23 08:23: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 4C8FE21F8746; Mon, 23 Apr 2012 08:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxjD55S2QQcd; Mon, 23 Apr 2012 08:23:15 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id DCD9F21F8745; Mon, 23 Apr 2012 08:23:14 -0700 (PDT)
Received: from piolinux.mtcc.com (65-172-208-69.dsl.volcano.net [65.172.208.69]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3NFN7Q6014312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 08:23:08 -0700
Message-ID: <4F9573D6.9080603@mtcc.com>
Date: Mon, 23 Apr 2012 08:23:02 -0700
From: Michael Thomas 
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Derek Atkins 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net>	<4F8852D0.4020404@cs.tcd.ie>	<9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>		<9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com>	<4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com>	<091401cd1ea3$e159be70$a40d3b50$@packetizer.com>		<091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>	 <4F917545.5080103@mtcc.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1434; t=1335194589; x=1336058589; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20[apps-discuss]=20Web=20Fin ger=20vs.=20Simple=20Web=20Discovery=0A=20(SWD) |Sender:=20 |To:=20Derek=20Atkins=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=55hjgRXMjNzDwpneJDH98T6BCdCvVYICzQfD1k8US7M=; b=uCncYxBwftAQRn1tgsmTzjfpEENgmnXWhTyB7GztEtN5JYqjlQhzOsAa2M o5iTU+/UXlr4m0sJwcv1gM+CF5nsKTuzxFTGqDexLXCFrzzm+QJMz4k83Xi5 VHq6tyQ87p6lmI3lDbOvYdM6Hq+6guIF2yB18i2COJYJDECA4RJ2Y=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
X-Mailman-Approved-At: Mon, 23 Apr 2012 08:26:34 -0700
Cc: oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 15:23:16 -0000

Derek Atkins wrote:
> Michael Thomas  writes:
> 
>> Why not MUST ASN.1 while you're at it? JSON has won in case
>> you'all haven't noticed it.
> 
> Well, now that you mention it...   ;-)
> 
> But seriously, we're basing this work on an RFC that was just release
> six months ago and it requires XML.  Why be so quick to drop something
> we just published half a year ago?  So maybe in 6 months we drop JSON
> and add the next big thing?  Come on, Mike.
> 
> I agree, we should definitely support JSON.  But I also think we should
> support XML.  The client can do what it wants, which is where want the
> light weight implementation.

I think you're probably misunderstanding me. I'm (I believe) with Tim
in saying "pick one". Just one. For clients and servers. And I'm only
saying that JSON is preferable because it has pretty much taken
over -- I see JSON all the time with webbish ajax-y data stuff and XML
almost never unless it's something vaguely markup-like. JSON is clean
in a what you see is what you get kind of way, and I'm puzzled by people
calling a 6 year old RFC a "flavor of the day" -- c'mon.

 From a programming standpoint, JSON is just easier to deal with. Consider
these two links:

http://php.net/manual/en/book.json.php

http://php.net/manual/en/book.xml.php

and tell me which you'd rather deal with. It's not huge, but it's not
nothing either.

Mike

Mike

From derek@ihtfp.com  Mon Apr 23 08:04: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 1C2BB21F85E4; Mon, 23 Apr 2012 08:04:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.988
X-Spam-Level: 
X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m146Vpmq3vXU; Mon, 23 Apr 2012 08:04:40 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7DC21F86B5; Mon, 23 Apr 2012 08:04:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 29E402602A9; Mon, 23 Apr 2012 11:04:39 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 29954-09; Mon, 23 Apr 2012 11:04:37 -0400 (EDT)
Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 41AC7260299; Mon, 23 Apr 2012 11:04:37 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3NF4ZUF025144; Mon, 23 Apr 2012 11:04:35 -0400
From: Derek Atkins 
To: Tim Bray 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  
Date: Mon, 23 Apr 2012 11:04:34 -0400
In-Reply-To:  (Tim Bray's message of "Fri, 20 Apr 2012 08:12:13 -0700")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard 1.0.2a
X-Mailman-Approved-At: Mon, 23 Apr 2012 08:26:48 -0700
Cc: Derek Atkins , oauth@ietf.org, Apps Discuss 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 15:04:41 -0000

Tim Bray  writes:

> There's a disconnect here. Mnot and I (at least) have argued that
> there are very specific problems and costs associated with going
> multi-format.  I=E2=80=99ve heard lots of people say "Well, I support
> multi-format=E2=80=9D but I haven=E2=80=99t heard any specific responses =
explaining
> why those costs and problems aren=E2=80=99t real, or why the benefits are
> sufficiently great that we should just accept them.
>
> Mnot: JSON or XML: Just Decide
> http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide
> tbray: Case Study: Atom and/or JSON
> http://www.tbray.org/ongoing/When/200x/2009/04/29/Model-and-Syntax#p-1
>
> Would this work better if I summarized the problems here inline in
> this thread?  It may be the pace that people=E2=80=99s IETF/email workflo=
w is
> such that they=E2=80=99re not able comfortably to consult external refere=
nces?

No, but I disagree with your conclusions.  Indeed, I disagree with your
problem statement.  Just because the server supports multiple formats
does NOT imply more work for the client.  The client can request a
specific format and never has to worry about the other, so it has NOT
doubled the work on the other side.

Let's take your rails example.  Yes, it's simple for a rails server to
output HTML, XML, JSON, and other formats.  But no, this does NOT make
it harder for the consumer of that content.  The consumer can
specifically ask for whatever format it wants!  This means you can have
a JSON-only client and it can interact 100% with your rails application
using just JSON.  It doesn't have to worry about receiving XML, because
it will always get JSON.

As for your abstract model issue..  Maybe Mike was right and we SHOULD
use ASN.1!  :-D Then we could have defined encodings to XML or JSON ;)

>  -Tim

-derek
--=20
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From bobwyman@gmail.com  Mon Apr 23 08:27: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 04D8521F867B for ; Mon, 23 Apr 2012 08:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.676
X-Spam-Level: 
X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkANDnxcKT7L for ; Mon, 23 Apr 2012 08:26:55 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBFA21F86FC for ; Mon, 23 Apr 2012 08:26:54 -0700 (PDT)
Received: by qaea16 with SMTP id a16so1561390qae.10 for ; Mon, 23 Apr 2012 08:26:53 -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=umKCuXzdQXu86e4bPGx8nPmg3Qp4yMed47RbJgceuvc=; b=J2SKyI5ZE9y+7xC3uGF/1zgr014fLMONEeZQe3ZjsgtSpKh064uSd1MMEPTm19OUCS hoMkJEakci62vixiSkPjfc8xlppm72xI+ffZ/dteZXM0XEVi/CUAfE6cBqKVKt8jqbzm E8lQ49J/dQcjKpVtY+JynnBcEO+QXhMm4PAlAaQgZXFMH+Ju58/JgPN75WQyMEDbTJLg rIMmdTITBS30RLZYHUZBsa/MG0wvmZmjwus4wiIKARD/q0BcE+gCRjWsvRiPoAn9df0X itvLxBthFrxiAAkOKf+6PPGetLpeDCMWvtMFrggjdF4U31987eFZSZ6nA2g4l+lapSM4 53Mg==
MIME-Version: 1.0
Received: by 10.229.111.79 with SMTP id r15mr4314743qcp.3.1335194813600; Mon, 23 Apr 2012 08:26:53 -0700 (PDT)
Sender: bobwyman@gmail.com
Received: by 10.229.12.194 with HTTP; Mon, 23 Apr 2012 08:26:53 -0700 (PDT)
In-Reply-To: <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>
Date: Mon, 23 Apr 2012 11:26:53 -0400
X-Google-Sender-Auth: Owj0ylOqsf_URl6FzIZD_pfK4Pc
Message-ID: 
From: Bob Wyman 
To: John Bradley 
Content-Type: multipart/alternative; boundary=0023544709889214c804be5a44f1
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 15:27:01 -0000

--0023544709889214c804be5a44f1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 23, 2012 at 11:08 AM, John Bradley  wrote:

> Mike,
>
> I think there is less resistance to making resource parameter REQUIRED
> than there is to removing the initial host-meta lookup to get the templat=
e.
>
> We should probably keep those issues separate.
>
> I agree that supporting indirect discovery of the template via
> host-meta.jason should probably stay.
>
> The question is if their can be an optimization that allows shortcutting
> that step if you know that all you want is web finger.
>
> A possible option for that could be using a fixed template in /
> .well-known/.
>
> That endpoint would return:
> a The terminal JRD (like SWD)
> b a 3xx redirect to the real endpoint
>
Causing a 3xx redirect typically requires modification to the configuration
files of a multi-host shared web server. Access to such configuration files
is often restricted in such a way that those responsible from just one or a
few of the sites sharing the common server are not permitted to make
modifications to those files. In many cases, such modifications can be
requested and will only be made after lengthy delays or the payment of
support and maintenance fees.

If we want this sort of discovery to become generally available, and not
just be limited to the "large" sites, we should ensure that it is as simple
as possible to deploy.


> c a copy of the host-meta.jrd
>
> We would probably only do one of b or c.
>
> c has the advantage of being a static file and you being no worse off tha=
n
> having started with host-meta.json.
> b is the simplest for the client and only requires common rewriting rules=
.
>
> If the redirect is to the same host you could avoid the overhead of two
> connections by pipelining the requests over the same TCP connection.
> SPDY in the future will make that even more efficient.
>
> I will grant Blaine that most openID Connect discovery requests are Serve=
r
> to Server,  However there are Apps that are also clients that should not =
be
> ignored.
> I personally like the fixed template with a 3xx redirect and  resource
> parameter returning a JRD due to the simplicity of client coding.
>
> Things needing other sorts of information about the host would still use
> host-meta or host-meta.json.
>
> John B.
>
>
> On 2012-04-23, at 1:11 AM, Mike Jones wrote:
>
> I agree with your goal of simplicity for clients.  Paul=92s example seems
> about as simple as it can get for clients:****
>                curl -v
> https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paulej@=
packetizer.com
> ****
> It shares the property with your earlier example (below) that clients hav=
e
> a no-branches code path to do discovery:****
>                curl -s http://example.com/.well-known/host-meta|****
>                awk "/lrdd/,/template/"|tr -d '\n'|sed -e
> "s/^.*template=3D'\([^']*\)'.*$/\1/"|****
>                sed -e "s/{uri}/user@example.com/"|xargs curl =96s****
> ** **
> However, I challenge the assumption in your note below that servers using
> only static pages must be supported.  I just don=92t see the requirement =
to
> implement a query parameter as being an impediment in practice, even for
> hosted domains.  I know of no hosting company that doesn=92t provide a me=
ans
> of putting executable code behind web pages, be it PHP, Perl, Ruby, ASP,
> JSP, etc.  I know you=92re trying to make the case for static pages, but =
in
> practice, I believe that dynamic pages are always easily available.****
> ** **
> Assuming that we=92re in an either-or situation with regard to either hav=
ing
> single-GET discovery or supporting discovery using only static server pag=
es
> (and I=92d love to have someone demonstrate to us that we=92re not), I=92=
d take
> single-GET discovery for sure, as in some cases, it makes an appreciable
> difference in user interface latency, and per the paragraph above, I
> believe that dynamic queries can be implemented on all hosting platforms.=
*
> ***
> ** **
> Assuming the WebFinger authors agree, I=92d suggest that a logical next s=
tep
> would be for a -04 version of draft-jones-appsawg-webfinger to be publish=
ed
> that changes support for the resource parameter from RECOMMENDED to
> REQUIRED, as that could provide a starting point for a common discovery
> spec.****
> ** **
>                                                             -- Mike****
>  ****
> P.S.  As long as draft-jones-appsawg-webfinger is being revised, I=92d al=
so
> suggest adding text making explicit what has been an implicit assumption =
in
> both WebFinger and SWD - that depending upon whether and how the client i=
s
> authenticated, the set of resources returned may vary (as Blaine had
> pointed out earlier).  That could help deal with some of the privacy
> perceptions.****
> ** **
> *From:* apps-discuss-bounces@ietf.org [mailto:
> apps-discuss-bounces@ietf.org] *On Behalf Of *Blaine Cook
> *Sent:* Sunday, April 22, 2012 2:15 PM
> *To:* apps-discuss@ietf.org
> *Subject:* [apps-discuss] Webfinger / SWD Issue #3: direct versus
> indirect discovery****
> ** **
> This is the last issue that I've flagged as blocking a new Webfinger / SW=
D
> draft.****
> ** **
> Mike suggested that being able to request a user's profile with a single
> request (i.e., that the /.well-known/ profile resource should be able to
> respond with full profile data immediately, rather than pointing at a
> second URL that will fulfil the request) is a requirement for this standa=
rd.
> ****
> ** **
> I'd like to challenge that requirement. The arguments for a direct
> discovery endpoint are:****
> ** **
> 1. Fewer requests against the server, since we save (in the worst-case)
> 50% of requests by bypassing the indirect lookup phase.****
> 2. Lower latency for clients (e.g., mobile clients) owing to the reduced
> number of lookups.****
> ** **
> The arguments for an indirect discovery endpoint are:****
> ** **
> 1. Trivial and web-standards friendly deployment for domains that won't
> host their own webfinger/swd profile servers, but want to enable accounts
> on their domains (e.g., statically hosted sites).****
> 2. A loosening of the requirement that URLs at the bare domain must run
> dynamic scripts that respond to requests to the /.well-known/ path.****
> ** **
> My opinion is that the approach that SWD has proposed for the redirect is
> problematic. First, the format is very similar in form to the HTML "meta
> refresh" tag that provided HTTP redirect support from within HTML. That
> format has been widely deprecated, and in these more enlightened times, w=
e
> just use the 3xx response codes with Location headers, instead.****
> ** **
> Secondly, the SWD request format means that for smaller sites, often thos=
e
> with the least resources, will end up serving static content in a way
> that's difficult to cache; certainly, more difficult to cache than just
> serving static content. This is due to the request parameters present in
> all SWD requests; those request parameters will bust caches.****
> ** **
> As for the first argument *for* SWD's approach, I'd suggest we look to
> DNS, which uses the same indirection approach for NS records, relying on =
a
> (relatively) very small set of root servers to handle the traffic for the
> whole internet. Clearly, this approach works, and webfinger/swd servers a=
re
> in a much better position to handle this additional traffic. Most of this
> traffic will be heavily cached, especially for the largest providers.****
> ** **
> In fact, in terms of real deployments, hosting a script at, e.g.,
> google.com/.well-known/simple-web-discovery is much harder than hosting a
> script atprofiles.google.com/profile.json for all sorts of reasons, so
> it's my belief that the first argument is a red herring.****
> ** **
> The second argument is legitimate, but only if mobile clients will
> actually be making requests to diverse webfinger/swd hosts. Instead, I
> strongly believe that we'll see the emergence of DNS-like servers that
> provide both profile hosting as well as proxy services. For a mobile
> client, the optimal approach will be to use SPDY to connect to a single
> host that performs webfinger/swd lookups on the mobile client's behalf,
> eliminating the latency concerns.****
> ** **
> I offer that the two-step lookup can be implemented without conditionals
> on the client, whereas the direct-unless-not approach cannot be implement=
ed
> that way (see my earlier curl example for proof). It's simpler, and easie=
r
> to explain to the (hopefully many) small site owners who we'd like to
> implement this technology.****
> ** **
> Thoughts? Am I missing something?****
> ** **
> b.****
> _______________________________________________
> 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
>
>

--0023544709889214c804be5a44f1
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable




On Mon, Apr 2=
3, 2012 at 11:08 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:=



Mike,

I think there =
is less resistance to making resource parameter REQUIRED than there is to r=
emoving the initial host-meta lookup to get the template.



We should probably keep those issues separate.

I agree that supporting indirect discovery of the template via host-meta.=
jason should probably stay.

The question is if the=
ir can be an optimization that allows shortcutting that step if you know th=
at all you want is web finger.



A possible option for that could be using a fixed templ=
ate in /.well-known/.

That endpoint would return:


a The terminal JRD (like =
SWD)
b a 3xx =
redirect to the real endpoint
Causing a=
 3xx redirect typically requires modification to the configuration files of=
 a multi-host shared web server. Access to such configuration files is ofte=
n restricted in such a way that those responsible from just one or a few of=
 the sites sharing the common server are not permitted to make modification=
s to those files. In many cases, such modifications can be requested and wi=
ll only be made after lengthy delays or the payment of support and maintena=
nce fees.=A0



If we want this sort of discovery to become generally a=
vailable, and not just be limited to the "large" sites, we should=
 ensure that it is as simple as possible to deploy.
=A0


c a copy of the host-meta.jrd

We=
 would probably only do one of b or c.

c has the a=
dvantage of being a static file and you being no worse off than having star=
ted with host-meta.json.


b is the simplest for the client and only requires common rewriting ru=
les.

If the redirect is to the same host you could=
 avoid the overhead of two connections by pipelining the requests over the =
same TCP connection.


SPDY in the future will make that even more efficient.

<=
/div>
I will grant Blaine that most openID Connect discovery requests a=
re Server to Server, =A0However there are Apps that are also clients that s=
hould not be ignored.


I personally like the fixed template with a 3xx redirect and =A0resour=
ce parameter returning a JRD due to the simplicity of client coding.
<=
div>
Things needing other sorts of information about the host=
 would still use host-meta or host-meta.json.



John B.


On 2012-04-23, at 1:11 AM, Mike Jones wrote:


I agree with your goal of simplicity for cli=
ents.=A0 Paul=92s example seems about as simple as it can get for clients:<=
u>



It shares the property with your earlier example (below) that clients ha=
ve a no-branches code path to do discovery:


=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 curl -s=A0http://example.com/.well-known/host=
-meta|


=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 awk "/lrdd/,/template/&q=
uot;|tr -d '\n'|sed -e "s/^.*template=3D'\([^']*\)'=
;.*$/\1/"|


=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 sed -e "s/{uri}/user@example.com/"=
|xargs curl =96s


=A0


However, I challenge the assumption in your note below that servers usin=
g only static pages must be supported.=A0=A0I j=
ust don=92t see the requirement to implement a query parameter as being an =
impediment in practice, even for hosted domains.=A0 I know of no hosting co=
mpany that doesn=92t provide a means of putting executable code behind web =
pages, be it PHP, Perl, Ruby, ASP, JSP, etc.=A0 I know you=92re trying to m=
ake the case for static pages, but in practice, I believe that dynamic page=
s are always easily available.


=A0


Assuming that we=92re in an either-or situation with regard to either ha=
ving single-GET discovery or supporting discovery using only static server =
pages (and I=92d love to have someone demonstrate to us that we=92re not), =
I=92d take single-GET discovery for sure, as in some cases, it makes an app=
reciable difference in user interface latency, and per the paragraph above,=
 I believe that dynamic queries can be implemented on all hosting platforms=
.


=A0


Assuming the WebFinger authors agree, I=92d suggest that a logical next =
step would be for a -04 version of draft-jones-appsawg-webfinger to be publ=
ished that changes support for the resource parameter from RECOMMENDED to R=
EQUIRED, as that could provide a starting point for a common discovery spec=
.


=A0


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


=A0


P.S.=A0 As long as draft-jones-appsawg-webfinger is being revised, I=92d=
 also suggest adding text making explicit what has been an implicit assumpt=
ion in both WebFinger and SWD - that depending upon whether and how the cli=
ent is authenticated, the set of resources returned may vary (as Blaine had=
 pointed out earlier).=A0 That could help deal with some of the privacy per=
ceptions.


=A0


From:=
=A0apps-d=
iscuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]=A0On Behalf Of=A0Blaine Cook

Sent:=A0Sunday, April 22, 2012 2:15 PM
To:=A0app=
s-discuss@ietf.org
Subject:=A0[apps-discuss] Web=
finger / SWD Issue #3: direct versus indirect discovery


=A0

This is the last issue that I've flagged as blocking a new Webfinger / =
SWD draft.

=A0
Mike suggested that being able to request a us=
er's profile with a single request (i.e., that the /.well-known/ profil=
e resource should be able to respond with full profile data immediately, ra=
ther than pointing at a second URL that will fulfil the request) is a requi=
rement for this standard.


=A0

I'd like to challenge that requirement. The arguments for a direct disc=
overy endpoint are:

=A0
1. Fewer requests against the server, since we=
 save (in the worst-case) 50% of requests by bypassing the indirect lookup =
phase.


2. Lower latency for clients (e.g., mobile clients) owing to the redu=
ced number of lookups.


=A0

The arguments for an indirect discovery endpoint are:

=A0
1. Trivial and web-standards friendly deployme=
nt for domains that won't host their own webfinger/swd profile servers,=
 but want to enable accounts on their domains (e.g., statically hosted site=
s).


2. A loosening of the requirement that URLs at the bare domain must r=
un dynamic scripts that respond to requests to the /.well-known/ path.


=A0

My opinion is that the approach that SWD has proposed for the redirect is p=
roblematic. First, the format is very similar in form to the HTML "met=
a refresh" tag that provided HTTP redirect support from within HTML. T=
hat format has been widely deprecated, and in these more enlightened times,=
 we just use the 3xx response codes with Location headers, instead.<=
u>


=A0

Secondly, the SWD request format means that for smaller sites, often those =
with the least resources, will end up serving static content in a way that&=
#39;s difficult to cache; certainly, more difficult to cache than just serv=
ing static content. This is due to the request parameters present in all SW=
D requests; those request parameters will bust caches.


=A0

As for the first argument *for* SWD's approach, I'd suggest we look=
 to DNS, which uses the same indirection approach for NS records, relying o=
n a (relatively) very small set of root servers to handle the traffic for t=
he whole internet. Clearly, this approach works, and webfinger/swd servers =
are in a much better position to handle this additional traffic. Most of th=
is traffic will be heavily cached, especially for the largest providers.=



=A0

In fact, in terms of real deployments, hosting a script at, e.g.,=A0<=
/span>google.com/.wel=
l-known/simple-web-discovery=A0is much harder than hosting=
 a script atprofiles.google.com/p=
rofile.json=A0for all sorts of reasons, so it's my bel=
ief that the first argument is a red herring.


=A0

The second argument is legitimate, but only if mobile clients will actually=
 be making requests to diverse webfinger/swd hosts. Instead, I strongly bel=
ieve that we'll see the emergence of DNS-like servers that provide both=
 profile hosting as well as proxy services. For a mobile client, the optima=
l approach will be to use SPDY to connect to a single host that performs we=
bfinger/swd lookups on the mobile client's behalf, eliminating the late=
ncy concerns.


=A0

I offer that the two-step lookup can be implemented without conditionals on=
 the client, whereas the direct-unless-not approach cannot be implemented t=
hat way (see my earlier curl example for proof). It's simpler, and easi=
er to explain to the (hopefully many) small site owners who we'd like t=
o implement this technology.


=A0

Thoughts? Am I missing something?
=A0


b.
___________=
____________________________________

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




_______________________=
________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--0023544709889214c804be5a44f1--

From wmills@yahoo-inc.com  Mon Apr 23 08:29: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 9CB2521F8438 for ; Mon, 23 Apr 2012 08:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.163
X-Spam-Level: 
X-Spam-Status: No, score=-17.163 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA4SFLWPwliq for ; Mon, 23 Apr 2012 08:29:19 -0700 (PDT)
Received: from nm17.bullet.mail.ac4.yahoo.com (nm17.bullet.mail.ac4.yahoo.com [98.139.52.214]) by ietfa.amsl.com (Postfix) with SMTP id E1F5021F8319 for ; Mon, 23 Apr 2012 08:29:14 -0700 (PDT)
Received: from [98.139.52.193] by nm17.bullet.mail.ac4.yahoo.com with NNFMP; 23 Apr 2012 15:29:10 -0000
Received: from [98.139.52.163] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 23 Apr 2012 15:29:10 -0000
Received: from [127.0.0.1] by omp1046.mail.ac4.yahoo.com with NNFMP; 23 Apr 2012 15:29:10 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 271233.37327.bm@omp1046.mail.ac4.yahoo.com
Received: (qmail 39070 invoked by uid 60001); 23 Apr 2012 15:29:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1335194949; bh=n84paakGsGH6FrJkERxd1I/FO63U/Q5uY1Q9vtt9XHA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=W/uxQRikbEBisp1bnmJBNvc7tqn66AqugfG+MYZfa/Kc3gsWuUz8CvrWQ/b6sU6jqpB+4P5uEiILjjj690XFGljwCdSsgdKjhb8EKtVBBAPqPQWw+YGcmWrcytQpPzZLVmDsZQST4So17BrhhVtH9oMr4El1/xlS88g/lJAoqf8=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=PLKIuD4YxLEKqO9AidgUHClsxLuYiP0KhIgoGbIIJ6GCt+GA+awbLBAdRlp3vv0toRGMILsSMaXuEV34u95Hm/GutYtrZc5b8P3sCK6zDtfsFUUHG3IZqfi7YKPy0JCEl55CloATU37/ylwYMq3K5+cBCcO9lPbdUZDMUA4Gasc=;
X-YMail-OSG: iv9IebQVM1m0pQvwZuUgvQnDbxqUYPDaJUk3nKQqClYx_UD atIqy3edcWTgyoinJWL25K_jir0ZreACLUZthb.c_NOzAUoTgxhb1Ypw0wkJ C.8xnJCdA85YO60HzvI3XybgZhPlSoarJYKJ4BkYoq4em4ueSKDMZdb50.I6 H4NssqWNn9v6HwqwzVi_4k3Pye6UvLQ0JNE5dQzx3PgtqpIe3GSsIrSB9PW1 _32oNs5X5amroB93KPdNmtnCTB9V.v2SagZJD8DXxGrEanmX4AHKbwYwyK1N iq.Ia_EFJ2rv1JwiokA0UXHDoaSq1oGGdWCoJS1G0Uv4A4qCBuUscT6p2a9_ D8rV7HO6p.JFiMJy23ZrYzPWYUabP2Pr7e.wiwtmCk6_cCFj6vutEOSM_uHt PFcRyCpbZ9DMhR501Atd9zYJXMvvDCjZgLQZHWt.P363OGATtBTfL_cV6LH1 OY5fiS5.wfTwnMAJ6Zh9SX6DFIIsvPNwPqVuWh3jtbhYRqcc9SQBsqdCBbV7 9VX0JoZsdO4KaniDncmKNWMphbNO_IoFmUbQGpr_QF5auY035Opt77n82KrC 5A35J4xF2Ecbs_JsRdWN_sgxPwvDuU751eNXIOfj7OPpNT.0gFGA_pneP0sp ErSBFtRl2reTOcLbYFvF.z3jb1OzrpSS0mcB3X667YFmmUoBvCReP7d2YwYK fUGef0v14uFQ.DZyt3O81vA0_uGHcse3njiSx_xc-
Received: from [99.31.212.42] by web31812.mail.mud.yahoo.com via HTTP; Mon, 23 Apr 2012 08:29:09 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com>
Message-ID: <1335194949.12040.YahooMailNeo@web31812.mail.mud.yahoo.com>
Date: Mon, 23 Apr 2012 08:29:09 -0700 (PDT)
From: William Mills 
To: Mike Jones , Blaine Cook ,  "apps-discuss@ietf.org" 
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1458549034-760143884-1335194949=:12040"
Subject: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD Issue #3: direct versus indirect discovery
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, 23 Apr 2012 15:29:20 -0000

--1458549034-760143884-1335194949=:12040
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I note that some examples are now using the construct (Eran called it a hac=
k, which it probably is, but I like it) host-meta.json to select the data f=
ormat.=C2=A0 This seems to me to be a workable way to:=0A=0A-=C2=A0=C2=A0=
=C2=A0 extend the current WF stuff keeping compatibility =0A=0A-=C2=A0=C2=
=A0=C2=A0 support for JSON without funky logic=0A-=C2=A0=C2=A0=C2=A0 allow =
the clients to implement a single simple code path=0A=0A-bill=0A=0A=0A=0A=
=0A>________________________________=0A> From: Mike Jones =0A>To: Blaine Cook ; "apps-discuss@ietf.org"=
  =0A>Sent: Sunday, April 22, 2012 9:11 PM=0A>Subjec=
t: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect disc=
overy=0A> =0A>=0A> =0A>I agree with your goal of simplicity for clients.=C2=
=A0 Paul=E2=80=99s example seems about as simple as it can get for clients:=
=0A>=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 curl -v https://packetizer.com/.well-known/host-meta.json?r=
esource=3Dacct:paulej@packetizer.com=0A>It shares the property with your ea=
rlier example (below) that clients have a no-branches code path to do disco=
very:=0A>=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 curl -s http://example.com/.well-known/host-meta|=0A>=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 awk "/lrdd/,/template/"|tr -d '\n'|sed -e "s/^.*template=3D'\([^']*\=
)'.*$/\1/"|=0A>=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 sed -e "s/{uri}/user@example.com/"|xargs curl =E2=
=80=93s=0A>=C2=A0=0A>However, I challenge the assumption in your note below=
 that servers using only static pages must be supported.=C2=A0 I just don=
=E2=80=99t see the requirement to implement a query parameter as being an i=
mpediment in practice, even for hosted domains.=C2=A0 I know of no hosting =
company that doesn=E2=80=99t provide a means of putting executable code beh=
ind web pages, be it PHP, Perl, Ruby, ASP, JSP, etc.=C2=A0 I know you=E2=80=
=99re trying to make the case for static pages, but in practice, I believe =
that dynamic pages are always easily available.=0A>=C2=A0=0A>Assuming that =
we=E2=80=99re in an either-or situation with regard to either having single=
-GET discovery or supporting discovery using only static server pages (and =
I=E2=80=99d love to have someone demonstrate to us that we=E2=80=99re not),=
 I=E2=80=99d take single-GET discovery for sure, as in some cases, it makes=
 an appreciable difference in user interface latency, and per the paragraph=
 above, I believe that dynamic queries can be implemented on all hosting pl=
atforms.=0A>=C2=A0=0A>Assuming the WebFinger authors agree, I=E2=80=99d sug=
gest that a logical next step would be for a -04 version of draft-jones-app=
sawg-webfinger to be published that changes support for the resource parame=
ter from RECOMMENDED to REQUIRED, as that could provide a starting point fo=
r a common discovery spec.=0A>=C2=A0=0A>=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=0A>=C2=A0 =0A>P.S.=C2=A0 As long as draft-jon=
es-appsawg-webfinger is being revised, I=E2=80=99d also suggest adding text=
 making explicit what has been an implicit assumption in both WebFinger and=
 SWD - that depending upon whether and how the client is authenticated, the=
 set of resources returned may vary (as Blaine had pointed out earlier).=C2=
=A0 That could help deal with some of the privacy perceptions.=0A>=C2=A0=0A=
>From:apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Blaine Cook=0A>Sent: Sunday, April 22, 2012 2:15 PM=0A>To: app=
s-discuss@ietf.org=0A>Subject: [apps-discuss] Webfinger / SWD Issue #3: dir=
ect versus indirect discovery=0A>=C2=A0=0A>This is the last issue that I've=
 flagged as blocking a new Webfinger / SWD draft.=0A>=C2=A0=0A>Mike suggest=
ed that being able to request a user's profile with a single request (i.e.,=
 that the /.well-known/ profile resource should be able to respond with ful=
l profile data immediately, rather than pointing at a second URL that will =
fulfil the request) is a requirement for this standard.=0A>=C2=A0=0A>I'd li=
ke to challenge that requirement. The arguments for a direct discovery endp=
oint are:=0A>=C2=A0=0A>1. Fewer requests against the server, since we save =
(in the worst-case) 50% of requests by bypassing the indirect lookup phase.=
=0A>2. Lower latency for clients (e.g., mobile clients) owing to the reduce=
d number of lookups.=0A>=C2=A0=0A>The arguments for an indirect discovery e=
ndpoint are:=0A>=C2=A0=0A>1. Trivial and web-standards friendly deployment =
for domains that won't host their own webfinger/swd profile servers, but wa=
nt to enable accounts on their domains (e.g., statically hosted sites).=0A>=
2. A loosening of the requirement that URLs at the bare domain must run dyn=
amic scripts that respond to requests to the /.well-known/ path.=0A>=C2=A0=
=0A>My opinion is that the approach that SWD has proposed for the redirect =
is problematic. First, the format is very similar in form to the HTML "meta=
 refresh" tag that provided HTTP redirect support from within HTML. That fo=
rmat has been widely deprecated, and in these more enlightened times, we ju=
st use the 3xx response codes with Location headers, instead.=0A>=C2=A0=0A>=
Secondly, the SWD request format means that for smaller sites, often those =
with the least resources, will end up serving static content in a way that'=
s difficult to cache; certainly, more difficult to cache than just serving =
static content. This is due to the request parameters present in all SWD re=
quests; those request parameters will bust caches.=0A>=C2=A0=0A>As for the =
first argument *for* SWD's approach, I'd suggest we look to DNS, which uses=
 the same indirection approach for NS records, relying on a (relatively) ve=
ry small set of root servers to handle the traffic for the whole internet. =
Clearly, this approach works, and webfinger/swd servers are in a much bette=
r position to handle this additional traffic. Most of this traffic will be =
heavily cached, especially for the largest providers.=0A>=C2=A0=0A>In fact,=
 in terms of real deployments, hosting a script at, e.g., google.com/.well-=
known/simple-web-discovery is much harder than hosting a script at profiles=
.google.com/profile.json for all sorts of reasons, so it's my belief that t=
he first argument is a red herring.=0A>=C2=A0=0A>The second argument is leg=
itimate, but only if mobile clients will actually be making requests to div=
erse webfinger/swd hosts. Instead, I strongly believe that we'll see the em=
ergence of DNS-like servers that provide both profile hosting as well as pr=
oxy services. For a mobile client, the optimal approach will be to use SPDY=
 to connect to a single host that performs webfinger/swd lookups on the mob=
ile client's behalf, eliminating the latency concerns.=0A>=C2=A0=0A>I offer=
 that the two-step lookup can be implemented without conditionals on the cl=
ient, whereas the direct-unless-not approach cannot be implemented that way=
 (see my earlier curl example for proof). It's simpler, and easier to expla=
in to the (hopefully many) small site owners who we'd like to implement thi=
s technology.=0A>=C2=A0=0A>Thoughts? Am I missing something?=0A>=C2=A0=0A>b=
.=0A>_______________________________________________=0A>apps-discuss mailin=
g list=0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/listinfo/ap=
ps-discuss=0A>=0A>=0A>
--1458549034-760143884-1335194949=:12040
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


I note that some examples are now using the construct (Eran called it a h=
ack, which it probably is, but I like it) host-meta.json to select the data=
 format.  This seems to me to be a workable way to:
<=
span>
-  &n=
bsp; extend the current WF stuff keeping compatibility 
-    =
support for JSON without funky logic
-<=
span class=3D"tab">    allow the clients to imp=
lement a single simple code path

-bill
<=
span>

  
 
 
  
  From:<=
/b> Mike Jones <Michael.Jones@microsoft.com>
 To: Blaine Cook <romeda@gmail.com>; "app=
s-discuss@ietf.org" <apps-discuss@ietf.org> 
 Sent: Sunday, April 22, 2012 9:11 PM
 Subject: Re: [apps-discuss] Web=
finger / SWD Issue #3: direct versus indirect discovery
  
 =

=0A=0A =0A =0A=0A=0A
=0A
=0A
I agree with your goal of simplicity=
 for clients.  Paul=E2=80=99s example seems about as simple as it can =
get for clients:
 =0A
     &=
nbsp;         curl -v=0A=0Ahttps://packetizer.com/=
.well-known/host-meta.json?resource=3Dacct:paulej@packetizer.com=

 =0A
It shares the property with your earlier example (belo=
w) that clients have a no-branches code path to do discovery:
 =
=0A
          &=
nbsp;    curl -s=0Ahttp://example.com/.well-=
known/host-meta|
 =0A
=
    &nb=
sp;          awk "/lrdd/,/temp=
late/"|tr -d '\n'|sed -e "s/^.*template=3D'\([^']*\)'.*$/\1/"|
=
 =0A
          =
     sed -e "s/{uri}/user@example.com/"|xargs curl =E2=
=80=93s
 =0A
  
 =0A
How=
ever, I challenge the assumption in your note below that servers using only=
 static pages must be supported. =0AI just don=E2=80=99t see the requirement to implement =
a query parameter as being an impediment in practice, even for hosted domai=
ns.  I know of no hosting company that doesn=E2=80=99t provide=0A a me=
ans of putting executable code behind web pages, be it PHP, Perl, Ruby, ASP=
, JSP, etc.  I know you=E2=80=99re trying to make the case for static =
pages, but in practice, I believe that dynamic pages are always easily avai=
lable.
 =0A
  
 =0A
Assumi=
ng that we=E2=80=99re in an either-or situation with regard to either havin=
g single-GET discovery or supporting discovery using only static server pag=
es (and=0A I=E2=80=99d love to have someone demonstrate to us that we=E2=80=
=99re not), I=E2=80=99d take single-GET discovery for sure, as in some case=
s, it makes an appreciable difference in user interface latency, and per th=
e paragraph above, I believe that dynamic queries can be implemented=0A on =
all hosting platforms.
 =0A
  
 =0A<=
div class=3D"yiv1747085369MsoNormal">Assuming the WebFinger authors agree, I=E2=80=99d suggest that a =
logical next step would be for a -04 version of draft-jones-appsawg-webfing=
er to be published that=0A changes support for the resource parameter from =
RECOMMENDED to REQUIRED, as that could provide a starting point for a commo=
n discovery spec.
 =0A
  
 =0A
           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;          -- Mike<=
/div> =0A
 =0A
 =0A
P.S.  As long=
 as draft-jones-appsawg-webfinger is being revised, I=E2=80=99d also sugges=
t adding text making explicit what has been an implicit assumption in both =
WebFinger=0A and SWD - that depending upon whether and how the client is au=
thenticated, the set of resources returned may vary (as Blaine had pointed =
out earlier).  That could help deal with some of the privacy perceptio=
ns.
 =0A
  
 =0A
From: apps-discuss-bounces@ietf.org [mailto:apps-d=
iscuss-bounces@ietf.org]=0AOn Behalf Of Blaine Cook
=0ASent: Sunday, April 22, 2012 2:15 PM
=0ATo: apps-discuss@ietf.org=0ASubject: [apps-discuss] Webfinger / SWD Issue #3: direct versus =
indirect discovery
 =0A
 &=
nbsp;
 =0A
This is the last issue=
 that I've flagged as blocking a new Webfinger / SWD draft.
 =0A
=
=0A
  
 =0A
=0A
=0A=

Mike suggested that being able to req=
uest a user's profile with a single request (i.e., that the /.well-known/ p=
rofile resource should be able to respond with full profile data immediatel=
y, rather than pointing at a second URL that will=0A fulfil the request) is=
 a requirement for this standard.
 =0A
=0A
=0A
  
 =0A
=0A
=0A
I'd like to challenge that requirement. The arguments f=
or a direct discovery endpoint are:
 =0A
=0A
=0A
  
 =0A
=0A
=0A
1. Fewer requests against the server, since we save (=
in the worst-case) 50% of requests by bypassing the indirect lookup phase.<=
/div> =0A
=0A
=0A
2. Lower la=
tency for clients (e.g., mobile clients) owing to the reduced number of loo=
kups.
 =0A
=0A
=0A
 &nbs=
p;
 =0A
=0A
=0A
The argu=
ments for an indirect discovery endpoint are:
 =0A
=0A
=0A  
 =0A
=0A
=0A
1. Trivial and web-standards friendly deplo=
yment for domains that won't host their own webfinger/swd profile servers, =
but want to enable accounts on their domains (e.g., statically hosted sites=
).
 =0A
=0A
=0A
2. A loo=
sening of the requirement that URLs at the bare domain must run dynamic scr=
ipts that respond to requests to the /.well-known/ path.
 =0A
=0A=

=0A
  
 =0A
=0A=0A
My opinion is that the approach =
that SWD has proposed for the redirect is problematic. First, the format is=
 very similar in form to the HTML "meta refresh" tag that provided HTTP red=
irect support from within HTML. That format has been widely=0A deprecated, =
and in these more enlightened times, we just use the 3xx response codes wit=
h Location headers, instead.
 =0A
=0A
=0A
  
 =0A
=0A
=0A
Secondly, the SWD request format means that for smaller site=
s, often those with the least resources, will end up serving static content=
 in a way that's difficult to cache; certainly, more difficult to cache tha=
n just serving static content.=0A This is due to the request parameters pre=
sent in all SWD requests; those request parameters will bust caches.
 =
=0A
=0A
=0A
  
 =0A=

=0A
=0A
As for the first arg=
ument *for* SWD's approach, I'd suggest we look to DNS, which uses the same=
 indirection approach for NS records, relying on a (relatively) very small =
set of root servers to handle the traffic for the whole internet.=0A Clearl=
y, this approach works, and webfinger/swd servers are in a much better posi=
tion to handle this additional traffic. Most of this traffic will be heavil=
y cached, especially for the largest providers.
 =0A
=0A
=0A<=
div class=3D"yiv1747085369MsoNormal">  
 =0A
=0A
=0AIn fact, in terms of real deployments, ho=
sting a script at, e.g.,=0Agoogle.com/.well-known/si=
mple-web-discovery is much harder than hosting a script at=0Aprofiles.google.com/profile.json for all sorts of reasons, so it's my=
 belief that the first argument is a red herring.
 =0A
=0A
=
=0A
  
 =0A
=0A
=0A=

The second argument is legitimate, bu=
t only if mobile clients will actually be making requests to diverse webfin=
ger/swd hosts. Instead, I strongly believe that we'll see the emergence of =
DNS-like servers that provide both profile hosting=0A as well as proxy serv=
ices. For a mobile client, the optimal approach will be to use SPDY to conn=
ect to a single host that performs webfinger/swd lookups on the mobile clie=
nt's behalf, eliminating the latency concerns.
 =0A
=0A
=0A  
 =0A
=0A
=0A
I offer that the two-step lookup can be im=
plemented without conditionals on the client, whereas the direct-unless-not=
 approach cannot be implemented that way (see my earlier curl example for p=
roof). It's simpler, and easier to explain to=0A the (hopefully many) small=
 site owners who we'd like to implement this technology.
 =0A
=0A=

=0A
  
 =0A
=0A=0A
Thoughts? Am I missing something=
?
 =0A
=0A
=0A
   =0A
=0A
=0A
b.
 =0A=

=0A
=0A
=0A=0A

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

<=
br> 
 
    
--1458549034-760143884-1335194949=:12040--

From ve7jtb@ve7jtb.com  Mon Apr 23 09:19: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 5EBE621F8734 for ; Mon, 23 Apr 2012 09:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.533
X-Spam-Level: 
X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.065,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQwaV-PiEb1f for ; Mon, 23 Apr 2012 09:19:33 -0700 (PDT)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5D05421F8741 for ; Mon, 23 Apr 2012 09:19:33 -0700 (PDT)
Received: by qafi31 with SMTP id i31so2102447qaf.15 for ; Mon, 23 Apr 2012 09:19:32 -0700 (PDT)
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=CBxzFjgKOCjEf8bNvp/gMgU/FOeYB8NWTfB4M7zK71I=; b=jbws2ljlhRJPBGG4i/obSUNWvRxDxIsu76m7QyWdQN4xqNhtzQ7d8tfRQ7id5ssBYU gQqmMGIeuPTSaDXWWSFZn1ILrlxOnF7sOba4+yxZmG/BSKInVsfk9D5WBrGQnSMmCGFg ZGtkmeP+GqGxJofxN6FQaZtHUdU79gYzmlHynis0WxAiH7JkRzVkLfYSmbxC/on4K1GY ufM6gqDr+xnI26v3yXbdzqkj3EPcZcWBFI78GPiscM+urqLzyFNwkA/zO5cBbHMzEKl7 mvxVJJgibf01mhsPx5NV9jjmr82JOtgLp1Y/ktdZU5iAOVFcSYVSmGuw0+3hp+ume5JO 2Qag==
Received: by 10.229.135.21 with SMTP id l21mr4389334qct.1.1335197971446; Mon, 23 Apr 2012 09:19:31 -0700 (PDT)
Received: from [192.168.1.213] (190-20-21-61.baf.movistar.cl. [190.20.21.61]) by mx.google.com with ESMTPS id gw8sm22361682qab.7.2012.04.23.09.19.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 09:19:30 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_818684B6-0A02-433B-86A4-25CE470D9963"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: 
Date: Mon, 23 Apr 2012 13:19:21 -0300
Message-Id: <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com> 
To: Bob Wyman 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQmA+5Iynepex38PI0LaaF7qZ0SRmf1fTFQve/QUxULb4+XfCTArqNVvi4KJnAzzc1HEEZDz
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 16:19:35 -0000

--Apple-Mail=_818684B6-0A02-433B-86A4-25CE470D9963
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_1B9B681E-A2BE-496E-9A9D-6F4B577A526A"


--Apple-Mail=_1B9B681E-A2BE-496E-9A9D-6F4B577A526A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I understand that in some environments you may not have access to http =
rewrite rules. =20
Others may preclude any scripts.

We do have to decide what environments we are going to support.

If we stick to static files only then we are just putting some lipstick =
on Yadis by adding a way to map a email like address to a file.

So yes there are those environments, but that needs to be balanced =
against the additional overhead on the clients to support that =
environment.

John B.

On 2012-04-23, at 12:26 PM, Bob Wyman wrote:

>=20
>=20
> On Mon, Apr 23, 2012 at 11:08 AM, John Bradley  =
wrote:
> Mike,
>=20
> I think there is less resistance to making resource parameter REQUIRED =
than there is to removing the initial host-meta lookup to get the =
template.
>=20
> We should probably keep those issues separate.
>=20
> I agree that supporting indirect discovery of the template via =
host-meta.jason should probably stay.
>=20
> The question is if their can be an optimization that allows =
shortcutting that step if you know that all you want is web finger.
>=20
> A possible option for that could be using a fixed template in =
/.well-known/.
>=20
> That endpoint would return:
> a The terminal JRD (like SWD)
> b a 3xx redirect to the real endpoint
> Causing a 3xx redirect typically requires modification to the =
configuration files of a multi-host shared web server. Access to such =
configuration files is often restricted in such a way that those =
responsible from just one or a few of the sites sharing the common =
server are not permitted to make modifications to those files. In many =
cases, such modifications can be requested and will only be made after =
lengthy delays or the payment of support and maintenance fees.=20
>=20
> If we want this sort of discovery to become generally available, and =
not just be limited to the "large" sites, we should ensure that it is as =
simple as possible to deploy.
> =20
> c a copy of the host-meta.jrd
>=20
> We would probably only do one of b or c.
>=20
> c has the advantage of being a static file and you being no worse off =
than having started with host-meta.json.
> b is the simplest for the client and only requires common rewriting =
rules.
>=20
> If the redirect is to the same host you could avoid the overhead of =
two connections by pipelining the requests over the same TCP connection.
> SPDY in the future will make that even more efficient.
>=20
> I will grant Blaine that most openID Connect discovery requests are =
Server to Server,  However there are Apps that are also clients that =
should not be ignored.
> I personally like the fixed template with a 3xx redirect and  resource =
parameter returning a JRD due to the simplicity of client coding.
>=20
> Things needing other sorts of information about the host would still =
use host-meta or host-meta.json.
>=20
> John B.
>=20
>=20
> On 2012-04-23, at 1:11 AM, Mike Jones wrote:
>=20
>> I agree with your goal of simplicity for clients.  Paul=92s example =
seems about as simple as it can get for clients:
>>                curl -v =
https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paulej@p=
acketizer.com
>> It shares the property with your earlier example (below) that clients =
have a no-branches code path to do discovery:
>>                curl -s http://example.com/.well-known/host-meta|
>>                awk "/lrdd/,/template/"|tr -d '\n'|sed -e =
"s/^.*template=3D'\([^']*\)'.*$/\1/"|
>>                sed -e "s/{uri}/user@example.com/"|xargs curl =96s
>> =20
>> However, I challenge the assumption in your note below that servers =
using only static pages must be supported.  I just don=92t see the =
requirement to implement a query parameter as being an impediment in =
practice, even for hosted domains.  I know of no hosting company that =
doesn=92t provide a means of putting executable code behind web pages, =
be it PHP, Perl, Ruby, ASP, JSP, etc.  I know you=92re trying to make =
the case for static pages, but in practice, I believe that dynamic pages =
are always easily available.
>> =20
>> Assuming that we=92re in an either-or situation with regard to either =
having single-GET discovery or supporting discovery using only static =
server pages (and I=92d love to have someone demonstrate to us that =
we=92re not), I=92d take single-GET discovery for sure, as in some =
cases, it makes an appreciable difference in user interface latency, and =
per the paragraph above, I believe that dynamic queries can be =
implemented on all hosting platforms.
>> =20
>> Assuming the WebFinger authors agree, I=92d suggest that a logical =
next step would be for a -04 version of draft-jones-appsawg-webfinger to =
be published that changes support for the resource parameter from =
RECOMMENDED to REQUIRED, as that could provide a starting point for a =
common discovery spec.
>> =20
>>                                                             -- Mike
>> =20
>> P.S.  As long as draft-jones-appsawg-webfinger is being revised, I=92d =
also suggest adding text making explicit what has been an implicit =
assumption in both WebFinger and SWD - that depending upon whether and =
how the client is authenticated, the set of resources returned may vary =
(as Blaine had pointed out earlier).  That could help deal with some of =
the privacy perceptions.
>> =20
>> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of Blaine Cook
>> Sent: Sunday, April 22, 2012 2:15 PM
>> To: apps-discuss@ietf.org
>> Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus =
indirect discovery
>> =20
>> This is the last issue that I've flagged as blocking a new Webfinger =
/ SWD draft.
>> =20
>> Mike suggested that being able to request a user's profile with a =
single request (i.e., that the /.well-known/ profile resource should be =
able to respond with full profile data immediately, rather than pointing =
at a second URL that will fulfil the request) is a requirement for this =
standard.
>> =20
>> I'd like to challenge that requirement. The arguments for a direct =
discovery endpoint are:
>> =20
>> 1. Fewer requests against the server, since we save (in the =
worst-case) 50% of requests by bypassing the indirect lookup phase.
>> 2. Lower latency for clients (e.g., mobile clients) owing to the =
reduced number of lookups.
>> =20
>> The arguments for an indirect discovery endpoint are:
>> =20
>> 1. Trivial and web-standards friendly deployment for domains that =
won't host their own webfinger/swd profile servers, but want to enable =
accounts on their domains (e.g., statically hosted sites).
>> 2. A loosening of the requirement that URLs at the bare domain must =
run dynamic scripts that respond to requests to the /.well-known/ path.
>> =20
>> My opinion is that the approach that SWD has proposed for the =
redirect is problematic. First, the format is very similar in form to =
the HTML "meta refresh" tag that provided HTTP redirect support from =
within HTML. That format has been widely deprecated, and in these more =
enlightened times, we just use the 3xx response codes with Location =
headers, instead.
>> =20
>> Secondly, the SWD request format means that for smaller sites, often =
those with the least resources, will end up serving static content in a =
way that's difficult to cache; certainly, more difficult to cache than =
just serving static content. This is due to the request parameters =
present in all SWD requests; those request parameters will bust caches.
>> =20
>> As for the first argument *for* SWD's approach, I'd suggest we look =
to DNS, which uses the same indirection approach for NS records, relying =
on a (relatively) very small set of root servers to handle the traffic =
for the whole internet. Clearly, this approach works, and webfinger/swd =
servers are in a much better position to handle this additional traffic. =
Most of this traffic will be heavily cached, especially for the largest =
providers.
>> =20
>> In fact, in terms of real deployments, hosting a script at, e.g., =
google.com/.well-known/simple-web-discovery is much harder than hosting =
a script atprofiles.google.com/profile.json for all sorts of reasons, so =
it's my belief that the first argument is a red herring.
>> =20
>> The second argument is legitimate, but only if mobile clients will =
actually be making requests to diverse webfinger/swd hosts. Instead, I =
strongly believe that we'll see the emergence of DNS-like servers that =
provide both profile hosting as well as proxy services. For a mobile =
client, the optimal approach will be to use SPDY to connect to a single =
host that performs webfinger/swd lookups on the mobile client's behalf, =
eliminating the latency concerns.
>> =20
>> I offer that the two-step lookup can be implemented without =
conditionals on the client, whereas the direct-unless-not approach =
cannot be implemented that way (see my earlier curl example for proof). =
It's simpler, and easier to explain to the (hopefully many) small site =
owners who we'd like to implement this technology.
>> =20
>> Thoughts? Am I missing something?
>> =20
>> b.
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
>=20


--Apple-Mail=_1B9B681E-A2BE-496E-9A9D-6F4B577A526A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I =
understand that in some environments you may not have access to http =
rewrite rules.  
Others may preclude any =
scripts.

We do have to decide what environments =
we are going to support.

If we stick to static =
files only then we are just putting some lipstick on Yadis by adding a =
way to map a email like address to a file.

So =
yes there are those environments, but that needs to be balanced against =
the additional overhead on the clients to support that =
environment.

John B.
=

--Apple-Mail=_1B9B681E-A2BE-496E-9A9D-6F4B577A526A--

--Apple-Mail=_818684B6-0A02-433B-86A4-25CE470D9963
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
MzE2MTkyMlowIwYJKoZIhvcNAQkEMRYEFHA2CkmdWoRcOWTIKUCXAcwMlVyoMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
ADvxiNbbAJyIBjRjIdgLl0Dk2+MEFkaU0NSrHPWXiKxXdrjREh0n3HJJRTR/EjzTlm6nmXFdQtht
XjxEqZdojaGLnFrW/9JgMtdMOvedG3gp+gLY/mB8BvApWaVWd5xMJgOriPpAbHi4mBTNIGVbC7aZ
+Z9QHYNOBNKIYxZLISOru6whxVvQChipipkjX6HMGPohvMByLqhei6jzTc7FtmLRLYOLUNNuJ+l7
M5iiXJd2RjRTSruWlC1UD6ebOsHwdHi7yrEODo9QFI3Whks9fZTuEjiQ4ODcJn7E+M5p+6mK4dtu
D8/fmF1zMCUz/cRPv8Mgi9B3pO4NYu0zNTi5Kg4AAAAAAAA=

--Apple-Mail=_818684B6-0A02-433B-86A4-25CE470D9963--

From ted.ietf@gmail.com  Mon Apr 23 09:23: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 EAC8E21F8763 for ; Mon, 23 Apr 2012 09:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.556
X-Spam-Level: 
X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxDwUFvkSb0j for ; Mon, 23 Apr 2012 09:23:32 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 042D121F875B for ; Mon, 23 Apr 2012 09:23:28 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so9635657vbb.31 for ; Mon, 23 Apr 2012 09:23:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=cSIHFOrpdj5XcMPpqy5IHuU1gL+yRFghl+CvCB1/k6g=; b=pNeVMMgy+uoWFksrdAsscukem3ULnenEr9Fbc88C3KlPveaSVTbfwlyrEbp20xeEyR t6+mGs3W/f4qsxaqmydMcchkJq/EgIhN3YYuGAK2A+IzbfSTT153IuvFQaIo3Uyy7X0f QGRSZaQNXmP2BKevY2DVmrK5erEEQFfNcF4egGunxkJHI/k3GLnEiXEsEIeEtHx6hmTD ROLprV+tOarBMZ6kBDuFrwISed4G7iktAxptlyhLWuMGybi3Zwbv6tDheEA9i2JOdXTT BCczmQdnifze5FRlivJa/xkc1AfAozyK7MF1zcct0O0LpZA6SQxPBB1KeZSuKsE6ySKZ jvrQ==
MIME-Version: 1.0
Received: by 10.220.230.67 with SMTP id jl3mr6274576vcb.50.1335198208431; Mon, 23 Apr 2012 09:23:28 -0700 (PDT)
Received: by 10.52.162.99 with HTTP; Mon, 23 Apr 2012 09:23:28 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 23 Apr 2012 09:23:28 -0700
Message-ID: 
From: Ted Hardie 
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: [apps-discuss] Fwd: Review of draft-ietf-eai-simpledowngrade-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, 23 Apr 2012 16:23:35 -0000

Apologies; I forgot to cc this list on the review.

regards,

Ted


---------- Forwarded message ----------
From: Ted Hardie 
Date: Mon, Apr 23, 2012 at 8:57 AM
Subject: Review of draft-ietf-eai-simpledowngrade-03
To: draft-ietf-eai-simpledowngrade.all@tools.ietf.org
Cc: IESG 


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:
Title: EAI: Simplified POP/IMAP downgrading
Reviewer: Ted Hardie
Review Date: April 23, 2012

Summary: I believe that the draft is almost ready for publication, but
that it cannot be progressed on the standards track because of its
impact on the security of the email messages. =A0I understand the
reluctance of the WG to create Experimental documents at this stage,
so I suggest Informational as a target status.

Major Issues:

The document is clear that its intent is to provide a
simple-to-implement method that provides basic means for downgrading
certain fields in a message. =A0 A major element of its strategy is to
silently excise information which cannot be presented to the user.
This may eliminate MIME parameters (see section 2.2); it may also
eliminate any header field not explicitly treated (the subject field
and those listed in 2.1). =A0This, combined with the possible invalidity
of signatures for signed body parts, can significantly reduce the
amount of data available to the user for making a determination of
whether or not a message is legitimate. =A0Crafting a message that
appeared to have already gone through this encoding also seems
relatively easy, making it possible for a sender to provide a message
that does not have the normal complement of data for assessment by a
user.

Given this major loss of information, I do not believe that this
document describes an approach that should be placed on the standards
track; if the working group believes this to be valuable, it should be
delivered as informational. =A0This seems also to be a better fit for
the loose interoperablity strategy here:

"The format of the display-name is explicitly unspecified. Anything
=A0 which tells the user what happened is good. Anything which produces
=A0 an email address which might belong to someone else is bad."

Minor Issues:

The document does not describe how it relates to the other two options
the working group has discussed for downgrade. =A0I believe it should do
so in order to provide context for the choices made here. =A0A review of
the mailing list shows this message:
http://www.ietf.org/mail-archive/web/ima/current/msg04539.html as
kicking off the core rationale and relationship. =A0 Some form of this
should be included in the document, possibly along with the "no
downgrade" option.

This document does not describe how the IMAP/POP downgrade choices
here would impact SIEVE script processing; I believe this represents
an assumption on when the downgrade takes place which should be made
explicit.

Nits:

The document says:

=A0 Given an internationalized address "Fred Foo ", an
=A0 implementation may choose to render it e.g. as these examples:

"render" is seriously overloaded in this context. =A0Would "encode" work
as well here?

From fluffy@iii.ca  Mon Apr 23 10:29: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 9124621F859A for ; Mon, 23 Apr 2012 10:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.975
X-Spam-Level: 
X-Spam-Status: No, score=-2.975 tagged_above=-999 required=5 tests=[AWL=0.580,  BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGLcg3F8LeyC for ; Mon, 23 Apr 2012 10:29:07 -0700 (PDT)
Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 0582A21F8734 for ; Mon, 23 Apr 2012 10:29:06 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 4E34C2FDC5D for ; Mon, 23 Apr 2012 13:29:00 -0400 (EDT)
Received: from sjc-vpn7-1727.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7353F22E25E; Mon, 23 Apr 2012 13:28:59 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings 
In-Reply-To: <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>
Date: Mon, 23 Apr 2012 06:57:00 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>
To: Zach Shelby 
X-Mailer: Apple Mail (2.1257)
Cc: "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Apr 2012 17:29:08 -0000

So what was the summary of the discussion on this? Other than clarifying =
draft-ietf-appsawg-media-type-regs, anything decided? Any changes I need =
to make to senml registrations?

On Mar 29, 2012, at 13:52 , Zach Shelby wrote:

> I have posted a new version of the +exi registration draft. This =
version improves the Interoperability considerations of the registration =
requirements and further clarifies when this suffix may be used, as per =
the feedback on the list from Carine and others.
>=20
> http://www.ietf.org/id/draft-shelby-exi-registration-01.txt
>=20
> Regards,
> Zach
>=20
> Begin forwarded message:
>=20
>> From: internet-drafts@ietf.org
>> Date: March 29, 2012 10:47:32 PM GMT+02:00
>> To: zach@sensinode.com
>> Subject: New Version Notification for =
draft-shelby-exi-registration-01.txt
>>=20
>> A new version of I-D, draft-shelby-exi-registration-01.txt has been =
successfully submitted by Zach Shelby and posted to the IETF repository.
>>=20
>> Filename:	 draft-shelby-exi-registration
>> Revision:	 01
>> Title:		 The +exi Media Type Suffix
>> Creation date:	 2012-03-29
>> WG ID:		 Individual Submission
>> Number of pages: 5
>>=20
>> Abstract:
>> Efficient XML Interchange (EXI) is an XML representation technique
>> specified by the W3C to provie a binary alternative to the standard
>> text XML representation.  This document defines a new Structure
>> Syntax Suffix "+exi" for use in a specific class of =
protocols, where
>> "exi" content-type encoding or the generic =
"application/exi" Media
>> Type are not applicable.
>>=20
>>=20
>>=20
>>=20
>> The IETF Secretariat
>=20
> --=20
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://www.sensinode.com
> http://zachshelby.org  - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From julian.reschke@gmx.de  Mon Apr 23 11:00: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 E31A021F85A4 for ; Mon, 23 Apr 2012 11:00:08 -0700 (PDT)
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=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6C6KuSAoMwPB for ; Mon, 23 Apr 2012 11:00:08 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 922A521F854D for ; Mon, 23 Apr 2012 11:00:07 -0700 (PDT)
Received: (qmail invoked by alias); 23 Apr 2012 18:00:05 -0000
Received: from 178-83-198-62.dynamic.hispeed.ch (EHLO [192.168.1.103]) [178.83.198.62] by mail.gmx.net (mp038) with SMTP; 23 Apr 2012 20:00:05 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19z0CE9iEBz0ONK4pe/8vDGqA4wdHAzJ95OoIPYXr mKCS67rzu5AlGC
Message-ID: <4F95691E.3020800@gmx.de>
Date: Mon, 23 Apr 2012 16:37:18 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Simon Perreault 
References: <4F955991.2080606@viagenie.ca>
In-Reply-To: <4F955991.2080606@viagenie.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "apps-discuss@ietf.org" , draft-ietf-appsawg-mime-default-charset@tools.ietf.org
Subject: Re: [apps-discuss] Default charset in vCard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 18:00:09 -0000

On 2012-04-23 15:30, Simon Perreault wrote:
> Hi,
>
> I took at look at draft-ietf-appsawg-mime-default-charset-03 to compare
> against what we have in vCard 4.

Ack.

> In vCard 4, we basically say two things:
> http://tools.ietf.org/html/rfc6350#section-3.1
>
> 1. The charset is always UTF-8.

As far as I can tell, that's not in-line with RFC 2046 which defines the 
default to be US-ASCII.

> 2. If you use the charset parameter, it MUST be UTF-8.
>
> It looks like it goes against the recommendation in your draft:
>
> a. specify that the "charset" parameter is not used for the defined
> subtype, because the charset information is transported inside
> the payload (such as in "text/xml"), or
> b. require explicit unconditional inclusion of the "charset"
> parameter eliminating the need for a default value.
> [...]
> New subtypes of the "text" media type, thus, SHOULD NOT define a
> default "charset" value. If there is a strong reason to do so
> despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as
> the default.
>
> So, two questions:
>
> - Am I reading this right? Is there actually a conflict?

I wouldn't call it a conflict. We just changed the defaults for new 
registrations. That doesn't change existing ones.

> - Should this be fixed eventually in a vCard 4 bis?

You could, if that doesn't result in an incompatible change.

As far as I can tell, with

 > 1. The charset is always UTF-8.

you were already outside what RFC 2046 says, and close to what the new 
recommendation is...

Best regards, Julian

From stpeter@stpeter.im  Mon Apr 23 11: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 2F2F621F860B for ; Mon, 23 Apr 2012 11:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.61
X-Spam-Level: 
X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92h1++5ECAUr for ; Mon, 23 Apr 2012 11:03:56 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5AE21F8608 for ; Mon, 23 Apr 2012 11:03:56 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8F1D740058; Mon, 23 Apr 2012 12:18:25 -0600 (MDT)
Message-ID: <4F95998A.9040608@stpeter.im>
Date: Mon, 23 Apr 2012 12:03:54 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Julian Reschke 
References: <4F955991.2080606@viagenie.ca> <4F95691E.3020800@gmx.de>
In-Reply-To: <4F95691E.3020800@gmx.de>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" , draft-ietf-appsawg-mime-default-charset@tools.ietf.org
Subject: Re: [apps-discuss] Default charset in vCard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 18:03:57 -0000

On 4/23/12 8:37 AM, Julian Reschke wrote:
> On 2012-04-23 15:30, Simon Perreault wrote:
>> Hi,
>>
>> I took at look at draft-ietf-appsawg-mime-default-charset-03 to compare
>> against what we have in vCard 4.
> 
> Ack.
> 
>> In vCard 4, we basically say two things:
>> http://tools.ietf.org/html/rfc6350#section-3.1
>>
>> 1. The charset is always UTF-8.
> 
> As far as I can tell, that's not in-line with RFC 2046 which defines the
> default to be US-ASCII.
> 
>> 2. If you use the charset parameter, it MUST be UTF-8.
>>
>> It looks like it goes against the recommendation in your draft:
>>
>> a. specify that the "charset" parameter is not used for the defined
>> subtype, because the charset information is transported inside
>> the payload (such as in "text/xml"), or
>> b. require explicit unconditional inclusion of the "charset"
>> parameter eliminating the need for a default value.
>> [...]
>> New subtypes of the "text" media type, thus, SHOULD NOT define a
>> default "charset" value. If there is a strong reason to do so
>> despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as
>> the default.
>>
>> So, two questions:
>>
>> - Am I reading this right? Is there actually a conflict?
> 
> I wouldn't call it a conflict. We just changed the defaults for new
> registrations. That doesn't change existing ones.
> 
>> - Should this be fixed eventually in a vCard 4 bis?
> 
> You could, if that doesn't result in an incompatible change.
> 
> As far as I can tell, with
> 
>> 1. The charset is always UTF-8.
> 
> you were already outside what RFC 2046 says, and close to what the new
> recommendation is...

Agreed, and that's a good place to be (defaulting to ASCII at this point
seems more than a bit old-fashioned).

Peter

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



From bobwyman@gmail.com  Mon Apr 23 11:09: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 15F8321F863D for ; Mon, 23 Apr 2012 11:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level: 
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[AWL=0.267,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNOZt73GsbC7 for ; Mon, 23 Apr 2012 11:09:56 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1058821F8619 for ; Mon, 23 Apr 2012 11:09:56 -0700 (PDT)
Received: by yenm5 with SMTP id m5so7356162yen.31 for ; Mon, 23 Apr 2012 11:09:55 -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=gg72+ckgB54gl1i1YmWjO25lv7AMpv/67mmtE8/qbZk=; b=rbs6jbZQMqb+NfGIzNVsa8HpM4sGp5D/kH/koRP74TL1jKbTDUddQySERsUY7ikQrO NEh27FURYpJergqP2VCcB8qGRVc0c1cEcyffZBWwKg2Jo3e6xYawbawV1+cb+9KcJh0a ba7Q9Vq8RLU1bOaMvyA3XhvIIiiOil2zK8QFAWc7C73AuWmPxofpSmTWlpS1MM+1Anie bKHY4IBzKPp//fjBYVv2rbAxASxLMREpT5vVNFa4+hI2NE4DDRLE2w2YIMnE5QmsarP3 xZ3hPYRbRyvv0N7j1JiJ1IH+4DVGkgZlCQVoSh7BCvY1jQKS8uhiQdmTONhyjCiM6snX VKPw==
MIME-Version: 1.0
Received: by 10.101.151.34 with SMTP id d34mr9790ano.19.1335204595624; Mon, 23 Apr 2012 11:09:55 -0700 (PDT)
Sender: bobwyman@gmail.com
Received: by 10.147.76.15 with HTTP; Mon, 23 Apr 2012 11:09:55 -0700 (PDT)
In-Reply-To: <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com>
Date: Mon, 23 Apr 2012 14:09:55 -0400
X-Google-Sender-Auth: V8YXylsp3hvgW7hpVHuREgsTO7U
Message-ID: 
From: Bob Wyman 
To: John Bradley 
Content-Type: multipart/alternative; boundary=001636c5bdcd9fea1104be5c8b96
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 18:09:58 -0000

--001636c5bdcd9fea1104be5c8b96
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 23, 2012 at 12:19 PM, John Bradley  wrote:

> I understand that in some environments you may not have access to http
> rewrite rules.
> Others may preclude any scripts.
>
> We do have to decide what environments we are going to support.
>
> If we stick to static files only then we are just putting some lipstick o=
n
> Yadis by adding a way to map a email like address to a file.
>
> So yes there are those environments, but that needs to be balanced agains=
t
> the additional overhead on the clients to support that environment.
>

Yes, of course. We must seek a balance. What have I missed in the following
attempt to balance the proposals?

If we adopt a solution that can't be implemented with static files, then:

   - Positive: Clients which seek only one or two bits of specific
   information may experience less "overhead."
   - Negative: Clients that seek all or many bits of available information
   would experience more overhead.
   - Negative: Many sites that could otherwise provide WebFinger support
   will not be able to.

I guess the question is: "How should we weight the positive against the
negatives?" Personally, I would suggest that the negatives outweigh
(out-balances?) the positive. I believe that is why, for the many years
that WebFinger has been under discussion, that the majority of discussions
have assumed that static files would be sufficient.

bob wyman


>
> John B.
>
> On 2012-04-23, at 12:26 PM, Bob Wyman wrote:
>
>
>
> On Mon, Apr 23, 2012 at 11:08 AM, John Bradley  wrote:
>
>> Mike,
>>
>> I think there is less resistance to making resource parameter REQUIRED
>> than there is to removing the initial host-meta lookup to get the templa=
te.
>>
>> We should probably keep those issues separate.
>>
>> I agree that supporting indirect discovery of the template via
>> host-meta.jason should probably stay.
>>
>> The question is if their can be an optimization that allows shortcutting
>> that step if you know that all you want is web finger.
>>
>> A possible option for that could be using a fixed template in /
>> .well-known/.
>>
>> That endpoint would return:
>> a The terminal JRD (like SWD)
>> b a 3xx redirect to the real endpoint
>>
> Causing a 3xx redirect typically requires modification to the
> configuration files of a multi-host shared web server. Access to such
> configuration files is often restricted in such a way that those
> responsible from just one or a few of the sites sharing the common server
> are not permitted to make modifications to those files. In many cases, su=
ch
> modifications can be requested and will only be made after lengthy delays
> or the payment of support and maintenance fees.
>
> If we want this sort of discovery to become generally available, and not
> just be limited to the "large" sites, we should ensure that it is as simp=
le
> as possible to deploy.
>
>
>> c a copy of the host-meta.jrd
>>
>> We would probably only do one of b or c.
>>
>> c has the advantage of being a static file and you being no worse off
>> than having started with host-meta.json.
>> b is the simplest for the client and only requires common rewriting rule=
s.
>>
>> If the redirect is to the same host you could avoid the overhead of two
>> connections by pipelining the requests over the same TCP connection.
>> SPDY in the future will make that even more efficient.
>>
>> I will grant Blaine that most openID Connect discovery requests are
>> Server to Server,  However there are Apps that are also clients that sho=
uld
>> not be ignored.
>> I personally like the fixed template with a 3xx redirect and  resource
>> parameter returning a JRD due to the simplicity of client coding.
>>
>> Things needing other sorts of information about the host would still use
>> host-meta or host-meta.json.
>>
>> John B.
>>
>>
>> On 2012-04-23, at 1:11 AM, Mike Jones wrote:
>>
>> I agree with your goal of simplicity for clients.  Paul=92s example seem=
s
>> about as simple as it can get for clients:****
>>                curl -v
>> https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paulej=
@packetizer.com
>> ****
>> It shares the property with your earlier example (below) that clients
>> have a no-branches code path to do discovery:****
>>                curl -s http://example.com/.well-known/host-meta|****
>>                awk "/lrdd/,/template/"|tr -d '\n'|sed -e
>> "s/^.*template=3D'\([^']*\)'.*$/\1/"|****
>>                sed -e "s/{uri}/user@example.com/"|xargs curl =96s****
>> ** **
>> However, I challenge the assumption in your note below that servers usin=
g
>> only static pages must be supported.  I just don=92t see the requirement
>> to implement a query parameter as being an impediment in practice, even =
for
>> hosted domains.  I know of no hosting company that doesn=92t provide a m=
eans
>> of putting executable code behind web pages, be it PHP, Perl, Ruby, ASP,
>> JSP, etc.  I know you=92re trying to make the case for static pages, but=
 in
>> practice, I believe that dynamic pages are always easily available.****
>> ** **
>> Assuming that we=92re in an either-or situation with regard to either
>> having single-GET discovery or supporting discovery using only static
>> server pages (and I=92d love to have someone demonstrate to us that we=
=92re
>> not), I=92d take single-GET discovery for sure, as in some cases, it mak=
es an
>> appreciable difference in user interface latency, and per the paragraph
>> above, I believe that dynamic queries can be implemented on all hosting
>> platforms.****
>> ** **
>> Assuming the WebFinger authors agree, I=92d suggest that a logical next
>> step would be for a -04 version of draft-jones-appsawg-webfinger to be
>> published that changes support for the resource parameter from RECOMMEND=
ED
>> to REQUIRED, as that could provide a starting point for a common discove=
ry
>> spec.****
>> ** **
>>                                                             -- Mike****
>>  ****
>> P.S.  As long as draft-jones-appsawg-webfinger is being revised, I=92d a=
lso
>> suggest adding text making explicit what has been an implicit assumption=
 in
>> both WebFinger and SWD - that depending upon whether and how the client =
is
>> authenticated, the set of resources returned may vary (as Blaine had
>> pointed out earlier).  That could help deal with some of the privacy
>> perceptions.****
>> ** **
>> *From:* apps-discuss-bounces@ietf.org [mailto:
>> apps-discuss-bounces@ietf.org] *On Behalf Of *Blaine Cook
>> *Sent:* Sunday, April 22, 2012 2:15 PM
>> *To:* apps-discuss@ietf.org
>> *Subject:* [apps-discuss] Webfinger / SWD Issue #3: direct versus
>> indirect discovery****
>> ** **
>> This is the last issue that I've flagged as blocking a new Webfinger /
>> SWD draft.****
>> ** **
>> Mike suggested that being able to request a user's profile with a single
>> request (i.e., that the /.well-known/ profile resource should be able to
>> respond with full profile data immediately, rather than pointing at a
>> second URL that will fulfil the request) is a requirement for this stand=
ard.
>> ****
>> ** **
>> I'd like to challenge that requirement. The arguments for a direct
>> discovery endpoint are:****
>> ** **
>> 1. Fewer requests against the server, since we save (in the worst-case)
>> 50% of requests by bypassing the indirect lookup phase.****
>> 2. Lower latency for clients (e.g., mobile clients) owing to the reduced
>> number of lookups.****
>> ** **
>> The arguments for an indirect discovery endpoint are:****
>> ** **
>> 1. Trivial and web-standards friendly deployment for domains that won't
>> host their own webfinger/swd profile servers, but want to enable account=
s
>> on their domains (e.g., statically hosted sites).****
>> 2. A loosening of the requirement that URLs at the bare domain must run
>> dynamic scripts that respond to requests to the /.well-known/ path.****
>> ** **
>> My opinion is that the approach that SWD has proposed for the redirect i=
s
>> problematic. First, the format is very similar in form to the HTML "meta
>> refresh" tag that provided HTTP redirect support from within HTML. That
>> format has been widely deprecated, and in these more enlightened times, =
we
>> just use the 3xx response codes with Location headers, instead.****
>> ** **
>> Secondly, the SWD request format means that for smaller sites, often
>> those with the least resources, will end up serving static content in a =
way
>> that's difficult to cache; certainly, more difficult to cache than just
>> serving static content. This is due to the request parameters present in
>> all SWD requests; those request parameters will bust caches.****
>> ** **
>> As for the first argument *for* SWD's approach, I'd suggest we look to
>> DNS, which uses the same indirection approach for NS records, relying on=
 a
>> (relatively) very small set of root servers to handle the traffic for th=
e
>> whole internet. Clearly, this approach works, and webfinger/swd servers =
are
>> in a much better position to handle this additional traffic. Most of thi=
s
>> traffic will be heavily cached, especially for the largest providers.***=
*
>> ** **
>> In fact, in terms of real deployments, hosting a script at, e.g.,
>> google.com/.well-known/simple-web-discovery is much harder than hosting
>> a script atprofiles.google.com/profile.json for all sorts of reasons, so
>> it's my belief that the first argument is a red herring.****
>> ** **
>> The second argument is legitimate, but only if mobile clients will
>> actually be making requests to diverse webfinger/swd hosts. Instead, I
>> strongly believe that we'll see the emergence of DNS-like servers that
>> provide both profile hosting as well as proxy services. For a mobile
>> client, the optimal approach will be to use SPDY to connect to a single
>> host that performs webfinger/swd lookups on the mobile client's behalf,
>> eliminating the latency concerns.****
>> ** **
>> I offer that the two-step lookup can be implemented without conditionals
>> on the client, whereas the direct-unless-not approach cannot be implemen=
ted
>> that way (see my earlier curl example for proof). It's simpler, and easi=
er
>> to explain to the (hopefully many) small site owners who we'd like to
>> implement this technology.****
>> ** **
>> Thoughts? Am I missing something?****
>> ** **
>> b.****
>> _______________________________________________
>> 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
>>
>>
>
>

--001636c5bdcd9fea1104be5c8b96
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable




On Mon, Apr 2=
3, 2012 at 12:19 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:=



I understand that in some environments =
you may not have access to http rewrite rules. =A0
Others may preclude =
any scripts.

We do have to decide what environment=
s we are going to support.



If we stick to static files only then we are just putti=
ng some lipstick on Yadis by adding a way to map a email like address to a =
file.

So yes there are those environments, but tha=
t needs to be balanced against the additional overhead on the clients to su=
pport that environment.



Yes, of course. We must seek a balan=
ce. What have I missed in the following attempt to balance the proposals?

If we adopt a solution that can't be implemente=
d with static files, then:


  • Positive: Clients which seek only one or two bits of specific =
information may experience less "overhead."
  • Negative: Cli=
ents that seek all or many bits of available information would experience m=
ore overhead.
    • 

  • Negative: Many sites that could otherwise provide WebFinger support wil=
l not be able to.=A0
I guess the question is: "How=
 should we weight the positive against the negatives?" Personally, I w=
ould suggest that the negatives outweigh (out-balances?) the positive. I be=
lieve that is why, for the many years that WebFinger has been under discuss=
ion, that the majority of discussions have assumed that static files would =
be sufficient.



bob wyman
=A0

John B.
<=
div>


On 2012-04-23, at 12:26 PM, Bob Wyman =
wrote:


On Mon, Apr 23, 2012 at 11:08 AM, John Bradley=
 <ve7jtb@ve7jtb.com> wrote:




Mike,

I think there =
is less resistance to making resource parameter REQUIRED than there is to r=
emoving the initial host-meta lookup to get the template.





We should probably keep those issues separate.

I agree that supporting indirect discovery of the template via host-meta.=
jason should probably stay.

The question is if the=
ir can be an optimization that allows shortcutting that step if you know th=
at all you want is web finger.




A possible option for that could be using a fixed templ=
ate in /.well-known/.

That endpoint would return:



a The terminal JRD (like =
SWD)
b a 3xx =
redirect to the real endpoint
Causing a=
 3xx redirect typically requires modification to the configuration files of=
 a multi-host shared web server. Access to such configuration files is ofte=
n restricted in such a way that those responsible from just one or a few of=
 the sites sharing the common server are not permitted to make modification=
s to those files. In many cases, such modifications can be requested and wi=
ll only be made after lengthy delays or the payment of support and maintena=
nce fees.=A0




If we want this sort of discovery to become generally a=
vailable, and not just be limited to the "large" sites, we should=
 ensure that it is as simple as possible to deploy.
=A0



c a copy of the host-meta.jrd

We=
 would probably only do one of b or c.

c has the a=
dvantage of being a static file and you being no worse off than having star=
ted with host-meta.json.



b is the simplest for the client and only requires common rewriting ru=
les.

If the redirect is to the same host you could=
 avoid the overhead of two connections by pipelining the requests over the =
same TCP connection.



SPDY in the future will make that even more efficient.

<=
/div>
I will grant Blaine that most openID Connect discovery requests a=
re Server to Server, =A0However there are Apps that are also clients that s=
hould not be ignored.



I personally like the fixed template with a 3xx redirect and =A0resour=
ce parameter returning a JRD due to the simplicity of client coding.
<=
div>
Things needing other sorts of information about the host=
 would still use host-meta or host-meta.json.




John B.


On 2012-04-23, at 1:11 AM, Mike Jones wrote:




I agree with your goal of simplicity for clients.=A0 Paul=
=92s example seems about as simple as it can get for clients:=






It shares the property with your earlier example (below) that clients ha=
ve a no-branches code path to do discovery:



=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 curl -s=A0http://example.com/.well-known/host=
-meta|



=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 awk "/lrdd/,/template/&q=
uot;|tr -d '\n'|sed -e "s/^.*template=3D'\([^']*\)'=
;.*$/\1/"|



=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 sed -e "s/{uri}/user@example.com/"=
|xargs curl =96s



=A0



However, I challenge the assumption in your note below that servers usin=
g only static pages must be supported.=A0=A0I j=
ust don=92t see the requirement to implement a query parameter as being an =
impediment in practice, even for hosted domains.=A0 I know of no hosting co=
mpany that doesn=92t provide a means of putting executable code behind web =
pages, be it PHP, Perl, Ruby, ASP, JSP, etc.=A0 I know you=92re trying to m=
ake the case for static pages, but in practice, I believe that dynamic page=
s are always easily available.



=A0



Assuming that we=92re in an either-or situation with regard to either ha=
ving single-GET discovery or supporting discovery using only static server =
pages (and I=92d love to have someone demonstrate to us that we=92re not), =
I=92d take single-GET discovery for sure, as in some cases, it makes an app=
reciable difference in user interface latency, and per the paragraph above,=
 I believe that dynamic queries can be implemented on all hosting platforms=
.



=A0



Assuming the WebFinger authors agree, I=92d suggest that a logical next =
step would be for a -04 version of draft-jones-appsawg-webfinger to be publ=
ished that changes support for the resource parameter from RECOMMENDED to R=
EQUIRED, as that could provide a starting point for a common discovery spec=
.



=A0



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



=A0



P.S.=A0 As long as draft-jones-appsawg-webfinger is being revised, I=92d=
 also suggest adding text making explicit what has been an implicit assumpt=
ion in both WebFinger and SWD - that depending upon whether and how the cli=
ent is authenticated, the set of resources returned may vary (as Blaine had=
 pointed out earlier).=A0 That could help deal with some of the privacy per=
ceptions.



=A0



From:=
=A0apps-d=
iscuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]=A0On Behalf Of=A0Blaine Cook


Sent:=A0Sunday, April 22, 2012 2:15 PM
To:=A0app=
s-discuss@ietf.org
Subject:=A0[apps-discuss] Web=
finger / SWD Issue #3: direct versus indirect discovery



=A0


This is the last issue that I've flagged as blocking a new Webfinger / =
SWD draft.


=A0
Mike suggested that being able to request a us=
er's profile with a single request (i.e., that the /.well-known/ profil=
e resource should be able to respond with full profile data immediately, ra=
ther than pointing at a second URL that will fulfil the request) is a requi=
rement for this standard.



=A0


I'd like to challenge that requirement. The arguments for a direct disc=
overy endpoint are:


=A0
1. Fewer requests against the server, since we=
 save (in the worst-case) 50% of requests by bypassing the indirect lookup =
phase.



2. Lower latency for clients (e.g., mobile clients) owing to the redu=
ced number of lookups.



=A0


The arguments for an indirect discovery endpoint are:


=A0
1. Trivial and web-standards friendly deployme=
nt for domains that won't host their own webfinger/swd profile servers,=
 but want to enable accounts on their domains (e.g., statically hosted site=
s).



2. A loosening of the requirement that URLs at the bare domain must r=
un dynamic scripts that respond to requests to the /.well-known/ path.



=A0


My opinion is that the approach that SWD has proposed for the redirect is p=
roblematic. First, the format is very similar in form to the HTML "met=
a refresh" tag that provided HTTP redirect support from within HTML. T=
hat format has been widely deprecated, and in these more enlightened times,=
 we just use the 3xx response codes with Location headers, instead.<=
u>



=A0


Secondly, the SWD request format means that for smaller sites, often those =
with the least resources, will end up serving static content in a way that&=
#39;s difficult to cache; certainly, more difficult to cache than just serv=
ing static content. This is due to the request parameters present in all SW=
D requests; those request parameters will bust caches.



=A0


As for the first argument *for* SWD's approach, I'd suggest we look=
 to DNS, which uses the same indirection approach for NS records, relying o=
n a (relatively) very small set of root servers to handle the traffic for t=
he whole internet. Clearly, this approach works, and webfinger/swd servers =
are in a much better position to handle this additional traffic. Most of th=
is traffic will be heavily cached, especially for the largest providers.=




=A0


In fact, in terms of real deployments, hosting a script at, e.g.,=A0<=
/span>google.com/.wel=
l-known/simple-web-discovery=A0is much harder than hosting=
 a script atprofiles.google.com/p=
rofile.json=A0for all sorts of reasons, so it's my bel=
ief that the first argument is a red herring.



=A0


The second argument is legitimate, but only if mobile clients will actually=
 be making requests to diverse webfinger/swd hosts. Instead, I strongly bel=
ieve that we'll see the emergence of DNS-like servers that provide both=
 profile hosting as well as proxy services. For a mobile client, the optima=
l approach will be to use SPDY to connect to a single host that performs we=
bfinger/swd lookups on the mobile client's behalf, eliminating the late=
ncy concerns.



=A0


I offer that the two-step lookup can be implemented without conditionals on=
 the client, whereas the direct-unless-not approach cannot be implemented t=
hat way (see my earlier curl example for proof). It's simpler, and easi=
er to explain to the (hopefully many) small site owners who we'd like t=
o implement this technology.



=A0


Thoughts? Am I missing something?
=A0



b.
________________________=
_______________________


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





_______________________=
________________________

apps-discuss mailing list

apps-discuss@iet=
f.org

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









--001636c5bdcd9fea1104be5c8b96--

From simon.perreault@viagenie.ca  Mon Apr 23 11:14: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 6695B21F8647 for ; Mon, 23 Apr 2012 11:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATBDCaDTe9ZV for ; Mon, 23 Apr 2012 11:14:37 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id A342721F8619 for ; Mon, 23 Apr 2012 11:14:37 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:8130:f627:d4d2:65bc]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EAC6540064; Mon, 23 Apr 2012 14:14:36 -0400 (EDT)
Message-ID: <4F959C0C.3000009@viagenie.ca>
Date: Mon, 23 Apr 2012 14:14:36 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Julian Reschke 
References: <4F955991.2080606@viagenie.ca> <4F95691E.3020800@gmx.de>
In-Reply-To: <4F95691E.3020800@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" , draft-ietf-appsawg-mime-default-charset@tools.ietf.org
Subject: Re: [apps-discuss] Default charset in vCard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 18:14:38 -0000

On 2012-04-23 10:37, Julian Reschke wrote:
>> In vCard 4, we basically say two things:
>> http://tools.ietf.org/html/rfc6350#section-3.1
>>
>> 1. The charset is always UTF-8.
>
> As far as I can tell, that's not in-line with RFC 2046 which defines the
> default to be US-ASCII.

Definitely. RFC 2046 is broken, we all agree on that. We tried to do the 
right thing.

>> 2. If you use the charset parameter, it MUST be UTF-8.
>>
>> It looks like it goes against the recommendation in your draft:
>>
>> a. specify that the "charset" parameter is not used for the defined
>> subtype, because the charset information is transported inside
>> the payload (such as in "text/xml"), or
>> b. require explicit unconditional inclusion of the "charset"
>> parameter eliminating the need for a default value.
>> [...]
>> New subtypes of the "text" media type, thus, SHOULD NOT define a
>> default "charset" value. If there is a strong reason to do so
>> despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as
>> the default.
>>
>> So, two questions:
>>
>> - Am I reading this right? Is there actually a conflict?
>
> I wouldn't call it a conflict. We just changed the defaults for new
> registrations. That doesn't change existing ones.

Right, but I meant to ask "if we were to do it again (for vCard), would 
we do it differently based on what is proposed here (in this draft)?"

Specifically "New subtypes of the "text" media type, thus, SHOULD NOT 
define a default "charset" value."

And if the answer is "yes we would do it differently", I would find that 
very suspect.

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From ve7jtb@ve7jtb.com  Mon Apr 23 11:27: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 5353D21F8592 for ; Mon, 23 Apr 2012 11:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.537
X-Spam-Level: 
X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.061,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOVmddApdU3o for ; Mon, 23 Apr 2012 11:27:31 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFAA21F84D2 for ; Mon, 23 Apr 2012 11:27:31 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so7345099yhk.31 for ; Mon, 23 Apr 2012 11:27:24 -0700 (PDT)
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=v6D9NKFafZL1AxF3aXaGw707BhM1ehWWl8vHoO46yy0=; b=An94qxzvAfuCJVZZMZNNM5JvIwdBHKEbeSqizWgRMSUXcTRQm1rZGoMyxjQSVt+hEb w2uJ2bNYRjOW/8Bda46xMLqNSMN9EOnXBAe8iUbFpVmclu9P8QNc2AoM6c7Fu+NU8MoQ T6Y4HePv1e8dfLsnf8bi+gNSB8cGNOnBPIEFHSIlkKFsSvVCRY1p7b5T4NUcEEA3xaCb oFsuX8fAkmUiYvMX2NDd0YCSxSgOsySSdsiB2vNE2mpDZZFywidUeGNl2NF6aFlHbeWR pEe8VDDBmV2u+r8vVlEjlXQQJ1xz/b9U8e4wVBy5LxS0Kwtu9AfZxVs6XcfPpDWzkuAB gEuw==
Received: by 10.60.4.199 with SMTP id m7mr21643896oem.65.1335205643754; Mon, 23 Apr 2012 11:27:23 -0700 (PDT)
Received: from [192.168.1.213] (190-20-21-61.baf.movistar.cl. [190.20.21.61]) by mx.google.com with ESMTPS id aj16sm13719192oec.4.2012.04.23.11.27.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 11:27:21 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_56157BBF-86EC-4BD7-B01E-A4B19683313C"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: 
Date: Mon, 23 Apr 2012 15:27:04 -0300
Message-Id: <599EB342-8023-453D-977E-DC318637B6E9@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com> 
To: Bob Wyman 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQlKaCNPBjbXilh5Ee47c2OcfJtRKQtljMlhTouMnQCWZtA3SFJNbvFS5IyUoBrLiP/nQsaO
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 18:27:33 -0000

--Apple-Mail=_56157BBF-86EC-4BD7-B01E-A4B19683313C
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_2D9F8022-7DBD-4DBD-9115-490BAA5BF15C"


--Apple-Mail=_2D9F8022-7DBD-4DBD-9115-490BAA5BF15C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

To some extent this hangs on the behaviour of a site that doesn't =
support the resource parameter.

In the current spec it is optional and if the server doesn't understand =
it you get back the whole document.

Mike,  would returning the JRD with all the relations be an acceptable =
response from endpoints not supporting resource?

That way large sites can optimize and small sites could still use static =
files.

The client would need a bit of extra logic to find the relation, but =
that should not be a big deal with JSON.

Sites supporting OAuth protected discovery and resource selection would =
be free to do that and others could have static public files

This is only half the issue. =20

The other is sites that can't support a URL rewrite ruler redirect.

That leaves returning the host-meta.json file in the initial response =
and leaving it up to the client to apply the template.

That is effectively what WF has now.  I am not keen on that answer as it =
adds a second code path to the client.

John B.

On 2012-04-23, at 3:09 PM, Bob Wyman wrote:

>=20
>=20
> On Mon, Apr 23, 2012 at 12:19 PM, John Bradley  =
wrote:
> I understand that in some environments you may not have access to http =
rewrite rules. =20
> Others may preclude any scripts.
>=20
> We do have to decide what environments we are going to support.
>=20
> If we stick to static files only then we are just putting some =
lipstick on Yadis by adding a way to map a email like address to a file.
>=20
> So yes there are those environments, but that needs to be balanced =
against the additional overhead on the clients to support that =
environment.
>=20
> Yes, of course. We must seek a balance. What have I missed in the =
following attempt to balance the proposals?
>=20
> If we adopt a solution that can't be implemented with static files, =
then:
> Positive: Clients which seek only one or two bits of specific =
information may experience less "overhead."
> Negative: Clients that seek all or many bits of available information =
would experience more overhead.
> Negative: Many sites that could otherwise provide WebFinger support =
will not be able to.=20
> I guess the question is: "How should we weight the positive against =
the negatives?" Personally, I would suggest that the negatives outweigh =
(out-balances?) the positive. I believe that is why, for the many years =
that WebFinger has been under discussion, that the majority of =
discussions have assumed that static files would be sufficient.
>=20
> bob wyman
> =20
>=20
> John B.
>=20
> On 2012-04-23, at 12:26 PM, Bob Wyman wrote:
>=20
>>=20
>>=20
>> On Mon, Apr 23, 2012 at 11:08 AM, John Bradley  =
wrote:
>> Mike,
>>=20
>> I think there is less resistance to making resource parameter =
REQUIRED than there is to removing the initial host-meta lookup to get =
the template.
>>=20
>> We should probably keep those issues separate.
>>=20
>> I agree that supporting indirect discovery of the template via =
host-meta.jason should probably stay.
>>=20
>> The question is if their can be an optimization that allows =
shortcutting that step if you know that all you want is web finger.
>>=20
>> A possible option for that could be using a fixed template in =
/.well-known/.
>>=20
>> That endpoint would return:
>> a The terminal JRD (like SWD)
>> b a 3xx redirect to the real endpoint
>> Causing a 3xx redirect typically requires modification to the =
configuration files of a multi-host shared web server. Access to such =
configuration files is often restricted in such a way that those =
responsible from just one or a few of the sites sharing the common =
server are not permitted to make modifications to those files. In many =
cases, such modifications can be requested and will only be made after =
lengthy delays or the payment of support and maintenance fees.=20
>>=20
>> If we want this sort of discovery to become generally available, and =
not just be limited to the "large" sites, we should ensure that it is as =
simple as possible to deploy.
>> =20
>> c a copy of the host-meta.jrd
>>=20
>> We would probably only do one of b or c.
>>=20
>> c has the advantage of being a static file and you being no worse off =
than having started with host-meta.json.
>> b is the simplest for the client and only requires common rewriting =
rules.
>>=20
>> If the redirect is to the same host you could avoid the overhead of =
two connections by pipelining the requests over the same TCP connection.
>> SPDY in the future will make that even more efficient.
>>=20
>> I will grant Blaine that most openID Connect discovery requests are =
Server to Server,  However there are Apps that are also clients that =
should not be ignored.
>> I personally like the fixed template with a 3xx redirect and  =
resource parameter returning a JRD due to the simplicity of client =
coding.
>>=20
>> Things needing other sorts of information about the host would still =
use host-meta or host-meta.json.
>>=20
>> John B.
>>=20
>>=20
>> On 2012-04-23, at 1:11 AM, Mike Jones wrote:
>>=20
>>> I agree with your goal of simplicity for clients.  Paul=92s example =
seems about as simple as it can get for clients:
>>>                curl -v =
https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paulej@p=
acketizer.com
>>> It shares the property with your earlier example (below) that =
clients have a no-branches code path to do discovery:
>>>                curl -s http://example.com/.well-known/host-meta|
>>>                awk "/lrdd/,/template/"|tr -d '\n'|sed -e =
"s/^.*template=3D'\([^']*\)'.*$/\1/"|
>>>                sed -e "s/{uri}/user@example.com/"|xargs curl =96s
>>> =20
>>> However, I challenge the assumption in your note below that servers =
using only static pages must be supported.  I just don=92t see the =
requirement to implement a query parameter as being an impediment in =
practice, even for hosted domains.  I know of no hosting company that =
doesn=92t provide a means of putting executable code behind web pages, =
be it PHP, Perl, Ruby, ASP, JSP, etc.  I know you=92re trying to make =
the case for static pages, but in practice, I believe that dynamic pages =
are always easily available.
>>> =20
>>> Assuming that we=92re in an either-or situation with regard to =
either having single-GET discovery or supporting discovery using only =
static server pages (and I=92d love to have someone demonstrate to us =
that we=92re not), I=92d take single-GET discovery for sure, as in some =
cases, it makes an appreciable difference in user interface latency, and =
per the paragraph above, I believe that dynamic queries can be =
implemented on all hosting platforms.
>>> =20
>>> Assuming the WebFinger authors agree, I=92d suggest that a logical =
next step would be for a -04 version of draft-jones-appsawg-webfinger to =
be published that changes support for the resource parameter from =
RECOMMENDED to REQUIRED, as that could provide a starting point for a =
common discovery spec.
>>> =20
>>>                                                             -- Mike
>>> =20
>>> P.S.  As long as draft-jones-appsawg-webfinger is being revised, I=92d=
 also suggest adding text making explicit what has been an implicit =
assumption in both WebFinger and SWD - that depending upon whether and =
how the client is authenticated, the set of resources returned may vary =
(as Blaine had pointed out earlier).  That could help deal with some of =
the privacy perceptions.
>>> =20
>>> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of Blaine Cook
>>> Sent: Sunday, April 22, 2012 2:15 PM
>>> To: apps-discuss@ietf.org
>>> Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus =
indirect discovery
>>> =20
>>> This is the last issue that I've flagged as blocking a new Webfinger =
/ SWD draft.
>>> =20
>>> Mike suggested that being able to request a user's profile with a =
single request (i.e., that the /.well-known/ profile resource should be =
able to respond with full profile data immediately, rather than pointing =
at a second URL that will fulfil the request) is a requirement for this =
standard.
>>> =20
>>> I'd like to challenge that requirement. The arguments for a direct =
discovery endpoint are:
>>> =20
>>> 1. Fewer requests against the server, since we save (in the =
worst-case) 50% of requests by bypassing the indirect lookup phase.
>>> 2. Lower latency for clients (e.g., mobile clients) owing to the =
reduced number of lookups.
>>> =20
>>> The arguments for an indirect discovery endpoint are:
>>> =20
>>> 1. Trivial and web-standards friendly deployment for domains that =
won't host their own webfinger/swd profile servers, but want to enable =
accounts on their domains (e.g., statically hosted sites).
>>> 2. A loosening of the requirement that URLs at the bare domain must =
run dynamic scripts that respond to requests to the /.well-known/ path.
>>> =20
>>> My opinion is that the approach that SWD has proposed for the =
redirect is problematic. First, the format is very similar in form to =
the HTML "meta refresh" tag that provided HTTP redirect support from =
within HTML. That format has been widely deprecated, and in these more =
enlightened times, we just use the 3xx response codes with Location =
headers, instead.
>>> =20
>>> Secondly, the SWD request format means that for smaller sites, often =
those with the least resources, will end up serving static content in a =
way that's difficult to cache; certainly, more difficult to cache than =
just serving static content. This is due to the request parameters =
present in all SWD requests; those request parameters will bust caches.
>>> =20
>>> As for the first argument *for* SWD's approach, I'd suggest we look =
to DNS, which uses the same indirection approach for NS records, relying =
on a (relatively) very small set of root servers to handle the traffic =
for the whole internet. Clearly, this approach works, and webfinger/swd =
servers are in a much better position to handle this additional traffic. =
Most of this traffic will be heavily cached, especially for the largest =
providers.
>>> =20
>>> In fact, in terms of real deployments, hosting a script at, e.g., =
google.com/.well-known/simple-web-discovery is much harder than hosting =
a script atprofiles.google.com/profile.json for all sorts of reasons, so =
it's my belief that the first argument is a red herring.
>>> =20
>>> The second argument is legitimate, but only if mobile clients will =
actually be making requests to diverse webfinger/swd hosts. Instead, I =
strongly believe that we'll see the emergence of DNS-like servers that =
provide both profile hosting as well as proxy services. For a mobile =
client, the optimal approach will be to use SPDY to connect to a single =
host that performs webfinger/swd lookups on the mobile client's behalf, =
eliminating the latency concerns.
>>> =20
>>> I offer that the two-step lookup can be implemented without =
conditionals on the client, whereas the direct-unless-not approach =
cannot be implemented that way (see my earlier curl example for proof). =
It's simpler, and easier to explain to the (hopefully many) small site =
owners who we'd like to implement this technology.
>>> =20
>>> Thoughts? Am I missing something?
>>> =20
>>> b.
>>> _______________________________________________
>>> apps-discuss mailing list
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>=20
>>=20
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>=20
>>=20
>=20
>=20


--Apple-Mail=_2D9F8022-7DBD-4DBD-9115-490BAA5BF15C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

To =
some extent this hangs on the behaviour of a site that doesn't support =
the resource parameter.

In the current spec it is =
optional and if the server doesn't understand it you get back the whole =
document.

Mike,  would returning the JRD =
with all the relations be an acceptable response from endpoints not =
supporting resource?

That way large sites can =
optimize and small sites could still use static =
files.

The client would need a bit of extra =
logic to find the relation, but that should not be a big deal with =
JSON.

Sites supporting OAuth protected =
discovery and resource selection would be free to do that and others =
could have static public files

This is only =
half the issue.  

The other is sites that =
can't support a URL rewrite ruler =
redirect.

That leaves returning the =
host-meta.json file in the initial response and leaving it up to the =
client to apply the template.

That is =
effectively what WF has now.  I am not keen on that answer as it =
adds a second code path to the client.

John =
B.

=

--Apple-Mail=_2D9F8022-7DBD-4DBD-9115-490BAA5BF15C--

--Apple-Mail=_56157BBF-86EC-4BD7-B01E-A4B19683313C
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
MzE4MjcwNVowIwYJKoZIhvcNAQkEMRYEFC8Q1eWedvBDZT4ujX8LUuwlvKCZMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
ALGzp+xkpRB7AAmnOmmJwScsi847MaUM65y1CR27450Dh9BwWRSzWAhra9CaQ/gk4wYhTv20seN1
INBQ8lGZibd5FcBNkkuuX8a7T1aFGBrRUaVTiXfPWtEPTmm/vC8Vpr7fpRkuSscy9tcEJdMdrFzv
8jGbB3usC4ogC5KaEuSx+Z8nLyXNbQIAbDPb4bTmWoEMY6JNp3vvE9MwKd0IWpdS8bwqh2ux00fe
4Q5UbnBiOxp8Q938XPQgGjcuJv7bnlbbFd4uRtVRHlmyttJnrMh6xb3WIbh3mXXdUplLj2UB/0dN
5AsxaUZCBkuLJWj5bjJSfmUHMvWu6iJEEjXyexwAAAAAAAA=

--Apple-Mail=_56157BBF-86EC-4BD7-B01E-A4B19683313C--

From stpeter@stpeter.im  Mon Apr 23 11:34: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 21EF821F8624 for ; Mon, 23 Apr 2012 11:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.61
X-Spam-Level: 
X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxYpjwTcHTzj for ; Mon, 23 Apr 2012 11:34:56 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D685721F85B5 for ; Mon, 23 Apr 2012 11:34:50 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4FC6D40058; Mon, 23 Apr 2012 12:49:20 -0600 (MDT)
Message-ID: <4F95A0C9.3020303@stpeter.im>
Date: Mon, 23 Apr 2012 12:34:49 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: John Bradley 
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com>  <599EB342-8023-453D-977E-DC318637B6E9@ve7jtb.com>
In-Reply-To: <599EB342-8023-453D-977E-DC318637B6E9@ve7jtb.com>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 18:34:57 -0000

Picking on a minor point here...

On 4/23/12 12:27 PM, John Bradley wrote:

> That way large sites can optimize and small sites could still use static
> files.

Is there evidence for the assumption that large services will serve
their data via an API whereas small services will serve their data via
static files? It seems clear to me that many small services might not
host static files, e.g., because they use a content management system or
community software application that automatically pulls data out of a
database of users and serves up some of that information in the form
defined by the WebFinger spec (or SWD or whatever). I rather doubt that
large services will host static files, but let's not base our design
decisions on a false premise about smaller services.

Peter

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



From cabo@tzi.org  Mon Apr 23 13:28: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 601E611E8073 for ; Mon, 23 Apr 2012 13:28:39 -0700 (PDT)
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_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJcDDVTYCR2w for ; Mon, 23 Apr 2012 13:28:38 -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 7202811E8072 for ; Mon, 23 Apr 2012 13:28: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 q3NKSUkt013734; Mon, 23 Apr 2012 22:28:30 +0200 (CEST)
Received: from [192.168.217.105] (p5B3E6405.dip.t-dialin.net [91.62.100.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D966AB15; Mon, 23 Apr 2012 22:28:29 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Mon, 23 Apr 2012 22:28:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org>
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> 
To: Cullen Jennings 
X-Mailer: Apple Mail (2.1257)
Cc: "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Apr 2012 20:28:39 -0000

My 5-line summary is:

1) EXI may or may not be a content-encoding in its schemaless form, but =
we don't care about that, we use EXI schema-informed mode.

2) +exi is considered undesirable for schema-informed EXI.
So we should go to an EXI specific media type, let's call that -exi.

This means three media types for SenML

application/senml+json
application/senml+xml
application/senml-exi

The third media type would in particular nail down the way EXI is used =
in schema-informed mode.

Gr=FC=DFe, Carsten


From ve7jtb@ve7jtb.com  Mon Apr 23 14:14: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 4381A11E807F for ; Mon, 23 Apr 2012 14:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.54
X-Spam-Level: 
X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.058,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKb5GAWdtJck for ; Mon, 23 Apr 2012 14:14:29 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 698F411E8088 for ; Mon, 23 Apr 2012 14:14:29 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so8662778qcs.31 for ; Mon, 23 Apr 2012 14:14:29 -0700 (PDT)
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=IPNifQi9PzsRTW0rzEhtwgmuPj+v2W42tmeyqzUrC7I=; b=RfoYqiN5fMBvH2ydXMDRRwE+sNTb3gQT+eGNEs0JaXdycKBaGtHx3UQI8RBe4OExZO DzHE7j8ydDaIgGn5EgFqXJARAyrWW9T6sFdaeQkY5tJcli0vRE8B4lNCW1lQaZgncdZ4 TFGtzMsRY0T8JkY3O/pPoT6Dd/pVy+wPEJlBajxJBTeEcefZLiga30CGB71l4iWBVn+y vZ+l+IHf4BF8xlAcP60LcxM9zkvz3Bels7AcFPeGdY5AphqMXwfP8yvf++u7hrcltPU/ 5Ooinm2R1kXLjrqsZApBeY8fzVCl5n7Yna2rO8NYYjycBeHtA2WIMLzBnaHq+eI96NPH Lpzw==
Received: by 10.224.222.145 with SMTP id ig17mr9363058qab.11.1335215668845; Mon, 23 Apr 2012 14:14:28 -0700 (PDT)
Received: from [192.168.1.213] (190-20-21-61.baf.movistar.cl. [190.20.21.61]) by mx.google.com with ESMTPS id g10sm23577976qae.11.2012.04.23.14.14.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 14:14:27 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_2E7B814B-1258-4755-9A86-B5C3CFF98713"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <4F95A0C9.3020303@stpeter.im>
Date: Mon, 23 Apr 2012 18:14:24 -0300
Message-Id: 
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com>  <599EB342-8023-453D-977E-DC318637B6E9@ve7jtb.com> <4F95A0C9.3020303@stpeter.im>
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQmmWgT1od4ZLk39zf15sbwIwFZ7y7BlTXkVAMQ8rN14wVUN2L2w1O2ZaxJnzMCqb8ExNpgM
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 21:14:30 -0000

--Apple-Mail=_2E7B814B-1258-4755-9A86-B5C3CFF98713
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8A996496-84BA-4622-95A9-472C2EADE2D6"


--Apple-Mail=_8A996496-84BA-4622-95A9-472C2EADE2D6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

It is not my assumption.  =20

=46rom a practical point of view with openID Connect, you couldn't host =
a IdP on a server that only supports static pages.

I think that Paul's example of a site supporting
curl -v =
https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paulej@p=
acketizer.com

Is the bar.   There are several ways to do that, so I don't think it is =
unreasonable.

John B.

On 2012-04-23, at 3:34 PM, Peter Saint-Andre wrote:

> Picking on a minor point here...
>=20
> On 4/23/12 12:27 PM, John Bradley wrote:
>=20
>> That way large sites can optimize and small sites could still use =
static
>> files.
>=20
> Is there evidence for the assumption that large services will serve
> their data via an API whereas small services will serve their data via
> static files? It seems clear to me that many small services might not
> host static files, e.g., because they use a content management system =
or
> community software application that automatically pulls data out of a
> database of users and serves up some of that information in the form
> defined by the WebFinger spec (or SWD or whatever). I rather doubt =
that
> large services will host static files, but let's not base our design
> decisions on a false premise about smaller services.
>=20
> Peter
>=20
> --=20
> Peter Saint-Andre
> https://stpeter.im/
>=20
>=20


--Apple-Mail=_8A996496-84BA-4622-95A9-472C2EADE2D6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

It is =
not my assumption.   

=46rom a practical =
point of view with openID Connect, you couldn't host a IdP on a server =
that only supports static pages.

I think that =
Paul's example of a site supporting
curl -v 
Picking on a minor point here...

On 4/23/12 =
12:27 PM, John Bradley wrote:

That way =
large sites can optimize and small sites could still use =
static
files.

Is there evidence for the =
assumption that large services will serve
their data via an API =
whereas small services will serve their data via
static files? It =
seems clear to me that many small services might not
host static =
files, e.g., because they use a content management system =
or
community software application that automatically pulls data out =
of a
database of users and serves up some of that information in the =
form
defined by the WebFinger spec (or SWD or whatever). I rather =
doubt that
large services will host static files, but let's not base =
our design
decisions on a false premise about smaller =
services.

Peter

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



=

--Apple-Mail=_8A996496-84BA-4622-95A9-472C2EADE2D6--

--Apple-Mail=_2E7B814B-1258-4755-9A86-B5C3CFF98713
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
MzIxMTQyNVowIwYJKoZIhvcNAQkEMRYEFAqfMROejFXq9v1FSlGtd8Ml/+GrMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AJEEgU2Ye5kNoql/Jw7XufGWkaKLUG4FJY0d6lwRMDRHynXlXGpfikw4TrJa5vY1CiqzsptPFIE7
h5QgDuU8WiJL+iTowQ+UIw5rqY6UgzdDTr0CkaH7XD8oAj7EotJefRq2e4W/v1o7wrvRHze2wKRT
FnB6A7Hg1QB4BdhdeauxMoJ5Rb7gYvaRkbDjZwYgk54fQnamXYALPQMV10LNZrygtsEY/xyPaUdB
dQjSVw9cNaPcG0EyUjtHk5yXHo+GQkSeM7tvivLgz08Fg6MgGUIGMN69DZcYl+99uaGf/h+Ur0Q1
Xb918CfPBlc5plm1WcDKBoIjwTWBeVkX/20ULpYAAAAAAAA=

--Apple-Mail=_2E7B814B-1258-4755-9A86-B5C3CFF98713--

From stpeter@stpeter.im  Mon Apr 23 14:30: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 08B4621E800F; Mon, 23 Apr 2012 14:30:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.609
X-Spam-Level: 
X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr+HjJNRepJ6; Mon, 23 Apr 2012 14:30:52 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B11B011E808C; Mon, 23 Apr 2012 14:30:52 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7825C40058; Mon, 23 Apr 2012 15:45:22 -0600 (MDT)
Message-ID: <4F95CA0B.8050202@stpeter.im>
Date: Mon, 23 Apr 2012 15:30:51 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "apps-discuss@ietf.org" , dane@ietf.org,  iesg@ietf.org
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 21:30:54 -0000

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

This is a supplemental AppsDir review of draft-ietf-dane-protocol (for
background on AppsDir, please see
).
Although Murray Kucherawy has already reviewed this I-D on behalf of
the AppsDir, folks in the Applications Area realize that wide
deployment of the TLSA Resource Record might have a significant impact
on applications, so we are performing additional reviews. Please treat
these comments just as you would any other Last Call feedback.

Document: draft-ietf-dane-protocol
Title: "The DNS-Based Authentication of Named Entities (DANE) Protocol
for Transport Layer Security (TLS)"
Reviewer: Peter Saint-Andre
Review Date: 2012-04-23
IETF Last Call Date: 2012-04-25
IESG Telechat: not yet scheduled

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

Major Issue:

This document does not mention that TLSA records cannot be used
directly in application protocols that depend on SRV (or NAPTR or
similar technologies). Although I realize that the DANE WG decided,
after much discussion, that the interaction between TLSA records and
SRV records is out of scope for this specification (and I do not mean
to reopen that discussion now), it would be very helpful for this
specification to reflect the results of that discussion. Although I
make specific suggestions regarding text under the Minor Issues below,
in general I think this document needs to be clearer about the
assumptions it has made in this regard; in fact, it seems to me that
an explicit applicability statement is warranted to avoid confusion of
the kind that Dave Cridland experienced (see his Last Call comments).
Absent such an applicability statement, it would be good to state up
front something that currently is not made explicit until the first
sentence of the Security Considerations:

   The security of the DNS RRtype described in this document relies on
   the security of DNSSEC as used by the client requesting A/AAAA and
   TLSA records.

The import of "and" in that sentence is significant, and needs to be
highlighted earlier in the specification.

Minor Issues:

1. In Section 1.2, these sentences might involve a slight
oversimplication:

   A TLS client begins a connection by exchanging messages with a TLS
   server.  It looks up the server's name using the DNS to get an
   Internet Protocol (IP) address associated with the name.  It then
   begins a connection to a client-chosen port at that address, and
   sends an initial message there.

1a. The second sentence might be construed as requiring only one step
(look up the name, get an IP address), whereas we know that sometimes
multiple steps are involved (think SRV). I'd be more comfortable if we
added a clause at the end along the lines of "sometimes via multiple
steps".

1b. The term "client-chosen port" makes it sound as if the client can
choose any port it pleases when connecting to the TLS server. Yet
typically the port is derived from a URI, "hardcoded" into the
application protocol (sometimes as a fallback), or discovered via the
DNS (again, think SRV). We needn't reflect those alternatives in the
text, but at the least "appropriate" is better than "client-chosen".

2. In Section 1.3, it is said that "This document only applies to PKIX
[RFC5280] certificates, not certificates of other formats." Does this
mean that a new RR type would need to be defined to handle other
formats (e.g., PGP as in RFC 6091), or only that documents defining
how to use TLSA records with those other formats would need to define
new values for the Certificate Usage field? Please clarify.

3. In Section 1.3, the following paragraph is true only for
application protocols that do not make use of SRV or similar technologies:

   This document defines a secure method to associate the certificate
   that is obtained from the TLS server with a domain name using DNS;
   the DNS information needs to be be protected by DNSSEC.  Because the
   certificate association was retrieved based on a DNS query, the
   domain name in the query is by definition associated with the
   certificate.

For example, in the case of XMPP the application client might discover
through a DNS SRV lookup that the XMPP service for example.com is
actually provided at im.example.net. In this case, the domain name in
the certificate presented by the TLS server (im.example.net) is not
the same as the certificate discovered via the DNS TLSA lookup
(example.com), so we can't simply stipulate that "the domain name in
the query is by definition associated with the certificate". Here
again that applicability statement would be helpful, because this
document assumes that you're connecting to the IP address that you
discover by means of DNS A/AAAA lookup on the domain name contained in
the prefixed DNS domain name defined in Section 3. (As noted, this is
made explicit in the first sentence of the Security Considerations.)

4. In Section 2.2, the term "whitespace" is underspecified. Does that
include, say, any Unicode space separator (Unicode General Category
Zs) or also line separators (Unicode General Category Zl) or only
certain code points in the ASCII range? Further, is the whitespace
significant in the examples from Section 2.3?

5. To those of us accustomed to SRV records, at first glance the
prefixed DNS domain name format defined in Section 3 looks strange:
why not _http._tcp.www.example.com instead of
_443._tcp.www.example.com? But when we take off our SRV-colored
glasses and realize that DANE assumes a DNS A/AAAA lookup on the
domain name, it all makes sense. Perhaps it would be helpful to
mention the reasoning behind the port number (instead of application
name) here?

6. In section 4, no mention is made of the application service that
the TLS expects to encounter at the TLS server:

   The TLS session that is to be set up MUST be for the specific port
   number and transport name that was given in the TLSA query.

Yet surely the application protocol can matter here, no? In
particular, given that 443 is the one true port, we know that folks
might run non-HTTP applications over that port (for evil reasons, of
course). Does DANE elide over the application protocol because we
simply assume that the "right" service is being served over any
particular port? What about service providers that wish to restrict
the usage of a certificate to a particular application service type
(cf. RFC 6125)? Or do we assume that it is enough to differentiate
among application services based on the underlying transport (as seems
to be the case in the text on "Multiple Ports" in Section 5)? IMHO we
have a bit of a muddle here.

7. The paragraph about SSL proxies in Section 8 says that "the TLS
client will get a certificate association from the DNS that will not
match the certificate that the SSL proxy uses with the client";
however, if the SSL proxy is working in concert with an external DNS
validator, is it possible to mimic the behavior of current SSL proxies?

Nits:

1. In Section 1.1, I suggest changing "using encryption" to "using
channel encryption" (since TLS uses connection-oriented encryption
methods, not object encryption).

2. Section 1.1, uses the term "subdomain" in the sentence "This
prevents an untrustworthy signer from compromising anyone's keys
except those in their own subdomains." The term "subdomain" is not
always well understood. I suggest explicitly citing Section 3.1 of RFC
1034 here.

3. In Section 1.3, the phrase "the domain name where the data is
found" makes it sound as if DANE applies only to application protocols
that involve data retrieval, whereas we know it can be used also for
technologies that involve communication (email, IM, etc.). I suggest
"the domain name for the relevant application service" or somesuch.

4. In Section 1.3, I suggest changing "server" (which might be
confused with the TLS server itself) to "service" or "application
service" in this sentence: "A DNS query can return multiple
certificate associations, such as in the case of a server is changing
from one certificate to another."

Typo: "have lead" should be "have led".

Peter

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


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

iEYEARECAAYFAk+VygoACgkQNL8k5A2w/vxyDwCfTTdHCQ1Vo/gHdumTbLGD8gP+
xJwAn0SQ1CkXK3t/38rWE881tc6ZbySt
=ZnZX
-----END PGP SIGNATURE-----

From romeda@gmail.com  Mon Apr 23 14: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 7B70221E8028 for ; Mon, 23 Apr 2012 14:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.474
X-Spam-Level: 
X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XnBhUEWMw3n for ; Mon, 23 Apr 2012 14:45:16 -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 3AFD921E800F for ; Mon, 23 Apr 2012 14:45:15 -0700 (PDT)
Received: by lbgc1 with SMTP id c1so7960lbg.31 for ; Mon, 23 Apr 2012 14:45:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ketxN7NqkmjhXDY2RNMD+y4XwFVsiavLrxMIa7AY568=; b=cQCuQox+kF6X6LQYyIXt1iHjwfqTMtCj/uePuw0N+IzUsKUqam+BaZW6fSl4Yigyb+ Yhc8HL4KGcmn9c6ngmVlAsKoeJ5xIeNI7vWZk/+e8/3iF3IrMeZ4fIZ2w+NAldYW9pcc oIxOlZyOOAmV52wEACDiuUWHSgQN9sKK/7HzTFfp6uuq+45zZTzLhpsFOS77+i5nTdpb 1SM3DLpi8UtPshytNlcFhHpkuy9NJLpfqFSjOFu1GCX+egJ1MoiCqtD4nIuTNIhffQ0f TqZY2LTMO5YMczk52qwvNSEKnQfUZqlY71pZQwsDPWR7+qemKixdHkFORwepdH7KXu4L aYWQ==
Received: by 10.112.47.66 with SMTP id b2mr8610754lbn.35.1335217515035; Mon, 23 Apr 2012 14:45:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.24.229 with HTTP; Mon, 23 Apr 2012 14:44:54 -0700 (PDT)
In-Reply-To: 
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com>  <599EB342-8023-453D-977E-DC318637B6E9@ve7jtb.com> <4F95A0C9.3020303@stpeter.im> 
From: Blaine Cook 
Date: Mon, 23 Apr 2012 22:44:54 +0100
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=bcaec554055eae7d8604be5f8d69
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 21:45:17 -0000

--bcaec554055eae7d8604be5f8d69
Content-Type: text/plain; charset=UTF-8

On 23 April 2012 22:14, John Bradley  wrote:

> It is not my assumption.
>
> From a practical point of view with openID Connect, you couldn't host a
> IdP on a server that only supports static pages.
>

Really? I disagree. My domain, romeda.org, has only static pages on the
root domain. I've done this intentionally, because I don't have time to
maintain potentially exploitable scripts on a personal domain.

My domain is also a valid IdP; fetching /.well-known/host-meta works, and
so does following the LRDD URI. If you use a valid email address (
blaine@romeda.org; just a dummy address, please don't email it), you'll be
given a valid OpenID Server link (it points to Google, whom I trust to run
an OpenID provider securely more than I trust myself).


> I think that Paul's example of a site supporting
>
curl -v
> https://packetizer.com/.well-known/host-meta.json?resource=acct:paulej@packetizer.com
>
> Is the bar.   There are several ways to do that, so I don't think it is
> unreasonable.
>

The arguments I've heard for this are:

1. Providers can't handle the load of 50% more requests (this argument is
bunk, so we'll dismiss it unless someone provides compelling evidence
otherwise).
2. Mobile clients can't handle the additional latency.
3. A uniform API is nice-to-have. Having a two-stage lookup ruins that
uniformity.

First, argument #2: SPDY and the availability (and likelihood of usage) of
proxies means this argument is slim in the face of making it easy for
anyone to serve a host-meta document.

Argument 3 is genuinely interesting. After doing some experiments
though[1], my conclusion is still that it's easier to write reliable client
code with the two-phase process. Clients that support the
SWD_service_redirect JSON response need to be written either with a while()
loop or using recursive functions. These are vastly more complicated, and
because there's no assumption that the SWD_service_redirect is global,
caching won't work globally nor is it possible to reuse the
SWD_service_redirect response.

If we're going to go with a parameters-first approach, I'd like to see
those issues addressed. I like the uniform protocol flow, but if it means
everyone needs to write recursive functions, it's less than ideal.

b.

[1] https://gist.github.com/b52a05bf14b0d4b5ce18

--bcaec554055eae7d8604be5f8d69
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On 23 April 2012 22:14, John Bradley <ve7jtb@=
ve7jtb.com> wrote:



It is not my assumption. =C2=A0=C2=A0
From a practical point of view with openID Connect, you c=
ouldn't host a IdP on a server that only supports static pages.




Really? I disagree. My domain, romeda.org, has only static pages on the root domain. I've do=
ne this intentionally, because I don't have time to maintain potentiall=
y exploitable scripts on a personal domain.




My domain is also a valid IdP; fetching /.well-known/ho=
st-meta works, and so does following the LRDD URI. If you use a valid email=
 address (blaine@romeda.org; just =
a dummy address, please don't email it), you'll be given a valid Op=
enID Server link (it points to Google, whom I trust to run an OpenID provid=
er securely more than I trust myself).



=C2=A0
I think that Paul's example of a site supporting



Is the bar. =C2=A0 There are several ways to do t=
hat, so I don't think it is unreasonable.
=

The arguments I've heard for this are:




1. Providers can't handle the load of 50% more requests (this argu=
ment is bunk, so we'll dismiss it unless someone provides compelling ev=
idence otherwise).
2. Mobile clients can't handle the additio=
nal latency.



3. A uniform API is nice-to-have. Having a two-stage lookup ruins that=
 uniformity.

First, argument #2: SPDY and the avai=
lability (and likelihood of usage) of proxies means this argument is slim i=
n the face of making it easy for anyone to serve a host-meta document.



Argument 3 is genuinely interesting. After doing some e=
xperiments though[1], my conclusion is still that it's easier to write =
reliable client code with the two-phase process. Clients that support the S=
WD_service_redirect JSON response need to be written either with a while() =
loop or using recursive functions. These are vastly more complicated, and b=
ecause there's no assumption that the SWD_service_redirect is global, c=
aching won't work globally nor is it possible to reuse the SWD_service_=
redirect response.




If we're going to go with a parameters-first approa=
ch, I'd like to see those issues addressed. I like the uniform protocol=
 flow, but if it means everyone needs to write recursive functions, it'=
s less than ideal.




b.



--bcaec554055eae7d8604be5f8d69--

From ve7jtb@ve7jtb.com  Mon Apr 23 15:02: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 C12C221E8028 for ; Mon, 23 Apr 2012 15:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.543
X-Spam-Level: 
X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.055,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NwS6wLcgSoJ for ; Mon, 23 Apr 2012 15:02:11 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id A319921F858F for ; Mon, 23 Apr 2012 15:02:11 -0700 (PDT)
Received: by qaea16 with SMTP id a16so1821659qae.10 for ; Mon, 23 Apr 2012 15:02:08 -0700 (PDT)
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=B/jYIi/0nTgMAG6I8l6IpLf11ihJATwxdkk1/Rhwi6I=; b=WYwjzFVvJXFn9/rVWnRjbk9+O+Q/A8NVV4oVtkEKsRKOO3NVucK3LBmjnJfBZJLKHr q9I2VBG7V/ELbdlFdQyoK9UbsxwufqgYIk7BgLh2WvIXYrrY7qPI1fV/tNkXwbi61lY8 fbYgtqMNUdHQMc9sai5HpyJVejpHxE1ePYBpx2Jc3KIAsNG+ozyOycIqbGT4qswHwkQE L2L9ENId0BaIQBckgdw/BpA0pcXcLUBPANfi4h1Q9Flw871kdLAllP4Q/4kbDR2i2blt VDUbuowa8BicX3XsBIZiAEwXPLZz6wY1WNlND98Fen4t+UXFNRfxI0gRT4SCeL2KEgDZ WAEg==
Received: by 10.224.200.198 with SMTP id ex6mr14989498qab.63.1335218528506; Mon, 23 Apr 2012 15:02:08 -0700 (PDT)
Received: from [192.168.1.213] (190-20-21-61.baf.movistar.cl. [190.20.21.61]) by mx.google.com with ESMTPS id i8sm23795741qah.4.2012.04.23.15.02.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 15:02:05 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_71CDB5B8-65E9-4C0C-BE5E-CB7C1F412AAF"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: 
Date: Mon, 23 Apr 2012 19:01:57 -0300
Message-Id: <21099CC3-A7FD-45F8-983B-26D27382CC97@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com>  <599EB342-8023-453D-977E-DC318637B6E9@ve7jtb.com> <4F95A0C9.3020303@stpeter.im>  
To: Blaine Cook 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQlLQ+06bWTFKNGvF2tQGP/jpAiPMIE5FYSYDoRmYuwHIpGYViytVpEjvmNMm1Phyppr3Spx
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 22:02:12 -0000

--Apple-Mail=_71CDB5B8-65E9-4C0C-BE5E-CB7C1F412AAF
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FE55B7BA-D2D0-493D-9CE2-68C4CACB30F8"


--Apple-Mail=_FE55B7BA-D2D0-493D-9CE2-68C4CACB30F8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Blaine,

Rewrite rules could also be used if scripts are not possible.

I am mostly making the third argument.
Make a GET and retrieve the desired JRD.

I don't think we are talking about the SWD_service_redirect currently.

If the response can't be directly retuned, you would issue a 3xx =
redirect to the static file.

We need to make clients simple.  There are far more clients than =
servers.

John B.

On 2012-04-23, at 6:44 PM, Blaine Cook wrote:

> On 23 April 2012 22:14, John Bradley  wrote:
> It is not my assumption.  =20
>=20
> =46rom a practical point of view with openID Connect, you couldn't =
host a IdP on a server that only supports static pages.
>=20
> Really? I disagree. My domain, romeda.org, has only static pages on =
the root domain. I've done this intentionally, because I don't have time =
to maintain potentially exploitable scripts on a personal domain.
>=20
> My domain is also a valid IdP; fetching /.well-known/host-meta works, =
and so does following the LRDD URI. If you use a valid email address =
(blaine@romeda.org; just a dummy address, please don't email it), you'll =
be given a valid OpenID Server link (it points to Google, whom I trust =
to run an OpenID provider securely more than I trust myself).
> =20
> I think that Paul's example of a site supporting
> curl -v =
https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paulej@p=
acketizer.com
>=20
> Is the bar.   There are several ways to do that, so I don't think it =
is unreasonable.
>=20
> The arguments I've heard for this are:
>=20
> 1. Providers can't handle the load of 50% more requests (this argument =
is bunk, so we'll dismiss it unless someone provides compelling evidence =
otherwise).
> 2. Mobile clients can't handle the additional latency.
> 3. A uniform API is nice-to-have. Having a two-stage lookup ruins that =
uniformity.
>=20
> First, argument #2: SPDY and the availability (and likelihood of =
usage) of proxies means this argument is slim in the face of making it =
easy for anyone to serve a host-meta document.
>=20
> Argument 3 is genuinely interesting. After doing some experiments =
though[1], my conclusion is still that it's easier to write reliable =
client code with the two-phase process. Clients that support the =
SWD_service_redirect JSON response need to be written either with a =
while() loop or using recursive functions. These are vastly more =
complicated, and because there's no assumption that the =
SWD_service_redirect is global, caching won't work globally nor is it =
possible to reuse the SWD_service_redirect response.
>=20
> If we're going to go with a parameters-first approach, I'd like to see =
those issues addressed. I like the uniform protocol flow, but if it =
means everyone needs to write recursive functions, it's less than ideal.
>=20
> b.
>=20
> [1] https://gist.github.com/b52a05bf14b0d4b5ce18


--Apple-Mail=_FE55B7BA-D2D0-493D-9CE2-68C4CACB30F8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On 23 April 2012 22:14, John =
Bradley <ve7jtb@ve7jtb.com> wrote:



It is not my assumption. =
  

=46rom a practical point of view with =
openID Connect, you couldn't host a IdP on a server that only supports =
static pages.




Really? I disagree. My domain, romeda.org, has only static pages on the =
root domain. I've done this intentionally, because I don't have time to =
maintain potentially exploitable scripts on a personal domain.




My domain is also a valid IdP; fetching =
/.well-known/host-meta works, and so does following the LRDD URI. If you =
use a valid email address (blaine@romeda.org; just a dummy =
address, please don't email it), you'll be given a valid OpenID Server =
link (it points to Google, whom I trust to run an OpenID provider =
securely more than I trust myself).



 
I think that Paul's example of a =
site supporting







Is the bar.   There are several ways to =
do that, so I don't think it is =
unreasonable.

The arguments =
I've heard for this are:




1. Providers can't handle the load of 50% more requests (this =
argument is bunk, so we'll dismiss it unless someone provides compelling =
evidence otherwise).
2. Mobile clients can't handle the =
additional latency.



3. A uniform API is nice-to-have. Having a two-stage lookup ruins =
that uniformity.

First, argument #2: SPDY and =
the availability (and likelihood of usage) of proxies means this =
argument is slim in the face of making it easy for anyone to serve a =
host-meta document.




Argument 3 is genuinely interesting. After doing =
some experiments though[1], my conclusion is still that it's easier to =
write reliable client code with the two-phase process. Clients that =
support the SWD_service_redirect JSON response need to be written either =
with a while() loop or using recursive functions. These are vastly more =
complicated, and because there's no assumption that the =
SWD_service_redirect is global, caching won't work globally nor is it =
possible to reuse the SWD_service_redirect response.




If we're going to go with a parameters-first =
approach, I'd like to see those issues addressed. I like the uniform =
protocol flow, but if it means everyone needs to write recursive =
functions, it's less than ideal.




b.




=

--Apple-Mail=_FE55B7BA-D2D0-493D-9CE2-68C4CACB30F8--

--Apple-Mail=_71CDB5B8-65E9-4C0C-BE5E-CB7C1F412AAF
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
MzIyMDE1OFowIwYJKoZIhvcNAQkEMRYEFFg/X3o1WRE/ioSuyKAQv6+LQDjgMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AKBukkNcj34deeLZWBfxVZ6W+pKlKz2LcTL/tbctO5DHtnmHyd1vQ98rhTANGNts6qG2PQGMfDQ6
8Y5tF5T+cpwOLSsXtcwCBJrQYOT2L7htcr4wHey2M5fu1CUHzv/XDBJVoBVSIQumXlyAJYH9CQOo
pKFNMQMje8gu/UNZdlCZYBLUlVT/lRoGO6LugCu3ngPsGBmSTPoos0TzOPd/7Lu4qmdqSkarFrcU
q/zjuxatxFZCLK+f4e8XrloIe+X48l1T3Ko9ioqHvBUM1xNSphvMQtjo8kn3wPbQYZ7ivoZCY1au
CjigoKvcd1G/GoWaTI6thU4TudaE3Je2MpfP/owAAAAAAAA=

--Apple-Mail=_71CDB5B8-65E9-4C0C-BE5E-CB7C1F412AAF--

From stpeter@stpeter.im  Mon Apr 23 15:05: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 D77F321F8594 for ; Mon, 23 Apr 2012 15:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.609
X-Spam-Level: 
X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giAKJ9yCsAwz for ; Mon, 23 Apr 2012 15:05:32 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1950921F8593 for ; Mon, 23 Apr 2012 15:05:32 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1859E40058; Mon, 23 Apr 2012 16:20:02 -0600 (MDT)
Message-ID: <4F95D22A.6060500@stpeter.im>
Date: Mon, 23 Apr 2012 16:05:30 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Carsten Bormann 
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org>
In-Reply-To: <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org application-layer protocols" , Cullen Jennings 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Apr 2012 22:05:33 -0000

On 4/23/12 2:28 PM, Carsten Bormann wrote:
> My 5-line summary is:

Thanks for the summary!

> 1) EXI may or may not be a content-encoding in its schemaless form, but we don't care about that, we use EXI schema-informed mode.
> 
> 2) +exi is considered undesirable for schema-informed EXI.
> So we should go to an EXI specific media type, let's call that -exi.
> 
> This means three media types for SenML
> 
> application/senml+json
> application/senml+xml
> application/senml-exi
> 
> The third media type would in particular nail down the way EXI is used in schema-informed mode.

Although it's not beautiful, I can see why we've ended up at #3 and it
seems like the least-worst solution at this point.

Peter

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



From romeda@gmail.com  Mon Apr 23 15:25: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 EF2E221E804A for ; Mon, 23 Apr 2012 15:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.492
X-Spam-Level: 
X-Spam-Status: No, score=-103.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyteeKrRvvmd for ; Mon, 23 Apr 2012 15:25: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 D833321E800F for ; Mon, 23 Apr 2012 15:25:31 -0700 (PDT)
Received: by lbgc1 with SMTP id c1so29061lbg.31 for ; Mon, 23 Apr 2012 15:25:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7+jLMi86xyiMYU0rBpNw2dgNZ/30xuaZ4GrdoxO4hK4=; b=kthQknMLO/bAcgjdma1QbaoRPANWMOq5vXaXpeh8BA0QKbB4zuLkENkThXaTLcnkjI 0gidujnohg6qOfz6LjkHoybEXghQ0L2peZMMomabz9Qv43SO3aabLDuxiOXgfhQl5ciH zf5TssDQucRHOqPQQTxI/R+8bLSIyUAiUWe6LsqPXg0N86On1bHx/9LFh2Jmgx6xD9+a 53PFgaTFCxejx/0BRsN63ygX3sFTegj9WyjBu3Kxa1ATuwB+wJzz0SNt/Dq5cuo5reJX PJFysqHIdWHxZoFqrruK6c+dWnwDfiNLNi3bA8+tVt7ZZXPcazHW8sBpdo5+aZZA0sfw aIQg==
Received: by 10.152.146.163 with SMTP id td3mr12126308lab.25.1335219930834; Mon, 23 Apr 2012 15:25:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.24.229 with HTTP; Mon, 23 Apr 2012 15:25:10 -0700 (PDT)
In-Reply-To: <21099CC3-A7FD-45F8-983B-26D27382CC97@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com>  <599EB342-8023-453D-977E-DC318637B6E9@ve7jtb.com> <4F95A0C9.3020303@stpeter.im>   <21099CC3-A7FD-45F8-983B-26D27382CC97@ve7jtb.com>
From: Blaine Cook 
Date: Mon, 23 Apr 2012 23:25:10 +0100
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=e89a8f234567aca74f04be601da5
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 22:25:33 -0000

--e89a8f234567aca74f04be601da5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 23 April 2012 23:01, John Bradley  wrote:

> Blaine,
>
> Rewrite rules could also be used if scripts are not possible.
>
> I am mostly making the third argument.
> Make a GET and retrieve the desired JRD.
>
> I don't think we are talking about the SWD_service_redirect currently.
>
> If the response can't be directly retuned, you would issue a 3xx redirect
> to the static file.
>

Have you tried setting up redirects on statically hosted domains? If you
have .htaccess support, it might be possible, but in practice even if
someone with a domain *does* have access to .htaccess, they probably don't
know how to configure mod_rewrite.

I've often heard the "if only DNS servers were easier", "if only it were
easier to register a domain" complaints; DNS is great, but it requires a
lot of involvement from experts. As far as I'm concerned, webfinger/swd
only works if EVERY domain with a webpage can serve it, and if EVERY domain
owner can get it to work without too much fuss.


>  We need to make clients simple.  There are far more clients than servers=
.
>

Agreed =E2=80=93 following redirects isn't hard, but I'm not convinced that
redirects are really deployable; also, it's worth noting that for the
"brain-dead" redirect scenario, the server-side needs to properly rewrite
the query string. :-/

DNS has different discovery paths for recursive queries versus "normal"
queries. I'm not sure why we shouldn't have the same approach here.

I've mentioned a few times that we could take the approach with
webfinger/swd that DNS did, and have dumb clients use a proxy server that
does the full recursive lookup on dumb clients' behalf. I think that solves
both problems, no?

b.

--e89a8f234567aca74f04be601da5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On 23 April 2012 23:01, John Bradley <ve7jtb@=
ve7jtb.com> wrote:



Blaine,

Rewrite rule=
s could also be used if scripts are not possible.

=
I am mostly making the third argument.
Make a GET and retrieve th=
e desired JRD.




I don't think we are talking about the SWD_service_=
redirect currently.

If the response can't be d=
irectly retuned, you would issue a 3xx redirect to the static file.




Have you tried setting up redirects =
on statically hosted domains? If you have .htaccess support, it might be po=
ssible, but in practice even if someone with a domain *does* have access to=
 .htaccess, they probably don't know how to configure mod_rewrite.



I've often heard the "if only DNS servers were=
 easier", "if only it were easier to register a domain" comp=
laints; DNS is great, but it requires a lot of involvement from experts. As=
 far as I'm concerned, webfinger/swd only works if EVERY domain with a =
webpage can serve it, and if EVERY domain owner can get it to work without =
too much fuss.



=C2=A0
=C2=A0We need to make clients simple. =C2=A0There are far mor=
e clients than servers.




Agreed =E2=80=93 following redirects=
 isn't hard, but I'm not convinced that redirects are really deploy=
able; also, it's worth noting that for the "brain-dead" redir=
ect scenario, the server-side needs to properly rewrite the query string. :=
-/




DNS has different discovery paths for recursive queries=
 versus "normal" queries. I'm not sure why we shouldn't h=
ave the same approach here.

I've mentioned a f=
ew times that we could take the approach with webfinger/swd that DNS did, a=
nd have dumb clients use a proxy server that does the full recursive lookup=
 on dumb clients' behalf. I think that solves both problems, no?




b.=C2=A0


--e89a8f234567aca74f04be601da5--

From Michael.Jones@microsoft.com  Mon Apr 23 15: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 1BB2B21E800F for ; Mon, 23 Apr 2012 15:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.908
X-Spam-Level: 
X-Spam-Status: No, score=-3.908 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dPhFKS2yw6z for ; Mon, 23 Apr 2012 15:30:49 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id B425221E8048 for ; Mon, 23 Apr 2012 15:30:48 -0700 (PDT)
Received: from mail16-db3-R.bigfish.com (10.3.81.243) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 23 Apr 2012 22:30:47 +0000
Received: from mail16-db3 (localhost [127.0.0.1])	by mail16-db3-R.bigfish.com (Postfix) with ESMTP id 3ACA23201D3; Mon, 23 Apr 2012 22:30:47 +0000 (UTC)
X-SpamScore: -45
X-BigFish: VS-45(z21aILz9371Ic89bh1418Ic857h98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail16-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail16-db3 (localhost.localdomain [127.0.0.1]) by mail16-db3 (MessageSwitch) id 1335220244741788_21149; Mon, 23 Apr 2012 22:30:44 +0000 (UTC)
Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.232])	by mail16-db3.bigfish.com (Postfix) with ESMTP id A4E564005A; Mon, 23 Apr 2012 22:30:44 +0000 (UTC)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 23 Apr 2012 22:30:43 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0283.004; Mon, 23 Apr 2012 22:30:24 +0000
From: Mike Jones 
To: Blaine Cook , John Bradley 
Thread-Topic: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
Thread-Index: Ac0hoKqUYpBy2tJxRXSHHzNPsZNFfw==
Date: Mon, 23 Apr 2012 22:30:23 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943664959C2@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.78]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943664959C2TK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 22:30:50 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943664959C2TK5EX14MBXC284r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

WW91IHdyb3RlIOKAnHdlIGNvdWxkIHRha2UgdGhlIGFwcHJvYWNoIHdpdGggd2ViZmluZ2VyL3N3
ZCB0aGF0IEROUyBkaWQsIGFuZCBoYXZlIGR1bWIgY2xpZW50cyB1c2UgYSBwcm94eSBzZXJ2ZXIg
dGhhdCBkb2VzIHRoZSBmdWxsIHJlY3Vyc2l2ZSBsb29rdXAgb24gZHVtYiBjbGllbnRzJyBiZWhh
bGbigJ0uICBJIHVuZGVyc3RhbmQgeW91ciBhcmd1bWVudCB0aGF0IHByb3h5IHNlcnZlcnMgY291
bGQgYmUgdXNlZCB0byByZWR1Y2UgbGF0ZW5jeSBhbmQvb3IgbWFrZSBjbGllbnRzIHNpbXBsZXIs
IGJ1dCBhdCB0aGF0IHBvaW50LCB5b3XigJl2ZSBlZmZlY3RpdmVseSBjb25jZWRlZCB0aGUgaW1w
b3J0YW5jZSBvZiBzaW5nbGUtR0VUIGRpc2NvdmVyeSwgYW5kIGlmIHNvLCB0aGUg4oCccmVhbOKA
nSBkaXNjb3ZlcnkgcHJvdG9jb2wgYmVjb21lcyB0aGUgY2xpZW50LXRvLXByb3h5IHByb3RvY29s
LiAgQnV0IHVubGVzcyB0aGUgY2xpZW50LXRvLXByb3h5IHByb3RvY29sIGlzIGFsc28gcGFydCBv
ZiB0aGUgc3RhbmRhcmQsIHlvdeKAmXJlIGVmZmVjdGl2ZWx5IHN1Z2dlc3RpbmcgYSBzb2x1dGlv
biBpbiB3aGljaCBhIGxhcmdlIHBvcnRpb24gb2YgdGhlIGNsaWVudHMgYXJlIG5vdCB1c2luZyB0
aGUgc3RhbmRhcmQgYXQgYWxsLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBhcHBzLWRpc2N1
c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3Jn
XSBPbiBCZWhhbGYgT2YgQmxhaW5lIENvb2sNClNlbnQ6IE1vbmRheSwgQXByaWwgMjMsIDIwMTIg
MzoyNSBQTQ0KVG86IEpvaG4gQnJhZGxleQ0KQ2M6IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KU3Vi
amVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFdlYmZpbmdlciAvIFNXRCBJc3N1ZSAjMzogZGlyZWN0
IHZlcnN1cyBpbmRpcmVjdCBkaXNjb3ZlcnkNCg0KT24gMjMgQXByaWwgMjAxMiAyMzowMSwgSm9o
biBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3
cm90ZToNCkJsYWluZSwNCg0KUmV3cml0ZSBydWxlcyBjb3VsZCBhbHNvIGJlIHVzZWQgaWYgc2Ny
aXB0cyBhcmUgbm90IHBvc3NpYmxlLg0KDQpJIGFtIG1vc3RseSBtYWtpbmcgdGhlIHRoaXJkIGFy
Z3VtZW50Lg0KTWFrZSBhIEdFVCBhbmQgcmV0cmlldmUgdGhlIGRlc2lyZWQgSlJELg0KDQpJIGRv
bid0IHRoaW5rIHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZSBTV0Rfc2VydmljZV9yZWRpcmVjdCBj
dXJyZW50bHkuDQoNCklmIHRoZSByZXNwb25zZSBjYW4ndCBiZSBkaXJlY3RseSByZXR1bmVkLCB5
b3Ugd291bGQgaXNzdWUgYSAzeHggcmVkaXJlY3QgdG8gdGhlIHN0YXRpYyBmaWxlLg0KDQpIYXZl
IHlvdSB0cmllZCBzZXR0aW5nIHVwIHJlZGlyZWN0cyBvbiBzdGF0aWNhbGx5IGhvc3RlZCBkb21h
aW5zPyBJZiB5b3UgaGF2ZSAuaHRhY2Nlc3Mgc3VwcG9ydCwgaXQgbWlnaHQgYmUgcG9zc2libGUs
IGJ1dCBpbiBwcmFjdGljZSBldmVuIGlmIHNvbWVvbmUgd2l0aCBhIGRvbWFpbiAqZG9lcyogaGF2
ZSBhY2Nlc3MgdG8gLmh0YWNjZXNzLCB0aGV5IHByb2JhYmx5IGRvbid0IGtub3cgaG93IHRvIGNv
bmZpZ3VyZSBtb2RfcmV3cml0ZS4NCg0KSSd2ZSBvZnRlbiBoZWFyZCB0aGUgImlmIG9ubHkgRE5T
IHNlcnZlcnMgd2VyZSBlYXNpZXIiLCAiaWYgb25seSBpdCB3ZXJlIGVhc2llciB0byByZWdpc3Rl
ciBhIGRvbWFpbiIgY29tcGxhaW50czsgRE5TIGlzIGdyZWF0LCBidXQgaXQgcmVxdWlyZXMgYSBs
b3Qgb2YgaW52b2x2ZW1lbnQgZnJvbSBleHBlcnRzLiBBcyBmYXIgYXMgSSdtIGNvbmNlcm5lZCwg
d2ViZmluZ2VyL3N3ZCBvbmx5IHdvcmtzIGlmIEVWRVJZIGRvbWFpbiB3aXRoIGEgd2VicGFnZSBj
YW4gc2VydmUgaXQsIGFuZCBpZiBFVkVSWSBkb21haW4gb3duZXIgY2FuIGdldCBpdCB0byB3b3Jr
IHdpdGhvdXQgdG9vIG11Y2ggZnVzcy4NCg0KIFdlIG5lZWQgdG8gbWFrZSBjbGllbnRzIHNpbXBs
ZS4gIFRoZXJlIGFyZSBmYXIgbW9yZSBjbGllbnRzIHRoYW4gc2VydmVycy4NCg0KQWdyZWVkIOKA
kyBmb2xsb3dpbmcgcmVkaXJlY3RzIGlzbid0IGhhcmQsIGJ1dCBJJ20gbm90IGNvbnZpbmNlZCB0
aGF0IHJlZGlyZWN0cyBhcmUgcmVhbGx5IGRlcGxveWFibGU7IGFsc28sIGl0J3Mgd29ydGggbm90
aW5nIHRoYXQgZm9yIHRoZSAiYnJhaW4tZGVhZCIgcmVkaXJlY3Qgc2NlbmFyaW8sIHRoZSBzZXJ2
ZXItc2lkZSBuZWVkcyB0byBwcm9wZXJseSByZXdyaXRlIHRoZSBxdWVyeSBzdHJpbmcuIDotLw0K
DQpETlMgaGFzIGRpZmZlcmVudCBkaXNjb3ZlcnkgcGF0aHMgZm9yIHJlY3Vyc2l2ZSBxdWVyaWVz
IHZlcnN1cyAibm9ybWFsIiBxdWVyaWVzLiBJJ20gbm90IHN1cmUgd2h5IHdlIHNob3VsZG4ndCBo
YXZlIHRoZSBzYW1lIGFwcHJvYWNoIGhlcmUuDQoNCkkndmUgbWVudGlvbmVkIGEgZmV3IHRpbWVz
IHRoYXQgd2UgY291bGQgdGFrZSB0aGUgYXBwcm9hY2ggd2l0aCB3ZWJmaW5nZXIvc3dkIHRoYXQg
RE5TIGRpZCwgYW5kIGhhdmUgZHVtYiBjbGllbnRzIHVzZSBhIHByb3h5IHNlcnZlciB0aGF0IGRv
ZXMgdGhlIGZ1bGwgcmVjdXJzaXZlIGxvb2t1cCBvbiBkdW1iIGNsaWVudHMnIGJlaGFsZi4gSSB0
aGluayB0aGF0IHNvbHZlcyBib3RoIHByb2JsZW1zLCBubz8NCg0KYi4NCg==

--_000_4E1F6AAD24975D4BA5B1680429673943664959C2TK5EX14MBXC284r_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+WW91IHdyb3RlIOKAnDwv
c3Bhbj53ZSBjb3VsZCB0YWtlIHRoZSBhcHByb2FjaCB3aXRoIHdlYmZpbmdlci9zd2QgdGhhdCBE
TlMgZGlkLCBhbmQgaGF2ZSBkdW1iIGNsaWVudHMgdXNlIGEgcHJveHkgc2VydmVyIHRoYXQgZG9l
cyB0aGUgZnVsbCByZWN1cnNpdmUgbG9va3VwIG9uDQogZHVtYiBjbGllbnRzJyBiZWhhbGY8c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+4oCdLiZuYnNwOw0KPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHVuZGVyc3RhbmQg
eW91ciBhcmd1bWVudCB0aGF0IHByb3h5IHNlcnZlcnMgY291bGQgYmUgdXNlZCB0byByZWR1Y2Ug
bGF0ZW5jeSBhbmQvb3IgbWFrZSBjbGllbnRzIHNpbXBsZXIsIGJ1dCBhdCB0aGF0IHBvaW50LCB5
b3XigJl2ZSBlZmZlY3RpdmVseSBjb25jZWRlZCB0aGUgaW1wb3J0YW5jZSBvZg0KIHNpbmdsZS1H
RVQgZGlzY292ZXJ5LCBhbmQgaWYgc28sIHRoZSDigJxyZWFs4oCdIGRpc2NvdmVyeSBwcm90b2Nv
bCBiZWNvbWVzIHRoZSBjbGllbnQtdG8tcHJveHkgcHJvdG9jb2wuJm5ic3A7IEJ1dCB1bmxlc3Mg
dGhlIGNsaWVudC10by1wcm94eSBwcm90b2NvbCBpcyBhbHNvIHBhcnQgb2YgdGhlIHN0YW5kYXJk
LCB5b3XigJlyZSBlZmZlY3RpdmVseSBzdWdnZXN0aW5nIGEgc29sdXRpb24gaW4gd2hpY2ggYSBs
YXJnZSBwb3J0aW9uIG9mIHRoZSBjbGllbnRzIGFyZQ0KIG5vdCB1c2luZyB0aGUgc3RhbmRhcmQg
YXQgYWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0t
IE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGFwcHMtZGlz
Y3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5v
cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJsYWluZSBDb29rPGJyPg0KPGI+U2VudDo8L2I+IE1v
bmRheSwgQXByaWwgMjMsIDIwMTIgMzoyNSBQTTxicj4NCjxiPlRvOjwvYj4gSm9obiBCcmFkbGV5
PGJyPg0KPGI+Q2M6PC9iPiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gUmU6IFthcHBzLWRpc2N1c3NdIFdlYmZpbmdlciAvIFNXRCBJc3N1ZSAjMzogZGlyZWN0IHZl
cnN1cyBpbmRpcmVjdCBkaXNjb3Zlcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5PbiAyMyBBcHJpbCAyMDEyIDIzOjAxLCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1h
aWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29t
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g
MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CbGFpbmUsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5SZXdyaXRlIHJ1bGVzIGNvdWxkIGFsc28gYmUgdXNlZCBpZiBz
Y3JpcHRzIGFyZSBub3QgcG9zc2libGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbW9zdGx5IG1ha2luZyB0aGUgdGhpcmQgYXJndW1l
bnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N
YWtlIGEgR0VUIGFuZCByZXRyaWV2ZSB0aGUgZGVzaXJlZCBKUkQuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgd2UgYXJl
IHRhbGtpbmcgYWJvdXQgdGhlIFNXRF9zZXJ2aWNlX3JlZGlyZWN0IGN1cnJlbnRseS48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIHJl
c3BvbnNlIGNhbid0IGJlIGRpcmVjdGx5IHJldHVuZWQsIHlvdSB3b3VsZCBpc3N1ZSBhIDN4eCBy
ZWRpcmVjdCB0byB0aGUgc3RhdGljIGZpbGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGF2ZSB5b3Ug
dHJpZWQgc2V0dGluZyB1cCByZWRpcmVjdHMgb24gc3RhdGljYWxseSBob3N0ZWQgZG9tYWlucz8g
SWYgeW91IGhhdmUgLmh0YWNjZXNzIHN1cHBvcnQsIGl0IG1pZ2h0IGJlIHBvc3NpYmxlLCBidXQg
aW4gcHJhY3RpY2UgZXZlbiBpZiBzb21lb25lIHdpdGggYSBkb21haW4gKmRvZXMqIGhhdmUgYWNj
ZXNzIHRvIC5odGFjY2VzcywgdGhleSBwcm9iYWJseSBkb24ndCBrbm93IGhvdyB0byBjb25maWd1
cmUNCiBtb2RfcmV3cml0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SSd2ZSBvZnRlbiBoZWFyZCB0aGUgJnF1b3Q7aWYgb25seSBETlMgc2Vy
dmVycyB3ZXJlIGVhc2llciZxdW90OywgJnF1b3Q7aWYgb25seSBpdCB3ZXJlIGVhc2llciB0byBy
ZWdpc3RlciBhIGRvbWFpbiZxdW90OyBjb21wbGFpbnRzOyBETlMgaXMgZ3JlYXQsIGJ1dCBpdCBy
ZXF1aXJlcyBhIGxvdCBvZiBpbnZvbHZlbWVudCBmcm9tIGV4cGVydHMuIEFzIGZhciBhcyBJJ20g
Y29uY2VybmVkLCB3ZWJmaW5nZXIvc3dkIG9ubHkgd29ya3MgaWYgRVZFUlkNCiBkb21haW4gd2l0
aCBhIHdlYnBhZ2UgY2FuIHNlcnZlIGl0LCBhbmQgaWYgRVZFUlkgZG9tYWluIG93bmVyIGNhbiBn
ZXQgaXQgdG8gd29yayB3aXRob3V0IHRvbyBtdWNoIGZ1c3MuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND
Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt
YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7V2UgbmVlZCB0byBtYWtlIGNsaWVudHMgc2ltcGxlLiAmbmJzcDtUaGVyZSBhcmUgZmFyIG1v
cmUgY2xpZW50cyB0aGFuIHNlcnZlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkIOKAkyBm
b2xsb3dpbmcgcmVkaXJlY3RzIGlzbid0IGhhcmQsIGJ1dCBJJ20gbm90IGNvbnZpbmNlZCB0aGF0
IHJlZGlyZWN0cyBhcmUgcmVhbGx5IGRlcGxveWFibGU7IGFsc28sIGl0J3Mgd29ydGggbm90aW5n
IHRoYXQgZm9yIHRoZSAmcXVvdDticmFpbi1kZWFkJnF1b3Q7IHJlZGlyZWN0IHNjZW5hcmlvLCB0
aGUgc2VydmVyLXNpZGUgbmVlZHMgdG8gcHJvcGVybHkgcmV3cml0ZSB0aGUgcXVlcnkgc3RyaW5n
LiA6LS88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+RE5TIGhhcyBkaWZmZXJlbnQgZGlzY292ZXJ5IHBhdGhzIGZvciByZWN1cnNpdmUgcXVlcmll
cyB2ZXJzdXMgJnF1b3Q7bm9ybWFsJnF1b3Q7IHF1ZXJpZXMuIEknbSBub3Qgc3VyZSB3aHkgd2Ug
c2hvdWxkbid0IGhhdmUgdGhlIHNhbWUgYXBwcm9hY2ggaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSd2ZSBtZW50aW9uZWQgYSBmZXcg
dGltZXMgdGhhdCB3ZSBjb3VsZCB0YWtlIHRoZSBhcHByb2FjaCB3aXRoIHdlYmZpbmdlci9zd2Qg
dGhhdCBETlMgZGlkLCBhbmQgaGF2ZSBkdW1iIGNsaWVudHMgdXNlIGEgcHJveHkgc2VydmVyIHRo
YXQgZG9lcyB0aGUgZnVsbCByZWN1cnNpdmUgbG9va3VwIG9uIGR1bWIgY2xpZW50cycgYmVoYWxm
LiBJIHRoaW5rIHRoYXQgc29sdmVzIGJvdGggcHJvYmxlbXMsIG5vPzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iLiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_4E1F6AAD24975D4BA5B1680429673943664959C2TK5EX14MBXC284r_--

From romeda@gmail.com  Mon Apr 23 15:40: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 3F66F11E808F for ; Mon, 23 Apr 2012 15:40:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.505
X-Spam-Level: 
X-Spam-Status: No, score=-103.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SucJWf8Zis4P for ; Mon, 23 Apr 2012 15:40:05 -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 49C6011E8075 for ; Mon, 23 Apr 2012 15:40:05 -0700 (PDT)
Received: by lbgc1 with SMTP id c1so36328lbg.31 for ; Mon, 23 Apr 2012 15:40:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=736fX/Kvg+37Djhxv9B/sldsh/fnZl1aBP9H9IZ+OZc=; b=yfPBpCbww8KXFX/6kFfCaz8hm3M7FOcjVrRe0nC8gCi5ZwupEhSVymrLzx/Unrrc1Z OFb/gL6bEzR9l6ddBTG55AXiS9NHvR9NkYzcYORYZa4p/jFPyVEt4VMA1/nKADiLpMkA I6/+w4e1mlzTMHGgzKo7ibFUvI92m0Y1E0i0lLuLA3H4sjcRsoTnsjAxW1FAYi3xCWzH 5spShc6BkaNU4oYyplBpDJodsvrpxQCMXhjQDlsijZbm3tjCqBZGWM4gzoZLwAtgXX8Q MKfAcyMLC2ODwHsPKnMx7YsExUK5efT8CFavf8c7qm0sUjQkEDkFQUJuK3mEXs/oyizI W7HA==
Received: by 10.112.85.230 with SMTP id k6mr2953918lbz.49.1335220804206; Mon, 23 Apr 2012 15:40:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.24.229 with HTTP; Mon, 23 Apr 2012 15:39:44 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664959C2@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B1680429673943664959C2@TK5EX14MBXC284.redmond.corp.microsoft.com>
From: Blaine Cook 
Date: Mon, 23 Apr 2012 23:39:44 +0100
Message-ID: 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=f46d0401fa11bb3ffc04be6051f4
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 22:40:06 -0000

--f46d0401fa11bb3ffc04be6051f4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 23 April 2012 23:30, Mike Jones  wrote:

>  You wrote =E2=80=9Cwe could take the approach with webfinger/swd that DN=
S did,
> and have dumb clients use a proxy server that does the full recursive
> lookup on dumb clients' behalf=E2=80=9D.  I understand your argument that=
 proxy
> servers could be used to reduce latency and/or make clients simpler, but =
at
> that point, you=E2=80=99ve effectively conceded the importance of single-=
GET
> discovery, and if so, the =E2=80=9Creal=E2=80=9D discovery protocol becom=
es the
> client-to-proxy protocol.  But unless the client-to-proxy protocol is als=
o
> part of the standard, you=E2=80=99re effectively suggesting a solution in=
 which a
> large portion of the clients are not using the standard at all.
>

No =E2=80=93 sorry for not being clear. My proposal is this:

1. Use host-meta to discover the authoritative URI for webfinger profiles
for a given domain.
2. Make a standardised request against the authoritative URI. e.g.,

GET ${uri-from-host-meta}?address=3D{address}[&resource=3D{resource}]

For clients that don't implement the full protocol, all that would be
necessary would be to decide on a webfinger server URL that the client
would trust and make the same request as in #2.

Does that work?

b.

--f46d0401fa11bb3ffc04be6051f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On 23 April 2012 23:30, Mike Jones <M=
ichael.Jones@microsoft.com> wrote:













You wrote =E2=80=9Cwe could take the approach with webfinger/swd that DNS did, and have dumb =
clients use a proxy server that does the full recursive lookup on
 dumb clients' behalf=E2=80=9D.=C2=A0
I understand your argument that proxy ser=
vers could be used to reduce latency and/or make clients simpler, but at th=
at point, you=E2=80=99ve effectively conceded the importance of
 single-GET discovery, and if so, the =E2=80=9Creal=E2=80=9D discovery prot=
ocol becomes the client-to-proxy protocol.=C2=A0 But unless the client-to-p=
roxy protocol is also part of the standard, you=E2=80=99re effectively sugg=
esting a solution in which a large portion of the clients are
 not using the standard at all.
No =E2=80=93 sorry for not being clear. My proposal is this:

1. Use host-meta to discover the authoritative URI f=
or webfinger profiles for a given domain.



2. Make a standardised request against the authoritative URI. e.g.,

GET ${uri-from-host-meta}?address=3D{address}[&r=
esource=3D{resource}]

For clients that don't i=
mplement the full protocol, all that would be necessary would be to decide =
on a webfinger server URL that the client would trust and make the same req=
uest as in #2.




Does that work?

b.
=



--f46d0401fa11bb3ffc04be6051f4--

From ted.ietf@gmail.com  Mon Apr 23 16:23: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 08E3911E8072; Mon, 23 Apr 2012 16:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.566
X-Spam-Level: 
X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDA4i+YX0-e3; Mon, 23 Apr 2012 16:23:13 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D75A121F858E; Mon, 23 Apr 2012 16:23:12 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so66620vcb.31 for ; Mon, 23 Apr 2012 16:23:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zgOhZCtMMZBX8f8l7wJStTqBdHYFBCA0XATAku38pdY=; b=VYofs8pGYCKBGppoSEcg4oEIQSEIc+w6lLPd6U/SWd18C/c+YoSx7Dm3gz564q35zm Lw5bvz/MAqUcTjJKJT7HG9p8t4GW60aXDHzV+ZxTAWbRjW/P8D6q4zhE5D/6CnuoLwpp PN6IcyVosRkc28951EUSi3QMLnx/Mim9PgbjbvMeBnDs8YS+isnCcBgyoM5PcS2zIWou sTzAgpkECxDbzxv0h1EqVmoeopkrERD49NGWcoVFBDgq0iigxAbFAgfvQ0tQIWgx8fOH d3sq4Ho+Set7LtJXENarlt7OO1/UuajxnftpSvydIbYUjRlKT9m6pCczJm50LdUBwlzP nzVg==
MIME-Version: 1.0
Received: by 10.52.35.12 with SMTP id d12mr14879944vdj.99.1335223392381; Mon, 23 Apr 2012 16:23:12 -0700 (PDT)
Received: by 10.52.162.99 with HTTP; Mon, 23 Apr 2012 16:23:12 -0700 (PDT)
In-Reply-To: <4F95D991.5010603@gulbrandsen.priv.no>
References:  <4F95D991.5010603@gulbrandsen.priv.no>
Date: Mon, 23 Apr 2012 16:23:12 -0700
Message-ID: 
From: Ted Hardie 
To: Arnt Gulbrandsen 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: draft-ietf-eai-simpledowngrade.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Review of draft-ietf-eai-simpledowngrade-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, 23 Apr 2012 23:23:14 -0000

Hi Arnt,

Thanks for your quick reply.  I've added the apps-discuss list to the
distribution; I forgot them on the original, though they are usually
cc'ed on appsdir reviews.

Further comments in-line.

On Mon, Apr 23, 2012 at 3:37 PM, Arnt Gulbrandsen
 wrote:
> I disgree with much of this.
>
> First off, this draft concerns itself with a corner case. The entire draf=
t
> is about what happens when two programs that cannot communicate, do.
> Considering this impairment, it's difficult for me to speak if "major los=
s
> of information" or "significant problems".
>
> Further, I think that some of what you describe as problems aren't proble=
ms
> with this draft, but rather with the coexistence of internationalized and
> conventional mail. If you accept that internationalized and conventional
> mail coexist, then you have to accept that there'll be problems when
> internationalized mail reaches a conventional client. The inability of
> conventional mail client to do what's needed is the very reason why EAI
> exists.
>

I certainly hope that internationalized mail to conventional mail will
be a corner case,
but I'm not sure my personal crystal ball is clear enough for me to be
certain that will be so.
I think there may be cases where one header or a few headers become
internationalized prior to others
(From, Resent-From, and Subject come to mind).  In those cases,
something like this approach
should be considered.  The question for me is:  for that case (corner
or not), is the result
sufficient to allow a user to assess the resulting message's validity?
 If not, should the document
describing this approach be considered part of the "standards track"
set of mail specifications?

The second question is trickier than the first; I think the first is
clear enough (if you allow the server
to excise large swathes of context, it's going to be hard to judge).
The second question is trickier, and it delves
pretty close to standards theory rather than being limited to this
document.  But my personal assessment
is that this document would do as much good as an informational for
those wanting a specification as it
would as a standards track document, and that keeping it off the
standards track may avoid some
development/deployment by folks seeing this as a valid alternative to
actually deploying an
internationalized system.  That's a personal opinion, and it's not
that strongly held.  I will not fall on my
sword if this goes on to the standards track.

>
> On 04/23/2012 05:57 PM, Ted Hardie wrote:
>>
>> Summary: I believe that the draft is almost ready for publication, but
>> that it cannot be progressed on the standards track because of its
>> impact on the security of the email messages.
>
>
> I disagree strongly.
>
> Signatures generally sign something that includes addresses, and addresse=
s
> cannot be served legally as-is. This makes breaking either POP/IMAP or
> signatures a necessary consequence of having downgrade at all, so that if
> any downgrade document can ever be on the standards document, then breaki=
ng
> signatures must be acceptable.
>
> This draft breaks the signatures in more cases. For instance, it might br=
eak
> a DKIM signature that signs only Content-Disposition and neither To, From=
,
> Cc or Subject. But I'm not going to worry about that. It's simply not
> significant.
>

I am not sure *any* downgrade doc belongs on the standards track, if that h=
elps
clarify my review.  I think losing security characteristics of the
sent message in order
to accomplish post-transformation delivery is a trade-off that raises
general concerns,
especially where a signature is present.

>
>> The document is clear that its intent is to provide a
>> simple-to-implement method that provides basic means for downgrading
>> certain fields in a message. =A0 A major element of its strategy is to
>> silently excise information which cannot be presented to the user.
>
>
> Major?
>
> IMO this is a fair description: Geld the addresses you have to, preserve =
the
> other major stuff, drop the minor stuff.
>
> Mime parameters are near the border. If RFC 2231 were better supported I
> might lean towards doing something with them. But...
>
>
>> This may eliminate MIME parameters (see section 2.2); it may also
>> eliminate any header field not explicitly treated (the subject field
>> and those listed in 2.1). =A0This, combined with the possible invalidity
>> of signatures for signed body parts, can significantly reduce the
>> amount of data available to the user for making a determination of
>> whether or not a message is legitimate.
>
>
> You seem to be describing a user who knows much about internationalized
> mail, who corresponds using internationalized mail, but who has no softwa=
re
> that supports it. Yes, it's hard on that user ;)
>

I think I am describing a conventional user more than an internationalized =
email
user.  If you have an expectation that an email message should contain
certain things
(or your user agent checks for validity by looking for specific
things), this won't even present
you nonsense in some places you are expecting sense.  It simply cuts
the data.  How can
the user or her delegated software assess that?


> My general answer is that the best way to help that user is to spend less
> time on downgrade support and more time on getting EAI support in more
> software.
>

On this, we agree.

>
>> Crafting a message that
>> appeared to have already gone through this encoding also seems
>> relatively easy, making it possible for a sender to provide a message
>> that does not have the normal complement of data for assessment by a
>> user.
>
>
> The assessment data is generally ASCII now, why would that change?
>

If I craft a message without any of the headers that this allows me to
excise and with
.invalid-ed in From and Re-sent From, how can the user or the user
agent distinguish
that from the action of the server here?

>
>> Given this major loss of information,
>
>
> It's difficult to predict the future, but from the mail I've seen the los=
s
> is unlikely to be major.
>
>
>> The document does not describe how it relates to the other two options
>> the working group has discussed for downgrade. =A0I believe it should do
>> so in order to provide context for the choices made here. =A0A review of
>> the mailing list shows this message:
>> http://www.ietf.org/mail-archive/web/ima/current/msg04539.html =A0as
>> kicking off the core rationale and relationship. =A0 Some form of this
>> should be included in the document, possibly along with the "no
>> downgrade" option.
>
>
> I haven't added anything like this, because I'm not sure which document
> should contain it.
>
> I'll happily supply text.
>

Thanks.  A pointer to text in another document would be equally valid.

>
>> This document does not describe how the IMAP/POP downgrade choices
>> here would impact SIEVE script processing; I believe this represents
>> an assumption on when the downgrade takes place which should be made
>> explicit.
>
>
> It isn't?
>
> Would you be happy if the document specifies explicitly that the stored f=
orm
> has to be the original message, not the synthesised form?

Yes, I think that would be a useful addition.

regards,

Ted Hardie

>
>
>> Nits:
>>
>> The document says:
>>
>> =A0 =A0Given an internationalized address "Fred Foo", =
an
>> =A0 =A0implementation may choose to render it e.g. as these examples:
>>
>> "render" is seriously overloaded in this context. =A0Would "encode" work
>> as well here?
>
>
> IMO encode suffers more from overload. But all of the candidate verbs suf=
fer
> to some degree.
>
> Arnt

From ned.freed@mrochek.com  Mon Apr 23 18:16: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 4131221F85DB for ; Mon, 23 Apr 2012 18:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.493
X-Spam-Level: 
X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aEPmvRqI4p5 for ; Mon, 23 Apr 2012 18:16:04 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 79A5F21F8599 for ; Mon, 23 Apr 2012 18:16:01 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEO1DOBOAO0007RB@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 23 Apr 2012 18:15:58 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Mon, 23 Apr 2012 18:15:55 -0700 (PDT)
Message-id: <01OEO1DMECF40006TF@mauve.mrochek.com>
Date: Mon, 23 Apr 2012 18:14:36 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 23 Apr 2012 16:05:30 -0600" <4F95D22A.6060500@stpeter.im>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org> <4F95D22A.6060500@stpeter.im>
To: Peter Saint-Andre 
Cc: Cullen Jennings , "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] New Version Notification for	draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 01:16:05 -0000

> On 4/23/12 2:28 PM, Carsten Bormann wrote:
> > My 5-line summary is:

> Thanks for the summary!

> > 1) EXI may or may not be a content-encoding in its schemaless form, but we don't care about that, we use EXI schema-informed mode.
> >
> > 2) +exi is considered undesirable for schema-informed EXI.
> > So we should go to an EXI specific media type, let's call that -exi.
> >
> > This means three media types for SenML
> >
> > application/senml+json
> > application/senml+xml
> > application/senml-exi
> >
> > The third media type would in particular nail down the way EXI is used in schema-informed mode.

> Although it's not beautiful, I can see why we've ended up at #3 and it
> seems like the least-worst solution at this point.

I have to agree. For better or worse, we didn't think about this case when the
architecture was designed. And as we all know, adding mandatory-to-implement
information fields after the fact doesn't work very well (if at all). So this
is where we end up.

				Ned

From masinter@adobe.com  Mon Apr 23 20:48: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 04E4C21F84D0 for ; Mon, 23 Apr 2012 20:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CVAV6lSLOTZ for ; Mon, 23 Apr 2012 20:48:22 -0700 (PDT)
Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id B986D21F8698 for ; Mon, 23 Apr 2012 20:48:10 -0700 (PDT)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKT5YieW7omiuCRli1eBPuDtX2b89CsKOi@postini.com; Mon, 23 Apr 2012 20:48:22 PDT
Received: from inner-relay-1.corp.adobe.com (inner-relay-1.sea.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q3O3m6sp017076; Mon, 23 Apr 2012 20:48:07 -0700 (PDT)
Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q3O3m5vm006515; Mon, 23 Apr 2012 20:48:05 -0700 (PDT)
Received: from SJ1SWM219.corp.adobe.com (10.5.77.61) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 23 Apr 2012 20:48:04 -0700
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by SJ1SWM219.corp.adobe.com ([fe80::d55c:7209:7a34:fcf7%12]) with mapi; Mon, 23 Apr 2012 20:48:04 -0700
From: Larry Masinter 
To: Simon Perreault , "julian.reschke@gmx.de" 
Date: Mon, 23 Apr 2012 20:48:02 -0700
Thread-Topic: [apps-discuss] Default charset in vCard
Thread-Index: Ac0hfPUvr8lh0ZGZTL6A+4QuP78HnwATUevg
Message-ID: 
References: <4F955991.2080606@viagenie.ca> <4F95691E.3020800@gmx.de> <4F959C0C.3000009@viagenie.ca>
In-Reply-To: <4F959C0C.3000009@viagenie.ca>
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: "apps-discuss@ietf.org" , "draft-ietf-appsawg-mime-default-charset@tools.ietf.org" 
Subject: Re: [apps-discuss] Default charset in vCard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Apr 2012 03:48:23 -0000

> Right, but I meant to ask "if we were to do it again (for vCard), would=20
> we do it differently based on what is proposed here (in this draft)?"

> Specifically "New subtypes of the "text" media type, thus, SHOULD NOT=20
> define a default "charset" value."

> And if the answer is "yes we would do it differently", I would find that=
=20
> very suspect.


http://www.rfc-editor.org/errata_search.php?rfc=3D6350&eid=3D3199



From paulej@packetizer.com  Mon Apr 23 22:56: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 809C521F853C; Mon, 23 Apr 2012 22:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.376
X-Spam-Level: 
X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWZcJYdqsGwj; Mon, 23 Apr 2012 22:56:31 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7521321F853B; Mon, 23 Apr 2012 22:56:31 -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 q3O5uSxP001046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Apr 2012 01:56:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335246990; bh=cNNYrDneXsrEue0Lb9FEMYqmN+5GR/Svy5NLDBci9+g=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=SyipDHmSqaJ/d54KpnJzKr+Fwih0gmNUSx4wJlQg6onEBa6+p16z3e4Do6sjG63xB W7kXayPqClRaff1k8nWpU/33xcrA200eM+nRYAWCyY2SrFg7K5CzgNqEyGrS1gxvhW fv2po9trH4qqCbzM4mswiZdduECPolHNt7fOCKO8=
From: "Paul E. Jones" 
To: "'Michael Thomas'" , "'Derek Atkins'" 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net>	<4F8852D0.4020404@cs.tcd.ie>	<9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>		<9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com>	<4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com>	<091401cd1ea3$e159be70$a40d3b50$@packetizer.com>		<091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>	 <4F917545.5080103@mtcc.com>  <4F9573D6.9080603@mtcc.com>
In-Reply-To: <4F9573D6.9080603@mtcc.com>
Date: Tue, 24 Apr 2012 01:56:32 -0400
Message-ID: <027701cd21df$0179de40$046d9ac0$@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: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAIw2f/NAUQ5aEgCO5nRqQLuh1nuApXB+mECb+r+0JV73h6g
Content-Language: en-us
Cc: oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Apr 2012 05:56:32 -0000

Michael,

>  From a programming standpoint, JSON is just easier to deal with. Consider
> these two links:
> 
> http://php.net/manual/en/book.json.php
> 
> http://php.net/manual/en/book.xml.php
> 
> and tell me which you'd rather deal with. It's not huge, but it's not
> nothing either.

To be fair, this works well partly because of the language.  Works even
better in JavaScript.  It would work less well in C.  Here's just one
example:
http://www.digip.org/jansson/doc/2.3/

JSON bits do not map perfectly to C.  I thought C++ might be simpler, but
the first library I grabbed had library documentation that was 224 pages
long (libjson).

When I process simple XML like that from WebFinger, I tend to use a parser
that just steps through each node in order.  I don't need to decode the
whole "document" in memory and reference pieces and parts of it: one pass
over it and I grab what I need.  It's very simple to process the XML output
from WebFinger that way.

Paul



From zach@sensinode.com  Tue Apr 24 00:53: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 7085C21F869D for ; Tue, 24 Apr 2012 00:53:56 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcCmoIJYBAx4 for ; Tue, 24 Apr 2012 00:53:55 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9555A21F861C for ; Tue, 24 Apr 2012 00:53:55 -0700 (PDT)
Received: from [172.20.10.4] (84-231-127-42.elisa-mobile.fi [84.231.127.42]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q3O7rqwx030873; Tue, 24 Apr 2012 10:53:53 +0300
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Zach Shelby 
In-Reply-To: <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org>
Date: Tue, 24 Apr 2012 10:53:51 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <8ADBF7CE-DB58-470B-BFC7-6F230A1ECE08@sensinode.com>
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.1084)
Cc: "apps-discuss@ietf.org application-layer protocols" , Cullen Jennings 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 07:53:56 -0000

I agree with Carsten's summary here, and plan on just letting my +exi =
draft expire. With SenML we can try out this senml-exi form and see how =
we get the information into the registry.

Zach

On Apr 23, 2012, at 11:28 PM, Carsten Bormann wrote:

> My 5-line summary is:
>=20
> 1) EXI may or may not be a content-encoding in its schemaless form, =
but we don't care about that, we use EXI schema-informed mode.
>=20
> 2) +exi is considered undesirable for schema-informed EXI.
> So we should go to an EXI specific media type, let's call that -exi.
>=20
> This means three media types for SenML
>=20
> application/senml+json
> application/senml+xml
> application/senml-exi
>=20
> The third media type would in particular nail down the way EXI is used =
in schema-informed mode.
>=20
> Gr=FC=DFe, Carsten
>=20

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


From ht@inf.ed.ac.uk  Tue Apr 24 01:55: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 BCADD21F8723 for ; Tue, 24 Apr 2012 01:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.576
X-Spam-Level: 
X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 352uT28zlOjI for ; Tue, 24 Apr 2012 01:55:30 -0700 (PDT)
Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id B7AAF21F8726 for ; Tue, 24 Apr 2012 01:55:26 -0700 (PDT)
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 q3O8tAZq005197; Tue, 24 Apr 2012 09:55:10 +0100 (BST)
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 q3O8tAMP010601; Tue, 24 Apr 2012 09:55:10 +0100
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 q3O8tA04017516;  Tue, 24 Apr 2012 09:55:10 +0100
Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q3O8t9F0017511; Tue, 24 Apr 2012 09:55:09 +0100
X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: Carsten Bormann 
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org>
From: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Tue, 24 Apr 2012 09:55:09 +0100
In-Reply-To: <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org> (Carsten Bormann's message of "Mon, 23 Apr 2012 22:28:28 +0200")
Message-ID: 
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (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: "apps-discuss@ietf.org application-layer protocols" , Cullen Jennings 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 08:55:31 -0000

Carsten Bormann writes:

> My 5-line summary is:
>
> 1) EXI may or may not be a content-encoding in its schemaless form,
> but we don't care about that, we use EXI schema-informed mode.
>
> 2) +exi is considered undesirable for schema-informed EXI.
> So we should go to an EXI specific media type, let's call that -exi.
>
> This means three media types for SenML
>
> application/senml+json
> application/senml+xml
> application/senml-exi
>
> The third media type would in particular nail down the way EXI is
> used in schema-informed mode.

Works for me.

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 tony@att.com  Tue Apr 24 03:41: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 39A6021F864A for ; Tue, 24 Apr 2012 03:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.442
X-Spam-Level: 
X-Spam-Status: No, score=-104.442 tagged_above=-999 required=5 tests=[AWL=0.864, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI2AF6El8HUs for ; Tue, 24 Apr 2012 03:41:21 -0700 (PDT)
Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 79A4E21F8584 for ; Tue, 24 Apr 2012 03:41:21 -0700 (PDT)
Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 053869f4.0.643191.00-436.1765881.nbfkord-smmo04.seg.att.com (envelope-from );  Tue, 24 Apr 2012 10:41:21 +0000 (UTC)
X-MXL-Hash: 4f968351791238b2-25393859e196baae12733ed1c0d50d3edc216d3f
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 q3OAfK6I009291 for ; Tue, 24 Apr 2012 06:41:20 -0400
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 q3OAfEMl009263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Apr 2012 06:41:14 -0400
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Tue, 24 Apr 2012 06:40:39 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3OAedBA002447 for ; Tue, 24 Apr 2012 06:40:39 -0400
Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3OAeWeP002354 for ; Tue, 24 Apr 2012 06:40:33 -0400
Received: from [135.70.94.94] (vpn-135-70-94-94.vpn.swst.att.com[135.70.94.94]) by maillennium.att.com (mailgw1) with ESMTP id <20120424103722gw1004or07e> (Authid: tony); Tue, 24 Apr 2012 10:37:22 +0000
X-Originating-IP: [135.70.94.94]
Message-ID: <4F96831F.6030004@att.com>
Date: Tue, 24 Apr 2012 06:40:31 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
CC: "apps-discuss@ietf.org application-layer protocols" 
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org> <4F95D22A.6060500@stpeter.im> <01OEO1DMECF40006TF@mauve.mrochek.com>
In-Reply-To: <01OEO1DMECF40006TF@mauve.mrochek.com>
Content-Type: multipart/alternative; boundary="------------010505000500000907040008"
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-RSA-Action: allow
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.20.145]
X-AnalysisOut: [v=1.0 c=1 a=N7jmR7O6mG8A:10 a=vnNYxAp2wzwA:10 a=I33QWX3c-g]
X-AnalysisOut: [EA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8]
X-AnalysisOut: [UMqPvVAA==:17 a=LU1XTwNGdYoCQVZclEQA:9 a=wPNLvfGTeEIA:10 a]
X-AnalysisOut: [=9aueKP-jAAAA:8 a=Jy1sZ59xldrHFTZWp1IA:9 a=rDUDItsgqzm60re]
X-AnalysisOut: [aVSIA:7 a=_W_S_7VecoQA:10]
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 10:41:22 -0000

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

On 4/23/2012 9:14 PM, Ned Freed wrote:
>> On 4/23/12 2:28 PM, Carsten Bormann wrote:
>>> My 5-line summary is:
> ...
>> Although it's not beautiful, I can see why we've ended up at #3 and it
>> seems like the least-worst solution at this point.
> I have to agree. For better or worse, we didn't think about this case when the
> architecture was designed. And as we all know, adding mandatory-to-implement
> information fields after the fact doesn't work very well (if at all). So this
> is where we end up.

Thanks for the summary Carsten. I think you captured the discussion very 
well.

     Tony Hansen

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


  
    
    
  
  
    On 4/23/2012 9:14 PM, Ned Freed wrote:
    

      

        
On 4/23/12 2:28 PM, Carsten Bormann wrote:


        

          
My 5-line summary is:


        

      

      ...
      

        
Although it's not beautiful, I can see why we've ended up at #3 and it
seems like the least-worst solution at this point.


      

      
I have to agree. For better or worse, we didn't think about this case when the
architecture was designed. And as we all know, adding mandatory-to-implement
information fields after the fact doesn't work very well (if at all). So this
is where we end up.


    

    

    Thanks for the summary Carsten. I think you captured the discussion
    very well.

    

        Tony Hansen

    

      

    

  


--------------010505000500000907040008--

From derek@ihtfp.com  Mon Apr 23 09: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 369EB21F867F; Mon, 23 Apr 2012 09:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.637
X-Spam-Level: 
X-Spam-Status: No, score=-101.637 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TICFkOByLTh; Mon, 23 Apr 2012 09:55:50 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB0A21F866D; Mon, 23 Apr 2012 09:55:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D1513260299; Mon, 23 Apr 2012 12:55:49 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 30604-10; Mon, 23 Apr 2012 12:55:48 -0400 (EDT)
Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id BD8B52601D8; Mon, 23 Apr 2012 12:55:48 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3NGtfvk027083; Mon, 23 Apr 2012 12:55:41 -0400
From: Derek Atkins 
To: Michael Thomas 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com>  <4F9573D6.9080603@mtcc.com>
Date: Mon, 23 Apr 2012 12:55:40 -0400
In-Reply-To: <4F9573D6.9080603@mtcc.com> (Michael Thomas's message of "Mon, 23 Apr 2012 08:23:02 -0700")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: Maia Mailguard 1.0.2a
X-Mailman-Approved-At: Tue, 24 Apr 2012 08:31:31 -0700
Cc: Derek Atkins , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 16:55:51 -0000

Michael Thomas  writes:

> Derek Atkins wrote:
>> Michael Thomas  writes:
>>
>>> Why not MUST ASN.1 while you're at it? JSON has won in case
>>> you'all haven't noticed it.
>>
>> Well, now that you mention it...   ;-)
>>
>> But seriously, we're basing this work on an RFC that was just release
>> six months ago and it requires XML.  Why be so quick to drop something
>> we just published half a year ago?  So maybe in 6 months we drop JSON
>> and add the next big thing?  Come on, Mike.
>>
>> I agree, we should definitely support JSON.  But I also think we should
>> support XML.  The client can do what it wants, which is where want the
>> light weight implementation.
>
> I think you're probably misunderstanding me. I'm (I believe) with Tim
> in saying "pick one". Just one. For clients and servers. And I'm only

No, I'm not misunderstanding you, I know exactly what you are arguing
for.  And I'm agreeing with you that we must support JSON.  However, I
disagree that we should drop XML, especially considering 6415 requires
XML and it was just released 6 months ago.

I'm also saying that this is only a server-side requirement to support
both.  The client can choose to support only one based on its own
requirements.  If you already have an XML-based client, why force them
to add JSON support?  Similarly, if you already have a JSON-based
client, why force them to add XML support?

If you're writing a client, you can ignore XML and only play with JSON.

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From mike@mtcc.com  Mon Apr 23 08:41: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 948A221F84E6; Mon, 23 Apr 2012 08:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAaA7eEgRw2Q; Mon, 23 Apr 2012 08:41:06 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id D9E5C21F84DF; Mon, 23 Apr 2012 08:41:06 -0700 (PDT)
Received: from piolinux.mtcc.com (65-172-208-69.dsl.volcano.net [65.172.208.69]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3NFf0dF020368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 08:41:01 -0700
Message-ID: <4F957807.3090409@mtcc.com>
Date: Mon, 23 Apr 2012 08:40:55 -0700
From: Michael Thomas 
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Stephen Farrell 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com> <4F921E53.8030109@cs.tcd.ie>
In-Reply-To: <4F921E53.8030109@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=928; t=1335195662; x=1336059662; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[apps-discuss]=20[OAUTH-WG]=20Web=20Fin ger=20vs.=20Simple=20Web=20Discovery=0A=20(SWD) |Sender:=20 |To:=20Stephen=20Farrell=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=o+xM5OZGu5C47gYVnWyfPXPbvUVDBkKnYvhCaIMAqHY=; b=sIpnE4I0pC7HMb9hKDh/aoWdNgqSwMSHdY2Ylas+5Qn+vlunn6vcWOtyWl L5lNRzZZ5cSnDxrEbrfjZUTBQgLGTR0SixYXlEwFvmr72mHJuag2mI709IPP U5Toozl8kYpG8tqEqckjl9AlbMGmYGQSSRZp145Uk84wObnCRFWUc=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
X-Mailman-Approved-At: Tue, 24 Apr 2012 08:31:38 -0700
Cc: Derek Atkins , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Apr 2012 15:41:07 -0000

Stephen Farrell wrote:
> 
> On 04/20/2012 03:40 PM, Michael Thomas wrote:
>> Why not MUST ASN.1 while you're at it? JSON has won in case
>> you'all haven't noticed it.
> 
> Well, I also remember when XML won over ASN.1, or
> was that some RPC thing? Seems like a new format wins
> about every five years or so, once the last winner
> gets enough crap added. (JSON pointer seems like the
> start of a nice slippery slope to me.)
> 
> I've no opinion as to what should be MTI here however,
> just a side comment.
> 

As a producer of schemas for my own purposes, I always feel like I'm
likely doing something wrong when I hack up XML, and I'm most likely
right since I haven't -- and don't want to -- read half of the RFC's.
Not so with JSON. I read 4627 through and thought -- groovy, nothing
more than meets the eye! It's impossible to sin!

Mike, and yes JSON will turn to crap if it gets loved to death

From fluffy@iii.ca  Tue Apr 24 08:49: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 3195E21F86B7 for ; Tue, 24 Apr 2012 08:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Level: 
X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-8mnmxTkXVF for ; Tue, 24 Apr 2012 08:49:54 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1FC21F8686 for ; Tue, 24 Apr 2012 08:49:54 -0700 (PDT)
Received: from [10.154.36.65] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1E6C822E25D; Tue, 24 Apr 2012 11:49:52 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1252
From: Cullen Jennings 
In-Reply-To: <01OEO1DMECF40006TF@mauve.mrochek.com>
Date: Tue, 24 Apr 2012 08:49:51 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org> <4F95D22A.6060500@stpeter.im> <01OEO1DMECF40006TF@mauve.mrochek.com>
To: Ned Freed 
X-Mailer: Apple Mail (2.1257)
Cc: "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 15:49:55 -0000

On Apr 23, 2012, at 18:14 , Ned Freed wrote:

>>> application/senml+json
>>> application/senml+xml
>>> application/senml-exi

I think the idea that first two are OK but the third one needs to have a =
"-" instead of a "+" is simply baffling. Can someone explain the logic =
to me ?

Cullen=20

I'll rest the urge to insert a rant here about the reason people don't =
bother to register new thing and just use text/plain for everything =85


From cabo@tzi.org  Tue Apr 24 08:56: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 49C3021F875D for ; Tue, 24 Apr 2012 08:56:32 -0700 (PDT)
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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygYpigr32eQX for ; Tue, 24 Apr 2012 08:56:31 -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 81FA921F8752 for ; Tue, 24 Apr 2012 08:56:31 -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 q3OFuO67008958; Tue, 24 Apr 2012 17:56:24 +0200 (CEST)
Received: from [192.168.217.105] (p5B3E64AF.dip.t-dialin.net [91.62.100.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 134218C;  Tue, 24 Apr 2012 17:56:24 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann 
In-Reply-To: 
Date: Tue, 24 Apr 2012 17:56:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AE9CE16-C021-4000-8A24-6E6084A8726D@tzi.org>
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org> <4F95D22A.6060500@stpeter.im> <01OEO1DMECF40006TF@mauve.mrochek.com> 
To: Cullen Jennings 
X-Mailer: Apple Mail (2.1257)
Cc: Ned Freed , "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 15:56:32 -0000

On Apr 24, 2012, at 17:49, Cullen Jennings wrote:

>=20
> On Apr 23, 2012, at 18:14 , Ned Freed wrote:
>=20
>>>> application/senml+json
>>>> application/senml+xml
>>>> application/senml-exi
>=20
> I think the idea that first two are OK but the third one needs to have =
a "-" instead of a "+" is simply baffling. Can someone explain the logic =
to me ?

Logic =3D=20
-- Least amount of pain
-- Gets the job done

(The detailed technical discussion is in the last 75 messages, which I =
won't try to repeat.  Yes, this is all logical, even if the result of =
all that logic appears to incite cognitive dissonance.  We must have =
spent some 100 hours of engineer time on this already.)

It's just a string, and it is not even sent in the packet!

(Can we spend the next 100 hours debating what to put in the EXI header, =
please?)

Gr=FC=DFe, Carsten


From ned.freed@mrochek.com  Tue Apr 24 09:04: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 1364121E802C for ; Tue, 24 Apr 2012 09:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level: 
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbnSFJpIs8Jw for ; Tue, 24 Apr 2012 09:04:07 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0845111E80B3 for ; Tue, 24 Apr 2012 09:04:06 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEOWEOLVA80008YL@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 24 Apr 2012 09:04:01 -0700 (PDT)
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 <01OENEYWYFI80006TF@mauve.mrochek.com>; Tue, 24 Apr 2012 09:03:58 -0700 (PDT)
Message-id: <01OEOWEMGCME0006TF@mauve.mrochek.com>
Date: Tue, 24 Apr 2012 08:51:04 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 24 Apr 2012 08:49:51 -0700" 
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org> <4F95D22A.6060500@stpeter.im> <01OEO1DMECF40006TF@mauve.mrochek.com> 
To: Cullen Jennings 
Cc: Ned Freed , "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 16:04:08 -0000

> On Apr 23, 2012, at 18:14 , Ned Freed wrote:

> >>> application/senml+json
> >>> application/senml+xml
> >>> application/senml-exi

> I think the idea that first two are OK but the third one needs to have a "-"
> instead of a "+" is simply baffling. Can someone explain the logic to me ?

+exi implies a syntax that can be processed generically by systems knowing
nothing specific about senml. But in order to decode schema-aware EXI, which is
what is being used here, you have to know the schema for the specific version
of senml that's in use. There is an field in the document itself that can be
used to provide a pointer to the schema, but it's optional. In other words, in
some cases the schema has to be known through out of band information, and that
violates the rules for +suffix.

> I'll rest the urge to insert a rant here about the reason people don't bother
> to register new thing and just use text/plain for everything …

In turn I'll resist the urge to rant about folks who jump into a long
discussion without making any attempt to read the preceeding messages and
expect others to do their work for them.

				Ned

From alexey.melnikov@isode.com  Tue Apr 24 09:14: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 0543821F87D8; Tue, 24 Apr 2012 09:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.511
X-Spam-Level: 
X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijVfdIg0D9MY; Tue, 24 Apr 2012 09:14:00 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id E644921F87C6; Tue, 24 Apr 2012 09:13:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335284038; d=isode.com; s=selector; i=@isode.com; bh=tuK+87IdECyx8g1ceSSw87kIOH54xvLgX2zRQoz7GuM=; 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=awuhaqwUM+WUlTXuD7TVYmc4P40mXUjdGP4m5lUoDpG+zwnFwkIlJXWPIxAcUuGDwpjqLU AumbpMDW1TAB6WT58ZDiY+uo1ILrIqybL+9GDJjdZchx27hZS0M2o87pG9LlXYM0SCEdoF L5+P9oPa5YdMeXjIZQGTzqJZgQDEZT4=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Tue, 24 Apr 2012 17:13:58 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4F96D157.7020504@isode.com>
Date: Tue, 24 Apr 2012 17:14:15 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: "apps-discuss@ietf.org" , dane@ietf.org, iesg@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-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Apr 2012 16:14:01 -0000

This is a supplemental AppsDir review of draft-ietf-dane-protocol (for
background on AppsDir, please see
).

Although Murray Kucherawy has already reviewed this I-D on behalf of
the AppsDir, folks in the Applications Area realize that wide
deployment of the TLSA Resource Record might have a significant impact
on applications, so we are performing additional reviews. Please treat
these comments just as you would any other Last Call feedback.

Document: draft-ietf-dane-protocol
Title: "The DNS-Based Authentication of Named Entities (DANE) Protocol
for Transport Layer Security (TLS)"
Reviewer: Peter Saint-Andre
Review Date: 2012-04-24
IETF Last Call Date: 2012-04-25
IESG Telechat: not yet scheduled


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


Major Issue: none, although a) I am agreeing with Peter Saint-Andre's 
major issue and b) I would like to see a reply to my minor issues

Minor Issues:

2.2.  TLSA RR Presentation Format

    The presentation format of the RDATA portion is as follows:

Presentation for what purpose? In management UIs? Is this a required 
presentation format for DNS tools that can retrieve and update TLSA records?

  [...]

    o  The certificate association data field MUST be represented as a
       string of hexadecimal characters.  Whitespace is allowed within
       the string of hexadecimal characters.

Please define what you mean by whitespace here? CR & LFs allowed?
Examples in the Section 2.3 seem to suggest that.

3.  Domain Names for TLS Certificate Associations

    2.  The protocol name of the transport on which a TLS-based service
        is assumed to exist is prepended with an underscore character
        ("_") to become the second left-most label in the prepared domain
        name.  The transport names defined for this protocol are "tcp",
        "udp" and "sctp".

DCCP? Should there be a registry?

4.  Use of TLSA Records in TLS

    Section 2.1 of this document defines the mandatory matching rules for
    the data from the TLSA certificate associations and the certificates
    received from the TLS server.

    The TLS session that is to be set up MUST be for the specific port
    number and transport name that was given in the TLSA query.

So this will not work for any type of DNS indirection mechanism, such as 
MX, SRV, etc? Or does DNS retrieval of such records also requires DNSSec?


Nits:

4.  Use of TLSA Records in TLS

    If a TLSA record has usage type 2 for the certifcate, the

typo: certificate

    corresponding TLS server SHOULD send the certificate that is
    referenced just like it currently sends intermediate certificates.


    If an application receives zero usable certificate associations from
    a DNS request or from its cache, it processes TLS in the normal
    fashion without any input from the TLSA records.

Just to double check: if TLS client receives some TLSA records, but none
of them are usable, is this considered to be the above case?

    If an application
    receives one or more usable certificate associations, it attempts to
    match each certificate association with the TLS server's end entity
    certificate until a successful match is found.  During the TLS
    handshake, if none of the certificate associations matches the
    certificate given by the TLS server, the TLS client MUST abort the
    handshake.

From fluffy@iii.ca  Tue Apr 24 09:16: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 ABA0021F87D8 for ; Tue, 24 Apr 2012 09:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.241
X-Spam-Level: 
X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, J_CHICKENPOX_53=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgG08vRK9Dnx for ; Tue, 24 Apr 2012 09:16:30 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1145021F87C7 for ; Tue, 24 Apr 2012 09:16:30 -0700 (PDT)
Received: from [10.154.36.65] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6132E22E25D; Tue, 24 Apr 2012 12:16:23 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1252
From: Cullen Jennings 
In-Reply-To: <6AE9CE16-C021-4000-8A24-6E6084A8726D@tzi.org>
Date: Tue, 24 Apr 2012 09:16:22 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <71DB17CE-56FC-4B10-BF4E-E6B2E0C6AC0B@iii.ca>
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org> <4F95D22A.6060500@stpeter.im> <01OEO1DMECF40006TF@mauve.mrochek.com>  <6AE9CE16-C021-4000-8A24-6E6084A8726D@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.1257)
Cc: Ned Freed , "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 16:16:30 -0000

On Apr 24, 2012, at 8:56 , Carsten Bormann wrote:

> On Apr 24, 2012, at 17:49, Cullen Jennings wrote:
>=20
>>=20
>> On Apr 23, 2012, at 18:14 , Ned Freed wrote:
>>=20
>>>>> application/senml+json
>>>>> application/senml+xml
>>>>> application/senml-exi
>>=20
>> I think the idea that first two are OK but the third one needs to =
have a "-" instead of a "+" is simply baffling. Can someone explain the =
logic to me ?
>=20
> Logic =3D=20
> -- Least amount of pain
> -- Gets the job done
>=20
> (The detailed technical discussion is in the last 75 messages, which I =
won't try to repeat.  Yes, this is all logical, even if the result of =
all that logic appears to incite cognitive dissonance.  We must have =
spent some 100 hours of engineer time on this already.)
>=20
> It's just a string, and it is not even sent in the packet!
>=20
> (Can we spend the next 100 hours debating what to put in the EXI =
header, please?)
>=20

So lets me paraphrase your answer.=20

There is no explainable technical reason but the IETF is so unreasonable =
that I've given up caring after 100s of hours of discussion and just =
trying to move forward.=20

I feel your pain and this is reasonable at some level but it is a =
serious problem for the IETF - if we can't make it easy for people to =
register types and know what to do, they just give up and use text/plain =
or some moral equivalent of that.=20

So that said, can someone take stab at explaining the logic behind =
senml+xml but senml-exi? I tired reading the draft and did not leap out =
to me why one was + and the other -.=20









From alexey.melnikov@isode.com  Tue Apr 24 09:17: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 16CB621F87C7; Tue, 24 Apr 2012 09:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.513
X-Spam-Level: 
X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HoZQB5qw0pS; Tue, 24 Apr 2012 09:17:15 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id F24DB21F87AD; Tue, 24 Apr 2012 09:17:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335284233; d=isode.com; s=selector; i=@isode.com; bh=sN7LUjIo85qtxOah+S/acw6ya4/AiEw+VHGaswzrK98=; 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=qO5UZhmivK4hlBrqV0VdxxVj9XOrXWdE6a7BcxIa3qDXdpra3qII9bg1PDyx+us2eAr8Oj +p3KthTsbwEIUMVrosh4OR3FO6NnmKvXmSO/HCDdUtKLEA837hVOMJ164xWnR+XMiKJ6kc /K0dKpIPFa6Bg7zb59EqC6US+9mn5PI=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Tue, 24 Apr 2012 17:17:13 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4F96D21A.7080006@isode.com>
Date: Tue, 24 Apr 2012 17:17:30 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: "apps-discuss@ietf.org" , dane@ietf.org, iesg@ietf.org
References: <4F96D157.7020504@isode.com>
In-Reply-To: <4F96D157.7020504@isode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Apr 2012 16:17:16 -0000

On 24/04/2012 17:14, Alexey Melnikov wrote:
> Document: draft-ietf-dane-protocol
> Title: "The DNS-Based Authentication of Named Entities (DANE) Protocol
> for Transport Layer Security (TLS)"
> Reviewer: Peter Saint-Andre
And now I even pretend to be Peter ;-).
> Review Date: 2012-04-24
> IETF Last Call Date: 2012-04-25
> IESG Telechat: not yet scheduled


From fluffy@iii.ca  Tue Apr 24 09: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 CE2F221F87D8 for ; Tue, 24 Apr 2012 09:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.234
X-Spam-Level: 
X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_53=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MWV0D-K9upD for ; Tue, 24 Apr 2012 09:17:49 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5C48A21F87C7 for ; Tue, 24 Apr 2012 09:17:49 -0700 (PDT)
Received: from [10.154.36.65] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 932E022E25C; Tue, 24 Apr 2012 12:17:48 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1252
From: Cullen Jennings 
In-Reply-To: <71DB17CE-56FC-4B10-BF4E-E6B2E0C6AC0B@iii.ca>
Date: Tue, 24 Apr 2012 09:17:47 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org> <4F95D22A.6060500@stpeter.im> <01OEO1DMECF40006TF@mauve.mrochek.com>  <6AE9CE16-C021-4000-8A24-6E6084A8726D@tzi.org> <71DB17CE-56FC-4B10-BF4E-E6B2E0C6AC0B@iii.ca>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.1257)
Cc: Ned Freed , "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 16:17:49 -0000

Oops - had not read Ned's response before sending that. I'll read Neds.=20=


On Apr 24, 2012, at 9:16 , Cullen Jennings wrote:

>=20
> On Apr 24, 2012, at 8:56 , Carsten Bormann wrote:
>=20
>> On Apr 24, 2012, at 17:49, Cullen Jennings wrote:
>>=20
>>>=20
>>> On Apr 23, 2012, at 18:14 , Ned Freed wrote:
>>>=20
>>>>>> application/senml+json
>>>>>> application/senml+xml
>>>>>> application/senml-exi
>>>=20
>>> I think the idea that first two are OK but the third one needs to =
have a "-" instead of a "+" is simply baffling. Can someone explain the =
logic to me ?
>>=20
>> Logic =3D=20
>> -- Least amount of pain
>> -- Gets the job done
>>=20
>> (The detailed technical discussion is in the last 75 messages, which =
I won't try to repeat.  Yes, this is all logical, even if the result of =
all that logic appears to incite cognitive dissonance.  We must have =
spent some 100 hours of engineer time on this already.)
>>=20
>> It's just a string, and it is not even sent in the packet!
>>=20
>> (Can we spend the next 100 hours debating what to put in the EXI =
header, please?)
>>=20
>=20
> So lets me paraphrase your answer.=20
>=20
> There is no explainable technical reason but the IETF is so =
unreasonable that I've given up caring after 100s of hours of discussion =
and just trying to move forward.=20
>=20
> I feel your pain and this is reasonable at some level but it is a =
serious problem for the IETF - if we can't make it easy for people to =
register types and know what to do, they just give up and use text/plain =
or some moral equivalent of that.=20
>=20
> So that said, can someone take stab at explaining the logic behind =
senml+xml but senml-exi? I tired reading the draft and did not leap out =
to me why one was + and the other -.=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20


From stpeter@stpeter.im  Tue Apr 24 09: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 CE98821E8034; Tue, 24 Apr 2012 09:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.609
X-Spam-Level: 
X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlEa22j8zlfR; Tue, 24 Apr 2012 09:20:03 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E51F421E8027; Tue, 24 Apr 2012 09:19:56 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 21B1C40058; Tue, 24 Apr 2012 10:34:29 -0600 (MDT)
Message-ID: <4F96D2AB.6090509@stpeter.im>
Date: Tue, 24 Apr 2012 10:19:55 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Alexey Melnikov 
References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com>
In-Reply-To: <4F96D21A.7080006@isode.com>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org
Subject: Re: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Apr 2012 16:20:05 -0000

On 4/24/12 10:17 AM, Alexey Melnikov wrote:
> On 24/04/2012 17:14, Alexey Melnikov wrote:
>> Document: draft-ietf-dane-protocol
>> Title: "The DNS-Based Authentication of Named Entities (DANE) Protocol
>> for Transport Layer Security (TLS)"
>> Reviewer: Peter Saint-Andre
> And now I even pretend to be Peter ;-).

Heh. :)

Alexey, overnight I realized that this document doesn't say anything
about internationalized domain names (in fact, it doesn't cite any
documents about the definition of "DNS domain name"). So I think at the
least it needs to provide a citation, e.g. to Section 2.2 of RFC 6125.

Peter

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



From melvincarvalho@gmail.com  Tue Apr 24 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 C27C021F864C for ; Tue, 24 Apr 2012 09:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.153
X-Spam-Level: 
X-Spam-Status: No, score=-3.153 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waSGQuE-NZf5 for ; Tue, 24 Apr 2012 09:26:56 -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 C6D9C21F8607 for ; Tue, 24 Apr 2012 09:26:56 -0700 (PDT)
Received: by obbwd20 with SMTP id wd20so1356474obb.31 for ; Tue, 24 Apr 2012 09:26:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0IR4UtbSwweOPxysidhYcFOjK29oKHvd+T4k4ozlJgQ=; b=SV6Pud2ciHQkwi2WR/yE0OaVmRvo7HgLBWw+tsNzEPHGzvgwUY8eyrmLJ+6gPxJImR RXbxH+s0Eo7Lpm9PZUJyzE8ZnRIUzR3OiRaxIyKbsJSKTjSpnpSk7w2+LJZU/wUNq41F JIgI2Hy7I0AYhA1P4+5L3g3MuN1MHnvOX8ElG3b/LuKA+/AAZh8bvQZ4vk06cxJoLPCg YlXS82BRf+QViQ1BHuRbUifwqSQgN3Aq788q6EjZv/hQMOAHoWwftcjfWJCf919Usdsq FAmokA9mgSucvoLyCUKI5Bi+dV7Bn7YNv9oAkIFgUeeCLZ7SbY3wSlkSWKDMaahnJgba Bhyw==
MIME-Version: 1.0
Received: by 10.182.122.4 with SMTP id lo4mr5847372obb.24.1335284816343; Tue, 24 Apr 2012 09:26:56 -0700 (PDT)
Received: by 10.182.152.102 with HTTP; Tue, 24 Apr 2012 09:26:56 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 24 Apr 2012 18:26:56 +0200
Message-ID: 
From: Melvin Carvalho 
To: Blaine Cook 
Content-Type: multipart/alternative; boundary=f46d044785fd26f1d004be6f39f1
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger / SWD Issue #2: JSON format
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Apr 2012 16:26:57 -0000

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

On 22 April 2012 23:15, Blaine Cook  wrote:

> As a follow on to Issue #1, we also need to know the specific format to be
> used to describe the discovery metadata.
>
> I think [in the unlikely event we choose XML-only] the XML format is easy:
> XRD is a good format, one that had lots of attention and is truly about as
> simple as we'll ever see (i.e., it's effectively a subset of HTML 
> tags).
>
> However, in the more likely event that we choose XML+JSON or JSON-only,
> we'll need to decide on a format.
>
> Webfinger uses JRD, while SWD uses a JSON response with a single key,
> "locations", that points to an array of locations where the service is
> available. Given that (it seems) we want to be able to provide multiple
> services per request versus SWD's single service per request, JRD is a
> likely candidate.
>
> Are there other response formats we should be considering? Is there
> already implicit consensus on using JRD?
>

I think the two incumbent formats are :

Plain old JSON: Content-Type: application/json ( SWD )
JRD: Content-Type: application/xrd+json ( WF )

Two other serializations that could be worth mentioning are :

Facebook Open Graph API
JSON LD ( http://json-ld.org/ )

I would expect to see both of these two see significant growth in the next
few years.


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

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




On 22 April 2=
012 23:15, Blaine Cook <romeda@gmail.com> wrote:

As a follow on to Issue #1, we also need to know the specific format to be =
used to describe the discovery metadata.

I think [in the=
 unlikely event we choose XML-only] the XML format is easy: XRD is a good f=
ormat, one that had lots of attention and is truly about as simple as we=
9;ll ever see (i.e., it's effectively a subset of HTML <head> tag=
s).







However, in the more likely event that we choose XML+JS=
ON or JSON-only, we'll need to decide on a format.

=

Webfinger uses JRD, while SWD uses a JSON response with a single key, =
"locations", that points to an array of locations where the servi=
ce is available. Given that (it seems) we want to be able to provide multip=
le services per request versus SWD's single service per request, JRD is=
 a likely candidate.






Are there other response formats we should be consideri=
ng? Is there already implicit consensus on using JRD?

I think the two incumbent formats are :

Plain old JSON: Conten=
t-Type: application/json ( SWD )

JRD: Content-Type: application/xrd+json ( WF )

Two other serializati=
ons that could be worth mentioning are :

Facebook Open Graph API
=
JSON LD ( http://json-ld.org/ )
=A0<=
br>
I would expect to see both of these two see significant growth in the next =
few years.

<=
span class=3D"HOEnZb">


b.


_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--f46d044785fd26f1d004be6f39f1--

From cabo@tzi.org  Tue Apr 24 09:30: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 EFDEB21E8086 for ; Tue, 24 Apr 2012 09:30:12 -0700 (PDT)
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_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d905snnzj9tB for ; Tue, 24 Apr 2012 09:30:12 -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 0986621E8027 for ; Tue, 24 Apr 2012 09:30:11 -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 q3OGUBi1026132; Tue, 24 Apr 2012 18:30:11 +0200 (CEST)
Received: from [192.168.217.105] (p5B3E64AF.dip.t-dialin.net [91.62.100.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E4AE4AD;  Tue, 24 Apr 2012 18:27:06 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann 
In-Reply-To: <71DB17CE-56FC-4B10-BF4E-E6B2E0C6AC0B@iii.ca>
Date: Tue, 24 Apr 2012 18:27:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2107D945-F807-4837-93E7-549427D87241@tzi.org>
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org> <4F95D22A.6060500@stpeter.im> <01OEO1DMECF40006TF@mauve.mrochek.com>  <6AE9CE16-C021-4000-8A24-6E6084A8726D@tzi.org> <71DB17CE-56FC-4B10-BF4E-E6B2E0C6AC0B@iii.ca>
To: Cullen Jennings 
X-Mailer: Apple Mail (2.1257)
Cc: Ned Freed , "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 16:30:13 -0000

> So lets me paraphrase your answer.=20
>=20
> There is no explainable technical reason

That's not what I said -- I said it's in the last 75 messages and I'm =
not that interested in repeating all this.

> but the IETF is so unreasonable that I've given up caring after 100s =
of hours of discussion and just trying to move forward.=20

It's not the IETF that is unreasonable, it is just that this maze of =
little specifications that this needs to operate in is more complicated =
than I would like it to be.

> I feel your pain and this is reasonable at some level but it is a =
serious problem for the IETF - if we can't make it easy for people to =
register types and know what to do, they just give up and use text/plain =
or some moral equivalent of that.=20

I think once Tony's draft is done, at least this part of the discussion =
will be easier.
We may need to work some more on 4.2.8 there, maybe adding this as an =
example.

(The rest is indeed in Ned's answer.)

Gr=FC=DFe, Carsten


From cabo@tzi.org  Tue Apr 24 09:31: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 30C8B11E809C for ; Tue, 24 Apr 2012 09:31:39 -0700 (PDT)
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_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdSLg50jMgPQ for ; Tue, 24 Apr 2012 09:31:38 -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 7950C11E8080 for ; Tue, 24 Apr 2012 09:31: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 q3OGVV0J026508; Tue, 24 Apr 2012 18:31:31 +0200 (CEST)
Received: from [192.168.217.105] (p5B3E64AF.dip.t-dialin.net [91.62.100.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 33C53B4;  Tue, 24 Apr 2012 18:31:31 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann 
In-Reply-To: <2107D945-F807-4837-93E7-549427D87241@tzi.org>
Date: Tue, 24 Apr 2012 18:31:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org> <4F95D22A.6060500@stpeter.im> <01OEO1DMECF40006TF@mauve.mrochek.com>  <6AE9CE16-C021-4000-8A24-6E6084A8726D@tzi.org> <71DB17CE-56FC-4B10-BF4E-E6B2E0C6AC0B@iii.ca> <2107D945-F807-4837-93E7-549427D87241@tzi.org>
To: Cullen Jennings 
X-Mailer: Apple Mail (2.1257)
Cc: Ned Freed , "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 16:31:39 -0000

On Apr 24, 2012, at 18:27, Carsten Bormann wrote:

> Tony's draft

draft-ietf-appsawg-media-type-regs-05.txt

Sorry, it does have a few more authors.
(It's probably Tony who was in my mind because he was championing it in =
Paris.)

Gr=FC=DFe, Carsten


From alexey.melnikov@isode.com  Tue Apr 24 09: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 1F73811E80BC for ; Tue, 24 Apr 2012 09:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.516
X-Spam-Level: 
X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAxX71zdPhQq for ; Tue, 24 Apr 2012 09:37:27 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 16E5511E80BA for ; Tue, 24 Apr 2012 09:37:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335285445; d=isode.com; s=selector; i=@isode.com; bh=pUzC5w3jVtrYQ3u6TatzSZwvyyMl8M8NnoG1EV4Z728=; 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=am8m2fShWT5zCebVKcCLHyKI8h69rMcNrYocPI8bzmp7ekNgnm62TEEXpr8Dc4UDrB6dsg 3q+ZDLQzpNdVUSRIH7FwDnN/uUTyvXxcZG3zS0bHeE2WGJ+uGBx4uheS5yYxGWaNmoSHK7 ZFKK31nDraRQSNNsKw1TiwsWnydZJO0=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Tue, 24 Apr 2012 17:37:25 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4F96D6D5.8020803@isode.com>
Date: Tue, 24 Apr 2012 17:37:41 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: Julian Reschke , Simon Perreault 
References: <4F955991.2080606@viagenie.ca> <4F95691E.3020800@gmx.de>
In-Reply-To: <4F95691E.3020800@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" , draft-ietf-appsawg-mime-default-charset@tools.ietf.org
Subject: Re: [apps-discuss] Default charset in vCard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Apr 2012 16:37:28 -0000

On 23/04/2012 15:37, Julian Reschke wrote:
> On 2012-04-23 15:30, Simon Perreault wrote:
>> Hi,
>>
>> I took at look at draft-ietf-appsawg-mime-default-charset-03 to compare
>> against what we have in vCard 4.
>
> Ack.
>
>> In vCard 4, we basically say two things:
>> http://tools.ietf.org/html/rfc6350#section-3.1
>>
>> 1. The charset is always UTF-8.
> As far as I can tell, that's not in-line with RFC 2046 which defines 
> the default to be US-ASCII.
>> 2. If you use the charset parameter, it MUST be UTF-8.
I always interpreted the text in vCard 4.0 as always requiring 
"charset=UTF-8". At least that is what I wanted the spec to say.
>> It looks like it goes against the recommendation in your draft:
>>
>> a. specify that the "charset" parameter is not used for the defined
>> subtype, because the charset information is transported inside
>> the payload (such as in "text/xml"), or
>> b. require explicit unconditional inclusion of the "charset"
>> parameter eliminating the need for a default value.
If I am right above, then b) applies. So text/vcard is Ok.
>> [...]
>> New subtypes of the "text" media type, thus, SHOULD NOT define a
>> default "charset" value. If there is a strong reason to do so
>> despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as
>> the default.
>>
>> So, two questions:
>>
>> - Am I reading this right? Is there actually a conflict?
> I wouldn't call it a conflict. We just changed the defaults for new 
> registrations. That doesn't change existing ones.
>
>> - Should this be fixed eventually in a vCard 4 bis?
I don't see a need. Although you can make the charset parameter optional.
> You could, if that doesn't result in an incompatible change.
Right.
> As far as I can tell, with
>
> > 1. The charset is always UTF-8.
>
> you were already outside what RFC 2046 says, and close to what the new 
> recommendation is...
I think it already complies with our draft, but please double check that.
> Best regards, Julian


From kevinmarks@gmail.com  Tue Apr 24 09:43: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 5010E21F8702; Tue, 24 Apr 2012 09:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd7UaKa8oOkk; Tue, 24 Apr 2012 09:43:08 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1A521F8709; Tue, 24 Apr 2012 09:43:08 -0700 (PDT)
Received: by qaea16 with SMTP id a16so229355qae.10 for ; Tue, 24 Apr 2012 09:43:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wIcTNmGW8GGvGrY6+Je6twrKi+MbHjuZsKRxVJWc34I=; b=kEIfkRSp98CZOsV3o6VuU2lR/xSYw84D1kDvQYfnjSPlGQwihIMs95cRxzPbxhqxjT 8eKqQ7uobf4vebIMmHxOijS2ZtTmHJtk4fELrd1VkY2WJr6S1QOCgpgpfhOWpuRNrQzM K3rjU5ka+gVzpSz43O445Tub1rtoZCk06WopWmLlaBNvAOP8R5JKWDDZiQmkR13VTK1N dxrCXIiAhCz4s36oGDoxcvajQfjz1Y95v3VLX0lrAaWCgbvg2d3zLaxt6nYMU2ICNCGv Af7vyRgh3I6rLmKfKefMm3e+XFpvZshvbh087zLwX8Nq5FPZadBZa67j6eiJbWbSrYDe 6lGg==
MIME-Version: 1.0
Received: by 10.224.209.4 with SMTP id ge4mr17423301qab.12.1335285788085; Tue, 24 Apr 2012 09:43:08 -0700 (PDT)
Received: by 10.229.138.77 with HTTP; Tue, 24 Apr 2012 09:43:07 -0700 (PDT)
In-Reply-To: <027701cd21df$0179de40$046d9ac0$@packetizer.com>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com>  <4F9573D6.9080603@mtcc.com> <027701cd21df$0179de40$046d9ac0$@packetizer.com>
Date: Tue, 24 Apr 2012 09:43:07 -0700
Message-ID: 
From: Kevin Marks 
To: "Paul E. Jones" 
Content-Type: multipart/alternative; boundary=20cf300fab73128cb404be6f736f
Cc: Michael Thomas , Derek Atkins , oauth@ietf.org, Apps Discuss 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Apr 2012 16:43:10 -0000

--20cf300fab73128cb404be6f736f
Content-Type: text/plain; charset=UTF-8

I think you make JSON's point for it. It has a single, unambiguous,
bidirectional mapping to native data structures in all dynamic languages;
indeed that is its design goal.

XML does not map well to language structures, except in languages designed
explicitly to manipulate it. The duality of elements and attributes means
additional choices at each encode/decode boundary, and guaranteed ambiguity.

To continue the argument made by mark Nottingham and Tim Bray, having to
choose between attributes and elements at each point imposes the same
overhead at a different layer than having to choose between xml and json.

Yes, this natural mapping does not hold true for C, because C doesn't have
a native dictionary/hashtag data structure. C doesn't make XML or anything
else easy either, but C programmers are used to that.

On Mon, Apr 23, 2012 at 10:56 PM, Paul E. Jones wrote:

> Michael,
>
> >  From a programming standpoint, JSON is just easier to deal with.
> Consider
> > these two links:
> >
> > http://php.net/manual/en/book.json.php
> >
> > http://php.net/manual/en/book.xml.php
> >
> > and tell me which you'd rather deal with. It's not huge, but it's not
> > nothing either.
>
> To be fair, this works well partly because of the language.  Works even
> better in JavaScript.  It would work less well in C.  Here's just one
> example:
> http://www.digip.org/jansson/doc/2.3/
>
> JSON bits do not map perfectly to C.  I thought C++ might be simpler, but
> the first library I grabbed had library documentation that was 224 pages
> long (libjson).
>
> When I process simple XML like that from WebFinger, I tend to use a parser
> that just steps through each node in order.  I don't need to decode the
> whole "document" in memory and reference pieces and parts of it: one pass
> over it and I grab what I need.  It's very simple to process the XML output
> from WebFinger that way.
>
> Paul
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--20cf300fab73128cb404be6f736f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I think you make JSON's point for it. It has=
 a single, unambiguous, bidirectional mapping to native data structures in =
all dynamic languages; indeed that is its design goal.


XML does not map well to language stru=
ctures, except in languages designed explicitly to manipulate it. The duali=
ty of elements and attributes means additional choices at each encode/decod=
e boundary, and guaranteed ambiguity.



To continue=
 the argument made by mark Nottingham and Tim Bray, having to choose betwee=
n attributes and elements at each point imposes the same overhead at a diff=
erent layer than having to choose between xml and json.



Yes, this natural mapping does not hold true=
 for C, because C doesn't have a native dictionary/hashtag data structu=
re. C doesn't make XML or anything else easy either, but C programmers =
are used to that.


On Mon, Apr 23, 2012 at 10:56 PM, Paul E. Jo=
nes <paulej@packetizer.com> wrote:

Michael,




> =C2=A0From a programming standpoint, JSON is just easier to deal with.=
 Consider

> these two links:

>

> h=
ttp://php.net/manual/en/book.json.php

>

> ht=
tp://php.net/manual/en/book.xml.php

>

> and tell me which you'd rather deal with. It's not huge, but i=
t's not

> nothing either.




To be fair, this works well partly because of the language. =C2=A0Wor=
ks even

better in JavaScript. =C2=A0It would work less well in C. =C2=A0Here's =
just one

example:

http://=
www.digip.org/jansson/doc/2.3/



JSON bits do not map perfectly to C. =C2=A0I thought C++ might be simpler, =
but

the first library I grabbed had library documentation that was 224 pages
long (libjson).



When I process simple XML like that from WebFinger, I tend to use a parser<=
br>
that just steps through each node in order. =C2=A0I don't need to decod=
e the

whole "document" in memory and reference pieces and parts of it: =
one pass

over it and I grab what I need. =C2=A0It's very simple to process the X=
ML output

from WebFinger that way.



Paul






_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





--20cf300fab73128cb404be6f736f--

From simon.perreault@viagenie.ca  Tue Apr 24 09:49: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 31A8D21E804D for ; Tue, 24 Apr 2012 09:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXfcdjxJzHzN for ; Tue, 24 Apr 2012 09:49:03 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id CAF7721E808C for ; Tue, 24 Apr 2012 09:49:03 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:dd7c:b6ca:a5db:dd69]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 17AF040061; Tue, 24 Apr 2012 12:49:03 -0400 (EDT)
Message-ID: <4F96D97E.5040500@viagenie.ca>
Date: Tue, 24 Apr 2012 12:49:02 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Alexey Melnikov 
References: <4F955991.2080606@viagenie.ca> <4F95691E.3020800@gmx.de> <4F96D6D5.8020803@isode.com>
In-Reply-To: <4F96D6D5.8020803@isode.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Julian Reschke , "apps-discuss@ietf.org" , draft-ietf-appsawg-mime-default-charset@tools.ietf.org
Subject: Re: [apps-discuss] Default charset in vCard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Apr 2012 16:49:05 -0000

On 2012-04-24 12:37, Alexey Melnikov wrote:
>>> 1. The charset is always UTF-8.
>> As far as I can tell, that's not in-line with RFC 2046 which defines
>> the default to be US-ASCII.
>>> 2. If you use the charset parameter, it MUST be UTF-8.
> I always interpreted the text in vCard 4.0 as always requiring
> "charset=UTF-8". At least that is what I wanted the spec to say.

charset is optional in vCard 4. It is listed under the "optional 
parameters" heading in the media type registration template.

http://tools.ietf.org/html/rfc6350#section-10.1

>>> It looks like it goes against the recommendation in your draft:
>>>
>>> a. specify that the "charset" parameter is not used for the defined
>>> subtype, because the charset information is transported inside
>>> the payload (such as in "text/xml"), or
>>> b. require explicit unconditional inclusion of the "charset"
>>> parameter eliminating the need for a default value.
> If I am right above, then b) applies. So text/vcard is Ok.

And what if you're wrong above? ;)

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From alexey.melnikov@isode.com  Tue Apr 24 10:09:59 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01DC21E80A6 for ; Tue, 24 Apr 2012 10:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level: 
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyWVPS4be47E for ; Tue, 24 Apr 2012 10:09:59 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id BB67321E80A1 for ; Tue, 24 Apr 2012 10:09:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335287397; d=isode.com; s=selector; i=@isode.com; bh=pdx3vAdP2l6TdSsNOWcIHq8xQ00mGilm16R0WDGJ3C0=; 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=jLVJguctangbp+JOC3uIYC/U4TN341qJ7z6AmVxLAjWB4yvfvt7yCyMzA5d2tSh9ok+vY5 z8wiQnbbsFbVH7mwM13EmH380CskHMBCKsBKXrW6JivjII2kCRSJ1RNIMFZOD6hpP4ZvZu MqniE2klrJePwtG0GKe2TRLM21P9I8k=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Tue, 24 Apr 2012 18:09:57 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4F96DE76.6060502@isode.com>
Date: Tue, 24 Apr 2012 18:10:14 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: Simon Perreault 
References: <4F955991.2080606@viagenie.ca> <4F95691E.3020800@gmx.de> <4F96D6D5.8020803@isode.com> <4F96D97E.5040500@viagenie.ca>
In-Reply-To: <4F96D97E.5040500@viagenie.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Julian Reschke , "apps-discuss@ietf.org" , draft-ietf-appsawg-mime-default-charset@tools.ietf.org
Subject: Re: [apps-discuss] Default charset in vCard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Apr 2012 17:09:59 -0000

On 24/04/2012 17:49, Simon Perreault wrote:
> On 2012-04-24 12:37, Alexey Melnikov wrote:
>>>> 1. The charset is always UTF-8.
>>> As far as I can tell, that's not in-line with RFC 2046 which defines
>>> the default to be US-ASCII.
>>>> 2. If you use the charset parameter, it MUST be UTF-8.
>> I always interpreted the text in vCard 4.0 as always requiring
>> "charset=UTF-8". At least that is what I wanted the spec to say.
> charset is optional in vCard 4. It is listed under the "optional 
> parameters" heading in the media type registration template.
>
> http://tools.ietf.org/html/rfc6350#section-10.1
Damn :-)
>>>> It looks like it goes against the recommendation in your draft:
>>>>
>>>> a. specify that the "charset" parameter is not used for the defined
>>>> subtype, because the charset information is transported inside
>>>> the payload (such as in "text/xml"), or
>>>> b. require explicit unconditional inclusion of the "charset"
>>>> parameter eliminating the need for a default value.
>> If I am right above, then b) applies. So text/vcard is Ok.
>
> And what if you're wrong above? ;)
Well, then the charset draft will make it legal according to new rules 
;-). So basically you don't need to do anything in the future.

But as Julian already said: our draft doesn't affect older registrations.


From alexey.melnikov@isode.com  Tue Apr 24 10: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 3E26B21E809D for ; Tue, 24 Apr 2012 10:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Level: 
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8Z4c2IuM+ts for ; Tue, 24 Apr 2012 10:25:27 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id A2B0321E8090 for ; Tue, 24 Apr 2012 10:25:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335288306; d=isode.com; s=selector; i=@isode.com; bh=alsYslObaCuvU2WmCEmCJT3UIrRkXd8GFIkImBt9Bpk=; 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=OaULzFQkeh4qAPgcTmfUbfWyOHxmXTrKclxcdDSLl4KmMDoGBh09QjnM4tMyMTCNJLXWK7 WYsQW/HO5OwX3tljCxXPAMhNVYB2T6DzxxeSwJrtR4mpk3zEjjvCMcRFmc1Qwz/oPG5sfT Qi8Z+SeGqo6jkmWYtK48Ra5QOSoZhJg=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Tue, 24 Apr 2012 18:25:06 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4F96E203.5060105@isode.com>
Date: Tue, 24 Apr 2012 18:25:23 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: "apps-discuss@ietf.org" 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] Call for Adoption: draft-kucherawy-received-state-02.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, 24 Apr 2012 17:25:28 -0000

Murray presented this draft in at least one of the face to face IETF 
meetings and my recollection is that general feedback on this document 
was positive. So I would like to initiate acceptance call for processing 
this document in the APPSAWG.

Please indicate your support or objection, and opinions thereto before 
the close of business on May 1st.

Alexey, as an APPSAWG co-chair


From arnt@gulbrandsen.priv.no  Tue Apr 24 10:34: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 667CC21F8853; Tue, 24 Apr 2012 10:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.587
X-Spam-Level: 
X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[AWL=1.012,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+CpLhjNQwPp; Tue, 24 Apr 2012 10:34:27 -0700 (PDT)
Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 10CB421F86F8; Tue, 24 Apr 2012 10:34:27 -0700 (PDT)
Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 6399AF8E538; Tue, 24 Apr 2012 17:34:23 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1335288862-21918-21917/11/1; Tue, 24 Apr 2012 17:34:22 +0000
Message-Id: <4F96E41D.1090405@gulbrandsen.priv.no>
Date: Tue, 24 Apr 2012 19:34:21 +0200
From: Arnt Gulbrandsen 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
Mime-Version: 1.0
To: Ted Hardie 
References:  <4F95D991.5010603@gulbrandsen.priv.no> 
In-Reply-To: 
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: draft-ietf-eai-simpledowngrade.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Review of draft-ietf-eai-simpledowngrade-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 17:34:28 -0000

On 04/24/2012 01:23 AM, Ted Hardie wrote:
> Hi Arnt,
>
> Thanks for your quick reply.  I've added the apps-discuss list to the
> distribution; I forgot them on the original, though they are usually
> cc'ed on appsdir reviews.

I wondered about that. "Shouldn't there be a Cc to that mailing list=20
that always refuses my reply?"


> I certainly hope that internationalized mail to conventional mail will
> be a corner case,
> but I'm not sure my personal crystal ball is clear enough for me to be
> certain that will be so.

My path to enlightenment was:

Assume that you have EAI and I not. Then your first mail would have been=20
the last in this thread. At that point I have two options: Accept not=20
replying (in which case the message count stays at one) or upgrade my=20
client (which is bothering me to do so anyway, as chance will have it).

How many times will I accept not being able to reply before I either=20
shout at you (on the phone) to stop being so $#@$!#@$ internationalized=20
or upgrade my own client? Few enough, I guess, that it remains an odd =
case.

(I'm told this how Microsoft makes people upgrade to new versions of =
Word.)

> I am not sure*any*  downgrade doc belongs on the standards track, if =
that helps
> clarify my review.  I think losing security characteristics of the
> sent message in order
> to accomplish post-transformation delivery is a trade-off that raises
> general concerns,
> especially where a signature is present.

Yeah. You could say that's why it was do easy for John to goad me into=20
writing this document. I feel that the transition period (when most=20
users have only conventional clients but some users send some=20
internationalized mail) is bad and ugly and should be abbreviated at=20
almost any cost, and therefore implementers should get to work=20
implementing EAI proper rather than downgrade.

Maybe -simpledowngrade should mention how wondrously easy it is for an=20
IMAP client to learn to read internationalized email? (Sending may be a=20
little tricky, but reading really is simple.)

>>> >>  This may eliminate MIME parameters (see section 2.2); it may also
>>> >>  eliminate any header field not explicitly treated (the subject =
field
>>> >>  and those listed in 2.1).  This, combined with the possible =
invalidity
>>> >>  of signatures for signed body parts, can significantly reduce the
>>> >>  amount of data available to the user for making a determination =
of
>>> >>  whether or not a message is legitimate.
>> >
>> >
>> >  You seem to be describing a user who knows much about international=
ized
>> >  mail, who corresponds using internationalized mail, but who has no =
software
>> >  that supports it. Yes, it's hard on that user;)
>> >
> I think I am describing a conventional user more than an internationali=
zed email
> user.  If you have an expectation that an email message should contain
> certain things
> (or your user agent checks for validity by looking for specific
> things), this won't even present
> you nonsense in some places you are expecting sense.  It simply cuts
> the data.  How can
> the user or her delegated software assess that?

How can you assess the validity of an email message which uses new=20
syntax? Syntax you don't understand?

For an IMAP client willing to learn the new syntax, the answer is easy.=20
Send one ENABLE command (in IMAP) and learn to accept UTF-8 in all the=20
places where you only accepted ASCII until now. For someone not willing=20
to learn the new syntax, I don't think the question can have any very=20
good answer.

>>> >>  Crafting a message that
>>> >>  appeared to have already gone through this encoding also seems
>>> >>  relatively easy, making it possible for a sender to provide a =
message
>>> >>  that does not have the normal complement of data for assessment =
by a
>>> >>  user.
>> >
>> >
>> >  The assessment data is generally ASCII now, why would that change?
>> >
> If I craft a message without any of the headers that this allows me to
> excise and with
> .invalid-ed in From and Re-sent From, how can the user or the user
> agent distinguish
> that from the action of the server here?

Why is that task worth supporting?

I can think of an easy way to support it within simpledowngrade (a new=20
FETCH item). But issuing the ENABLE command and doing the analysis based=20
on the pristine message is just as easy.

>>> >>  The document does not describe how it relates to the other two =
options
>>> >>  the working group has discussed for downgrade.  I believe it =
should do
>>> >>  so in order to provide context for the choices made here.  A =
review of
>>> >>  the mailing list shows this message:
>>> >>  http://www.ietf.org/mail-archive/web/ima/current/msg04539.html   =
as
>>> >>  kicking off the core rationale and relationship.   Some form of =
this
>>> >>  should be included in the document, possibly along with the "no
>>> >>  downgrade" option.
>> >
>> >
>> >  I haven't added anything like this, because I'm not sure which =
document
>> >  should contain it.
>> >
>> >  I'll happily supply text.
>> >
> Thanks.  A pointer to text in another document would be equally valid.

My gut feeling is that we'll end up with an overview document of some=20
sort which links to both downgrade documents, and that that document is=20
the right place. But I confess I haven't tried to work out what that=20
means in concrete terms.

>> >  Would you be happy if the document specifies explicitly that the =
stored form
>> >  has to be the original message, not the synthesised form?
> Yes, I think that would be a useful addition.

OK.

Arnt

From fluffy@iii.ca  Tue Apr 24 10:48: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 A700221E80AB for ; Tue, 24 Apr 2012 10:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level: 
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9e6Fj4SayxE for ; Tue, 24 Apr 2012 10:48:04 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2C821E8024 for ; Tue, 24 Apr 2012 10:48:04 -0700 (PDT)
Received: from [10.154.36.65] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C457722E256; Tue, 24 Apr 2012 13:47:56 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1252
From: Cullen Jennings 
In-Reply-To: <01OEOWEMGCME0006TF@mauve.mrochek.com>
Date: Tue, 24 Apr 2012 10:47:55 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <41343CC3-D28C-42B7-8B08-03B6579458BD@iii.ca>
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org> <4F95D22A.6060500@stpeter.im> <01OEO1DMECF40006TF@mauve.mrochek.com>  <01OEOWEMGCME0006TF@mauve.mrochek.com>
To: Ned Freed 
X-Mailer: Apple Mail (2.1257)
Cc: "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 17:48:04 -0000

On Apr 24, 2012, at 8:51 , Ned Freed wrote:

>=20
>> On Apr 23, 2012, at 18:14 , Ned Freed wrote:
>=20
>>>>> application/senml+json
>>>>> application/senml+xml
>>>>> application/senml-exi
>=20
>> I think the idea that first two are OK but the third one needs to =
have a "-"
>> instead of a "+" is simply baffling. Can someone explain the logic to =
me ?
>=20
> +exi implies a syntax that can be processed generically by systems =
knowing

Thanks - that answer does help. But what do you mean can be "processed =
generically"? If we mean can check the syntax is valid, sure, all can do =
that. If we mean understand the semantic content of the data without the =
schema information,  it seem pretty unlikely that senml should have the =
+ for json or xml.=20

I will point out the senml mandates that data inside has to identify the =
schema in use for that inside the exi data - now it's not a globally =
resolvable URI for the schema or something but it does make sense in the =
context of senml. You can process the senml exi without the schema at =
least in the context of determining it might be valid exi.=20

But really the questions is what's is our definition of "generically =
processable" ?


> nothing specific about senml. But in order to decode schema-aware EXI, =
which is
> what is being used here, you have to know the schema for the specific =
version
> of senml that's in use. There is an field in the document itself that =
can be
> used to provide a pointer to the schema, but it's optional. In other =
words, in
> some cases the schema has to be known through out of band information, =
and that
> violates the rules for +suffix.
>=20
>> I'll rest the urge to insert a rant here about the reason people =
don't bother
>> to register new thing and just use text/plain for everything =85
>=20
> In turn I'll resist the urge to rant about folks who jump into a long
> discussion without making any attempt to read the preceeding messages =
and
> expect others to do their work for them.

I've really had read the whole thread when I sent the previous email. I =
think you will agree with me that many people find it is hard to =
register a new type like this. I applaud you doing the =
draft-ietf-appsawg-media-type-regs draft and the work on =
draft-hansen-media-type-suffix-regs to try and make this easier.=20=

From ned.freed@mrochek.com  Tue Apr 24 11:17: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 5096621F882D for ; Tue, 24 Apr 2012 11:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.497
X-Spam-Level: 
X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bIlWz6LpI1F for ; Tue, 24 Apr 2012 11:17:54 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 36F2D21F882B for ; Tue, 24 Apr 2012 11:17:54 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEP12JQ59C000958@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 24 Apr 2012 11:17:47 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Tue, 24 Apr 2012 11:17:45 -0700 (PDT)
Message-id: <01OEP12HVL860006TF@mauve.mrochek.com>
Date: Tue, 24 Apr 2012 10:51:28 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 24 Apr 2012 10:47:55 -0700" <41343CC3-D28C-42B7-8B08-03B6579458BD@iii.ca>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=windows-1252
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org> <4F95D22A.6060500@stpeter.im> <01OEO1DMECF40006TF@mauve.mrochek.com>  <01OEOWEMGCME0006TF@mauve.mrochek.com> <41343CC3-D28C-42B7-8B08-03B6579458BD@iii.ca>
To: Cullen Jennings 
Cc: Ned Freed , "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 18:17:55 -0000

> On Apr 24, 2012, at 8:51 , Ned Freed wrote:

> >
> >> On Apr 23, 2012, at 18:14 , Ned Freed wrote:
> >
> >>>>> application/senml+json
> >>>>> application/senml+xml
> >>>>> application/senml-exi
> >
> >> I think the idea that first two are OK but the third one needs to have a "-"
> >> instead of a "+" is simply baffling. Can someone explain the logic to me ?
> >
> > +exi implies a syntax that can be processed generically by systems knowing

> Thanks - that answer does help. But what do you mean can be "processed
> generically"? If we mean can check the syntax is valid, sure, all can do that.

Well, there are these things called XML editors and renderers... And probably
ones for JSON too, although I'm not as familiar with that space.

> If we mean understand the semantic content of the data without the schema
> information,  it seem pretty unlikely that senml should have the + for json or
> xml.

No, it doesn't mean that. If it did there would basically be no use-case at all
for +xml or +json.

> I will point out the senml mandates that data inside has to identify the
> schema in use for that inside the exi data - now it's not a globally resolvable
> URI for the schema or something but it does make sense in the context of senml.
> You can process the senml exi without the schema at least in the context of
> determining it might be valid exi.

First of all, it is by no means clear that even if the schema reference
was mandatory, it would fulfill the requirements of +suffixes. The idea
was that no external information would be needed to understand the syntax
of such types. As best I can tell, there is no consensus to loosen this.

That said, a +exi suffix is necessarily a generic mechanism that needs to be
able to apply to multiple types. If all such usage required explicit schema
specification in the document, or better still, mandated that EXI be operated
in schema-agnostic mode, then +exi might make sense. But it seems people using
EXI aren't willing to make that tradeoff in order to use +exi. Which given the 
target space I completely understand and agree with.

> But really the questions is what's is our definition of "generically
> processable" ?

It's pretty simple: Processing at the syntactic but no the semantic level.

> > discussion without making any attempt to read the preceeding messages and
> > expect others to do their work for them.

> I've really had read the whole thread when I sent the previous email. I think
> you will agree with me that many people find it is hard to register a new type
> like this.

Since on average I approve registration of several types a week, often on the
first submission and rarely requiring more than one revision, I really don't
agree. With senml you're apparently after the additional imprimateur of a
standards body - which is, or at least should be, a separate consideration -
and that necessarily is going to involve a lot more process.

>  I applaud you doing the draft-ietf-appsawg-media-type-regs draft and
> the work on draft-hansen-media-type-suffix-regs to try and make this easier.

Thanks. However, the main intent is to try and streamline the standards tree
process for other standards bodies, and of course to formalize the +suffix
business. The effect on RFCs that happen to define media types is going to be
fairly minimal.

				Ned

From msk@cloudmark.com  Tue Apr 24 11:58: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 BF9A021E80A5 for ; Tue, 24 Apr 2012 11:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.547
X-Spam-Level: 
X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHTEQ32sKB+i for ; Tue, 24 Apr 2012 11:58:21 -0700 (PDT)
Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 621EE21E80A4 for ; Tue, 24 Apr 2012 11:58:21 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 1tkX1j0010as01C01tkXiG; Tue, 24 Apr 2012 10:44:31 -0700
X-CMAE-Match: 0
X-CMAE-Score: 0.00
X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=9LL2mffbdxwA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=3JjZmSF931lozcl4X3QA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 10:44:10 -0700
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Thread-Topic: [apps-discuss] Call for Adoption: draft-kucherawy-received-state-02.txt
Thread-Index: AQHNIj9AN1nk+YFzr0W6hEyjxr2WzpaqPxOA
Date: Tue, 24 Apr 2012 17:44:09 +0000
Message-ID: <9452079D1A51524AA5749AD23E003928100E82@exch-mbx901.corp.cloudmark.com>
References: <4F96E203.5060105@isode.com>
In-Reply-To: <4F96E203.5060105@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.20.2.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335289471; bh=QIWB4cMW/2IdwPUwSV/BrnBKp55Dm3lKWmMmIBP/uhI=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=axNTQqIucrcweNB7du7+oEJvEH2cVAhpxhLfGD5kaAAtJHmoNHxRnRIUne/myOomy /ZxDGPqPf5zyXSWolq0BfQIUZEpc71XD2dKaLmcQbzTIeUBlmBZtMd0bGv2CeuUuPv k/FBRSf0sdsXIpw/fvwGcH+yQme8zsfL/6Rt31Sc=
Subject: Re: [apps-discuss] Call for Adoption:	draft-kucherawy-received-state-02.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, 24 Apr 2012 18:58:21 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of Alexey Melnikov
> Sent: Tuesday, April 24, 2012 10:25 AM
> To: apps-discuss@ietf.org
> Subject: [apps-discuss] Call for Adoption: draft-kucherawy-received-state=
-02.txt
>=20
> Murray presented this draft in at least one of the face to face IETF
> meetings and my recollection is that general feedback on this document
> was positive. So I would like to initiate acceptance call for
> processing this document in the APPSAWG.
>=20
> Please indicate your support or objection, and opinions thereto before
> the close of business on May 1st.
>=20
> Alexey, as an APPSAWG co-chair

I've forwarded this to ietf-822 and ietf-smtp as well.

-MSK

From arnt@gulbrandsen.priv.no  Tue Apr 24 12:03: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 B3DC121F877A; Tue, 24 Apr 2012 12:03:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.714
X-Spam-Level: 
X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=0.885,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mlw1ur8Mt1pC; Tue, 24 Apr 2012 12:03:58 -0700 (PDT)
Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 17A3E21F876C; Tue, 24 Apr 2012 12:03:58 -0700 (PDT)
Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 47C9CF8E58B; Tue, 24 Apr 2012 19:03:56 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1335294235-21918-21917/11/2; Tue, 24 Apr 2012 19:03:55 +0000
Message-Id: <4F96F91A.9010807@gulbrandsen.priv.no>
Date: Tue, 24 Apr 2012 21:03:54 +0200
From: Arnt Gulbrandsen 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
Mime-Version: 1.0
To: Ted Hardie , John Klensin , Joseph Yee 
References:  <4F95D991.5010603@gulbrandsen.priv.no>  <4F96E41D.1090405@gulbrandsen.priv.no>
In-Reply-To: <4F96E41D.1090405@gulbrandsen.priv.no>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Cc: draft-ietf-eai-simpledowngrade.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Review of draft-ietf-eai-simpledowngrade-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 19:03:58 -0000

Hi,

I went for a walk and pondered Ted's reading of the simpledowngrade 
document.

I wonder if it might not be a good idea to have an informational RFC 
entitled "The transition to internationalized mail", "Implementation 
recommendations for internationalized mail" or similar.

A page or a little more for each of a) MUAs as readers, b) as writers, 
c) IMAP servers, d) POP servers, e) MSAs and f) MTAs. A little bit of 
overview text, some examples, pointers to the relevant specifications 
for each. Not a single MUST or SHOULD, more than a bit of handwaving and 
general prose.

I'm willing to write it. Unless it exists and I've missed it, which 
would please me greatly. In that case I'll want to refer to it from 
simpledowngrade.

Arnt

From fluffy@iii.ca  Tue Apr 24 14:15: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 7AAAD11E80B6 for ; Tue, 24 Apr 2012 14:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.23
X-Spam-Level: 
X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.231,  BAYES_00=-2.599, J_CHICKENPOX_53=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l56XFIsKf8OZ for ; Tue, 24 Apr 2012 14:15:36 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D369211E80C8 for ; Tue, 24 Apr 2012 14:15:35 -0700 (PDT)
Received: from [10.154.36.65] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3FB8D22E25B; Tue, 24 Apr 2012 17:15:29 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings 
In-Reply-To: <01OEP12HVL860006TF@mauve.mrochek.com>
Date: Tue, 24 Apr 2012 14:15:27 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org> <4F95D22A.6060500@stpeter.im> <01OEO1DMECF40006TF@mauve.mrochek.com>  <01OEOWEMGCME0006TF@mauve.mrochek.com> <41343CC3-D28C-42B7-8B08-03B6579458BD@iii.ca> <01OEP12HVL860006TF@mauve.mrochek.com>
To: Ned Freed 
X-Mailer: Apple Mail (2.1257)
Cc: "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 21:15:36 -0000

On Apr 24, 2012, at 10:51 , Ned Freed wrote:

>=20
>> On Apr 24, 2012, at 8:51 , Ned Freed wrote:
>=20
>>>=20
>>>> On Apr 23, 2012, at 18:14 , Ned Freed wrote:
>>>=20
>>>>>>> application/senml+json
>>>>>>> application/senml+xml
>>>>>>> application/senml-exi
>>>=20
>>>> I think the idea that first two are OK but the third one needs to =
have a "-"
>>>> instead of a "+" is simply baffling. Can someone explain the logic =
to me ?
>>>=20
>>> +exi implies a syntax that can be processed generically by systems =
knowing
>=20
>> Thanks - that answer does help. But what do you mean can be =
"processed
>> generically"? If we mean can check the syntax is valid, sure, all can =
do that.
>=20
> Well, there are these things called XML editors and renderers... And =
probably
> ones for JSON too, although I'm not as familiar with that space.
>=20
>> If we mean understand the semantic content of the data without the =
schema
>> information,  it seem pretty unlikely that senml should have the + =
for json or
>> xml.
>=20
> No, it doesn't mean that. If it did there would basically be no =
use-case at all
> for +xml or +json.
>=20
>> I will point out the senml mandates that data inside has to identify =
the
>> schema in use for that inside the exi data - now it's not a globally =
resolvable
>> URI for the schema or something but it does make sense in the context =
of senml.
>> You can process the senml exi without the schema at least in the =
context of
>> determining it might be valid exi.
>=20
> First of all, it is by no means clear that even if the schema =
reference
> was mandatory, it would fulfill the requirements of +suffixes. The =
idea
> was that no external information would be needed to understand the =
syntax
> of such types. As best I can tell, there is no consensus to loosen =
this.
>=20
> That said, a +exi suffix is necessarily a generic mechanism that needs =
to be
> able to apply to multiple types. If all such usage required explicit =
schema
> specification in the document, or better still, mandated that EXI be =
operated
> in schema-agnostic mode, then +exi might make sense. But it seems =
people using
> EXI aren't willing to make that tradeoff in order to use +exi. Which =
given the=20
> target space I completely understand and agree with.
>=20
>> But really the questions is what's is our definition of "generically
>> processable" ?
>=20
> It's pretty simple: Processing at the syntactic but no the semantic =
level.

Ok, but it seem that is what EXI in this form allows - you can step over =
the elements, often find their types at the "string" "int" sort of level =
but can not expand what the actually tags names are without the schema =
but you tell there is a tag named something, you know if you encounter =
the same tag again, and so on. You can check it is valid.  I don't use =
EXI editors but they do exist and they should be able to load it and =
display it. It would look a lot like XML where all the tag names had =
been changed to tag1, tag2, tag3 etc but otherwise had the structure and =
many of the values.=20

Cullen

I should mention one thing - I have only participated in this thread =
because I did not think it is was clear why some things use + and some =
use -. For the uses of senml-exi that I care about senml-exi will work =
just as well as senml+exi. But what happens here seem like it will =
impact other uses of EXI.=20





From ned.freed@mrochek.com  Tue Apr 24 15:09: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 4386621F862F for ; Tue, 24 Apr 2012 15:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKpLvkD7R7Gb for ; Tue, 24 Apr 2012 15:09:52 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6941F21F8620 for ; Tue, 24 Apr 2012 15:09:52 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEP966AFZK0009CV@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 24 Apr 2012 15:09:48 -0700 (PDT)
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Tue, 24 Apr 2012 15:09:43 -0700 (PDT)
Message-id: <01OEP9640POM0006TF@mauve.mrochek.com>
Date: Tue, 24 Apr 2012 13:40:39 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 23 Apr 2012 09:23:28 -0700" 
References:  
To: Ted Hardie 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: Review of draft-ietf-eai-simpledowngrade-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Apr 2012 22:09:54 -0000

> Apologies; I forgot to cc this list on the review.

> regards,

> Ted


> ---------- Forwarded message ----------
> From: Ted Hardie 
> Date: Mon, Apr 23, 2012 at 8:57 AM
> Subject: Review of draft-ietf-eai-simpledowngrade-03
> To: draft-ietf-eai-simpledowngrade.all@tools.ietf.org
> Cc: IESG 


> 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:
> Title: EAI: Simplified POP/IMAP downgrading
> Reviewer: Ted Hardie
> Review Date: April 23, 2012

> Summary: I believe that the draft is almost ready for publication, but
> that it cannot be progressed on the standards track because of its
> impact on the security of the email messages.  I understand the
> reluctance of the WG to create Experimental documents at this stage,
> so I suggest Informational as a target status.

> Major Issues:

> The document is clear that its intent is to provide a
> simple-to-implement method that provides basic means for downgrading
> certain fields in a message.   A major element of its strategy is to
> silently excise information which cannot be presented to the user.
> This may eliminate MIME parameters (see section 2.2); it may also
> eliminate any header field not explicitly treated (the subject field
> and those listed in 2.1).  This, combined with the possible invalidity
> of signatures for signed body parts, can significantly reduce the
> amount of data available to the user for making a determination of
> whether or not a message is legitimate.  Crafting a message that
> appeared to have already gone through this encoding also seems
> relatively easy, making it possible for a sender to provide a message
> that does not have the normal complement of data for assessment by a
> user.

20 years ago MIME defined multipart/alternative, a mechanism by which different
users see different variations of the content of a message. This
opened the door wide to abuses where the variations actually say different
things.

This mechanism has proved to be incredibly popular - I personally recieve at
least a dozen messages employing multipart/alternative a day, mostly from
mailing lists with very large distributions. In a significant number of cases
the content of the alternatives is, shall we say, less than equivalent,
including lots of cases where there is simply no justification for the lack of
equivalence. But this is the result of carelessess, not abuse. (In fact I don't
believe I've ever heard of a case of outright abuse. If anyone has heard of one
I'd like to know about it.)

The IETF has had at least two working groups specifically focused on gatewaying
messages into restricted enviroments (FAX and voicemail), where the original
fidelity of many messages cannot possibly be maintained. An assortment of
standards-track documents have emerged from the these groups, including ones
defining fairly general mechanisms that give the sender (not the recipient)
some measure of control over various sorts of message alterations that include,
but are not limited to, excision of some content.

And then there's the practical, everyday reality, where message parts are
routinely converted from one form to another or simply removed, sometimes for
good reason and sometimes not. Sometimes annotations are used to note that such
operations have been performed, but a lot of times there is no indication that
such actions were performed anywhere in the message. (And it is highly
debatable given current client behavior whether or not adding a nonstandard
header actually constitutes any sort of real notification.)

The milter interface is an interesting manifestation of this. It provides for
wholesale modification of message content, and the popular MIMEdefang software
exploits this capability to provide all sorts of message modification
facilities.

In the specific case of MIME parameters, due to the presence of actively
exploited buffer overrun bugs in certain clients, it sometimes has been
necessary to length-limit or even remove certain parameters, including ones
that could be useful in determining message authenticity.

More generally, the business world seems to operate on the basis of documents
stored in various proprietary formats that are continually evolving and
changing, to the point where even if everyone uses the same program high
fidelity reproduction is often not achieved, and this often includes parts of
said documents being visible to some people and not others. And with different
programs... let me just say I have four different programs I switch between in
order to view the content of various documents because none of them work in all
cases.

So, while I am bit sympathetic (but not a whole lot) to the argument that we
shouldn't make an extremely bad situation a very tiny bit worse as part of a
transition plan, might I respectfully suggest that if this issue was important
to you, you're raising it about 25 years too late, and that the proverbial
horse left the barn long ago and we're now dealing with its 5th generation
offspring?

Oh, and as for the risk associated with being able to craft a nefarious message
that has undergone this transition, in order for that to stand any chance of
working you'd have to know that:

(a) The recipient has an EAI-enabled mailbox.
(b) The recipient uses a non-EAI client on that mailbox.
(c) The recipient never uses an EAI client on that mailbox.

It seems very likely that if you know all this, you know more than enough to be
able to fake things without resorting to this technique, especially given how
easily spoofable email in general is. Put differently, this is so far down the
branches of the attack tree we're talking about twigs where there are study
branches galore to stand on.

> Given this major loss of information, I do not believe that this
> document describes an approach that should be placed on the standards
> track; if the working group believes this to be valuable, it should be
> delivered as informational.

Frankly, I have little use for any of these schemes. My take is that the
combination of EAI with a non-EAI-capable client is sufficiently toxic - and
more importantly, so likely to be a major support call generator - that the
approach I strongly prefer is to simply not allow a non-EAI client to access an
EAI mailbox. In such a scenario the only place I see a use for downgrading is
if an upgrade was done in error and has to be reversed.

That said, given the present day reality of how email works, I also think the
security issues you're talking about here a very small beer both compared with
the security issues email has irrespective of EAI and to the other operational
problems downgrading is going to cause.

>  This seems also to be a better fit for
> the loose interoperablity strategy here:

> "The format of the display-name is explicitly unspecified. Anything
>   which tells the user what happened is good. Anything which produces
>   an email address which might belong to someone else is bad."

For better or worse, current mail access protocols provide no means of issuing
such a warning in a reliable fashion. And while adding the capability to do
this in a reliable fashion might be an interesting discussion, we of course
cannot have deployment of EAI depend on a mechanism that hasn't even been
defined, let alone universally deployed.

> ...

> This document does not describe how the IMAP/POP downgrade choices
> here would impact SIEVE script processing; I believe this represents
> an assumption on when the downgrade takes place which should be made
> explicit.

I'm not sure I see the issue. Unless the scope has been expanded at some point,
downgrading is intended to happen only when a non-EAI client accesses a message
in an EAI mailbox. (This, BTW, would provide a means by which fake messages
crafted to look like downgraded messages could be detected and dealt with,
assuming you think it is worth it, which I don't.)

Sieve processing is supposed to occur at  or around the time of final delivery,
so it happens before any of this stuff comes into play. Of course there is some
Sieve usage after message download, but in that case it happens after
downgrading.

It may be possible, depending on what client or clients are used, that a
mixture of downgraded and non-downgraded messages could be processed. Indeed,
it's entirely possible for both forms of the same message to be processed with
different results. But this is again small beer compared to the confusion this
will cause independent of any Sieve usage, and is why I think the intended use
of these downgrade mechanisms is actually a bad idea.

				Ned

P.S. Please note that I have not objected to these documents going on the
standards track. I understand the use-case for them even if I don't think it's
a good idea.

From ned.freed@mrochek.com  Tue Apr 24 17:54: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 3704511E80BF for ; Tue, 24 Apr 2012 17:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, J_CHICKENPOX_53=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfBR3FZdZK7K for ; Tue, 24 Apr 2012 17:54:33 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7D11711E809D for ; Tue, 24 Apr 2012 17:54:33 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEPEXDQYTS0009JJ@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 24 Apr 2012 17:54:29 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Tue, 24 Apr 2012 17:54:27 -0700 (PDT)
Message-id: <01OEPEXC13DK0006TF@mauve.mrochek.com>
Date: Tue, 24 Apr 2012 17:48:28 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 24 Apr 2012 14:15:27 -0700" 
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com>  <6CCF89EF-B173-4FBD-96F8-5D4C161FFC28@tzi.org> <4F95D22A.6060500@stpeter.im> <01OEO1DMECF40006TF@mauve.mrochek.com>  <01OEOWEMGCME0006TF@mauve.mrochek.com> <41343CC3-D28C-42B7-8B08-03B6579458BD@iii.ca> <01OEP12HVL860006TF@mauve.mrochek.com> 
To: Cullen Jennings 
Cc: Ned Freed , "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Apr 2012 00:54:34 -0000

> On Apr 24, 2012, at 10:51 , Ned Freed wrote:

> >
> >> On Apr 24, 2012, at 8:51 , Ned Freed wrote:
> >
> >>>
> >>>> On Apr 23, 2012, at 18:14 , Ned Freed wrote:
> >>>
> >>>>>>> application/senml+json
> >>>>>>> application/senml+xml
> >>>>>>> application/senml-exi
> >>>
> >>>> I think the idea that first two are OK but the third one needs to have a "-"
> >>>> instead of a "+" is simply baffling. Can someone explain the logic to me ?
> >>>
> >>> +exi implies a syntax that can be processed generically by systems knowing
> >
> >> Thanks - that answer does help. But what do you mean can be "processed
> >> generically"? If we mean can check the syntax is valid, sure, all can do that.
> >
> > Well, there are these things called XML editors and renderers... And probably
> > ones for JSON too, although I'm not as familiar with that space.
> >
> >> If we mean understand the semantic content of the data without the schema
> >> information,  it seem pretty unlikely that senml should have the + for json or
> >> xml.
> >
> > No, it doesn't mean that. If it did there would basically be no use-case at all
> > for +xml or +json.
> >
> >> I will point out the senml mandates that data inside has to identify the
> >> schema in use for that inside the exi data - now it's not a globally resolvable
> >> URI for the schema or something but it does make sense in the context of senml.
> >> You can process the senml exi without the schema at least in the context of
> >> determining it might be valid exi.
> >
> > First of all, it is by no means clear that even if the schema reference
> > was mandatory, it would fulfill the requirements of +suffixes. The idea
> > was that no external information would be needed to understand the syntax
> > of such types. As best I can tell, there is no consensus to loosen this.
> >
> > That said, a +exi suffix is necessarily a generic mechanism that needs to be
> > able to apply to multiple types. If all such usage required explicit schema
> > specification in the document, or better still, mandated that EXI be operated
> > in schema-agnostic mode, then +exi might make sense. But it seems people using
> > EXI aren't willing to make that tradeoff in order to use +exi. Which given the
> > target space I completely understand and agree with.
> >
> >> But really the questions is what's is our definition of "generically
> >> processable" ?
> >
> > It's pretty simple: Processing at the syntactic but no the semantic level.

> Ok, but it seem that is what EXI in this form allows - you can step over the
> elements, often find their types at the "string" "int" sort of level but can
> not expand what the actually tags names are without the schema but you tell
> there is a tag named something, you know if you encounter the same tag again,
> and so on. You can check it is valid.  I don't use EXI editors but they do
> exist and they should be able to load it and display it. It would look a lot
> like XML where all the tag names had been changed to tag1, tag2, tag3 etc but
> otherwise had the structure and many of the values.

This boils down to expectations. The expectation is going to be behavior
comparable to XML. That expectation won't be met.

Contrast this with BER and friends, where there is no expectation that you'll
be able to see the "tag names" unless you have the schema.

> I should mention one thing - I have only participated in this thread because
> I did not think it is was clear why some things use + and some use -. For the
> uses of senml-exi that I care about senml-exi will work just as well as
> senml+exi. But what happens here seem like it will impact other uses of EXI.

That's actually rather doubtful, since the criteria for +suffix are, AFAIK,
fairly unique.

No, it's the design choice to have schema dependencies in the absence of a
reliable way to know what the schema is that is going to impact EXI. For
example, schema-aware EXI as content encoding appears to be a nonstarter, and
that's going to be true irrespective of how it is handled as a suffix.

				Ned

From ve7jtb@ve7jtb.com  Tue Apr 24 19:09: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 C66BB21E8012 for ; Tue, 24 Apr 2012 19:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.479
X-Spam-Level: 
X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuPCZ0CXyF+b for ; Tue, 24 Apr 2012 19:09:11 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD8311E8074 for ; Tue, 24 Apr 2012 19:09:11 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so1033750ghb.31 for ; Tue, 24 Apr 2012 19:09:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:mime-version:content-type:subject:date:references:cc:to :message-id:x-mailer:x-gm-message-state; bh=Ix8vNQNzv1AaSF0MoL2Wn7GbIPJhpWJpDFCuUyKuzsQ=; b=oYlE7qedLBef0VT5VJ9iicZezUj5DHoog2O4NgE+Bln+DnVShDHcMei31TbbpdQS3u fBjpOuqEDVcb3oyWwRl0mUOYWTQu0eJzS5Kvk1RqEWdddg/saWN281cbPfZPAZH9f00/ OWvbElKeVwevyFVkjsqkfO5li6B9CSYmZfrDS8U+aXCvV7jYgSQNk3hbcgqYhL86FfEX wRHBD9t34Reqjfa9j7hbzEOTT15aMcFYrzofYh2U/rldU5h+KdNwh02fKLC9Oaj47l3f 3oGNpvkY0MIQZZAIMqG/L3K+WyVLBbEin79pb9n/B4v2dtbR2iXSSRcRFLukYibdWQmI XBFg==
Received: by 10.236.82.134 with SMTP id o6mr707378yhe.51.1335319750905; Tue, 24 Apr 2012 19:09:10 -0700 (PDT)
Received: from [192.168.1.213] (190-20-33-66.baf.movistar.cl. [190.20.33.66]) by mx.google.com with ESMTPS id t43sm94925201yht.11.2012.04.24.19.08.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 19:09:09 -0700 (PDT)
From: John Bradley 
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_351B68B0-584D-40F9-B423-4EF2E9638900"; protocol="application/pkcs7-signature"; micalg=sha1
Date: Tue, 24 Apr 2012 23:08:38 -0300
References: <4E1F6AAD24975D4BA5B1680429673943664980EB@TK5EX14MBXC284.redmond.corp.microsoft.com>
To: apps-discuss@ietf.org
Message-Id: <60A11443-8F46-42E5-A00B-B2FA8F7A7CAC@ve7jtb.com>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQkNqzEIta9t0NnN3W6588rxhLA5cNM/YodQyL7dXOO2AK2738apsKiDyTgeoM9DgRLLleWt
Subject: [apps-discuss] Fwd: Draft for apps discuss
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 02:09:12 -0000

--Apple-Mail=_351B68B0-584D-40F9-B423-4EF2E9638900
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_743A7804-156F-40A0-AAEA-50152FE98576"


--Apple-Mail=_743A7804-156F-40A0-AAEA-50152FE98576
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Paul,

I am looking at how the flows in WF might work for openID.

Let's set aside the XML issue for the moment and focus on the JSON flow.

Please correct anything I get wrong.

The openID Connect defines a relation of =
http://openid.net/specs/connect/issuer

WF allows for a JSON host-meta that takes two parameters, "resource" and =
"rel"

An example request and response (line-brakes for readability)

GET /.well-known/host-meta.json
     ?resource=3Djoe@example.com
     &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
 Host: example.com

   HTTP/1.1 200 OK

   Access-Control-Allow-Origin: *
   Content-Type: application/json; charset=3DUTF-8

   {
     "subject" : "joe@example.com",
     "links" :
     [
       {
         "rel" : "http://openid.net/specs/connect/issuer",
         "href" : "https://server.example.com"
       }
     ]
   }

If the host can't support rewrite rules or scripts the exchange would =
look like:

GET /.well-known/host-meta.json
     ?resource=3Djoe@example.com
     &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
 Host: example.com

HTTP/1.1 200 OK
   Access-Control-Allow-Origin: *
   Content-Type: application/json; charset=3DUTF-8
   {
     "expires" : "2012-03-13T20:56:11Z",
     "links" :
     [
       {
         "rel" : "lrdd",
         "type" : "application/json",
         "template" :
           "https://example.com/lrdd/?format=3Djson&resource=3D{uri}"
       }

GET /lrdd/
     ?format=3Djson
     &resource=3Djoe@example.com
 Host: example.com

HTTP/1.1 200 OK

   Access-Control-Allow-Origin: *
   Content-Type: application/json; charset=3DUTF-8

   {
     "subject" : "joe@example.com",
     "links" :
     [
       {
         "rel" : "http://openid.net/specs/connect/issuer",
         "href" : "https://server.example.com"
       },
       {
         "rel" : "http://webfinger.net/rel/avatar",
         "href" : "http://example.com/~joe/joe.jpg"
       }

     ]
   }

I can't find a template parameter for "rel".  The host-meta spec allows =
for extension but it is missing.

What if the server wants to support filtering on del but can't support =
it in the root for some reason?

Is it possible to have a template like:
"https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}"

That simple addition may solve a number of problems for openID.

John B.


--Apple-Mail=_743A7804-156F-40A0-AAEA-50152FE98576
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

 http://openid.net/specs/co=
nnect/issuer

WF allows for a JSON host-meta that =
takes two parameters, "resource" and "rel"

An example =
request and response (line-brakes for readability)

GET =
/.well-known/host-meta.json
     ?resource=3Djoe@example.com
     &rel=3Dhttp%3A%2F%2Fopen=
id.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
 Host: example.com

  =
; HTTP/1.1 200 =
OK

   Access-Control-Allow-Origin: =
*
   Content-Type: application/json; =
charset=3DUTF-8

   {
 =
    "subject" : "joe@example.com",
 =
    "links" =
:
     [
  =
     {
    &nbs=
p;    "rel" : "http://openid.net/specs/co=
nnect/issuer",
       =
;  "href" : "https://server.example.com"
       }
 &=
nbsp;   ]
   }

If the host can't support rewrite rules or scripts the exchange would =
look like:

GET =
/.well-known/host-meta.json
     ?resource=3Djoe@example.com
     &rel=3Dhttp%3A%2F%2Fopen=
id.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
 Host: example.com

HTTP/1.1 =
200 OK
   Access-Control-Allow-Origin: =
*
   Content-Type: application/json; =
charset=3DUTF-8
   {
 &nbs=
p;   "expires" : =
"2012-03-13T20:56:11Z",
     "links=
" =
:
     [
  =
     {
    &nbs=
p;    "rel" : =
"lrdd",
        &nbs=
p;"type" : =
"application/json",
      &nbs=
p;  "template" =
:
       }

GET =
/lrdd/
     ?format=3Djson
 Host: example.com

HTTP/1.1 =
200 OK

   Access-Control-Allow-Origin: =
*
   Content-Type: application/json; =
charset=3DUTF-8

   {
 =
    "subject" : "joe@example.com",
 =
    "links" =
:
     [
  =
     {
    &nbs=
p;    "rel" : "http://openid.net/specs/co=
nnect/issuer",

=

--Apple-Mail=_743A7804-156F-40A0-AAEA-50152FE98576--

--Apple-Mail=_351B68B0-584D-40F9-B423-4EF2E9638900
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
NTAyMDgzOVowIwYJKoZIhvcNAQkEMRYEFPGeHcTIQrehdNBo0Ygrz4RL8QhBMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AC87uTolfHa/ZSu7BBBf0oq7M0KIAzGpqp33ZoETglXp/yypDwE69bjOU6zBbYyM5zFo+6FpE/ks
rt4YjE0Z+xu99/x363lW8qvuhixTQHfXTnoT9YRTzJ2KJRanRO9l60CZWzf/ZcPCtvmehkLbWG/7
ZEpf6oSuNTWgisjkbs4ci6ZbXl0AXz2AypbYF6ZrTeY6rj3r260+laD7Lsx6C7y13viS0dFwnZkf
CZQbRZgebVISFX7D6nPDZPRy4ietfqCAcfDaprnbDmmVkrizLOb53UJ42os1lvehYWn3CplcnqDM
qjW0veJ1Ux92de/HBMIaQ0fckoVYEGiBsMWj4NEAAAAAAAA=

--Apple-Mail=_351B68B0-584D-40F9-B423-4EF2E9638900--

From ve7jtb@ve7jtb.com  Tue Apr 24 19:17: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 9EF4321E8032 for ; Tue, 24 Apr 2012 19:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.478
X-Spam-Level: 
X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XSfGpK0wftU for ; Tue, 24 Apr 2012 19:17:15 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC0521E802D for ; Tue, 24 Apr 2012 19:17:15 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so1036518ghb.31 for ; Tue, 24 Apr 2012 19:17:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:mime-version:content-type:subject:date:references:cc:to :message-id:x-mailer:x-gm-message-state; bh=hLw46OH5gtUU6K9zefOMwvF069140vxyIRwfYwcVdHc=; b=HjSZed42rxYCGeGwLmHeEUmE5FKdvr8W868JWDJsYkCN7ZrY5INMdiD9Z4o7xQ0zjE 47+i2ORbjdyPccflbvXOC8/+g69O6Rbfdl8zpr2vm70bmj363pTIHQOlcDOPW5aageK+ pymehDUC27FOK453XmEJwiwdjW+3EsHBzrbnjj6mud0SDEfLxzhc9FA4KhLJ8HDyJFCX Tpb31czXQZT4Sqfz+JhrT8ArzEAiIJ0A4v7ZLGTPBhHiwsya3yRiwJICMw/Fz32RO091 tf1/USpXu7aKmqPfe1z5OACefjBQ4Pev4WDyKRLSaqRhwfHpWQbDN/cLRXLNKNrlarFW 24kg==
Received: by 10.236.184.193 with SMTP id s41mr617251yhm.127.1335320234955; Tue, 24 Apr 2012 19:17:14 -0700 (PDT)
Received: from [192.168.1.213] (190-20-33-66.baf.movistar.cl. [190.20.33.66]) by mx.google.com with ESMTPS id o15sm13004214anj.1.2012.04.24.19.16.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 19:17:13 -0700 (PDT)
From: John Bradley 
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_A0CF13AB-E68E-4529-803F-2A09EA42ABFE"; protocol="application/pkcs7-signature"; micalg=sha1
Date: Tue, 24 Apr 2012 23:16:35 -0300
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com>
To: "Paul E. Jones" 
Message-Id: <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQmccqZbYwEtWKJ7ZV/niEvVtb7I9ExR1uU9rZaycKKoFbIdLbndyJYNm8hXTtAOc6Wsldqn
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 02:17:16 -0000

--Apple-Mail=_A0CF13AB-E68E-4529-803F-2A09EA42ABFE
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FA0EF794-7676-4495-9360-B7FDDC0A537B"


--Apple-Mail=_FA0EF794-7676-4495-9360-B7FDDC0A537B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Paul,

Sorry I hit send on the previous message with a typo.

I am looking at how the flows in WF might work for openID.

Let's set aside the XML issue for the moment and focus on the JSON flow.

Please correct anything I get wrong.

The openID Connect defines a relation of =
http://openid.net/specs/connect/issuer

WF allows for a JSON host-meta that takes two parameters, "resource" and =
"rel"

An example request and response (line-brakes for readability)

GET /.well-known/host-meta.json
     ?resource=3Djoe@example.com
     &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
 Host: example.com

   HTTP/1.1 200 OK

   Access-Control-Allow-Origin: *
   Content-Type: application/json; charset=3DUTF-8

   {
     "subject" : "joe@example.com",
     "links" :
     [
       {
         "rel" : "http://openid.net/specs/connect/issuer",
         "href" : "https://server.example.com"
       }
     ]
   }

If the host can't support rewrite rules or scripts the exchange would =
look like:

GET /.well-known/host-meta.json
     ?resource=3Djoe@example.com
     &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
 Host: example.com

HTTP/1.1 200 OK
   Access-Control-Allow-Origin: *
   Content-Type: application/json; charset=3DUTF-8
   {
     "expires" : "2012-03-13T20:56:11Z",
     "links" :
     [
       {
         "rel" : "lrdd",
         "type" : "application/json",
         "template" :
           "https://example.com/lrdd/?format=3Djson&resource=3D{uri}"
       }

GET /lrdd/
     ?format=3Djson
     &resource=3Djoe@example.com
 Host: example.com

HTTP/1.1 200 OK

   Access-Control-Allow-Origin: *
   Content-Type: application/json; charset=3DUTF-8

   {
     "subject" : "joe@example.com",
     "links" :
     [
       {
         "rel" : "http://openid.net/specs/connect/issuer",
         "href" : "https://server.example.com"
       },
       {
         "rel" : "http://webfinger.net/rel/avatar",
         "href" : "http://example.com/~joe/joe.jpg"
       }

     ]
   }

I can't find a template parameter for "rel".  The host-meta spec allows =
for extension but it is missing.

What if the server wants to support filtering on rel but can't support =
it in the root for some reason?

Is it possible to have a template like:
"https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}"

That simple addition may solve a number of problems for openID.

John B.




--Apple-Mail=_FA0EF794-7676-4495-9360-B7FDDC0A537B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Paul,

Sorry I hit =
send on the previous message with a typo.

I am =
looking at how the flows in WF might work for =
openID.

Let's set aside the XML issue for the =
moment and focus on the JSON flow.

WF allows for a JSON host-meta that =
takes two parameters, "resource" and "rel"

An example =
request and response (line-brakes for readability)

GET =
/.well-known/host-meta.json
     ?resource=3Djoe@example.com
     &rel=3Dhttp%3A%2F%2Fopen=
id.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
 Host: example.com

  =
; HTTP/1.1 200 =
OK

   Access-Control-Allow-Origin: =
*
   Content-Type: application/json; =
charset=3DUTF-8

   {
 =
    "subject" : "joe@example.com",
 =
    "links" =
:
     [
  =
     {
    &nbs=
p;    "rel" : "http://openid.net/specs/co=
nnect/issuer",
       =
;  "href" : "https://server.example.com"
       }
 &=
nbsp;   ]
   }

If the host can't support rewrite rules or scripts the exchange would =
look like:

GET =
/.well-known/host-meta.json
     ?resource=3Djoe@example.com
     &rel=3Dhttp%3A%2F%2Fopen=
id.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
 Host: example.com

HTTP/1.1 =
200 OK
   Access-Control-Allow-Origin: =
*
   Content-Type: application/json; =
charset=3DUTF-8
   {
 &nbs=
p;   "expires" : =
"2012-03-13T20:56:11Z",
     "links=
" =
:
     [
  =
     {
    &nbs=
p;    "rel" : =
"lrdd",
        &nbs=
p;"type" : =
"application/json",
      &nbs=
p;  "template" =
:
       }

GET =
/lrdd/
     ?format=3Djson
 Host: example.com

HTTP/1.1 =
200 OK

   Access-Control-Allow-Origin: =
*
   Content-Type: application/json; =
charset=3DUTF-8

   {
 =
    "subject" : "joe@example.com",
 =
    "links" =
:
     [
  =
     {
    &nbs=
p;    "rel" : "http://openid.net/specs/co=
nnect/issuer",



=

--Apple-Mail=_FA0EF794-7676-4495-9360-B7FDDC0A537B--

--Apple-Mail=_A0CF13AB-E68E-4529-803F-2A09EA42ABFE
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
NTAyMTYzNlowIwYJKoZIhvcNAQkEMRYEFBAEyAtaZH6EFqg7q8MsIlPqPI/pMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AIWnBKf52XYYfijCpIR1f+pg1DZfyNj/MkUqf5nZRO2ISyqoh4cpxOgnvnJlhc1HW56+KLxIT3o3
RaFgC9vBCV1HVXdtZd0gG5oo6fu/1z/AEooCUX/QFNFrpQse8gXrjrDE+Y5WBH33EjUxmxTQzdAP
Z/ga/L2o0+tx/abZoSOy+LqzMxs+lTRQzNKtbIKn9lw1eHeVycvVxG6D8JGvvqwrb20u9OncQBDa
WefOLGS7v4thg4ErH5xZOgu++xMfRaUwVsv5ovXUBV8Xgs9o9Y/XPoVTwGD0lCx3IKr/qeZQSdtR
PHhjzNu4WHDDd+lJ5m3eU4P96VYgIqdxjq+2EVwAAAAAAAA=

--Apple-Mail=_A0CF13AB-E68E-4529-803F-2A09EA42ABFE--

From johnl@iecc.com  Tue Apr 24 21:04: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 2DFCC21F864B for ; Tue, 24 Apr 2012 21:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.053
X-Spam-Level: 
X-Spam-Status: No, score=-111.053 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL4UAeZUZEux for ; Tue, 24 Apr 2012 21:04:55 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6707321F8647 for ; Tue, 24 Apr 2012 21:04:55 -0700 (PDT)
Received: (qmail 98228 invoked from network); 25 Apr 2012 04:04:53 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Apr 2012 04:04:53 -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=4f9777e5.xn--3zv.k1204; i=johnl@user.iecc.com; bh=jw/GiOv18B7gpIdYh7liR3RB27BsNu8i10t3dsntSoo=; b=QtDeA2JpgzIKeaSGfZJPAOstx6JFmX1Wxz4Pe/ODzvR7rJYFsOk1OwZ6mVmpdj1crOO329xWBA39HY8r5Z33Xl1GOmCzHTGZMUt77hyvCr4T0rFbIDIeFDQDL/BBRHv7xLcLgmlCVpjbJmUpGNIcyvg2PXnOq/Mf7yWaHIWDPT4=
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=4f9777e5.xn--3zv.k1204; olt=johnl@user.iecc.com; bh=jw/GiOv18B7gpIdYh7liR3RB27BsNu8i10t3dsntSoo=; b=YafTzUqsuF76si9QuZ7W2rvJxzcInuWZviKNCU3q3vO9V/qxvlb/7rns1a3xB9s5lK4zd539JtDwAWRfwiWIsWupDnUllvTazi4opTyojhdoqokBZ2I8SAU7N/WQKnS+a11DqvQhqI3edaG+t6+BFPLpmS22A5EISVUa6/KKspU=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 25 Apr 2012 04:04:31 -0000
Message-ID: <20120425040431.32686.qmail@joyce.lan>
From: "John Levine" 
To: apps-discuss@ietf.org
In-Reply-To: <4F96F91A.9010807@gulbrandsen.priv.no>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Cc: arnt@gulbrandsen.priv.no
Subject: Re: [apps-discuss] Review of draft-ietf-eai-simpledowngrade-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: Wed, 25 Apr 2012 04:04:56 -0000

>I wonder if it might not be a good idea to have an informational RFC 
>entitled "The transition to internationalized mail", "Implementation 
>recommendations for internationalized mail" or similar.

It's not a bad idea.  It would be helpful if it could give some of the
motivations for NOT providing more complex backward compatibility and
downgrade options, basically that they all turned out to add more
problems than they solved, and that the goal is to encourage people
to move to an all-EAI environment.

R's,
John




From johnl@iecc.com  Tue Apr 24 22:23: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 7B92A21F8644 for ; Tue, 24 Apr 2012 22:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.059
X-Spam-Level: 
X-Spam-Status: No, score=-111.059 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QyIRa+ySnzy for ; Tue, 24 Apr 2012 22:23:40 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 51BD921F862F for ; Tue, 24 Apr 2012 22:23:40 -0700 (PDT)
Received: (qmail 12343 invoked from network); 25 Apr 2012 05:23:39 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Apr 2012 05:23:39 -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=4f978a5b.xn--i8sz2z.k1204; i=johnl@user.iecc.com; bh=cxpWPL0+i0POrQFfqr1DOK5SlUOl93u3n/QuS35hSvg=; b=JSU+kUxEG7qQvzxItXSNvMYtJWMJwnataK+mdqpcAtQRlLCSSJDSl8oVCULIvRlcMalwJAglHn7ZqI23Cl0npNs8Yvv6UnyoqY01PFwcyJwNwxnF0Y51Wnv7z8YiuagQOKa0/8ycsROrbZDopxXno7OwlD9r02oyULN/Yrc0PWw=
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=4f978a5b.xn--i8sz2z.k1204; olt=johnl@user.iecc.com; bh=cxpWPL0+i0POrQFfqr1DOK5SlUOl93u3n/QuS35hSvg=; b=FR9aij7FTUcj0FNYTpl6XsVooMAiwlARH6HmlvO9hqoI/kSiprInQYcUvk+5RNz9yKsBeGb6oDyHUWn0FPN39I8DEqeYoQvvmFnupJpq9MtebK6uzGt/cE6/jUHaVzcf72jVL5EPPhQxkm5A3ITNRUr5Y+au+Zb4bueo95xb7gE=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 25 Apr 2012 05:23:17 -0000
Message-ID: <20120425052317.77243.qmail@joyce.lan>
From: "John Levine" 
To: apps-discuss@ietf.org
In-Reply-To: <9452079D1A51524AA5749AD23E003928100E82@exch-mbx901.corp.cloudmark.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Subject: Re: [apps-discuss] Call for Adoption:	draft-kucherawy-received-state-02.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, 25 Apr 2012 05:23:41 -0000

>> Please indicate your support or objection, and opinions thereto before
>> the close of business on May 1st.

I have my doubts about the utility of this feature, but it is at worst
harmless so it's fine to publish it.  The quality of the draft is good,
didn't see anything that needed to change.

R's,
John


From paulej@packetizer.com  Tue Apr 24 22: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 4B29321F8647 for ; Tue, 24 Apr 2012 22:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.314
X-Spam-Level: 
X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKDUBO9giQzy for ; Tue, 24 Apr 2012 22:25:23 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1288321F862F for ; Tue, 24 Apr 2012 22:25:22 -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 q3P5PL4H007686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Apr 2012 01:25:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335331522; bh=kX2S89Fi0PQMeIa0GNP+vZlJ9E6IgT8GtOBJxpaF75Y=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=IDXUrVj4cyylQfSv7oPCen9n257xMUNax35pPPrEiuUcK9wEkSW8wNQ0ouolIeurT TPopmrGpPaUp3TAq7rsZSaIm+GL/3lMmkNoUXbpLqkGFp0EjYyYX2LWWNwskRkT5EI AYaE2HxImbYxp8tfbSC3CTBgbTSbZrUHL7xhtviI=
From: "Paul E. Jones" 
To: "'John Bradley'" 
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com>
In-Reply-To: <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com>
Date: Wed, 25 Apr 2012 01:25:27 -0400
Message-ID: <042501cd22a3$d37d24a0$7a776de0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0426_01CD2282.4C6DCE90"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIsWOE+Nj6a2+m+DlaA/0DoJV2C/wIeE8UWldulPoA=
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 05:25:26 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0426_01CD2282.4C6DCE90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

John,

 

The "rel" parameter is something we still need to discuss, so not is as good
a time as any.

 

What "rel" does is act as a filter.  For the most part, the only purpose it
serves is to help reduce the number of link relations that might be sent
from the server.  So, if a user had 1,000 different link relations, this
might reduce the returned message to containing only 1.  However, if a user
has more than one link relation of the same type, all of them would match
and be returned.

 

When you say the host cannot support re-write rules, I assume you mean it
does not support the URI parameters on host-meta?  In that case, yes, the
parameters are ignored and you get just the host-meta document.

 

The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1).  There
are no other URI template values defined.  (Note: this whole section exists
only because RFC  6570 did not yet exist, I think.

 

In any case, we could define a new URI template, but then we would be
putting an optimization in place for LRDD.  If host-meta is not going to
support the "rel" URI parameter, why would LRDD?  It would also mean that
the LRDD logic would have to be ready to receive a URI parameter that is not
replaced, since some clients would only change {uri} and leave {rel} there.
That would introduce more conditional logic in the server.  This would also
present issues with static sites.  (Of course, one might be able to use
Apache re-writing rules to get around that problem, but it certainly would
not work for "real" static sites.)

 

Personally,  I'd prefer to not add the "rel" parameter to LRDD, since I
think optimization using "rel" would always be done on host-meta.  That
said, I question the value of "rel" entirely.  Do you think it's useful to
have this filter at all?  Is there really a risk that a site might return
1,000 link relations that the client would have to step over?

 

Paul

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, April 24, 2012 10:17 PM
To: Paul E. Jones
Cc: apps-discuss@ietf.org
Subject: WF flow with rel parameter

 

Paul,

 

Sorry I hit send on the previous message with a typo.

 

I am looking at how the flows in WF might work for openID.

 

Let's set aside the XML issue for the moment and focus on the JSON flow.

 

Please correct anything I get wrong.

 

The openID Connect defines a relation of
http://openid.net/specs/connect/issuer

 

WF allows for a JSON host-meta that takes two parameters, "resource" and
"rel"

 

An example request and response (line-brakes for readability)

 

GET /.well-known/host-meta.json

     ?resource=joe@example.com

     &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1

 Host: example.com  

 

   HTTP/1.1 200 OK

 

   Access-Control-Allow-Origin: *

   Content-Type: application/json; charset=UTF-8

 

   {

     "subject" : "joe@example.com",

     "links" :

     [

       {

         "rel" : "http://openid.net/specs/connect/issuer",

         "href" : "https://server.example.com 
"

       }

     ]

   }

 

If the host can't support rewrite rules or scripts the exchange would look
like:

 

GET /.well-known/host-meta.json

     ?resource=joe@example.com

     &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1

 Host: example.com  

 

HTTP/1.1 200 OK

   Access-Control-Allow-Origin: *

   Content-Type: application/json; charset=UTF-8

   {

     "expires" : "2012-03-13T20:56:11Z",

     "links" :

     [

       {

         "rel" : "lrdd",

         "type" : "application/json",

         "template" :

           "https://example.com/lrdd/?format=json
 &resource={uri}"

       }

 

GET /lrdd/

     ?format=json

     &resource=joe@example.com

 Host: example.com  

 

HTTP/1.1 200 OK

 

   Access-Control-Allow-Origin: *

   Content-Type: application/json; charset=UTF-8

 

   {

     "subject" : "joe@example.com",

     "links" :

     [

       {

         "rel" : "http://openid.net/specs/connect/issuer",

         "href" : "https://server.example.com 
"

       },

       {

         "rel" : "http://webfinger.net/rel/avatar",

         "href" : "http://example.com/~joe/joe.jpg"

       }

 

     ]

   }

 

I can't find a template parameter for "rel".  The host-meta spec allows for
extension but it is missing.

 

What if the server wants to support filtering on rel but can't support it in
the root for some reason?

 

Is it possible to have a template like:

"https://example.com/lrdd/?format=json

&resource={uri}&rel={rel}"

 

That simple addition may solve a number of problems for openID.

 

John B.

 

 

 


------=_NextPart_000_0426_01CD2282.4C6DCE90
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


John,
 
The “rel” parameter is something we still need to =
discuss, so not is as good a time as any.
 
What “rel” does is act as a filter.  For the most =
part, the only purpose it serves is to help reduce the number of link =
relations that might be sent from the server.  So, if a user had =
1,000 different link relations, this might reduce the returned message =
to containing only 1.  However, if a user has more than one link =
relation of the same type, all of them would match and be =
returned.
 
When you say the host cannot support re-write rules, I assume you =
mean it does not support the URI parameters on host-meta?  In that =
case, yes, the parameters are ignored and you get just the host-meta =
document.
 
The only URI template defined in RFC 6415 is “{uri}” (see =
3.1.1.1).  There are no other URI template values defined.  =
(Note: this whole section exists only because RFC  6570 did not yet =
exist, I think.
 
In any case, we could define a new URI template, but then we would be =
putting an optimization in place for LRDD.  If host-meta is not =
going to support the “rel” URI parameter, why would =
LRDD?  It would also mean that the LRDD logic would have to be =
ready to receive a URI parameter that is not replaced, since some =
clients would only change {uri} and leave {rel} there.  That would =
introduce more conditional logic in the server.  This would also =
present issues with static sites.  (Of course, one might be able to =
use Apache re-writing rules to get around that problem, but it certainly =
would not work for “real” static =
sites.)
 
Personally,  I’d prefer to not add the =
“rel” parameter to LRDD, since I think optimization using =
“rel” would always be done on host-meta.  That said, I =
question the value of “rel” entirely.  Do you think =
it’s useful to have this filter at all?  Is there really a =
risk that a site might return 1,000 link relations that the client would =
have to step over?
 
Paul
 
From:=
 =
John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, April =
24, 2012 10:17 PM
To: Paul E. Jones
Cc: =
apps-discuss@ietf.org
Subject: WF flow with rel =
parameter
 
Paul,
 
Sorry I hit send on the previous message with a =
typo.
 
I am =
looking at how the flows in WF might work for =
openID.
 
Let's set aside the XML issue for the moment and focus =
on the JSON flow.
&nbs=
p;
Please =
correct anything I get wrong.
&nbs=
p;
The =
openID Connect defines a relation of http://openid.net/specs/c=
onnect/issuer
&nbs=
p;
WF =
allows for a JSON host-meta that takes two parameters, =
"resource" and "rel"
&nbs=
p;
An =
example request and response (line-brakes for =
readability)
&nbs=
p;
GET =
/.well-known/host-meta.json
<=
p class=3DMsoNormal>&nbs=
p;
 &nb=
sp; HTTP/1.1 200 OK
&nbs=
p;
 &nb=
sp; Access-Control-Allow-Origin: =
*
 &nb=
sp; Content-Type: application/json; =
charset=3DUTF-8
&nbs=
p;
 &nb=
sp; {
 &nb=
sp;   "subject" : "joe@example.com",
 &nb=
sp;   "links" =
:
 &nb=
sp;   [
 &nb=
sp;     {
 &nb=
sp;       "rel" : "http://openid.net/specs/c=
onnect/issuer",
 &nb=
sp;       "href" : "https://server.example.com"=

 &nb=
sp;     }
 &nb=
sp;   ]
 &nb=
sp; }
&nbs=
p;
If the =
host can't support rewrite rules or scripts the exchange would look =
like:
&nbs=
p;
GET =
/.well-known/host-meta.json
<=
p class=3DMsoNormal>&nbs=
p;
HTTP/1.1 =
200 OK
 &nb=
sp; Access-Control-Allow-Origin: =
*
 &nb=
sp; Content-Type: application/json; =
charset=3DUTF-8
 &nb=
sp; {
 &nb=
sp;   "expires" : =
"2012-03-13T20:56:11Z",
 &nb=
sp;   "links" =
:
 &nb=
sp;   [
 &nb=
sp;     {
 &nb=
sp;       "rel" : =
"lrdd",
 &nb=
sp;       "type" : =
"application/json",
 &nb=
sp;       "template" =
:
 &nb=
sp;     }
&nbs=
p;
GET =
/lrdd/
 &nb=
sp;   ?format=3Djson
 &nb=
sp;   &resource=3Djoe@example.com=

 Hos=
t: example.com
<=
p class=3DMsoNormal>&nbs=
p;
HTTP/1.1 =
200 OK
&nbs=
p;
 &nb=
sp; Access-Control-Allow-Origin: =
*
 &nb=
sp; Content-Type: application/json; =
charset=3DUTF-8
&nbs=
p;
 &nb=
sp; {
 &nb=
sp;   "subject" : "joe@example.com",
 &nb=
sp;   "links" =
:
 &nb=
sp;   [
 &nb=
sp;     {
 &nb=
sp;       "rel" : "http://openid.net/specs/c=
onnect/issuer",
 &nb=
sp;       "href" : "https://server.example.com"=

 &nb=
sp;     },
 &nb=
sp;     {
 &nb=
sp;       "rel" : "http://webfinger.net/rel/avatar<=
/a>",
&nbs=
p;
&nbs=
p;
&nbs=
p;
&nbs=
p;
&nbs=
p;
That =
simple addition may solve a number of problems for =
openID.
&nbs=
p;
John =
B.
 
 
 

------=_NextPart_000_0426_01CD2282.4C6DCE90--


From alexey.melnikov@isode.com  Wed Apr 25 05:32: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 23A5021F86DC; Wed, 25 Apr 2012 05:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX4XDwutvHZc; Wed, 25 Apr 2012 05:32:09 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9800821F86DA; Wed, 25 Apr 2012 05:32:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335357126; d=isode.com; s=selector; i=@isode.com; bh=r5dwvu8Hvqu9B8XUPUuH0EYoLCL8fkN4+YUDgiYP48w=; 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=TLYDaBZuiM1Tm7vVKNtnvPUOmx5/tyj8Q3220WgsP68LPIijjQjAb1U7u666HcO3GHjmT4 imq7zmSUWecnn/iafuAGBJyNGElyM7fEPdXs1MBNO4jmCVoAjOhV7Ux78ydKxpCEdBJTrE uancbd9IHMi/iMSqB7MPfBk9yHdRfk4=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Wed, 25 Apr 2012 13:32:06 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4F97EED6.5010201@isode.com>
Date: Wed, 25 Apr 2012 13:32:22 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: Claudio Allocchio 
References:  <4F8F1733.1040407@isode.com> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] APPSDIR review of draft-melnikov-smtp-priority-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Apr 2012 12:32:10 -0000

On 22/04/2012 16:43, Claudio Allocchio wrote:
> Hello Alexey,
Hi Claudio,
> On Wed, 18 Apr 2012, Alexey Melnikov wrote:
>> Hi Claudio,
>> Thank you for the review and sorry for the delayed response: I've 
>> started writing some replies, but I only now got around to updating 
>> my copy of the document.
>
> no problem, we are all quite busy!
>
> See inline.
Likewise (I've removed part of the exchange where we agree.)
>>
>> On 28/03/2012 17:12, Claudio Allocchio wrote:
>
>>> Summary:
>>>
>>> In its declared scope, this document provides a mechamism (and 
>>> implementation suggestions) in order to enble a "real" priority 
>>> delivery service into the global e-mail handling scenario.
>>>
>>> However, it also introduces a concept idea on how to "tunnel" new 
>>> SMTP parameters requests via MTAs which do not support and ignore 
>>> them, embedding them into e-mail Heders fields. In doing this it 
>>> breaks the ideal separation between Envelope (SMTP) and Content 
>>> (Headers and bodyparts) in a different a new way than it was done 
>>> before, because is causes Headers to be able to modify Envelope 
>>> parameters. There is no negative consideration in this, but this 
>>> feature should also be stated more explicitly in the introduction.
>> Right. Based on IETF LC feedback and after talking to Apps AD the 
>> plan is to split the document into 2: one will describe a pure SMTP 
>> extension (with no tunneling) and will be targeted at Proposed 
>> Standard. Another one will be an Experimental document that talks 
>> about tunneling and gatewaying. So I will have more explicit text 
>> about this in the latter document.
> Very good solution!
>>> In general the document is well specified, and no major technical 
>>> issues are present. However I suggest yet another turn of 
>>> consideraion for the state iself of the specification: the WG and 
>>> many others propose to go into Standards Track, but in order to do 
>>> this there are at least some more exlicit considerations to clarify 
>>> into the text itself. Also, it is not easy to guess what will be the 
>>> adoption level of this mechanism,
>> That is true.
>>> and the risk introduced by possible inaccurate implementations shall 
>>> also be evaluated before going Proposed Standard.
>> Can you be more specific here?
>>
>> A MTA implementation which accepts the PRIORITY parameter and ignores 
>> it is not particularly harmful. An implementation that treats higher 
>> priority messages as lower priority messages is, well, broken. So I 
>> am not entirely sure what are you thinking about here.
>
> I was considering not specifically the "PRIORITY" case, but in general 
> the idea of the parameters tunneling which is introduced. Of course a 
> mismatched PRIORITY request is not harmful, but if another more 
> essential parameter is tunnelled and lost in transactions (imagine a 
> DSN reuqest for example, if somebody decides to use the mechanism to 
> bypass non DSN conformat e-mail systems...) then it can be harmful. 
> Thus I was considering a possible future scenario, and that's why I 
> was sggesting Experimental for the tunnelling mechanism. As you will 
> split documents, my suggestion is fully accomplished :-)
Great :-).
>>> Major Issues:
>>>
>>> The first major issue is non-technical. The e-mail service via SMTP 
>>> (and gateways and other related transport protocols) is best-effort, 
>>> often first-in/first-out based. And by itself, e-mail is a non 
>>> real-time service,
>> In practice I might disagree with you on that, although I see your 
>> point.
>
> I kno people tend to consider e-mail as a real time way to get 
> information to somebody... I do it myself... but, theoretically, we 
> cannot complain if somebody reads the information one week later :-)
True. A delivery of an IM message doesn't mean that either, but I 
digress ;-).
>>> This apparently contradictory point shall be explained better. If 
>>> this specification is going Proposed Standard, it shall be crystal 
>>> clear about these scenarios, because implementers who did not take 
>>> part in the original discussion will implement it, and thus all 
>>> pre-assupmtions made during the discussion process of the 
>>> specification discussion will not be available for them.
>>>
>>> Minor Issues:
>>>
>>> There is no discussion (explicit) about how this specification 
>>> interacts/interferes with anti-spam techniques like graylisting / 
>>> whitelisting. Section 5.1 suggests that shorter retry times shall be 
>>> used for higher priority messages, but it does not mention at all 
>>> graylisting, for example. This should be explicitly mentioned, and 
>>> some guidance / suggestion given, to ensure a coherent behaviour.
>> As this extension requires some form of trust relationship and 
>> authentication (whether using SMTP AUTH, TLS, IP address whitelist, 
>> etc.), then greylisting should be disabled. But if you think this 
>> should be explicitly mentioned, I can mention it.
>
> Just expand you sentence above in the document, and that's perfect.
Done.
>>> Section 4.2: why allowing an X-something like X-Priority to be used?
>> Because it is widely used (due to Exchange and some MUAs).
>
> I see the point.
>
>>> I understand why not "Importance" and why yes "Priority"... but...
>>> Maybe this specification should "update" or even attempt to Obsolete 
>>> partially RFC2156?
>> I don't think it would be a good idea to touch RFC 2156. What do you 
>> think is broken in it anyway?
>
> Nothing broken technically. It might just lead some confusion... in 
> implementers. But it's a minor point, you can ignore my comment and 
> that's fine anyhow.
Ok.
>>> Section 4.5: the text say that in case of mailing lists and aliases 
>>> the Header parameters tunnelling this specification extension SHOULD 
>>> retain the original priority. What about the many implementations 
>>> where headers are completely re-written and many parameters just 
>>> disappear? Some sentence should be given about this case, too.
>> Can you suggest some specific case? SHOULD is here is exactly to 
>> address this kind of case, but I have hard time explaining why it can 
>> be violated in general terms.
>
> The SHOULD makes existing ML implementaions compliant :-)
>
> Just add that "in some cases, a ML service might result is dropping 
> the tunnelling parameter".
I will see where I can add this to the second (Experimental) document.
>>>
>>> Section 9: given the current architecture, I'm very worried this 
>>> will ALWAYS happen (different behaviours because different support 
>>> at various MX-pointed servers). I'd make the consideration more 
>>> explicit and suggest a stronger guidance.
>> Can you suggest an improved text? I've changed "advised" to "strongly 
>> advised", but have troubles improving this text.
>
> true, not easy... something like:
>
>    If multiple DNS MX records are used to specify multiple servers for a
>    domain in section 5 of [RFC5321], it is strongly advised that all of
>    them support the MT-PRIORITY extension and handles priorities is
>    exactly then same way. If one or more server does behave like that,
>    (or even when you cannot fully control the servers behaviour or
>    configuration), then it is strongly suggested that none of the servers
>    support the MT-PRIORITY extension.
>    Otherwise, unexpected differences in message delivery speed or even
>    rejections can happen during temporary or permanent failures, which
>    users might perceive as serious reliability issues.
>
> this makes the comment stronger... maybe to strong... it's up tp you 
> to accept or ignore this stronger version. But also your minimal 
> "strongly advised" in the original text is already enough.
I've used a variant of your text (I've dropped text in (), as I am not 
sure what it is trying to convey and fixed obvious typos).

From barryleiba@gmail.com  Wed Apr 25 05:41: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 7578621F8712 for ; Wed, 25 Apr 2012 05:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWTeftFdW1nD for ; Wed, 25 Apr 2012 05:41:28 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62AE621F86A0 for ; Wed, 25 Apr 2012 05:41:21 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so24507qcs.31 for ; Wed, 25 Apr 2012 05:41:21 -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=ACfvAesSkQHO8IrNqemubtLVeIjFDb2R4EsRZ0uusC0=; b=Oy1lH2Q76APB8ZjtSgkifafo/OELwRvVX/0va014W6n9sRWds5hh7kKr8WIPpCf4Rx wCvJb9pmEzC7qVsVmoatLC986NPo7/oorG41z7+SYv7XQ7L6FLhdP48V2GKdqaXQpFn+ +Pd9Mxy/bowyngmZS6BtV1ovTgeWnKKvfAJiVE6WfZEHuURxFEkBaryK4qT4gZZxqDLH pVQwz27ysydrKA4/wzuMMPuFrwEb+b9ze3fY0w3NrldG9iHI1Di8+xEDvC0AaShKk5qe Nkmq0u+OlTsuSy//kOIZFvy7k5uaI/2ZcAsxfqBZRpY2DD76n3Vysrbtif+eAJ6atgH/ DVyw==
MIME-Version: 1.0
Received: by 10.224.184.70 with SMTP id cj6mr1801234qab.77.1335357680929; Wed, 25 Apr 2012 05:41:20 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.229.220.19 with HTTP; Wed, 25 Apr 2012 05:41:20 -0700 (PDT)
Date: Wed, 25 Apr 2012 08:41:20 -0400
X-Google-Sender-Auth: oXiN9bAHxkAn82ynhtKk3B9AZwc
Message-ID: 
From: Barry Leiba 
To: Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] Citations for terms from RFC 5598 (Internet Mail Architecture)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 12:41:28 -0000

RFC 5598, "Internet Mail Architecture", is a handy document -- an
Informational doc that's on the approved-downref list, and which
contains explanations for many terms that we use in talking about
email infrastructure, along with a clear picture of how the pieces all
fit together.

It frequently comes up in document reviews, both from
directorates/review teams and from the IESG, that people wish we'd
expanded the terms taken from RFC 5598 on first use.  We freely use
terms such as "MTA", "MSA", "MUA", "ADMD", and so on, and readers
aren't always sure whether *that* term comes from 5598 or not.
Further, someone with a basic idea of how things work might not have
to look to 5598 to understand "Message Submission Agent" or
"Administrative Management Domain", but is likely not to get the
abbreviations without heading to the reference.

I think it's reasonable for us to establish a convention for citing
from RFC 5598 that goes something like this:

1. Put a reference in the terminology section that says that a number
of terms in this document come from RFC 5598.  Something like this
works:

   1.1 Terminology

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in RFC 2119 [RFC2119].

      A number of terms used in this document are explained in "Internet Mail
      Architecture" [RFC5598], and an understanding of the concepts in RFC 5598
      is important for readers of this document.

2. On first use of any particular term, spell it out, abbreviate it,
and cite it.  Do this for *every* term we get out of 5598.  So on
first use of MTA we say, "when a Message Transfer Agent (MTA)
[RFC5598] receives a connection...".  If we also use "MSA", we *also*
say, on first use, "when connecting to a Message Submission Agent
(MSA) [RFC5598], it is important to...".  And then, "if the recipient
is in the same Administrative Management Domain (ADMD) [RFC5598],
then...".  And so on, for all the terms.

This may mean that we have a lot of citations to 5598, one for each
term we use out of there, but I think it will make it easier for
people to read and understand the email-related documents.

Comments?

Barry

From ve7jtb@ve7jtb.com  Wed Apr 25 06:16: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 5231E21F874C for ; Wed, 25 Apr 2012 06:16:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.477
X-Spam-Level: 
X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS6l2YWpochE for ; Wed, 25 Apr 2012 06:16:50 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6FE21F86FA for ; Wed, 25 Apr 2012 06:16:50 -0700 (PDT)
Received: by yenm5 with SMTP id m5so68704yen.31 for ; Wed, 25 Apr 2012 06:16:50 -0700 (PDT)
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=Kshv6caMe4gMJbcKiRDd0LmmCGXanbU5WutSTzuRXgw=; b=G7P45sSn+cnVD3ZCoVIcy9DedK6OBhf6RQXQQA5PP/bT6sMYr7iELympS91uYFARRG LrVjvQi6rV+dsqtVzH+rN4aJgOYkreTpepZH22xvLpEqswSB5aNoEbwY0pFcQKOlKZxv A2E/YfL7xrcI3Aq7MrqU8tv5a+pxseQXkJTtoCy3wDT8tAjXYO2UPHeJrjbH8at5R/1l Xd70tttyiOGCW7Z4aUeIwFPy47jXo+khjYoMDal9yh9K7+heRG1ixGZOjXEgxmu/o38q 6pgTMSlH0V0iuWYY3gex5qTlFWtq3zMjp0XICD5CpAk51FRPIhgJPcziGuov0WOvhXVX pVlg==
Received: by 10.236.147.19 with SMTP id s19mr2485831yhj.36.1335359809865; Wed, 25 Apr 2012 06:16:49 -0700 (PDT)
Received: from [192.168.1.213] (190-20-63-108.baf.movistar.cl. [190.20.63.108]) by mx.google.com with ESMTPS id 22sm101949217yhs.6.2012.04.25.06.16.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 06:16:44 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_1319A2E8-F0C0-4131-8139-3B017415423D"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <042501cd22a3$d37d24a0$7a776de0$@packetizer.com>
Date: Wed, 25 Apr 2012 10:16:33 -0300
Message-Id: <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com>
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com>
To: "Paul E. Jones" 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQmFc5aTyJXyURP/ta+7jNrMEqSwR9M3dx78x8MQDSZJiy9nEqgrKzFynT4ANagqBzjgkT9z
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 13:16:52 -0000

--Apple-Mail=_1319A2E8-F0C0-4131-8139-3B017415423D
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_296444B6-EE7C-44E0-B2F9-F630B14EEB40"


--Apple-Mail=_296444B6-EE7C-44E0-B2F9-F630B14EEB40
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Paul,=20

"rel" as a filter is something WF has for host-meta.  It however doesn't =
seem to have that for user JRD in the case where host-meta is returned, =
and the template is used.

The "resource" and "rel" parameters are already an optimization for LRDD =
and not part of host-meta.
Adding LRDD specific parameters to host-meta/host-meta.json will =
probably raise some eyebrows in review, but I am OK with it.

I think there are use cases where size matters.  Where a host-meta or =
resource JRD may be large and it is more efficient not to send the whole =
thing to a mobile client.
It seems to be one of Mike Jones requirements.

Using RFC6570 for LRDD is a possibility for passing through the filter =
request for sites that support filtering on resource JRD.

What other proposals do you have.  I am guessing that filtering on =
resource JRD is not a totally new topic.

LRDD is the one really doing the optimization  in any event,  it may be =
done at the host-meta GET but it is a LRDD specific extension.
Having it in the template allows LRDD to filter at the resource JRD in =
cases where it is not possible to do it at the host-meta level, due to =
some no script or other restriction.

I agree that it should be filtered at the how-meta request but you and =
others say that is not always possible.

John B.




On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:

> John,
> =20
> The =93rel=94 parameter is something we still need to discuss, so not =
is as good a time as any.
> =20
> What =93rel=94 does is act as a filter.  For the most part, the only =
purpose it serves is to help reduce the number of link relations that =
might be sent from the server.  So, if a user had 1,000 different link =
relations, this might reduce the returned message to containing only 1.  =
However, if a user has more than one link relation of the same type, all =
of them would match and be returned.
> =20
> When you say the host cannot support re-write rules, I assume you mean =
it does not support the URI parameters on host-meta?  In that case, yes, =
the parameters are ignored and you get just the host-meta document.
> =20
> The only URI template defined in RFC 6415 is =93{uri}=94 (see =
3.1.1.1).  There are no other URI template values defined.  (Note: this =
whole section exists only because RFC  6570 did not yet exist, I think.
> =20
> In any case, we could define a new URI template, but then we would be =
putting an optimization in place for LRDD.  If host-meta is not going to =
support the =93rel=94 URI parameter, why would LRDD?  It would also mean =
that the LRDD logic would have to be ready to receive a URI parameter =
that is not replaced, since some clients would only change {uri} and =
leave {rel} there.  That would introduce more conditional logic in the =
server.  This would also present issues with static sites.  (Of course, =
one might be able to use Apache re-writing rules to get around that =
problem, but it certainly would not work for =93real=94 static sites.)
> =20
> Personally,  I=92d prefer to not add the =93rel=94 parameter to LRDD, =
since I think optimization using =93rel=94 would always be done on =
host-meta.  That said, I question the value of =93rel=94 entirely.  Do =
you think it=92s useful to have this filter at all?  Is there really a =
risk that a site might return 1,000 link relations that the client would =
have to step over?
> =20
> Paul
> =20
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Tuesday, April 24, 2012 10:17 PM
> To: Paul E. Jones
> Cc: apps-discuss@ietf.org
> Subject: WF flow with rel parameter
> =20
> Paul,
> =20
> Sorry I hit send on the previous message with a typo.
> =20
> I am looking at how the flows in WF might work for openID.
> =20
> Let's set aside the XML issue for the moment and focus on the JSON =
flow.
> =20
> Please correct anything I get wrong.
> =20
> The openID Connect defines a relation of =
http://openid.net/specs/connect/issuer
> =20
> WF allows for a JSON host-meta that takes two parameters, "resource" =
and "rel"
> =20
> An example request and response (line-brakes for readability)
> =20
> GET /.well-known/host-meta.json
>      ?resource=3Djoe@example.com
>      &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
>  Host: example.com
> =20
>    HTTP/1.1 200 OK
> =20
>    Access-Control-Allow-Origin: *
>    Content-Type: application/json; charset=3DUTF-8
> =20
>    {
>      "subject" : "joe@example.com",
>      "links" :
>      [
>        {
>          "rel" : "http://openid.net/specs/connect/issuer",
>          "href" : "https://server.example.com"
>        }
>      ]
>    }
> =20
> If the host can't support rewrite rules or scripts the exchange would =
look like:
> =20
> GET /.well-known/host-meta.json
>      ?resource=3Djoe@example.com
>      &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
>  Host: example.com
> =20
> HTTP/1.1 200 OK
>    Access-Control-Allow-Origin: *
>    Content-Type: application/json; charset=3DUTF-8
>    {
>      "expires" : "2012-03-13T20:56:11Z",
>      "links" :
>      [
>        {
>          "rel" : "lrdd",
>          "type" : "application/json",
>          "template" :
>            "https://example.com/lrdd/?format=3Djson&resource=3D{uri}"
>        }
> =20
> GET /lrdd/
>      ?format=3Djson
>      &resource=3Djoe@example.com
>  Host: example.com
> =20
> HTTP/1.1 200 OK
> =20
>    Access-Control-Allow-Origin: *
>    Content-Type: application/json; charset=3DUTF-8
> =20
>    {
>      "subject" : "joe@example.com",
>      "links" :
>      [
>        {
>          "rel" : "http://openid.net/specs/connect/issuer",
>          "href" : "https://server.example.com"
>        },
>        {
>          "rel" : "http://webfinger.net/rel/avatar",
>          "href" : "http://example.com/~joe/joe.jpg"
>        }
> =20
>      ]
>    }
> =20
> I can't find a template parameter for "rel".  The host-meta spec =
allows for extension but it is missing.
> =20
> What if the server wants to support filtering on rel but can't support =
it in the root for some reason?
> =20
> Is it possible to have a template like:
> "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}"
> =20
> That simple addition may solve a number of problems for openID.
> =20
> John B.
> =20
> =20
> =20


--Apple-Mail=_296444B6-EE7C-44E0-B2F9-F630B14EEB40
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Paul, 

"rel" as a filter is =
something WF has for host-meta.  It however doesn't seem to have =
that for user JRD in the case where host-meta is returned, and the =
template is used.

The "resource" and "rel" =
parameters are already an optimization for LRDD and not part of =
host-meta.
Adding LRDD specific parameters to =
host-meta/host-meta.json will probably raise some eyebrows in review, =
but I am OK with it.

I think there are use =
cases where size matters.  Where a host-meta or resource JRD may be =
large and it is more efficient not to send the whole thing to a mobile =
client.
It seems to be one of Mike Jones =
requirements.

Using RFC6570 for LRDD is a =
possibility for passing through the filter request for sites that =
support filtering on resource JRD.

What other =
proposals do you have.  I am guessing that filtering on resource =
JRD is not a totally new topic.

LRDD is the one =
really doing the optimization  in any event,  it may be done =
at the host-meta GET but it is a LRDD specific =
extension.
Having it in the template allows LRDD to filter at =
the resource JRD in cases where it is not possible to do it at the =
host-meta level, due to some no script or other =
restriction.

I agree that it should be filtered =
at the how-meta request but you and others say that is not always =
possible.

John =
B.




On=
 2012-04-25, at 2:25 AM, Paul E. Jones wrote:

The =
=93rel=94 parameter is something we still need to discuss, so not is as =
good a time as any.
 
What =93rel=94 does is act as a =
filter.  For the most part, the only purpose it serves is to help =
reduce the number of link relations that might be sent from the =
server.  So, if a user had 1,000 different link relations, this =
might reduce the returned message to containing only 1.  However, =
if a user has more than one link relation of the same type, all of them =
would match and be returned.
When =
you say the host cannot support re-write rules, I assume you mean it =
does not support the URI parameters on host-meta?  In that case, =
yes, the parameters are ignored and you get just the host-meta =
document.
The =
only URI template defined in RFC 6415 is =93{uri}=94 (see =
3.1.1.1).  There are no other URI template values defined.  =
(Note: this whole section exists only because RFC  6570 did not yet =
exist, I think.
In =
any case, we could define a new URI template, but then we would be =
putting an optimization in place for LRDD.  If host-meta is not =
going to support the =93rel=94 URI parameter, why would LRDD?  It =
would also mean that the LRDD logic would have to be ready to receive a =
URI parameter that is not replaced, since some clients would only change =
{uri} and leave {rel} there.  That would introduce more conditional =
logic in the server.  This would also present issues with static =
sites.  (Of course, one might be able to use Apache re-writing =
rules to get around that problem, but it certainly would not work for =
=93real=94 static sites.)
 
Personally,  I=92d prefer =
to not add the =93rel=94 parameter =
to LRDD, since I think optimization using =93rel=94 would always be done =
on host-meta.  That said, I question the value of =93rel=94 =
entirely.  Do you think it=92s useful to have this filter at =
all?  Is there really a risk that a site might return 1,000 link =
relations that the client would have to step =
over?
 John =
Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, April 24, 2012 =
10:17 PM
To: Paul E. =
Jones
Cc:  WF flow with rel =
parameter
     "links" =
:
 
If the host can't support rewrite rules or =
scripts the exchange would look like:
 
GET =
/.well-known/host-meta.json
      example.com
 
HTTP/1.1 200 =
OK
     "expires" : =
"2012-03-13T20:56:11Z",
     "links" =
:
 
GET =
/lrdd/
 
HTTP/1.1 200 =
OK
     "subject" : "joe@example.com",
     "links" =
:
=

<=
div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "> 
 
I can't find a template parameter for "rel". =
 The host-meta spec allows for extension but it is =
missing.
What if the server wants =
to support filtering on rel but can't support it in the root for some =
reason?
Is it possible to have a =
template like:
"

Thread-Topic: [apps-discuss] WF flow with rel parameter
Thread-Index: AQHNIomKaCym1aAtdUm4KjKnInrNO5ard+qAgACDoID//6IRMA==
Date: Wed, 25 Apr 2012 14:41:11 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201007020@P3PWEX2MB008.ex2.secureserver.net>
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com>
In-Reply-To: <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA201007020P3PWEX2MB008ex2_"
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 14:41:18 -0000

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA201007020P3PWEX2MB008ex2_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Purely from a practical standpoint, do you think it is likely that a server=
 will support the query filter for the lrdd documents but not for host-meta=
?

EH

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of John Bradley
Sent: Wednesday, April 25, 2012 6:17 AM
To: Paul E. Jones
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WF flow with rel parameter

Paul,

"rel" as a filter is something WF has for host-meta.  It however doesn't se=
em to have that for user JRD in the case where host-meta is returned, and t=
he template is used.

The "resource" and "rel" parameters are already an optimization for LRDD an=
d not part of host-meta.
Adding LRDD specific parameters to host-meta/host-meta.json will probably r=
aise some eyebrows in review, but I am OK with it.

I think there are use cases where size matters.  Where a host-meta or resou=
rce JRD may be large and it is more efficient not to send the whole thing t=
o a mobile client.
It seems to be one of Mike Jones requirements.

Using RFC6570 for LRDD is a possibility for passing through the filter requ=
est for sites that support filtering on resource JRD.

What other proposals do you have.  I am guessing that filtering on resource=
 JRD is not a totally new topic.

LRDD is the one really doing the optimization  in any event,  it may be don=
e at the host-meta GET but it is a LRDD specific extension.
Having it in the template allows LRDD to filter at the resource JRD in case=
s where it is not possible to do it at the host-meta level, due to some no =
script or other restriction.

I agree that it should be filtered at the how-meta request but you and othe=
rs say that is not always possible.

John B.




On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:


John,

The "rel" parameter is something we still need to discuss, so not is as goo=
d a time as any.

What "rel" does is act as a filter.  For the most part, the only purpose it=
 serves is to help reduce the number of link relations that might be sent f=
rom the server.  So, if a user had 1,000 different link relations, this mig=
ht reduce the returned message to containing only 1.  However, if a user ha=
s more than one link relation of the same type, all of them would match and=
 be returned.

When you say the host cannot support re-write rules, I assume you mean it d=
oes not support the URI parameters on host-meta?  In that case, yes, the pa=
rameters are ignored and you get just the host-meta document.

The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1).  There =
are no other URI template values defined.  (Note: this whole section exists=
 only because RFC  6570 did not yet exist, I think.

In any case, we could define a new URI template, but then we would be putti=
ng an optimization in place for LRDD.  If host-meta is not going to support=
 the "rel" URI parameter, why would LRDD?  It would also mean that the LRDD=
 logic would have to be ready to receive a URI parameter that is not replac=
ed, since some clients would only change {uri} and leave {rel} there.  That=
 would introduce more conditional logic in the server.  This would also pre=
sent issues with static sites.  (Of course, one might be able to use Apache=
 re-writing rules to get around that problem, but it certainly would not wo=
rk for "real" static sites.)

Personally,  I'd prefer to not add the "rel" parameter to LRDD, since I thi=
nk optimization using "rel" would always be done on host-meta.  That said, =
I question the value of "rel" entirely.  Do you think it's useful to have t=
his filter at all?  Is there really a risk that a site might return 1,000 l=
ink relations that the client would have to step over?

Paul

From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Tuesday, April 24, 2012 10:17 PM
To: Paul E. Jones
Cc: apps-discuss@ietf.org
Subject: WF flow with rel parameter

Paul,

Sorry I hit send on the previous message with a typo.

I am looking at how the flows in WF might work for openID.

Let's set aside the XML issue for the moment and focus on the JSON flow.

Please correct anything I get wrong.

The openID Connect defines a relation of http://openid.net/specs/connect/is=
suer

WF allows for a JSON host-meta that takes two parameters, "resource" and "r=
el"

An example request and response (line-brakes for readability)

GET /.well-known/host-meta.json
     ?resource=3Djoe@example.com
     &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1=
.1
 Host: example.com

   HTTP/1.1 200 OK

   Access-Control-Allow-Origin: *
   Content-Type: application/json; charset=3DUTF-8

   {
     "subject" : "joe@example.com",
     "links" :
     [
       {
         "rel" : "http://openid.net/specs/connect/issuer",
         "href" : "https://server.example.com"
       }
     ]
   }

If the host can't support rewrite rules or scripts the exchange would look =
like:

GET /.well-known/host-meta.json
     ?resource=3Djoe@example.com
     &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1=
.1
 Host: example.com

HTTP/1.1 200 OK
   Access-Control-Allow-Origin: *
   Content-Type: application/json; charset=3DUTF-8
   {
     "expires" : "2012-03-13T20:56:11Z",
     "links" :
     [
       {
         "rel" : "lrdd",
         "type" : "application/json",
         "template" :
           "https://example.com/lrdd/?format=3Djson&resource=3D{uri}"
       }

GET /lrdd/
     ?format=3Djson
     &resource=3Djoe@example.com
 Host: example.com

HTTP/1.1 200 OK

   Access-Control-Allow-Origin: *
   Content-Type: application/json; charset=3DUTF-8

   {
     "subject" : "joe@example.com",
     "links" :
     [
       {
         "rel" : "http://openid.net/specs/connect/issuer",
         "href" : "https://server.example.com"
       },
       {
         "rel" : "http://webfinger.net/rel/avatar",
         "href" : "http://example.com/~joe/joe.jpg"
       }

     ]
   }

I can't find a template parameter for "rel".  The host-meta spec allows for=
 extension but it is missing.

What if the server wants to support filtering on rel but can't support it i=
n the root for some reason?

Is it possible to have a template like:
"https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}"

That simple addition may solve a number of problems for openID.

John B.





--_000_0CBAEB56DDB3A140BA8E8C124C04ECA201007020P3PWEX2MB008ex2_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Purely from a practical s=
tandpoint, do you think it is likely that a server will support the query f=
ilter for the lrdd documents but not for host-meta?


 <=
/p>

EH


 <=
/p>







From: apps-dis=
cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of John Bradley

Sent: Wednesday, April 25, 2012 6:17 AM

To: Paul E. Jones

Cc: apps-discuss@ietf.org

Subject: Re: [apps-discuss] WF flow with rel parameter






 


Paul, 




 






"rel" as a filter is something WF has for =
host-meta.  It however doesn't seem to have that for user JRD in the c=
ase where host-meta is returned, and the template is used.






 






The "resource" and "rel" paramet=
ers are already an optimization for LRDD and not part of host-meta.






Adding LRDD specific parameters to host-meta/host-me=
ta.json will probably raise some eyebrows in review, but I am OK with it.






 






I think there are use cases where size matters. &nbs=
p;Where a host-meta or resource JRD may be large and it is more efficient n=
ot to send the whole thing to a mobile client.






It seems to be one of Mike Jones requirements.<=
/o:p>






 






Using RFC6570 for LRDD is a possibility for passing =
through the filter request for sites that support filtering on resource JRD=
.






 






What other proposals do you have.  I am guessin=
g that filtering on resource JRD is not a totally new topic.






 






LRDD is the one really doing the optimization  =
in any event,  it may be done at the host-meta GET but it is a LRDD sp=
ecific extension.






Having it in the template allows LRDD to filter at t=
he resource JRD in cases where it is not possible to do it at the host-meta=
 level, due to some no script or other restriction.






 






I agree that it should be filtered at the how-meta r=
equest but you and others say that is not always possible.






 






John B.






 






 






 






 






On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:=
















John,





 <=
/p>





The “rel” par=
ameter is something we still need to discuss, so not is as good a time as a=
ny.






 <=
/p>





What “rel” do=
es is act as a filter.  For the most part, the only purpose it serves =
is to help reduce the number of link relations that might be sent from the
 server.  So, if a user had 1,000 different link relations, this might=
 reduce the returned message to containing only 1.  However, if a user=
 has more than one link relation of the same type, all of them would match =
and be returned.






 <=
/p>





When you say the host can=
not support re-write rules, I assume you mean it does not support the URI p=
arameters on host-meta?  In that case, yes, the parameters
 are ignored and you get just the host-meta document.






 <=
/p>





The only URI template def=
ined in RFC 6415 is “{uri}” (see 3.1.1.1).  There are no o=
ther URI template values defined.  (Note: this whole section exists on=
ly
 because RFC  6570 did not yet exist, I think.






 <=
/p>





In any case, we could def=
ine a new URI template, but then we would be putting an optimization in pla=
ce for LRDD.  If host-meta is not going to support the “rel̶=
1;
 URI parameter, why would LRDD?  It would also mean that the LRDD logi=
c would have to be ready to receive a URI parameter that is not replaced, s=
ince some clients would only change {uri} and leave {rel} there.  That=
 would introduce more conditional logic in
 the server.  This would also present issues with static sites.  =
(Of course, one might be able to use Apache re-writing rules to get around =
that problem, but it certainly would not work for “real” static=
 sites.)






 <=
/p>





Personally,  I’=
;d prefer to not add the “rel” =
parameter to LRDD,
 since I think optimization using “rel” would always be done on=
 host-meta.  That said, I question the value of “rel” enti=
rely.  Do you think it’s useful to have this filter at all? =
; Is there really a risk that a site might return 1,000 link relations that=
 the
 client would have to step over?






 <=
/p>





Paul





 <=
/p>








 










Paul,
















 










Sorry I hit send on the previous message with a typo=
.










 








I am looking at how the flows in WF might work for o=
penID.










 










Let's set aside the XML issue for the moment and foc=
us on the JSON flow.












 








Please correct anything I get wrong.<=
/span>








 








The openID Connect defines a relation=
 of http://openid.net/specs/connect/issuer








 








WF allows for a JSON host-meta that t=
akes two parameters, "resource" and "rel"








 








An example request and response (line=
-brakes for readability)








 








GET /.well-known/host-meta.json











     &re=
l=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1










 Host: example.com








 








   HTTP/1.1 200 OK








 








   Access-Control-Allo=
w-Origin: *










   Content-Type: appli=
cation/json; charset=3DUTF-8








 








   {=











     "s=
ubject" : "joe@example.com=
",










     "l=
inks" :










     [










      &=
nbsp;{










      &=
nbsp;  "rel" : "http://openid.net/specs/connect/issuer",










      &=
nbsp;  "href" : "https://server.example.com"










      &=
nbsp;}










     ]










   }=









 








If the host can't support rewrite rul=
es or scripts the exchange would look like:








 








GET /.well-known/host-meta.json











     &re=
l=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1










 Host: example.com








 








HTTP/1.1 200 OK










   Access-Control-Allo=
w-Origin: *










   Content-Type: appli=
cation/json; charset=3DUTF-8










   {=











     "e=
xpires" : "2012-03-13T20:56:11Z",










     "l=
inks" :










     [










      &=
nbsp;{










      &=
nbsp;  "rel" : "lrdd",










      &=
nbsp;  "type" : "application/json",










      &=
nbsp;  "template" :











      &=
nbsp;}








 








GET /lrdd/










     ?format=
=3Djson










     &resource=3Djoe@example.com<=
/span>










 Host: example.com








 








HTTP/1.1 200 OK








 








   Access-Control-Allo=
w-Origin: *










   Content-Type: appli=
cation/json; charset=3DUTF-8








 








   {=











     "s=
ubject" : "joe@example.com=
",










     "l=
inks" :










     [










      &=
nbsp;{










      &=
nbsp;  "rel" : "http://openid.net/specs/connect/issuer",










      &=
nbsp;  "href" : "https://server.example.com"










      &=
nbsp;},










      &=
nbsp;{










      &=
nbsp;  "rel" : "http://webfinger.net/rel/avatar",










      &=
nbsp;  "href" : "http://example.com/~joe/joe.jpg"










      &=
nbsp;}








 








     ]










   }=









 








I can't find a template parameter for=
 "rel".  The host-meta spec allows for extension but it is m=
issing.








 








What if the server wants to support f=
iltering on rel but can't support it in the root for some reason?








 








Is it possible to have a template lik=
e:









 








That simple addition may solve a numb=
er of problems for openID.








 








John B.














 










 










 










 










--_000_0CBAEB56DDB3A140BA8E8C124C04ECA201007020P3PWEX2MB008ex2_--

From ve7jtb@ve7jtb.com  Wed Apr 25 07:49: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 6EC3721F86D6 for ; Wed, 25 Apr 2012 07:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.477
X-Spam-Level: 
X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU8zKssU5988 for ; Wed, 25 Apr 2012 07:49:19 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C00521F86D3 for ; Wed, 25 Apr 2012 07:49:18 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so190957ghb.31 for ; Wed, 25 Apr 2012 07:49:18 -0700 (PDT)
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=/aaju9LwtRhkCQHqncXHPdTSqYbdzTWnwFKiidiz/tk=; b=Pw92gC0ZXeQbWoGlw2AQobMSHNxhzkhiPZ+ftvp1XXj37FlQU7qHbY93Kx7Uwbhpc4 eFhqSAOUToj+VeE0M+cYXgsGN223I799OvXZt6fU8+5WjxUp0rVhgYNXMnvi5gHn9ZZX G7ZUAEqVGbDHXoO0QRRYtH0oByWPU2rdEcI6K7tMhAuCcMkoaEIvDPJ6rZ6U5Bn1Yp0Y I7MrnTt8DPRLP26SWrKGxcFOs/TGyLaZ2MsORcx4i72LVhzt4UT9A+yluQEknze9bpVT 9gOVuFQ7QFJHnimUZPyDc3VAlLCee9DilNvp/O25FSpSsOkvSanKp1NxRFmpSS7cZHmr AQng==
Received: by 10.236.184.102 with SMTP id r66mr2754897yhm.46.1335365358166; Wed, 25 Apr 2012 07:49:18 -0700 (PDT)
Received: from [192.168.1.213] (190-20-63-108.baf.movistar.cl. [190.20.63.108]) by mx.google.com with ESMTPS id 34sm14031063anu.6.2012.04.25.07.49.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 07:49:14 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_3A2265F8-B6F6-4D28-BC36-BF24ED134FE3"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <042501cd22a3$d37d24a0$7a776de0$@packetizer.com>
Date: Wed, 25 Apr 2012 11:48:32 -0300
Message-Id: 
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com>
To: Paul E. Jones 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQnuSdZTw1i1OaEXYhi+nbh8ymxnqtsOiO6lnktJKVvOmitozC7GuSjzsAldwaeEVANQhz7u
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 14:49:20 -0000

--Apple-Mail=_3A2265F8-B6F6-4D28-BC36-BF24ED134FE3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Taking a closer look at http://tools.ietf.org/html/rfc6570

The lrdd template can be something like:
https://example.com/lrdd/?format=3Djson{&uri,rel}
or
https://example.com/lrdd/?format=3Djson&resource=3D{uri}{&rel}

So it probably comes down to me asking for WF to conform to rfc6570 for =
LRDD template construction or at least adding the {?} and {&} templates =
from rfc6570.

That way people who want to host JRD's as a service on another host =
don't lose the ability to filter.

John B.

On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:

> John,
> =20
> The =93rel=94 parameter is something we still need to discuss, so not =
is as good a time as any.
> =20
> What =93rel=94 does is act as a filter.  For the most part, the only =
purpose it serves is to help reduce the number of link relations that =
might be sent from the server.  So, if a user had 1,000 different link =
relations, this might reduce the returned message to containing only 1.  =
However, if a user has more than one link relation of the same type, all =
of them would match and be returned.
> =20
> When you say the host cannot support re-write rules, I assume you mean =
it does not support the URI parameters on host-meta?  In that case, yes, =
the parameters are ignored and you get just the host-meta document.
> =20
> The only URI template defined in RFC 6415 is =93{uri}=94 (see =
3.1.1.1).  There are no other URI template values defined.  (Note: this =
whole section exists only because RFC  6570 did not yet exist, I think.
> =20
> In any case, we could define a new URI template, but then we would be =
putting an optimization in place for LRDD.  If host-meta is not going to =
support the =93rel=94 URI parameter, why would LRDD?  It would also mean =
that the LRDD logic would have to be ready to receive a URI parameter =
that is not replaced, since some clients would only change {uri} and =
leave {rel} there.  That would introduce more conditional logic in the =
server.  This would also present issues with static sites.  (Of course, =
one might be able to use Apache re-writing rules to get around that =
problem, but it certainly would not work for =93real=94 static sites.)
> =20
> Personally,  I=92d prefer to not add the =93rel=94 parameter to LRDD, =
since I think optimization using =93rel=94 would always be done on =
host-meta.  That said, I question the value of =93rel=94 entirely.  Do =
you think it=92s useful to have this filter at all?  Is there really a =
risk that a site might return 1,000 link relations that the client would =
have to step over?
> =20
> Paul
> =20
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Tuesday, April 24, 2012 10:17 PM
> To: Paul E. Jones
> Cc: apps-discuss@ietf.org
> Subject: WF flow with rel parameter
> =20
> Paul,
> =20
> Sorry I hit send on the previous message with a typo.
> =20
> I am looking at how the flows in WF might work for openID.
> =20
> Let's set aside the XML issue for the moment and focus on the JSON =
flow.
> =20
> Please correct anything I get wrong.
> =20
> The openID Connect defines a relation of =
http://openid.net/specs/connect/issuer
> =20
> WF allows for a JSON host-meta that takes two parameters, "resource" =
and "rel"
> =20
> An example request and response (line-brakes for readability)
> =20
> GET /.well-known/host-meta.json
>      ?resource=3Djoe@example.com
>      &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
>  Host: example.com
> =20
>    HTTP/1.1 200 OK
> =20
>    Access-Control-Allow-Origin: *
>    Content-Type: application/json; charset=3DUTF-8
> =20
>    {
>      "subject" : "joe@example.com",
>      "links" :
>      [
>        {
>          "rel" : "http://openid.net/specs/connect/issuer",
>          "href" : "https://server.example.com"
>        }
>      ]
>    }
> =20
> If the host can't support rewrite rules or scripts the exchange would =
look like:
> =20
> GET /.well-known/host-meta.json
>      ?resource=3Djoe@example.com
>      &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
>  Host: example.com
> =20
> HTTP/1.1 200 OK
>    Access-Control-Allow-Origin: *
>    Content-Type: application/json; charset=3DUTF-8
>    {
>      "expires" : "2012-03-13T20:56:11Z",
>      "links" :
>      [
>        {
>          "rel" : "lrdd",
>          "type" : "application/json",
>          "template" :
>            "https://example.com/lrdd/?format=3Djson&resource=3D{uri}"
>        }
> =20
> GET /lrdd/
>      ?format=3Djson
>      &resource=3Djoe@example.com
>  Host: example.com
> =20
> HTTP/1.1 200 OK
> =20
>    Access-Control-Allow-Origin: *
>    Content-Type: application/json; charset=3DUTF-8
> =20
>    {
>      "subject" : "joe@example.com",
>      "links" :
>      [
>        {
>          "rel" : "http://openid.net/specs/connect/issuer",
>          "href" : "https://server.example.com"
>        },
>        {
>          "rel" : "http://webfinger.net/rel/avatar",
>          "href" : "http://example.com/~joe/joe.jpg"
>        }
> =20
>      ]
>    }
> =20
> I can't find a template parameter for "rel".  The host-meta spec =
allows for extension but it is missing.
> =20
> What if the server wants to support filtering on rel but can't support =
it in the root for some reason?
> =20
> Is it possible to have a template like:
> "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}"
> =20
> That simple addition may solve a number of problems for openID.
> =20
> John B.
> =20
> =20
> =20


--Apple-Mail=_3A2265F8-B6F6-4D28-BC36-BF24ED134FE3
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
NTE0NDgzMlowIwYJKoZIhvcNAQkEMRYEFHqL193Jn2nWcuCNnHxk7weWAu3yMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AC8PiN8hgafH/+IFzqEjOcxoyGV2V6HuK1vgo/o3juc6/h8kHHOQk8qV+R2iwWOolLkcT0muWUuA
0OgrItySAjTfZTgEoQaqKeJ0Qo5HyIUCzodhtxnqeXTRHIWRP1VTzZm7b2Dq18bvf4AbejzKwDsB
pRY2ZL6oKWjSO4lx5DUaiVKe7lYNUIAp9yiU0cNbxNLiXnaOrn7UDgvURxflY6d6mEoCEZ3Roe2a
2P+GcrBD6cyJ/6D4KuRbkjb9tTe5giKqzlkci+P2c7rXln8RCCXONYcr2eQg2vrdZYl8N10m/Tu/
nZhDcoAzayGdMhcFQqsm44tdT0j6pDf/MExHX80AAAAAAAA=

--Apple-Mail=_3A2265F8-B6F6-4D28-BC36-BF24ED134FE3--

From paulej@packetizer.com  Wed Apr 25 08:01: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 36B3521F869C for ; Wed, 25 Apr 2012 08:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.318
X-Spam-Level: 
X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.146,  BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw2p8mhUzkJ2 for ; Wed, 25 Apr 2012 08:01:33 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF0B21F854A for ; Wed, 25 Apr 2012 08:01:33 -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 q3PF1VKv023770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Apr 2012 11:01:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335366092; bh=JQIr56/5JtDIgssSh/DS/caGL93pAGJsLN8rmCXbwLg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=k0eB7Ac4LlqIEka2vnUsptMzVpqsrroiRKgWK7PA+s61i9EyBCbP7d9H1vGMb1DrK leOA0bE2WpLrVdJAYUGiOHODMsXqA0haNO4mrq20s7cGBr/KWL8yvAftv1CMGdHZCf ELTj3zPt7q/hCoSXCDupsQ65E2xNVS6RzfQHMYAo=
From: "Paul E. Jones" 
To: "'John Bradley'" 
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com>
In-Reply-To: <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com>
Date: Wed, 25 Apr 2012 11:01:37 -0400
Message-ID: <049001cd22f4$5161a210$f424e630$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0491_01CD22D2.CA535D70"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIsWOE+Nj6a2+m+DlaA/0DoJV2C/wIeE8UWAjl8XVEB+oMj25W6mtmA
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 15:01:38 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0491_01CD22D2.CA535D70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

John,

 

I actually did implement my server so that 'rel' is honored whether it's
given to host-meta or LRDD.  The reason is that it's actually the same
program.  It is a logical thing to have there for all the same reasons.

 

However, I am concerned with defining a URI template like '{rel}' that may
not be modified by the client.  So, what might happen is that a query might
be sent by the client that looks like this:

 

GET /lrdd/?resource=acct:bob@example.com&rel={rel}

 

The world would not end, but the server will have to know that the 'rel'
value of '{rel}' means no 'rel' parameter was actually passed.  I find that
a bit odd.

 

Why not just optimize on host-meta instead of LRDD?  I agree that WebFinger
is mostly an LRDD thing, but be mindful that querying host-meta, one gets a
set of link relations and querying LRDD one gets more link relations.  To
have all of the link relations for a specific resource, one must query both
host-meta and LRDD and merge the link relations (in the order received).  If
using the "resource" parameter on host-meta, then this merging of host-meta
resource-specific link relations (i.e., those that are "template" types) are
automatically merged in order with pure resource-specific link relations
returned by LRDD.

 

In any case, I have no strong objections, but we would have to have special
language about handling '{rel}' if the template is not substituted with a
real value.

 

Paul

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, April 25, 2012 9:17 AM
To: Paul E. Jones
Cc: apps-discuss@ietf.org
Subject: Re: WF flow with rel parameter

 

Paul, 

 

"rel" as a filter is something WF has for host-meta.  It however doesn't
seem to have that for user JRD in the case where host-meta is returned, and
the template is used.

 

The "resource" and "rel" parameters are already an optimization for LRDD and
not part of host-meta.

Adding LRDD specific parameters to host-meta/host-meta.json will probably
raise some eyebrows in review, but I am OK with it.

 

I think there are use cases where size matters.  Where a host-meta or
resource JRD may be large and it is more efficient not to send the whole
thing to a mobile client.

It seems to be one of Mike Jones requirements.

 

Using RFC6570 for LRDD is a possibility for passing through the filter
request for sites that support filtering on resource JRD.

 

What other proposals do you have.  I am guessing that filtering on resource
JRD is not a totally new topic.

 

LRDD is the one really doing the optimization  in any event,  it may be done
at the host-meta GET but it is a LRDD specific extension.

Having it in the template allows LRDD to filter at the resource JRD in cases
where it is not possible to do it at the host-meta level, due to some no
script or other restriction.

 

I agree that it should be filtered at the how-meta request but you and
others say that is not always possible.

 

John B.

 

 

 

 

On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:





John,

 

The "rel" parameter is something we still need to discuss, so not is as good
a time as any.

 

What "rel" does is act as a filter.  For the most part, the only purpose it
serves is to help reduce the number of link relations that might be sent
from the server.  So, if a user had 1,000 different link relations, this
might reduce the returned message to containing only 1.  However, if a user
has more than one link relation of the same type, all of them would match
and be returned.

 

When you say the host cannot support re-write rules, I assume you mean it
does not support the URI parameters on host-meta?  In that case, yes, the
parameters are ignored and you get just the host-meta document.

 

The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1).  There
are no other URI template values defined.  (Note: this whole section exists
only because RFC  6570 did not yet exist, I think.

 

In any case, we could define a new URI template, but then we would be
putting an optimization in place for LRDD.  If host-meta is not going to
support the "rel" URI parameter, why would LRDD?  It would also mean that
the LRDD logic would have to be ready to receive a URI parameter that is not
replaced, since some clients would only change {uri} and leave {rel} there.
That would introduce more conditional logic in the server.  This would also
present issues with static sites.  (Of course, one might be able to use
Apache re-writing rules to get around that problem, but it certainly would
not work for "real" static sites.)

 

Personally,  I'd prefer to not add the "rel" parameter to LRDD, since I
think optimization using "rel" would always be done on host-meta.  That
said, I question the value of "rel" entirely.  Do you think it's useful to
have this filter at all?  Is there really a risk that a site might return
1,000 link relations that the client would have to step over?

 

Paul

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Tuesday, April 24, 2012 10:17 PM
To: Paul E. Jones
Cc: apps-discuss@ietf.org
Subject: WF flow with rel parameter

 

Paul,

 

Sorry I hit send on the previous message with a typo.

 

I am looking at how the flows in WF might work for openID.

 

Let's set aside the XML issue for the moment and focus on the JSON flow.

 

Please correct anything I get wrong.

 

The openID Connect defines a relation of
http://openid.net/specs/connect/issuer

 

WF allows for a JSON host-meta that takes two parameters, "resource" and
"rel"

 

An example request and response (line-brakes for readability)

 

GET /.well-known/host-meta.json

     ?resource=joe@example.com

     &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1

 Host: example.com  

 

   HTTP/1.1 200 OK

 

   Access-Control-Allow-Origin: *

   Content-Type: application/json; charset=UTF-8

 

   {

     "subject" : "joe@example.com",

     "links" :

     [

       {

         "rel" : "http://openid.net/specs/connect/issuer",

         "href" : "https://server.example.com 
"

       }

     ]

   }

 

If the host can't support rewrite rules or scripts the exchange would look
like:

 

GET /.well-known/host-meta.json

     ?resource=joe@example.com

     &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1

 Host: example.com  

 

HTTP/1.1 200 OK

   Access-Control-Allow-Origin: *

   Content-Type: application/json; charset=UTF-8

   {

     "expires" : "2012-03-13T20:56:11Z",

     "links" :

     [

       {

         "rel" : "lrdd",

         "type" : "application/json",

         "template" :

           "https://example.com/lrdd/?format=json
 &resource={uri}"

       }

 

GET /lrdd/

     ?format=json

     &resource=joe@example.com

 Host: example.com  

 

HTTP/1.1 200 OK

 

   Access-Control-Allow-Origin: *

   Content-Type: application/json; charset=UTF-8

 

   {

     "subject" : "joe@example.com",

     "links" :

     [

       {

         "rel" : "http://openid.net/specs/connect/issuer",

         "href" : "https://server.example.com 
"

       },

       {

         "rel" : "http://webfinger.net/rel/avatar",

         "href" : "http://example.com/~joe/joe.jpg"

       }

 

     ]

   }

 

I can't find a template parameter for "rel".  The host-meta spec allows for
extension but it is missing.

 

What if the server wants to support filtering on rel but can't support it in
the root for some reason?

 

Is it possible to have a template like:

"https://example.com/lrdd/?format=json

&resource={uri}&rel={rel}"

 

That simple addition may solve a number of problems for openID.

 

John B.

 

 

 

 


------=_NextPart_000_0491_01CD22D2.CA535D70
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


John,
 
I actually did implement my server so that ‘rel’ is =
honored whether it’s given to host-meta or LRDD.  The reason =
is that it’s actually the same program.  It is a logical =
thing to have there for all the same reasons.
 
However, I am concerned with defining a URI template like =
‘{rel}’ that may not be modified by the client.  So, =
what might happen is that a query might be sent by the client that looks =
like this:
 
GET =
/lrdd/?resource=3Dacct:bob@example.com&rel=3D{rel}<=
/p>
 
The world would not end, but the server will have to know that the =
‘rel’ value of ‘{rel}’ means no =
‘rel’ parameter was actually passed.  I find that a bit =
odd.
 
Why not just optimize on host-meta instead of LRDD?  I agree =
that WebFinger is mostly an LRDD thing, but be mindful that =
querying host-meta, one gets a set of link relations and querying LRDD =
one gets more link relations.  To have all of the link relations =
for a specific resource, one must query both host-meta and LRDD and =
merge the link relations (in the order received).  If using the =
“resource” parameter on host-meta, then this merging of =
host-meta resource-specific link relations (i.e., those that are =
“template” types) are automatically merged in order with =
pure resource-specific link relations returned by =
LRDD.
 
In any case, I have no strong objections, but we would have to have =
special language about handling ‘{rel}’ if the template is =
not substituted with a real value.
 
Paul
 
From:=
 =
John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, =
April 25, 2012 9:17 AM
To: Paul E. Jones
Cc: =
apps-discuss@ietf.org
Subject: Re: WF flow with rel =
parameter
 
Paul, 
 
"rel" as a filter is something WF has for =
host-meta.  It however doesn't seem to have that for user JRD in =
the case where host-meta is returned, and the template is =
used.
 
The "resource" and "rel" =
parameters are already an optimization for LRDD and not part of =
host-meta.
Adding LRDD =
specific parameters to host-meta/host-meta.json will probably raise some =
eyebrows in review, but I am OK with it.
 
I =
think there are use cases where size matters.  Where a host-meta or =
resource JRD may be large and it is more efficient not to send the whole =
thing to a mobile client.
It seems to be one of Mike Jones =
requirements.
 
Using RFC6570 for LRDD is a possibility for passing =
through the filter request for sites that support filtering on resource =
JRD.
 
What other proposals do you have.  I am guessing =
that filtering on resource JRD is not a totally new =
topic.
 
LRDD is the one really doing the optimization  in =
any event,  it may be done at the host-meta GET but it is a LRDD =
specific extension.
Having =
it in the template allows LRDD to filter at the resource JRD in cases =
where it is not possible to do it at the host-meta level, due to some no =
script or other restriction.
 
I =
agree that it should be filtered at the how-meta request but you and =
others say that is not always possible.
 
John B.
 
 
 
 
On =
2012-04-25, at 2:25 AM, Paul E. Jones wrote:


John,
 
The “rel” parameter is something we still need to =
discuss, so not is as good a time as =
any.
 
What “rel” does is act as a filter.  For the most =
part, the only purpose it serves is to help reduce the number of link =
relations that might be sent from the server.  So, if a user had =
1,000 different link relations, this might reduce the returned message =
to containing only 1.  However, if a user has more than one link =
relation of the same type, all of them would match and be =
returned.
 
When you say the host cannot support re-write rules, I assume you =
mean it does not support the URI parameters on host-meta?  In that =
case, yes, the parameters are ignored and you get just the host-meta =
document.
 
The only URI template defined in RFC 6415 is “{uri}” (see =
3.1.1.1).  There are no other URI template values defined.  =
(Note: this whole section exists only because RFC  6570 did not yet =
exist, I think.
 
In any case, we could define a new URI template, but then we would be =
putting an optimization in place for LRDD.  If host-meta is not =
going to support the “rel” URI parameter, why would =
LRDD?  It would also mean that the LRDD logic would have to be =
ready to receive a URI parameter that is not replaced, since some =
clients would only change {uri} and leave {rel} there.  That would =
introduce more conditional logic in the server.  This would also =
present issues with static sites.  (Of course, one might be able to =
use Apache re-writing rules to get around that problem, but it certainly =
would not work for “real” static =
sites.)
 
Personally,  I’d prefer to not add the “rel” =
parameter to LRDD, since I think optimization using “rel” =
would always be done on host-meta.  That said, I question the value =
of “rel” entirely.  Do you think it’s useful to =
have this filter at all?  Is there really a risk that a site might =
return 1,000 link relations that the client would have to step =
over?
 
Paul
 
From:=
 John =
Bradley [mailto:ve7jtb@ve7jtb.com]=
 
Sent: Tuesday, April 24, 2012 10:17 =
PM
To: Paul E. =
Jones
Cc: apps-discuss@ietf.org
Sub=
ject: WF flow with =
rel parameter
 
Paul,
 
Sorry I hit send on the previous message with a =
typo.
 
I am looking at how the flows in WF might work for =
openID.
 
Let's set aside the XML issue for the moment and focus =
on the JSON flow.
 
Please =
correct anything I get wrong.
 
The =
openID Connect defines a relation of http://openid.net/specs/c=
onnect/issuer
 
WF =
allows for a JSON host-meta that takes two parameters, =
"resource" and =
"rel"
 
An =
example request and response (line-brakes for =
readability)
 
GET =
/.well-known/host-meta.json
<=
/div>
 
 &nb=
sp; HTTP/1.1 200 OK
 
 &nb=
sp; Access-Control-Allow-Origin: =
*
 &nb=
sp; Content-Type: application/json; =
charset=3DUTF-8
 
 &nb=
sp; {
 &nb=
sp;   "subject" : "joe@example.com",
 &nb=
sp;   "links" =
:
 &nb=
sp;   [
 &nb=
sp;     {
=

 &nb=
sp;       "rel" : "http://openid.net/specs/c=
onnect/issuer",
 &nb=
sp;       "href" : "https://server.example.com"=

 &nb=
sp;     }
=

 &nb=
sp;   ]
 &nb=
sp; }
 
If the =
host can't support rewrite rules or scripts the exchange would look =
like:
 
GET =
/.well-known/host-meta.json
<=
/div>
 
HTTP/1.1 =
200 OK
 &nb=
sp; Access-Control-Allow-Origin: =
*
 &nb=
sp; Content-Type: application/json; =
charset=3DUTF-8
 &nb=
sp; {
 &nb=
sp;   "expires" : =
"2012-03-13T20:56:11Z",
<=
div>
 &nb=
sp;   "links" =
:
 &nb=
sp;   [
 &nb=
sp;     {
=

 &nb=
sp;       "rel" : =
"lrdd",
 &nb=
sp;       "type" : =
"application/json",
=

 &nb=
sp;       "template" =
:
 &nb=
sp;     }
=

 
GET =
/lrdd/
 &nb=
sp;   ?format=3Djson
 &nb=
sp;   &resource=3Djoe@example.com=

 Hos=
t: example.com
<=
/div>
 
HTTP/1.1 =
200 OK
 
 &nb=
sp; Access-Control-Allow-Origin: =
*
 &nb=
sp; Content-Type: application/json; =
charset=3DUTF-8
 
 &nb=
sp; {
 &nb=
sp;   "subject" : "joe@example.com",
 &nb=
sp;   "links" =
:
 &nb=
sp;   [
 &nb=
sp;     {
=

 &nb=
sp;       "rel" : "http://openid.net/specs/c=
onnect/issuer",
 &nb=
sp;       "href" : "https://server.example.com"=

 &nb=
sp;     },
 &nb=
sp;     {
=

 &nb=
sp;       "rel" : "http://webfinger.net/rel/avatar<=
/a>",
=

 
That =
simple addition may solve a number of problems for =
openID.
 
John =
B.
 
 
 
 

------=_NextPart_000_0491_01CD22D2.CA535D70--


From paulej@packetizer.com  Wed Apr 25 08:06: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 84E0D21F85AF for ; Wed, 25 Apr 2012 08:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.322
X-Spam-Level: 
X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.143,  BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3e2eOdFYiuW for ; Wed, 25 Apr 2012 08:06:10 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8F78E21F85AE for ; Wed, 25 Apr 2012 08:06:10 -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 q3PF69VH023907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Apr 2012 11:06:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335366370; bh=IZwMWCDCEV/9YL0pqWw/wlvojWaRJxdrzbH9gnT9vIg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=P1GGGAkQ2a9EcSKS1qng+TvlF+fXCELCDDf1yNaDnsElmcFjJLPmxhBQSxeP2/kfW P4n6Nun4zb5v8UZz/C9wH5Oma7NEzgFfafCFaJLasXDtB5ZM0Q3xyhgTErkKIdKI++ XoZFgM7di1+qDzT7GzSB+9BBwYw6ZCnXTBKckAz4=
From: "Paul E. Jones" 
To: "'John Bradley'" 
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> 
In-Reply-To: 
Date: Wed, 25 Apr 2012 11:06:16 -0400
Message-ID: <04a601cd22f4$f6df0cf0$e49d26d0$@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: AQIsWOE+Nj6a2+m+DlaA/0DoJV2C/wIeE8UWAjl8XVEBerP71JW+pSaw
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 15:06:11 -0000

Oh that would be worse.  A client that does not implement the "rel"
optimization (i.e., all current clients) would end up passing this to the
server:

https://example.com/lrdd/?format=json&resource=acct:bob@example.com{&rel}

So the value of "resource" is wrong.  We'd have to clean that up
server-side.  I don't like that.  I could live with looking for "rel={rel}'
and throwing away "{rel}".  Still, I have concerns about optimizing there.
I can see some benefit, but if we optimize on host-meta, that seems better.

Paul

> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Wednesday, April 25, 2012 10:49 AM
> To: Paul E. Jones
> Cc: apps-discuss@ietf.org
> Subject: Re: WF flow with rel parameter
> 
> Taking a closer look at http://tools.ietf.org/html/rfc6570
> 
> The lrdd template can be something like:
> https://example.com/lrdd/?format=json{&uri,rel}
> or
> https://example.com/lrdd/?format=json&resource={uri}{&rel}
> 
> So it probably comes down to me asking for WF to conform to rfc6570 for
> LRDD template construction or at least adding the {?} and {&} templates
> from rfc6570.
> 
> That way people who want to host JRD's as a service on another host don't
> lose the ability to filter.
> 
> John B.
> 
> On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
> 
> > John,
> >
> > The "rel" parameter is something we still need to discuss, so not is as
> good a time as any.
> >
> > What "rel" does is act as a filter.  For the most part, the only purpose
> it serves is to help reduce the number of link relations that might be
> sent from the server.  So, if a user had 1,000 different link relations,
> this might reduce the returned message to containing only 1.  However, if
> a user has more than one link relation of the same type, all of them would
> match and be returned.
> >
> > When you say the host cannot support re-write rules, I assume you mean
> it does not support the URI parameters on host-meta?  In that case, yes,
> the parameters are ignored and you get just the host-meta document.
> >
> > The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1).
> There are no other URI template values defined.  (Note: this whole section
> exists only because RFC  6570 did not yet exist, I think.
> >
> > In any case, we could define a new URI template, but then we would be
> putting an optimization in place for LRDD.  If host-meta is not going to
> support the "rel" URI parameter, why would LRDD?  It would also mean that
> the LRDD logic would have to be ready to receive a URI parameter that is
> not replaced, since some clients would only change {uri} and leave {rel}
> there.  That would introduce more conditional logic in the server.  This
> would also present issues with static sites.  (Of course, one might be
> able to use Apache re-writing rules to get around that problem, but it
> certainly would not work for "real" static sites.)
> >
> > Personally,  I'd prefer to not add the "rel" parameter to LRDD, since I
> think optimization using "rel" would always be done on host-meta.  That
> said, I question the value of "rel" entirely.  Do you think it's useful to
> have this filter at all?  Is there really a risk that a site might return
> 1,000 link relations that the client would have to step over?
> >
> > Paul
> >
> > From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> > Sent: Tuesday, April 24, 2012 10:17 PM
> > To: Paul E. Jones
> > Cc: apps-discuss@ietf.org
> > Subject: WF flow with rel parameter
> >
> > Paul,
> >
> > Sorry I hit send on the previous message with a typo.
> >
> > I am looking at how the flows in WF might work for openID.
> >
> > Let's set aside the XML issue for the moment and focus on the JSON flow.
> >
> > Please correct anything I get wrong.
> >
> > The openID Connect defines a relation of
> http://openid.net/specs/connect/issuer
> >
> > WF allows for a JSON host-meta that takes two parameters, "resource" and
> "rel"
> >
> > An example request and response (line-brakes for readability)
> >
> > GET /.well-known/host-meta.json
> >      ?resource=joe@example.com
> >      &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> HTTP/1.1
> >  Host: example.com
> >
> >    HTTP/1.1 200 OK
> >
> >    Access-Control-Allow-Origin: *
> >    Content-Type: application/json; charset=UTF-8
> >
> >    {
> >      "subject" : "joe@example.com",
> >      "links" :
> >      [
> >        {
> >          "rel" : "http://openid.net/specs/connect/issuer",
> >          "href" : "https://server.example.com"
> >        }
> >      ]
> >    }
> >
> > If the host can't support rewrite rules or scripts the exchange would
> look like:
> >
> > GET /.well-known/host-meta.json
> >      ?resource=joe@example.com
> >      &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> HTTP/1.1
> >  Host: example.com
> >
> > HTTP/1.1 200 OK
> >    Access-Control-Allow-Origin: *
> >    Content-Type: application/json; charset=UTF-8
> >    {
> >      "expires" : "2012-03-13T20:56:11Z",
> >      "links" :
> >      [
> >        {
> >          "rel" : "lrdd",
> >          "type" : "application/json",
> >          "template" :
> >            "https://example.com/lrdd/?format=json&resource={uri}"
> >        }
> >
> > GET /lrdd/
> >      ?format=json
> >      &resource=joe@example.com
> >  Host: example.com
> >
> > HTTP/1.1 200 OK
> >
> >    Access-Control-Allow-Origin: *
> >    Content-Type: application/json; charset=UTF-8
> >
> >    {
> >      "subject" : "joe@example.com",
> >      "links" :
> >      [
> >        {
> >          "rel" : "http://openid.net/specs/connect/issuer",
> >          "href" : "https://server.example.com"
> >        },
> >        {
> >          "rel" : "http://webfinger.net/rel/avatar",
> >          "href" : "http://example.com/~joe/joe.jpg"
> >        }
> >
> >      ]
> >    }
> >
> > I can't find a template parameter for "rel".  The host-meta spec allows
> for extension but it is missing.
> >
> > What if the server wants to support filtering on rel but can't support
> it in the root for some reason?
> >
> > Is it possible to have a template like:
> > "https://example.com/lrdd/?format=json&resource={uri}&rel={rel}"
> >
> > That simple addition may solve a number of problems for openID.
> >
> > John B.
> >
> >
> >



From barryleiba.mailing.lists@gmail.com  Wed Apr 25 08:06: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 B4D2D21F85C2 for ; Wed, 25 Apr 2012 08:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.975
X-Spam-Level: 
X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQBCtonE26wf for ; Wed, 25 Apr 2012 08:06:23 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A254721F85F4 for ; Wed, 25 Apr 2012 08:06:23 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so141566vbb.31 for ; Wed, 25 Apr 2012 08:06:16 -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=aajdGDE/J9y7eYFBz+9sNytlViiB5QuKsPW21wrUruY=; b=xv8vErgEYlXj9fRoAwnVQuoYdE5YLbq6G/dqaP9BSy9knbqjwsqESGu8F5Vbpht72+ BiCySYVEUXMFFFfu2BWs1HoMcOHZCRJvN3ms+WvX6GJznyZ1bQpRBghEbB/XIiQ110fa 0OgwkEA5MK9EH0j9YPHBkTrh+vEjvbsldD+zqWWNy8hT3na2gKRulTO8T1IEghETLWO3 1rkSOQpBR90Oz9eZRelGEVugl9CpGI4FnIWAEuWTTINJaSWzdd17NugECQctYnODKkWR Ht5XFsfSZ6G4kJrOTEX/Nw2Z6elj9aPU3EV/Tb7Z89N0rYB7FwW6ARr9sfrCnUbhihpJ f38A==
MIME-Version: 1.0
Received: by 10.52.34.79 with SMTP id x15mr2519500vdi.0.1335366376539; Wed, 25 Apr 2012 08:06:16 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.52.163.1 with HTTP; Wed, 25 Apr 2012 08:06:16 -0700 (PDT)
Date: Wed, 25 Apr 2012 11:06:16 -0400
X-Google-Sender-Auth: ksVUvEI6shJ0Za_Bw97oi7S_Qfw
Message-ID: 
From: Barry Leiba 
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] On citations in general
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 15:06:24 -0000

While I'm on the topic of citations, let me throw something out to
this crowd before sending it to the general IETF discussion list.

There are various styles of using citations, and various strongly held
opinions about which ones are good, which evil, and which lie
somewhere between.  I don't want to make this a religious argument,
though I'm pretty sure it will be that, but here:

I consider that a citation in the text serves two purposes.  One is to
explain where the information came from, and the other is to make it
easy to get to the cited document.  As cute as it may be to say things
like, "To use items defined in [EMAIL], one must additionally...", I
find that it's not very helpful when I reading documents.

What I prefer to see -- what helps me the most as a reader -- is both
short text and an RFC number.  Often, if the short text is properly
chosen, I don't have to look at the referenced document at all.  And
when I do, I can find it immediately from the RFC number in the
citation, without having to bounce to the bottom of the doc and look
at the references.  Of course, if there are repeated citations, I
don't expect every one to have the full thing, and just the RFC
citation is enough.

Here's the sort of thing I'm talking about (made-up examples, mostly):

"...is done through SMTP [RFC5321]..."
"...SHOULD be signed using DKIM [RFC6376]..."
"The script can use the External-lists extension [RFC6134] to..."
"If a DNS block list [RFC5782] includes an IP address..."

It's also sometimes very useful to have section numbers in the
citations, when one needs to be referred to a specific point in the
cited document.  Consider this, from one of the httpbis documents:

"The field value consists of a single URI-reference.  When it has the
form of a relative reference ([RFC3986], Section 4.2), the final value
is computed by resolving it against the effective request URI
([RFC3986], Section 5)."

I find all of these to be MUCH more useful to the reader than, say,
"The script can use [RFC6134] to...", or, "If a [DNSBL] includes an IP
address...", even though the full information is in the References
section in any case.

Comments?

Barry

From marka@isc.org  Wed Apr 25 01:31: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 AB05021F8620; Wed, 25 Apr 2012 01:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.445
X-Spam-Level: 
X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUsFHnoU96Cj; Wed, 25 Apr 2012 01:31:24 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 98D0A21F85FC; Wed, 25 Apr 2012 01:31:23 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 760FB5F9915; Wed, 25 Apr 2012 08:31:05 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:d0ee:8b9f:40c6:edea]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6FDE6216C31; Wed, 25 Apr 2012 08:31:02 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B12E11FE9A17; Wed, 25 Apr 2012 18:30:59 +1000 (EST)
To: Alexey Melnikov 
From: Mark Andrews 
References: <4F96D157.7020504@isode.com>
In-reply-to: Your message of "Tue, 24 Apr 2012 17:14:15 +0100." <4F96D157.7020504@isode.com>
Date: Wed, 25 Apr 2012 18:30:59 +1000
Message-Id: <20120425083059.B12E11FE9A17@drugs.dv.isc.org>
X-Mailman-Approved-At: Wed, 25 Apr 2012 08:12:09 -0700
Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 08:31:24 -0000

In message <4F96D157.7020504@isode.com>, Alexey Melnikov writes:
> This is a supplemental AppsDir review of draft-ietf-dane-protocol (for
> background on AppsDir, please see
> ).
> 
> Although Murray Kucherawy has already reviewed this I-D on behalf of
> the AppsDir, folks in the Applications Area realize that wide
> deployment of the TLSA Resource Record might have a significant impact
> on applications, so we are performing additional reviews. Please treat
> these comments just as you would any other Last Call feedback.
> 
> Document: draft-ietf-dane-protocol
> Title: "The DNS-Based Authentication of Named Entities (DANE) Protocol
> for Transport Layer Security (TLS)"
> Reviewer: Peter Saint-Andre
> Review Date: 2012-04-24
> IETF Last Call Date: 2012-04-25
> IESG Telechat: not yet scheduled
> 
> 
> Summary: This draft is almost ready for publication as an Standards
> Track RFC but has a few issues that should be fixed before publication.
> 
> 
> Major Issue: none, although a) I am agreeing with Peter Saint-Andre's 
> major issue and b) I would like to see a reply to my minor issues
> 
> Minor Issues:
> 
> 2.2.  TLSA RR Presentation Format
> 
>     The presentation format of the RDATA portion is as follows:
> 
> Presentation for what purpose? In management UIs? Is this a required 
> presentation format for DNS tools that can retrieve and update TLSA records?

DNS management tools could get away with using RFC 3597.
 
>   [...]
> 
>     o  The certificate association data field MUST be represented as a
>        string of hexadecimal characters.  Whitespace is allowed within
>        the string of hexadecimal characters.
> 
> Please define what you mean by whitespace here? CR & LFs allowed?
> Examples in the Section 2.3 seem to suggest that.

They are allowed. See RFC 1035, Section 5.1.

( )             Parentheses are used to group data that crosses a line
                boundary.  In effect, line terminations are not
                recognized within parentheses.

 
> 3.  Domain Names for TLS Certificate Associations
> 
>     2.  The protocol name of the transport on which a TLS-based service
>         is assumed to exist is prepended with an underscore character
>         ("_") to become the second left-most label in the prepared domain
>         name.  The transport names defined for this protocol are "tcp",
>         "udp" and "sctp".
> 
> DCCP? Should there be a registry?
> 
> 4.  Use of TLSA Records in TLS
> 
>     Section 2.1 of this document defines the mandatory matching rules for
>     the data from the TLSA certificate associations and the certificates
>     received from the TLS server.
> 
>     The TLS session that is to be set up MUST be for the specific port
>     number and transport name that was given in the TLSA query.
> 
> So this will not work for any type of DNS indirection mechanism, such as 
> MX, SRV, etc? Or does DNS retrieval of such records also requires DNSSec?

NAPTR, SRV, MX, CNAME, DNAME all potentially change/define the
expected name.  Whether they do or not is protocol specific not
record specific.  If the record changes/defines the expected name
then the record should be signed or one is vulnerable to DNS based
attacks.

NAPTR, SRV, MX, CNAME, DNAME can be encountered when trying to
determine the TLSA's lookup name.

CNAME and DNAME can also be encountered as part of the TLSA lookup
itself.  In the case the CNAME / DNAME MUST be signed or you can't
trust the TLSA.

> Nits:
> 
> 4.  Use of TLSA Records in TLS
> 
>     If a TLSA record has usage type 2 for the certifcate, the
> 
> typo: certificate
> 
>     corresponding TLS server SHOULD send the certificate that is
>     referenced just like it currently sends intermediate certificates.
> 
> 
>     If an application receives zero usable certificate associations from
>     a DNS request or from its cache, it processes TLS in the normal
>     fashion without any input from the TLSA records.
> 
> Just to double check: if TLS client receives some TLSA records, but none
> of them are usable, is this considered to be the above case?
> 
>     If an application
>     receives one or more usable certificate associations, it attempts to
>     match each certificate association with the TLS server's end entity
>     certificate until a successful match is found.  During the TLS
>     handshake, if none of the certificate associations matches the
>     certificate given by the TLS server, the TLS client MUST abort the
>     handshake.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From mike@mtcc.com  Tue Apr 24 14:00: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 AE77511E80AB; Tue, 24 Apr 2012 14:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.261
X-Spam-Level: 
X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5j-v1RwVq2P1; Tue, 24 Apr 2012 14:00:44 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 3272A11E8074; Tue, 24 Apr 2012 14:00:44 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3OL0gj0027071 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 14:00:43 -0700
Message-ID: <4F97147A.7020503@mtcc.com>
Date: Tue, 24 Apr 2012 14:00:42 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Derek Atkins 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com>  <4F9573D6.9080603@mtcc.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2331; t=1335301243; x=1336165243; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20[apps-discuss]=20Web=20Fin ger=20vs.=20Simple=20Web=20Discovery=0A=20(SWD) |Sender:=20 |To:=20Derek=20Atkins=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=ZRm2iFlcuB1ZSWNJCMNNNFq4umlLCvS4RWBuA48Ctms=; b=Gx9lVvhBCoBxrCpKx7obJhfJFwGbz7r+/VQ03FOmDD+wVfXRNL7Xek1ic2 m2cFOtSuDtOtkYZuIIuPIrxtE7vguToG5Mc+6ipUxoK5OHPx8m0Z6uqzkUhY fSJa1MCjdPB5OwU/sJxIVtC49/iUSiedsi9cNbraNkGOm4hHS30ms=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
X-Mailman-Approved-At: Wed, 25 Apr 2012 08:12:17 -0700
Cc: oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Apr 2012 21:00:44 -0000

On 04/23/2012 09:55 AM, Derek Atkins wrote:
> Michael Thomas  writes:
>
>> Derek Atkins wrote:
>>> Michael Thomas  writes:
>>>
>>>> Why not MUST ASN.1 while you're at it? JSON has won in case
>>>> you'all haven't noticed it.
>>> Well, now that you mention it...   ;-)
>>>
>>> But seriously, we're basing this work on an RFC that was just release
>>> six months ago and it requires XML.  Why be so quick to drop something
>>> we just published half a year ago?  So maybe in 6 months we drop JSON
>>> and add the next big thing?  Come on, Mike.
>>>
>>> I agree, we should definitely support JSON.  But I also think we should
>>> support XML.  The client can do what it wants, which is where want the
>>> light weight implementation.
>> I think you're probably misunderstanding me. I'm (I believe) with Tim
>> in saying "pick one". Just one. For clients and servers. And I'm only
> No, I'm not misunderstanding you, I know exactly what you are arguing
> for.  And I'm agreeing with you that we must support JSON.  However, I
> disagree that we should drop XML, especially considering 6415 requires
> XML and it was just released 6 months ago.
>
> I'm also saying that this is only a server-side requirement to support
> both.  The client can choose to support only one based on its own
> requirements.  If you already have an XML-based client, why force them
> to add JSON support?  Similarly, if you already have a JSON-based
> client, why force them to add XML support?
>
> If you're writing a client, you can ignore XML and only play with JSON.
>

Derek -- I think that the modern reality is that most things can
support both without much problem from a code footprint and
library availability standpoint,  both client and server. But that
misses a larger point of whether we _should_ just because we
_can_. There is a cost to maintaining two different encoding/
decoding both on the implementation side, as well as the
specification (and the debugging thereof) side. So my feeling
is that "chose one" should *always* be a SHOULD in the way
that Stephen outlined as well. If that means choosing XML
mainly for historical reasons, that's still better than trying to
placate both sides or "facilitating the transition" or any other
reason on offer.

Mike

From tbray@textuality.com  Wed Apr 25 08:23: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 AA31721F87A5 for ; Wed, 25 Apr 2012 08:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.241
X-Spam-Level: 
X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+XxTiaBgc42 for ; Wed, 25 Apr 2012 08:23:39 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1CA21F86D7 for ; Wed, 25 Apr 2012 08:23:39 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so234252yhk.31 for ; Wed, 25 Apr 2012 08:23:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=HjtT/nG8ZYEECJIi//K1oPICK0IiLQf2eRgzw/R+CFA=; b=eWKg9d2vepX7wSCMJgcLRoeclnWacFLvsxiiVbQIS6phFydOERY3Qz5JNdea3OH7ji RWWotq9jE05i66ZaAON2lFoM7uPsFUwP9DOzy3zlOUeTlk6uzBNfKTyUMh8Gmq/wiSld 9A5fw3zb4iVV3qbvbjD8EvGqAgHNP3Sm9ocih0lSvrfjrN8TpHmov5NLdoRsXm2MuVFL 49Vs3lFtwBz8xz31VOMMR/l5SXT70ixfhzuao7oeo+/odyPg8n06Ht80sKBzEwYqdE8O 1/wDXamNSbjU8+5LvQzOzIrW9I4gyTFXAIYPiSSGm/vSVGVaxIB8NeDZjIYwNPhnRQXi R+MQ==
MIME-Version: 1.0
Received: by 10.60.170.172 with SMTP id an12mr3860759oec.44.1335367404146; Wed, 25 Apr 2012 08:23:24 -0700 (PDT)
Received: by 10.182.204.71 with HTTP; Wed, 25 Apr 2012 08:23:24 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
In-Reply-To: 
References: 
Date: Wed, 25 Apr 2012 08:23:24 -0700
Message-ID: 
From: Tim Bray 
To: Barry Leiba 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmpSXcsv2uKzxRJoYTmaLFKxDYWz12UNniyW7c+ZKhdbCOgfok5Vv6tHoY+S139P2KupcXH
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On citations in general
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 15:23:40 -0000

If only there were a technology which allowed citations to be made
actual actionable usable links directly to the targeted source. A text
with this sort of thing would be so great that we=92d need a new name
for it... supertext? ultratext? hypertext?

 -T

On Wed, Apr 25, 2012 at 8:06 AM, Barry Leiba  wrot=
e:
> While I'm on the topic of citations, let me throw something out to
> this crowd before sending it to the general IETF discussion list.
>
> There are various styles of using citations, and various strongly held
> opinions about which ones are good, which evil, and which lie
> somewhere between. =A0I don't want to make this a religious argument,
> though I'm pretty sure it will be that, but here:
>
> I consider that a citation in the text serves two purposes. =A0One is to
> explain where the information came from, and the other is to make it
> easy to get to the cited document. =A0As cute as it may be to say things
> like, "To use items defined in [EMAIL], one must additionally...", I
> find that it's not very helpful when I reading documents.
>
> What I prefer to see -- what helps me the most as a reader -- is both
> short text and an RFC number. =A0Often, if the short text is properly
> chosen, I don't have to look at the referenced document at all. =A0And
> when I do, I can find it immediately from the RFC number in the
> citation, without having to bounce to the bottom of the doc and look
> at the references. =A0Of course, if there are repeated citations, I
> don't expect every one to have the full thing, and just the RFC
> citation is enough.
>
> Here's the sort of thing I'm talking about (made-up examples, mostly):
>
> "...is done through SMTP [RFC5321]..."
> "...SHOULD be signed using DKIM [RFC6376]..."
> "The script can use the External-lists extension [RFC6134] to..."
> "If a DNS block list [RFC5782] includes an IP address..."
>
> It's also sometimes very useful to have section numbers in the
> citations, when one needs to be referred to a specific point in the
> cited document. =A0Consider this, from one of the httpbis documents:
>
> "The field value consists of a single URI-reference. =A0When it has the
> form of a relative reference ([RFC3986], Section 4.2), the final value
> is computed by resolving it against the effective request URI
> ([RFC3986], Section 5)."
>
> I find all of these to be MUCH more useful to the reader than, say,
> "The script can use [RFC6134] to...", or, "If a [DNSBL] includes an IP
> address...", even though the full information is in the References
> section in any case.
>
> Comments?
>
> Barry
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From stpeter@stpeter.im  Wed Apr 25 08:26: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 7A56721F842A for ; Wed, 25 Apr 2012 08:26:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.533
X-Spam-Level: 
X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3fNn0aYTDaa for ; Wed, 25 Apr 2012 08:26:17 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1E89E21F8617 for ; Wed, 25 Apr 2012 08:26:13 -0700 (PDT)
Received: from [192.168.0.3] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AFED240058; Wed, 25 Apr 2012 09:40:48 -0600 (MDT)
Message-ID: <4F981796.2090505@stpeter.im>
Date: Wed, 25 Apr 2012 09:26:14 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Barry Leiba 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On citations in general
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 15:26:18 -0000

On 4/25/12 9:06 AM, Barry Leiba wrote:

> Comments?

I think this topic is more appropriate for the rfc-interest list. In
fact, the RFC Editor had a Citations Committee for a while...

/psa


From ve7jtb@ve7jtb.com  Wed Apr 25 08:26: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 9E55C21F842A for ; Wed, 25 Apr 2012 08:26:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.477
X-Spam-Level: 
X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+HKijKOl7su for ; Wed, 25 Apr 2012 08:26:44 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6627B21F87BA for ; Wed, 25 Apr 2012 08:26:44 -0700 (PDT)
Received: by mail-yw0-f44.google.com with SMTP id k25so237444yhk.31 for ; Wed, 25 Apr 2012 08:26:44 -0700 (PDT)
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=6ZFmlghyd6oJwl6nZzIGNsD4OvsMONs+g7eBiovNzg8=; b=iM1zng822Fmx5QcvdkfYpsqXOfwLsrpr0olJV8uJ4HHSDTcxtZeLDiqV+3Xd0DpkJJ x+rcsSzG0CPWC+odrRD8WGEBCVWju/swcWPBetbBFP26auYtllk7lT3wcCVyvAA2U8a3 2fgaS64wB/4xvhRoC4ADmnBSqeLoL0jYWc9yplmE35yB6UsTJTxrMfAzyrDnL6oWYMcE +uxqMw2nFMdq9/efNK1oWXZxPHsKAT5WtJan03SY3DUeDBj+RVgZ8HuHfip8NLCjFfPD Q8v228g90MEWLmqKV9FhDgm+RDFHhh/LPcaVrNqfp3/j80km27otaNDrV9cZKOBQIvDK Dxhg==
Received: by 10.236.170.130 with SMTP id p2mr2850766yhl.73.1335367603921; Wed, 25 Apr 2012 08:26:43 -0700 (PDT)
Received: from [192.168.1.213] (190-20-63-108.baf.movistar.cl. [190.20.63.108]) by mx.google.com with ESMTPS id a35sm103335479yhh.13.2012.04.25.08.26.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 08:26:43 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_F8093BFF-49D2-453F-8F71-232AC0B1E5D6"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201007020@P3PWEX2MB008.ex2.secureserver.net>
Date: Wed, 25 Apr 2012 12:26:32 -0300
Message-Id: <515663DA-67BF-4367-9AD9-6E940424CBCD@ve7jtb.com>
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201007020@P3PWEX2MB008.ex2.secureserver.net>
To: Eran Hammer 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQm+z9bgN7RuIfyJJJa1OnfsY2PqNp/EQ1zrtSzWrikFlSiooneoVtyU3wV+PCAJ9Qlxhvmx
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 15:26:45 -0000

--Apple-Mail=_F8093BFF-49D2-453F-8F71-232AC0B1E5D6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

That was one thing that initially confused me.  The rel filter is not =
applied to host-meta, but rather the linked lrdd resource JRD.

The currently defined "resource" parameter has an implicit host-meta =
"rel" of "lrdd".

To use this mechanism for other relations you would need to make that =
parameter explicit.

That then raises the question of the filter being part of host-meta or =
WF if it applies to relationships other than lrdd.

If you are asking if filtering should be supported by lrdd where you =
start discovery from a link header, then it probably should be possible =
as well.

Though I thought lrdd stopped being updated over a year a year ago.   =
Sorry if I am out of date.

So XRD/JRD documents SHOULD be filterable by "rel" independent of if you =
get to them via lrdd or host-meta.

Host-meta SHOULD support a mechanism to filter by "rel" or filter by a =
combination of "resource" (uri) , host-meta-rel and resource-rel (the =
host-meta-rel is currently implicit.)

I recall discussing this in the XRI TC when we did XRD years ago, though =
that was more around using XRI identifiers.

The same principal still holds.  I should be able to ask for.
GET /.well-known/host-meta.json
     ?resource=3Djoe@example.com
     &host-meta-rel=3Dlrdd
     &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
 Host: example.com

(personally I think calling the parameter "resource" and the template =
{uri} will be confusing to people)

In SWD we used fixed the parameter names and the base URI is the part =
that gets changed when the /.well-known can't host a script.
That makes the template simpler for the client to process.  The =
equivalent to "rel" is always passed to make processing simpler.

As Blaine has pointed out several times SWD and WF largely get us to the =
same place.

I am trying to find a way to close the gap.
=20
John B.


On 2012-04-25, at 11:41 AM, Eran Hammer wrote:

> Purely from a practical standpoint, do you think it is likely that a =
server will support the query filter for the lrdd documents but not for =
host-meta?
> =20
> EH
> =20
> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, April 25, 2012 6:17 AM
> To: Paul E. Jones
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] WF flow with rel parameter
> =20
> Paul,=20
> =20
> "rel" as a filter is something WF has for host-meta.  It however =
doesn't seem to have that for user JRD in the case where host-meta is =
returned, and the template is used.
> =20
> The "resource" and "rel" parameters are already an optimization for =
LRDD and not part of host-meta.
> Adding LRDD specific parameters to host-meta/host-meta.json will =
probably raise some eyebrows in review, but I am OK with it.
> =20
> I think there are use cases where size matters.  Where a host-meta or =
resource JRD may be large and it is more efficient not to send the whole =
thing to a mobile client.
> It seems to be one of Mike Jones requirements.
> =20
> Using RFC6570 for LRDD is a possibility for passing through the filter =
request for sites that support filtering on resource JRD.
> =20
> What other proposals do you have.  I am guessing that filtering on =
resource JRD is not a totally new topic.
> =20
> LRDD is the one really doing the optimization  in any event,  it may =
be done at the host-meta GET but it is a LRDD specific extension.
> Having it in the template allows LRDD to filter at the resource JRD in =
cases where it is not possible to do it at the host-meta level, due to =
some no script or other restriction.
> =20
> I agree that it should be filtered at the how-meta request but you and =
others say that is not always possible.
> =20
> John B.
> =20
> =20
> =20
> =20
> On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
>=20
>=20
> John,
> =20
> The =93rel=94 parameter is something we still need to discuss, so not =
is as good a time as any.
> =20
> What =93rel=94 does is act as a filter.  For the most part, the only =
purpose it serves is to help reduce the number of link relations that =
might be sent from the server.  So, if a user had 1,000 different link =
relations, this might reduce the returned message to containing only 1.  =
However, if a user has more than one link relation of the same type, all =
of them would match and be returned.
> =20
> When you say the host cannot support re-write rules, I assume you mean =
it does not support the URI parameters on host-meta?  In that case, yes, =
the parameters are ignored and you get just the host-meta document.
> =20
> The only URI template defined in RFC 6415 is =93{uri}=94 (see =
3.1.1.1).  There are no other URI template values defined.  (Note: this =
whole section exists only because RFC  6570 did not yet exist, I think.
> =20
> In any case, we could define a new URI template, but then we would be =
putting an optimization in place for LRDD.  If host-meta is not going to =
support the =93rel=94 URI parameter, why would LRDD?  It would also mean =
that the LRDD logic would have to be ready to receive a URI parameter =
that is not replaced, since some clients would only change {uri} and =
leave {rel} there.  That would introduce more conditional logic in the =
server.  This would also present issues with static sites.  (Of course, =
one might be able to use Apache re-writing rules to get around that =
problem, but it certainly would not work for =93real=94 static sites.)
> =20
> Personally,  I=92d prefer to not add the =93rel=94 parameter to LRDD, =
since I think optimization using =93rel=94 would always be done on =
host-meta.  That said, I question the value of =93rel=94 entirely.  Do =
you think it=92s useful to have this filter at all?  Is there really a =
risk that a site might return 1,000 link relations that the client would =
have to step over?
> =20
> Paul
> =20
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Tuesday, April 24, 2012 10:17 PM
> To: Paul E. Jones
> Cc: apps-discuss@ietf.org
> Subject: WF flow with rel parameter
> =20
> Paul,
> =20
> Sorry I hit send on the previous message with a typo.
> =20
> I am looking at how the flows in WF might work for openID.
> =20
> Let's set aside the XML issue for the moment and focus on the JSON =
flow.
> =20
> Please correct anything I get wrong.
> =20
> The openID Connect defines a relation of =
http://openid.net/specs/connect/issuer
> =20
> WF allows for a JSON host-meta that takes two parameters, "resource" =
and "rel"
> =20
> An example request and response (line-brakes for readability)
> =20
> GET /.well-known/host-meta.json
>      ?resource=3Djoe@example.com
>      &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
>  Host: example.com
> =20
>    HTTP/1.1 200 OK
> =20
>    Access-Control-Allow-Origin: *
>    Content-Type: application/json; charset=3DUTF-8
> =20
>    {
>      "subject" : "joe@example.com",
>      "links" :
>      [
>        {
>          "rel" : "http://openid.net/specs/connect/issuer",
>          "href" : "https://server.example.com"
>        }
>      ]
>    }
> =20
> If the host can't support rewrite rules or scripts the exchange would =
look like:
> =20
> GET /.well-known/host-meta.json
>      ?resource=3Djoe@example.com
>      &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer =
HTTP/1.1
>  Host: example.com
> =20
> HTTP/1.1 200 OK
>    Access-Control-Allow-Origin: *
>    Content-Type: application/json; charset=3DUTF-8
>    {
>      "expires" : "2012-03-13T20:56:11Z",
>      "links" :
>      [
>        {
>          "rel" : "lrdd",
>          "type" : "application/json",
>          "template" :
>            "https://example.com/lrdd/?format=3Djson&resource=3D{uri}"
>        }
> =20
> GET /lrdd/
>      ?format=3Djson
>      &resource=3Djoe@example.com
>  Host: example.com
> =20
> HTTP/1.1 200 OK
> =20
>    Access-Control-Allow-Origin: *
>    Content-Type: application/json; charset=3DUTF-8
> =20
>    {
>      "subject" : "joe@example.com",
>      "links" :
>      [
>        {
>          "rel" : "http://openid.net/specs/connect/issuer",
>          "href" : "https://server.example.com"
>        },
>        {
>          "rel" : "http://webfinger.net/rel/avatar",
>          "href" : "http://example.com/~joe/joe.jpg"
>        }
> =20
>      ]
>    }
> =20
> I can't find a template parameter for "rel".  The host-meta spec =
allows for extension but it is missing.
> =20
> What if the server wants to support filtering on rel but can't support =
it in the root for some reason?
> =20
> Is it possible to have a template like:
> "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}"
> =20
> That simple addition may solve a number of problems for openID.
> =20
> John B.
> =20
> =20
> =20


--Apple-Mail=_F8093BFF-49D2-453F-8F71-232AC0B1E5D6
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
NTE1MjYzM1owIwYJKoZIhvcNAQkEMRYEFE+1ZtUcJm9HrSWaesbxWsZvfRTIMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AFYIhwNcpaSwNNldv0/q3+CAtoP6dy6vrJ5Rjst1aGRqVLL1ioXsujQXfIuiwq/crYNYLe7STYbJ
Tf4eDLpS4bQF+x0BeDcPRv4adCnr1e/yucEVBMAeSHxO39yNsljZeNIMiifhHrDc5zSR65MlEixb
FP8IkAIdkcAjeX/8NMorTyLV2T21dj7b5IzjK/KgxLzqozLOe+djNG1VuOwXsiWXDe6YVwRN/qLB
/Doz4Hq9lq5jBEQ5zCokGSn0sWkHXkORMZp7gOLYSlLPmWq6OQnrKV72V+mOrs8Dxrk86rTkT6i0
Zy40WDEmb9CboOfb8ZhONn6Pa3R7FnNwR8tgzI0AAAAAAAA=

--Apple-Mail=_F8093BFF-49D2-453F-8F71-232AC0B1E5D6--

From barryleiba@gmail.com  Wed Apr 25 08:35: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 BE83E21F8666 for ; Wed, 25 Apr 2012 08:35:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.975
X-Spam-Level: 
X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nl4jHNgNAmVU for ; Wed, 25 Apr 2012 08:35:56 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27A7121F865A for ; Wed, 25 Apr 2012 08:35:56 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so249919yhk.31 for ; Wed, 25 Apr 2012 08:35:55 -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=sMpIpZlyTy//ptDQxqax35kLUCbtctGCV4Bf/lFf7Ug=; b=CPFiFyRpvUeHb0hRHcyFEcp3ZHB88QgzmXSTtGwaC2PtDDHQmdeJsjRFa6M8Al3eih lxPs6+ZwXVtbuXG3Pe0z6fySwxp32arbHWteITtIFkv48oVvBgmd6J6PfiFFiz78xrFA QztBFpKLdALw+yGKvH0KfZ0VZape8cp4n6mPW+9+1laLo+PIfl7cYuau7nEy/tdET3P9 vXCv3Ifs8JCIp0rkewwBsrCBG/2Xc+/9FqtpCrOfpROXxnx1gZftLBV21J9A6RKj0VMb OxT8Gxa/SbzexhSF6sZKAPFwEel77rJC4T4ijNgeajv49/QljzBM/MMh0IJULk9UYmn1 1uWA==
MIME-Version: 1.0
Received: by 10.60.23.138 with SMTP id m10mr4055430oef.12.1335368155717; Wed, 25 Apr 2012 08:35:55 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.60.10.68 with HTTP; Wed, 25 Apr 2012 08:35:55 -0700 (PDT)
In-Reply-To: 
References:  
Date: Wed, 25 Apr 2012 11:35:55 -0400
X-Google-Sender-Auth: ganwHdrpFRTvrcfiRYfp5rrF-Co
Message-ID: 
From: Barry Leiba 
To: Tim Bray 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On citations in general
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 15:35:56 -0000

> If only there were a technology which allowed citations to be made
> actual actionable usable links directly to the targeted source.

Yeh, eliminating your biting sarcasm: we're often reviewing these
things offline, and sometimes even from printed text.  Not having to
flip back and forth can be useful.

Barry

From fanf2@hermes.cam.ac.uk  Wed Apr 25 08:43: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 2C74321F87C8 for ; Wed, 25 Apr 2012 08:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.403
X-Spam-Level: 
X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elroRNg90LoV for ; Wed, 25 Apr 2012 08:43:32 -0700 (PDT)
Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id BF54B21F87BF for ; Wed, 25 Apr 2012 08:43:17 -0700 (PDT)
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-2.csi.cam.ac.uk ([131.111.8.54]:42514) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1SN4NA-0000nS-py (Exim 4.72) (return-path ); Wed, 25 Apr 2012 16:43:16 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SN4NA-0003xw-2X (Exim 4.67) (return-path ); Wed, 25 Apr 2012 16:43:16 +0100
Date: Wed, 25 Apr 2012 16:43:16 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Barry Leiba 
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: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On citations in general
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 15:43:33 -0000

Barry Leiba  wrote:
>
> Comments?

I think all your suggestions are excellent.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Biscay: Southwest 6 to gale 8, occasionally severe gale 9 at first. Very rough
or high. Squally showers. Poor, becoming moderate.

From paulej@packetizer.com  Wed Apr 25 09: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 F368A21F86D9 for ; Wed, 25 Apr 2012 09:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.325
X-Spam-Level: 
X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.140,  BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZj8J8LyNZ8B for ; Wed, 25 Apr 2012 09:07:39 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id CF8B121F87D5 for ; Wed, 25 Apr 2012 09:07:38 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3PG7Zhf025804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Apr 2012 12:07:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335370056; bh=nAyPPQfJaZeuTs77oFHHIY5BmwLGgue2/x181xaLj4Y=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Bl80B2RheDuoDLnkwMkzxzUIsIloj7NNATfvBaqobwZEZDKM5isGPllOTKV1dtsT9 mhBy9Ge8ShBEe/SbxdC/FNNT/7VVp5aVypKYzBnoiQfFMhv6I2nJuEsXd3tAR14j0/ mcR50tjWtYc+vqRTTpWuTqVtk90t6tejlLHovyjQ=
From: "Paul E. Jones" 
To: "'John Bradley'" , "'Eran Hammer'" 
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201007020@P3PWEX2MB008.ex2.secureserver.net> <515663DA-67BF-4367-9AD9-6E940424CBCD@ve7jtb.com>
In-Reply-To: <515663DA-67BF-4367-9AD9-6E940424CBCD@ve7jtb.com>
Date: Wed, 25 Apr 2012 12:07:42 -0400
Message-ID: <04fa01cd22fd$8be9fb90$a3bdf2b0$@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: AQIsWOE+Nj6a2+m+DlaA/0DoJV2C/wIeE8UWAjl8XVEB+oMj2wHBLcV7AhY5Pe+Vm/L3gA==
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 16:07:40 -0000

John,

> That was one thing that initially confused me.  The rel filter is not
> applied to host-meta, but rather the linked lrdd resource JRD.

It should be applied to all 's returned from a query to host-meta
where "resource" and "rel" parameters are used.  What I do is collect all
host-meta links and then all LRDD links (in order), then running the filter
over that after collecting all of the links.  (Memory optimization might be
to discard things that match right away, but it wasn't worth my time to see
if I can shave off milliseconds here.)
 
> The currently defined "resource" parameter has an implicit host-meta "rel"
> of "lrdd".

Are you saying we implicitly filter only on LRDD links?  If so, that was not
the intent.  We should filter on ALL links that might be returned from the
query to host-meta. 

> To use this mechanism for other relations you would need to make that
> parameter explicit.

The parameter is only documented for host-meta and documented in a section
called "The Web Host Metadata "rel" Parameter."  If that's not clear, we
should make it clear.  Suggestions?

> That then raises the question of the filter being part of host-meta or WF
> if it applies to relationships other than lrdd.

Only applies to host-meta queries (per the spec presently).
 
> If you are asking if filtering should be supported by lrdd where you start
> discovery from a link header, then it probably should be possible as well.

It's possible and my server would do that, as I mentioned.  I'm not sure how
useful it is.  If one believes it might be useful at host-meta level, then
it might be useful on LRDD only.  That said, I question both the usefulness
(since it merely reduces the document size) and I question why we don't
apply the "rel" filter at just one place if optimization is desired.
 
> Though I thought lrdd stopped being updated over a year a year ago.
> Sorry if I am out of date.

The specs merged, but LRDD is its own resource.  It's not "host metadata",
but a resource-specific thing.
 
> So XRD/JRD documents SHOULD be filterable by "rel" independent of if you
> get to them via lrdd or host-meta.

We could, but presently the spec intended to only applies this to host-meta.
My concern is with the construction of those templates, effect on existing
servers and clients, etc.
 
> Host-meta SHOULD support a mechanism to filter by "rel" or filter by a
> combination of "resource" (uri) , host-meta-rel and resource-rel (the
> host-meta-rel is currently implicit.)

The "rel" parameter when applied to /.well-known/host-meta should filter all
link relation values returned, regardless if those are resource-specific
that might have been expanded from LRDD or resource-specific as defined in
the host-meta document itself.  I have this working on my server.  See these
examples:

$ curl 'https://packetizer.com/.well-known/host-meta?
                  resource=acct:paulej@packetizer.com'
$ curl 'https://packetizer.com/.well-known/host-meta?
                  resource=acct:paulej@packetizer.com&rel=test'

The first returns the entire document.  The second returns only "test".
This "test" resource you can see came from host-meta:

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

> I recall discussing this in the XRI TC when we did XRD years ago, though
> that was more around using XRI identifiers.
> 
> The same principal still holds.  I should be able to ask for.
> GET /.well-known/host-meta.json
>      ?resource=joe@example.com
>      &host-meta-rel=lrdd
>      &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> HTTP/1.1
>  Host: example.com

Given what I said, would we want the host-meta-rel parameter?  I don't think
we'd need it.
 
> (personally I think calling the parameter "resource" and the template
> {uri} will be confusing to people)

Why is this confusing?  What would be better?
 
> In SWD we used fixed the parameter names and the base URI is the part that
> gets changed when the /.well-known can't host a script.
> That makes the template simpler for the client to process.  The equivalent
> to "rel" is always passed to make processing simpler.

This is one difference :)
 
> As Blaine has pointed out several times SWD and WF largely get us to the
> same place.

True.

Paul



From eran@hueniverse.com  Wed Apr 25 09:18: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 0DBC421F87E8 for ; Wed, 25 Apr 2012 09:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.509
X-Spam-Level: 
X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5DK1L77fcUs for ; Wed, 25 Apr 2012 09:18:51 -0700 (PDT)
Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id E942521F87E9 for ; Wed, 25 Apr 2012 09:18:50 -0700 (PDT)
Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id 2GJq1j0060Dcg9U01GJq8b; Wed, 25 Apr 2012 09:18:50 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Wed, 25 Apr 2012 09:18:50 -0700
From: Eran Hammer 
To: John Bradley , Paul E.Jones 
Thread-Topic: [apps-discuss] WF flow with rel parameter
Thread-Index: AQHNIomKaCym1aAtdUm4KjKnInrNO5ard+qAgACdUwD//6MpkA==
Date: Wed, 25 Apr 2012 16:18:49 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20100988A@P3PWEX2MB008.ex2.secureserver.net>
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 16:18:52 -0000

There are two separate issues here:

1. Adding support for RFC 6570 - this adds complexity (but might have happe=
ned if 6570 was finished earlier).
2. Define additional parameters (right now, only 'uri' is defined as a temp=
late input).

EH

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, April 25, 2012 7:49 AM
> To: Paul E.Jones
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] WF flow with rel parameter
>=20
> Taking a closer look at http://tools.ietf.org/html/rfc6570
>=20
> The lrdd template can be something like:
> https://example.com/lrdd/?format=3Djson{&uri,rel}
> or
> https://example.com/lrdd/?format=3Djson&resource=3D{uri}{&rel}
>=20
> So it probably comes down to me asking for WF to conform to rfc6570 for
> LRDD template construction or at least adding the {?} and {&} templates f=
rom
> rfc6570.
>=20
> That way people who want to host JRD's as a service on another host don't
> lose the ability to filter.
>=20
> John B.
>=20
> On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
>=20
> > John,
> >
> > The "rel" parameter is something we still need to discuss, so not is as=
 good
> a time as any.
> >
> > What "rel" does is act as a filter.  For the most part, the only purpos=
e it
> serves is to help reduce the number of link relations that might be sent =
from
> the server.  So, if a user had 1,000 different link relations, this might=
 reduce
> the returned message to containing only 1.  However, if a user has more t=
han
> one link relation of the same type, all of them would match and be return=
ed.
> >
> > When you say the host cannot support re-write rules, I assume you mean =
it
> does not support the URI parameters on host-meta?  In that case, yes, the
> parameters are ignored and you get just the host-meta document.
> >
> > The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1).  Th=
ere are
> no other URI template values defined.  (Note: this whole section exists o=
nly
> because RFC  6570 did not yet exist, I think.
> >
> > In any case, we could define a new URI template, but then we would be
> putting an optimization in place for LRDD.  If host-meta is not going to
> support the "rel" URI parameter, why would LRDD?  It would also mean that
> the LRDD logic would have to be ready to receive a URI parameter that is =
not
> replaced, since some clients would only change {uri} and leave {rel} ther=
e.
> That would introduce more conditional logic in the server.  This would al=
so
> present issues with static sites.  (Of course, one might be able to use A=
pache
> re-writing rules to get around that problem, but it certainly would not w=
ork
> for "real" static sites.)
> >
> > Personally,  I'd prefer to not add the "rel" parameter to LRDD, since I=
 think
> optimization using "rel" would always be done on host-meta.  That said, I
> question the value of "rel" entirely.  Do you think it's useful to have t=
his filter
> at all?  Is there really a risk that a site might return 1,000 link relat=
ions that the
> client would have to step over?
> >
> > Paul
> >
> > From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> > Sent: Tuesday, April 24, 2012 10:17 PM
> > To: Paul E. Jones
> > Cc: apps-discuss@ietf.org
> > Subject: WF flow with rel parameter
> >
> > Paul,
> >
> > Sorry I hit send on the previous message with a typo.
> >
> > I am looking at how the flows in WF might work for openID.
> >
> > Let's set aside the XML issue for the moment and focus on the JSON flow=
.
> >
> > Please correct anything I get wrong.
> >
> > The openID Connect defines a relation of
> http://openid.net/specs/connect/issuer
> >
> > WF allows for a JSON host-meta that takes two parameters, "resource" an=
d
> "rel"
> >
> > An example request and response (line-brakes for readability)
> >
> > GET /.well-known/host-meta.json
> >      ?resource=3Djoe@example.com
> >      &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> HTTP/1.1
> >  Host: example.com
> >
> >    HTTP/1.1 200 OK
> >
> >    Access-Control-Allow-Origin: *
> >    Content-Type: application/json; charset=3DUTF-8
> >
> >    {
> >      "subject" : "joe@example.com",
> >      "links" :
> >      [
> >        {
> >          "rel" : "http://openid.net/specs/connect/issuer",
> >          "href" : "https://server.example.com"
> >        }
> >      ]
> >    }
> >
> > If the host can't support rewrite rules or scripts the exchange would l=
ook
> like:
> >
> > GET /.well-known/host-meta.json
> >      ?resource=3Djoe@example.com
> >      &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> HTTP/1.1
> >  Host: example.com
> >
> > HTTP/1.1 200 OK
> >    Access-Control-Allow-Origin: *
> >    Content-Type: application/json; charset=3DUTF-8
> >    {
> >      "expires" : "2012-03-13T20:56:11Z",
> >      "links" :
> >      [
> >        {
> >          "rel" : "lrdd",
> >          "type" : "application/json",
> >          "template" :
> >            "https://example.com/lrdd/?format=3Djson&resource=3D{uri}"
> >        }
> >
> > GET /lrdd/
> >      ?format=3Djson
> >      &resource=3Djoe@example.com
> >  Host: example.com
> >
> > HTTP/1.1 200 OK
> >
> >    Access-Control-Allow-Origin: *
> >    Content-Type: application/json; charset=3DUTF-8
> >
> >    {
> >      "subject" : "joe@example.com",
> >      "links" :
> >      [
> >        {
> >          "rel" : "http://openid.net/specs/connect/issuer",
> >          "href" : "https://server.example.com"
> >        },
> >        {
> >          "rel" : "http://webfinger.net/rel/avatar",
> >          "href" : "http://example.com/~joe/joe.jpg"
> >        }
> >
> >      ]
> >    }
> >
> > I can't find a template parameter for "rel".  The host-meta spec allows=
 for
> extension but it is missing.
> >
> > What if the server wants to support filtering on rel but can't support =
it in
> the root for some reason?
> >
> > Is it possible to have a template like:
> > "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}"
> >
> > That simple addition may solve a number of problems for openID.
> >
> > John B.
> >
> >
> >


From eran@hueniverse.com  Wed Apr 25 09:34:17 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A2721F87E9 for ; Wed, 25 Apr 2012 09:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.507
X-Spam-Level: 
X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n65Gqtil0q+x for ; Wed, 25 Apr 2012 09:34:16 -0700 (PDT)
Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id F1AB221F87DA for ; Wed, 25 Apr 2012 09:34:15 -0700 (PDT)
Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id 2GaF1j0050CJzpC01GaFvK; Wed, 25 Apr 2012 09:34:15 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Wed, 25 Apr 2012 09:34:15 -0700
From: Eran Hammer 
To: John Bradley 
Thread-Topic: [apps-discuss] WF flow with rel parameter
Thread-Index: AQHNIomKaCym1aAtdUm4KjKnInrNO5ard+qAgACDoID//6IRMIAAgkAA//+ZoSA=
Date: Wed, 25 Apr 2012 16:34:14 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20100990A@P3PWEX2MB008.ex2.secureserver.net>
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201007020@P3PWEX2MB008.ex2.secureserver.net> <515663DA-67BF-4367-9AD9-6E940424CBCD@ve7jtb.com>
In-Reply-To: <515663DA-67BF-4367-9AD9-6E940424CBCD@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 16:34:17 -0000

It is important to understand the semantics of host-meta, which I think the=
re is some confusion about here.

As a mechanism, host-meta providers you with a method of obtaining both hos=
t-wide and resource-specific links (and properties). To accomplish that, it=
 provides with both a document and processing rules.

WebFinger - the name given for the host-meta *use-case* of retrieving user =
information - is a specialization of obtaining resource-specific links.

The 'rel' and 'resource' query parameters (as proposed) apply to the endpoi=
nt *after* executing the processing rules (which include expanding template=
s and importing links from one level LRDD documents).

LRDD documents only apply to resource-specific links, which means they are =
ignored for any host-wide query. For example, the location of the site's TO=
S document. From the host-meta perspective, LRDD documents are just a deplo=
yment tool to provide customization not possible using just link templates =
at the host-meta document level. It's just a link-include mechanism, and ho=
st-meta uses it restrictively.

IMO, the 'rel' and 'resource' optimization should only apply to the host-me=
ta endpoint, and act as a filter post the processing rules. If 'resource' i=
s specified, it is a resource-specific request, otherwise, host-wide.

Let me know if this helps or if it is still unclear.

EH




> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Wednesday, April 25, 2012 8:27 AM
> To: Eran Hammer
> Cc: Paul E. Jones; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] WF flow with rel parameter
>=20
> That was one thing that initially confused me.  The rel filter is not app=
lied to
> host-meta, but rather the linked lrdd resource JRD.
>=20
> The currently defined "resource" parameter has an implicit host-meta "rel=
"
> of "lrdd".
>=20
> To use this mechanism for other relations you would need to make that
> parameter explicit.
>=20
> That then raises the question of the filter being part of host-meta or WF=
 if it
> applies to relationships other than lrdd.
>=20
> If you are asking if filtering should be supported by lrdd where you star=
t
> discovery from a link header, then it probably should be possible as well=
.
>=20
> Though I thought lrdd stopped being updated over a year a year ago.   Sor=
ry if
> I am out of date.
>=20
> So XRD/JRD documents SHOULD be filterable by "rel" independent of if you
> get to them via lrdd or host-meta.
>=20
> Host-meta SHOULD support a mechanism to filter by "rel" or filter by a
> combination of "resource" (uri) , host-meta-rel and resource-rel (the hos=
t-
> meta-rel is currently implicit.)
>=20
> I recall discussing this in the XRI TC when we did XRD years ago, though =
that
> was more around using XRI identifiers.
>=20
> The same principal still holds.  I should be able to ask for.
> GET /.well-known/host-meta.json
>      ?resource=3Djoe@example.com
>      &host-meta-rel=3Dlrdd
>      &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> HTTP/1.1
>  Host: example.com
>=20
> (personally I think calling the parameter "resource" and the template {ur=
i}
> will be confusing to people)
>=20
> In SWD we used fixed the parameter names and the base URI is the part tha=
t
> gets changed when the /.well-known can't host a script.
> That makes the template simpler for the client to process.  The equivalen=
t to
> "rel" is always passed to make processing simpler.
>=20
> As Blaine has pointed out several times SWD and WF largely get us to the
> same place.
>=20
> I am trying to find a way to close the gap.
>=20
> John B.
>=20
>=20
> On 2012-04-25, at 11:41 AM, Eran Hammer wrote:
>=20
> > Purely from a practical standpoint, do you think it is likely that a se=
rver will
> support the query filter for the lrdd documents but not for host-meta?
> >
> > EH
> >
> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of John Bradley
> > Sent: Wednesday, April 25, 2012 6:17 AM
> > To: Paul E. Jones
> > Cc: apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] WF flow with rel parameter
> >
> > Paul,
> >
> > "rel" as a filter is something WF has for host-meta.  It however doesn'=
t
> seem to have that for user JRD in the case where host-meta is returned, a=
nd
> the template is used.
> >
> > The "resource" and "rel" parameters are already an optimization for LRD=
D
> and not part of host-meta.
> > Adding LRDD specific parameters to host-meta/host-meta.json will
> probably raise some eyebrows in review, but I am OK with it.
> >
> > I think there are use cases where size matters.  Where a host-meta or
> resource JRD may be large and it is more efficient not to send the whole
> thing to a mobile client.
> > It seems to be one of Mike Jones requirements.
> >
> > Using RFC6570 for LRDD is a possibility for passing through the filter =
request
> for sites that support filtering on resource JRD.
> >
> > What other proposals do you have.  I am guessing that filtering on reso=
urce
> JRD is not a totally new topic.
> >
> > LRDD is the one really doing the optimization  in any event,  it may be=
 done
> at the host-meta GET but it is a LRDD specific extension.
> > Having it in the template allows LRDD to filter at the resource JRD in =
cases
> where it is not possible to do it at the host-meta level, due to some no =
script
> or other restriction.
> >
> > I agree that it should be filtered at the how-meta request but you and
> others say that is not always possible.
> >
> > John B.
> >
> >
> >
> >
> > On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
> >
> >
> > John,
> >
> > The "rel" parameter is something we still need to discuss, so not is as=
 good
> a time as any.
> >
> > What "rel" does is act as a filter.  For the most part, the only purpos=
e it
> serves is to help reduce the number of link relations that might be sent =
from
> the server.  So, if a user had 1,000 different link relations, this might=
 reduce
> the returned message to containing only 1.  However, if a user has more t=
han
> one link relation of the same type, all of them would match and be return=
ed.
> >
> > When you say the host cannot support re-write rules, I assume you mean =
it
> does not support the URI parameters on host-meta?  In that case, yes, the
> parameters are ignored and you get just the host-meta document.
> >
> > The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1).  Th=
ere are
> no other URI template values defined.  (Note: this whole section exists o=
nly
> because RFC  6570 did not yet exist, I think.
> >
> > In any case, we could define a new URI template, but then we would be
> putting an optimization in place for LRDD.  If host-meta is not going to
> support the "rel" URI parameter, why would LRDD?  It would also mean that
> the LRDD logic would have to be ready to receive a URI parameter that is =
not
> replaced, since some clients would only change {uri} and leave {rel} ther=
e.
> That would introduce more conditional logic in the server.  This would al=
so
> present issues with static sites.  (Of course, one might be able to use A=
pache
> re-writing rules to get around that problem, but it certainly would not w=
ork
> for "real" static sites.)
> >
> > Personally,  I'd prefer to not add the "rel" parameter to LRDD, since I=
 think
> optimization using "rel" would always be done on host-meta.  That said, I
> question the value of "rel" entirely.  Do you think it's useful to have t=
his filter
> at all?  Is there really a risk that a site might return 1,000 link relat=
ions that the
> client would have to step over?
> >
> > Paul
> >
> > From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> > Sent: Tuesday, April 24, 2012 10:17 PM
> > To: Paul E. Jones
> > Cc: apps-discuss@ietf.org
> > Subject: WF flow with rel parameter
> >
> > Paul,
> >
> > Sorry I hit send on the previous message with a typo.
> >
> > I am looking at how the flows in WF might work for openID.
> >
> > Let's set aside the XML issue for the moment and focus on the JSON flow=
.
> >
> > Please correct anything I get wrong.
> >
> > The openID Connect defines a relation of
> http://openid.net/specs/connect/issuer
> >
> > WF allows for a JSON host-meta that takes two parameters, "resource" an=
d
> "rel"
> >
> > An example request and response (line-brakes for readability)
> >
> > GET /.well-known/host-meta.json
> >      ?resource=3Djoe@example.com
> >      &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> HTTP/1.1
> >  Host: example.com
> >
> >    HTTP/1.1 200 OK
> >
> >    Access-Control-Allow-Origin: *
> >    Content-Type: application/json; charset=3DUTF-8
> >
> >    {
> >      "subject" : "joe@example.com",
> >      "links" :
> >      [
> >        {
> >          "rel" : "http://openid.net/specs/connect/issuer",
> >          "href" : "https://server.example.com"
> >        }
> >      ]
> >    }
> >
> > If the host can't support rewrite rules or scripts the exchange would l=
ook
> like:
> >
> > GET /.well-known/host-meta.json
> >      ?resource=3Djoe@example.com
> >      &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> HTTP/1.1
> >  Host: example.com
> >
> > HTTP/1.1 200 OK
> >    Access-Control-Allow-Origin: *
> >    Content-Type: application/json; charset=3DUTF-8
> >    {
> >      "expires" : "2012-03-13T20:56:11Z",
> >      "links" :
> >      [
> >        {
> >          "rel" : "lrdd",
> >          "type" : "application/json",
> >          "template" :
> >            "https://example.com/lrdd/?format=3Djson&resource=3D{uri}"
> >        }
> >
> > GET /lrdd/
> >      ?format=3Djson
> >      &resource=3Djoe@example.com
> >  Host: example.com
> >
> > HTTP/1.1 200 OK
> >
> >    Access-Control-Allow-Origin: *
> >    Content-Type: application/json; charset=3DUTF-8
> >
> >    {
> >      "subject" : "joe@example.com",
> >      "links" :
> >      [
> >        {
> >          "rel" : "http://openid.net/specs/connect/issuer",
> >          "href" : "https://server.example.com"
> >        },
> >        {
> >          "rel" : "http://webfinger.net/rel/avatar",
> >          "href" : "http://example.com/~joe/joe.jpg"
> >        }
> >
> >      ]
> >    }
> >
> > I can't find a template parameter for "rel".  The host-meta spec allows=
 for
> extension but it is missing.
> >
> > What if the server wants to support filtering on rel but can't support =
it in
> the root for some reason?
> >
> > Is it possible to have a template like:
> > "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}"
> >
> > That simple addition may solve a number of problems for openID.
> >
> > John B.
> >
> >
> >


From sm@resistor.net  Wed Apr 25 09:59: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 0660821F87D4 for ; Wed, 25 Apr 2012 09:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.543
X-Spam-Level: 
X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBqXMg1BNB05 for ; Wed, 25 Apr 2012 09:59:34 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 714D121F87A9 for ; Wed, 25 Apr 2012 09:59:34 -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 q3PGxPt1006195; Wed, 25 Apr 2012 09:59:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335373170; i=@resistor.net; bh=Rxfm3mxYA4LxXiAg5EIpgMZgZUJLOlsJV979e0Ivozw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vJUbiaQwqIVGNBD9w9OlO6pFc0oEa7XoVJW1sb5Ce+9Aathegad+J5N1mlbIzaDp7 98gfpTgrimdc3/Vn7InIUWUyWvUup2ee/t9D/ONboeuAKappR+T42GS9wLiOPoysxq Q+I/lrBoixhbJ/mkQNum98VwiJIEEPnEdV1mEf1k=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1335373170; i=@resistor.net; bh=Rxfm3mxYA4LxXiAg5EIpgMZgZUJLOlsJV979e0Ivozw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=S9srO9NGotcT2THK330zHknQm1sVKZ+zxenT2CMJr4xzaF5vcrko+FZ+y0WgpJ6w7 Df52ex1g/pd+2uofqS38uzhlzIiNwYpBvkeSZnzvRfdchgUck3kekyy5KAIjOk5BQh +tRasWeJppJp7VaUwOCOy17bx8jqWBFGLs0tsGPI=
Message-Id: <6.2.5.6.2.20120425095148.0a7f0bf0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 25 Apr 2012 09:58:25 -0700
To: Barry Leiba 
From: SM 
In-Reply-To: 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On citations in general
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 16:59:39 -0000

Hi Barry,
At 08:06 25-04-2012, Barry Leiba wrote:
>While I'm on the topic of citations, let me throw something out to
>this crowd before sending it to the general IETF discussion list.

Peter already commented on rfc-interest.

>There are various styles of using citations, and various strongly held
>opinions about which ones are good, which evil, and which lie
>somewhere between.  I don't want to make this a religious argument,
>though I'm pretty sure it will be that, but here:

It's unfortunately going to turn into one.

>I consider that a citation in the text serves two purposes.  One is to
>explain where the information came from, and the other is to make it
>easy to get to the cited document.  As cute as it may be to say things
>like, "To use items defined in [EMAIL], one must additionally...", I
>find that it's not very helpful when I reading documents.

Yes.

>What I prefer to see -- what helps me the most as a reader -- is both
>short text and an RFC number.  Often, if the short text is properly
>chosen, I don't have to look at the referenced document at all.  And
>when I do, I can find it immediately from the RFC number in the
>citation, without having to bounce to the bottom of the doc and look
>at the references.  Of course, if there are repeated citations, I
>don't expect every one to have the full thing, and just the RFC
>citation is enough.

I find that having the RFC number makes the text for some RFCs more readable.

>It's also sometimes very useful to have section numbers in the
>citations, when one needs to be referred to a specific point in the
>cited document.  Consider this, from one of the httpbis documents:

Yes, especially for a long document.

BTW, this is more of a matter of style.

Regards,
-sm 


From stpeter@stpeter.im  Wed Apr 25 10:03: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 C8A2321F87DB for ; Wed, 25 Apr 2012 10:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.608
X-Spam-Level: 
X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ny8ok4OwvIZa for ; Wed, 25 Apr 2012 10:03:38 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3230421F87D4 for ; Wed, 25 Apr 2012 10:03:38 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D057340058; Wed, 25 Apr 2012 11:18:13 -0600 (MDT)
Message-ID: <4F982E68.6080207@stpeter.im>
Date: Wed, 25 Apr 2012 11:03:36 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: SM 
References:  <6.2.5.6.2.20120425095148.0a7f0bf0@resistor.net>
In-Reply-To: <6.2.5.6.2.20120425095148.0a7f0bf0@resistor.net>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Barry Leiba , apps-discuss@ietf.org
Subject: Re: [apps-discuss] On citations in general
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 17:03:38 -0000

On 4/25/12 10:58 AM, SM wrote:

> BTW, this is more of a matter of style.

Exactly. And the RFC Editor Style Guide is being updated even as we
speak. Thus this is relevant for the rfc-interest list.

Peter

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



From ajs@anvilwalrusden.com  Wed Apr 25 10:26: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 9C56421F8671 for ; Wed, 25 Apr 2012 10:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level: 
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=-0.351,  BAYES_00=-2.599, J_CHICKENPOX_65=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB+DItfV+7uK for ; Wed, 25 Apr 2012 10:26:33 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id A69EE21F8649 for ; Wed, 25 Apr 2012 10:26:33 -0700 (PDT)
Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D51DF1ECB41C for ; Wed, 25 Apr 2012 17:26:32 +0000 (UTC)
Date: Wed, 25 Apr 2012 13:26:30 -0400
From: Andrew Sullivan 
To: apps-discuss@ietf.org
Message-ID: <20120425172555.GM60024@mail.yitter.info>
References:  <6.2.5.6.2.20120425095148.0a7f0bf0@resistor.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6.2.5.6.2.20120425095148.0a7f0bf0@resistor.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [apps-discuss] On citations in general
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 17:26:34 -0000

On Wed, Apr 25, 2012 at 09:58:25AM -0700, SM wrote:
> BTW, this is more of a matter of style.

And consequently of religion.  I'd prefer that we not talk about it,
either here or on rfc-i, since in both cases I think we will explore
every rathole possible (and some impossible ones) involving Fowler
vs. Strunk&White, MLA vs. Chicago, involving whatever
your 3d grade teacher said even though s/he couldn't write worth a
tinker's dam (yes, that's how it's spelled), and the Oxford comma and
requirements for its use.  I have the Gowers edition Fowler on my
book-shelf, and I am as happy to waive it about as the next person.
But I don't think we're going to be more productive that way.

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

From ve7jtb@ve7jtb.com  Wed Apr 25 10:37: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 B98E521F8830 for ; Wed, 25 Apr 2012 10:37:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.476
X-Spam-Level: 
X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d34YVgz8qVYU for ; Wed, 25 Apr 2012 10:37:46 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4559421F86AD for ; Wed, 25 Apr 2012 10:37:43 -0700 (PDT)
Received: by yenm5 with SMTP id m5so382522yen.31 for ; Wed, 25 Apr 2012 10:37:42 -0700 (PDT)
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=sfhP8oXpSnKvZx1xWj0qeSHHxGAsfz/AoOpwlE0WNL8=; b=mxNJ2AWBBndSbeZS8gcDDc4vvdmBOXPIep6iRIxWu3x4NF+yWWRfegKxvj+fg/QGsV 88Cw/kd4NZGstinmzauRokFx+morf4dS12o+gRNT/eCUIIjm6qwTTRnITeVC5mR5Pchg 60CrKgw9mt2tLaz9ieQcwD/01rlsCpuWdTCcU1keEJufII8iZ52BgkQfMO/Tdaj1/Vh8 sGSlhjEoJB2UP0G7YorixaJzbBBsCUpuIaXym1grNJEqXV5rg0yafZTR10nzOHPXieka a5CW8Um3w5vpdyVViDOSEWKNh8ipp8mFVBx52FHF+yAUuWLp5ayx0hs/+QG1f4q+21NM 3LAg==
Received: by 10.236.109.197 with SMTP id s45mr3311410yhg.64.1335375462721; Wed, 25 Apr 2012 10:37:42 -0700 (PDT)
Received: from [192.168.1.213] (190-20-63-108.baf.movistar.cl. [190.20.63.108]) by mx.google.com with ESMTPS id p15sm248961ani.15.2012.04.25.10.37.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 10:37:40 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_4F6E9745-0509-4B03-99E0-B28662A6B23F"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20100990A@P3PWEX2MB008.ex2.secureserver.net>
Date: Wed, 25 Apr 2012 14:37:32 -0300
Message-Id: 
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201007020@P3PWEX2MB008.ex2.secureserver.net> <515663DA-67BF-4367-9AD9-6E940424CBCD@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20100990A@P3PWEX2MB008.ex2.secureserver.net>
To: Eran Hammer 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQk5Iv58PkebV2p+io0Xj9dPJmwAgKxLOLVz/Dr36lZXPGD7Ywk25VqMG4LIo4cfLB2XpBfC
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 17:37:47 -0000

--Apple-Mail=_4F6E9745-0509-4B03-99E0-B28662A6B23F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Eran,

It was unclear, at least to me that the server side host-meta processing =
rule specified in WF requires all the templates (or just the LRDD ones) =
to be processed substituting inserting "resource" for URI and then =
retrieving and merging all the resource JRD before processing the filter =
on the "rel".

If I defined a rel of FOO would WF fill the template and retrieve the =
JRD and merge its links with the lrdd JRD?
I might think that would be a touch confusing to clients.

So I go back to the rational explanation that lrdd templates are =
expanded and those links rolled up and filtered.

Now I am guessing that some of the SWD people are thinking that when the =
server is using flat files that puts a lot of burden onto the client.

Probably why you added the server side processing.

Given that WF takes the liberty of adding query parameters to host-meta =
and seems to define host-meta processing rules (perhaps for non lrdd?), =
I am not finding the separation of the two specs as clean as possible.
It seems a bit like there is there a RFC 6415 dependency on WF.  Though =
that is a touch strange for a RFC.

What stops someone from defining a relation of super-discovery and =
adding some query parameters to host-meta.json to hover up some lrdd =
based on a template expansion of  "super-discovery" rel types, and =
filter on "rel"?

I wouldn't have thought to do that because stepping on the RFC 6415 =
endpoint seems slightly wrong to me.

I would probably define a new endpoint /.well-known/super-discovery with =
my own query parameters and processing rules for JRD documents.=20

Without being able to make server-side processing of host-meta required, =
 we need someway to delegate that to another endpoint. =20

In XRD we did discuss delegating the entire XRD.  Is there a way to do =
that in host-meta?

At the moment all of the processing gets pushed back on the client if =
the host only supports static files in /.well-known

John B.



On 2012-04-25, at 1:34 PM, Eran Hammer wrote:

> It is important to understand the semantics of host-meta, which I =
think there is some confusion about here.
>=20
> As a mechanism, host-meta providers you with a method of obtaining =
both host-wide and resource-specific links (and properties). To =
accomplish that, it provides with both a document and processing rules.
>=20
> WebFinger - the name given for the host-meta *use-case* of retrieving =
user information - is a specialization of obtaining resource-specific =
links.
>=20
> The 'rel' and 'resource' query parameters (as proposed) apply to the =
endpoint *after* executing the processing rules (which include expanding =
templates and importing links from one level LRDD documents).
>=20
> LRDD documents only apply to resource-specific links, which means they =
are ignored for any host-wide query. For example, the location of the =
site's TOS document. =46rom the host-meta perspective, LRDD documents =
are just a deployment tool to provide customization not possible using =
just link templates at the host-meta document level. It's just a =
link-include mechanism, and host-meta uses it restrictively.
>=20
> IMO, the 'rel' and 'resource' optimization should only apply to the =
host-meta endpoint, and act as a filter post the processing rules. If =
'resource' is specified, it is a resource-specific request, otherwise, =
host-wide.
>=20
> Let me know if this helps or if it is still unclear.
>=20
> EH
>=20
>=20
>=20
>=20
>> -----Original Message-----
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>> Sent: Wednesday, April 25, 2012 8:27 AM
>> To: Eran Hammer
>> Cc: Paul E. Jones; apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>=20
>> That was one thing that initially confused me.  The rel filter is not =
applied to
>> host-meta, but rather the linked lrdd resource JRD.
>>=20
>> The currently defined "resource" parameter has an implicit host-meta =
"rel"
>> of "lrdd".
>>=20
>> To use this mechanism for other relations you would need to make that
>> parameter explicit.
>>=20
>> That then raises the question of the filter being part of host-meta =
or WF if it
>> applies to relationships other than lrdd.
>>=20
>> If you are asking if filtering should be supported by lrdd where you =
start
>> discovery from a link header, then it probably should be possible as =
well.
>>=20
>> Though I thought lrdd stopped being updated over a year a year ago.   =
Sorry if
>> I am out of date.
>>=20
>> So XRD/JRD documents SHOULD be filterable by "rel" independent of if =
you
>> get to them via lrdd or host-meta.
>>=20
>> Host-meta SHOULD support a mechanism to filter by "rel" or filter by =
a
>> combination of "resource" (uri) , host-meta-rel and resource-rel (the =
host-
>> meta-rel is currently implicit.)
>>=20
>> I recall discussing this in the XRI TC when we did XRD years ago, =
though that
>> was more around using XRI identifiers.
>>=20
>> The same principal still holds.  I should be able to ask for.
>> GET /.well-known/host-meta.json
>>     ?resource=3Djoe@example.com
>>     &host-meta-rel=3Dlrdd
>>     &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>> HTTP/1.1
>> Host: example.com
>>=20
>> (personally I think calling the parameter "resource" and the template =
{uri}
>> will be confusing to people)
>>=20
>> In SWD we used fixed the parameter names and the base URI is the part =
that
>> gets changed when the /.well-known can't host a script.
>> That makes the template simpler for the client to process.  The =
equivalent to
>> "rel" is always passed to make processing simpler.
>>=20
>> As Blaine has pointed out several times SWD and WF largely get us to =
the
>> same place.
>>=20
>> I am trying to find a way to close the gap.
>>=20
>> John B.
>>=20
>>=20
>> On 2012-04-25, at 11:41 AM, Eran Hammer wrote:
>>=20
>>> Purely from a practical standpoint, do you think it is likely that a =
server will
>> support the query filter for the lrdd documents but not for =
host-meta?
>>>=20
>>> EH
>>>=20
>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>> bounces@ietf.org] On Behalf Of John Bradley
>>> Sent: Wednesday, April 25, 2012 6:17 AM
>>> To: Paul E. Jones
>>> Cc: apps-discuss@ietf.org
>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>=20
>>> Paul,
>>>=20
>>> "rel" as a filter is something WF has for host-meta.  It however =
doesn't
>> seem to have that for user JRD in the case where host-meta is =
returned, and
>> the template is used.
>>>=20
>>> The "resource" and "rel" parameters are already an optimization for =
LRDD
>> and not part of host-meta.
>>> Adding LRDD specific parameters to host-meta/host-meta.json will
>> probably raise some eyebrows in review, but I am OK with it.
>>>=20
>>> I think there are use cases where size matters.  Where a host-meta =
or
>> resource JRD may be large and it is more efficient not to send the =
whole
>> thing to a mobile client.
>>> It seems to be one of Mike Jones requirements.
>>>=20
>>> Using RFC6570 for LRDD is a possibility for passing through the =
filter request
>> for sites that support filtering on resource JRD.
>>>=20
>>> What other proposals do you have.  I am guessing that filtering on =
resource
>> JRD is not a totally new topic.
>>>=20
>>> LRDD is the one really doing the optimization  in any event,  it may =
be done
>> at the host-meta GET but it is a LRDD specific extension.
>>> Having it in the template allows LRDD to filter at the resource JRD =
in cases
>> where it is not possible to do it at the host-meta level, due to some =
no script
>> or other restriction.
>>>=20
>>> I agree that it should be filtered at the how-meta request but you =
and
>> others say that is not always possible.
>>>=20
>>> John B.
>>>=20
>>>=20
>>>=20
>>>=20
>>> On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
>>>=20
>>>=20
>>> John,
>>>=20
>>> The "rel" parameter is something we still need to discuss, so not is =
as good
>> a time as any.
>>>=20
>>> What "rel" does is act as a filter.  For the most part, the only =
purpose it
>> serves is to help reduce the number of link relations that might be =
sent from
>> the server.  So, if a user had 1,000 different link relations, this =
might reduce
>> the returned message to containing only 1.  However, if a user has =
more than
>> one link relation of the same type, all of them would match and be =
returned.
>>>=20
>>> When you say the host cannot support re-write rules, I assume you =
mean it
>> does not support the URI parameters on host-meta?  In that case, yes, =
the
>> parameters are ignored and you get just the host-meta document.
>>>=20
>>> The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1).  =
There are
>> no other URI template values defined.  (Note: this whole section =
exists only
>> because RFC  6570 did not yet exist, I think.
>>>=20
>>> In any case, we could define a new URI template, but then we would =
be
>> putting an optimization in place for LRDD.  If host-meta is not going =
to
>> support the "rel" URI parameter, why would LRDD?  It would also mean =
that
>> the LRDD logic would have to be ready to receive a URI parameter that =
is not
>> replaced, since some clients would only change {uri} and leave {rel} =
there.
>> That would introduce more conditional logic in the server.  This =
would also
>> present issues with static sites.  (Of course, one might be able to =
use Apache
>> re-writing rules to get around that problem, but it certainly would =
not work
>> for "real" static sites.)
>>>=20
>>> Personally,  I'd prefer to not add the "rel" parameter to LRDD, =
since I think
>> optimization using "rel" would always be done on host-meta.  That =
said, I
>> question the value of "rel" entirely.  Do you think it's useful to =
have this filter
>> at all?  Is there really a risk that a site might return 1,000 link =
relations that the
>> client would have to step over?
>>>=20
>>> Paul
>>>=20
>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>> Sent: Tuesday, April 24, 2012 10:17 PM
>>> To: Paul E. Jones
>>> Cc: apps-discuss@ietf.org
>>> Subject: WF flow with rel parameter
>>>=20
>>> Paul,
>>>=20
>>> Sorry I hit send on the previous message with a typo.
>>>=20
>>> I am looking at how the flows in WF might work for openID.
>>>=20
>>> Let's set aside the XML issue for the moment and focus on the JSON =
flow.
>>>=20
>>> Please correct anything I get wrong.
>>>=20
>>> The openID Connect defines a relation of
>> http://openid.net/specs/connect/issuer
>>>=20
>>> WF allows for a JSON host-meta that takes two parameters, "resource" =
and
>> "rel"
>>>=20
>>> An example request and response (line-brakes for readability)
>>>=20
>>> GET /.well-known/host-meta.json
>>>     ?resource=3Djoe@example.com
>>>     &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>> HTTP/1.1
>>> Host: example.com
>>>=20
>>>   HTTP/1.1 200 OK
>>>=20
>>>   Access-Control-Allow-Origin: *
>>>   Content-Type: application/json; charset=3DUTF-8
>>>=20
>>>   {
>>>     "subject" : "joe@example.com",
>>>     "links" :
>>>     [
>>>       {
>>>         "rel" : "http://openid.net/specs/connect/issuer",
>>>         "href" : "https://server.example.com"
>>>       }
>>>     ]
>>>   }
>>>=20
>>> If the host can't support rewrite rules or scripts the exchange =
would look
>> like:
>>>=20
>>> GET /.well-known/host-meta.json
>>>     ?resource=3Djoe@example.com
>>>     &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>> HTTP/1.1
>>> Host: example.com
>>>=20
>>> HTTP/1.1 200 OK
>>>   Access-Control-Allow-Origin: *
>>>   Content-Type: application/json; charset=3DUTF-8
>>>   {
>>>     "expires" : "2012-03-13T20:56:11Z",
>>>     "links" :
>>>     [
>>>       {
>>>         "rel" : "lrdd",
>>>         "type" : "application/json",
>>>         "template" :
>>>           "https://example.com/lrdd/?format=3Djson&resource=3D{uri}"
>>>       }
>>>=20
>>> GET /lrdd/
>>>     ?format=3Djson
>>>     &resource=3Djoe@example.com
>>> Host: example.com
>>>=20
>>> HTTP/1.1 200 OK
>>>=20
>>>   Access-Control-Allow-Origin: *
>>>   Content-Type: application/json; charset=3DUTF-8
>>>=20
>>>   {
>>>     "subject" : "joe@example.com",
>>>     "links" :
>>>     [
>>>       {
>>>         "rel" : "http://openid.net/specs/connect/issuer",
>>>         "href" : "https://server.example.com"
>>>       },
>>>       {
>>>         "rel" : "http://webfinger.net/rel/avatar",
>>>         "href" : "http://example.com/~joe/joe.jpg"
>>>       }
>>>=20
>>>     ]
>>>   }
>>>=20
>>> I can't find a template parameter for "rel".  The host-meta spec =
allows for
>> extension but it is missing.
>>>=20
>>> What if the server wants to support filtering on rel but can't =
support it in
>> the root for some reason?
>>>=20
>>> Is it possible to have a template like:
>>> "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}"=

>>>=20
>>> That simple addition may solve a number of problems for openID.
>>>=20
>>> John B.
>>>=20
>>>=20
>>>=20
>=20


--Apple-Mail=_4F6E9745-0509-4B03-99E0-B28662A6B23F
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
NTE3MzczM1owIwYJKoZIhvcNAQkEMRYEFPIUtO9Va4/sLzBClUD80cQkstxIMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
ABE1yWSSZwRR5vkp1PvLeY1+moMQNfQ5gWQxSZGTfNszx6wSjshjs2An3EiCAVzYQwIUtjWa0s0n
2oMLaSzQpN7x0kfC+D+EJBgRE6HjLwh5V7lPz3BCaYVUZqYvCeAyh0Kie0NA+RSv/xtG3c91Y4H/
kgIpMyQmG9ZQ6OYdQkYs1EXXHHoVkmLfLqRXJVLv5ofgFPYWD3qG7VdWym5WOYYeRS9IcDQpYUZ3
IEj7w0bEgI6b0bEARkyh4WBimgx4KgtPfByXWzUUfSIMuB5aF2QXjMrvTL7uDzalBSPCNMR9yguc
iHF93qspA94qn1VHWPX/PhRp1ZR7yFlyGQN9664AAAAAAAA=

--Apple-Mail=_4F6E9745-0509-4B03-99E0-B28662A6B23F--

From romeda@gmail.com  Wed Apr 25 11:09: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 5AF2121F881C for ; Wed, 25 Apr 2012 11:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.516
X-Spam-Level: 
X-Spam-Status: No, score=-103.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ReY+rN2sG5X for ; Wed, 25 Apr 2012 11:09:49 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 87D2621F873C for ; Wed, 25 Apr 2012 11:09:49 -0700 (PDT)
Received: by lagj5 with SMTP id j5so329649lag.31 for ; Wed, 25 Apr 2012 11:09:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+0R+lhPjolu3jpCQiuRhK4opfOcNgQg2ZYlRyJMs808=; b=z+clQo2a2wzAXPisrAfD9YsFjm84oo3pO6nnJ8VPrqWMTYTPfUwwOf5K2En+38jnBn OvYwWQnu92ILskEBSb/meKZZMrMOdn8wII3oOrk+9J9Fuhew47Bs0jCnoFIZS3rJSAvJ 2KFrRqLqR3fcqYMA7eRfcY+kkezHnt0ocmn12oDMJ7tMRg3rrWQ/tP+9Ni5BFEPr7lfA 6sHU9kLO78EoOTr5jCOeZxP8uYC5M4k9XcJisHDqzw6iHMoVZCL0urjC24LlU7dgiq4/ NhL7SQ6j8+S6Zt4ErDZz3oDNgsWvy7tw7AXH4qstFV7ELZNTNOoQZ2k8LnqKqGwrmucy 3c5A==
Received: by 10.152.105.241 with SMTP id gp17mr3920051lab.21.1335377388244; Wed, 25 Apr 2012 11:09:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.24.229 with HTTP; Wed, 25 Apr 2012 11:09:28 -0700 (PDT)
In-Reply-To: 
References:   
From: Blaine Cook 
Date: Wed, 25 Apr 2012 19:09:28 +0100
Message-ID: 
To: Barry Leiba 
Content-Type: multipart/alternative; boundary=f46d0407152bde0ff004be84c68f
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On citations in general
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 18:09:50 -0000

--f46d0407152bde0ff004be84c68f
Content-Type: text/plain; charset=UTF-8

Why not just use links as Tim suggests with descriptive text in the content
of the anchor? I don't see how offline reading is a blocker.

b.

On 25 April 2012 16:35, Barry Leiba  wrote:

> > If only there were a technology which allowed citations to be made
> > actual actionable usable links directly to the targeted source.
>
> Yeh, eliminating your biting sarcasm: we're often reviewing these
> things offline, and sometimes even from printed text.  Not having to
> flip back and forth can be useful.
>
> Barry
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--f46d0407152bde0ff004be84c68f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Why not just use links as Tim suggests with desc=
riptive text in the content of the anchor? I don't see how offline read=
ing is a blocker.



b.

On 25 April 2012 16:35, Barry Leiba <barryleiba@computer.org> wrote:



> If only there were a technology which allowed citati=
ons to be made

> actual actionable usable links directly to the targeted source.




Yeh, eliminating your biting sarcasm: we're often reviewing these=


things offline, and sometimes even from printed text. =C2=A0Not having to
flip back and forth can be useful.




Barry

_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--f46d0407152bde0ff004be84c68f--

From paulej@packetizer.com  Wed Apr 25 11:23: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 D532821F87FA for ; Wed, 25 Apr 2012 11:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.394
X-Spam-Level: 
X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.204,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnUuCeYhxdnc for ; Wed, 25 Apr 2012 11:23:10 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1544D21F883B for ; Wed, 25 Apr 2012 11:23:10 -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 q3PIN6F2029539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Apr 2012 14:23:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335378187; bh=WLQqOab09h3IyRCAexHUTLeolEc53Dr8hBt7Q1pdAfU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Z9eECRCzd59MHnyZWSA2kKM5iieD0H0g+vTAPBGq5jEeIZhsDfFjV0HRNzLniMCJ6 ndj7WD4WNyrDPR8/2QHl1buL/98e5/urzN3pZsliBAKQFWzYC9vOkCOIh6m0Mn9P7H QvA41RreeE+7B3Z+fFGPLbXlpLblPJrXO4vLwcT4=
From: "Paul E. Jones" 
To: "'William Mills'" , "'Mike Jones'" , "'Blaine Cook'" , 
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <1335194949.12040.YahooMailNeo@web31812.mail.mud.yahoo.com>
In-Reply-To: <1335194949.12040.YahooMailNeo@web31812.mail.mud.yahoo.com>
Date: Wed, 25 Apr 2012 14:23:14 -0400
Message-ID: <053c01cd2310$7aea0b60$70be2220$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_053D_01CD22EE.F3DAB550"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIJGNvIkGmsH/dlhis4V9nZDOGpGAEfNpTdlirz3XA=
Content-Language: en-us
Subject: Re: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD Issue	#3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 18:23:12 -0000

This is a multipart message in MIME format.

------=_NextPart_000_053D_01CD22EE.F3DAB550
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Bill,

=20

Host-meta.json was introduced in RFC 6415 as a means of selecting JSON, =
particularly when the client does not have the ability to indicate via =
the =E2=80=9CAccept=E2=80=9D header that it wants =
=E2=80=9Capplication/json=E2=80=9D.  On my server, I return XML by =
default.  I also honor the =E2=80=9CAccept=E2=80=9D header and return =
the type requested.  And, I support host-meta.json, which will return =
JSON by default (i.e., =E2=80=9CAccept=E2=80=9D is =
=E2=80=9C*/*=E2=80=9D), but I still honor the =E2=80=9CAccept=E2=80=9D =
header.  I always given preference to the Accept header, which I think =
is appropriate, though not explicitly documented anywhere.  This is =
where the =E2=80=9Chack=E2=80=9D part comes in.  One should honor what =
HTTP says, but then how to we treat a request based on the URI path?  =
Not sure, but I=E2=80=99m inclined to leave it that way until somebody =
tells me why it=E2=80=99s a bad idea.

=20

In any case, this was not invented as a part of the current draft; it =
was already defined.

=20

Paul

=20

From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of William Mills
Sent: Monday, April 23, 2012 11:29 AM
To: Mike Jones; Blaine Cook; apps-discuss@ietf.org
Subject: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD =
Issue #3: direct versus indirect discovery

=20

I note that some examples are now using the construct (Eran called it a =
hack, which it probably is, but I like it) host-meta.json to select the =
data format.  This seems to me to be a workable way to:

=20

-    extend the current WF stuff keeping compatibility=20

-    support for JSON without funky logic

-    allow the clients to implement a single simple code path

=20

-bill

=20


  _____ =20


From: Mike Jones 
To: Blaine Cook ; "apps-discuss@ietf.org" =
=20
Sent: Sunday, April 22, 2012 9:11 PM
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus =
indirect discovery

=20

I agree with your goal of simplicity for clients.  Paul=E2=80=99s =
example seems about as simple as it can get for clients:

               curl -v =
https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paulej@=
packetizer.com

It shares the property with your earlier example (below) that clients =
have a no-branches code path to do discovery:

               curl -s http://example.com/.well-known/host-meta| =
=20

               awk "/lrdd/,/template/"|tr -d '\n'|sed -e =
"s/^.*template=3D'\([^']*\)'.*$/\1/"|

               sed -e "s/{uri}/user@example.com/ =
 "|xargs curl =E2=80=93s

=20

However, I challenge the assumption in your note below that servers =
using only static pages must be supported.  I just don=E2=80=99t see the =
requirement to implement a query parameter as being an impediment in =
practice, even for hosted domains.  I know of no hosting company that =
doesn=E2=80=99t provide a means of putting executable code behind web =
pages, be it PHP, Perl, Ruby, ASP, JSP, etc.  I know you=E2=80=99re =
trying to make the case for static pages, but in practice, I believe =
that dynamic pages are always easily available.

=20

Assuming that we=E2=80=99re in an either-or situation with regard to =
either having single-GET discovery or supporting discovery using only =
static server pages (and I=E2=80=99d love to have someone demonstrate to =
us that we=E2=80=99re not), I=E2=80=99d take single-GET discovery for =
sure, as in some cases, it makes an appreciable difference in user =
interface latency, and per the paragraph above, I believe that dynamic =
queries can be implemented on all hosting platforms.

=20

Assuming the WebFinger authors agree, I=E2=80=99d suggest that a logical =
next step would be for a -04 version of draft-jones-appsawg-webfinger to =
be published that changes support for the resource parameter from =
RECOMMENDED to REQUIRED, as that could provide a starting point for a =
common discovery spec.

=20

                                                            -- Mike

 =20

P.S.  As long as draft-jones-appsawg-webfinger is being revised, =
I=E2=80=99d also suggest adding text making explicit what has been an =
implicit assumption in both WebFinger and SWD - that depending upon =
whether and how the client is authenticated, the set of resources =
returned may vary (as Blaine had pointed out earlier).  That could help =
deal with some of the privacy perceptions.

=20

From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of Blaine Cook
Sent: Sunday, April 22, 2012 2:15 PM
To: apps-discuss@ietf.org
Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect =
discovery

=20

This is the last issue that I've flagged as blocking a new Webfinger / =
SWD draft.

=20

Mike suggested that being able to request a user's profile with a single =
request (i.e., that the /.well-known/ profile resource should be able to =
respond with full profile data immediately, rather than pointing at a =
second URL that will fulfil the request) is a requirement for this =
standard.

=20

I'd like to challenge that requirement. The arguments for a direct =
discovery endpoint are:

=20

1. Fewer requests against the server, since we save (in the worst-case) =
50% of requests by bypassing the indirect lookup phase.

2. Lower latency for clients (e.g., mobile clients) owing to the reduced =
number of lookups.

=20

The arguments for an indirect discovery endpoint are:

=20

1. Trivial and web-standards friendly deployment for domains that won't =
host their own webfinger/swd profile servers, but want to enable =
accounts on their domains (e.g., statically hosted sites).

2. A loosening of the requirement that URLs at the bare domain must run =
dynamic scripts that respond to requests to the /.well-known/ path.

=20

My opinion is that the approach that SWD has proposed for the redirect =
is problematic. First, the format is very similar in form to the HTML =
"meta refresh" tag that provided HTTP redirect support from within HTML. =
That format has been widely deprecated, and in these more enlightened =
times, we just use the 3xx response codes with Location headers, =
instead.

=20

Secondly, the SWD request format means that for smaller sites, often =
those with the least resources, will end up serving static content in a =
way that's difficult to cache; certainly, more difficult to cache than =
just serving static content. This is due to the request parameters =
present in all SWD requests; those request parameters will bust caches.

=20

As for the first argument *for* SWD's approach, I'd suggest we look to =
DNS, which uses the same indirection approach for NS records, relying on =
a (relatively) very small set of root servers to handle the traffic for =
the whole internet. Clearly, this approach works, and webfinger/swd =
servers are in a much better position to handle this additional traffic. =
Most of this traffic will be heavily cached, especially for the largest =
providers.

=20

In fact, in terms of real deployments, hosting a script at, e.g., =
google.com/.well-known/simple-web-discovery is much harder than hosting =
a script at profiles.google.com/profile.json for all sorts of reasons, =
so it's my belief that the first argument is a red herring.

=20

The second argument is legitimate, but only if mobile clients will =
actually be making requests to diverse webfinger/swd hosts. Instead, I =
strongly believe that we'll see the emergence of DNS-like servers that =
provide both profile hosting as well as proxy services. For a mobile =
client, the optimal approach will be to use SPDY to connect to a single =
host that performs webfinger/swd lookups on the mobile client's behalf, =
eliminating the latency concerns.

=20

I offer that the two-step lookup can be implemented without conditionals =
on the client, whereas the direct-unless-not approach cannot be =
implemented that way (see my earlier curl example for proof). It's =
simpler, and easier to explain to the (hopefully many) small site owners =
who we'd like to implement this technology.

=20

Thoughts? Am I missing something?

=20

b.


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




------=_NextPart_000_053D_01CD22EE.F3DAB550
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Bill,
 
Host-meta.json was introduced in RFC 6415 as a means of selecting =
JSON, particularly when the client does not have the ability to indicate =
via the =E2=80=9CAccept=E2=80=9D header that it wants =
=E2=80=9Capplication/json=E2=80=9D.=C2=A0 On my server, I return XML by =
default.=C2=A0 I also honor the =E2=80=9CAccept=E2=80=9D header and =
return the type requested.=C2=A0 And, I support host-meta.json, which =
will return JSON by default (i.e., =E2=80=9CAccept=E2=80=9D is =
=E2=80=9C*/*=E2=80=9D), but I still honor the =E2=80=9CAccept=E2=80=9D =
header.=C2=A0 I always given preference to the Accept header, which I =
think is appropriate, though not explicitly documented anywhere.=C2=A0 =
This is where the =E2=80=9Chack=E2=80=9D part comes in.=C2=A0 One should =
honor what HTTP says, but then how to we treat a request based on the =
URI path?=C2=A0 Not sure, but I=E2=80=99m inclined to leave it that way =
until somebody tells me why it=E2=80=99s a bad =
idea.
 
In any case, this was not invented as a part of the current draft; it =
was already defined.
 
Paul
 
From:=
 =
apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of William Mills
Sent: Monday, April 23, 2012 =
11:29 AM
To: Mike Jones; Blaine Cook; =
apps-discuss@ietf.org
Subject: [apps-discuss] Is =
host-meta.json viable? Re: Webfinger / SWD Issue #3: direct versus =
indirect discovery
 
I note =
that some examples are now using the construct (Eran called it a hack, =
which it probably is, but I like it) host-meta.json to select the data =
format.  This seems to me to be a workable way =
to:
 
-    extend the current WF stuff =
keeping compatibility 
-    support for JSON without funky =
logic
-    allow the clients to implement a =
single simple code path
 
-bill
 
<=
hr size=3D1 width=3D"100%" align=3Dcenter>
F=
rom: =
Mike Jones <Michael.Jones@microsoft.com>
To: Blaine Cook <romeda@gmail.com>; "apps-discuss@ietf.org" =
<apps-discuss@ietf.org> =

Sent: Sunday, April 22, 2012 9:11 PM
Subject: Re: =
[apps-discuss] Webfinger / SWD Issue #3: direct versus indirect =
discovery
 
I agree with your goal of =
simplicity for clients.  Paul=E2=80=99s example seems about as =
simple as it can get for clients:
It shares the property with =
your earlier example (below) that clients have a no-branches code path =
to do discovery:
     &n=
bsp;         curl -s http://example.com/.well-known/host-meta|
     &n=
bsp;         awk =
"/lrdd/,/template/"|tr -d '\n'|sed -e =
"s/^.*template=3D'\([^']*\)'.*$/\1/"|
     &n=
bsp;         sed -e "s/{uri}/user@example.com/"|xargs curl =E2=80=93s
From: apps-discuss-bounces@ietf.o=
rg [mailto:apps-discu=
ss-bounces@ietf.org] On Behalf Of Blaine Cook
Sent: =
Sunday, April 22, 2012 2:15 PM
To: apps-discuss@ietf.org
Sub=
ject: [apps-discuss] Webfinger / SWD Issue #3: direct versus =
indirect discovery
 
This is the last issue that I've flagged as =
blocking a new Webfinger / SWD =
draft.
 
<=
p class=3DMsoNormal style=3D'background:white'>Mike suggested that being able to request a user's =
profile with a single request (i.e., that the /.well-known/ profile =
resource should be able to respond with full profile data immediately, =
rather than pointing at a second URL that will fulfil the request) is a =
requirement for this =
standard.
 
<=
p class=3DMsoNormal style=3D'background:white'>I'd like to challenge that requirement. The =
arguments for a direct discovery endpoint =
are:
 
<=
p class=3DMsoNormal style=3D'background:white'>1. Fewer requests against the server, since we =
save (in the worst-case) 50% of requests by bypassing the indirect =
lookup phase.
2. Lower latency for clients (e.g., mobile =
clients) owing to the reduced number of =
lookups.
 
<=
p class=3DMsoNormal style=3D'background:white'>The arguments for an indirect discovery endpoint =
are:
 
<=
p class=3DMsoNormal style=3D'background:white'>1. Trivial and web-standards friendly deployment =
for domains that won't host their own webfinger/swd profile servers, but =
want to enable accounts on their domains (e.g., statically hosted =
sites).
2. A loosening of =
the requirement that URLs at the bare domain must run dynamic scripts =
that respond to requests to the /.well-known/ =
path.
 
<=
p class=3DMsoNormal style=3D'background:white'>My opinion is that the approach that SWD has =
proposed for the redirect is problematic. First, the format is very =
similar in form to the HTML "meta refresh" tag that provided =
HTTP redirect support from within HTML. That format has been widely =
deprecated, and in these more enlightened times, we just use the 3xx =
response codes with Location headers, =
instead.
 
<=
p class=3DMsoNormal style=3D'background:white'>Secondly, the SWD request format means that for =
smaller sites, often those with the least resources, will end up serving =
static content in a way that's difficult to cache; certainly, more =
difficult to cache than just serving static content. This is due to the =
request parameters present in all SWD requests; those request parameters =
will bust caches.
 
<=
p class=3DMsoNormal style=3D'background:white'>As for the first argument *for* SWD's approach, =
I'd suggest we look to DNS, which uses the same indirection approach for =
NS records, relying on a (relatively) very small set of root servers to =
handle the traffic for the whole internet. Clearly, this approach works, =
and webfinger/swd servers are in a much better position to handle this =
additional traffic. Most of this traffic will be heavily cached, =
especially for the largest =
providers.
 
<=
p class=3DMsoNormal style=3D'background:white'>In fact, in terms of real deployments, hosting a =
script at, e.g., google.com/.well-known/simple-web-discovery is =
much harder than hosting a script at profiles.google.com/profile.json for all sorts of =
reasons, so it's my belief that the first argument is a red =
herring.
 
<=
p class=3DMsoNormal style=3D'background:white'>The second argument is legitimate, but only if =
mobile clients will actually be making requests to diverse webfinger/swd =
hosts. Instead, I strongly believe that we'll see the emergence of =
DNS-like servers that provide both profile hosting as well as proxy =
services. For a mobile client, the optimal approach will be to use SPDY =
to connect to a single host that performs webfinger/swd lookups on the =
mobile client's behalf, eliminating the latency =
concerns.
 
<=
p class=3DMsoNormal style=3D'background:white'>I offer that the two-step lookup can be =
implemented without conditionals on the client, whereas the =
direct-unless-not approach cannot be implemented that way (see my =
earlier curl example for proof). It's simpler, and easier to explain to =
the (hopefully many) small site owners who we'd like to implement this =
technology.
 
<=
p class=3DMsoNormal style=3D'background:white'>Thoughts? Am I missing =
something?
 
<=
p class=3DMsoNormal style=3D'background:white'>b.

_______________________________________________=

apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<=
br>
<=
/div>
------=_NextPart_000_053D_01CD22EE.F3DAB550--


From eran@hueniverse.com  Wed Apr 25 11:29: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 7D97C21F8849 for ; Wed, 25 Apr 2012 11:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.505
X-Spam-Level: 
X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JU6px8y1exl for ; Wed, 25 Apr 2012 11:29:03 -0700 (PDT)
Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id F029921F88D6 for ; Wed, 25 Apr 2012 11:29:02 -0700 (PDT)
Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id 2JV21j00c0EuLVk01JV2y0; Wed, 25 Apr 2012 11:29:02 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Wed, 25 Apr 2012 11:29:02 -0700
From: Eran Hammer 
To: John Bradley 
Thread-Topic: [apps-discuss] WF flow with rel parameter
Thread-Index: AQHNIomKaCym1aAtdUm4KjKnInrNO5ard+qAgACDoID//6IRMIAAgkAA//+ZoSCAAIr5AP//lX+Q
Date: Wed, 25 Apr 2012 18:29:02 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201009E4D@P3PWEX2MB008.ex2.secureserver.net>
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201007020@P3PWEX2MB008.ex2.secureserver.net> <515663DA-67BF-4367-9AD9-6E940424CBCD@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20100990A@P3PWEX2MB008.ex2.secureserver.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 18:29:04 -0000

> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Wednesday, April 25, 2012 10:38 AM
> To: Eran Hammer
> Cc: Paul E. Jones; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] WF flow with rel parameter
>=20
> Eran,
>=20
> It was unclear, at least to me that the server side host-meta processing =
rule
> specified in WF requires all the templates (or just the LRDD ones) to be
> processed substituting inserting "resource" for URI and then retrieving a=
nd
> merging all the resource JRD before processing the filter on the "rel".
>=20
> If I defined a rel of FOO would WF fill the template and retrieve the JRD=
 and
> merge its links with the lrdd JRD?
> I might think that would be a touch confusing to clients.

No. It only does *one* level of LRDD import (in order). See:

http://tools.ietf.org/html/rfc6415#section-4.2

> So I go back to the rational explanation that lrdd templates are expanded=
 and
> those links rolled up and filtered.
>=20
> Now I am guessing that some of the SWD people are thinking that when the
> server is using flat files that puts a lot of burden onto the client.
>=20
> Probably why you added the server side processing.

The idea of adding server-side processing and filtering via the query came =
out of the original OpenID Connect proposal that David Recordon and I wrote=
, trying to keep the clients super simple and avoid the need to go fetch ho=
st-meta, then one or more LRDD documents.

Complexity is very much implementation specific on the server side. Yahoo d=
oesn't have LRDD documents and puts everything as link templates in host-me=
ta while others like the ability to customize. The most likely scenario of =
servers including LRDD links in host-meta is that the host-meta document is=
 static, while the LRDD links are dynamically generated. Otherwise, there i=
s very little value in the added complexity. In that case, the client will =
typically be faced with 2 requests.

I would argue that a server using multiple LRDD links in host-meta is abusi=
ng the system, very much like a server using multiple 3xx redirections betw=
een its initial host-meta endpoint to where the document actually lives.

IOW, there are many ways to inflict pain on the client.

> Given that WF takes the liberty of adding query parameters to host-meta
> and seems to define host-meta processing rules (perhaps for non lrdd?), I
> am not finding the separation of the two specs as clean as possible.
> It seems a bit like there is there a RFC 6415 dependency on WF.  Though t=
hat
> is a touch strange for a RFC.

The WF draft should not introduce any new processing rules. It should only =
add the query optimization but that must result in exactly the same set of =
links as defined by 6415. If this is the case, it's a bug.

> What stops someone from defining a relation of super-discovery and adding
> some query parameters to host-meta.json to hover up some lrdd based on a
> template expansion of  "super-discovery" rel types, and filter on "rel"?
>=20
> I wouldn't have thought to do that because stepping on the RFC 6415
> endpoint seems slightly wrong to me.
>=20
> I would probably define a new endpoint /.well-known/super-discovery with
> my own query parameters and processing rules for JRD documents.

That would be the right approach. Note that 6415 registers both host-meta (=
defaults to XML) and host-meta.json (JSON required).

> Without being able to make server-side processing of host-meta required,
> we need someway to delegate that to another endpoint.
>=20
> In XRD we did discuss delegating the entire XRD.  Is there a way to do th=
at in
> host-meta?

3xx.

EH

> At the moment all of the processing gets pushed back on the client if the
> host only supports static files in /.well-known
>=20
> John B.
>=20
>=20
>=20
> On 2012-04-25, at 1:34 PM, Eran Hammer wrote:
>=20
> > It is important to understand the semantics of host-meta, which I think
> there is some confusion about here.
> >
> > As a mechanism, host-meta providers you with a method of obtaining both
> host-wide and resource-specific links (and properties). To accomplish tha=
t, it
> provides with both a document and processing rules.
> >
> > WebFinger - the name given for the host-meta *use-case* of retrieving
> user information - is a specialization of obtaining resource-specific lin=
ks.
> >
> > The 'rel' and 'resource' query parameters (as proposed) apply to the
> endpoint *after* executing the processing rules (which include expanding
> templates and importing links from one level LRDD documents).
> >
> > LRDD documents only apply to resource-specific links, which means they
> are ignored for any host-wide query. For example, the location of the sit=
e's
> TOS document. From the host-meta perspective, LRDD documents are just a
> deployment tool to provide customization not possible using just link
> templates at the host-meta document level. It's just a link-include
> mechanism, and host-meta uses it restrictively.
> >
> > IMO, the 'rel' and 'resource' optimization should only apply to the hos=
t-
> meta endpoint, and act as a filter post the processing rules. If 'resourc=
e' is
> specified, it is a resource-specific request, otherwise, host-wide.
> >
> > Let me know if this helps or if it is still unclear.
> >
> > EH
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >> Sent: Wednesday, April 25, 2012 8:27 AM
> >> To: Eran Hammer
> >> Cc: Paul E. Jones; apps-discuss@ietf.org
> >> Subject: Re: [apps-discuss] WF flow with rel parameter
> >>
> >> That was one thing that initially confused me.  The rel filter is not =
applied
> to
> >> host-meta, but rather the linked lrdd resource JRD.
> >>
> >> The currently defined "resource" parameter has an implicit host-meta
> "rel"
> >> of "lrdd".
> >>
> >> To use this mechanism for other relations you would need to make that
> >> parameter explicit.
> >>
> >> That then raises the question of the filter being part of host-meta or=
 WF if
> it
> >> applies to relationships other than lrdd.
> >>
> >> If you are asking if filtering should be supported by lrdd where you s=
tart
> >> discovery from a link header, then it probably should be possible as w=
ell.
> >>
> >> Though I thought lrdd stopped being updated over a year a year ago.
> Sorry if
> >> I am out of date.
> >>
> >> So XRD/JRD documents SHOULD be filterable by "rel" independent of if
> you
> >> get to them via lrdd or host-meta.
> >>
> >> Host-meta SHOULD support a mechanism to filter by "rel" or filter by a
> >> combination of "resource" (uri) , host-meta-rel and resource-rel (the
> host-
> >> meta-rel is currently implicit.)
> >>
> >> I recall discussing this in the XRI TC when we did XRD years ago, thou=
gh
> that
> >> was more around using XRI identifiers.
> >>
> >> The same principal still holds.  I should be able to ask for.
> >> GET /.well-known/host-meta.json
> >>     ?resource=3Djoe@example.com
> >>     &host-meta-rel=3Dlrdd
> >>
> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> >> HTTP/1.1
> >> Host: example.com
> >>
> >> (personally I think calling the parameter "resource" and the template =
{uri}
> >> will be confusing to people)
> >>
> >> In SWD we used fixed the parameter names and the base URI is the part
> that
> >> gets changed when the /.well-known can't host a script.
> >> That makes the template simpler for the client to process.  The equiva=
lent
> to
> >> "rel" is always passed to make processing simpler.
> >>
> >> As Blaine has pointed out several times SWD and WF largely get us to t=
he
> >> same place.
> >>
> >> I am trying to find a way to close the gap.
> >>
> >> John B.
> >>
> >>
> >> On 2012-04-25, at 11:41 AM, Eran Hammer wrote:
> >>
> >>> Purely from a practical standpoint, do you think it is likely that a =
server
> will
> >> support the query filter for the lrdd documents but not for host-meta?
> >>>
> >>> EH
> >>>
> >>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> >> bounces@ietf.org] On Behalf Of John Bradley
> >>> Sent: Wednesday, April 25, 2012 6:17 AM
> >>> To: Paul E. Jones
> >>> Cc: apps-discuss@ietf.org
> >>> Subject: Re: [apps-discuss] WF flow with rel parameter
> >>>
> >>> Paul,
> >>>
> >>> "rel" as a filter is something WF has for host-meta.  It however does=
n't
> >> seem to have that for user JRD in the case where host-meta is returned=
,
> and
> >> the template is used.
> >>>
> >>> The "resource" and "rel" parameters are already an optimization for
> LRDD
> >> and not part of host-meta.
> >>> Adding LRDD specific parameters to host-meta/host-meta.json will
> >> probably raise some eyebrows in review, but I am OK with it.
> >>>
> >>> I think there are use cases where size matters.  Where a host-meta or
> >> resource JRD may be large and it is more efficient not to send the who=
le
> >> thing to a mobile client.
> >>> It seems to be one of Mike Jones requirements.
> >>>
> >>> Using RFC6570 for LRDD is a possibility for passing through the filte=
r
> request
> >> for sites that support filtering on resource JRD.
> >>>
> >>> What other proposals do you have.  I am guessing that filtering on
> resource
> >> JRD is not a totally new topic.
> >>>
> >>> LRDD is the one really doing the optimization  in any event,  it may =
be
> done
> >> at the host-meta GET but it is a LRDD specific extension.
> >>> Having it in the template allows LRDD to filter at the resource JRD i=
n
> cases
> >> where it is not possible to do it at the host-meta level, due to some =
no
> script
> >> or other restriction.
> >>>
> >>> I agree that it should be filtered at the how-meta request but you an=
d
> >> others say that is not always possible.
> >>>
> >>> John B.
> >>>
> >>>
> >>>
> >>>
> >>> On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
> >>>
> >>>
> >>> John,
> >>>
> >>> The "rel" parameter is something we still need to discuss, so not is =
as
> good
> >> a time as any.
> >>>
> >>> What "rel" does is act as a filter.  For the most part, the only purp=
ose it
> >> serves is to help reduce the number of link relations that might be se=
nt
> from
> >> the server.  So, if a user had 1,000 different link relations, this mi=
ght
> reduce
> >> the returned message to containing only 1.  However, if a user has mor=
e
> than
> >> one link relation of the same type, all of them would match and be
> returned.
> >>>
> >>> When you say the host cannot support re-write rules, I assume you
> mean it
> >> does not support the URI parameters on host-meta?  In that case, yes,
> the
> >> parameters are ignored and you get just the host-meta document.
> >>>
> >>> The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1).  =
There
> are
> >> no other URI template values defined.  (Note: this whole section exist=
s
> only
> >> because RFC  6570 did not yet exist, I think.
> >>>
> >>> In any case, we could define a new URI template, but then we would be
> >> putting an optimization in place for LRDD.  If host-meta is not going =
to
> >> support the "rel" URI parameter, why would LRDD?  It would also mean
> that
> >> the LRDD logic would have to be ready to receive a URI parameter that =
is
> not
> >> replaced, since some clients would only change {uri} and leave {rel} t=
here.
> >> That would introduce more conditional logic in the server.  This would=
 also
> >> present issues with static sites.  (Of course, one might be able to us=
e
> Apache
> >> re-writing rules to get around that problem, but it certainly would no=
t
> work
> >> for "real" static sites.)
> >>>
> >>> Personally,  I'd prefer to not add the "rel" parameter to LRDD, since=
 I
> think
> >> optimization using "rel" would always be done on host-meta.  That said=
, I
> >> question the value of "rel" entirely.  Do you think it's useful to hav=
e this
> filter
> >> at all?  Is there really a risk that a site might return 1,000 link re=
lations that
> the
> >> client would have to step over?
> >>>
> >>> Paul
> >>>
> >>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >>> Sent: Tuesday, April 24, 2012 10:17 PM
> >>> To: Paul E. Jones
> >>> Cc: apps-discuss@ietf.org
> >>> Subject: WF flow with rel parameter
> >>>
> >>> Paul,
> >>>
> >>> Sorry I hit send on the previous message with a typo.
> >>>
> >>> I am looking at how the flows in WF might work for openID.
> >>>
> >>> Let's set aside the XML issue for the moment and focus on the JSON
> flow.
> >>>
> >>> Please correct anything I get wrong.
> >>>
> >>> The openID Connect defines a relation of
> >> http://openid.net/specs/connect/issuer
> >>>
> >>> WF allows for a JSON host-meta that takes two parameters, "resource"
> and
> >> "rel"
> >>>
> >>> An example request and response (line-brakes for readability)
> >>>
> >>> GET /.well-known/host-meta.json
> >>>     ?resource=3Djoe@example.com
> >>>
> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> >> HTTP/1.1
> >>> Host: example.com
> >>>
> >>>   HTTP/1.1 200 OK
> >>>
> >>>   Access-Control-Allow-Origin: *
> >>>   Content-Type: application/json; charset=3DUTF-8
> >>>
> >>>   {
> >>>     "subject" : "joe@example.com",
> >>>     "links" :
> >>>     [
> >>>       {
> >>>         "rel" : "http://openid.net/specs/connect/issuer",
> >>>         "href" : "https://server.example.com"
> >>>       }
> >>>     ]
> >>>   }
> >>>
> >>> If the host can't support rewrite rules or scripts the exchange would=
 look
> >> like:
> >>>
> >>> GET /.well-known/host-meta.json
> >>>     ?resource=3Djoe@example.com
> >>>
> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> >> HTTP/1.1
> >>> Host: example.com
> >>>
> >>> HTTP/1.1 200 OK
> >>>   Access-Control-Allow-Origin: *
> >>>   Content-Type: application/json; charset=3DUTF-8
> >>>   {
> >>>     "expires" : "2012-03-13T20:56:11Z",
> >>>     "links" :
> >>>     [
> >>>       {
> >>>         "rel" : "lrdd",
> >>>         "type" : "application/json",
> >>>         "template" :
> >>>           "https://example.com/lrdd/?format=3Djson&resource=3D{uri}"
> >>>       }
> >>>
> >>> GET /lrdd/
> >>>     ?format=3Djson
> >>>     &resource=3Djoe@example.com
> >>> Host: example.com
> >>>
> >>> HTTP/1.1 200 OK
> >>>
> >>>   Access-Control-Allow-Origin: *
> >>>   Content-Type: application/json; charset=3DUTF-8
> >>>
> >>>   {
> >>>     "subject" : "joe@example.com",
> >>>     "links" :
> >>>     [
> >>>       {
> >>>         "rel" : "http://openid.net/specs/connect/issuer",
> >>>         "href" : "https://server.example.com"
> >>>       },
> >>>       {
> >>>         "rel" : "http://webfinger.net/rel/avatar",
> >>>         "href" : "http://example.com/~joe/joe.jpg"
> >>>       }
> >>>
> >>>     ]
> >>>   }
> >>>
> >>> I can't find a template parameter for "rel".  The host-meta spec allo=
ws
> for
> >> extension but it is missing.
> >>>
> >>> What if the server wants to support filtering on rel but can't suppor=
t it in
> >> the root for some reason?
> >>>
> >>> Is it possible to have a template like:
> >>> "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}=
"
> >>>
> >>> That simple addition may solve a number of problems for openID.
> >>>
> >>> John B.
> >>>
> >>>
> >>>
> >


From wmills@yahoo-inc.com  Wed Apr 25 11:29: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 54A8121F88E4 for ; Wed, 25 Apr 2012 11:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.298
X-Spam-Level: 
X-Spam-Status: No, score=-17.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I1Dewz7Wc-6 for ; Wed, 25 Apr 2012 11:29:20 -0700 (PDT)
Received: from nm36-vm5.bullet.mail.ne1.yahoo.com (nm36-vm5.bullet.mail.ne1.yahoo.com [98.138.229.117]) by ietfa.amsl.com (Postfix) with SMTP id 70E2F21F88E2 for ; Wed, 25 Apr 2012 11:29:20 -0700 (PDT)
Received: from [98.138.90.48] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 25 Apr 2012 18:29:16 -0000
Received: from [98.138.87.3] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 25 Apr 2012 18:29:16 -0000
Received: from [127.0.0.1] by omp1003.mail.ne1.yahoo.com with NNFMP; 25 Apr 2012 18:29:16 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 836154.94183.bm@omp1003.mail.ne1.yahoo.com
Received: (qmail 86910 invoked by uid 60001); 25 Apr 2012 18:29:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1335378556; bh=NAk3aHVngWAK7Z7m75w4TAAwCQF2gqS2hU6NwKdoX3U=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=SW5OC4LO0w4IQIS0W+eQqY3GNPvydl+Bwf3G3w2zeD7/F0pxAyV1zHwpR91UqauVjIbHaMJFU5LULy6rx09gz5xgOBed1klyZGIuWr6QFAGzHRXWZHAgRTKBcPwDzHDBHG/dIBeIRmLhSvXABPxYEdvR6XjYaPeY82kv+zY62Hg=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=QQwX6fR9vN1igBTYf/BYfGTp3CBuvlMTMEe6Dp+D1z+r3sTN4FNQmkweV+Xzx1XN31DFns3cgB6e14ejyV9NX7dXYzZVkCpcc3mFAIOOMd5ZLUm4izW3Z+4W/mv8H9gPqN4OqCgGUSFVwxYCJgV6joxxcLstsChUvwPANKt++34=;
X-YMail-OSG: sWlMvGsVM1l5wCQ3lOjvQZpx9TWGY9KRNPgZrewdCH.nHed mshDkNioP2kgjj3jhijHvNNONoDRbPYI3q04eRCOvfRCW2V45v2_DJNl0RvJ nIwwqkBeZJZVd0_95vLUwQi1gf_pz63HjVopTce9PEna6xjm32phVFY7WdYL EZ_o3X2ANcOoLG7UGAf1vzZmvomSmJYB.PkVvdJ0f5_kSN_EmEKHMUXJMwOT Xjk_VjQIpp34LyMtqocIG.Hd7xNmDqXlva2wEKcxPHQeZbc3cOHm7YRqgDkA usHgfhyt9wubTtJCGmh__Kr2oNbT84YA.h_Okd7SQocyoTkFy4WbQ774icYp MvMActipdntLB7l05l4gdlmUapX7j_w0OJ7a2sAwm7X5nCaMPa9b6xvj_SN2 SV0njjI4NkAYfqQcJEK.GK4eUDZnfKy6GYPu2CsmES.TijlboldFXFDhh3MR O206FtnyYqeFfMiBHT_o.NANFA0b33._g2IaJ_D03gzJxa1T20Aw11fX7Jmp o1ysozleG.vLt5L3Hf.w3Q27psJJG9fpk359kbRZKcgUVDl_XUB7iEIP_k_S LjQoVhkzAjjdf.1Tz0btRjo3oEoDlPNjYmTd7tmuYoYzLgiMw
Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Wed, 25 Apr 2012 11:29:16 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <1335194949.12040.YahooMailNeo@web31812.mail.mud.yahoo.com> <053c01cd2310$7aea0b60$70be2220$@packetizer.com>
Message-ID: <1335378556.86839.YahooMailNeo@web31808.mail.mud.yahoo.com>
Date: Wed, 25 Apr 2012 11:29:16 -0700 (PDT)
From: William Mills 
To: "Paul E. Jones" , 'Mike Jones' , 'Blaine Cook' , "apps-discuss@ietf.org" 
In-Reply-To: <053c01cd2310$7aea0b60$70be2220$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="258328648-477248381-1335378556=:86839"
Subject: Re: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Apr 2012 18:29:22 -0000

--258328648-477248381-1335378556=:86839
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Even better.=0A=0A=0A=0A=0A>________________________________=0A> From: Paul=
 E. Jones =0A>To: 'William Mills' ; 'Mike Jones' ; 'Blaine Cook' ; apps-discuss@ietf.org =0A>Sent: Wednesday, April 25, 2012 11:23 AM=
=0A>Subject: RE: [apps-discuss] Is host-meta.json viable? Re: Webfinger / S=
WD Issue #3: direct versus indirect discovery=0A> =0A>=0A>Bill,=0A>=C2=A0=
=0A>Host-meta.json was introduced in RFC 6415 as a means of selecting JSON,=
 particularly when the client does not have the ability to indicate via the=
 =E2=80=9CAccept=E2=80=9D header that it wants =E2=80=9Capplication/json=E2=
=80=9D.=C2=A0 On my server, I return XML by default.=C2=A0 I also honor the=
 =E2=80=9CAccept=E2=80=9D header and return the type requested.=C2=A0 And, =
I support host-meta.json, which will return JSON by default (i.e., =E2=80=
=9CAccept=E2=80=9D is =E2=80=9C*/*=E2=80=9D), but I still honor the =E2=80=
=9CAccept=E2=80=9D header.=C2=A0 I always given preference to the Accept he=
ader, which I think is appropriate, though not explicitly documented anywhe=
re.=C2=A0 This is where the =E2=80=9Chack=E2=80=9D part comes in.=C2=A0 One=
 should honor what HTTP says, but then how to we treat a request based on t=
he URI path?=C2=A0 Not sure, but I=E2=80=99m inclined to leave it that way =
until somebody tells me why it=E2=80=99s a bad idea.=0A>=C2=A0=0A>In any ca=
se, this was not invented as a part of the current draft; it was already de=
fined.=0A>=C2=A0=0A>Paul=0A>=C2=A0=0A>From:apps-discuss-bounces@ietf.org [m=
ailto:apps-discuss-bounces@ietf.org] On Behalf Of William Mills=0A>Sent: Mo=
nday, April 23, 2012 11:29 AM=0A>To: Mike Jones; Blaine Cook; apps-discuss@=
ietf.org=0A>Subject: [apps-discuss] Is host-meta.json viable? Re: Webfinger=
 / SWD Issue #3: direct versus indirect discovery=0A>=C2=A0=0A>I note that =
some examples are now using the construct (Eran called it a hack, which it =
probably is, but I like it) host-meta.json to select the data format.=C2=A0=
 This seems to me to be a workable way to:=0A>=C2=A0=0A>-=C2=A0=C2=A0=C2=A0=
 extend the current WF stuff keeping compatibility =0A>-=C2=A0=C2=A0=C2=A0 =
support for JSON without funky logic=0A>-=C2=A0=C2=A0=C2=A0 allow the clien=
ts to implement a single simple code path=0A>=C2=A0=0A>-bill=0A>=C2=A0=0A>>=
=0A>>________________________________=0A>>=0A>>From:Mike Jones =0A>>To: Blaine Cook ; "apps-discuss@iet=
f.org"  =0A>>Sent: Sunday, April 22, 2012 9:11 PM=0A=
>>Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indir=
ect discovery=0A>>=C2=A0=0A>>I agree with your goal of simplicity for clien=
ts.=C2=A0 Paul=E2=80=99s example seems about as simple as it can get for cl=
ients:=0A>>=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 curl -v https://packetizer.com/.well-known/host-meta.=
json?resource=3Dacct:paulej@packetizer.com=0A>>It shares the property with =
your earlier example (below) that clients have a no-branches code path to d=
o discovery:=0A>>=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 curl -s http://example.com/.well-known/host-met=
a%7C=0A>>=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 awk "/lrdd/,/template/"|tr -d '\n'|sed -e "s/^.*template=
=3D'\([^']*\)'.*$/\1/"|=0A>>=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 sed -e "s/{uri}/user@example.com/"|=
xargs curl =E2=80=93s=0A>>=C2=A0=0A>>However, I challenge the assumption in=
 your note below that servers using only static pages must be supported.=C2=
=A0 I just don=E2=80=99t see the requirement to implement a query parameter=
 as being an impediment in practice, even for hosted domains.=C2=A0 I know =
of no hosting company that doesn=E2=80=99t provide a means of putting execu=
table code behind web pages, be it PHP, Perl, Ruby, ASP, JSP, etc.=C2=A0 I =
know you=E2=80=99re trying to make the case for static pages, but in practi=
ce, I believe that dynamic pages are always easily available.=0A>>=C2=A0=0A=
>>Assuming that we=E2=80=99re in an either-or situation with regard to eith=
er having single-GET discovery or supporting discovery using only static se=
rver pages (and I=E2=80=99d love to have someone demonstrate to us that we=
=E2=80=99re not), I=E2=80=99d take single-GET discovery for sure, as in som=
e cases, it makes an appreciable difference in user interface latency, and =
per the paragraph above, I believe that dynamic queries can be implemented =
on all hosting platforms.=0A>>=C2=A0=0A>>Assuming the WebFinger authors agr=
ee, I=E2=80=99d suggest that a logical next step would be for a -04 version=
 of draft-jones-appsawg-webfinger to be published that changes support for =
the resource parameter from RECOMMENDED to REQUIRED, as that could provide =
a starting point for a common discovery spec.=0A>>=C2=A0=0A>>=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=0A>>=C2=A0 =0A>>P.S.=C2=
=A0 As long as draft-jones-appsawg-webfinger is being revised, I=E2=80=99d =
also suggest adding text making explicit what has been an implicit assumpti=
on in both WebFinger and SWD - that depending upon whether and how the clie=
nt is authenticated, the set of resources returned may vary (as Blaine had =
pointed out earlier).=C2=A0 That could help deal with some of the privacy p=
erceptions.=0A>>=C2=A0=0A>>From:apps-discuss-bounces@ietf.org [mailto:apps-=
discuss-bounces@ietf.org] On Behalf Of Blaine Cook=0A>>Sent: Sunday, April =
22, 2012 2:15 PM=0A>>To: apps-discuss@ietf.org=0A>>Subject: [apps-discuss] =
Webfinger / SWD Issue #3: direct versus indirect discovery=0A>>=C2=A0=0A>>T=
his is the last issue that I've flagged as blocking a new Webfinger / SWD d=
raft.=0A>>=C2=A0=0A>>Mike suggested that being able to request a user's pro=
file with a single request (i.e., that the /.well-known/ profile resource s=
hould be able to respond with full profile data immediately, rather than po=
inting at a second URL that will fulfil the request) is a requirement for t=
his standard.=0A>>=C2=A0=0A>>I'd like to challenge that requirement. The ar=
guments for a direct discovery endpoint are:=0A>>=C2=A0=0A>>1. Fewer reques=
ts against the server, since we save (in the worst-case) 50% of requests by=
 bypassing the indirect lookup phase.=0A>>2. Lower latency for clients (e.g=
., mobile clients) owing to the reduced number of lookups.=0A>>=C2=A0=0A>>T=
he arguments for an indirect discovery endpoint are:=0A>>=C2=A0=0A>>1. Triv=
ial and web-standards friendly deployment for domains that won't host their=
 own webfinger/swd profile servers, but want to enable accounts on their do=
mains (e.g., statically hosted sites).=0A>>2. A loosening of the requiremen=
t that URLs at the bare domain must run dynamic scripts that respond to req=
uests to the /.well-known/ path.=0A>>=C2=A0=0A>>My opinion is that the appr=
oach that SWD has proposed for the redirect is problematic. First, the form=
at is very similar in form to the HTML "meta refresh" tag that provided HTT=
P redirect support from within HTML. That format has been widely deprecated=
, and in these more enlightened times, we just use the 3xx response codes w=
ith Location headers, instead.=0A>>=C2=A0=0A>>Secondly, the SWD request for=
mat means that for smaller sites, often those with the least resources, wil=
l end up serving static content in a way that's difficult to cache; certain=
ly, more difficult to cache than just serving static content. This is due t=
o the request parameters present in all SWD requests; those request paramet=
ers will bust caches.=0A>>=C2=A0=0A>>As for the first argument *for* SWD's =
approach, I'd suggest we look to DNS, which uses the same indirection appro=
ach for NS records, relying on a (relatively) very small set of root server=
s to handle the traffic for the whole internet. Clearly, this approach work=
s, and webfinger/swd servers are in a much better position to handle this a=
dditional traffic. Most of this traffic will be heavily cached, especially =
for the largest providers.=0A>>=C2=A0=0A>>In fact, in terms of real deploym=
ents, hosting a script at, e.g., google.com/.well-known/simple-web-discover=
y is much harder than hosting a script at profiles.google.com/profile.json =
for all sorts of reasons, so it's my belief that the first argument is a re=
d herring.=0A>>=C2=A0=0A>>The second argument is legitimate, but only if mo=
bile clients will actually be making requests to diverse webfinger/swd host=
s. Instead, I strongly believe that we'll see the emergence of DNS-like ser=
vers that provide both profile hosting as well as proxy services. For a mob=
ile client, the optimal approach will be to use SPDY to connect to a single=
 host that performs webfinger/swd lookups on the mobile client's behalf, el=
iminating the latency concerns.=0A>>=C2=A0=0A>>I offer that the two-step lo=
okup can be implemented without conditionals on the client, whereas the dir=
ect-unless-not approach cannot be implemented that way (see my earlier curl=
 example for proof). It's simpler, and easier to explain to the (hopefully =
many) small site owners who we'd like to implement this technology.=0A>>=C2=
=A0=0A>>Thoughts? Am I missing something?=0A>>=C2=A0=0A>>b.=0A>>=0A>>______=
_________________________________________=0A>>apps-discuss mailing list=0A>=
>apps-discuss@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/apps-discu=
ss=0A>>=0A>>=0A>=0A>
--258328648-477248381-1335378556=:86839
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Even better.

  
 
 
  
  From=
: Paul E. Jones <paulej@packetizer.com>
 To: 'William Mills' <wmills@yahoo-inc=
.com>; 'Mike Jones' <Michael.Jones@microsoft.com>; 'Blaine Cook' &=
lt;romeda@gmail.com>; apps-discuss@ietf.org 
 Sent: Wednesday, April 25, 2012 11:23 AM
 <=
span
 style=3D"font-weight: bold;">Subject: RE: [apps-discuss] Is hos=
t-meta.json viable? Re: Webfinger / SWD Issue #3: direct versus indirect di=
scovery
  
 
=0A
Bill,
  
Hos=
t-meta.json was introduced in RFC 6415 as a means of selecting JSON, partic=
ularly when the client does not have the ability to indicate via the =E2=80=
=9CAccept=E2=80=9D header that it wants =E2=80=9Capplication/json=E2=80=9D.=
  On my server, I return XML by default.  I also honor the =E2=80=
=9CAccept=E2=80=9D header and return the type requested.  And, I suppo=
rt host-meta.json, which will return JSON by default (i.e., =E2=80=9CAccept=
=E2=80=9D is =E2=80=9C*/*=E2=80=9D), but I still honor the =E2=80=9CAccept=
=E2=80=9D header.  I always given preference to the Accept
 header, which I think is appropriate, though not explicitly documented any=
where.  This is where the =E2=80=9Chack=E2=80=9D part comes in.  =
One should honor what HTTP says, but then how to we treat a request based o=
n the URI path?  Not sure, but I=E2=80=99m inclined to leave it that w=
ay until somebody tells me why it=E2=80=99s a bad idea.
  
In any case, this was not invented as a part =
of the current draft; it was already defined.
  
Paul
  
=
From:<=
/span> apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] <=
b>On Behalf Of William Mills
Sent: Monday, April 23, 2012 11:=
29 AM
To: Mike Jones; Blaine Cook; apps-discuss@ietf.org
Su=
bject: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD Iss=
ue #3: direct versus indirect discovery
  
I note that some exa=
mples are now using the construct (Eran called it a hack, which it probably=
 is, but I like it) host-meta.json to select the data format.  This se=
ems to me to be a workable way to:
  
-    exten=
d the current WF stuff keeping compatibility 
    support for J=
SON without funky logic
-    allow the clients to implement a single simpl=
e code path
  
-bill=

  
From: Mike Jones =
<Michael.Jones@mic=
rosoft.com>
To: Blaine Cook <romeda@gmail.com>=
;; "apps-discuss@ietf.org" &l=
t;apps-discuss@ietf.org> <=
br>Sent: Sunday, April 22, 2012 9:11 PM
Subject: Re: [apps=
-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery=

  =

I agree with your goal of simplicity for clients.  P=
aul=E2=80=99s example seems about as simple as it can get for clients:
It shares the prop=
erty with your earlier example (below) that clients have a no-branches code=
 path to do discovery:
     &n=
bsp;         curl -s http://example=
.com/.well-known/host-meta%7C
   &nbs=
p;           awk "/lrdd/,=
/template/"|tr -d '\n'|sed -e "s/^.*template=3D'\([^']*\)'.*$/\1/"|<=
span style=3D"color:black;">
          =
;     sed -e "s/{uri}/user@example.com/"|xargs curl =E2=80=93s
 
However, I challenge the assumpti=
on in your note below that servers using only static pages must be supporte=
d.  I just don=E2=80=99t see the requirement to implement a query para=
meter as being an impediment in practice, even for hosted domains.  I =
know of no hosting company that doesn=E2=80=99t provide a means of putting =
executable code behind web pages, be it PHP, Perl, Ruby, ASP, JSP, etc.&nbs=
p; I know you=E2=80=99re trying to make the case for static pages, but in p=
ractice, I believe that dynamic pages are always easily available.
 
Assuming that we=E2=80=99re in an either-or=
 situation with regard to either having single-GET discovery or supporting =
discovery using only static server pages (and I=E2=80=99d love to have some=
one demonstrate to us that we=E2=80=99re not), I=E2=80=99d take single-GET =
discovery for sure, as in some cases, it makes an appreciable difference in=
 user interface latency, and per the paragraph above, I believe that dynami=
c queries can be implemented on all hosting platforms.
 
Assuming the WebFinger authors agree, I=E2=80=99d suggest that a logical =
next step would be for a -04 version of draft-jones-appsawg-webfinger to be=
 published that changes support for the resource parameter from RECOMMENDED=
 to REQUIRED, as that could provide a starting point for a common discovery=
 spec.
 
     &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;    -- Mike
  
P.S.  As long as draft-jones-appsawg-webfinger is being revi=
sed, I=E2=80=99d also suggest adding text making explicit what has been an =
implicit assumption in both WebFinger and SWD - that depending upon whether=
 and how the
 client is authenticated, the set of resources returned may vary (as Blaine=
 had pointed out earlier).  That could help deal with some of the priv=
acy perceptions.
 
Fro=
m: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Blaine Co=
ok
Sent: Sunday,
 April 22, 2012 2:15 PM
To: apps-discuss@ietf.org
Subject: [apps-discuss] Webfinger =
/ SWD Issue #3: direct versus indirect discovery
 
<=
span style=3D"color:black;">This is the last issue that I've flagged as blo=
cking a new Webfinger / SWD draft.
 
Mike=
 suggested that being able to request a user's profile with a single reques=
t (i.e., that the
 /.well-known/ profile resource should be able to respond with full profile=
 data immediately, rather than pointing at a second URL that will fulfil th=
e request) is a requirement for this standard.
 
I'd like to challenge that requirement. The arguments for a dir=
ect discovery endpoint are:
 
1. Fewe=
r requests against the server, since we save (in the worst-case) 50% of req=
uests by bypassing the indirect lookup phase.
=

2. Lower latency for clients (e.g., mobile clients) owing=
 to the reduced number of lookups.
 
=
The arguments for an indirect discovery endpoint are:
 
<=
div class=3D"yiv1356346771MsoNormal" style=3D"background:white;">1. Trivial and web-standards friendly deployment for dom=
ains that won't host their own webfinger/swd profile servers, but want to e=
nable accounts on their domains (e.g., statically hosted
 sites).
2. A looseni=
ng of the requirement that URLs at the bare domain must run dynamic scripts=
 that respond to requests to the /.well-known/ path.
 
My opinion is that the approach that SWD has proposed for=
 the redirect is problematic. First, the format is very similar in form to =
the HTML "meta refresh" tag that provided HTTP redirect support from within=
 HTML. That format has been widely deprecated, and in these more enlightene=
d times, we just use the 3xx response codes with Location headers, instead.=

 
Secondly, the SWD request forma=
t means that for smaller sites, often those with the least resources, will =
end up serving static content in a way that's difficult to cache; certainly=
, more difficult to cache than just serving static content. This is due to =
the request parameters present in all SWD requests; those request parameter=
s will bust caches.
&=
nbsp;
As for the firs=
t argument *for* SWD's approach, I'd suggest we look to DNS, which uses the=
 same indirection approach for NS records, relying on a (relatively) very s=
mall set of
 root servers to handle the traffic for the whole internet. Clearly, this a=
pproach works, and webfinger/swd servers are in a much better position to h=
andle this additional traffic. Most of this traffic will be heavily cached,=
 especially for the largest providers.
 
In fact, in terms of real deployments, hosting a script at, e.g., google.com/.well-known/simple-web-discovery is much h=
arder than hosting a script at profiles.google.com/profile.js=
on for all sorts of reasons, so it's my belief that the first argument =
is a red
 herring.
 
The second argument is =
legitimate, but only if mobile clients will actually be making requests to =
diverse webfinger/swd hosts. Instead, I strongly believe that we'll see the=
 emergence of DNS-like servers that provide both profile hosting as well as=
 proxy services. For a mobile client, the optimal approach will be to use S=
PDY to connect to a single host that performs webfinger/swd lookups on the =
mobile client's behalf, eliminating the latency concerns.
 
I offer that the two-step lookup can be implemented=
 without conditionals on the client, whereas the direct-unless-not approach=
 cannot be implemented that way (see my earlier curl example for proof). It=
's simpler, and easier to explain to the (hopefully many) small site owners=
 who we'd like to implement this technology.
<=
div>
 
Thoughts? Am I missing something?
 
b.

_______________________________________________
apps-discuss mai=
ling list
apps-discuss@ietf.or=
g
https://www.ietf.org/mailman/listinfo/apps-=
discuss

=


      
--258328648-477248381-1335378556=:86839--

From paulej@packetizer.com  Wed Apr 25 11: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 C098121F88CA for ; Wed, 25 Apr 2012 11:30:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.199,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZfKyZ+HyYNU for ; Wed, 25 Apr 2012 11:30:39 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDCD21F8849 for ; Wed, 25 Apr 2012 11:30:39 -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 q3PIUb0s029827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Apr 2012 14:30:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335378638; bh=EHHjU2ROB7t0vmUFy00NYtvBXOYt8zbUXZyQI549jqc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=t8JbAKtJ6mgIwaljEzyUSHqkyg+3RcAykb8xOuFZZDmX27gCmt9afLN8C+rzgLHdv pPpKlQkYIIufCwYWGjQpICd2DF2FDi06rk+dCBIehGPnaz/Gp7Bv5VpXathKHGbCBC KAxvCmlODPKtIkIwndpr0eX7PPzAaamrDW/dzrlA=
From: "Paul E. Jones" 
To: "'John Bradley'" , "'Bob Wyman'" 
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com>	<7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>	 <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com>
In-Reply-To: <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com>
Date: Wed, 25 Apr 2012 14:30:44 -0400
Message-ID: <054901cd2311$87a24fb0$96e6ef10$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_054A_01CD22F0.009320B0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIJGNvIkGmsH/dlhis4V9nZDOGpGAKB6SPgAbGhC8kDARG59JX6SomA
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect	discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 18:30:45 -0000

This is a multipart message in MIME format.

------=_NextPart_000_054A_01CD22F0.009320B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

John,

 

I don't think we need to decide specific environments we want to support,
but *if* people want to use static files, there are choices we can make
where the resource parameter will still work, even in a static environment.
Previously, I sent out a sample config that allows Apache to handle the
"resource" parameter and still map that to static files.  However, I cannot
do the same with the "rel" parameter, thus we could never mandate that if we
want to have any hope at all for allowing static sites.

 

I appreciate having the "resource" parameter, but I also appreciate some do
not need (or have the ability to support) an elaborate server.

 

Paul

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of John Bradley
Sent: Monday, April 23, 2012 12:19 PM
To: Bob Wyman
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect
discovery

 

I understand that in some environments you may not have access to http
rewrite rules.  

Others may preclude any scripts.

 

We do have to decide what environments we are going to support.

 

If we stick to static files only then we are just putting some lipstick on
Yadis by adding a way to map a email like address to a file.

 

So yes there are those environments, but that needs to be balanced against
the additional overhead on the clients to support that environment.

 

John B.

 

On 2012-04-23, at 12:26 PM, Bob Wyman wrote:





 

On Mon, Apr 23, 2012 at 11:08 AM, John Bradley  wrote:

Mike,

 

I think there is less resistance to making resource parameter REQUIRED than
there is to removing the initial host-meta lookup to get the template.

 

We should probably keep those issues separate.

 

I agree that supporting indirect discovery of the template via
host-meta.jason should probably stay.

 

The question is if their can be an optimization that allows shortcutting
that step if you know that all you want is web finger.

 

A possible option for that could be using a fixed template in /.well-known/.

 

That endpoint would return:

a The terminal JRD (like SWD)

b a 3xx redirect to the real endpoint

Causing a 3xx redirect typically requires modification to the configuration
files of a multi-host shared web server. Access to such configuration files
is often restricted in such a way that those responsible from just one or a
few of the sites sharing the common server are not permitted to make
modifications to those files. In many cases, such modifications can be
requested and will only be made after lengthy delays or the payment of
support and maintenance fees. 

 

If we want this sort of discovery to become generally available, and not
just be limited to the "large" sites, we should ensure that it is as simple
as possible to deploy.

 

c a copy of the host-meta.jrd

 

We would probably only do one of b or c.

 

c has the advantage of being a static file and you being no worse off than
having started with host-meta.json.

b is the simplest for the client and only requires common rewriting rules.

 

If the redirect is to the same host you could avoid the overhead of two
connections by pipelining the requests over the same TCP connection.

SPDY in the future will make that even more efficient.

 

I will grant Blaine that most openID Connect discovery requests are Server
to Server,  However there are Apps that are also clients that should not be
ignored.

I personally like the fixed template with a 3xx redirect and  resource
parameter returning a JRD due to the simplicity of client coding.

 

Things needing other sorts of information about the host would still use
host-meta or host-meta.json.

 

John B.

 

 

On 2012-04-23, at 1:11 AM, Mike Jones wrote:

 

I agree with your goal of simplicity for clients.  Paul's example seems
about as simple as it can get for clients:

               curl -v
https://packetizer.com/.well-known/host-meta.json?resource=acct:paulej@packe
tizer.com

It shares the property with your earlier example (below) that clients have a
no-branches code path to do discovery:

               curl -s http://example.com/.well-known/host-meta|
 

               awk "/lrdd/,/template/"|tr -d '\n'|sed -e
"s/^.*template='\([^']*\)'.*$/\1/"|

               sed -e "s/{uri}/user@example.com/"|xargs curl -s

 

However, I challenge the assumption in your note below that servers using
only static pages must be supported.  I just don't see the requirement to
implement a query parameter as being an impediment in practice, even for
hosted domains.  I know of no hosting company that doesn't provide a means
of putting executable code behind web pages, be it PHP, Perl, Ruby, ASP,
JSP, etc.  I know you're trying to make the case for static pages, but in
practice, I believe that dynamic pages are always easily available.

 

Assuming that we're in an either-or situation with regard to either having
single-GET discovery or supporting discovery using only static server pages
(and I'd love to have someone demonstrate to us that we're not), I'd take
single-GET discovery for sure, as in some cases, it makes an appreciable
difference in user interface latency, and per the paragraph above, I believe
that dynamic queries can be implemented on all hosting platforms.

 

Assuming the WebFinger authors agree, I'd suggest that a logical next step
would be for a -04 version of draft-jones-appsawg-webfinger to be published
that changes support for the resource parameter from RECOMMENDED to
REQUIRED, as that could provide a starting point for a common discovery
spec.

 

                                                            -- Mike

 

P.S.  As long as draft-jones-appsawg-webfinger is being revised, I'd also
suggest adding text making explicit what has been an implicit assumption in
both WebFinger and SWD - that depending upon whether and how the client is
authenticated, the set of resources returned may vary (as Blaine had pointed
out earlier).  That could help deal with some of the privacy perceptions.

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of Blaine Cook
Sent: Sunday, April 22, 2012 2:15 PM
To: apps-discuss@ietf.org
Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect
discovery

 

This is the last issue that I've flagged as blocking a new Webfinger / SWD
draft.

 

Mike suggested that being able to request a user's profile with a single
request (i.e., that the /.well-known/ profile resource should be able to
respond with full profile data immediately, rather than pointing at a second
URL that will fulfil the request) is a requirement for this standard.

 

I'd like to challenge that requirement. The arguments for a direct discovery
endpoint are:

 

1. Fewer requests against the server, since we save (in the worst-case) 50%
of requests by bypassing the indirect lookup phase.

2. Lower latency for clients (e.g., mobile clients) owing to the reduced
number of lookups.

 

The arguments for an indirect discovery endpoint are:

 

1. Trivial and web-standards friendly deployment for domains that won't host
their own webfinger/swd profile servers, but want to enable accounts on
their domains (e.g., statically hosted sites).

2. A loosening of the requirement that URLs at the bare domain must run
dynamic scripts that respond to requests to the /.well-known/ path.

 

My opinion is that the approach that SWD has proposed for the redirect is
problematic. First, the format is very similar in form to the HTML "meta
refresh" tag that provided HTTP redirect support from within HTML. That
format has been widely deprecated, and in these more enlightened times, we
just use the 3xx response codes with Location headers, instead.

 

Secondly, the SWD request format means that for smaller sites, often those
with the least resources, will end up serving static content in a way that's
difficult to cache; certainly, more difficult to cache than just serving
static content. This is due to the request parameters present in all SWD
requests; those request parameters will bust caches.

 

As for the first argument *for* SWD's approach, I'd suggest we look to DNS,
which uses the same indirection approach for NS records, relying on a
(relatively) very small set of root servers to handle the traffic for the
whole internet. Clearly, this approach works, and webfinger/swd servers are
in a much better position to handle this additional traffic. Most of this
traffic will be heavily cached, especially for the largest providers.

 

In fact, in terms of real deployments, hosting a script at, e.g.,
google.com/.well-known/simple-web-discovery is much harder than hosting a
script atprofiles.google.com/profile.json for all sorts of reasons, so it's
my belief that the first argument is a red herring.

 

The second argument is legitimate, but only if mobile clients will actually
be making requests to diverse webfinger/swd hosts. Instead, I strongly
believe that we'll see the emergence of DNS-like servers that provide both
profile hosting as well as proxy services. For a mobile client, the optimal
approach will be to use SPDY to connect to a single host that performs
webfinger/swd lookups on the mobile client's behalf, eliminating the latency
concerns.

 

I offer that the two-step lookup can be implemented without conditionals on
the client, whereas the direct-unless-not approach cannot be implemented
that way (see my earlier curl example for proof). It's simpler, and easier
to explain to the (hopefully many) small site owners who we'd like to
implement this technology.

 

Thoughts? Am I missing something?

 

b.

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

 


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

 

 


------=_NextPart_000_054A_01CD22F0.009320B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


John,
 
I don’t think we need to decide specific environments we want =
to support, but *if* people want to use static files, there are =
choices we can make where the resource parameter will still work, even =
in a static environment.  Previously, I sent out a sample config =
that allows Apache to handle the “resource” parameter and =
still map that to static files.  However, I cannot do the same with =
the “rel” parameter, thus we could never mandate that if we =
want to have any hope at all for allowing static =
sites.
 
I appreciate having the “resource” parameter, but I also =
appreciate some do not need (or have the ability to support) an =
elaborate server.
 
Paul
 
From:=
 =
apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of John Bradley
Sent: Monday, April 23, 2012 =
12:19 PM
To: Bob Wyman
Cc: =
apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger / =
SWD Issue #3: direct versus indirect =
discovery
 
I understand =
that in some environments you may not have access to http rewrite rules. =
 
Others may preclude any =
scripts.
 
We do have to decide what environments we are going to =
support.
 
If we stick to static files only then we are just =
putting some lipstick on Yadis by adding a way to map a email like =
address to a file.
 
So yes there are those environments, but that needs to =
be balanced against the additional overhead on the clients to support =
that environment.
 
John B.
 
On =
2012-04-23, at 12:26 PM, Bob Wyman wrote:


 
On Mon, Apr 23, 2012 at 11:08 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Mike,
 
I =
think there is less resistance to making resource parameter REQUIRED =
than there is to removing the initial host-meta lookup to get the =
template.
 
We should probably keep those issues =
separate.
 
I =
agree that supporting indirect discovery of the template via =
host-meta.jason should probably stay.
 
The question is if their can be an optimization that =
allows shortcutting that step if you know that all you want is web =
finger.
 
A =
possible option for that could be using a fixed template in /.well-known/.
 
That endpoint would =
return:
a The terminal JRD =
(like SWD)
b a 3xx =
redirect to the real endpoint
Causing a 3xx redirect typically requires modification =
to the configuration files of a multi-host shared web server. Access to =
such configuration files is often restricted in such a way that those =
responsible from just one or a few of the sites sharing the common =
server are not permitted to make modifications to those files. In many =
cases, such modifications can be requested and will only be made after =
lengthy delays or the payment of support and maintenance =
fees. 
 
If we want this sort of discovery to become generally =
available, and not just be limited to the "large" sites, we =
should ensure that it is as simple as possible to =
deploy.
 
c a copy of the =
host-meta.jrd
 
We would probably only do one of b or =
c.
 
c =
has the advantage of being a static file and you being no worse off than =
having started with host-meta.json.
b is the simplest for the client and only requires =
common rewriting rules.
 
If the redirect is to the same host you could avoid =
the overhead of two connections by pipelining the requests over the same =
TCP connection.
SPDY in =
the future will make that even more =
efficient.
 
I =
will grant Blaine that most openID Connect discovery requests are Server =
to Server,  However there are Apps that are also clients that =
should not be ignored.
I =
personally like the fixed template with a 3xx redirect and =
 resource parameter returning a JRD due to the simplicity of client =
coding.
 
Things needing other sorts of information about the =
host would still use host-meta or =
host-meta.json.
 
John B.
 
 
On 2012-04-23, at 1:11 AM, Mike Jones =
wrote:
 
<=
p class=3DMsoNormal>I agree with your goal of simplicity for clients.  Paul’s =
example seems about as simple as it can get for =
clients:
It shares the property with your earlier example (below) that clients =
have a no-branches code path to do =
discovery:
           &nbs=
p;   curl -s http://example.com/.well-known/host-meta|
           &nbs=
p;   awk "/lrdd/,/template/"|tr -d '\n'|sed -e =
"s/^.*template=3D'\([^']*\)'.*$/\1/"|
           &nbs=
p;   sed -e "s/{uri}/user@example.com/"|xargs curl =
–s
 
However, I challenge the assumption in your note below that servers =
using only static pages must be supported.  I just don’t =
see the requirement to implement a query parameter as being an =
impediment in practice, even for hosted domains.  I know of no =
hosting company that doesn’t provide a means of putting executable =
code behind web pages, be it PHP, Perl, Ruby, ASP, JSP, etc.  I =
know you’re trying to make the case for static pages, but in =
practice, I believe that dynamic pages are always easily =
available.
 
Assuming that we’re in an either-or situation with regard to =
either having single-GET discovery or supporting discovery using only =
static server pages (and I’d love to have someone demonstrate to =
us that we’re not), I’d take single-GET discovery for sure, =
as in some cases, it makes an appreciable difference in user interface =
latency, and per the paragraph above, I believe that dynamic queries can =
be implemented on all hosting =
platforms.
 
Assuming the WebFinger authors agree, I’d suggest that a =
logical next step would be for a -04 version of =
draft-jones-appsawg-webfinger to be published that changes support for =
the resource parameter from RECOMMENDED to REQUIRED, as that could =
provide a starting point for a common discovery =
spec.
 
           &nbs=
p;            =
;            =
            &=
nbsp;           -- =
Mike
 
P.S.  As long as draft-jones-appsawg-webfinger is being revised, =
I’d also suggest adding text making explicit what has been an =
implicit assumption in both WebFinger and SWD - that depending upon =
whether and how the client is authenticated, the set of resources =
returned may vary (as Blaine had pointed out earlier).  That could =
help deal with some of the privacy =
perceptions.
 
From:=
 apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf =
Of Blaine Cook
Sent: Sunday, April 22, 2012 2:15 =
PM
To: apps-discuss@ietf.org
Subject: [apps=
-discuss] Webfinger / SWD Issue #3: direct versus indirect =
discovery
 
This is the last issue that I've flagged as blocking a =
new Webfinger / SWD draft.
 
Mike suggested that being able to request a user's =
profile with a single request (i.e., that the /.well-known/ profile =
resource should be able to respond with full profile data immediately, =
rather than pointing at a second URL that will fulfil the request) is a =
requirement for this standard.
 
I'd like to challenge that requirement. The arguments =
for a direct discovery endpoint =
are:
 
1. Fewer requests against the server, since we save =
(in the worst-case) 50% of requests by bypassing the indirect lookup =
phase.
2. Lower =
latency for clients (e.g., mobile clients) owing to the reduced number =
of lookups.
 
The arguments for an indirect discovery endpoint =
are:
 
1. Trivial and web-standards friendly deployment for =
domains that won't host their own webfinger/swd profile servers, but =
want to enable accounts on their domains (e.g., statically hosted =
sites).
2. A =
loosening of the requirement that URLs at the bare domain must run =
dynamic scripts that respond to requests to the /.well-known/ =
path.
 
My opinion is that the approach that SWD has proposed =
for the redirect is problematic. First, the format is very similar in =
form to the HTML "meta refresh" tag that provided HTTP =
redirect support from within HTML. That format has been widely =
deprecated, and in these more enlightened times, we just use the 3xx =
response codes with Location headers, =
instead.
 
Secondly, the SWD request format means that for =
smaller sites, often those with the least resources, will end up serving =
static content in a way that's difficult to cache; certainly, more =
difficult to cache than just serving static content. This is due to the =
request parameters present in all SWD requests; those request parameters =
will bust caches.
 
As for the first argument *for* SWD's approach, I'd =
suggest we look to DNS, which uses the same indirection approach for NS =
records, relying on a (relatively) very small set of root servers to =
handle the traffic for the whole internet. Clearly, this approach works, =
and webfinger/swd servers are in a much better position to handle this =
additional traffic. Most of this traffic will be heavily cached, =
especially for the largest =
providers.
 
=

In fact, in terms of real deployments, hosting a =
script at, e.g., google.com/.well-known/simple-web-discovery is=
 much harder than hosting a script atprofiles.google.com/profile.json for all =
sorts of reasons, so it's my belief that the first argument is a red =
herring.
 
The second argument is legitimate, but only if mobile =
clients will actually be making requests to diverse webfinger/swd hosts. =
Instead, I strongly believe that we'll see the emergence of DNS-like =
servers that provide both profile hosting as well as proxy services. For =
a mobile client, the optimal approach will be to use SPDY to connect to =
a single host that performs webfinger/swd lookups on the mobile client's =
behalf, eliminating the latency =
concerns.
 
I offer that the two-step lookup can be implemented =
without conditionals on the client, whereas the direct-unless-not =
approach cannot be implemented that way (see my earlier curl example for =
proof). It's simpler, and easier to explain to the (hopefully many) =
small site owners who we'd like to implement this =
technology.
 
Thoughts? Am I missing =
something?
 
b.
_________=
______________________________________
apps-discuss mailing =
list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<=
o:p>
 

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

------=_NextPart_000_054A_01CD22F0.009320B0--


From eran@hueniverse.com  Wed Apr 25 11:34: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 A16B121F889C for ; Wed, 25 Apr 2012 11:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level: 
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJuxwdwxmaYm for ; Wed, 25 Apr 2012 11:34:02 -0700 (PDT)
Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id E865F21F88C6 for ; Wed, 25 Apr 2012 11:34:01 -0700 (PDT)
Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id 2JZy1j0040CJzpC01JZyEp; Wed, 25 Apr 2012 11:33:58 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Wed, 25 Apr 2012 11:33:58 -0700
From: Eran Hammer 
To: "Paul E. Jones" , 'William Mills' , 'Mike Jones' , "'Blaine Cook'" , "apps-discuss@ietf.org" 
Thread-Topic: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD Issue	#3: direct versus indirect discovery
Thread-Index: AQHNIxB7j0yI+NHWrkCBmkZ7+KER75ar3KDA
Date: Wed, 25 Apr 2012 18:33:57 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201009E7E@P3PWEX2MB008.ex2.secureserver.net>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <1335194949.12040.YahooMailNeo@web31812.mail.mud.yahoo.com> <053c01cd2310$7aea0b60$70be2220$@packetizer.com>
In-Reply-To: <053c01cd2310$7aea0b60$70be2220$@packetizer.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA201009E7EP3PWEX2MB008ex2_"
MIME-Version: 1.0
Subject: Re: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD	Issue	#3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 18:34:03 -0000

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA201009E7EP3PWEX2MB008ex2_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U2VydmluZyBhbnl0aGluZyBvdGhlciB0aGFuIEpSRCBvbiBob3N0LW1ldGEuanNvbiwgd2hpbGUg
bGVnYWwgSFRUUCwgaXMgb2RkLiBJIHdvdWxkIHJlamVjdCB0aGUgcmVxdWVzdCBpZiB0aGUgQWNj
ZXB0IGhlYWRlciBpcyBzcGVjaWZ5aW5nIGFueXRoaW5nIG90aGVyIHRoYW4gSlJELiBUaGUgYmVu
ZWZpdCBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgaXQgYWxsb3dzIHByb3RvY29sIHRvIGV4cGxp
Y2l0bHkgc3BlY2lmeSBob3N0LW1ldGEuanNvbiBhcyB0aGUgZGlzY292ZXJ5IGVuZHBvaW50LCB3
aGljaCBoYXMgdGhlIHNhbWUgZWZmZWN0IG9mIG1ha2luZyBKU09OIHRoZSByZXF1aXJlZCBhbmQg
b25seSBmb3JtYXQuIE9uZSBpc3N1ZSBpcyB0aGF0IHRoaXMgZG9lc27igJl0IGV4dGVuZCB0byBM
UkREIHdoaWNoIG1lYW5zLCBpZiB0aGUgc2VydmVyIGRvZXNu4oCZdCBzdXBwb3J0IHRoZSBxdWVy
eSBwYXJhbWV0ZXJzLCB0aGUgY2xpZW50IG1pZ2h0IGVuZCB1cCB3aXRoIFhNTCBpbiBMUkREIGxp
bmtzLg0KDQpXZSBzaG91bGQgZmlyc3QgZGVjaWRlIG9uIGhvdyB0byBhcHByb2FjaCB0aGUgZm9y
bWF0IGlzc3VlLCB0aGVuIGp1c3QgZ28gYW5kIHVwZGF0ZS9yZXBsYWNlIDY0MTUgYWNjb3JkaW5n
bHkuIEkgZG9u4oCZdCB0aGluayB0aGUgc2NhbGUgb2YgZXhpc3RpbmcgZGVwbG95bWVudCBpcyBz
aWduaWZpY2FudCBlbm91Z2ggdG8gcGxheSBhIG1ham9yIHJvbGUuIEl04oCZcyBvayB0byBicmVh
ayBzb21lIHN0dWZmIGZvciBhIGNsZWFuZXIsIGNsZWFyZXIgZnV0dXJlLg0KDQpFSA0KDQoNCkZy
b206IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIEUuIEpvbmVzDQpTZW50OiBXZWRuZXNk
YXksIEFwcmlsIDI1LCAyMDEyIDExOjIzIEFNDQpUbzogJ1dpbGxpYW0gTWlsbHMnOyAnTWlrZSBK
b25lcyc7ICdCbGFpbmUgQ29vayc7IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6
IFthcHBzLWRpc2N1c3NdIElzIGhvc3QtbWV0YS5qc29uIHZpYWJsZT8gUmU6IFdlYmZpbmdlciAv
IFNXRCBJc3N1ZSAjMzogZGlyZWN0IHZlcnN1cyBpbmRpcmVjdCBkaXNjb3ZlcnkNCg0KQmlsbCwN
Cg0KSG9zdC1tZXRhLmpzb24gd2FzIGludHJvZHVjZWQgaW4gUkZDIDY0MTUgYXMgYSBtZWFucyBv
ZiBzZWxlY3RpbmcgSlNPTiwgcGFydGljdWxhcmx5IHdoZW4gdGhlIGNsaWVudCBkb2VzIG5vdCBo
YXZlIHRoZSBhYmlsaXR5IHRvIGluZGljYXRlIHZpYSB0aGUg4oCcQWNjZXB04oCdIGhlYWRlciB0
aGF0IGl0IHdhbnRzIOKAnGFwcGxpY2F0aW9uL2pzb27igJ0uICBPbiBteSBzZXJ2ZXIsIEkgcmV0
dXJuIFhNTCBieSBkZWZhdWx0LiAgSSBhbHNvIGhvbm9yIHRoZSDigJxBY2NlcHTigJ0gaGVhZGVy
IGFuZCByZXR1cm4gdGhlIHR5cGUgcmVxdWVzdGVkLiAgQW5kLCBJIHN1cHBvcnQgaG9zdC1tZXRh
Lmpzb24sIHdoaWNoIHdpbGwgcmV0dXJuIEpTT04gYnkgZGVmYXVsdCAoaS5lLiwg4oCcQWNjZXB0
4oCdIGlzIOKAnCovKuKAnSksIGJ1dCBJIHN0aWxsIGhvbm9yIHRoZSDigJxBY2NlcHTigJ0gaGVh
ZGVyLiAgSSBhbHdheXMgZ2l2ZW4gcHJlZmVyZW5jZSB0byB0aGUgQWNjZXB0IGhlYWRlciwgd2hp
Y2ggSSB0aGluayBpcyBhcHByb3ByaWF0ZSwgdGhvdWdoIG5vdCBleHBsaWNpdGx5IGRvY3VtZW50
ZWQgYW55d2hlcmUuICBUaGlzIGlzIHdoZXJlIHRoZSDigJxoYWNr4oCdIHBhcnQgY29tZXMgaW4u
ICBPbmUgc2hvdWxkIGhvbm9yIHdoYXQgSFRUUCBzYXlzLCBidXQgdGhlbiBob3cgdG8gd2UgdHJl
YXQgYSByZXF1ZXN0IGJhc2VkIG9uIHRoZSBVUkkgcGF0aD8gIE5vdCBzdXJlLCBidXQgSeKAmW0g
aW5jbGluZWQgdG8gbGVhdmUgaXQgdGhhdCB3YXkgdW50aWwgc29tZWJvZHkgdGVsbHMgbWUgd2h5
IGl04oCZcyBhIGJhZCBpZGVhLg0KDQpJbiBhbnkgY2FzZSwgdGhpcyB3YXMgbm90IGludmVudGVk
IGFzIGEgcGFydCBvZiB0aGUgY3VycmVudCBkcmFmdDsgaXQgd2FzIGFscmVhZHkgZGVmaW5lZC4N
Cg0KUGF1bA0KDQpGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YXBw
cy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNA
aWV0Zi5vcmddPG1haWx0bzpbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXT4g
T24gQmVoYWxmIE9mIFdpbGxpYW0gTWlsbHMNClNlbnQ6IE1vbmRheSwgQXByaWwgMjMsIDIwMTIg
MTE6MjkgQU0NClRvOiBNaWtlIEpvbmVzOyBCbGFpbmUgQ29vazsgYXBwcy1kaXNjdXNzQGlldGYu
b3JnPG1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbYXBwcy1kaXNjdXNz
XSBJcyBob3N0LW1ldGEuanNvbiB2aWFibGU/IFJlOiBXZWJmaW5nZXIgLyBTV0QgSXNzdWUgIzM6
IGRpcmVjdCB2ZXJzdXMgaW5kaXJlY3QgZGlzY292ZXJ5DQoNCkkgbm90ZSB0aGF0IHNvbWUgZXhh
bXBsZXMgYXJlIG5vdyB1c2luZyB0aGUgY29uc3RydWN0IChFcmFuIGNhbGxlZCBpdCBhIGhhY2ss
IHdoaWNoIGl0IHByb2JhYmx5IGlzLCBidXQgSSBsaWtlIGl0KSBob3N0LW1ldGEuanNvbiB0byBz
ZWxlY3QgdGhlIGRhdGEgZm9ybWF0LiAgVGhpcyBzZWVtcyB0byBtZSB0byBiZSBhIHdvcmthYmxl
IHdheSB0bzoNCg0KLSAgICBleHRlbmQgdGhlIGN1cnJlbnQgV0Ygc3R1ZmYga2VlcGluZyBjb21w
YXRpYmlsaXR5DQotICAgIHN1cHBvcnQgZm9yIEpTT04gd2l0aG91dCBmdW5reSBsb2dpYw0KLSAg
ICBhbGxvdyB0aGUgY2xpZW50cyB0byBpbXBsZW1lbnQgYSBzaW5nbGUgc2ltcGxlIGNvZGUgcGF0
aA0KDQotYmlsbA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogTWlr
ZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVz
QG1pY3Jvc29mdC5jb20+Pg0KVG86IEJsYWluZSBDb29rIDxyb21lZGFAZ21haWwuY29tPG1haWx0
bzpyb21lZGFAZ21haWwuY29tPj47ICJhcHBzLWRpc2N1c3NAaWV0Zi5vcmc8bWFpbHRvOmFwcHMt
ZGlzY3Vzc0BpZXRmLm9yZz4iIDxhcHBzLWRpc2N1c3NAaWV0Zi5vcmc8bWFpbHRvOmFwcHMtZGlz
Y3Vzc0BpZXRmLm9yZz4+DQpTZW50OiBTdW5kYXksIEFwcmlsIDIyLCAyMDEyIDk6MTEgUE0NClN1
YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBXZWJmaW5nZXIgLyBTV0QgSXNzdWUgIzM6IGRpcmVj
dCB2ZXJzdXMgaW5kaXJlY3QgZGlzY292ZXJ5DQoNCkkgYWdyZWUgd2l0aCB5b3VyIGdvYWwgb2Yg
c2ltcGxpY2l0eSBmb3IgY2xpZW50cy4gIFBhdWzigJlzIGV4YW1wbGUgc2VlbXMgYWJvdXQgYXMg
c2ltcGxlIGFzIGl0IGNhbiBnZXQgZm9yIGNsaWVudHM6DQogICAgICAgICAgICAgICBjdXJsIC12
IGh0dHBzOi8vcGFja2V0aXplci5jb20vLndlbGwta25vd24vaG9zdC1tZXRhLmpzb24/cmVzb3Vy
Y2U9YWNjdDpwYXVsZWpAcGFja2V0aXplci5jb20NCkl0IHNoYXJlcyB0aGUgcHJvcGVydHkgd2l0
aCB5b3VyIGVhcmxpZXIgZXhhbXBsZSAoYmVsb3cpIHRoYXQgY2xpZW50cyBoYXZlIGEgbm8tYnJh
bmNoZXMgY29kZSBwYXRoIHRvIGRvIGRpc2NvdmVyeToNCiAgICAgICAgICAgICAgIGN1cmwgLXMg
aHR0cDovL2V4YW1wbGUuY29tLy53ZWxsLWtub3duL2hvc3QtbWV0YXw8aHR0cDovL2V4YW1wbGUu
Y29tLy53ZWxsLWtub3duL2hvc3QtbWV0YSU3Qz4NCiAgICAgICAgICAgICAgIGF3ayAiL2xyZGQv
LC90ZW1wbGF0ZS8ifHRyIC1kICdcbid8c2VkIC1lICJzL14uKnRlbXBsYXRlPSdcKFteJ10qXCkn
LiokL1wxLyJ8DQogICAgICAgICAgICAgICBzZWQgLWUgInMve3VyaX0vdXNlckBleGFtcGxlLmNv
bS88bWFpbHRvOnMvJTdidXJpJTdkL3VzZXJAZXhhbXBsZS5jb20vPiJ8eGFyZ3MgY3VybCDigJNz
DQoNCkhvd2V2ZXIsIEkgY2hhbGxlbmdlIHRoZSBhc3N1bXB0aW9uIGluIHlvdXIgbm90ZSBiZWxv
dyB0aGF0IHNlcnZlcnMgdXNpbmcgb25seSBzdGF0aWMgcGFnZXMgbXVzdCBiZSBzdXBwb3J0ZWQu
ICBJIGp1c3QgZG9u4oCZdCBzZWUgdGhlIHJlcXVpcmVtZW50IHRvIGltcGxlbWVudCBhIHF1ZXJ5
IHBhcmFtZXRlciBhcyBiZWluZyBhbiBpbXBlZGltZW50IGluIHByYWN0aWNlLCBldmVuIGZvciBo
b3N0ZWQgZG9tYWlucy4gIEkga25vdyBvZiBubyBob3N0aW5nIGNvbXBhbnkgdGhhdCBkb2VzbuKA
mXQgcHJvdmlkZSBhIG1lYW5zIG9mIHB1dHRpbmcgZXhlY3V0YWJsZSBjb2RlIGJlaGluZCB3ZWIg
cGFnZXMsIGJlIGl0IFBIUCwgUGVybCwgUnVieSwgQVNQLCBKU1AsIGV0Yy4gIEkga25vdyB5b3Xi
gJlyZSB0cnlpbmcgdG8gbWFrZSB0aGUgY2FzZSBmb3Igc3RhdGljIHBhZ2VzLCBidXQgaW4gcHJh
Y3RpY2UsIEkgYmVsaWV2ZSB0aGF0IGR5bmFtaWMgcGFnZXMgYXJlIGFsd2F5cyBlYXNpbHkgYXZh
aWxhYmxlLg0KDQpBc3N1bWluZyB0aGF0IHdl4oCZcmUgaW4gYW4gZWl0aGVyLW9yIHNpdHVhdGlv
biB3aXRoIHJlZ2FyZCB0byBlaXRoZXIgaGF2aW5nIHNpbmdsZS1HRVQgZGlzY292ZXJ5IG9yIHN1
cHBvcnRpbmcgZGlzY292ZXJ5IHVzaW5nIG9ubHkgc3RhdGljIHNlcnZlciBwYWdlcyAoYW5kIEni
gJlkIGxvdmUgdG8gaGF2ZSBzb21lb25lIGRlbW9uc3RyYXRlIHRvIHVzIHRoYXQgd2XigJlyZSBu
b3QpLCBJ4oCZZCB0YWtlIHNpbmdsZS1HRVQgZGlzY292ZXJ5IGZvciBzdXJlLCBhcyBpbiBzb21l
IGNhc2VzLCBpdCBtYWtlcyBhbiBhcHByZWNpYWJsZSBkaWZmZXJlbmNlIGluIHVzZXIgaW50ZXJm
YWNlIGxhdGVuY3ksIGFuZCBwZXIgdGhlIHBhcmFncmFwaCBhYm92ZSwgSSBiZWxpZXZlIHRoYXQg
ZHluYW1pYyBxdWVyaWVzIGNhbiBiZSBpbXBsZW1lbnRlZCBvbiBhbGwgaG9zdGluZyBwbGF0Zm9y
bXMuDQoNCkFzc3VtaW5nIHRoZSBXZWJGaW5nZXIgYXV0aG9ycyBhZ3JlZSwgSeKAmWQgc3VnZ2Vz
dCB0aGF0IGEgbG9naWNhbCBuZXh0IHN0ZXAgd291bGQgYmUgZm9yIGEgLTA0IHZlcnNpb24gb2Yg
ZHJhZnQtam9uZXMtYXBwc2F3Zy13ZWJmaW5nZXIgdG8gYmUgcHVibGlzaGVkIHRoYXQgY2hhbmdl
cyBzdXBwb3J0IGZvciB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIGZyb20gUkVDT01NRU5ERUQgdG8g
UkVRVUlSRUQsIGFzIHRoYXQgY291bGQgcHJvdmlkZSBhIHN0YXJ0aW5nIHBvaW50IGZvciBhIGNv
bW1vbiBkaXNjb3Zlcnkgc3BlYy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpQLlMuICBBcyBsb25nIGFzIGRy
YWZ0LWpvbmVzLWFwcHNhd2ctd2ViZmluZ2VyIGlzIGJlaW5nIHJldmlzZWQsIEnigJlkIGFsc28g
c3VnZ2VzdCBhZGRpbmcgdGV4dCBtYWtpbmcgZXhwbGljaXQgd2hhdCBoYXMgYmVlbiBhbiBpbXBs
aWNpdCBhc3N1bXB0aW9uIGluIGJvdGggV2ViRmluZ2VyIGFuZCBTV0QgLSB0aGF0IGRlcGVuZGlu
ZyB1cG9uIHdoZXRoZXIgYW5kIGhvdyB0aGUgY2xpZW50IGlzIGF1dGhlbnRpY2F0ZWQsIHRoZSBz
ZXQgb2YgcmVzb3VyY2VzIHJldHVybmVkIG1heSB2YXJ5IChhcyBCbGFpbmUgaGFkIHBvaW50ZWQg
b3V0IGVhcmxpZXIpLiAgVGhhdCBjb3VsZCBoZWxwIGRlYWwgd2l0aCBzb21lIG9mIHRoZSBwcml2
YWN5IHBlcmNlcHRpb25zLg0KDQpGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzxt
YWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86YXBwcy1kaXNjdXNz
LWJvdW5jZXNAaWV0Zi5vcmddPG1haWx0bzpbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGll
dGYub3JnXT4gT24gQmVoYWxmIE9mIEJsYWluZSBDb29rDQpTZW50OiBTdW5kYXksIEFwcmlsIDIy
LCAyMDEyIDI6MTUgUE0NClRvOiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmc8bWFpbHRvOmFwcHMtZGlz
Y3Vzc0BpZXRmLm9yZz4NClN1YmplY3Q6IFthcHBzLWRpc2N1c3NdIFdlYmZpbmdlciAvIFNXRCBJ
c3N1ZSAjMzogZGlyZWN0IHZlcnN1cyBpbmRpcmVjdCBkaXNjb3ZlcnkNCg0KVGhpcyBpcyB0aGUg
bGFzdCBpc3N1ZSB0aGF0IEkndmUgZmxhZ2dlZCBhcyBibG9ja2luZyBhIG5ldyBXZWJmaW5nZXIg
LyBTV0QgZHJhZnQuDQoNCk1pa2Ugc3VnZ2VzdGVkIHRoYXQgYmVpbmcgYWJsZSB0byByZXF1ZXN0
IGEgdXNlcidzIHByb2ZpbGUgd2l0aCBhIHNpbmdsZSByZXF1ZXN0IChpLmUuLCB0aGF0IHRoZSAv
LndlbGwta25vd24vIHByb2ZpbGUgcmVzb3VyY2Ugc2hvdWxkIGJlIGFibGUgdG8gcmVzcG9uZCB3
aXRoIGZ1bGwgcHJvZmlsZSBkYXRhIGltbWVkaWF0ZWx5LCByYXRoZXIgdGhhbiBwb2ludGluZyBh
dCBhIHNlY29uZCBVUkwgdGhhdCB3aWxsIGZ1bGZpbCB0aGUgcmVxdWVzdCkgaXMgYSByZXF1aXJl
bWVudCBmb3IgdGhpcyBzdGFuZGFyZC4NCg0KSSdkIGxpa2UgdG8gY2hhbGxlbmdlIHRoYXQgcmVx
dWlyZW1lbnQuIFRoZSBhcmd1bWVudHMgZm9yIGEgZGlyZWN0IGRpc2NvdmVyeSBlbmRwb2ludCBh
cmU6DQoNCjEuIEZld2VyIHJlcXVlc3RzIGFnYWluc3QgdGhlIHNlcnZlciwgc2luY2Ugd2Ugc2F2
ZSAoaW4gdGhlIHdvcnN0LWNhc2UpIDUwJSBvZiByZXF1ZXN0cyBieSBieXBhc3NpbmcgdGhlIGlu
ZGlyZWN0IGxvb2t1cCBwaGFzZS4NCjIuIExvd2VyIGxhdGVuY3kgZm9yIGNsaWVudHMgKGUuZy4s
IG1vYmlsZSBjbGllbnRzKSBvd2luZyB0byB0aGUgcmVkdWNlZCBudW1iZXIgb2YgbG9va3Vwcy4N
Cg0KVGhlIGFyZ3VtZW50cyBmb3IgYW4gaW5kaXJlY3QgZGlzY292ZXJ5IGVuZHBvaW50IGFyZToN
Cg0KMS4gVHJpdmlhbCBhbmQgd2ViLXN0YW5kYXJkcyBmcmllbmRseSBkZXBsb3ltZW50IGZvciBk
b21haW5zIHRoYXQgd29uJ3QgaG9zdCB0aGVpciBvd24gd2ViZmluZ2VyL3N3ZCBwcm9maWxlIHNl
cnZlcnMsIGJ1dCB3YW50IHRvIGVuYWJsZSBhY2NvdW50cyBvbiB0aGVpciBkb21haW5zIChlLmcu
LCBzdGF0aWNhbGx5IGhvc3RlZCBzaXRlcykuDQoyLiBBIGxvb3NlbmluZyBvZiB0aGUgcmVxdWly
ZW1lbnQgdGhhdCBVUkxzIGF0IHRoZSBiYXJlIGRvbWFpbiBtdXN0IHJ1biBkeW5hbWljIHNjcmlw
dHMgdGhhdCByZXNwb25kIHRvIHJlcXVlc3RzIHRvIHRoZSAvLndlbGwta25vd24vIHBhdGguDQoN
Ck15IG9waW5pb24gaXMgdGhhdCB0aGUgYXBwcm9hY2ggdGhhdCBTV0QgaGFzIHByb3Bvc2VkIGZv
ciB0aGUgcmVkaXJlY3QgaXMgcHJvYmxlbWF0aWMuIEZpcnN0LCB0aGUgZm9ybWF0IGlzIHZlcnkg
c2ltaWxhciBpbiBmb3JtIHRvIHRoZSBIVE1MICJtZXRhIHJlZnJlc2giIHRhZyB0aGF0IHByb3Zp
ZGVkIEhUVFAgcmVkaXJlY3Qgc3VwcG9ydCBmcm9tIHdpdGhpbiBIVE1MLiBUaGF0IGZvcm1hdCBo
YXMgYmVlbiB3aWRlbHkgZGVwcmVjYXRlZCwgYW5kIGluIHRoZXNlIG1vcmUgZW5saWdodGVuZWQg
dGltZXMsIHdlIGp1c3QgdXNlIHRoZSAzeHggcmVzcG9uc2UgY29kZXMgd2l0aCBMb2NhdGlvbiBo
ZWFkZXJzLCBpbnN0ZWFkLg0KDQpTZWNvbmRseSwgdGhlIFNXRCByZXF1ZXN0IGZvcm1hdCBtZWFu
cyB0aGF0IGZvciBzbWFsbGVyIHNpdGVzLCBvZnRlbiB0aG9zZSB3aXRoIHRoZSBsZWFzdCByZXNv
dXJjZXMsIHdpbGwgZW5kIHVwIHNlcnZpbmcgc3RhdGljIGNvbnRlbnQgaW4gYSB3YXkgdGhhdCdz
IGRpZmZpY3VsdCB0byBjYWNoZTsgY2VydGFpbmx5LCBtb3JlIGRpZmZpY3VsdCB0byBjYWNoZSB0
aGFuIGp1c3Qgc2VydmluZyBzdGF0aWMgY29udGVudC4gVGhpcyBpcyBkdWUgdG8gdGhlIHJlcXVl
c3QgcGFyYW1ldGVycyBwcmVzZW50IGluIGFsbCBTV0QgcmVxdWVzdHM7IHRob3NlIHJlcXVlc3Qg
cGFyYW1ldGVycyB3aWxsIGJ1c3QgY2FjaGVzLg0KDQpBcyBmb3IgdGhlIGZpcnN0IGFyZ3VtZW50
ICpmb3IqIFNXRCdzIGFwcHJvYWNoLCBJJ2Qgc3VnZ2VzdCB3ZSBsb29rIHRvIEROUywgd2hpY2gg
dXNlcyB0aGUgc2FtZSBpbmRpcmVjdGlvbiBhcHByb2FjaCBmb3IgTlMgcmVjb3JkcywgcmVseWlu
ZyBvbiBhIChyZWxhdGl2ZWx5KSB2ZXJ5IHNtYWxsIHNldCBvZiByb290IHNlcnZlcnMgdG8gaGFu
ZGxlIHRoZSB0cmFmZmljIGZvciB0aGUgd2hvbGUgaW50ZXJuZXQuIENsZWFybHksIHRoaXMgYXBw
cm9hY2ggd29ya3MsIGFuZCB3ZWJmaW5nZXIvc3dkIHNlcnZlcnMgYXJlIGluIGEgbXVjaCBiZXR0
ZXIgcG9zaXRpb24gdG8gaGFuZGxlIHRoaXMgYWRkaXRpb25hbCB0cmFmZmljLiBNb3N0IG9mIHRo
aXMgdHJhZmZpYyB3aWxsIGJlIGhlYXZpbHkgY2FjaGVkLCBlc3BlY2lhbGx5IGZvciB0aGUgbGFy
Z2VzdCBwcm92aWRlcnMuDQoNCkluIGZhY3QsIGluIHRlcm1zIG9mIHJlYWwgZGVwbG95bWVudHMs
IGhvc3RpbmcgYSBzY3JpcHQgYXQsIGUuZy4sIGdvb2dsZS5jb20vLndlbGwta25vd24vc2ltcGxl
LXdlYi1kaXNjb3Zlcnk8aHR0cDovL2dvb2dsZS5jb20vLndlbGwta25vd24vc2ltcGxlLXdlYi1k
aXNjb3Zlcnk+IGlzIG11Y2ggaGFyZGVyIHRoYW4gaG9zdGluZyBhIHNjcmlwdCBhdCBwcm9maWxl
cy5nb29nbGUuY29tL3Byb2ZpbGUuanNvbjxodHRwOi8vcHJvZmlsZXMuZ29vZ2xlLmNvbS9wcm9m
aWxlLmpzb24+IGZvciBhbGwgc29ydHMgb2YgcmVhc29ucywgc28gaXQncyBteSBiZWxpZWYgdGhh
dCB0aGUgZmlyc3QgYXJndW1lbnQgaXMgYSByZWQgaGVycmluZy4NCg0KVGhlIHNlY29uZCBhcmd1
bWVudCBpcyBsZWdpdGltYXRlLCBidXQgb25seSBpZiBtb2JpbGUgY2xpZW50cyB3aWxsIGFjdHVh
bGx5IGJlIG1ha2luZyByZXF1ZXN0cyB0byBkaXZlcnNlIHdlYmZpbmdlci9zd2QgaG9zdHMuIElu
c3RlYWQsIEkgc3Ryb25nbHkgYmVsaWV2ZSB0aGF0IHdlJ2xsIHNlZSB0aGUgZW1lcmdlbmNlIG9m
IEROUy1saWtlIHNlcnZlcnMgdGhhdCBwcm92aWRlIGJvdGggcHJvZmlsZSBob3N0aW5nIGFzIHdl
bGwgYXMgcHJveHkgc2VydmljZXMuIEZvciBhIG1vYmlsZSBjbGllbnQsIHRoZSBvcHRpbWFsIGFw
cHJvYWNoIHdpbGwgYmUgdG8gdXNlIFNQRFkgdG8gY29ubmVjdCB0byBhIHNpbmdsZSBob3N0IHRo
YXQgcGVyZm9ybXMgd2ViZmluZ2VyL3N3ZCBsb29rdXBzIG9uIHRoZSBtb2JpbGUgY2xpZW50J3Mg
YmVoYWxmLCBlbGltaW5hdGluZyB0aGUgbGF0ZW5jeSBjb25jZXJucy4NCg0KSSBvZmZlciB0aGF0
IHRoZSB0d28tc3RlcCBsb29rdXAgY2FuIGJlIGltcGxlbWVudGVkIHdpdGhvdXQgY29uZGl0aW9u
YWxzIG9uIHRoZSBjbGllbnQsIHdoZXJlYXMgdGhlIGRpcmVjdC11bmxlc3Mtbm90IGFwcHJvYWNo
IGNhbm5vdCBiZSBpbXBsZW1lbnRlZCB0aGF0IHdheSAoc2VlIG15IGVhcmxpZXIgY3VybCBleGFt
cGxlIGZvciBwcm9vZikuIEl0J3Mgc2ltcGxlciwgYW5kIGVhc2llciB0byBleHBsYWluIHRvIHRo
ZSAoaG9wZWZ1bGx5IG1hbnkpIHNtYWxsIHNpdGUgb3duZXJzIHdobyB3ZSdkIGxpa2UgdG8gaW1w
bGVtZW50IHRoaXMgdGVjaG5vbG9neS4NCg0KVGhvdWdodHM/IEFtIEkgbWlzc2luZyBzb21ldGhp
bmc/DQoNCmIuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQphcHBzLWRpc2N1c3MgbWFpbGluZyBsaXN0DQphcHBzLWRpc2N1c3NAaWV0Zi5vcmc8bWFp
bHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vYXBwcy1kaXNjdXNzDQo=

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA201009E7EP3PWEX2MB008ex2_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K
CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov
DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p
bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ
e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo
YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4
LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29u
VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m
YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAueWl2MTc0NzA4NTM2OW1zb25vcm1hbCwg
bGkueWl2MTc0NzA4NTM2OW1zb25vcm1hbCwgZGl2LnlpdjE3NDcwODUzNjltc29ub3JtYWwNCgl7
bXNvLXN0eWxlLW5hbWU6eWl2MTc0NzA4NTM2OW1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU
aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC55aXYxNzQ3MDg1MzY5bXNvbm9ybWFsMSwgbGku
eWl2MTc0NzA4NTM2OW1zb25vcm1hbDEsIGRpdi55aXYxNzQ3MDg1MzY5bXNvbm9ybWFsMQ0KCXtt
c28tc3R5bGUtbmFtZTp5aXYxNzQ3MDg1MzY5bXNvbm9ybWFsMTsNCgltYXJnaW46MGluOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU
aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi50YWINCgl7bXNvLXN0eWxlLW5hbWU6dGFi
O30NCnNwYW4ueWl2MTc0NzA4NTM2OW1zb2h5cGVybGluaw0KCXttc28tc3R5bGUtbmFtZTp5aXYx
NzQ3MDg1MzY5bXNvaHlwZXJsaW5rO30NCnNwYW4ueWl2MTc0NzA4NTM2OW1zb2h5cGVybGlua2Zv
bGxvd2VkDQoJe21zby1zdHlsZS1uYW1lOnlpdjE3NDcwODUzNjltc29oeXBlcmxpbmtmb2xsb3dl
ZDt9DQpzcGFuLnlpdjE3NDcwODUzNjllbWFpbHN0eWxlMTcNCgl7bXNvLXN0eWxlLW5hbWU6eWl2
MTc0NzA4NTM2OWVtYWlsc3R5bGUxNzt9DQpzcGFuLnlpdjE3NDcwODUzNjltc29oeXBlcmxpbmsx
DQoJe21zby1zdHlsZS1uYW1lOnlpdjE3NDcwODUzNjltc29oeXBlcmxpbmsxOw0KCWNvbG9yOmJs
dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLnlpdjE3NDcwODUzNjltc29o
eXBlcmxpbmtmb2xsb3dlZDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTc0NzA4NTM2OW1zb2h5cGVy
bGlua2ZvbGxvd2VkMTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTt9DQpzcGFuLnlpdjE3NDcwODUzNjllbWFpbHN0eWxlMTcxDQoJe21zby1zdHlsZS1uYW1lOnlp
djE3NDcwODUzNjllbWFpbHN0eWxlMTcxOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy
aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv
cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG
NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm
b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp
bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K
CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s
PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl
eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs
YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu
az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPlNlcnZpbmcgYW55dGhpbmcgb3RoZXIgdGhhbiBKUkQgb24gaG9zdC1tZXRhLmpzb24sIHdo
aWxlIGxlZ2FsIEhUVFAsIGlzIG9kZC4gSSB3b3VsZCByZWplY3QgdGhlIHJlcXVlc3QgaWYgdGhl
IEFjY2VwdCBoZWFkZXIgaXMgc3BlY2lmeWluZyBhbnl0aGluZyBvdGhlciB0aGFuDQogSlJELiBU
aGUgYmVuZWZpdCBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgaXQgYWxsb3dzIHByb3RvY29sIHRv
IGV4cGxpY2l0bHkgc3BlY2lmeSBob3N0LW1ldGEuanNvbiBhcyB0aGUgZGlzY292ZXJ5IGVuZHBv
aW50LCB3aGljaCBoYXMgdGhlIHNhbWUgZWZmZWN0IG9mIG1ha2luZyBKU09OIHRoZSByZXF1aXJl
ZCBhbmQgb25seSBmb3JtYXQuIE9uZSBpc3N1ZSBpcyB0aGF0IHRoaXMgZG9lc27igJl0IGV4dGVu
ZCB0byBMUkREIHdoaWNoIG1lYW5zLCBpZg0KIHRoZSBzZXJ2ZXIgZG9lc27igJl0IHN1cHBvcnQg
dGhlIHF1ZXJ5IHBhcmFtZXRlcnMsIHRoZSBjbGllbnQgbWlnaHQgZW5kIHVwIHdpdGggWE1MIGlu
IExSREQgbGlua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBzaG91bGQgZmlyc3QgZGVjaWRlIG9uIGhvdyB0byBh
cHByb2FjaCB0aGUgZm9ybWF0IGlzc3VlLCB0aGVuIGp1c3QgZ28gYW5kIHVwZGF0ZS9yZXBsYWNl
IDY0MTUgYWNjb3JkaW5nbHkuIEkgZG9u4oCZdCB0aGluayB0aGUgc2NhbGUgb2YgZXhpc3Rpbmcg
ZGVwbG95bWVudA0KIGlzIHNpZ25pZmljYW50IGVub3VnaCB0byBwbGF5IGEgbWFqb3Igcm9sZS4g
SXTigJlzIG9rIHRvIGJyZWFrIHNvbWUgc3R1ZmYgZm9yIGEgY2xlYW5lciwgY2xlYXJlciBmdXR1
cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5FSDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk
aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gYXBwcy1kaXNjdXNzLWJv
dW5jZXNAaWV0Zi5vcmcgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10NCjxi
Pk9uIEJlaGFsZiBPZiA8L2I+UGF1bCBFLiBKb25lczxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNk
YXksIEFwcmlsIDI1LCAyMDEyIDExOjIzIEFNPGJyPg0KPGI+VG86PC9iPiAnV2lsbGlhbSBNaWxs
cyc7ICdNaWtlIEpvbmVzJzsgJ0JsYWluZSBDb29rJzsgYXBwcy1kaXNjdXNzQGlldGYub3JnPGJy
Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbYXBwcy1kaXNjdXNzXSBJcyBob3N0LW1ldGEuanNvbiB2
aWFibGU/IFJlOiBXZWJmaW5nZXIgLyBTV0QgSXNzdWUgIzM6IGRpcmVjdCB2ZXJzdXMgaW5kaXJl
Y3QgZGlzY292ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJpbGwsPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5Ib3N0LW1ldGEuanNvbiB3YXMgaW50cm9kdWNlZCBpbiBSRkMgNjQxNSBhcyBhIG1lYW5z
IG9mIHNlbGVjdGluZyBKU09OLCBwYXJ0aWN1bGFybHkgd2hlbiB0aGUgY2xpZW50IGRvZXMgbm90
IGhhdmUgdGhlIGFiaWxpdHkgdG8gaW5kaWNhdGUgdmlhIHRoZSDigJxBY2NlcHTigJ0NCiBoZWFk
ZXIgdGhhdCBpdCB3YW50cyDigJxhcHBsaWNhdGlvbi9qc29u4oCdLiZuYnNwOyBPbiBteSBzZXJ2
ZXIsIEkgcmV0dXJuIFhNTCBieSBkZWZhdWx0LiZuYnNwOyBJIGFsc28gaG9ub3IgdGhlIOKAnEFj
Y2VwdOKAnSBoZWFkZXIgYW5kIHJldHVybiB0aGUgdHlwZSByZXF1ZXN0ZWQuJm5ic3A7IEFuZCwg
SSBzdXBwb3J0IGhvc3QtbWV0YS5qc29uLCB3aGljaCB3aWxsIHJldHVybiBKU09OIGJ5IGRlZmF1
bHQgKGkuZS4sIOKAnEFjY2VwdOKAnSBpcyDigJwqLyrigJ0pLCBidXQgSSBzdGlsbCBob25vcg0K
IHRoZSDigJxBY2NlcHTigJ0gaGVhZGVyLiZuYnNwOyBJIGFsd2F5cyBnaXZlbiBwcmVmZXJlbmNl
IHRvIHRoZSBBY2NlcHQgaGVhZGVyLCB3aGljaCBJIHRoaW5rIGlzIGFwcHJvcHJpYXRlLCB0aG91
Z2ggbm90IGV4cGxpY2l0bHkgZG9jdW1lbnRlZCBhbnl3aGVyZS4mbmJzcDsgVGhpcyBpcyB3aGVy
ZSB0aGUg4oCcaGFja+KAnSBwYXJ0IGNvbWVzIGluLiZuYnNwOyBPbmUgc2hvdWxkIGhvbm9yIHdo
YXQgSFRUUCBzYXlzLCBidXQgdGhlbiBob3cgdG8gd2UgdHJlYXQgYSByZXF1ZXN0IGJhc2VkDQog
b24gdGhlIFVSSSBwYXRoPyZuYnNwOyBOb3Qgc3VyZSwgYnV0IEnigJltIGluY2xpbmVkIHRvIGxl
YXZlIGl0IHRoYXQgd2F5IHVudGlsIHNvbWVib2R5IHRlbGxzIG1lIHdoeSBpdOKAmXMgYSBiYWQg
aWRlYS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkluIGFueSBjYXNlLCB0aGlzIHdhcyBub3QgaW52ZW50ZWQgYXMgYSBw
YXJ0IG9mIHRoZSBjdXJyZW50IGRyYWZ0OyBpdCB3YXMgYWxyZWFkeSBkZWZpbmVkLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+UGF1bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl
IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp
biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEg
aHJlZj0ibWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIj5hcHBzLWRpc2N1c3Mt
Ym91bmNlc0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86YXBwcy1kaXNjdXNz
LWJvdW5jZXNAaWV0Zi5vcmddIj4NClttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5v
cmddPC9hPiA8Yj5PbiBCZWhhbGYgT2YgPC9iPldpbGxpYW0gTWlsbHM8YnI+DQo8Yj5TZW50Ojwv
Yj4gTW9uZGF5LCBBcHJpbCAyMywgMjAxMiAxMToyOSBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBK
b25lczsgQmxhaW5lIENvb2s7IDxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmci
PmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2FwcHMtZGlz
Y3Vzc10gSXMgaG9zdC1tZXRhLmpzb24gdmlhYmxlPyBSZTogV2ViZmluZ2VyIC8gU1dEIElzc3Vl
ICMzOiBkaXJlY3QgdmVyc3VzIGluZGlyZWN0IGRpc2NvdmVyeTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91
bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JIG5vdGUgdGhhdCBzb21lIGV4YW1wbGVz
IGFyZSBub3cgdXNpbmcgdGhlIGNvbnN0cnVjdCAoRXJhbiBjYWxsZWQgaXQgYSBoYWNrLCB3aGlj
aCBpdCBwcm9iYWJseSBpcywgYnV0IEkgbGlrZSBpdCkgaG9zdC1tZXRhLmpzb24gdG8gc2VsZWN0
IHRoZQ0KIGRhdGEgZm9ybWF0LiZuYnNwOyBUaGlzIHNlZW1zIHRvIG1lIHRvIGJlIGEgd29ya2Fi
bGUgd2F5IHRvOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj
ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr
Ij4tPHNwYW4gY2xhc3M9InRhYiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ZXh0ZW5kIHRo
ZSBjdXJyZW50IFdGIHN0dWZmIGtlZXBpbmcgY29tcGF0aWJpbGl0eSA8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPi08c3BhbiBjbGFzcz0idGFiIj4mbmJz
cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5zdXBwb3J0IGZvciBKU09OIHdpdGhvdXQgZnVua3kgbG9n
aWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPi08c3Bh
biBjbGFzcz0idGFiIj4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5hbGxvdyB0aGUgY2xpZW50
cyB0byBpbXBsZW1lbnQgYSBzaW5nbGUgc2ltcGxlIGNvZGUgcGF0aDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91
bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4tYmlsbDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2lu
LWxlZnQ6My43NXB0O21hcmdpbi10b3A6My43NXB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y
OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu
OmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6YmxhY2siPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwv
c3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IE1pa2UgSm9uZXMgJmx0
OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+VG86PC9iPiBCbGFpbmUgQ29vayAmbHQ7
PGEgaHJlZj0ibWFpbHRvOnJvbWVkYUBnbWFpbC5jb20iPnJvbWVkYUBnbWFpbC5jb208L2E+Jmd0
OzsgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZyI+YXBwcy1kaXNj
dXNzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFwcHMtZGlzY3Vzc0Bp
ZXRmLm9yZyI+YXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9i
PiBTdW5kYXksIEFwcmlsIDIyLCAyMDEyIDk6MTEgUE08YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6
IFthcHBzLWRpc2N1c3NdIFdlYmZpbmdlciAvIFNXRCBJc3N1ZSAjMzogZGlyZWN0IHZlcnN1cyBp
bmRpcmVjdCBkaXNjb3Zlcnk8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr
Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxkaXYgaWQ9InlpdjE3NDcwODUzNjkiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCB5b3VyIGdv
YWwgb2Ygc2ltcGxpY2l0eSBmb3IgY2xpZW50cy4mbmJzcDsgUGF1bOKAmXMgZXhhbXBsZSBzZWVt
cyBhYm91dCBhcyBzaW1wbGUgYXMgaXQgY2FuIGdldCBmb3IgY2xpZW50czo8L3NwYW4+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IGN1cmwgLXYNCjxhIGhyZWY9Imh0dHBzOi8vcGFja2V0aXplci5jb20vLndlbGwta25v
d24vaG9zdC1tZXRhLmpzb24/cmVzb3VyY2U9YWNjdDpwYXVsZWpAcGFja2V0aXplci5jb20iIHRh
cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vcGFja2V0aXplci5jb20vLndlbGwta25vd24vaG9zdC1t
ZXRhLmpzb24/cmVzb3VyY2U9YWNjdDpwYXVsZWpAcGFja2V0aXplci5jb208L2E+PC9zcGFuPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkl0IHNoYXJlcyB0aGUgcHJv
cGVydHkgd2l0aCB5b3VyIGVhcmxpZXIgZXhhbXBsZSAoYmVsb3cpIHRoYXQgY2xpZW50cyBoYXZl
IGEgbm8tYnJhbmNoZXMgY29kZSBwYXRoIHRvIGRvIGRpc2NvdmVyeTo8L3NwYW4+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGN1cmwgLXMNCjxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbS8ud2VsbC1rbm93bi9ob3N0
LW1ldGElN0MiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZXhhbXBsZS5jb20vLndlbGwta25vd24v
aG9zdC1tZXRhfDwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFG
NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF3ayAmcXVvdDsvbHJkZC8sL3RlbXBs
YXRlLyZxdW90O3x0ciAtZCAnXG4nfHNlZCAtZSAmcXVvdDtzL14uKnRlbXBsYXRlPSdcKFteJ10q
XCknLiokL1wxLyZxdW90O3w8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6
IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlZCAtZSAmcXVvdDs8YSBocmVm
PSJtYWlsdG86cy8lN2J1cmklN2QvdXNlckBleGFtcGxlLmNvbS8iPnMve3VyaX0vdXNlckBleGFt
cGxlLmNvbS88L2E+JnF1b3Q7fHhhcmdzIGN1cmwg4oCTczwvc3Bhbj48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgSSBjaGFsbGVuZ2UgdGhlIGFzc3VtcHRp
b24gaW4geW91ciBub3RlIGJlbG93IHRoYXQgc2VydmVycyB1c2luZyBvbmx5IHN0YXRpYyBwYWdl
cyBtdXN0IGJlIHN1cHBvcnRlZC4mbmJzcDsgSSBqdXN0IGRvbuKAmXQgc2VlIHRoZSByZXF1aXJl
bWVudCB0byBpbXBsZW1lbnQgYSBxdWVyeQ0KIHBhcmFtZXRlciBhcyBiZWluZyBhbiBpbXBlZGlt
ZW50IGluIHByYWN0aWNlLCBldmVuIGZvciBob3N0ZWQgZG9tYWlucy4mbmJzcDsgSSBrbm93IG9m
IG5vIGhvc3RpbmcgY29tcGFueSB0aGF0IGRvZXNu4oCZdCBwcm92aWRlIGEgbWVhbnMgb2YgcHV0
dGluZyBleGVjdXRhYmxlIGNvZGUgYmVoaW5kIHdlYiBwYWdlcywgYmUgaXQgUEhQLCBQZXJsLCBS
dWJ5LCBBU1AsIEpTUCwgZXRjLiZuYnNwOyBJIGtub3cgeW914oCZcmUgdHJ5aW5nIHRvIG1ha2Ug
dGhlIGNhc2UgZm9yDQogc3RhdGljIHBhZ2VzLCBidXQgaW4gcHJhY3RpY2UsIEkgYmVsaWV2ZSB0
aGF0IGR5bmFtaWMgcGFnZXMgYXJlIGFsd2F5cyBlYXNpbHkgYXZhaWxhYmxlLjwvc3Bhbj48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+QXNzdW1pbmcgdGhhdCB3ZeKAmXJl
IGluIGFuIGVpdGhlci1vciBzaXR1YXRpb24gd2l0aCByZWdhcmQgdG8gZWl0aGVyIGhhdmluZyBz
aW5nbGUtR0VUIGRpc2NvdmVyeSBvciBzdXBwb3J0aW5nIGRpc2NvdmVyeSB1c2luZyBvbmx5IHN0
YXRpYyBzZXJ2ZXIgcGFnZXMgKGFuZCBJ4oCZZCBsb3ZlIHRvDQogaGF2ZSBzb21lb25lIGRlbW9u
c3RyYXRlIHRvIHVzIHRoYXQgd2XigJlyZSBub3QpLCBJ4oCZZCB0YWtlIHNpbmdsZS1HRVQgZGlz
Y292ZXJ5IGZvciBzdXJlLCBhcyBpbiBzb21lIGNhc2VzLCBpdCBtYWtlcyBhbiBhcHByZWNpYWJs
ZSBkaWZmZXJlbmNlIGluIHVzZXIgaW50ZXJmYWNlIGxhdGVuY3ksIGFuZCBwZXIgdGhlIHBhcmFn
cmFwaCBhYm92ZSwgSSBiZWxpZXZlIHRoYXQgZHluYW1pYyBxdWVyaWVzIGNhbiBiZSBpbXBsZW1l
bnRlZCBvbiBhbGwgaG9zdGluZw0KIHBsYXRmb3Jtcy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkFzc3VtaW5nIHRoZSBXZWJGaW5nZXIgYXV0aG9ycyBhZ3Jl
ZSwgSeKAmWQgc3VnZ2VzdCB0aGF0IGEgbG9naWNhbCBuZXh0IHN0ZXAgd291bGQgYmUgZm9yIGEg
LTA0IHZlcnNpb24gb2YgZHJhZnQtam9uZXMtYXBwc2F3Zy13ZWJmaW5nZXIgdG8gYmUgcHVibGlz
aGVkIHRoYXQgY2hhbmdlcyBzdXBwb3J0DQogZm9yIHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIgZnJv
bSBSRUNPTU1FTkRFRCB0byBSRVFVSVJFRCwgYXMgdGhhdCBjb3VsZCBwcm92aWRlIGEgc3RhcnRp
bmcgcG9pbnQgZm9yIGEgY29tbW9uIGRpc2NvdmVyeSBzcGVjLjwvc3Bhbj48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7DQo8L3NwYW4+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+UC5TLiZuYnNwOyBBcyBsb25n
IGFzIGRyYWZ0LWpvbmVzLWFwcHNhd2ctd2ViZmluZ2VyIGlzIGJlaW5nIHJldmlzZWQsIEnigJlk
IGFsc28gc3VnZ2VzdCBhZGRpbmcgdGV4dCBtYWtpbmcgZXhwbGljaXQgd2hhdCBoYXMgYmVlbiBh
biBpbXBsaWNpdCBhc3N1bXB0aW9uIGluIGJvdGggV2ViRmluZ2VyIGFuZA0KIFNXRCAtIHRoYXQg
ZGVwZW5kaW5nIHVwb24gd2hldGhlciBhbmQgaG93IHRoZSBjbGllbnQgaXMgYXV0aGVudGljYXRl
ZCwgdGhlIHNldCBvZiByZXNvdXJjZXMgcmV0dXJuZWQgbWF5IHZhcnkgKGFzIEJsYWluZSBoYWQg
cG9pbnRlZCBvdXQgZWFybGllcikuJm5ic3A7IFRoYXQgY291bGQgaGVscCBkZWFsIHdpdGggc29t
ZSBvZiB0aGUgcHJpdmFjeSBwZXJjZXB0aW9ucy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Y29sb3I6YmxhY2siPg0KPGEgaHJlZj0ibWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3Vu
Y2VzQGlldGYub3JnIj5hcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0i
bWFpbHRvOlttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIj4NClttYWlsdG86
YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddPC9hPiA8Yj5PbiBCZWhhbGYgT2YgPC9iPkJs
YWluZSBDb29rPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgQXByaWwgMjIsIDIwMTIgMjoxNSBQ
TTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZyI+
YXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbYXBwcy1kaXNj
dXNzXSBXZWJmaW5nZXIgLyBTV0QgSXNzdWUgIzM6IGRpcmVjdCB2ZXJzdXMgaW5kaXJlY3QgZGlz
Y292ZXJ5PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91
bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn
cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhpcyBpcyB0aGUgbGFzdCBp
c3N1ZSB0aGF0IEkndmUgZmxhZ2dlZCBhcyBibG9ja2luZyBhIG5ldyBXZWJmaW5nZXIgLyBTV0Qg
ZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1pa2Ugc3VnZ2VzdGVkIHRoYXQgYmVpbmcgYWJs
ZSB0byByZXF1ZXN0IGEgdXNlcidzIHByb2ZpbGUgd2l0aCBhIHNpbmdsZSByZXF1ZXN0IChpLmUu
LCB0aGF0IHRoZSAvLndlbGwta25vd24vIHByb2ZpbGUgcmVzb3VyY2Ugc2hvdWxkIGJlIGFibGUg
dG8gcmVzcG9uZCB3aXRoIGZ1bGwgcHJvZmlsZSBkYXRhIGltbWVkaWF0ZWx5LA0KIHJhdGhlciB0
aGFuIHBvaW50aW5nIGF0IGEgc2Vjb25kIFVSTCB0aGF0IHdpbGwgZnVsZmlsIHRoZSByZXF1ZXN0
KSBpcyBhIHJlcXVpcmVtZW50IGZvciB0aGlzIHN0YW5kYXJkLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPkknZCBsaWtlIHRvIGNoYWxsZW5nZSB0aGF0IHJlcXVpcmVtZW50LiBUaGUgYXJn
dW1lbnRzIGZvciBhIGRpcmVjdCBkaXNjb3ZlcnkgZW5kcG9pbnQgYXJlOjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siPjEuIEZld2VyIHJlcXVlc3RzIGFnYWluc3QgdGhlIHNlcnZlciwgc2lu
Y2Ugd2Ugc2F2ZSAoaW4gdGhlIHdvcnN0LWNhc2UpIDUwJSBvZiByZXF1ZXN0cyBieSBieXBhc3Np
bmcgdGhlIGluZGlyZWN0IGxvb2t1cCBwaGFzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj
a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4yLiBMb3dlciBsYXRlbmN5
IGZvciBjbGllbnRzIChlLmcuLCBtb2JpbGUgY2xpZW50cykgb3dpbmcgdG8gdGhlIHJlZHVjZWQg
bnVtYmVyIG9mIGxvb2t1cHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp
dGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGFyZ3Vt
ZW50cyBmb3IgYW4gaW5kaXJlY3QgZGlzY292ZXJ5IGVuZHBvaW50IGFyZTo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m
bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIj4xLiBUcml2aWFsIGFuZCB3ZWItc3RhbmRhcmRzIGZyaWVuZGx5IGRl
cGxveW1lbnQgZm9yIGRvbWFpbnMgdGhhdCB3b24ndCBob3N0IHRoZWlyIG93biB3ZWJmaW5nZXIv
c3dkIHByb2ZpbGUgc2VydmVycywgYnV0IHdhbnQgdG8gZW5hYmxlIGFjY291bnRzIG9uIHRoZWly
IGRvbWFpbnMgKGUuZy4sIHN0YXRpY2FsbHkgaG9zdGVkDQogc2l0ZXMpLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjIu
IEEgbG9vc2VuaW5nIG9mIHRoZSByZXF1aXJlbWVudCB0aGF0IFVSTHMgYXQgdGhlIGJhcmUgZG9t
YWluIG11c3QgcnVuIGR5bmFtaWMgc2NyaXB0cyB0aGF0IHJlc3BvbmQgdG8gcmVxdWVzdHMgdG8g
dGhlIC8ud2VsbC1rbm93bi8gcGF0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu
ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NeSBv
cGluaW9uIGlzIHRoYXQgdGhlIGFwcHJvYWNoIHRoYXQgU1dEIGhhcyBwcm9wb3NlZCBmb3IgdGhl
IHJlZGlyZWN0IGlzIHByb2JsZW1hdGljLiBGaXJzdCwgdGhlIGZvcm1hdCBpcyB2ZXJ5IHNpbWls
YXIgaW4gZm9ybSB0byB0aGUgSFRNTCAmcXVvdDttZXRhIHJlZnJlc2gmcXVvdDsgdGFnIHRoYXQg
cHJvdmlkZWQgSFRUUCByZWRpcmVjdA0KIHN1cHBvcnQgZnJvbSB3aXRoaW4gSFRNTC4gVGhhdCBm
b3JtYXQgaGFzIGJlZW4gd2lkZWx5IGRlcHJlY2F0ZWQsIGFuZCBpbiB0aGVzZSBtb3JlIGVubGln
aHRlbmVkIHRpbWVzLCB3ZSBqdXN0IHVzZSB0aGUgM3h4IHJlc3BvbnNlIGNvZGVzIHdpdGggTG9j
YXRpb24gaGVhZGVycywgaW5zdGVhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu
ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TZWNv
bmRseSwgdGhlIFNXRCByZXF1ZXN0IGZvcm1hdCBtZWFucyB0aGF0IGZvciBzbWFsbGVyIHNpdGVz
LCBvZnRlbiB0aG9zZSB3aXRoIHRoZSBsZWFzdCByZXNvdXJjZXMsIHdpbGwgZW5kIHVwIHNlcnZp
bmcgc3RhdGljIGNvbnRlbnQgaW4gYSB3YXkgdGhhdCdzIGRpZmZpY3VsdCB0byBjYWNoZTsgY2Vy
dGFpbmx5LCBtb3JlDQogZGlmZmljdWx0IHRvIGNhY2hlIHRoYW4ganVzdCBzZXJ2aW5nIHN0YXRp
YyBjb250ZW50LiBUaGlzIGlzIGR1ZSB0byB0aGUgcmVxdWVzdCBwYXJhbWV0ZXJzIHByZXNlbnQg
aW4gYWxsIFNXRCByZXF1ZXN0czsgdGhvc2UgcmVxdWVzdCBwYXJhbWV0ZXJzIHdpbGwgYnVzdCBj
YWNoZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0
eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91
bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QXMgZm9yIHRoZSBmaXJzdCBhcmd1
bWVudCAqZm9yKiBTV0QncyBhcHByb2FjaCwgSSdkIHN1Z2dlc3Qgd2UgbG9vayB0byBETlMsIHdo
aWNoIHVzZXMgdGhlIHNhbWUgaW5kaXJlY3Rpb24gYXBwcm9hY2ggZm9yIE5TIHJlY29yZHMsIHJl
bHlpbmcgb24gYSAocmVsYXRpdmVseSkgdmVyeSBzbWFsbCBzZXQgb2Ygcm9vdCBzZXJ2ZXJzDQog
dG8gaGFuZGxlIHRoZSB0cmFmZmljIGZvciB0aGUgd2hvbGUgaW50ZXJuZXQuIENsZWFybHksIHRo
aXMgYXBwcm9hY2ggd29ya3MsIGFuZCB3ZWJmaW5nZXIvc3dkIHNlcnZlcnMgYXJlIGluIGEgbXVj
aCBiZXR0ZXIgcG9zaXRpb24gdG8gaGFuZGxlIHRoaXMgYWRkaXRpb25hbCB0cmFmZmljLiBNb3N0
IG9mIHRoaXMgdHJhZmZpYyB3aWxsIGJlIGhlYXZpbHkgY2FjaGVkLCBlc3BlY2lhbGx5IGZvciB0
aGUgbGFyZ2VzdCBwcm92aWRlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6
d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SW4gZmFj
dCwgaW4gdGVybXMgb2YgcmVhbCBkZXBsb3ltZW50cywgaG9zdGluZyBhIHNjcmlwdCBhdCwgZS5n
LiwNCjxhIGhyZWY9Imh0dHA6Ly9nb29nbGUuY29tLy53ZWxsLWtub3duL3NpbXBsZS13ZWItZGlz
Y292ZXJ5IiB0YXJnZXQ9Il9ibGFuayI+Z29vZ2xlLmNvbS8ud2VsbC1rbm93bi9zaW1wbGUtd2Vi
LWRpc2NvdmVyeTwvYT4gaXMgbXVjaCBoYXJkZXIgdGhhbiBob3N0aW5nIGEgc2NyaXB0IGF0DQo8
YSBocmVmPSJodHRwOi8vcHJvZmlsZXMuZ29vZ2xlLmNvbS9wcm9maWxlLmpzb24iIHRhcmdldD0i
X2JsYW5rIj5wcm9maWxlcy5nb29nbGUuY29tL3Byb2ZpbGUuanNvbjwvYT4gZm9yIGFsbCBzb3J0
cyBvZiByZWFzb25zLCBzbyBpdCdzIG15IGJlbGllZiB0aGF0IHRoZSBmaXJzdCBhcmd1bWVudCBp
cyBhIHJlZCBoZXJyaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBzZWNvbmQg
YXJndW1lbnQgaXMgbGVnaXRpbWF0ZSwgYnV0IG9ubHkgaWYgbW9iaWxlIGNsaWVudHMgd2lsbCBh
Y3R1YWxseSBiZSBtYWtpbmcgcmVxdWVzdHMgdG8gZGl2ZXJzZSB3ZWJmaW5nZXIvc3dkIGhvc3Rz
LiBJbnN0ZWFkLCBJIHN0cm9uZ2x5IGJlbGlldmUgdGhhdCB3ZSdsbCBzZWUgdGhlIGVtZXJnZW5j
ZSBvZg0KIEROUy1saWtlIHNlcnZlcnMgdGhhdCBwcm92aWRlIGJvdGggcHJvZmlsZSBob3N0aW5n
IGFzIHdlbGwgYXMgcHJveHkgc2VydmljZXMuIEZvciBhIG1vYmlsZSBjbGllbnQsIHRoZSBvcHRp
bWFsIGFwcHJvYWNoIHdpbGwgYmUgdG8gdXNlIFNQRFkgdG8gY29ubmVjdCB0byBhIHNpbmdsZSBo
b3N0IHRoYXQgcGVyZm9ybXMgd2ViZmluZ2VyL3N3ZCBsb29rdXBzIG9uIHRoZSBtb2JpbGUgY2xp
ZW50J3MgYmVoYWxmLCBlbGltaW5hdGluZyB0aGUgbGF0ZW5jeQ0KIGNvbmNlcm5zLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siPkkgb2ZmZXIgdGhhdCB0aGUgdHdvLXN0ZXAgbG9va3VwIGNh
biBiZSBpbXBsZW1lbnRlZCB3aXRob3V0IGNvbmRpdGlvbmFscyBvbiB0aGUgY2xpZW50LCB3aGVy
ZWFzIHRoZSBkaXJlY3QtdW5sZXNzLW5vdCBhcHByb2FjaCBjYW5ub3QgYmUgaW1wbGVtZW50ZWQg
dGhhdCB3YXkgKHNlZSBteSBlYXJsaWVyIGN1cmwgZXhhbXBsZQ0KIGZvciBwcm9vZikuIEl0J3Mg
c2ltcGxlciwgYW5kIGVhc2llciB0byBleHBsYWluIHRvIHRoZSAoaG9wZWZ1bGx5IG1hbnkpIHNt
YWxsIHNpdGUgb3duZXJzIHdobyB3ZSdkIGxpa2UgdG8gaW1wbGVtZW50IHRoaXMgdGVjaG5vbG9n
eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3
aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaG91Z2h0cz8gQW0gSSBtaXNzaW5nIHNv
bWV0aGluZz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5iLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3Q8YnI+
DQo8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnIj5hcHBzLWRpc2N1c3NAaWV0
Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9hcHBzLWRpc2N1c3MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3VzczwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA201009E7EP3PWEX2MB008ex2_--

From stpeter@stpeter.im  Wed Apr 25 11: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 D8C4321F88B9 for ; Wed, 25 Apr 2012 11:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.308
X-Spam-Level: 
X-Spam-Status: No, score=-102.308 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qC+7ko+nqLW for ; Wed, 25 Apr 2012 11:37:34 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3554321F88A2 for ; Wed, 25 Apr 2012 11:37:28 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BAB9C40058; Wed, 25 Apr 2012 12:52:03 -0600 (MDT)
Message-ID: <4F984466.8020704@stpeter.im>
Date: Wed, 25 Apr 2012 12:37:26 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Andrew Sullivan 
References:  <6.2.5.6.2.20120425095148.0a7f0bf0@resistor.net> <20120425172555.GM60024@mail.yitter.info>
In-Reply-To: <20120425172555.GM60024@mail.yitter.info>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On citations in general
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 18:37:35 -0000

On 4/25/12 11:26 AM, Andrew Sullivan wrote:
> On Wed, Apr 25, 2012 at 09:58:25AM -0700, SM wrote:
>> BTW, this is more of a matter of style.
> 
> And consequently of religion.  I'd prefer that we not talk about it,
> either here or on rfc-i, since in both cases I think we will explore
> every rathole possible (and some impossible ones) involving Fowler
> vs. Strunk&White, MLA vs. Chicago, involving whatever
> your 3d grade teacher said even though s/he couldn't write worth a
> tinker's dam (yes, that's how it's spelled), and the Oxford comma and
> requirements for its use.  I have the Gowers edition Fowler on my
> book-shelf, and I am as happy to waive it about as the next person.
> But I don't think we're going to be more productive that way.

Agreed. Indeed, perhaps we could learn from Jon Postel's advice to
authors: read a recent RFC and emulate its style.

/psa


From barryleiba.mailing.lists@gmail.com  Wed Apr 25 11:45: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 0D09D21F88E0 for ; Wed, 25 Apr 2012 11:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.975
X-Spam-Level: 
X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbKxXKaTJMda for ; Wed, 25 Apr 2012 11:45:24 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 794D321F88D8 for ; Wed, 25 Apr 2012 11:45:24 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so461422yhk.31 for ; Wed, 25 Apr 2012 11:45:24 -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=7aMFHR8j1SRA0S0PPWoCL1Y4xSVqGW5BhovbIvlwb6A=; b=xen67bUdrGhGsgGrrlWGQ0Y9rdPqyeMIEdljC96aY5tXxpC9bXHQ10i/6ngX9EXySH bp+/l1R+Moago6hO/q+GmTXaUJ3G8VR6UaYdtG3BsbVtqnGhY2wMiAyQFsOIu9Fhlanw kG8ioHst2uvJYy1jt0ZfI49OdArASVyXVeS2iXC7nNr/E+gD1geyf19+bmgWXq/Gdf79 RtNQ3otlA2V3YVNOY7ubXBuA5pTi/qOxsm1WxaP/OdcnYDfA/kQsVrFK0FzBbpfKKzlV D3CJXu/NX4eaNS6xCvlcsJ1hqXYV1LbHFYvu1SyI6XfJQ6d60FlaCHsidWDYsW/SgEAj m7Sw==
MIME-Version: 1.0
Received: by 10.236.76.41 with SMTP id a29mr3445372yhe.117.1335379524162; Wed, 25 Apr 2012 11:45:24 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.152.14 with HTTP; Wed, 25 Apr 2012 11:45:24 -0700 (PDT)
In-Reply-To: <20120425172555.GM60024@mail.yitter.info>
References:  <6.2.5.6.2.20120425095148.0a7f0bf0@resistor.net> <20120425172555.GM60024@mail.yitter.info>
Date: Wed, 25 Apr 2012 14:45:24 -0400
X-Google-Sender-Auth: sr1pypboi2eBrSHMEdc-vJwBgM4
Message-ID: 
From: Barry Leiba 
To: Andrew Sullivan 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On citations in general
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 18:45:25 -0000

> But I don't think we're going to be more productive that way.

Yeh, you're probably right.

Never mind.  Let's drop this thread.

Barry

From nico@cryptonector.com  Wed Apr 25 11:49: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 5EC1921F88F5 for ; Wed, 25 Apr 2012 11:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.955
X-Spam-Level: 
X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.022,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th4PCxvNOTsr for ; Wed, 25 Apr 2012 11:49:51 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id C7C4221F888D for ; Wed, 25 Apr 2012 11:49:51 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 3C3D2318077 for ; Wed, 25 Apr 2012 11:49:51 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to: content-type; q=dns; s=cryptonector.com; b=Pu8q/JRcbQRK69CslIFVO Ie7ldUPLEgfRs44u0vo5G3d2TAqVYEnL9dm8KGUdGNsBW/R+3wlJj9c1FWNb2Pp/ 1Us184Q/R/p4YQva5Nhn9sS/y4OC8ZulsgtMuoqNCgZrD4ZdS4S5Dv/lpnbN6/QV 263VKUExiDB2TVJ+5eH25g=
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:content-type; s=cryptonector.com; bh=u5NySxjL8fpRIdmymOFZhA+ tTmU=; b=O5yCePSBHQJvQF9d/lrZ37R1xPDlYz50Et7Wnr9RnuZDtLgiBb4s/dp fePO8NoQGu9NnvLwZnRhRtmOU+d2iCTj6vD4L/uU3yCoi6Qi5dJe1TmWx1kBsB83 01XyYrfG8hLJqP2R/wfdkoK2qwM7f/MX5UMQatPgfbeoonNa34hw=
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-a89.g.dreamhost.com (Postfix) with ESMTPSA id 1D7CE31807C for ; Wed, 25 Apr 2012 11:49:50 -0700 (PDT)
Received: by pbbrp16 with SMTP id rp16so1841337pbb.31 for ; Wed, 25 Apr 2012 11:49:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.221.10 with SMTP id qa10mr8496426pbc.139.1335379790568; Wed, 25 Apr 2012 11:49:50 -0700 (PDT)
Received: by 10.68.28.6 with HTTP; Wed, 25 Apr 2012 11:49:50 -0700 (PDT)
In-Reply-To: 
References:    
Date: Wed, 25 Apr 2012 13:49:50 -0500
Message-ID: 
From: Nico Williams 
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=UTF-8
Subject: Re: [apps-discuss] On citations in general
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 18:49:52 -0000

On Wed, Apr 25, 2012 at 1:09 PM, Blaine Cook  wrote:
> Why not just use links as Tim suggests with descriptive text in the content
> of the anchor? I don't see how offline reading is a blocker.

That's fine for HTML rendering, not so much for .txt rendering.
Though maybe it's time to obsolete .txt, if we won't allow UTF-8 in
.txt ever anyways in case -gasp!- someone's terminal displays garbage
(because you know that *never* happens and never possibly could as
long as we refrain from putting UTF-8 in RFCs).  (Hey, this sarcasm
thing is pretty fun!)

Though personally, I *like* .txt.  For one I get to apply the find |
xargs egrep pattern, and I really like being able to use advanced
regular expressions like that.  I can also apply various text indexing
tools; I've been thinking that a SQLite3 FTS RFC and I-D DB toolset
would be handy.  Web search engines aren't anywhere near as powerful
for searching such a small document set -- web search engines are
great for searching data/doc sets I could *never* store copies of
locally.  Also, less(1) is fantastic for reading RFCs and has much
faster startup/load times than any browser out there.  Sometimes less,
is more, and spartan .txt (with UTF-8 for bleep's sakes) is fabulous.
I suppose what I need is elinks(1) with regexp support, and to keep
rendered (as .txt) forms around for find | xargs egrep searching (or
else local web search indexes).  But, really, from a simplicity point
of view, .txt is just hard to beat.

Nico
--

From ve7jtb@ve7jtb.com  Wed Apr 25 12:00: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 6EA7D21F8955 for ; Wed, 25 Apr 2012 12:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.476
X-Spam-Level: 
X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAU2tID6q5-0 for ; Wed, 25 Apr 2012 12:00:29 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBCC21F891C for ; Wed, 25 Apr 2012 12:00:27 -0700 (PDT)
Received: by yenm5 with SMTP id m5so468244yen.31 for ; Wed, 25 Apr 2012 12:00:27 -0700 (PDT)
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=XKhhbDxRSutEBuVZy8PQXN69glFvzNJvVP2/B4vI4Lg=; b=aopbOjSrnTUK13G4bNug0GrIxwp/xryA411xV2D40T819zkhz1VFt9tMSdAnRFXQhJ Z1iFUSOAnPdrYUOx9scunjO4NRtErYy5e6PYFJfAm9PoAIByGMDUL9CFOJRwYL+BAa9L XWC1OCbWOUX3gfK2UgY7Pilb8TwclSaYjHEiuCOgVt+BVMqzMi3TAAUAfg6xzvblpsge 1Z4OODz7JbR1vXVRLX2Jp+hnLfH/0HtauXWyn5kybsxZF/N7MdpIovQnqq11F73dsYsw IlGJCr7UhaCwaj+wAcMthGWW7O9pT1faz5O0gCJt2KMXDG8nT8IfByESOIYOxZ/PLCDY 4t2A==
Received: by 10.236.184.202 with SMTP id s50mr3531350yhm.84.1335380427549; Wed, 25 Apr 2012 12:00:27 -0700 (PDT)
Received: from [192.168.1.213] (190-20-63-108.baf.movistar.cl. [190.20.63.108]) by mx.google.com with ESMTPS id m30sm2311418yhe.15.2012.04.25.12.00.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 12:00:23 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_1B4768A3-8AF7-4F48-88F9-359FD9067A50"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201009E4D@P3PWEX2MB008.ex2.secureserver.net>
Date: Wed, 25 Apr 2012 16:00:15 -0300
Message-Id: 
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201007020@P3PWEX2MB008.ex2.secureserver.net> <515663DA-67BF-4367-9AD9-6E940424CBCD@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20100990A@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA201009E4D@P3PWEX2MB008.ex2.secureserver.net>
To: Eran Hammer 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQnZZ3kdP6//sGvrlUXQEIgeuni29H8ofdLbhIdPfE+8F9ZXgMc0TRVPmjqdzWyBToy+yj2i
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 19:00:33 -0000

--Apple-Mail=_1B4768A3-8AF7-4F48-88F9-359FD9067A50
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

OK so host-meta is one level of lrdd link processing for a resource (not =
host).=20

Multiple lrdd links are not precluded, but are an abuse.=20

If you want to redirect to an alternate host-meta location you use 3xx =
and the client will follow.
(I heard some complaining about what if my site can't support redirects =
earlier.)

The links are aggregated with host-meta links and filtered by "rel".

So if in host-meta I have:=20
{
       "rel" : "http://openid.net/specs/connect/issuer",
       "href" : "https://server.example.com"
     }

before my lrdd entry

That would be returned in the filtered list before any resource specific =
"rel" ?

Thus making a global setting for all resources. =20

I don't think the original Connect proposal had per user discovery only =
per host via host meta without following lrdd.

If aggrigating and sorting links are a requirement, that needs to be =
done server side for Connect clients.

John B.





On 2012-04-25, at 3:29 PM, Eran Hammer wrote:

>=20
>=20
>> -----Original Message-----
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>> Sent: Wednesday, April 25, 2012 10:38 AM
>> To: Eran Hammer
>> Cc: Paul E. Jones; apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>=20
>> Eran,
>>=20
>> It was unclear, at least to me that the server side host-meta =
processing rule
>> specified in WF requires all the templates (or just the LRDD ones) to =
be
>> processed substituting inserting "resource" for URI and then =
retrieving and
>> merging all the resource JRD before processing the filter on the =
"rel".
>>=20
>> If I defined a rel of FOO would WF fill the template and retrieve the =
JRD and
>> merge its links with the lrdd JRD?
>> I might think that would be a touch confusing to clients.
>=20
> No. It only does *one* level of LRDD import (in order). See:
>=20
> http://tools.ietf.org/html/rfc6415#section-4.2
>=20
>> So I go back to the rational explanation that lrdd templates are =
expanded and
>> those links rolled up and filtered.
>>=20
>> Now I am guessing that some of the SWD people are thinking that when =
the
>> server is using flat files that puts a lot of burden onto the client.
>>=20
>> Probably why you added the server side processing.
>=20
> The idea of adding server-side processing and filtering via the query =
came out of the original OpenID Connect proposal that David Recordon and =
I wrote, trying to keep the clients super simple and avoid the need to =
go fetch host-meta, then one or more LRDD documents.
>=20
> Complexity is very much implementation specific on the server side. =
Yahoo doesn't have LRDD documents and puts everything as link templates =
in host-meta while others like the ability to customize. The most likely =
scenario of servers including LRDD links in host-meta is that the =
host-meta document is static, while the LRDD links are dynamically =
generated. Otherwise, there is very little value in the added =
complexity. In that case, the client will typically be faced with 2 =
requests.
>=20
> I would argue that a server using multiple LRDD links in host-meta is =
abusing the system, very much like a server using multiple 3xx =
redirections between its initial host-meta endpoint to where the =
document actually lives.
>=20
> IOW, there are many ways to inflict pain on the client.
>=20
>> Given that WF takes the liberty of adding query parameters to =
host-meta
>> and seems to define host-meta processing rules (perhaps for non =
lrdd?), I
>> am not finding the separation of the two specs as clean as possible.
>> It seems a bit like there is there a RFC 6415 dependency on WF.  =
Though that
>> is a touch strange for a RFC.
>=20
> The WF draft should not introduce any new processing rules. It should =
only add the query optimization but that must result in exactly the same =
set of links as defined by 6415. If this is the case, it's a bug.
>=20
>> What stops someone from defining a relation of super-discovery and =
adding
>> some query parameters to host-meta.json to hover up some lrdd based =
on a
>> template expansion of  "super-discovery" rel types, and filter on =
"rel"?
>>=20
>> I wouldn't have thought to do that because stepping on the RFC 6415
>> endpoint seems slightly wrong to me.
>>=20
>> I would probably define a new endpoint /.well-known/super-discovery =
with
>> my own query parameters and processing rules for JRD documents.
>=20
> That would be the right approach. Note that 6415 registers both =
host-meta (defaults to XML) and host-meta.json (JSON required).
>=20
>> Without being able to make server-side processing of host-meta =
required,
>> we need someway to delegate that to another endpoint.
>>=20
>> In XRD we did discuss delegating the entire XRD.  Is there a way to =
do that in
>> host-meta?
>=20
> 3xx.
>=20
> EH
>=20
>> At the moment all of the processing gets pushed back on the client if =
the
>> host only supports static files in /.well-known
>>=20
>> John B.
>>=20
>>=20
>>=20
>> On 2012-04-25, at 1:34 PM, Eran Hammer wrote:
>>=20
>>> It is important to understand the semantics of host-meta, which I =
think
>> there is some confusion about here.
>>>=20
>>> As a mechanism, host-meta providers you with a method of obtaining =
both
>> host-wide and resource-specific links (and properties). To accomplish =
that, it
>> provides with both a document and processing rules.
>>>=20
>>> WebFinger - the name given for the host-meta *use-case* of =
retrieving
>> user information - is a specialization of obtaining resource-specific =
links.
>>>=20
>>> The 'rel' and 'resource' query parameters (as proposed) apply to the
>> endpoint *after* executing the processing rules (which include =
expanding
>> templates and importing links from one level LRDD documents).
>>>=20
>>> LRDD documents only apply to resource-specific links, which means =
they
>> are ignored for any host-wide query. For example, the location of the =
site's
>> TOS document. =46rom the host-meta perspective, LRDD documents are =
just a
>> deployment tool to provide customization not possible using just link
>> templates at the host-meta document level. It's just a link-include
>> mechanism, and host-meta uses it restrictively.
>>>=20
>>> IMO, the 'rel' and 'resource' optimization should only apply to the =
host-
>> meta endpoint, and act as a filter post the processing rules. If =
'resource' is
>> specified, it is a resource-specific request, otherwise, host-wide.
>>>=20
>>> Let me know if this helps or if it is still unclear.
>>>=20
>>> EH
>>>=20
>>>=20
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>> Sent: Wednesday, April 25, 2012 8:27 AM
>>>> To: Eran Hammer
>>>> Cc: Paul E. Jones; apps-discuss@ietf.org
>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>>=20
>>>> That was one thing that initially confused me.  The rel filter is =
not applied
>> to
>>>> host-meta, but rather the linked lrdd resource JRD.
>>>>=20
>>>> The currently defined "resource" parameter has an implicit =
host-meta
>> "rel"
>>>> of "lrdd".
>>>>=20
>>>> To use this mechanism for other relations you would need to make =
that
>>>> parameter explicit.
>>>>=20
>>>> That then raises the question of the filter being part of host-meta =
or WF if
>> it
>>>> applies to relationships other than lrdd.
>>>>=20
>>>> If you are asking if filtering should be supported by lrdd where =
you start
>>>> discovery from a link header, then it probably should be possible =
as well.
>>>>=20
>>>> Though I thought lrdd stopped being updated over a year a year ago.
>> Sorry if
>>>> I am out of date.
>>>>=20
>>>> So XRD/JRD documents SHOULD be filterable by "rel" independent of =
if
>> you
>>>> get to them via lrdd or host-meta.
>>>>=20
>>>> Host-meta SHOULD support a mechanism to filter by "rel" or filter =
by a
>>>> combination of "resource" (uri) , host-meta-rel and resource-rel =
(the
>> host-
>>>> meta-rel is currently implicit.)
>>>>=20
>>>> I recall discussing this in the XRI TC when we did XRD years ago, =
though
>> that
>>>> was more around using XRI identifiers.
>>>>=20
>>>> The same principal still holds.  I should be able to ask for.
>>>> GET /.well-known/host-meta.json
>>>>    ?resource=3Djoe@example.com
>>>>    &host-meta-rel=3Dlrdd
>>>>=20
>> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>>>> HTTP/1.1
>>>> Host: example.com
>>>>=20
>>>> (personally I think calling the parameter "resource" and the =
template {uri}
>>>> will be confusing to people)
>>>>=20
>>>> In SWD we used fixed the parameter names and the base URI is the =
part
>> that
>>>> gets changed when the /.well-known can't host a script.
>>>> That makes the template simpler for the client to process.  The =
equivalent
>> to
>>>> "rel" is always passed to make processing simpler.
>>>>=20
>>>> As Blaine has pointed out several times SWD and WF largely get us =
to the
>>>> same place.
>>>>=20
>>>> I am trying to find a way to close the gap.
>>>>=20
>>>> John B.
>>>>=20
>>>>=20
>>>> On 2012-04-25, at 11:41 AM, Eran Hammer wrote:
>>>>=20
>>>>> Purely from a practical standpoint, do you think it is likely that =
a server
>> will
>>>> support the query filter for the lrdd documents but not for =
host-meta?
>>>>>=20
>>>>> EH
>>>>>=20
>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>>>> bounces@ietf.org] On Behalf Of John Bradley
>>>>> Sent: Wednesday, April 25, 2012 6:17 AM
>>>>> To: Paul E. Jones
>>>>> Cc: apps-discuss@ietf.org
>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>>>=20
>>>>> Paul,
>>>>>=20
>>>>> "rel" as a filter is something WF has for host-meta.  It however =
doesn't
>>>> seem to have that for user JRD in the case where host-meta is =
returned,
>> and
>>>> the template is used.
>>>>>=20
>>>>> The "resource" and "rel" parameters are already an optimization =
for
>> LRDD
>>>> and not part of host-meta.
>>>>> Adding LRDD specific parameters to host-meta/host-meta.json will
>>>> probably raise some eyebrows in review, but I am OK with it.
>>>>>=20
>>>>> I think there are use cases where size matters.  Where a host-meta =
or
>>>> resource JRD may be large and it is more efficient not to send the =
whole
>>>> thing to a mobile client.
>>>>> It seems to be one of Mike Jones requirements.
>>>>>=20
>>>>> Using RFC6570 for LRDD is a possibility for passing through the =
filter
>> request
>>>> for sites that support filtering on resource JRD.
>>>>>=20
>>>>> What other proposals do you have.  I am guessing that filtering on
>> resource
>>>> JRD is not a totally new topic.
>>>>>=20
>>>>> LRDD is the one really doing the optimization  in any event,  it =
may be
>> done
>>>> at the host-meta GET but it is a LRDD specific extension.
>>>>> Having it in the template allows LRDD to filter at the resource =
JRD in
>> cases
>>>> where it is not possible to do it at the host-meta level, due to =
some no
>> script
>>>> or other restriction.
>>>>>=20
>>>>> I agree that it should be filtered at the how-meta request but you =
and
>>>> others say that is not always possible.
>>>>>=20
>>>>> John B.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
>>>>>=20
>>>>>=20
>>>>> John,
>>>>>=20
>>>>> The "rel" parameter is something we still need to discuss, so not =
is as
>> good
>>>> a time as any.
>>>>>=20
>>>>> What "rel" does is act as a filter.  For the most part, the only =
purpose it
>>>> serves is to help reduce the number of link relations that might be =
sent
>> from
>>>> the server.  So, if a user had 1,000 different link relations, this =
might
>> reduce
>>>> the returned message to containing only 1.  However, if a user has =
more
>> than
>>>> one link relation of the same type, all of them would match and be
>> returned.
>>>>>=20
>>>>> When you say the host cannot support re-write rules, I assume you
>> mean it
>>>> does not support the URI parameters on host-meta?  In that case, =
yes,
>> the
>>>> parameters are ignored and you get just the host-meta document.
>>>>>=20
>>>>> The only URI template defined in RFC 6415 is "{uri}" (see =
3.1.1.1).  There
>> are
>>>> no other URI template values defined.  (Note: this whole section =
exists
>> only
>>>> because RFC  6570 did not yet exist, I think.
>>>>>=20
>>>>> In any case, we could define a new URI template, but then we would =
be
>>>> putting an optimization in place for LRDD.  If host-meta is not =
going to
>>>> support the "rel" URI parameter, why would LRDD?  It would also =
mean
>> that
>>>> the LRDD logic would have to be ready to receive a URI parameter =
that is
>> not
>>>> replaced, since some clients would only change {uri} and leave =
{rel} there.
>>>> That would introduce more conditional logic in the server.  This =
would also
>>>> present issues with static sites.  (Of course, one might be able to =
use
>> Apache
>>>> re-writing rules to get around that problem, but it certainly would =
not
>> work
>>>> for "real" static sites.)
>>>>>=20
>>>>> Personally,  I'd prefer to not add the "rel" parameter to LRDD, =
since I
>> think
>>>> optimization using "rel" would always be done on host-meta.  That =
said, I
>>>> question the value of "rel" entirely.  Do you think it's useful to =
have this
>> filter
>>>> at all?  Is there really a risk that a site might return 1,000 link =
relations that
>> the
>>>> client would have to step over?
>>>>>=20
>>>>> Paul
>>>>>=20
>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>>> Sent: Tuesday, April 24, 2012 10:17 PM
>>>>> To: Paul E. Jones
>>>>> Cc: apps-discuss@ietf.org
>>>>> Subject: WF flow with rel parameter
>>>>>=20
>>>>> Paul,
>>>>>=20
>>>>> Sorry I hit send on the previous message with a typo.
>>>>>=20
>>>>> I am looking at how the flows in WF might work for openID.
>>>>>=20
>>>>> Let's set aside the XML issue for the moment and focus on the JSON
>> flow.
>>>>>=20
>>>>> Please correct anything I get wrong.
>>>>>=20
>>>>> The openID Connect defines a relation of
>>>> http://openid.net/specs/connect/issuer
>>>>>=20
>>>>> WF allows for a JSON host-meta that takes two parameters, =
"resource"
>> and
>>>> "rel"
>>>>>=20
>>>>> An example request and response (line-brakes for readability)
>>>>>=20
>>>>> GET /.well-known/host-meta.json
>>>>>    ?resource=3Djoe@example.com
>>>>>=20
>> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>>>> HTTP/1.1
>>>>> Host: example.com
>>>>>=20
>>>>>  HTTP/1.1 200 OK
>>>>>=20
>>>>>  Access-Control-Allow-Origin: *
>>>>>  Content-Type: application/json; charset=3DUTF-8
>>>>>=20
>>>>>  {
>>>>>    "subject" : "joe@example.com",
>>>>>    "links" :
>>>>>    [
>>>>>      {
>>>>>        "rel" : "http://openid.net/specs/connect/issuer",
>>>>>        "href" : "https://server.example.com"
>>>>>      }
>>>>>    ]
>>>>>  }
>>>>>=20
>>>>> If the host can't support rewrite rules or scripts the exchange =
would look
>>>> like:
>>>>>=20
>>>>> GET /.well-known/host-meta.json
>>>>>    ?resource=3Djoe@example.com
>>>>>=20
>> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>>>> HTTP/1.1
>>>>> Host: example.com
>>>>>=20
>>>>> HTTP/1.1 200 OK
>>>>>  Access-Control-Allow-Origin: *
>>>>>  Content-Type: application/json; charset=3DUTF-8
>>>>>  {
>>>>>    "expires" : "2012-03-13T20:56:11Z",
>>>>>    "links" :
>>>>>    [
>>>>>      {
>>>>>        "rel" : "lrdd",
>>>>>        "type" : "application/json",
>>>>>        "template" :
>>>>>          "https://example.com/lrdd/?format=3Djson&resource=3D{uri}"
>>>>>      }
>>>>>=20
>>>>> GET /lrdd/
>>>>>    ?format=3Djson
>>>>>    &resource=3Djoe@example.com
>>>>> Host: example.com
>>>>>=20
>>>>> HTTP/1.1 200 OK
>>>>>=20
>>>>>  Access-Control-Allow-Origin: *
>>>>>  Content-Type: application/json; charset=3DUTF-8
>>>>>=20
>>>>>  {
>>>>>    "subject" : "joe@example.com",
>>>>>    "links" :
>>>>>    [
>>>>>      {
>>>>>        "rel" : "http://openid.net/specs/connect/issuer",
>>>>>        "href" : "https://server.example.com"
>>>>>      },
>>>>>      {
>>>>>        "rel" : "http://webfinger.net/rel/avatar",
>>>>>        "href" : "http://example.com/~joe/joe.jpg"
>>>>>      }
>>>>>=20
>>>>>    ]
>>>>>  }
>>>>>=20
>>>>> I can't find a template parameter for "rel".  The host-meta spec =
allows
>> for
>>>> extension but it is missing.
>>>>>=20
>>>>> What if the server wants to support filtering on rel but can't =
support it in
>>>> the root for some reason?
>>>>>=20
>>>>> Is it possible to have a template like:
>>>>> "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel=
}"
>>>>>=20
>>>>> That simple addition may solve a number of problems for openID.
>>>>>=20
>>>>> John B.
>>>>>=20
>>>>>=20
>>>>>=20
>>>=20
>=20


--Apple-Mail=_1B4768A3-8AF7-4F48-88F9-359FD9067A50
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
NTE5MDAxNlowIwYJKoZIhvcNAQkEMRYEFNLwaV1pHBB//EEDfVuHmcoQipPLMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AHG3do/CzkTWakxfFrv//+t6r5knJ97WA20KkjB1BoGhlKkKun45X95CZUkagSQ0Z9+p9RxRfAgB
B7ROX0PaxsX7NiCqBg6pLO1ctTRddV/uq8d6mzkyR1i+Tt4qCpF/rAl9bJj8ZQFVueJX8NF6ju6d
7gJJxlk/EFbO0/ghbckM0Zx4hg5EPh0ZasthRpJEyshTKRFDBIggnkVoH2LJyoNXh9HtjNRzNvx6
NGeOy3GgLZZECCjUGCKPNHqrAY8zAuwl0iGY454XQTeZoUj1+nvAqbHaVUQRGB3de6cSSYQboXFd
o1l96YeTMPd084rxwNKWBz2yuFvvD9Yzn4hUyFUAAAAAAAA=

--Apple-Mail=_1B4768A3-8AF7-4F48-88F9-359FD9067A50--

From ve7jtb@ve7jtb.com  Wed Apr 25 12:13: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 1F48921F8942 for ; Wed, 25 Apr 2012 12:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.844
X-Spam-Level: 
X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYQbWyw19Ul1 for ; Wed, 25 Apr 2012 12:13:28 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 337AC21F8941 for ; Wed, 25 Apr 2012 12:13:27 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so487629ghb.31 for ; Wed, 25 Apr 2012 12:13:27 -0700 (PDT)
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=nFj/MDMEq4fusGCQ5Jfslk06uird9UzolTm4BJjbirQ=; b=n1cFiHaeP2RoszXq6KoSb1Qw8foosM1EIYNgoFy+bKdNhyPAdYX8n3Io+NIhTZG39U Eg7SGJqYyardJkVitZBs+BUzOLO8FuoAscRswMcBU9tI0Z9piF8jIK0Y9XLqNvQ3C/zj g2zXfMepPRTmsXgNQ8GhD5OuOoahhYRcMjjeOEiFupSQiUH5nCjiTIV2NUhX/4qteg70 m+lqjMjdH4g2Og4RWVd+qePNOtOyMQn0xpatZ4hDTjwLJKThn/src36P1CjNib91+lJS cgdKbzYCwoKQ3+HjB5IL9a+wR/py5hflzqOmLqiQwZjC5r/wb5kt+xE/ls7k3LB+9uFX PxQw==
Received: by 10.101.187.2 with SMTP id o2mr1013538anp.32.1335381207323; Wed, 25 Apr 2012 12:13:27 -0700 (PDT)
Received: from [192.168.1.213] (190-20-63-108.baf.movistar.cl. [190.20.63.108]) by mx.google.com with ESMTPS id d63sm2448020yhh.17.2012.04.25.12.13.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 12:13:25 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_A0F45CF5-7561-4A2C-91A1-C3780BFDC4EB"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <054901cd2311$87a24fb0$96e6ef10$@packetizer.com>
Date: Wed, 25 Apr 2012 16:13:20 -0300
Message-Id: <4CC716F1-F6A4-46CF-86FD-6636B1F84500@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com> <054901cd2311$87a24fb0$96e6ef10$@packetizer.com>
To: "Paul E. Jones" 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQmkk5gLoonxUnV8yXeaMmtfY31bYorB6ojiEDA/u71XcMwAn2uqMoxeIcGjX6f09XXXdQFJ
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 19:13:30 -0000

--Apple-Mail=_A0F45CF5-7561-4A2C-91A1-C3780BFDC4EB
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A5D42719-8AEE-4BC2-90D9-2C9023AE8B13"


--Apple-Mail=_A5D42719-8AEE-4BC2-90D9-2C9023AE8B13
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

If WF were to make resource REQUIRED and rel optional that would be a =
significant step forward.

Though the Apache http rewrite probably violates the host-meta =
processing rules Eran just described, if the links from host-meta must =
be included in order.
You could get around it by restricting the contents of host-meta if you =
are doing that I suppose.

John B.


On 2012-04-25, at 3:30 PM, Paul E. Jones wrote:

> John,
> =20
> I don=92t think we need to decide specific environments we want to =
support, but *if* people want to use static files, there are choices we =
can make where the resource parameter will still work, even in a static =
environment.  Previously, I sent out a sample config that allows Apache =
to handle the =93resource=94 parameter and still map that to static =
files.  However, I cannot do the same with the =93rel=94 parameter, thus =
we could never mandate that if we want to have any hope at all for =
allowing static sites.
> =20
> I appreciate having the =93resource=94 parameter, but I also =
appreciate some do not need (or have the ability to support) an =
elaborate server.
> =20
> Paul
> =20
> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley
> Sent: Monday, April 23, 2012 12:19 PM
> To: Bob Wyman
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus =
indirect discovery
> =20
> I understand that in some environments you may not have access to http =
rewrite rules. =20
> Others may preclude any scripts.
> =20
> We do have to decide what environments we are going to support.
> =20
> If we stick to static files only then we are just putting some =
lipstick on Yadis by adding a way to map a email like address to a file.
> =20
> So yes there are those environments, but that needs to be balanced =
against the additional overhead on the clients to support that =
environment.
> =20
> John B.
> =20
> On 2012-04-23, at 12:26 PM, Bob Wyman wrote:
>=20
>=20
> =20
>=20
> On Mon, Apr 23, 2012 at 11:08 AM, John Bradley  =
wrote:
> Mike,
> =20
> I think there is less resistance to making resource parameter REQUIRED =
than there is to removing the initial host-meta lookup to get the =
template.
> =20
> We should probably keep those issues separate.
> =20
> I agree that supporting indirect discovery of the template via =
host-meta.jason should probably stay.
> =20
> The question is if their can be an optimization that allows =
shortcutting that step if you know that all you want is web finger.
> =20
> A possible option for that could be using a fixed template in =
/.well-known/.
> =20
> That endpoint would return:
> a The terminal JRD (like SWD)
> b a 3xx redirect to the real endpoint
> Causing a 3xx redirect typically requires modification to the =
configuration files of a multi-host shared web server. Access to such =
configuration files is often restricted in such a way that those =
responsible from just one or a few of the sites sharing the common =
server are not permitted to make modifications to those files. In many =
cases, such modifications can be requested and will only be made after =
lengthy delays or the payment of support and maintenance fees.=20
> =20
> If we want this sort of discovery to become generally available, and =
not just be limited to the "large" sites, we should ensure that it is as =
simple as possible to deploy.
> =20
> c a copy of the host-meta.jrd
> =20
> We would probably only do one of b or c.
> =20
> c has the advantage of being a static file and you being no worse off =
than having started with host-meta.json.
> b is the simplest for the client and only requires common rewriting =
rules.
> =20
> If the redirect is to the same host you could avoid the overhead of =
two connections by pipelining the requests over the same TCP connection.
> SPDY in the future will make that even more efficient.
> =20
> I will grant Blaine that most openID Connect discovery requests are =
Server to Server,  However there are Apps that are also clients that =
should not be ignored.
> I personally like the fixed template with a 3xx redirect and  resource =
parameter returning a JRD due to the simplicity of client coding.
> =20
> Things needing other sorts of information about the host would still =
use host-meta or host-meta.json.
> =20
> John B.
> =20
> =20
> On 2012-04-23, at 1:11 AM, Mike Jones wrote:
> =20
> I agree with your goal of simplicity for clients.  Paul=92s example =
seems about as simple as it can get for clients:
>                curl -v =
https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paulej@p=
acketizer.com
> It shares the property with your earlier example (below) that clients =
have a no-branches code path to do discovery:
>                curl -s http://example.com/.well-known/host-meta|
>                awk "/lrdd/,/template/"|tr -d '\n'|sed -e =
"s/^.*template=3D'\([^']*\)'.*$/\1/"|
>                sed -e "s/{uri}/user@example.com/"|xargs curl =96s
> =20
> However, I challenge the assumption in your note below that servers =
using only static pages must be supported.  I just don=92t see the =
requirement to implement a query parameter as being an impediment in =
practice, even for hosted domains.  I know of no hosting company that =
doesn=92t provide a means of putting executable code behind web pages, =
be it PHP, Perl, Ruby, ASP, JSP, etc.  I know you=92re trying to make =
the case for static pages, but in practice, I believe that dynamic pages =
are always easily available.
> =20
> Assuming that we=92re in an either-or situation with regard to either =
having single-GET discovery or supporting discovery using only static =
server pages (and I=92d love to have someone demonstrate to us that =
we=92re not), I=92d take single-GET discovery for sure, as in some =
cases, it makes an appreciable difference in user interface latency, and =
per the paragraph above, I believe that dynamic queries can be =
implemented on all hosting platforms.
> =20
> Assuming the WebFinger authors agree, I=92d suggest that a logical =
next step would be for a -04 version of draft-jones-appsawg-webfinger to =
be published that changes support for the resource parameter from =
RECOMMENDED to REQUIRED, as that could provide a starting point for a =
common discovery spec.
> =20
>                                                             -- Mike
> =20
> P.S.  As long as draft-jones-appsawg-webfinger is being revised, I=92d =
also suggest adding text making explicit what has been an implicit =
assumption in both WebFinger and SWD - that depending upon whether and =
how the client is authenticated, the set of resources returned may vary =
(as Blaine had pointed out earlier).  That could help deal with some of =
the privacy perceptions.
> =20
> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of Blaine Cook
> Sent: Sunday, April 22, 2012 2:15 PM
> To: apps-discuss@ietf.org
> Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus =
indirect discovery
> =20
> This is the last issue that I've flagged as blocking a new Webfinger / =
SWD draft.
> =20
> Mike suggested that being able to request a user's profile with a =
single request (i.e., that the /.well-known/ profile resource should be =
able to respond with full profile data immediately, rather than pointing =
at a second URL that will fulfil the request) is a requirement for this =
standard.
> =20
> I'd like to challenge that requirement. The arguments for a direct =
discovery endpoint are:
> =20
> 1. Fewer requests against the server, since we save (in the =
worst-case) 50% of requests by bypassing the indirect lookup phase.
> 2. Lower latency for clients (e.g., mobile clients) owing to the =
reduced number of lookups.
> =20
> The arguments for an indirect discovery endpoint are:
> =20
> 1. Trivial and web-standards friendly deployment for domains that =
won't host their own webfinger/swd profile servers, but want to enable =
accounts on their domains (e.g., statically hosted sites).
> 2. A loosening of the requirement that URLs at the bare domain must =
run dynamic scripts that respond to requests to the /.well-known/ path.
> =20
> My opinion is that the approach that SWD has proposed for the redirect =
is problematic. First, the format is very similar in form to the HTML =
"meta refresh" tag that provided HTTP redirect support from within HTML. =
That format has been widely deprecated, and in these more enlightened =
times, we just use the 3xx response codes with Location headers, =
instead.
> =20
> Secondly, the SWD request format means that for smaller sites, often =
those with the least resources, will end up serving static content in a =
way that's difficult to cache; certainly, more difficult to cache than =
just serving static content. This is due to the request parameters =
present in all SWD requests; those request parameters will bust caches.
> =20
> As for the first argument *for* SWD's approach, I'd suggest we look to =
DNS, which uses the same indirection approach for NS records, relying on =
a (relatively) very small set of root servers to handle the traffic for =
the whole internet. Clearly, this approach works, and webfinger/swd =
servers are in a much better position to handle this additional traffic. =
Most of this traffic will be heavily cached, especially for the largest =
providers.
> =20
> In fact, in terms of real deployments, hosting a script at, e.g., =
google.com/.well-known/simple-web-discovery is much harder than hosting =
a script atprofiles.google.com/profile.json for all sorts of reasons, so =
it's my belief that the first argument is a red herring.
> =20
> The second argument is legitimate, but only if mobile clients will =
actually be making requests to diverse webfinger/swd hosts. Instead, I =
strongly believe that we'll see the emergence of DNS-like servers that =
provide both profile hosting as well as proxy services. For a mobile =
client, the optimal approach will be to use SPDY to connect to a single =
host that performs webfinger/swd lookups on the mobile client's behalf, =
eliminating the latency concerns.
> =20
> I offer that the two-step lookup can be implemented without =
conditionals on the client, whereas the direct-unless-not approach =
cannot be implemented that way (see my earlier curl example for proof). =
It's simpler, and easier to explain to the (hopefully many) small site =
owners who we'd like to implement this technology.
> =20
> Thoughts? Am I missing something?
> =20
> b.
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> =20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> =20


--Apple-Mail=_A5D42719-8AEE-4BC2-90D9-2C9023AE8B13
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

If WF were to make resource REQUIRED and rel =
optional that would be a significant step =
forward.

Though the Apache http rewrite probably =
violates the host-meta processing rules Eran just described, if the =
links from host-meta must be included in order.
You could get =
around it by restricting the contents of host-meta if you are doing that =
I suppose.

John =
B.


On 2012-04-25, at 3:30 PM, =
Paul E. Jones wrote:

I =
don=92t think we need to decide specific environments we want to =
support, but *if* people want to use static files, there are =
choices we can make where the resource parameter will still work, even =
in a static environment.  Previously, I sent out a sample config =
that allows Apache to handle the =93resource=94 parameter and still map =
that to static files.  However, I cannot do the same with the =93rel=94=
 parameter, thus we could never mandate that if we want to have any hope =
at all for allowing static sites.
I =
appreciate having the =93resource=94 parameter, but I also appreciate =
some do not need (or have the ability to support) an elaborate =
server.
 apps-discuss-bounces@ietf.or=
g [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John =
Bradley
Sent: Monday, April 23, 2012 =
12:19 PM
To: Bob =
Wyman
Cc: apps-discuss@ietf.org
Subj=
ect: Re: =
[apps-discuss] Webfinger / SWD Issue #3: direct versus indirect =
discovery
I understand that in some =
environments you may not have access to http rewrite rules. =
 
Others may preclude any =
scripts.
We do have to decide what =
environments we are going to support.
 
If we stick to static files only then we are just =
putting some lipstick on Yadis by adding a way to map a email like =
address to a file.
So yes there are those =
environments, but that needs to be balanced against the additional =
overhead on the clients to support that =
environment.
John =
B.
On 2012-04-23, at 12:26 =
PM, Bob Wyman wrote:
 

Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 19:42:04 -0000

> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Wednesday, April 25, 2012 12:00 PM
> To: Eran Hammer
> Cc: Paul E. Jones; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] WF flow with rel parameter
>=20
> OK so host-meta is one level of lrdd link processing for a resource (not =
host).
>=20
> Multiple lrdd links are not precluded, but are an abuse.
>=20
> If you want to redirect to an alternate host-meta location you use 3xx an=
d
> the client will follow.
> (I heard some complaining about what if my site can't support redirects
> earlier.)
>=20
> The links are aggregated with host-meta links and filtered by "rel".
>=20
> So if in host-meta I have:
> {
>        "rel" : "http://openid.net/specs/connect/issuer",
>        "href" : "https://server.example.com"
>      }
>=20
> before my lrdd entry

Only if you change 'href' above to 'template'. 'href' are host-wide only an=
d do not apply to resource-specific.

If you make a host-wide request, lrdd links and all templates are ignored.
If you make a resource-specific request, all href links in host-meta are ig=
nored, templates expanded, and lrdd templates followed and included inline.

EH

> That would be returned in the filtered list before any resource specific =
"rel" ?
>=20
> Thus making a global setting for all resources.
>=20
> I don't think the original Connect proposal had per user discovery only p=
er
> host via host meta without following lrdd.
>=20
> If aggrigating and sorting links are a requirement, that needs to be done
> server side for Connect clients.
>=20
> John B.
>=20
>=20
>=20
>=20
>=20
> On 2012-04-25, at 3:29 PM, Eran Hammer wrote:
>=20
> >
> >
> >> -----Original Message-----
> >> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >> Sent: Wednesday, April 25, 2012 10:38 AM
> >> To: Eran Hammer
> >> Cc: Paul E. Jones; apps-discuss@ietf.org
> >> Subject: Re: [apps-discuss] WF flow with rel parameter
> >>
> >> Eran,
> >>
> >> It was unclear, at least to me that the server side host-meta processi=
ng
> rule
> >> specified in WF requires all the templates (or just the LRDD ones) to =
be
> >> processed substituting inserting "resource" for URI and then retrievin=
g
> and
> >> merging all the resource JRD before processing the filter on the "rel"=
.
> >>
> >> If I defined a rel of FOO would WF fill the template and retrieve the =
JRD
> and
> >> merge its links with the lrdd JRD?
> >> I might think that would be a touch confusing to clients.
> >
> > No. It only does *one* level of LRDD import (in order). See:
> >
> > http://tools.ietf.org/html/rfc6415#section-4.2
> >
> >> So I go back to the rational explanation that lrdd templates are expan=
ded
> and
> >> those links rolled up and filtered.
> >>
> >> Now I am guessing that some of the SWD people are thinking that when
> the
> >> server is using flat files that puts a lot of burden onto the client.
> >>
> >> Probably why you added the server side processing.
> >
> > The idea of adding server-side processing and filtering via the query c=
ame
> out of the original OpenID Connect proposal that David Recordon and I
> wrote, trying to keep the clients super simple and avoid the need to go f=
etch
> host-meta, then one or more LRDD documents.
> >
> > Complexity is very much implementation specific on the server side. Yah=
oo
> doesn't have LRDD documents and puts everything as link templates in host=
-
> meta while others like the ability to customize. The most likely scenario=
 of
> servers including LRDD links in host-meta is that the host-meta document =
is
> static, while the LRDD links are dynamically generated. Otherwise, there =
is
> very little value in the added complexity. In that case, the client will =
typically
> be faced with 2 requests.
> >
> > I would argue that a server using multiple LRDD links in host-meta is a=
busing
> the system, very much like a server using multiple 3xx redirections betwe=
en
> its initial host-meta endpoint to where the document actually lives.
> >
> > IOW, there are many ways to inflict pain on the client.
> >
> >> Given that WF takes the liberty of adding query parameters to host-met=
a
> >> and seems to define host-meta processing rules (perhaps for non lrdd?)=
, I
> >> am not finding the separation of the two specs as clean as possible.
> >> It seems a bit like there is there a RFC 6415 dependency on WF.  Thoug=
h
> that
> >> is a touch strange for a RFC.
> >
> > The WF draft should not introduce any new processing rules. It should o=
nly
> add the query optimization but that must result in exactly the same set o=
f
> links as defined by 6415. If this is the case, it's a bug.
> >
> >> What stops someone from defining a relation of super-discovery and
> adding
> >> some query parameters to host-meta.json to hover up some lrdd based
> on a
> >> template expansion of  "super-discovery" rel types, and filter on "rel=
"?
> >>
> >> I wouldn't have thought to do that because stepping on the RFC 6415
> >> endpoint seems slightly wrong to me.
> >>
> >> I would probably define a new endpoint /.well-known/super-discovery
> with
> >> my own query parameters and processing rules for JRD documents.
> >
> > That would be the right approach. Note that 6415 registers both host-me=
ta
> (defaults to XML) and host-meta.json (JSON required).
> >
> >> Without being able to make server-side processing of host-meta
> required,
> >> we need someway to delegate that to another endpoint.
> >>
> >> In XRD we did discuss delegating the entire XRD.  Is there a way to do=
 that
> in
> >> host-meta?
> >
> > 3xx.
> >
> > EH
> >
> >> At the moment all of the processing gets pushed back on the client if =
the
> >> host only supports static files in /.well-known
> >>
> >> John B.
> >>
> >>
> >>
> >> On 2012-04-25, at 1:34 PM, Eran Hammer wrote:
> >>
> >>> It is important to understand the semantics of host-meta, which I thi=
nk
> >> there is some confusion about here.
> >>>
> >>> As a mechanism, host-meta providers you with a method of obtaining
> both
> >> host-wide and resource-specific links (and properties). To accomplish
> that, it
> >> provides with both a document and processing rules.
> >>>
> >>> WebFinger - the name given for the host-meta *use-case* of retrieving
> >> user information - is a specialization of obtaining resource-specific =
links.
> >>>
> >>> The 'rel' and 'resource' query parameters (as proposed) apply to the
> >> endpoint *after* executing the processing rules (which include expandi=
ng
> >> templates and importing links from one level LRDD documents).
> >>>
> >>> LRDD documents only apply to resource-specific links, which means the=
y
> >> are ignored for any host-wide query. For example, the location of the
> site's
> >> TOS document. From the host-meta perspective, LRDD documents are
> just a
> >> deployment tool to provide customization not possible using just link
> >> templates at the host-meta document level. It's just a link-include
> >> mechanism, and host-meta uses it restrictively.
> >>>
> >>> IMO, the 'rel' and 'resource' optimization should only apply to the h=
ost-
> >> meta endpoint, and act as a filter post the processing rules. If 'reso=
urce' is
> >> specified, it is a resource-specific request, otherwise, host-wide.
> >>>
> >>> Let me know if this helps or if it is still unclear.
> >>>
> >>> EH
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >>>> Sent: Wednesday, April 25, 2012 8:27 AM
> >>>> To: Eran Hammer
> >>>> Cc: Paul E. Jones; apps-discuss@ietf.org
> >>>> Subject: Re: [apps-discuss] WF flow with rel parameter
> >>>>
> >>>> That was one thing that initially confused me.  The rel filter is no=
t
> applied
> >> to
> >>>> host-meta, but rather the linked lrdd resource JRD.
> >>>>
> >>>> The currently defined "resource" parameter has an implicit host-meta
> >> "rel"
> >>>> of "lrdd".
> >>>>
> >>>> To use this mechanism for other relations you would need to make tha=
t
> >>>> parameter explicit.
> >>>>
> >>>> That then raises the question of the filter being part of host-meta =
or
> WF if
> >> it
> >>>> applies to relationships other than lrdd.
> >>>>
> >>>> If you are asking if filtering should be supported by lrdd where you=
 start
> >>>> discovery from a link header, then it probably should be possible as
> well.
> >>>>
> >>>> Though I thought lrdd stopped being updated over a year a year ago.
> >> Sorry if
> >>>> I am out of date.
> >>>>
> >>>> So XRD/JRD documents SHOULD be filterable by "rel" independent of if
> >> you
> >>>> get to them via lrdd or host-meta.
> >>>>
> >>>> Host-meta SHOULD support a mechanism to filter by "rel" or filter by=
 a
> >>>> combination of "resource" (uri) , host-meta-rel and resource-rel (th=
e
> >> host-
> >>>> meta-rel is currently implicit.)
> >>>>
> >>>> I recall discussing this in the XRI TC when we did XRD years ago, th=
ough
> >> that
> >>>> was more around using XRI identifiers.
> >>>>
> >>>> The same principal still holds.  I should be able to ask for.
> >>>> GET /.well-known/host-meta.json
> >>>>    ?resource=3Djoe@example.com
> >>>>    &host-meta-rel=3Dlrdd
> >>>>
> >> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> >>>> HTTP/1.1
> >>>> Host: example.com
> >>>>
> >>>> (personally I think calling the parameter "resource" and the templat=
e
> {uri}
> >>>> will be confusing to people)
> >>>>
> >>>> In SWD we used fixed the parameter names and the base URI is the
> part
> >> that
> >>>> gets changed when the /.well-known can't host a script.
> >>>> That makes the template simpler for the client to process.  The
> equivalent
> >> to
> >>>> "rel" is always passed to make processing simpler.
> >>>>
> >>>> As Blaine has pointed out several times SWD and WF largely get us to
> the
> >>>> same place.
> >>>>
> >>>> I am trying to find a way to close the gap.
> >>>>
> >>>> John B.
> >>>>
> >>>>
> >>>> On 2012-04-25, at 11:41 AM, Eran Hammer wrote:
> >>>>
> >>>>> Purely from a practical standpoint, do you think it is likely that =
a server
> >> will
> >>>> support the query filter for the lrdd documents but not for host-met=
a?
> >>>>>
> >>>>> EH
> >>>>>
> >>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> >>>> bounces@ietf.org] On Behalf Of John Bradley
> >>>>> Sent: Wednesday, April 25, 2012 6:17 AM
> >>>>> To: Paul E. Jones
> >>>>> Cc: apps-discuss@ietf.org
> >>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
> >>>>>
> >>>>> Paul,
> >>>>>
> >>>>> "rel" as a filter is something WF has for host-meta.  It however do=
esn't
> >>>> seem to have that for user JRD in the case where host-meta is
> returned,
> >> and
> >>>> the template is used.
> >>>>>
> >>>>> The "resource" and "rel" parameters are already an optimization for
> >> LRDD
> >>>> and not part of host-meta.
> >>>>> Adding LRDD specific parameters to host-meta/host-meta.json will
> >>>> probably raise some eyebrows in review, but I am OK with it.
> >>>>>
> >>>>> I think there are use cases where size matters.  Where a host-meta =
or
> >>>> resource JRD may be large and it is more efficient not to send the
> whole
> >>>> thing to a mobile client.
> >>>>> It seems to be one of Mike Jones requirements.
> >>>>>
> >>>>> Using RFC6570 for LRDD is a possibility for passing through the fil=
ter
> >> request
> >>>> for sites that support filtering on resource JRD.
> >>>>>
> >>>>> What other proposals do you have.  I am guessing that filtering on
> >> resource
> >>>> JRD is not a totally new topic.
> >>>>>
> >>>>> LRDD is the one really doing the optimization  in any event,  it ma=
y be
> >> done
> >>>> at the host-meta GET but it is a LRDD specific extension.
> >>>>> Having it in the template allows LRDD to filter at the resource JRD=
 in
> >> cases
> >>>> where it is not possible to do it at the host-meta level, due to som=
e no
> >> script
> >>>> or other restriction.
> >>>>>
> >>>>> I agree that it should be filtered at the how-meta request but you =
and
> >>>> others say that is not always possible.
> >>>>>
> >>>>> John B.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
> >>>>>
> >>>>>
> >>>>> John,
> >>>>>
> >>>>> The "rel" parameter is something we still need to discuss, so not i=
s as
> >> good
> >>>> a time as any.
> >>>>>
> >>>>> What "rel" does is act as a filter.  For the most part, the only pu=
rpose it
> >>>> serves is to help reduce the number of link relations that might be =
sent
> >> from
> >>>> the server.  So, if a user had 1,000 different link relations, this =
might
> >> reduce
> >>>> the returned message to containing only 1.  However, if a user has
> more
> >> than
> >>>> one link relation of the same type, all of them would match and be
> >> returned.
> >>>>>
> >>>>> When you say the host cannot support re-write rules, I assume you
> >> mean it
> >>>> does not support the URI parameters on host-meta?  In that case, yes=
,
> >> the
> >>>> parameters are ignored and you get just the host-meta document.
> >>>>>
> >>>>> The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1).
> There
> >> are
> >>>> no other URI template values defined.  (Note: this whole section exi=
sts
> >> only
> >>>> because RFC  6570 did not yet exist, I think.
> >>>>>
> >>>>> In any case, we could define a new URI template, but then we would
> be
> >>>> putting an optimization in place for LRDD.  If host-meta is not goin=
g to
> >>>> support the "rel" URI parameter, why would LRDD?  It would also mean
> >> that
> >>>> the LRDD logic would have to be ready to receive a URI parameter tha=
t
> is
> >> not
> >>>> replaced, since some clients would only change {uri} and leave {rel}
> there.
> >>>> That would introduce more conditional logic in the server.  This wou=
ld
> also
> >>>> present issues with static sites.  (Of course, one might be able to =
use
> >> Apache
> >>>> re-writing rules to get around that problem, but it certainly would =
not
> >> work
> >>>> for "real" static sites.)
> >>>>>
> >>>>> Personally,  I'd prefer to not add the "rel" parameter to LRDD, sin=
ce I
> >> think
> >>>> optimization using "rel" would always be done on host-meta.  That sa=
id,
> I
> >>>> question the value of "rel" entirely.  Do you think it's useful to h=
ave this
> >> filter
> >>>> at all?  Is there really a risk that a site might return 1,000 link =
relations
> that
> >> the
> >>>> client would have to step over?
> >>>>>
> >>>>> Paul
> >>>>>
> >>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >>>>> Sent: Tuesday, April 24, 2012 10:17 PM
> >>>>> To: Paul E. Jones
> >>>>> Cc: apps-discuss@ietf.org
> >>>>> Subject: WF flow with rel parameter
> >>>>>
> >>>>> Paul,
> >>>>>
> >>>>> Sorry I hit send on the previous message with a typo.
> >>>>>
> >>>>> I am looking at how the flows in WF might work for openID.
> >>>>>
> >>>>> Let's set aside the XML issue for the moment and focus on the JSON
> >> flow.
> >>>>>
> >>>>> Please correct anything I get wrong.
> >>>>>
> >>>>> The openID Connect defines a relation of
> >>>> http://openid.net/specs/connect/issuer
> >>>>>
> >>>>> WF allows for a JSON host-meta that takes two parameters,
> "resource"
> >> and
> >>>> "rel"
> >>>>>
> >>>>> An example request and response (line-brakes for readability)
> >>>>>
> >>>>> GET /.well-known/host-meta.json
> >>>>>    ?resource=3Djoe@example.com
> >>>>>
> >> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> >>>> HTTP/1.1
> >>>>> Host: example.com
> >>>>>
> >>>>>  HTTP/1.1 200 OK
> >>>>>
> >>>>>  Access-Control-Allow-Origin: *
> >>>>>  Content-Type: application/json; charset=3DUTF-8
> >>>>>
> >>>>>  {
> >>>>>    "subject" : "joe@example.com",
> >>>>>    "links" :
> >>>>>    [
> >>>>>      {
> >>>>>        "rel" : "http://openid.net/specs/connect/issuer",
> >>>>>        "href" : "https://server.example.com"
> >>>>>      }
> >>>>>    ]
> >>>>>  }
> >>>>>
> >>>>> If the host can't support rewrite rules or scripts the exchange wou=
ld
> look
> >>>> like:
> >>>>>
> >>>>> GET /.well-known/host-meta.json
> >>>>>    ?resource=3Djoe@example.com
> >>>>>
> >> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> >>>> HTTP/1.1
> >>>>> Host: example.com
> >>>>>
> >>>>> HTTP/1.1 200 OK
> >>>>>  Access-Control-Allow-Origin: *
> >>>>>  Content-Type: application/json; charset=3DUTF-8
> >>>>>  {
> >>>>>    "expires" : "2012-03-13T20:56:11Z",
> >>>>>    "links" :
> >>>>>    [
> >>>>>      {
> >>>>>        "rel" : "lrdd",
> >>>>>        "type" : "application/json",
> >>>>>        "template" :
> >>>>>          "https://example.com/lrdd/?format=3Djson&resource=3D{uri}"
> >>>>>      }
> >>>>>
> >>>>> GET /lrdd/
> >>>>>    ?format=3Djson
> >>>>>    &resource=3Djoe@example.com
> >>>>> Host: example.com
> >>>>>
> >>>>> HTTP/1.1 200 OK
> >>>>>
> >>>>>  Access-Control-Allow-Origin: *
> >>>>>  Content-Type: application/json; charset=3DUTF-8
> >>>>>
> >>>>>  {
> >>>>>    "subject" : "joe@example.com",
> >>>>>    "links" :
> >>>>>    [
> >>>>>      {
> >>>>>        "rel" : "http://openid.net/specs/connect/issuer",
> >>>>>        "href" : "https://server.example.com"
> >>>>>      },
> >>>>>      {
> >>>>>        "rel" : "http://webfinger.net/rel/avatar",
> >>>>>        "href" : "http://example.com/~joe/joe.jpg"
> >>>>>      }
> >>>>>
> >>>>>    ]
> >>>>>  }
> >>>>>
> >>>>> I can't find a template parameter for "rel".  The host-meta spec al=
lows
> >> for
> >>>> extension but it is missing.
> >>>>>
> >>>>> What if the server wants to support filtering on rel but can't supp=
ort it
> in
> >>>> the root for some reason?
> >>>>>
> >>>>> Is it possible to have a template like:
> >>>>> "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{re=
l}"
> >>>>>
> >>>>> That simple addition may solve a number of problems for openID.
> >>>>>
> >>>>> John B.
> >>>>>
> >>>>>
> >>>>>
> >>>
> >


From flefauch@cisco.com  Wed Apr 25 11: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 490CD21F88E8 for ; Wed, 25 Apr 2012 11:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.466
X-Spam-Level: 
X-Spam-Status: No, score=-9.466 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAxCYLfG5sYz for ; Wed, 25 Apr 2012 11:34:16 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0DC21F8832 for ; Wed, 25 Apr 2012 11:34:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=46346; q=dns/txt; s=iport; t=1335378854; x=1336588454; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=QxQSCbJQeBBHUhqn+M7lSqvY+inajqacEyr7sAUaF+o=; b=ObCHkBIObTPRsZbht6tu9nLhe+q+Z6ePVl2mqYZtMX0Zy7cr3WlBE7jC MZ+uEmWhNxkpALZRg1ADtajlBJQKOzVz2HwFXpSZ0wv0NG/e7xYYYtjji EcVCqXKey2ZSTCgIEQaLL6YLErOSa1Ifq83WWjQZcZYXXA6CYjbcWbRiS E=;
X-Files: image001.jpg, green.gif : 11041, 87
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600";  d="gif'147?jpg'147,145?scan'147,145,208,145,147,217";a="136228531"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 25 Apr 2012 18:34:13 +0000
Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3PIYBnX009643; Wed, 25 Apr 2012 18:34:11 GMT
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5AB648E7-8C2B-409E-A6DB-60EB57BF4DA9"
From: Francois Le Faucheur 
In-Reply-To: <4F8C3E49.5030100@bell-labs.com>
Date: Wed, 25 Apr 2012 20:34:06 +0200
Message-Id: <8CD8D5FA-CCA8-4A3F-B7C5-62F91B311002@cisco.com>
References: <4F8C3E49.5030100@bell-labs.com>
To: "Vijay K. Gurbani" , draft-ietf-cdni-problem-statement@tools.ietf.org
X-Mailer: Apple Mail (2.1257)
X-Mailman-Approved-At: Wed, 25 Apr 2012 12:53:56 -0700
Cc: Le Faucheur Francois , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Review of draft-ietf-cdni-problem-statement-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, 25 Apr 2012 18:34:18 -0000

--Apple-Mail=_5AB648E7-8C2B-409E-A6DB-60EB57BF4DA9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Vijay, Ben, Nabil, all,

On 16 Apr 2012, at 17:44, Vijay K. Gurbani wrote:
>=20
> Major Issues:
> - S6: I believe that expanding the security considerations for each
> CDNI interface will help in the long run.

Below is an edited/expanded version of the Security Considerations =
section that integrates Vijay's comment and also captures a couple of =
high-level points from the Security Considerations section of the =
cdni-framework. Can you guys review and refine if needed?

I think we can integrate Vijay's Minor comments and nits offline.

Thanks much to Vijay for the useful review.

Francois


6.  Security Considerations

Distribution of content by a CDN comes with a range of security
   considerations such as how to enforce control of access to the
   content by users in line with the CSP policy, or how to trust the =
logging information generated by the CDN for the purposes of charging =
the CSP. These security aspects
   are already dealt with by CDN Providers and CSPs today in the context
   of standalone CDNs.  However, interconnection of CDNs introduces a
   new set of security considerations by extending the trust model to a =
chain of trust (i.e.
   the CSP "trusts" a CDN that "trusts" another CDN).
The mechanisms used to mitigate these risks in multi-CDN environments =
may be similar to those used in the single CDN case, but their
   suitability in this more complex environment must be validated.

   Maintaining the security of the content itself, its associated
   metadata (including delivery policies) and the CDNs
   distributing and delivering it, are critical requirements for both
   CDN Providers and CSPs and the CDN Interconnection interfaces must
   provide sufficient mechanisms to maintain the security of the overall
  system of interconnected CDNs as well as the information (content,
   metadata, logs, etc) distributed and delivered through any set of =
interconnected CDNs.

6.1 Security of the CDNI Control Interface

  Information on this interface is of a very private nature.
  A pair of CDNs use this interface to allow bootstrapping of all the =
other CDNI interfaces possibly including establishment of the mechanisms =
for securing these interfaces. Therefore, corruption of that interface =
may result in corruption of all other interfaces.=20
Using this interface, an upstream CDN may pre-position or delete content =
or metadata in a downstream
  CDN and a downstream CDN may provide administrative information to an =
upstream CDN, etc.
  All of these operations require that the peer CDNs are appropriately
  authenticated and that the confidentiality and integrity of =
information flowing
  between them can be ensured.

6.2 Security of the CDNI Request Routing Interface

  Appropriate levels of authentication and confidentiality must be
  used in this interface because it allows an upstream CDN to
  query the downstream CDN in order to redirect requests, and =
conversely, allows
  the downstream CDN to influence the upstream CDN's Request Routing
  function.

  Absent appropriate security on this interface, a rogue upstream
  CDN can inundate downstream CDNs with bogus requests, or have the
  downstream CDN send the rogue upstream CDN private information. Also, =
a rogue downstream CDN could influence the upstream CDN so the uCDN =
redirects requests to the rogue dCDN or another dCDN in order to attract =
additional delivery revenue.

6.3 Security of the CDNI Metadata Interface

  Because this interface allows a downstream CDN to request metadata
  from an upstream CDN, the latter must ensure that the former is
  appropriately authenticated before sending the data.  Conversely,
  a downstream CDN must authenticate an upstream CDN before requesting
  metadata to insulate itself from poisoning by rogue upstream CDNs.
  The confidentiality and integrity of the information exchanged between =
the peers
  must be protected.

6.4 Security of the CDNI Logging Interface

  Logging data consists of potentially sensitive information (which
  user accesses which media resource, IP addresses of users, potential
  names and subscriber account information, etc.) Confidentiality of =
this information
  must be protected as the log records are moved between hosts.
This information may also be sensitive from the viewpoint that it can be =
the basis for charging across CDNs. Therefore, appropriate levels of =
protection are needed against corruption, duplication and loss of this =
information.=20





>  Here is a first stab at
> this that you may want to consider replacing the second paragraph
> with (please feel free to expand this since you are the subject
> matter experts here).  Suggested text:
>=20
> 6.1 Security of the CDNI Request Routing Interface
>=20
>   Appropriate levels of authentication and confidentiality must be
>   used in this interface because it allows an upstream CDN to
>   query capabilities of a downstream CDN, and conversely, allows
>   the downstream CDN to control the upstream CDN's Request Routing
>   function.
>=20
>   Absent appropriate security on this interface, a rogue upstream
>   CDN can inundate downstream CDNs with bogus requests, or have the
>   downstream CDN send the rogue upstream CDN private information
>  (e.g., load, resources).
>=20
> 6.2 Security of the CDNI Control Interface
>=20
>   Information on this interface is of a very private nature as well.
>   A pair of CDNs use this interface to allow bootstrapping of content
>   acquisition; an upstream CDN may pre-position content in a =
downstream
>   CDN, or it may purge the contents at a downstream CDN; a downstream
>   CDN may provide administrative information to an upstream CDN, etc.
>   All of these operations require that the peer CDNs are appropriately
>   authenticated and that the confidentiality of information flowing
>   between them is maintained.
>=20
> 6.3 Security of the CDNI Metadata Interface
>=20
>   Because this interface allows a downstream CDN to request metadata
>   from an upstream CDN, the latter must ensure that the former is
>   appropriately authenticated before sending the data.  Conversely,
>   a downstream CDN must authenticate an upstream CDN before requesting
>   metadata to insulate itself from poisoning by rouge upstream CDNs.
>   The confidentiality of the information exchanged between the peers
>   must be protected.
>=20
> 6.4 Security of the CDNI Logging Interface
>=20
>   Logging data consists of potentially sensitive information (which
>   user accesses which media resource, IP addresses of users, potential
>   names and subscriber account information, etc.)  This information
>   must be protected as the log records are moved between hosts.
>=20
> Minor Issues:
>=20
> - S1: Your problem statement essentially is an interplay between
> four logical entities: end user, CSP, CDN, and NSP.  I think this
> interplay needs to be laid out a bit more explicitly.  It seems to me
> that your model is that a user is subscribed to a CSP.   The CSP has
> arrangements with various CDN providers to distribute content.  The
> user, at a certain point in time, is in a network owned by a NSP that
> uses a CDN that does not have receive content from CSP.  Thus CSP is
> at a disadvantage since it will have to serve the user from a CDN that
> is not necessarily close to the user, thereby introducing a reduced
> quality of experience for the user.
>=20
> What CDNI does is enable the CSP to contract with an "authoritative"
> CDN provider for the delivery of content and that that
> authoritative CDN Provider could contract with one or more downstream
> CDN Provider(s) to distribute and deliver some or all of the content
> on behalf of the authoritative CDN Provider.  Because the downstream
> CDN Provider(s) will be closer to the user, the user is subjected to
> a better viewing experience than he or she would be had the content
> been delivered from a farther CDN.
>=20
> I think that laying out the interplay between the four entities in
> the second paragraph of S1 more explicitly may provide better context
> to the reader who is not already well versed with CDNs.
>=20
> - S1: I would advise to order the terms defined by an alphabetical
> order (if possible).
>=20
> - S3, last paragraph: The term "where to go" is rather ambiguous.
> Do you mean, "which upstream CDN to acquire content from"?  Or
> something else?  It will help to make this more explicit.
>=20
> - S4, last paragraph: it is stated that "we assume that this =
[developing
> a new protocol] is unnecessary".  Based on the contents of S4.1-
> S4.4, I believe you do more than "assume".  You clearly enunciate a
> list of protocols that can be used for the various interfaces, thus
> providing a first order reasoning for why a new protocol for CDNI
> is not needed.
>=20
> Therefore, I would exhort you to use a stronger word than "assume";
> something like:
>=20
>   Secondly, although a new application protocol could be designed
>   specifically for CDNI, our analysis below shows that this is
>   unnecessary ...
>=20
> - S4.3: Are these "log lines" or "log records"?  Presumably, one or
> more lines will aggregate to one log record.  It seems appropriate
> in this document to talk about "log records" instead of "log lines".
> The CDNI logging interface draft can tease out more precisely how
> many lines comprise a record, etc.
>=20
> Secure ftp and secure copying (scp) appears to be missing in the list
> of protocols.  I would suspect that sftp would be preferred over
> normal ftp.
>=20
> Nits:
>=20
> - Global: In the Abstract and S1, "End Users" is employed multiple
> times.  End Users is defined in the Terminology section as a
> definition.  I would propose that attach the acronym "EU" on
> the first encounter of "End User" in the Abstract and S1,
> and from then on simply use "EU".
>=20
> - S1, second paragraph: "attachment network" sounds incomplete.
> Maybe you meant "attachment to the network"?
>=20
> - S3: s/existing protocols: this is/existing protocols; this is/
>=20
> - S4.1, last paragraph: May be good to give a reference to ALTO.
>=20
> Thanks,
>=20
> - vijay
> --=20
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
> Web:   http://ect.bell-labs.com/who/vkg/



Francois Le Faucheur
Distinguished Engineer
Service Provider Video Technology Group  =20
flefauch@cisco.com
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90



Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com


=20


 Think before you print.

This email may contain confidential and privileged material for the sole =
use of the intended recipient. Any review, use, distribution or =
disclosure by others is strictly prohibited. If you are not the intended =
recipient (or authorized to receive for the recipient), please contact =
the sender by reply email and delete all copies of this message.

Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue =
Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy =
les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, =
Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html



--Apple-Mail=_5AB648E7-8C2B-409E-A6DB-60EB57BF4DA9
Content-Type: multipart/related;
	type="text/html";
	boundary="Apple-Mail=_D6AE22B4-627E-4EEE-BE17-F9F97BE9CF2E"


--Apple-Mail=_D6AE22B4-627E-4EEE-BE17-F9F97BE9CF2E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252








6. =
 Security Considerations

Distribution of content =
by a CDN comes with a range of security
  =
 considerations such as how to enforce control of access to =
the
   content by users in line with the CSP policy, =
or how to trust the logging information generated by the CDN for the =
purposes of charging the CSP. These security =
aspects
   are already dealt with by CDN Providers =
and CSPs today in the context
   of standalone CDNs. =
 However, interconnection of CDNs introduces a
  =
 new set of security considerations by extending the trust model to =
a chain of trust (i.e.
   the CSP "trusts" a CDN =
that "trusts" another CDN).
The mechanisms used to =
mitigate these risks in multi-CDN environments may be similar to =
those used in the single CDN case, but their
  =
 suitability in this more complex environment must be =
validated.

   Maintaining the =
security of the content itself, its associated
  =
 metadata (including delivery policies) and the =
CDNs
   distributing and delivering it, are critical =
requirements for both
   CDN Providers and CSPs and =
the CDN Interconnection interfaces must
   provide =
sufficient mechanisms to maintain the security of the =
overall
  system of interconnected CDNs as well as the =
information (content,
   metadata, logs, etc) =
distributed and delivered through any set of interconnected =
CDNs.

6.1 Security of the CDNI Control =
Interface

  Information on this interface is of a very =
private nature.
  A pair of CDNs use this interface to allow =
bootstrapping of all the other CDNI interfaces possibly including =
establishment of the mechanisms for securing these interfaces. =
Therefore, corruption of that interface may result in corruption of all =
other interfaces. 
Using this interface, an upstream CDN =
may pre-position or delete content or metadata in a =
downstream
  CDN and a downstream CDN may =
provide administrative information to an upstream CDN, =
etc.
  All of these operations require that the peer CDNs =
are appropriately
  authenticated and that the confidentiality =
and integrity of information flowing
  between them can be =
ensured.

6.2 Security of the CDNI Request =
Routing Interface

  Appropriate levels of authentication and =
confidentiality must be
  used in this interface because it =
allows an upstream CDN to
  query the downstream CDN in order to =
redirect requests, and conversely, allows
  the downstream CDN =
to influence the upstream CDN's Request Routing
  =
function.

  Absent appropriate security on this interface, a =
rogue upstream
  CDN can inundate downstream CDNs with bogus =
requests, or have the
  downstream CDN send the rogue upstream =
CDN private information. Also, a rogue downstream CDN could influence =
the upstream CDN so the uCDN redirects requests to the rogue dCDN or =
another dCDN in order to attract additional delivery revenue.

6.3 =
Security of the CDNI Metadata Interface

  Because this =
interface allows a downstream CDN to request metadata
  from an =
upstream CDN, the latter must ensure that the former is
  =
appropriately authenticated before sending the data. =
 Conversely,
  a downstream CDN must authenticate an =
upstream CDN before requesting
  metadata to insulate itself =
from poisoning by rogue upstream CDNs.
  The confidentiality and =
integrity of the information exchanged between the peers
  must =
be protected.

6.4 Security of the CDNI Logging =
Interface

  Logging data consists of potentially sensitive =
information (which
  user accesses which media resource, IP =
addresses of users, potential
  names and subscriber account =
information, etc.) Confidentiality of this information
  must be =
protected as the log records are moved between hosts.
This =
information may also be sensitive from the viewpoint that it can be the =
basis for charging across CDNs. Therefore, appropriate levels of =
protection are needed against corruption, duplication and loss of this =
information. 





 Here is a first stab at
 =
this that you may want to consider replacing the second paragraph
 =
with (please feel free to expand this since you are the subject
 =
matter experts here).  Suggested text:

 6.1 Security of the =
CDNI Request Routing Interface

   Appropriate levels of =
authentication and confidentiality must be
   used in this =
interface because it allows an upstream CDN to
   query =
capabilities of a downstream CDN, and conversely, allows
 =
  the downstream CDN to control the upstream CDN's Request =
Routing
   function.

   Absent appropriate =
security on this interface, a rogue upstream
   CDN can =
inundate downstream CDNs with bogus requests, or have the
 =
  downstream CDN send the rogue upstream CDN private =
information
  (e.g., load, resources).

 6.2 Security of =
the CDNI Control Interface

   Information on this =
interface is of a very private nature as well.
   A pair of =
CDNs use this interface to allow bootstrapping of content
 =
  acquisition; an upstream CDN may pre-position content in a =
downstream
   CDN, or it may purge the contents at a =
downstream CDN; a downstream
   CDN may provide =
administrative information to an upstream CDN, etc.
   All =
of these operations require that the peer CDNs are appropriately
 =
  authenticated and that the confidentiality of information =
flowing
   between them is maintained.

 6.3 Security =
of the CDNI Metadata Interface

   Because this =
interface allows a downstream CDN to request metadata
 =
  from an upstream CDN, the latter must ensure that the former =
is
   appropriately authenticated before sending the data. =
 Conversely,
   a downstream CDN must authenticate an =
upstream CDN before requesting
   metadata to insulate =
itself from poisoning by rouge upstream CDNs.
   The =
confidentiality of the information exchanged between the peers
 =
  must be protected.

 6.4 Security of the CDNI Logging =
Interface

   Logging data consists of potentially =
sensitive information (which
   user accesses which media =
resource, IP addresses of users, potential
   names and =
subscriber account information, etc.)  This information
 =
  must be protected as the log records are moved between =
hosts.

Minor Issues:

- S1: Your problem statement =
essentially is an interplay between
 four logical entities: end user, =
CSP, CDN, and NSP.  I think this
 interplay needs to be laid out =
a bit more explicitly.  It seems to me
 that your model is that =
a user is subscribed to a CSP.   The CSP has
 arrangements =
with various CDN providers to distribute content.  The
 user, at =
a certain point in time, is in a network owned by a NSP that
 uses a =
CDN that does not have receive content from CSP.  Thus CSP is
 =
at a disadvantage since it will have to serve the user from a CDN =
that
 is not necessarily close to the user, thereby introducing a =
reduced
 quality of experience for the user.

 What CDNI does =
is enable the CSP to contract with an "authoritative"
 CDN provider =
for the delivery of content and that that
 authoritative CDN Provider =
could contract with one or more downstream
 CDN Provider(s) to =
distribute and deliver some or all of the content
 on behalf of the =
authoritative CDN Provider.  Because the downstream
 CDN =
Provider(s) will be closer to the user, the user is subjected to
 a =
better viewing experience than he or she would be had the content
 =
been delivered from a farther CDN.

 I think that laying out the =
interplay between the four entities in
 the second paragraph of S1 =
more explicitly may provide better context
 to the reader who is not =
already well versed with CDNs.

- S1: I would advise to order the =
terms defined by an alphabetical
 order (if possible).

- S3, =
last paragraph: The term "where to go" is rather ambiguous.
 Do you =
mean, "which upstream CDN to acquire content from"?  Or
 =
something else?  It will help to make this more explicit.

- =
S4, last paragraph: it is stated that "we assume that this =
[developing
 a new protocol] is unnecessary".  Based on the =
contents of S4.1-
 S4.4, I believe you do more than "assume". =
 You clearly enunciate a
 list of protocols that can be used for =
the various interfaces, thus
 providing a first order reasoning for =
why a new protocol for CDNI
 is not needed.

 Therefore, I =
would exhort you to use a stronger word than "assume";
 something =
like:

   Secondly, although a new application protocol =
could be designed
   specifically for CDNI, our analysis =
below shows that this is
   unnecessary ...

- S4.3: =
Are these "log lines" or "log records"?  Presumably, one or
 =
more lines will aggregate to one log record.  It seems =
appropriate
 in this document to talk about "log records" instead of =
"log lines".
 The CDNI logging interface draft can tease out more =
precisely how
 many lines comprise a record, etc.

 Secure ftp =
and secure copying (scp) appears to be missing in the list
 of =
protocols.  I would suspect that sftp would be preferred over
 =
normal ftp.

Nits:

- Global: In the Abstract and S1, "End =
Users" is employed multiple
 times.  End Users is defined in the =
Terminology section as a
 definition.  I would propose that =
attach the acronym "EU" on
 the first encounter of "End User" in the =
Abstract and S1,
 and from then on simply use "EU".

- S1, =
second paragraph: "attachment network" sounds incomplete.
 Maybe you =
meant "attachment to the network"?

- S3: s/existing protocols: =
this is/existing protocols; this is/

- S4.1, last paragraph: May =
be good to give a reference to ALTO.

Thanks,

- vijay
-- =

Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent =
Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: =
vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-luc=
ent.com
Web:   http://ect.bell-labs.com/who/vk=
g/





Francois Le =
Faucheur
Distinguished =
Engineer
Service Provider Video Technology Group =
  
Cisco Systems =
France
Greenside
400 Ave de Roumanille
06410 Sophia =
Antipolis
France
Cisco.com

 


 Think before you =
print.


/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB
AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu
TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf
AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF
EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ
SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB
AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy
gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk
ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI
ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49
/wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx
SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo
tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+
v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ
xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi
zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44
mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN
RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ
0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P
Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs
FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn
SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs
6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh
ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68
A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/
AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7
/wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn
wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP
4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct
jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4
b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM
HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v
Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM
/wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63
4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh
8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4
qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/
8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD
9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv
p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF
ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV
SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p
gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg
q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd
rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H
31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1
5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY
nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g
8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm
ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF
mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF
FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do
aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y
ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM
yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh
XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w
3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK
1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg
nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8
9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa
Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf
BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115
9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD
46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx
vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK
XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW
k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs
jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew
+IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin
/BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd
Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz
DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg
7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8
SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct
gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18
THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr
23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv
/FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX
9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH
enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403
VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh
joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk
4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN
d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc
W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj
w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF
TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M
eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe
teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX
xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm
7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to
Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2
+KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H
Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C
OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q
6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2
kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa
9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth
qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt
SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8
W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG
u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU
n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW
sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU
YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj
l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31
7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ
6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J
/DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L
/hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E
UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM
r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU
4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI
NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3
Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC
ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa
xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ
hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60
I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd
XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6
10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn
9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY
vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph
201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq
hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM
xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe
3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8
THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl
bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft
FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI
QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT
ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr
XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt
/Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM
Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4
k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN
T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL
Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS
zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J
Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp
FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo
Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r
N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1
pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T
QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H
fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z
b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf
Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF
eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x
Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z
ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U
Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i
4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z
awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp
4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B
zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/
h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16
L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br
mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A
a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A
7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH
+KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/
AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh
caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX
Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7
eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3
8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8
bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq
VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL
Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW
0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf
jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY
y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97
fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB
zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd
wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif
pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w
tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi
y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh
AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq
JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ
Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG
VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP
F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM
7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir
qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs
AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ
xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur
vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX
YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU
UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q==

--Apple-Mail=_D6AE22B4-627E-4EEE-BE17-F9F97BE9CF2E
Content-Transfer-Encoding: base64
Content-Disposition: inline;
	filename=green.gif
Content-Type: image/gif;
	name="green.gif"
Content-Id: 

R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf
bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7

--Apple-Mail=_D6AE22B4-627E-4EEE-BE17-F9F97BE9CF2E--

--Apple-Mail=_5AB648E7-8C2B-409E-A6DB-60EB57BF4DA9--

From ve7jtb@ve7jtb.com  Wed Apr 25 13:07: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 7C8E521F88FA for ; Wed, 25 Apr 2012 13:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.453
X-Spam-Level: 
X-Spam-Status: No, score=-3.453 tagged_above=-999 required=5 tests=[AWL=0.012,  BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s3LmA7G36vf for ; Wed, 25 Apr 2012 13:07:56 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 749D021F88E6 for ; Wed, 25 Apr 2012 13:07:56 -0700 (PDT)
Received: by yenm5 with SMTP id m5so534133yen.31 for ; Wed, 25 Apr 2012 13:07:56 -0700 (PDT)
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=28XOA1nzkkduBdAcK8VeDTVeW6iRUeMtJRCo8hLIbEc=; b=UBKz/SIpwyr8Rz60wkqoijc9qqntYoZUsjBhPEvGQHCDsdig7eYFhGck/munrkXw+V KWcPHEDAgEgMbYyD11EEe/SsLtOONCbY3Lj/2bmLqzyHY+PJGAXkc+i4fXEQBCenIxdl JaRI6Bq2DvM/K0pZTIP/bYvylFXWChdJKRrXWDi19i6eVkppyaQ5sW6Gi6plSVj4WVzj rYvxEkIMTZY5nktlP+Ut3g9xyCHor3Q6+uUqsrQAuRquJhJ1X5rkfjsC2yi9r26rRXX8 NpshmjYf4PCC8DuYhJn+CVzu/q3xy1c+j26nIZLyujUz6AIiFZ/42aRWUwPPgv8I0GJ4 38eg==
Received: by 10.236.9.36 with SMTP id 24mr3762197yhs.19.1335384475883; Wed, 25 Apr 2012 13:07:55 -0700 (PDT)
Received: from [192.168.1.213] (190-20-63-108.baf.movistar.cl. [190.20.63.108]) by mx.google.com with ESMTPS id r13sm531027anm.20.2012.04.25.13.07.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 13:07:53 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_454A3414-69FF-4A17-A310-0D23AF72C337"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20100AEA2@P3PWEX2MB008.ex2.secureserver.net>
Date: Wed, 25 Apr 2012 17:07:44 -0300
Message-Id: <1699AC2D-56DD-44F1-BA51-5E01CCA43E26@ve7jtb.com>
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201007020@P3PWEX2MB008.ex2.secureserver.net> <515663DA-67BF-4367-9AD9-6E940424CBCD@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20100990A@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA201009E4D@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA20100AEA2@P3PWEX2MB008.ex2.secureserver.net>
To: Eran Hammer 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQnCkYr+Ov3IrXYh2pEWtCtwe3Oe1F9CT5fZMcTekpgwZ7aToQcTLnVeBww3mokV7jiYFh/h
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 20:07:58 -0000

--Apple-Mail=_454A3414-69FF-4A17-A310-0D23AF72C337
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

So the merged output if there is one in the host-meta and one in the =
resource JRD is more like:
"links" :
{
      "rel" : "http://openid.net/specs/connect/issuer",
      "template" : "https://server.example.com"
    },
{
      "rel" : "http://openid.net/specs/connect/issuer",
      "href" : "https://server.example.com"
    }
}

Is that correct?

John B.

On 2012-04-25, at 4:42 PM, Eran Hammer wrote:

>=20
>=20
>> -----Original Message-----
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>> Sent: Wednesday, April 25, 2012 12:00 PM
>> To: Eran Hammer
>> Cc: Paul E. Jones; apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>=20
>> OK so host-meta is one level of lrdd link processing for a resource =
(not host).
>>=20
>> Multiple lrdd links are not precluded, but are an abuse.
>>=20
>> If you want to redirect to an alternate host-meta location you use =
3xx and
>> the client will follow.
>> (I heard some complaining about what if my site can't support =
redirects
>> earlier.)
>>=20
>> The links are aggregated with host-meta links and filtered by "rel".
>>=20
>> So if in host-meta I have:
>> {
>>       "rel" : "http://openid.net/specs/connect/issuer",
>>       "href" : "https://server.example.com"
>>     }
>>=20
>> before my lrdd entry
>=20
> Only if you change 'href' above to 'template'. 'href' are host-wide =
only and do not apply to resource-specific.
>=20
> If you make a host-wide request, lrdd links and all templates are =
ignored.
> If you make a resource-specific request, all href links in host-meta =
are ignored, templates expanded, and lrdd templates followed and =
included inline.
>=20
> EH
>=20
>> That would be returned in the filtered list before any resource =
specific "rel" ?
>>=20
>> Thus making a global setting for all resources.
>>=20
>> I don't think the original Connect proposal had per user discovery =
only per
>> host via host meta without following lrdd.
>>=20
>> If aggrigating and sorting links are a requirement, that needs to be =
done
>> server side for Connect clients.
>>=20
>> John B.
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 2012-04-25, at 3:29 PM, Eran Hammer wrote:
>>=20
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>> Sent: Wednesday, April 25, 2012 10:38 AM
>>>> To: Eran Hammer
>>>> Cc: Paul E. Jones; apps-discuss@ietf.org
>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>>=20
>>>> Eran,
>>>>=20
>>>> It was unclear, at least to me that the server side host-meta =
processing
>> rule
>>>> specified in WF requires all the templates (or just the LRDD ones) =
to be
>>>> processed substituting inserting "resource" for URI and then =
retrieving
>> and
>>>> merging all the resource JRD before processing the filter on the =
"rel".
>>>>=20
>>>> If I defined a rel of FOO would WF fill the template and retrieve =
the JRD
>> and
>>>> merge its links with the lrdd JRD?
>>>> I might think that would be a touch confusing to clients.
>>>=20
>>> No. It only does *one* level of LRDD import (in order). See:
>>>=20
>>> http://tools.ietf.org/html/rfc6415#section-4.2
>>>=20
>>>> So I go back to the rational explanation that lrdd templates are =
expanded
>> and
>>>> those links rolled up and filtered.
>>>>=20
>>>> Now I am guessing that some of the SWD people are thinking that =
when
>> the
>>>> server is using flat files that puts a lot of burden onto the =
client.
>>>>=20
>>>> Probably why you added the server side processing.
>>>=20
>>> The idea of adding server-side processing and filtering via the =
query came
>> out of the original OpenID Connect proposal that David Recordon and I
>> wrote, trying to keep the clients super simple and avoid the need to =
go fetch
>> host-meta, then one or more LRDD documents.
>>>=20
>>> Complexity is very much implementation specific on the server side. =
Yahoo
>> doesn't have LRDD documents and puts everything as link templates in =
host-
>> meta while others like the ability to customize. The most likely =
scenario of
>> servers including LRDD links in host-meta is that the host-meta =
document is
>> static, while the LRDD links are dynamically generated. Otherwise, =
there is
>> very little value in the added complexity. In that case, the client =
will typically
>> be faced with 2 requests.
>>>=20
>>> I would argue that a server using multiple LRDD links in host-meta =
is abusing
>> the system, very much like a server using multiple 3xx redirections =
between
>> its initial host-meta endpoint to where the document actually lives.
>>>=20
>>> IOW, there are many ways to inflict pain on the client.
>>>=20
>>>> Given that WF takes the liberty of adding query parameters to =
host-meta
>>>> and seems to define host-meta processing rules (perhaps for non =
lrdd?), I
>>>> am not finding the separation of the two specs as clean as =
possible.
>>>> It seems a bit like there is there a RFC 6415 dependency on WF.  =
Though
>> that
>>>> is a touch strange for a RFC.
>>>=20
>>> The WF draft should not introduce any new processing rules. It =
should only
>> add the query optimization but that must result in exactly the same =
set of
>> links as defined by 6415. If this is the case, it's a bug.
>>>=20
>>>> What stops someone from defining a relation of super-discovery and
>> adding
>>>> some query parameters to host-meta.json to hover up some lrdd based
>> on a
>>>> template expansion of  "super-discovery" rel types, and filter on =
"rel"?
>>>>=20
>>>> I wouldn't have thought to do that because stepping on the RFC 6415
>>>> endpoint seems slightly wrong to me.
>>>>=20
>>>> I would probably define a new endpoint /.well-known/super-discovery
>> with
>>>> my own query parameters and processing rules for JRD documents.
>>>=20
>>> That would be the right approach. Note that 6415 registers both =
host-meta
>> (defaults to XML) and host-meta.json (JSON required).
>>>=20
>>>> Without being able to make server-side processing of host-meta
>> required,
>>>> we need someway to delegate that to another endpoint.
>>>>=20
>>>> In XRD we did discuss delegating the entire XRD.  Is there a way to =
do that
>> in
>>>> host-meta?
>>>=20
>>> 3xx.
>>>=20
>>> EH
>>>=20
>>>> At the moment all of the processing gets pushed back on the client =
if the
>>>> host only supports static files in /.well-known
>>>>=20
>>>> John B.
>>>>=20
>>>>=20
>>>>=20
>>>> On 2012-04-25, at 1:34 PM, Eran Hammer wrote:
>>>>=20
>>>>> It is important to understand the semantics of host-meta, which I =
think
>>>> there is some confusion about here.
>>>>>=20
>>>>> As a mechanism, host-meta providers you with a method of obtaining
>> both
>>>> host-wide and resource-specific links (and properties). To =
accomplish
>> that, it
>>>> provides with both a document and processing rules.
>>>>>=20
>>>>> WebFinger - the name given for the host-meta *use-case* of =
retrieving
>>>> user information - is a specialization of obtaining =
resource-specific links.
>>>>>=20
>>>>> The 'rel' and 'resource' query parameters (as proposed) apply to =
the
>>>> endpoint *after* executing the processing rules (which include =
expanding
>>>> templates and importing links from one level LRDD documents).
>>>>>=20
>>>>> LRDD documents only apply to resource-specific links, which means =
they
>>>> are ignored for any host-wide query. For example, the location of =
the
>> site's
>>>> TOS document. =46rom the host-meta perspective, LRDD documents are
>> just a
>>>> deployment tool to provide customization not possible using just =
link
>>>> templates at the host-meta document level. It's just a link-include
>>>> mechanism, and host-meta uses it restrictively.
>>>>>=20
>>>>> IMO, the 'rel' and 'resource' optimization should only apply to =
the host-
>>>> meta endpoint, and act as a filter post the processing rules. If =
'resource' is
>>>> specified, it is a resource-specific request, otherwise, host-wide.
>>>>>=20
>>>>> Let me know if this helps or if it is still unclear.
>>>>>=20
>>>>> EH
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>>>> Sent: Wednesday, April 25, 2012 8:27 AM
>>>>>> To: Eran Hammer
>>>>>> Cc: Paul E. Jones; apps-discuss@ietf.org
>>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>>>>=20
>>>>>> That was one thing that initially confused me.  The rel filter is =
not
>> applied
>>>> to
>>>>>> host-meta, but rather the linked lrdd resource JRD.
>>>>>>=20
>>>>>> The currently defined "resource" parameter has an implicit =
host-meta
>>>> "rel"
>>>>>> of "lrdd".
>>>>>>=20
>>>>>> To use this mechanism for other relations you would need to make =
that
>>>>>> parameter explicit.
>>>>>>=20
>>>>>> That then raises the question of the filter being part of =
host-meta or
>> WF if
>>>> it
>>>>>> applies to relationships other than lrdd.
>>>>>>=20
>>>>>> If you are asking if filtering should be supported by lrdd where =
you start
>>>>>> discovery from a link header, then it probably should be possible =
as
>> well.
>>>>>>=20
>>>>>> Though I thought lrdd stopped being updated over a year a year =
ago.
>>>> Sorry if
>>>>>> I am out of date.
>>>>>>=20
>>>>>> So XRD/JRD documents SHOULD be filterable by "rel" independent of =
if
>>>> you
>>>>>> get to them via lrdd or host-meta.
>>>>>>=20
>>>>>> Host-meta SHOULD support a mechanism to filter by "rel" or filter =
by a
>>>>>> combination of "resource" (uri) , host-meta-rel and resource-rel =
(the
>>>> host-
>>>>>> meta-rel is currently implicit.)
>>>>>>=20
>>>>>> I recall discussing this in the XRI TC when we did XRD years ago, =
though
>>>> that
>>>>>> was more around using XRI identifiers.
>>>>>>=20
>>>>>> The same principal still holds.  I should be able to ask for.
>>>>>> GET /.well-known/host-meta.json
>>>>>>   ?resource=3Djoe@example.com
>>>>>>   &host-meta-rel=3Dlrdd
>>>>>>=20
>>>> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>>>>>> HTTP/1.1
>>>>>> Host: example.com
>>>>>>=20
>>>>>> (personally I think calling the parameter "resource" and the =
template
>> {uri}
>>>>>> will be confusing to people)
>>>>>>=20
>>>>>> In SWD we used fixed the parameter names and the base URI is the
>> part
>>>> that
>>>>>> gets changed when the /.well-known can't host a script.
>>>>>> That makes the template simpler for the client to process.  The
>> equivalent
>>>> to
>>>>>> "rel" is always passed to make processing simpler.
>>>>>>=20
>>>>>> As Blaine has pointed out several times SWD and WF largely get us =
to
>> the
>>>>>> same place.
>>>>>>=20
>>>>>> I am trying to find a way to close the gap.
>>>>>>=20
>>>>>> John B.
>>>>>>=20
>>>>>>=20
>>>>>> On 2012-04-25, at 11:41 AM, Eran Hammer wrote:
>>>>>>=20
>>>>>>> Purely from a practical standpoint, do you think it is likely =
that a server
>>>> will
>>>>>> support the query filter for the lrdd documents but not for =
host-meta?
>>>>>>>=20
>>>>>>> EH
>>>>>>>=20
>>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>>>>>> bounces@ietf.org] On Behalf Of John Bradley
>>>>>>> Sent: Wednesday, April 25, 2012 6:17 AM
>>>>>>> To: Paul E. Jones
>>>>>>> Cc: apps-discuss@ietf.org
>>>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>>>>>=20
>>>>>>> Paul,
>>>>>>>=20
>>>>>>> "rel" as a filter is something WF has for host-meta.  It however =
doesn't
>>>>>> seem to have that for user JRD in the case where host-meta is
>> returned,
>>>> and
>>>>>> the template is used.
>>>>>>>=20
>>>>>>> The "resource" and "rel" parameters are already an optimization =
for
>>>> LRDD
>>>>>> and not part of host-meta.
>>>>>>> Adding LRDD specific parameters to host-meta/host-meta.json will
>>>>>> probably raise some eyebrows in review, but I am OK with it.
>>>>>>>=20
>>>>>>> I think there are use cases where size matters.  Where a =
host-meta or
>>>>>> resource JRD may be large and it is more efficient not to send =
the
>> whole
>>>>>> thing to a mobile client.
>>>>>>> It seems to be one of Mike Jones requirements.
>>>>>>>=20
>>>>>>> Using RFC6570 for LRDD is a possibility for passing through the =
filter
>>>> request
>>>>>> for sites that support filtering on resource JRD.
>>>>>>>=20
>>>>>>> What other proposals do you have.  I am guessing that filtering =
on
>>>> resource
>>>>>> JRD is not a totally new topic.
>>>>>>>=20
>>>>>>> LRDD is the one really doing the optimization  in any event,  it =
may be
>>>> done
>>>>>> at the host-meta GET but it is a LRDD specific extension.
>>>>>>> Having it in the template allows LRDD to filter at the resource =
JRD in
>>>> cases
>>>>>> where it is not possible to do it at the host-meta level, due to =
some no
>>>> script
>>>>>> or other restriction.
>>>>>>>=20
>>>>>>> I agree that it should be filtered at the how-meta request but =
you and
>>>>>> others say that is not always possible.
>>>>>>>=20
>>>>>>> John B.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>> John,
>>>>>>>=20
>>>>>>> The "rel" parameter is something we still need to discuss, so =
not is as
>>>> good
>>>>>> a time as any.
>>>>>>>=20
>>>>>>> What "rel" does is act as a filter.  For the most part, the only =
purpose it
>>>>>> serves is to help reduce the number of link relations that might =
be sent
>>>> from
>>>>>> the server.  So, if a user had 1,000 different link relations, =
this might
>>>> reduce
>>>>>> the returned message to containing only 1.  However, if a user =
has
>> more
>>>> than
>>>>>> one link relation of the same type, all of them would match and =
be
>>>> returned.
>>>>>>>=20
>>>>>>> When you say the host cannot support re-write rules, I assume =
you
>>>> mean it
>>>>>> does not support the URI parameters on host-meta?  In that case, =
yes,
>>>> the
>>>>>> parameters are ignored and you get just the host-meta document.
>>>>>>>=20
>>>>>>> The only URI template defined in RFC 6415 is "{uri}" (see =
3.1.1.1).
>> There
>>>> are
>>>>>> no other URI template values defined.  (Note: this whole section =
exists
>>>> only
>>>>>> because RFC  6570 did not yet exist, I think.
>>>>>>>=20
>>>>>>> In any case, we could define a new URI template, but then we =
would
>> be
>>>>>> putting an optimization in place for LRDD.  If host-meta is not =
going to
>>>>>> support the "rel" URI parameter, why would LRDD?  It would also =
mean
>>>> that
>>>>>> the LRDD logic would have to be ready to receive a URI parameter =
that
>> is
>>>> not
>>>>>> replaced, since some clients would only change {uri} and leave =
{rel}
>> there.
>>>>>> That would introduce more conditional logic in the server.  This =
would
>> also
>>>>>> present issues with static sites.  (Of course, one might be able =
to use
>>>> Apache
>>>>>> re-writing rules to get around that problem, but it certainly =
would not
>>>> work
>>>>>> for "real" static sites.)
>>>>>>>=20
>>>>>>> Personally,  I'd prefer to not add the "rel" parameter to LRDD, =
since I
>>>> think
>>>>>> optimization using "rel" would always be done on host-meta.  That =
said,
>> I
>>>>>> question the value of "rel" entirely.  Do you think it's useful =
to have this
>>>> filter
>>>>>> at all?  Is there really a risk that a site might return 1,000 =
link relations
>> that
>>>> the
>>>>>> client would have to step over?
>>>>>>>=20
>>>>>>> Paul
>>>>>>>=20
>>>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>>>>> Sent: Tuesday, April 24, 2012 10:17 PM
>>>>>>> To: Paul E. Jones
>>>>>>> Cc: apps-discuss@ietf.org
>>>>>>> Subject: WF flow with rel parameter
>>>>>>>=20
>>>>>>> Paul,
>>>>>>>=20
>>>>>>> Sorry I hit send on the previous message with a typo.
>>>>>>>=20
>>>>>>> I am looking at how the flows in WF might work for openID.
>>>>>>>=20
>>>>>>> Let's set aside the XML issue for the moment and focus on the =
JSON
>>>> flow.
>>>>>>>=20
>>>>>>> Please correct anything I get wrong.
>>>>>>>=20
>>>>>>> The openID Connect defines a relation of
>>>>>> http://openid.net/specs/connect/issuer
>>>>>>>=20
>>>>>>> WF allows for a JSON host-meta that takes two parameters,
>> "resource"
>>>> and
>>>>>> "rel"
>>>>>>>=20
>>>>>>> An example request and response (line-brakes for readability)
>>>>>>>=20
>>>>>>> GET /.well-known/host-meta.json
>>>>>>>   ?resource=3Djoe@example.com
>>>>>>>=20
>>>> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>>>>>> HTTP/1.1
>>>>>>> Host: example.com
>>>>>>>=20
>>>>>>> HTTP/1.1 200 OK
>>>>>>>=20
>>>>>>> Access-Control-Allow-Origin: *
>>>>>>> Content-Type: application/json; charset=3DUTF-8
>>>>>>>=20
>>>>>>> {
>>>>>>>   "subject" : "joe@example.com",
>>>>>>>   "links" :
>>>>>>>   [
>>>>>>>     {
>>>>>>>       "rel" : "http://openid.net/specs/connect/issuer",
>>>>>>>       "href" : "https://server.example.com"
>>>>>>>     }
>>>>>>>   ]
>>>>>>> }
>>>>>>>=20
>>>>>>> If the host can't support rewrite rules or scripts the exchange =
would
>> look
>>>>>> like:
>>>>>>>=20
>>>>>>> GET /.well-known/host-meta.json
>>>>>>>   ?resource=3Djoe@example.com
>>>>>>>=20
>>>> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>>>>>> HTTP/1.1
>>>>>>> Host: example.com
>>>>>>>=20
>>>>>>> HTTP/1.1 200 OK
>>>>>>> Access-Control-Allow-Origin: *
>>>>>>> Content-Type: application/json; charset=3DUTF-8
>>>>>>> {
>>>>>>>   "expires" : "2012-03-13T20:56:11Z",
>>>>>>>   "links" :
>>>>>>>   [
>>>>>>>     {
>>>>>>>       "rel" : "lrdd",
>>>>>>>       "type" : "application/json",
>>>>>>>       "template" :
>>>>>>>         "https://example.com/lrdd/?format=3Djson&resource=3D{uri}"=

>>>>>>>     }
>>>>>>>=20
>>>>>>> GET /lrdd/
>>>>>>>   ?format=3Djson
>>>>>>>   &resource=3Djoe@example.com
>>>>>>> Host: example.com
>>>>>>>=20
>>>>>>> HTTP/1.1 200 OK
>>>>>>>=20
>>>>>>> Access-Control-Allow-Origin: *
>>>>>>> Content-Type: application/json; charset=3DUTF-8
>>>>>>>=20
>>>>>>> {
>>>>>>>   "subject" : "joe@example.com",
>>>>>>>   "links" :
>>>>>>>   [
>>>>>>>     {
>>>>>>>       "rel" : "http://openid.net/specs/connect/issuer",
>>>>>>>       "href" : "https://server.example.com"
>>>>>>>     },
>>>>>>>     {
>>>>>>>       "rel" : "http://webfinger.net/rel/avatar",
>>>>>>>       "href" : "http://example.com/~joe/joe.jpg"
>>>>>>>     }
>>>>>>>=20
>>>>>>>   ]
>>>>>>> }
>>>>>>>=20
>>>>>>> I can't find a template parameter for "rel".  The host-meta spec =
allows
>>>> for
>>>>>> extension but it is missing.
>>>>>>>=20
>>>>>>> What if the server wants to support filtering on rel but can't =
support it
>> in
>>>>>> the root for some reason?
>>>>>>>=20
>>>>>>> Is it possible to have a template like:
>>>>>>> "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{r=
el}"
>>>>>>>=20
>>>>>>> That simple addition may solve a number of problems for openID.
>>>>>>>=20
>>>>>>> John B.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>=20
>>>=20
>=20


--Apple-Mail=_454A3414-69FF-4A17-A310-0D23AF72C337
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
NTIwMDc0NVowIwYJKoZIhvcNAQkEMRYEFJ5KhvOMqau+AeJHX/RHWMo3/brDMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AJBYwAXRKJBaHYlecSTNpXnG5lKpsRFDAZSVYVwKJy8sLlOthnc0WEaKE2Au7E3e7M0sufy6gJAj
l5cgptJMPK0trGcqX8g4oUIRAdVRAqHeN3JZU7Ublrt2T0wLnbovaGuWE7QS5+2D5diDe9qXeP2+
ZbFDcv6WiwmQ3BiGQh1ncYmrW6F42BKDEJ6MaysMypZonMb0CzVWSOY+hX1NZD+R4w9UJO6VQ7Rl
dcQ9fWFay7nWzZWUIxDbFKwjVc5uUIZBlGkabffUlu3ATUPL8LEF60Pn5Qy9GaBoFNoIKzsKpKTa
Nctt8afltNIfwLLCDsergbItDtUP5BBItyAudeAAAAAAAAA=

--Apple-Mail=_454A3414-69FF-4A17-A310-0D23AF72C337--

From julian.reschke@gmx.de  Wed Apr 25 13:36: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 39D8321F884D for ; Wed, 25 Apr 2012 13:36:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level: 
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G+sdCmKE2En for ; Wed, 25 Apr 2012 13:36:25 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B95CE21F87A9 for ; Wed, 25 Apr 2012 13:36:20 -0700 (PDT)
Received: (qmail invoked by alias); 25 Apr 2012 20:36:19 -0000
Received: from 178-83-198-62.dynamic.hispeed.ch (EHLO [192.168.1.103]) [178.83.198.62] by mail.gmx.net (mp016) with SMTP; 25 Apr 2012 22:36:19 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18opX4APmsoVagPK+RuwPke+/PNH7ig7B6ha4leyE 7KJzgdFW44Bw43
Message-ID: <4F986041.5060909@gmx.de>
Date: Wed, 25 Apr 2012 22:36:17 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
To: Tim Bray 
References:  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: Barry Leiba , apps-discuss@ietf.org
Subject: Re: [apps-discuss] On citations in general
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 20:36:27 -0000

On 2012-04-25 17:23, Tim Bray wrote:
> If only there were a technology which allowed citations to be made
> actual actionable usable links directly to the targeted source. A text
> with this sort of thing would be so great that we’d need a new name
> for it... supertext? ultratext? hypertext?
>
>   -T

xml2rfc source + extensions formatted through rfc2629.xslt?


From eran@hueniverse.com  Wed Apr 25 14:11: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 B49EA21F8754 for ; Wed, 25 Apr 2012 14:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Level: 
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy9J5eZRxZ1f for ; Wed, 25 Apr 2012 14:11:42 -0700 (PDT)
Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6780221F865F for ; Wed, 25 Apr 2012 14:11:41 -0700 (PDT)
Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id 2MBg1j0060EuLVk01MBgWF; Wed, 25 Apr 2012 14:11:40 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Wed, 25 Apr 2012 14:11:40 -0700
From: Eran Hammer 
To: John Bradley 
Thread-Topic: [apps-discuss] WF flow with rel parameter
Thread-Index: AQHNIomKaCym1aAtdUm4KjKnInrNO5ard+qAgACDoID//6IRMIAAgkAA//+ZoSCAAIr5AP//lX+QABAztYAADUhqUP//qJcAgABmnVA=
Date: Wed, 25 Apr 2012 21:11:39 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20100B18C@P3PWEX2MB008.ex2.secureserver.net>
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201007020@P3PWEX2MB008.ex2.secureserver.net> <515663DA-67BF-4367-9AD9-6E940424CBCD@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20100990A@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA201009E4D@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA20100AEA2@P3PWEX2MB008.ex2.secureserver.net> <1699AC2D-56DD-44F1-BA51-5E01CCA43E26@ve7jtb.com>
In-Reply-To: <1699AC2D-56DD-44F1-BA51-5E01CCA43E26@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 21:11:43 -0000

If your host-meta is:

{
  "links":[
    {
      "rel":"example",
      "href":"http://example.com/1"
    },
    {
      "rel":"lrdd",
      "template":"http://example.com/lrdd?resource=3D{uri}"
    },
    {
      "rel":"example",
      "template":"http://example.com/2"
    }
  ]
}

And your LRDD document always return:

{
  "links":[
    {
      "rel":"example",
      "template":"http://example.com/3"
    }
  ]
}

Then a host-wide request:

GET /.well-known/host-meta.json?rel=3Dexample

Will return (I haven't checked the exact format of the latest draft so the =
syntax might be wrong here):

{
  "links":[
    {
      "rel":"example",
      "href":"http://example.com/1"
    }
  ]
}

And a resource-specific request (not escaped for readability):

GET /.well-known/host-meta.json?resource=3Dhttp://example.com/resource

Will return:

{
  "links":[
    {
      "rel":"example",
      "href":"http://example.com/1"
    },
    {
      "rel":"example",
      "href":"http://example.com/2"
    }
  ]
}

Does this help?

EH

> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Wednesday, April 25, 2012 1:08 PM
> To: Eran Hammer
> Cc: Paul E. Jones; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] WF flow with rel parameter
>=20
> So the merged output if there is one in the host-meta and one in the
> resource JRD is more like:
> "links" :
> {
>       "rel" : "http://openid.net/specs/connect/issuer",
>       "template" : "https://server.example.com"
>     },
> {
>       "rel" : "http://openid.net/specs/connect/issuer",
>       "href" : "https://server.example.com"
>     }
> }
>=20
> Is that correct?
>=20
> John B.
>=20
> On 2012-04-25, at 4:42 PM, Eran Hammer wrote:
>=20
> >
> >
> >> -----Original Message-----
> >> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >> Sent: Wednesday, April 25, 2012 12:00 PM
> >> To: Eran Hammer
> >> Cc: Paul E. Jones; apps-discuss@ietf.org
> >> Subject: Re: [apps-discuss] WF flow with rel parameter
> >>
> >> OK so host-meta is one level of lrdd link processing for a resource (n=
ot
> host).
> >>
> >> Multiple lrdd links are not precluded, but are an abuse.
> >>
> >> If you want to redirect to an alternate host-meta location you use 3xx=
 and
> >> the client will follow.
> >> (I heard some complaining about what if my site can't support redirect=
s
> >> earlier.)
> >>
> >> The links are aggregated with host-meta links and filtered by "rel".
> >>
> >> So if in host-meta I have:
> >> {
> >>       "rel" : "http://openid.net/specs/connect/issuer",
> >>       "href" : "https://server.example.com"
> >>     }
> >>
> >> before my lrdd entry
> >
> > Only if you change 'href' above to 'template'. 'href' are host-wide onl=
y and
> do not apply to resource-specific.
> >
> > If you make a host-wide request, lrdd links and all templates are ignor=
ed.
> > If you make a resource-specific request, all href links in host-meta ar=
e
> ignored, templates expanded, and lrdd templates followed and included
> inline.
> >
> > EH
> >
> >> That would be returned in the filtered list before any resource specif=
ic
> "rel" ?
> >>
> >> Thus making a global setting for all resources.
> >>
> >> I don't think the original Connect proposal had per user discovery onl=
y per
> >> host via host meta without following lrdd.
> >>
> >> If aggrigating and sorting links are a requirement, that needs to be d=
one
> >> server side for Connect clients.
> >>
> >> John B.
> >>
> >>
> >>
> >>
> >>
> >> On 2012-04-25, at 3:29 PM, Eran Hammer wrote:
> >>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >>>> Sent: Wednesday, April 25, 2012 10:38 AM
> >>>> To: Eran Hammer
> >>>> Cc: Paul E. Jones; apps-discuss@ietf.org
> >>>> Subject: Re: [apps-discuss] WF flow with rel parameter
> >>>>
> >>>> Eran,
> >>>>
> >>>> It was unclear, at least to me that the server side host-meta proces=
sing
> >> rule
> >>>> specified in WF requires all the templates (or just the LRDD ones) t=
o be
> >>>> processed substituting inserting "resource" for URI and then retriev=
ing
> >> and
> >>>> merging all the resource JRD before processing the filter on the "re=
l".
> >>>>
> >>>> If I defined a rel of FOO would WF fill the template and retrieve th=
e JRD
> >> and
> >>>> merge its links with the lrdd JRD?
> >>>> I might think that would be a touch confusing to clients.
> >>>
> >>> No. It only does *one* level of LRDD import (in order). See:
> >>>
> >>> http://tools.ietf.org/html/rfc6415#section-4.2
> >>>
> >>>> So I go back to the rational explanation that lrdd templates are
> expanded
> >> and
> >>>> those links rolled up and filtered.
> >>>>
> >>>> Now I am guessing that some of the SWD people are thinking that
> when
> >> the
> >>>> server is using flat files that puts a lot of burden onto the client=
.
> >>>>
> >>>> Probably why you added the server side processing.
> >>>
> >>> The idea of adding server-side processing and filtering via the query
> came
> >> out of the original OpenID Connect proposal that David Recordon and I
> >> wrote, trying to keep the clients super simple and avoid the need to g=
o
> fetch
> >> host-meta, then one or more LRDD documents.
> >>>
> >>> Complexity is very much implementation specific on the server side.
> Yahoo
> >> doesn't have LRDD documents and puts everything as link templates in
> host-
> >> meta while others like the ability to customize. The most likely scena=
rio of
> >> servers including LRDD links in host-meta is that the host-meta docume=
nt
> is
> >> static, while the LRDD links are dynamically generated. Otherwise, the=
re is
> >> very little value in the added complexity. In that case, the client wi=
ll
> typically
> >> be faced with 2 requests.
> >>>
> >>> I would argue that a server using multiple LRDD links in host-meta is
> abusing
> >> the system, very much like a server using multiple 3xx redirections
> between
> >> its initial host-meta endpoint to where the document actually lives.
> >>>
> >>> IOW, there are many ways to inflict pain on the client.
> >>>
> >>>> Given that WF takes the liberty of adding query parameters to host-
> meta
> >>>> and seems to define host-meta processing rules (perhaps for non
> lrdd?), I
> >>>> am not finding the separation of the two specs as clean as possible.
> >>>> It seems a bit like there is there a RFC 6415 dependency on WF.
> Though
> >> that
> >>>> is a touch strange for a RFC.
> >>>
> >>> The WF draft should not introduce any new processing rules. It should
> only
> >> add the query optimization but that must result in exactly the same se=
t of
> >> links as defined by 6415. If this is the case, it's a bug.
> >>>
> >>>> What stops someone from defining a relation of super-discovery and
> >> adding
> >>>> some query parameters to host-meta.json to hover up some lrdd
> based
> >> on a
> >>>> template expansion of  "super-discovery" rel types, and filter on "r=
el"?
> >>>>
> >>>> I wouldn't have thought to do that because stepping on the RFC 6415
> >>>> endpoint seems slightly wrong to me.
> >>>>
> >>>> I would probably define a new endpoint /.well-known/super-discovery
> >> with
> >>>> my own query parameters and processing rules for JRD documents.
> >>>
> >>> That would be the right approach. Note that 6415 registers both host-
> meta
> >> (defaults to XML) and host-meta.json (JSON required).
> >>>
> >>>> Without being able to make server-side processing of host-meta
> >> required,
> >>>> we need someway to delegate that to another endpoint.
> >>>>
> >>>> In XRD we did discuss delegating the entire XRD.  Is there a way to =
do
> that
> >> in
> >>>> host-meta?
> >>>
> >>> 3xx.
> >>>
> >>> EH
> >>>
> >>>> At the moment all of the processing gets pushed back on the client i=
f
> the
> >>>> host only supports static files in /.well-known
> >>>>
> >>>> John B.
> >>>>
> >>>>
> >>>>
> >>>> On 2012-04-25, at 1:34 PM, Eran Hammer wrote:
> >>>>
> >>>>> It is important to understand the semantics of host-meta, which I
> think
> >>>> there is some confusion about here.
> >>>>>
> >>>>> As a mechanism, host-meta providers you with a method of obtaining
> >> both
> >>>> host-wide and resource-specific links (and properties). To accomplis=
h
> >> that, it
> >>>> provides with both a document and processing rules.
> >>>>>
> >>>>> WebFinger - the name given for the host-meta *use-case* of
> retrieving
> >>>> user information - is a specialization of obtaining resource-specifi=
c links.
> >>>>>
> >>>>> The 'rel' and 'resource' query parameters (as proposed) apply to th=
e
> >>>> endpoint *after* executing the processing rules (which include
> expanding
> >>>> templates and importing links from one level LRDD documents).
> >>>>>
> >>>>> LRDD documents only apply to resource-specific links, which means
> they
> >>>> are ignored for any host-wide query. For example, the location of th=
e
> >> site's
> >>>> TOS document. From the host-meta perspective, LRDD documents are
> >> just a
> >>>> deployment tool to provide customization not possible using just lin=
k
> >>>> templates at the host-meta document level. It's just a link-include
> >>>> mechanism, and host-meta uses it restrictively.
> >>>>>
> >>>>> IMO, the 'rel' and 'resource' optimization should only apply to the
> host-
> >>>> meta endpoint, and act as a filter post the processing rules. If 're=
source'
> is
> >>>> specified, it is a resource-specific request, otherwise, host-wide.
> >>>>>
> >>>>> Let me know if this helps or if it is still unclear.
> >>>>>
> >>>>> EH
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >>>>>> Sent: Wednesday, April 25, 2012 8:27 AM
> >>>>>> To: Eran Hammer
> >>>>>> Cc: Paul E. Jones; apps-discuss@ietf.org
> >>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
> >>>>>>
> >>>>>> That was one thing that initially confused me.  The rel filter is =
not
> >> applied
> >>>> to
> >>>>>> host-meta, but rather the linked lrdd resource JRD.
> >>>>>>
> >>>>>> The currently defined "resource" parameter has an implicit host-
> meta
> >>>> "rel"
> >>>>>> of "lrdd".
> >>>>>>
> >>>>>> To use this mechanism for other relations you would need to make
> that
> >>>>>> parameter explicit.
> >>>>>>
> >>>>>> That then raises the question of the filter being part of host-met=
a or
> >> WF if
> >>>> it
> >>>>>> applies to relationships other than lrdd.
> >>>>>>
> >>>>>> If you are asking if filtering should be supported by lrdd where y=
ou
> start
> >>>>>> discovery from a link header, then it probably should be possible =
as
> >> well.
> >>>>>>
> >>>>>> Though I thought lrdd stopped being updated over a year a year ago=
.
> >>>> Sorry if
> >>>>>> I am out of date.
> >>>>>>
> >>>>>> So XRD/JRD documents SHOULD be filterable by "rel" independent
> of if
> >>>> you
> >>>>>> get to them via lrdd or host-meta.
> >>>>>>
> >>>>>> Host-meta SHOULD support a mechanism to filter by "rel" or filter =
by
> a
> >>>>>> combination of "resource" (uri) , host-meta-rel and resource-rel (=
the
> >>>> host-
> >>>>>> meta-rel is currently implicit.)
> >>>>>>
> >>>>>> I recall discussing this in the XRI TC when we did XRD years ago,
> though
> >>>> that
> >>>>>> was more around using XRI identifiers.
> >>>>>>
> >>>>>> The same principal still holds.  I should be able to ask for.
> >>>>>> GET /.well-known/host-meta.json
> >>>>>>   ?resource=3Djoe@example.com
> >>>>>>   &host-meta-rel=3Dlrdd
> >>>>>>
> >>>>
> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> >>>>>> HTTP/1.1
> >>>>>> Host: example.com
> >>>>>>
> >>>>>> (personally I think calling the parameter "resource" and the templ=
ate
> >> {uri}
> >>>>>> will be confusing to people)
> >>>>>>
> >>>>>> In SWD we used fixed the parameter names and the base URI is the
> >> part
> >>>> that
> >>>>>> gets changed when the /.well-known can't host a script.
> >>>>>> That makes the template simpler for the client to process.  The
> >> equivalent
> >>>> to
> >>>>>> "rel" is always passed to make processing simpler.
> >>>>>>
> >>>>>> As Blaine has pointed out several times SWD and WF largely get us =
to
> >> the
> >>>>>> same place.
> >>>>>>
> >>>>>> I am trying to find a way to close the gap.
> >>>>>>
> >>>>>> John B.
> >>>>>>
> >>>>>>
> >>>>>> On 2012-04-25, at 11:41 AM, Eran Hammer wrote:
> >>>>>>
> >>>>>>> Purely from a practical standpoint, do you think it is likely tha=
t a
> server
> >>>> will
> >>>>>> support the query filter for the lrdd documents but not for host-
> meta?
> >>>>>>>
> >>>>>>> EH
> >>>>>>>
> >>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> >>>>>> bounces@ietf.org] On Behalf Of John Bradley
> >>>>>>> Sent: Wednesday, April 25, 2012 6:17 AM
> >>>>>>> To: Paul E. Jones
> >>>>>>> Cc: apps-discuss@ietf.org
> >>>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
> >>>>>>>
> >>>>>>> Paul,
> >>>>>>>
> >>>>>>> "rel" as a filter is something WF has for host-meta.  It however
> doesn't
> >>>>>> seem to have that for user JRD in the case where host-meta is
> >> returned,
> >>>> and
> >>>>>> the template is used.
> >>>>>>>
> >>>>>>> The "resource" and "rel" parameters are already an optimization
> for
> >>>> LRDD
> >>>>>> and not part of host-meta.
> >>>>>>> Adding LRDD specific parameters to host-meta/host-meta.json will
> >>>>>> probably raise some eyebrows in review, but I am OK with it.
> >>>>>>>
> >>>>>>> I think there are use cases where size matters.  Where a host-met=
a
> or
> >>>>>> resource JRD may be large and it is more efficient not to send the
> >> whole
> >>>>>> thing to a mobile client.
> >>>>>>> It seems to be one of Mike Jones requirements.
> >>>>>>>
> >>>>>>> Using RFC6570 for LRDD is a possibility for passing through the f=
ilter
> >>>> request
> >>>>>> for sites that support filtering on resource JRD.
> >>>>>>>
> >>>>>>> What other proposals do you have.  I am guessing that filtering o=
n
> >>>> resource
> >>>>>> JRD is not a totally new topic.
> >>>>>>>
> >>>>>>> LRDD is the one really doing the optimization  in any event,  it =
may
> be
> >>>> done
> >>>>>> at the host-meta GET but it is a LRDD specific extension.
> >>>>>>> Having it in the template allows LRDD to filter at the resource J=
RD in
> >>>> cases
> >>>>>> where it is not possible to do it at the host-meta level, due to s=
ome
> no
> >>>> script
> >>>>>> or other restriction.
> >>>>>>>
> >>>>>>> I agree that it should be filtered at the how-meta request but yo=
u
> and
> >>>>>> others say that is not always possible.
> >>>>>>>
> >>>>>>> John B.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> John,
> >>>>>>>
> >>>>>>> The "rel" parameter is something we still need to discuss, so not=
 is
> as
> >>>> good
> >>>>>> a time as any.
> >>>>>>>
> >>>>>>> What "rel" does is act as a filter.  For the most part, the only
> purpose it
> >>>>>> serves is to help reduce the number of link relations that might b=
e
> sent
> >>>> from
> >>>>>> the server.  So, if a user had 1,000 different link relations, thi=
s might
> >>>> reduce
> >>>>>> the returned message to containing only 1.  However, if a user has
> >> more
> >>>> than
> >>>>>> one link relation of the same type, all of them would match and be
> >>>> returned.
> >>>>>>>
> >>>>>>> When you say the host cannot support re-write rules, I assume you
> >>>> mean it
> >>>>>> does not support the URI parameters on host-meta?  In that case,
> yes,
> >>>> the
> >>>>>> parameters are ignored and you get just the host-meta document.
> >>>>>>>
> >>>>>>> The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1=
).
> >> There
> >>>> are
> >>>>>> no other URI template values defined.  (Note: this whole section
> exists
> >>>> only
> >>>>>> because RFC  6570 did not yet exist, I think.
> >>>>>>>
> >>>>>>> In any case, we could define a new URI template, but then we
> would
> >> be
> >>>>>> putting an optimization in place for LRDD.  If host-meta is not go=
ing
> to
> >>>>>> support the "rel" URI parameter, why would LRDD?  It would also
> mean
> >>>> that
> >>>>>> the LRDD logic would have to be ready to receive a URI parameter
> that
> >> is
> >>>> not
> >>>>>> replaced, since some clients would only change {uri} and leave {re=
l}
> >> there.
> >>>>>> That would introduce more conditional logic in the server.  This
> would
> >> also
> >>>>>> present issues with static sites.  (Of course, one might be able t=
o use
> >>>> Apache
> >>>>>> re-writing rules to get around that problem, but it certainly woul=
d
> not
> >>>> work
> >>>>>> for "real" static sites.)
> >>>>>>>
> >>>>>>> Personally,  I'd prefer to not add the "rel" parameter to LRDD, s=
ince
> I
> >>>> think
> >>>>>> optimization using "rel" would always be done on host-meta.  That
> said,
> >> I
> >>>>>> question the value of "rel" entirely.  Do you think it's useful to=
 have
> this
> >>>> filter
> >>>>>> at all?  Is there really a risk that a site might return 1,000 lin=
k relations
> >> that
> >>>> the
> >>>>>> client would have to step over?
> >>>>>>>
> >>>>>>> Paul
> >>>>>>>
> >>>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >>>>>>> Sent: Tuesday, April 24, 2012 10:17 PM
> >>>>>>> To: Paul E. Jones
> >>>>>>> Cc: apps-discuss@ietf.org
> >>>>>>> Subject: WF flow with rel parameter
> >>>>>>>
> >>>>>>> Paul,
> >>>>>>>
> >>>>>>> Sorry I hit send on the previous message with a typo.
> >>>>>>>
> >>>>>>> I am looking at how the flows in WF might work for openID.
> >>>>>>>
> >>>>>>> Let's set aside the XML issue for the moment and focus on the
> JSON
> >>>> flow.
> >>>>>>>
> >>>>>>> Please correct anything I get wrong.
> >>>>>>>
> >>>>>>> The openID Connect defines a relation of
> >>>>>> http://openid.net/specs/connect/issuer
> >>>>>>>
> >>>>>>> WF allows for a JSON host-meta that takes two parameters,
> >> "resource"
> >>>> and
> >>>>>> "rel"
> >>>>>>>
> >>>>>>> An example request and response (line-brakes for readability)
> >>>>>>>
> >>>>>>> GET /.well-known/host-meta.json
> >>>>>>>   ?resource=3Djoe@example.com
> >>>>>>>
> >>>>
> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> >>>>>> HTTP/1.1
> >>>>>>> Host: example.com
> >>>>>>>
> >>>>>>> HTTP/1.1 200 OK
> >>>>>>>
> >>>>>>> Access-Control-Allow-Origin: *
> >>>>>>> Content-Type: application/json; charset=3DUTF-8
> >>>>>>>
> >>>>>>> {
> >>>>>>>   "subject" : "joe@example.com",
> >>>>>>>   "links" :
> >>>>>>>   [
> >>>>>>>     {
> >>>>>>>       "rel" : "http://openid.net/specs/connect/issuer",
> >>>>>>>       "href" : "https://server.example.com"
> >>>>>>>     }
> >>>>>>>   ]
> >>>>>>> }
> >>>>>>>
> >>>>>>> If the host can't support rewrite rules or scripts the exchange
> would
> >> look
> >>>>>> like:
> >>>>>>>
> >>>>>>> GET /.well-known/host-meta.json
> >>>>>>>   ?resource=3Djoe@example.com
> >>>>>>>
> >>>>
> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> >>>>>> HTTP/1.1
> >>>>>>> Host: example.com
> >>>>>>>
> >>>>>>> HTTP/1.1 200 OK
> >>>>>>> Access-Control-Allow-Origin: *
> >>>>>>> Content-Type: application/json; charset=3DUTF-8
> >>>>>>> {
> >>>>>>>   "expires" : "2012-03-13T20:56:11Z",
> >>>>>>>   "links" :
> >>>>>>>   [
> >>>>>>>     {
> >>>>>>>       "rel" : "lrdd",
> >>>>>>>       "type" : "application/json",
> >>>>>>>       "template" :
> >>>>>>>         "https://example.com/lrdd/?format=3Djson&resource=3D{uri}=
"
> >>>>>>>     }
> >>>>>>>
> >>>>>>> GET /lrdd/
> >>>>>>>   ?format=3Djson
> >>>>>>>   &resource=3Djoe@example.com
> >>>>>>> Host: example.com
> >>>>>>>
> >>>>>>> HTTP/1.1 200 OK
> >>>>>>>
> >>>>>>> Access-Control-Allow-Origin: *
> >>>>>>> Content-Type: application/json; charset=3DUTF-8
> >>>>>>>
> >>>>>>> {
> >>>>>>>   "subject" : "joe@example.com",
> >>>>>>>   "links" :
> >>>>>>>   [
> >>>>>>>     {
> >>>>>>>       "rel" : "http://openid.net/specs/connect/issuer",
> >>>>>>>       "href" : "https://server.example.com"
> >>>>>>>     },
> >>>>>>>     {
> >>>>>>>       "rel" : "http://webfinger.net/rel/avatar",
> >>>>>>>       "href" : "http://example.com/~joe/joe.jpg"
> >>>>>>>     }
> >>>>>>>
> >>>>>>>   ]
> >>>>>>> }
> >>>>>>>
> >>>>>>> I can't find a template parameter for "rel".  The host-meta spec
> allows
> >>>> for
> >>>>>> extension but it is missing.
> >>>>>>>
> >>>>>>> What if the server wants to support filtering on rel but can't
> support it
> >> in
> >>>>>> the root for some reason?
> >>>>>>>
> >>>>>>> Is it possible to have a template like:
> >>>>>>>
> "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}"
> >>>>>>>
> >>>>>>> That simple addition may solve a number of problems for openID.
> >>>>>>>
> >>>>>>> John B.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >


From romeda@gmail.com  Wed Apr 25 14:45:28 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AAD21E803C for ; Wed, 25 Apr 2012 14:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.524
X-Spam-Level: 
X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRyrMI2685xI for ; Wed, 25 Apr 2012 14:45:27 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 585C421E8037 for ; Wed, 25 Apr 2012 14:45:27 -0700 (PDT)
Received: by lagj5 with SMTP id j5so482258lag.31 for ; Wed, 25 Apr 2012 14:45:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=xbmJLRPvfFBNpF0VjHW70ts3jx2v5oS8nxrINEdpD2E=; b=cd8qEMffBBQgkaf+Z0v5b4upcAk44pDfn3tplYm3Sus8sco4Vh1EWo4/daa9YyhuSL vdI/ulthZWpaaPsnsFF4AMdXANBQpKW2nJ9rRemcBzhBQVnDNHj1MzVbN7CpJ9FZFYSp ExQw0IwRNzW4aDZ5qlTVEQzM58RMaGxaGZ+Mpbk8p6jPptzz0XlOSrB6E9kjgkrdoR9M GPwNiOCLkDaACMKFBrz8vV+oFA0G7Xxu4rIsyJdemf1Cb1y/uk6Y6frQz3XS9aowHcog PFA5sQRmZK7QOgNxi0m/6J4srGBT3CsJDGZTx4qv8fHcwo1JOg6lbd13yOVRgOdAD3lT sJVw==
Received: by 10.112.84.202 with SMTP id b10mr2177372lbz.7.1335390326151; Wed, 25 Apr 2012 14:45:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.24.229 with HTTP; Wed, 25 Apr 2012 14:45:05 -0700 (PDT)
In-Reply-To: <4CC716F1-F6A4-46CF-86FD-6636B1F84500@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com> <054901cd2311$87a24fb0$96e6ef10$@packetizer.com> <4CC716F1-F6A4-46CF-86FD-6636B1F84500@ve7jtb.com>
From: Blaine Cook 
Date: Wed, 25 Apr 2012 22:45:05 +0100
Message-ID: 
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=f46d04016c6d06db9104be87ca45
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 21:45:28 -0000

--f46d04016c6d06db9104be87ca45
Content-Type: text/plain; charset=UTF-8

*sigh*

This is crazy. There are a half-dozen of us debating theoretical ways to
structure a thing that may or may not ever get used, so that some specs can
get finalised so that *maybe* Microsoft and Google can ship a new version
of OpenID (that doesn't adequately address one of the core usability
shortcomings of the first two OpenIDs).

I don't know if Evan Prodromou or anyone from Diaspora or anyone else who
has *actually tried to deploy* similar things is watching this thread, but
if they are, I hope they pipe up, because there is absolutely zero
consideration for actual implementations happening in this discussion.

Also, keep in mind that if *we're* confused about the host-meta processing
rules, or if my "single-code-path" arguments are being dismissed because
"it's easy either way", then we're in a lot of trouble. Refer to the fact
that we've switched from XML to JSON because XML is too hard for most
developers.

The point of all this is to make it accessible and easy, since we have a
chicken-and-egg problem. If this is going to work, it's going to take the
whole long tail, not just Microsoft and Google. The specs we have right now
clearly don't work, but idle speculation on our part isn't going to make
any of this work.

b.

--f46d04016c6d06db9104be87ca45
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


*sigh*

This is crazy. There are a half-dozen of us deb=
ating theoretical ways to structure a thing that may or may not ever get us=
ed, so that some specs can get finalised so that *maybe* Microsoft and Goog=
le can ship a new version of OpenID (that doesn't adequately address on=
e of the core usability shortcomings of the first two OpenIDs).




I don=
't know if Evan Prodromou or anyone from Diaspora or anyone else who ha=
s *actually tried to deploy* similar things is watching this thread, but if=
 they are, I hope they pipe up, because there is absolutely zero considerat=
ion for actual implementations happening in this discussion.




Also, keep =
in mind that if *we're* confused about the host-meta processing rules, =
or if my "single-code-path" arguments are being dismissed because=
 "it's easy either way", then we're in a lot of trouble. =
Refer to the fact that we've switched from XML to JSON because XML is t=
oo hard for most developers.




The point o=
f all this is to make it accessible and easy, since we have a chicken-and-e=
gg problem. If this is going to work, it's going to take the whole long=
 tail, not just Microsoft and Google. The specs we have right now clearly d=
on't work, but idle speculation on our part isn't going to make any=
 of this work.




b.


--f46d04016c6d06db9104be87ca45--

From Michael.Jones@microsoft.com  Wed Apr 25 15:13: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 164B921E8049 for ; Wed, 25 Apr 2012 15:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.929
X-Spam-Level: 
X-Spam-Status: No, score=-3.929 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylal2Je9YgF6 for ; Wed, 25 Apr 2012 15:13:37 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 05FBF11E808E for ; Wed, 25 Apr 2012 15:13:34 -0700 (PDT)
Received: from mail183-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Wed, 25 Apr 2012 22:13:33 +0000
Received: from mail183-va3 (localhost [127.0.0.1])	by mail183-va3-R.bigfish.com (Postfix) with ESMTP id D180826052F; Wed, 25 Apr 2012 22:13:33 +0000 (UTC)
X-SpamScore: -46
X-BigFish: VS-46(z21aILz9371Ic89bh1803Mc857hzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail183-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail183-va3 (localhost.localdomain [127.0.0.1]) by mail183-va3 (MessageSwitch) id 1335392012390739_30548; Wed, 25 Apr 2012 22:13:32 +0000 (UTC)
Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.253])	by mail183-va3.bigfish.com (Postfix) with ESMTP id 59D8C100210; Wed, 25 Apr 2012 22:13:32 +0000 (UTC)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 25 Apr 2012 22:13:32 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0298.005; Wed, 25 Apr 2012 22:13:30 +0000
From: Mike Jones 
To: Blaine Cook , "apps-discuss@ietf.org" 
Thread-Topic: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect	discovery
Thread-Index: AQHNIxeF/1ProoIvn0WtumnQ5VDIrZasEyqAgAAGb8A=
Date: Wed, 25 Apr 2012 22:13:30 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366499664@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com> <054901cd2311$87a24fb0$96e6ef10$@packetizer.com> <4CC716F1-F6A4-46CF-86FD-6636B1F84500@ve7jtb.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_4E1F6AAD24975D4BA5B168042967394366499664TK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect	discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 22:13:38 -0000

--_000_4E1F6AAD24975D4BA5B168042967394366499664TK5EX14MBXC284r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBhZ3JlZSB0aGF0IGlmIHdl4oCZcmUgY29uZnVzZWQgYWJvdXQgdGhlIGhvc3QtbWV0YSBwcm9j
ZXNzaW5nIHJ1bGVzLCBldGMuIGl04oCZcyBhIHNpZ24gdGhhdCB3ZeKAmXJlIG1ha2luZyB0aGlu
Z3MgdG9vIGhhcmQuICBJIGJlbGlldmUgdGhlc2UgYXJlIGV4YWN0bHkgdGhlIGtpbmRzIG9mIHJl
YXNvbnMgdGhhdCBsZWQgWWFyb24gdG8gZGV2ZWxvcCBTaW1wbGUgV2ViIERpc2NvdmVyeS4NCg0K
TWF5YmUgaXTigJlzIHRpbWUgZm9yIHBlb3BsZSB0byByZXJlYWQgaHR0cDovL3d3dy5nb2xhbmQu
b3JnL3NpbXBsZXdlYmZpbmdlci8gYW5kIGh0dHA6Ly93d3cuZ29sYW5kLm9yZy9tYW5hZ2luZ2Zp
bmdlcnNlcnZpY2UvIChvciB0byByZWFkIHRoZW0gZm9yIHRoZSBmaXJzdCB0aW1lKS4gIEkgc3Vz
cGVjdCB0aGUgcmVhc29uaW5nIGluIHRoZW0gd2lsbCByZXNvbmF0ZSBtb3JlIGluIHRoZSBjb250
ZXh0IG9mIHRoZSBjdXJyZW50IGRpc2N1c3Npb24sIGZvciB3aGF0IGl04oCZcyB3b3J0aOKApg0K
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAtLSBNaWtlDQoNClAuUy4gIFlvdSBjYW4gdGFrZSB0aGUgdmlld3BvaW50IHRoaXMgaXMg
YWJvdXQgTWljcm9zb2Z0IGFuZCBHb29nbGUgaWYgeW91IGxpa2UsIGJ1dCBpbiBteSBtaW5kLCB0
aGlzIGlzIGFib3V0IHViaXF1aXRvdXMgZGlzY292ZXJ5IGZvciB0aGUgb3BlbiBXZWIuDQoNCkZy
b206IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCbGFpbmUgQ29vaw0KU2VudDogV2VkbmVzZGF5
LCBBcHJpbCAyNSwgMjAxMiAyOjQ1IFBNDQpUbzogYXBwcy1kaXNjdXNzQGlldGYub3JnDQpTdWJq
ZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gV2ViZmluZ2VyIC8gU1dEIElzc3VlICMzOiBkaXJlY3Qg
dmVyc3VzIGluZGlyZWN0IGRpc2NvdmVyeQ0KDQoqc2lnaCoNCg0KVGhpcyBpcyBjcmF6eS4gVGhl
cmUgYXJlIGEgaGFsZi1kb3plbiBvZiB1cyBkZWJhdGluZyB0aGVvcmV0aWNhbCB3YXlzIHRvIHN0
cnVjdHVyZSBhIHRoaW5nIHRoYXQgbWF5IG9yIG1heSBub3QgZXZlciBnZXQgdXNlZCwgc28gdGhh
dCBzb21lIHNwZWNzIGNhbiBnZXQgZmluYWxpc2VkIHNvIHRoYXQgKm1heWJlKiBNaWNyb3NvZnQg
YW5kIEdvb2dsZSBjYW4gc2hpcCBhIG5ldyB2ZXJzaW9uIG9mIE9wZW5JRCAodGhhdCBkb2Vzbid0
IGFkZXF1YXRlbHkgYWRkcmVzcyBvbmUgb2YgdGhlIGNvcmUgdXNhYmlsaXR5IHNob3J0Y29taW5n
cyBvZiB0aGUgZmlyc3QgdHdvIE9wZW5JRHMpLg0KDQpJIGRvbid0IGtub3cgaWYgRXZhbiBQcm9k
cm9tb3Ugb3IgYW55b25lIGZyb20gRGlhc3BvcmEgb3IgYW55b25lIGVsc2Ugd2hvIGhhcyAqYWN0
dWFsbHkgdHJpZWQgdG8gZGVwbG95KiBzaW1pbGFyIHRoaW5ncyBpcyB3YXRjaGluZyB0aGlzIHRo
cmVhZCwgYnV0IGlmIHRoZXkgYXJlLCBJIGhvcGUgdGhleSBwaXBlIHVwLCBiZWNhdXNlIHRoZXJl
IGlzIGFic29sdXRlbHkgemVybyBjb25zaWRlcmF0aW9uIGZvciBhY3R1YWwgaW1wbGVtZW50YXRp
b25zIGhhcHBlbmluZyBpbiB0aGlzIGRpc2N1c3Npb24uDQoNCkFsc28sIGtlZXAgaW4gbWluZCB0
aGF0IGlmICp3ZSdyZSogY29uZnVzZWQgYWJvdXQgdGhlIGhvc3QtbWV0YSBwcm9jZXNzaW5nIHJ1
bGVzLCBvciBpZiBteSAic2luZ2xlLWNvZGUtcGF0aCIgYXJndW1lbnRzIGFyZSBiZWluZyBkaXNt
aXNzZWQgYmVjYXVzZSAiaXQncyBlYXN5IGVpdGhlciB3YXkiLCB0aGVuIHdlJ3JlIGluIGEgbG90
IG9mIHRyb3VibGUuIFJlZmVyIHRvIHRoZSBmYWN0IHRoYXQgd2UndmUgc3dpdGNoZWQgZnJvbSBY
TUwgdG8gSlNPTiBiZWNhdXNlIFhNTCBpcyB0b28gaGFyZCBmb3IgbW9zdCBkZXZlbG9wZXJzLg0K
DQpUaGUgcG9pbnQgb2YgYWxsIHRoaXMgaXMgdG8gbWFrZSBpdCBhY2Nlc3NpYmxlIGFuZCBlYXN5
LCBzaW5jZSB3ZSBoYXZlIGEgY2hpY2tlbi1hbmQtZWdnIHByb2JsZW0uIElmIHRoaXMgaXMgZ29p
bmcgdG8gd29yaywgaXQncyBnb2luZyB0byB0YWtlIHRoZSB3aG9sZSBsb25nIHRhaWwsIG5vdCBq
dXN0IE1pY3Jvc29mdCBhbmQgR29vZ2xlLiBUaGUgc3BlY3Mgd2UgaGF2ZSByaWdodCBub3cgY2xl
YXJseSBkb24ndCB3b3JrLCBidXQgaWRsZSBzcGVjdWxhdGlvbiBvbiBvdXIgcGFydCBpc24ndCBn
b2luZyB0byBtYWtlIGFueSBvZiB0aGlzIHdvcmsuDQoNCmIuDQo=

--_000_4E1F6AAD24975D4BA5B168042967394366499664TK5EX14MBXC284r_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp
bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K
CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s
PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl
eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs
YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu
az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkkgYWdyZWUgdGhhdCBpZiB3ZeKAmXJlIGNvbmZ1c2VkIGFib3V0IHRoZSBob3N0LW1ldGEg
cHJvY2Vzc2luZyBydWxlcywgZXRjLiBpdOKAmXMgYSBzaWduIHRoYXQgd2XigJlyZSBtYWtpbmcg
dGhpbmdzIHRvbyBoYXJkLiZuYnNwOyBJIGJlbGlldmUgdGhlc2UgYXJlIGV4YWN0bHkgdGhlIGtp
bmRzDQogb2YgcmVhc29ucyB0aGF0IGxlZCBZYXJvbiB0byBkZXZlbG9wIFNpbXBsZSBXZWIgRGlz
Y292ZXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+TWF5YmUgaXTigJlzIHRpbWUgZm9yIHBlb3BsZSB0byByZXJlYWQN
CjxhIGhyZWY9Imh0dHA6Ly93d3cuZ29sYW5kLm9yZy9zaW1wbGV3ZWJmaW5nZXIvIj5odHRwOi8v
d3d3LmdvbGFuZC5vcmcvc2ltcGxld2ViZmluZ2VyLzwvYT4gYW5kDQo8YSBocmVmPSJodHRwOi8v
d3d3LmdvbGFuZC5vcmcvbWFuYWdpbmdmaW5nZXJzZXJ2aWNlLyI+aHR0cDovL3d3dy5nb2xhbmQu
b3JnL21hbmFnaW5nZmluZ2Vyc2VydmljZS88L2E+IChvciB0byByZWFkIHRoZW0gZm9yIHRoZSBm
aXJzdCB0aW1lKS4mbmJzcDsgSSBzdXNwZWN0IHRoZSByZWFzb25pbmcgaW4gdGhlbSB3aWxsIHJl
c29uYXRlIG1vcmUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbiwgZm9y
IHdoYXQgaXTigJlzIHdvcnRo4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+UC5TLiZuYnNwOyBZb3UgY2FuIHRha2UgdGhlIHZpZXdwb2ludCB0aGlzIGlzIGFib3V0
IE1pY3Jvc29mdCBhbmQgR29vZ2xlIGlmIHlvdSBsaWtlLCBidXQgaW4gbXkgbWluZCwgdGhpcyBp
cyBhYm91dCB1YmlxdWl0b3VzIGRpc2NvdmVyeSBmb3IgdGhlIG9wZW4gV2ViLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0
Zi5vcmcgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs
ZiBPZiA8L2I+QmxhaW5lIENvb2s8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAy
NSwgMjAxMiAyOjQ1IFBNPGJyPg0KPGI+VG86PC9iPiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmc8YnI+
DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFthcHBzLWRpc2N1c3NdIFdlYmZpbmdlciAvIFNXRCBJc3N1
ZSAjMzogZGlyZWN0IHZlcnN1cyBpbmRpcmVjdCBkaXNjb3Zlcnk8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4qc2lnaCo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBjcmF6eS4gVGhlcmUgYXJlIGEgaGFsZi1k
b3plbiBvZiB1cyBkZWJhdGluZyB0aGVvcmV0aWNhbCB3YXlzIHRvIHN0cnVjdHVyZSBhIHRoaW5n
IHRoYXQgbWF5IG9yIG1heSBub3QgZXZlciBnZXQgdXNlZCwgc28gdGhhdCBzb21lIHNwZWNzIGNh
biBnZXQgZmluYWxpc2VkIHNvIHRoYXQgKm1heWJlKiBNaWNyb3NvZnQgYW5kIEdvb2dsZSBjYW4g
c2hpcCBhIG5ldyB2ZXJzaW9uIG9mIE9wZW5JRCAodGhhdA0KIGRvZXNuJ3QgYWRlcXVhdGVseSBh
ZGRyZXNzIG9uZSBvZiB0aGUgY29yZSB1c2FiaWxpdHkgc2hvcnRjb21pbmdzIG9mIHRoZSBmaXJz
dCB0d28gT3BlbklEcykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkkgZG9uJ3Qga25vdyBpZiBFdmFuIFByb2Ryb21vdSBvciBhbnlvbmUgZnJv
bSBEaWFzcG9yYSBvciBhbnlvbmUgZWxzZSB3aG8gaGFzICphY3R1YWxseSB0cmllZCB0byBkZXBs
b3kqIHNpbWlsYXIgdGhpbmdzIGlzIHdhdGNoaW5nIHRoaXMgdGhyZWFkLCBidXQgaWYgdGhleSBh
cmUsIEkgaG9wZSB0aGV5IHBpcGUgdXAsIGJlY2F1c2UgdGhlcmUgaXMgYWJzb2x1dGVseSB6ZXJv
IGNvbnNpZGVyYXRpb24gZm9yIGFjdHVhbA0KIGltcGxlbWVudGF0aW9ucyBoYXBwZW5pbmcgaW4g
dGhpcyBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5BbHNvLCBrZWVwIGluIG1pbmQgdGhhdCBpZiAqd2UncmUqIGNvbmZ1c2Vk
IGFib3V0IHRoZSBob3N0LW1ldGEgcHJvY2Vzc2luZyBydWxlcywgb3IgaWYgbXkgJnF1b3Q7c2lu
Z2xlLWNvZGUtcGF0aCZxdW90OyBhcmd1bWVudHMgYXJlIGJlaW5nIGRpc21pc3NlZCBiZWNhdXNl
ICZxdW90O2l0J3MgZWFzeSBlaXRoZXIgd2F5JnF1b3Q7LCB0aGVuIHdlJ3JlIGluIGEgbG90IG9m
IHRyb3VibGUuIFJlZmVyIHRvIHRoZSBmYWN0IHRoYXQgd2UndmUgc3dpdGNoZWQNCiBmcm9tIFhN
TCB0byBKU09OIGJlY2F1c2UgWE1MIGlzIHRvbyBoYXJkIGZvciBtb3N0IGRldmVsb3BlcnMuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBw
b2ludCBvZiBhbGwgdGhpcyBpcyB0byBtYWtlIGl0IGFjY2Vzc2libGUgYW5kIGVhc3ksIHNpbmNl
IHdlIGhhdmUgYSBjaGlja2VuLWFuZC1lZ2cgcHJvYmxlbS4gSWYgdGhpcyBpcyBnb2luZyB0byB3
b3JrLCBpdCdzIGdvaW5nIHRvIHRha2UgdGhlIHdob2xlIGxvbmcgdGFpbCwgbm90IGp1c3QgTWlj
cm9zb2Z0IGFuZCBHb29nbGUuIFRoZSBzcGVjcyB3ZSBoYXZlIHJpZ2h0IG5vdyBjbGVhcmx5IGRv
bid0DQogd29yaywgYnV0IGlkbGUgc3BlY3VsYXRpb24gb24gb3VyIHBhcnQgaXNuJ3QgZ29pbmcg
dG8gbWFrZSBhbnkgb2YgdGhpcyB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_4E1F6AAD24975D4BA5B168042967394366499664TK5EX14MBXC284r_--

From romeda@gmail.com  Wed Apr 25 15:31: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 3B81221F87C9 for ; Wed, 25 Apr 2012 15:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.531
X-Spam-Level: 
X-Spam-Status: No, score=-103.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEdV0g0AmofQ for ; Wed, 25 Apr 2012 15:31:36 -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 6D78721F87C5 for ; Wed, 25 Apr 2012 15:31:28 -0700 (PDT)
Received: by lbbgm13 with SMTP id gm13so346878lbb.31 for ; Wed, 25 Apr 2012 15:31:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KoJGo++QTnJ+0bYKMseDOk6iuTtXM3I6B9Qbo3mJwOE=; b=FNKx4xi8ci4hd9lLWy8f+SAgt9O9z58fxRMNwwQ6jLAAXm/L72nIZg8X/VUljkkjyk Zt6rFxVQUEOibZZ3js2BmRd6rae7twJRngPxA/sW6cQ5Y2uSIWs74JRnKiojXxwavSKK Io7PDBziOJZSZwOoMFlS0UzLsnVd2kA/ci3R8YYxW9VhbhHqsAgcGOBex9L1xmUf+N5K Nd8NxbgjkxQvHjX+iPn4K8uWcs341ZjNJRn0Fno4KrBbxCWWlqHAXQ6irFYQsPZHjv9w HcREy9RB+BY0GU9I+bagk0iHktT4YMrVY1m/uZZp62XHfwx8q6ma215ve43C0tZLH3l0 Bizg==
Received: by 10.152.110.170 with SMTP id ib10mr4782812lab.7.1335393087389; Wed, 25 Apr 2012 15:31:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.24.229 with HTTP; Wed, 25 Apr 2012 15:31:07 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366499664@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com> <054901cd2311$87a24fb0$96e6ef10$@packetizer.com> <4CC716F1-F6A4-46CF-86FD-6636B1F84500@ve7jtb.com>  <4E1F6AAD24975D4BA5B168042967394366499664@TK5EX14MBXC284.redmond.corp.microsoft.com>
From: Blaine Cook 
Date: Wed, 25 Apr 2012 23:31:07 +0100
Message-ID: 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=f46d0408d6b59c01a004be886ef5
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 22:31:37 -0000

--f46d0408d6b59c01a004be886ef5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 25 April 2012 23:13, Mike Jones  wrote:

>  P.S.  You can take the viewpoint this is about Microsoft and Google if
> you like, but in my mind, this is about ubiquitous discovery for the open
> Web.
>

I'll take another look at Yaron's posts when I get a chance, but yes =E2=80=
=93 we
definitely agree on this! :-) I'm just worried that there's a very limited
set of people debating this. I'm working on getting relevant people to
comment. I strongly believe in the consensus process here, but we really
need the code bit in play for this discussion to be fruitful.

b.

--f46d0408d6b59c01a004be886ef5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On 25 April 2012 23:13, Mike Jones <M=
ichael.Jones@microsoft.com> wrote:













P.S.=C2=A0 You can take the viewpoint this i=
s about Microsoft and Google if you like, but in my mind, this is about ubi=
quitous discovery for the open Web.




I'll take another look at =
Yaron's posts when I get a chance, but yes =E2=80=93 we definitely agre=
e on this! :-) I'm just worried that there's a very limited set of =
people debating this. I'm working on getting relevant people to comment=
. I strongly believe in the consensus process here, but we really need the =
code bit in play for this discussion to be fruitful.




b.


--f46d0408d6b59c01a004be886ef5--

From eran@hueniverse.com  Wed Apr 25 15:46: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 57DEB21E8051 for ; Wed, 25 Apr 2012 15:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnyt2j0Ha35N for ; Wed, 25 Apr 2012 15:46:38 -0700 (PDT)
Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 333D511E808C for ; Wed, 25 Apr 2012 15:46:38 -0700 (PDT)
Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id 2Nmd1j0040EuLVk01NmdGx; Wed, 25 Apr 2012 15:46:37 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Wed, 25 Apr 2012 15:46:37 -0700
From: Eran Hammer 
To: Mike Jones , Blaine Cook ,  "apps-discuss@ietf.org" 
Thread-Topic: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect	discovery
Thread-Index: AQHNIzCr+2ULRXEvnE6KUPc3ynazSpasI0sw
Date: Wed, 25 Apr 2012 22:46:36 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20100B46D@P3PWEX2MB008.ex2.secureserver.net>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com> <054901cd2311$87a24fb0$96e6ef10$@packetizer.com> <4CC716F1-F6A4-46CF-86FD-6636B1F84500@ve7jtb.com>  <4E1F6AAD24975D4BA5B168042967394366499664@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366499664@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA20100B46DP3PWEX2MB008ex2_"
MIME-Version: 1.0
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus	indirect	discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 22:46:39 -0000

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA20100B46DP3PWEX2MB008ex2_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSB3b3VsZCBhcmd1ZSB0aGF0IG11Y2ggb2YgdGhlIGNvbmZ1c2lvbiBpcyBjb21pbmcgZnJvbSB0
cnlpbmcgdG8gdW5kZXJzdGFuZCBob3N0LW1ldGEgZnJvbSBhIGZldyBleGFtcGxlcyByYXRoZXIg
dGhhbiByZWFkIHRoZSAodmVyeSBzaG9ydCkgc3BlY2lmaWNhdGlvbi4gVGhlcmUgaXMgdmFsdWUg
aW4gYm90aCBwcm9wb3NhbHMgaW4gdGhhdCB0aGV5IHJlcHJlc2VudCB2ZXJ5IGRpZmZlcmVudCB1
c2UgY2FzZXMgYW5kIGRldmVsb3BtZW50IGV4cGVyaWVuY2UuDQoNCkkgYW0gbm90IGFkdm9jYXRp
bmcgYW55IHBhcnRpY3VsYXIgZW5kIHJlc3VsdCBoZXJlIOKAkyBJIGFtIGNvbmZpZGVudCBJIHdp
bGwgbmV2ZXIgbmVlZCB0byBpbXBsZW1lbnQgYW55IG9mIHRoaXMsIHNvIG15IHBhcnRpY2lwYXRp
b24gaGVyZSBpcyBsaW1pdGVkIHRvIG9mZmVyaW5nIGNsYXJpZmljYXRpb24gb24gaG9zdC1tZXRh
IGFuZCByZXByZXNlbnRpbmcgYWJvdXQgNSB5ZWFycyBvZiBjb21tdW5pdHkgd29yayBJ4oCZdmUg
YmVlbiBwYXJ0IG9mLg0KDQpFSA0KDQoNCkZyb206IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYu
b3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBN
aWtlIEpvbmVzDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI1LCAyMDEyIDM6MTQgUE0NClRvOiBC
bGFpbmUgQ29vazsgYXBwcy1kaXNjdXNzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2FwcHMtZGlz
Y3Vzc10gV2ViZmluZ2VyIC8gU1dEIElzc3VlICMzOiBkaXJlY3QgdmVyc3VzIGluZGlyZWN0IGRp
c2NvdmVyeQ0KDQpJIGFncmVlIHRoYXQgaWYgd2XigJlyZSBjb25mdXNlZCBhYm91dCB0aGUgaG9z
dC1tZXRhIHByb2Nlc3NpbmcgcnVsZXMsIGV0Yy4gaXTigJlzIGEgc2lnbiB0aGF0IHdl4oCZcmUg
bWFraW5nIHRoaW5ncyB0b28gaGFyZC4gIEkgYmVsaWV2ZSB0aGVzZSBhcmUgZXhhY3RseSB0aGUg
a2luZHMgb2YgcmVhc29ucyB0aGF0IGxlZCBZYXJvbiB0byBkZXZlbG9wIFNpbXBsZSBXZWIgRGlz
Y292ZXJ5Lg0KDQpNYXliZSBpdOKAmXMgdGltZSBmb3IgcGVvcGxlIHRvIHJlcmVhZCBodHRwOi8v
d3d3LmdvbGFuZC5vcmcvc2ltcGxld2ViZmluZ2VyLyBhbmQgaHR0cDovL3d3dy5nb2xhbmQub3Jn
L21hbmFnaW5nZmluZ2Vyc2VydmljZS8gKG9yIHRvIHJlYWQgdGhlbSBmb3IgdGhlIGZpcnN0IHRp
bWUpLiAgSSBzdXNwZWN0IHRoZSByZWFzb25pbmcgaW4gdGhlbSB3aWxsIHJlc29uYXRlIG1vcmUg
aW4gdGhlIGNvbnRleHQgb2YgdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbiwgZm9yIHdoYXQgaXTigJlz
IHdvcnRo4oCmDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KUC5TLiAgWW91IGNhbiB0YWtlIHRoZSB2aWV3cG9p
bnQgdGhpcyBpcyBhYm91dCBNaWNyb3NvZnQgYW5kIEdvb2dsZSBpZiB5b3UgbGlrZSwgYnV0IGlu
IG15IG1pbmQsIHRoaXMgaXMgYWJvdXQgdWJpcXVpdG91cyBkaXNjb3ZlcnkgZm9yIHRoZSBvcGVu
IFdlYi4NCg0KRnJvbTogYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFwcHMt
ZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGll
dGYub3JnXTxtYWlsdG86W21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10+IE9u
IEJlaGFsZiBPZiBCbGFpbmUgQ29vaw0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAxMiAy
OjQ1IFBNDQpUbzogYXBwcy1kaXNjdXNzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3NAaWV0
Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gV2ViZmluZ2VyIC8gU1dEIElzc3Vl
ICMzOiBkaXJlY3QgdmVyc3VzIGluZGlyZWN0IGRpc2NvdmVyeQ0KDQoqc2lnaCoNCg0KVGhpcyBp
cyBjcmF6eS4gVGhlcmUgYXJlIGEgaGFsZi1kb3plbiBvZiB1cyBkZWJhdGluZyB0aGVvcmV0aWNh
bCB3YXlzIHRvIHN0cnVjdHVyZSBhIHRoaW5nIHRoYXQgbWF5IG9yIG1heSBub3QgZXZlciBnZXQg
dXNlZCwgc28gdGhhdCBzb21lIHNwZWNzIGNhbiBnZXQgZmluYWxpc2VkIHNvIHRoYXQgKm1heWJl
KiBNaWNyb3NvZnQgYW5kIEdvb2dsZSBjYW4gc2hpcCBhIG5ldyB2ZXJzaW9uIG9mIE9wZW5JRCAo
dGhhdCBkb2Vzbid0IGFkZXF1YXRlbHkgYWRkcmVzcyBvbmUgb2YgdGhlIGNvcmUgdXNhYmlsaXR5
IHNob3J0Y29taW5ncyBvZiB0aGUgZmlyc3QgdHdvIE9wZW5JRHMpLg0KDQpJIGRvbid0IGtub3cg
aWYgRXZhbiBQcm9kcm9tb3Ugb3IgYW55b25lIGZyb20gRGlhc3BvcmEgb3IgYW55b25lIGVsc2Ug
d2hvIGhhcyAqYWN0dWFsbHkgdHJpZWQgdG8gZGVwbG95KiBzaW1pbGFyIHRoaW5ncyBpcyB3YXRj
aGluZyB0aGlzIHRocmVhZCwgYnV0IGlmIHRoZXkgYXJlLCBJIGhvcGUgdGhleSBwaXBlIHVwLCBi
ZWNhdXNlIHRoZXJlIGlzIGFic29sdXRlbHkgemVybyBjb25zaWRlcmF0aW9uIGZvciBhY3R1YWwg
aW1wbGVtZW50YXRpb25zIGhhcHBlbmluZyBpbiB0aGlzIGRpc2N1c3Npb24uDQoNCkFsc28sIGtl
ZXAgaW4gbWluZCB0aGF0IGlmICp3ZSdyZSogY29uZnVzZWQgYWJvdXQgdGhlIGhvc3QtbWV0YSBw
cm9jZXNzaW5nIHJ1bGVzLCBvciBpZiBteSAic2luZ2xlLWNvZGUtcGF0aCIgYXJndW1lbnRzIGFy
ZSBiZWluZyBkaXNtaXNzZWQgYmVjYXVzZSAiaXQncyBlYXN5IGVpdGhlciB3YXkiLCB0aGVuIHdl
J3JlIGluIGEgbG90IG9mIHRyb3VibGUuIFJlZmVyIHRvIHRoZSBmYWN0IHRoYXQgd2UndmUgc3dp
dGNoZWQgZnJvbSBYTUwgdG8gSlNPTiBiZWNhdXNlIFhNTCBpcyB0b28gaGFyZCBmb3IgbW9zdCBk
ZXZlbG9wZXJzLg0KDQpUaGUgcG9pbnQgb2YgYWxsIHRoaXMgaXMgdG8gbWFrZSBpdCBhY2Nlc3Np
YmxlIGFuZCBlYXN5LCBzaW5jZSB3ZSBoYXZlIGEgY2hpY2tlbi1hbmQtZWdnIHByb2JsZW0uIElm
IHRoaXMgaXMgZ29pbmcgdG8gd29yaywgaXQncyBnb2luZyB0byB0YWtlIHRoZSB3aG9sZSBsb25n
IHRhaWwsIG5vdCBqdXN0IE1pY3Jvc29mdCBhbmQgR29vZ2xlLiBUaGUgc3BlY3Mgd2UgaGF2ZSBy
aWdodCBub3cgY2xlYXJseSBkb24ndCB3b3JrLCBidXQgaWRsZSBzcGVjdWxhdGlvbiBvbiBvdXIg
cGFydCBpc24ndCBnb2luZyB0byBtYWtlIGFueSBvZiB0aGlzIHdvcmsuDQoNCmIuDQo=

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA20100B46DP3PWEX2MB008ex2_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv
QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp
bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K
CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy
c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv
cjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs
b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r
OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQou
TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6
MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn
aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv
cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh
cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm
XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi
Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94
bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg
dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291
bGQgYXJndWUgdGhhdCBtdWNoIG9mIHRoZSBjb25mdXNpb24gaXMgY29taW5nIGZyb20gdHJ5aW5n
IHRvIHVuZGVyc3RhbmQgaG9zdC1tZXRhIGZyb20gYSBmZXcgZXhhbXBsZXMgcmF0aGVyIHRoYW4g
cmVhZCB0aGUgKHZlcnkgc2hvcnQpIHNwZWNpZmljYXRpb24uDQogVGhlcmUgaXMgdmFsdWUgaW4g
Ym90aCBwcm9wb3NhbHMgaW4gdGhhdCB0aGV5IHJlcHJlc2VudCB2ZXJ5IGRpZmZlcmVudCB1c2Ug
Y2FzZXMgYW5kIGRldmVsb3BtZW50IGV4cGVyaWVuY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFtIG5vdCBhZHZv
Y2F0aW5nIGFueSBwYXJ0aWN1bGFyIGVuZCByZXN1bHQgaGVyZSDigJMgSSBhbSBjb25maWRlbnQg
SSB3aWxsIG5ldmVyIG5lZWQgdG8gaW1wbGVtZW50IGFueSBvZiB0aGlzLCBzbyBteSBwYXJ0aWNp
cGF0aW9uIGhlcmUgaXMgbGltaXRlZCB0byBvZmZlcmluZw0KIGNsYXJpZmljYXRpb24gb24gaG9z
dC1tZXRhIGFuZCByZXByZXNlbnRpbmcgYWJvdXQgNSB5ZWFycyBvZiBjb21tdW5pdHkgd29yayBJ
4oCZdmUgYmVlbiBwYXJ0IG9mLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RUg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5j
ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1pa2UgSm9uZXM8YnI+DQo8Yj5TZW50
OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAxMiAzOjE0IFBNPGJyPg0KPGI+VG86PC9iPiBC
bGFpbmUgQ29vazsgYXBwcy1kaXNjdXNzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl
OiBbYXBwcy1kaXNjdXNzXSBXZWJmaW5nZXIgLyBTV0QgSXNzdWUgIzM6IGRpcmVjdCB2ZXJzdXMg
aW5kaXJlY3QgZGlzY292ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdy
ZWUgdGhhdCBpZiB3ZeKAmXJlIGNvbmZ1c2VkIGFib3V0IHRoZSBob3N0LW1ldGEgcHJvY2Vzc2lu
ZyBydWxlcywgZXRjLiBpdOKAmXMgYSBzaWduIHRoYXQgd2XigJlyZSBtYWtpbmcgdGhpbmdzIHRv
byBoYXJkLiZuYnNwOyBJIGJlbGlldmUgdGhlc2UgYXJlIGV4YWN0bHkgdGhlIGtpbmRzDQogb2Yg
cmVhc29ucyB0aGF0IGxlZCBZYXJvbiB0byBkZXZlbG9wIFNpbXBsZSBXZWIgRGlzY292ZXJ5Ljxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+TWF5YmUgaXTigJlzIHRpbWUgZm9yIHBlb3BsZSB0byByZXJlYWQNCjxhIGhyZWY9
Imh0dHA6Ly93d3cuZ29sYW5kLm9yZy9zaW1wbGV3ZWJmaW5nZXIvIj5odHRwOi8vd3d3LmdvbGFu
ZC5vcmcvc2ltcGxld2ViZmluZ2VyLzwvYT4gYW5kDQo8YSBocmVmPSJodHRwOi8vd3d3LmdvbGFu
ZC5vcmcvbWFuYWdpbmdmaW5nZXJzZXJ2aWNlLyI+aHR0cDovL3d3dy5nb2xhbmQub3JnL21hbmFn
aW5nZmluZ2Vyc2VydmljZS88L2E+IChvciB0byByZWFkIHRoZW0gZm9yIHRoZSBmaXJzdCB0aW1l
KS4mbmJzcDsgSSBzdXNwZWN0IHRoZSByZWFzb25pbmcgaW4gdGhlbSB3aWxsIHJlc29uYXRlIG1v
cmUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbiwgZm9yIHdoYXQgaXTi
gJlzIHdvcnRo4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UC5T
LiZuYnNwOyBZb3UgY2FuIHRha2UgdGhlIHZpZXdwb2ludCB0aGlzIGlzIGFib3V0IE1pY3Jvc29m
dCBhbmQgR29vZ2xlIGlmIHlvdSBsaWtlLCBidXQgaW4gbXkgbWluZCwgdGhpcyBpcyBhYm91dCB1
YmlxdWl0b3VzIGRpc2NvdmVyeSBmb3IgdGhlIG9wZW4gV2ViLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3MtYm91
bmNlc0BpZXRmLm9yZyI+YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9
Im1haWx0bzpbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSI+DQpbbWFpbHRv
OmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXTwvYT4gPGI+T24gQmVoYWxmIE9mIDwvYj5C
bGFpbmUgQ29vazxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDI1LCAyMDEyIDI6
NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5v
cmciPmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFth
cHBzLWRpc2N1c3NdIFdlYmZpbmdlciAvIFNXRCBJc3N1ZSAjMzogZGlyZWN0IHZlcnN1cyBpbmRp
cmVjdCBkaXNjb3Zlcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qc2ln
aCo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
VGhpcyBpcyBjcmF6eS4gVGhlcmUgYXJlIGEgaGFsZi1kb3plbiBvZiB1cyBkZWJhdGluZyB0aGVv
cmV0aWNhbCB3YXlzIHRvIHN0cnVjdHVyZSBhIHRoaW5nIHRoYXQgbWF5IG9yIG1heSBub3QgZXZl
ciBnZXQgdXNlZCwgc28gdGhhdCBzb21lIHNwZWNzIGNhbiBnZXQgZmluYWxpc2VkIHNvIHRoYXQg
Km1heWJlKiBNaWNyb3NvZnQgYW5kIEdvb2dsZSBjYW4gc2hpcCBhIG5ldyB2ZXJzaW9uIG9mIE9w
ZW5JRCAodGhhdA0KIGRvZXNuJ3QgYWRlcXVhdGVseSBhZGRyZXNzIG9uZSBvZiB0aGUgY29yZSB1
c2FiaWxpdHkgc2hvcnRjb21pbmdzIG9mIHRoZSBmaXJzdCB0d28gT3BlbklEcykuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3Qga25v
dyBpZiBFdmFuIFByb2Ryb21vdSBvciBhbnlvbmUgZnJvbSBEaWFzcG9yYSBvciBhbnlvbmUgZWxz
ZSB3aG8gaGFzICphY3R1YWxseSB0cmllZCB0byBkZXBsb3kqIHNpbWlsYXIgdGhpbmdzIGlzIHdh
dGNoaW5nIHRoaXMgdGhyZWFkLCBidXQgaWYgdGhleSBhcmUsIEkgaG9wZSB0aGV5IHBpcGUgdXAs
IGJlY2F1c2UgdGhlcmUgaXMgYWJzb2x1dGVseSB6ZXJvIGNvbnNpZGVyYXRpb24gZm9yIGFjdHVh
bA0KIGltcGxlbWVudGF0aW9ucyBoYXBwZW5pbmcgaW4gdGhpcyBkaXNjdXNzaW9uLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCBrZWVw
IGluIG1pbmQgdGhhdCBpZiAqd2UncmUqIGNvbmZ1c2VkIGFib3V0IHRoZSBob3N0LW1ldGEgcHJv
Y2Vzc2luZyBydWxlcywgb3IgaWYgbXkgJnF1b3Q7c2luZ2xlLWNvZGUtcGF0aCZxdW90OyBhcmd1
bWVudHMgYXJlIGJlaW5nIGRpc21pc3NlZCBiZWNhdXNlICZxdW90O2l0J3MgZWFzeSBlaXRoZXIg
d2F5JnF1b3Q7LCB0aGVuIHdlJ3JlIGluIGEgbG90IG9mIHRyb3VibGUuIFJlZmVyIHRvIHRoZSBm
YWN0IHRoYXQgd2UndmUgc3dpdGNoZWQNCiBmcm9tIFhNTCB0byBKU09OIGJlY2F1c2UgWE1MIGlz
IHRvbyBoYXJkIGZvciBtb3N0IGRldmVsb3BlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwb2ludCBvZiBhbGwgdGhpcyBpcyB0byBt
YWtlIGl0IGFjY2Vzc2libGUgYW5kIGVhc3ksIHNpbmNlIHdlIGhhdmUgYSBjaGlja2VuLWFuZC1l
Z2cgcHJvYmxlbS4gSWYgdGhpcyBpcyBnb2luZyB0byB3b3JrLCBpdCdzIGdvaW5nIHRvIHRha2Ug
dGhlIHdob2xlIGxvbmcgdGFpbCwgbm90IGp1c3QgTWljcm9zb2Z0IGFuZCBHb29nbGUuIFRoZSBz
cGVjcyB3ZSBoYXZlIHJpZ2h0IG5vdyBjbGVhcmx5IGRvbid0DQogd29yaywgYnV0IGlkbGUgc3Bl
Y3VsYXRpb24gb24gb3VyIHBhcnQgaXNuJ3QgZ29pbmcgdG8gbWFrZSBhbnkgb2YgdGhpcyB3b3Jr
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5i
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA20100B46DP3PWEX2MB008ex2_--

From ve7jtb@ve7jtb.com  Wed Apr 25 15:47: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 26EA721E8051 for ; Wed, 25 Apr 2012 15:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.454
X-Spam-Level: 
X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.011,  BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Whgg+ciFet4u for ; Wed, 25 Apr 2012 15:47:28 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1658721E804D for ; Wed, 25 Apr 2012 15:47:28 -0700 (PDT)
Received: by yenm5 with SMTP id m5so649305yen.31 for ; Wed, 25 Apr 2012 15:47:27 -0700 (PDT)
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=tN2wSKTTu3t0FE9jMSkjcihQamHg9W6PdRcACII9eOY=; b=KrE1tzAjqqqkmYqQD+5A/zrHexQIn7KlLSDkjehIW5/gSMU7kVInS3xCZbMfhvgy/k PXDsbznZNWJsgVxDq6sN0qGOrMPBA3hwpwXiwqlEZPHdOqAb/T4TdZdz78M8kw/1VwNW GTG2wiXTPBkIKKnsMtBW+o4VKxZFWxpOBW/C4bvKdqHfNui3U+rGDn3SCqu024+hhe5Y YKxUWfci2UoRdQPuCnrzz6vipN0gFBb3FbRHFd5G0oMObd0hIb2cZ7zKY/BKywQ2FqoA 0xO37a8aRrrVoEnnYKUfXU8ZTr9q7JyFr9123KKJdRjWxOBgijED1yeRMw0nT8n+S3bV 4KoA==
Received: by 10.100.246.16 with SMTP id t16mr1333235anh.3.1335394047614; Wed, 25 Apr 2012 15:47:27 -0700 (PDT)
Received: from [192.168.1.213] (190-20-63-108.baf.movistar.cl. [190.20.63.108]) by mx.google.com with ESMTPS id 49sm4843938yhs.12.2012.04.25.15.47.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 15:47:26 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_7BE170EC-C17F-438D-9B3B-F4DF7534A34C"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20100B18C@P3PWEX2MB008.ex2.secureserver.net>
Date: Wed, 25 Apr 2012 19:47:18 -0300
Message-Id: 
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201007020@P3PWEX2MB008.ex2.secureserver.net> <515663DA-67BF-4367-9AD9-6E940424CBCD@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20100990A@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA201009E4D@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA20100AEA2@P3PWEX2MB008.ex2.secureserver.net> <1699AC2D-56DD-44F1-BA51-5E01CCA43E26@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20100B18C@P3PWEX2MB008.ex2.secureserver.net>
To: Eran Hammer 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQnUBYKVxrtQrWGxa3IwzPwpG/qyhSjiIfHDEttoBfWctpy1lVJOGbXNgVeAWbRiu/T1Z3dH
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 22:47:30 -0000

--Apple-Mail=_7BE170EC-C17F-438D-9B3B-F4DF7534A34C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Thanks,

I think the example may be wrong though.

Shouldn't  the response to:
> GET /.well-known/host-meta.json?resource=3Dhttp://example.com/resource

be:
> {
>  "links":[
>    {
>      "rel":"example",
>      "href":"http://example.com/3"
>    },
>    {
>      "rel":"example",
>      "href":"http://example.com/2"
>    }
>  ]
> }

What bit of magic logic turns the template to a href in the response?   =
I would not have guessed that, part of my confusion.

So "template" gets expanded and  converted to href in the host-meta =
along with the "subject" becoming a canonical synonym for "resource"?

The "subject" value indicating that host side processing succeeded?

I feel like I am closer to understanding,  though perhaps farther away =
on convincing people of WF's simplicity for clients.

John B.


On 2012-04-25, at 6:11 PM, Eran Hammer wrote:

> If your host-meta is:
>=20
> {
>  "links":[
>    {
>      "rel":"example",
>      "href":"http://example.com/1"
>    },
>    {
>      "rel":"lrdd",
>      "template":"http://example.com/lrdd?resource=3D{uri}"
>    },
>    {
>      "rel":"example",
>      "template":"http://example.com/2"
>    }
>  ]
> }
>=20
> And your LRDD document always return:
>=20
> {
>  "links":[
>    {
>      "rel":"example",
>      "template":"http://example.com/3"
>    }
>  ]
> }
>=20
> Then a host-wide request:
>=20
> GET /.well-known/host-meta.json?rel=3Dexample
>=20
> Will return (I haven't checked the exact format of the latest draft so =
the syntax might be wrong here):
>=20
> {
>  "links":[
>    {
>      "rel":"example",
>      "href":"http://example.com/1"
>    }
>  ]
> }
>=20
> And a resource-specific request (not escaped for readability):
>=20
> GET /.well-known/host-meta.json?resource=3Dhttp://example.com/resource
>=20
> Will return:
>=20
> {
>  "links":[
>    {
>      "rel":"example",
>      "href":"http://example.com/1"
>    },
>    {
>      "rel":"example",
>      "href":"http://example.com/2"
>    }
>  ]
> }
>=20
> Does this help?
>=20
> EH
>=20
>> -----Original Message-----
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>> Sent: Wednesday, April 25, 2012 1:08 PM
>> To: Eran Hammer
>> Cc: Paul E. Jones; apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>=20
>> So the merged output if there is one in the host-meta and one in the
>> resource JRD is more like:
>> "links" :
>> {
>>      "rel" : "http://openid.net/specs/connect/issuer",
>>      "template" : "https://server.example.com"
>>    },
>> {
>>      "rel" : "http://openid.net/specs/connect/issuer",
>>      "href" : "https://server.example.com"
>>    }
>> }
>>=20
>> Is that correct?
>>=20
>> John B.
>>=20
>> On 2012-04-25, at 4:42 PM, Eran Hammer wrote:
>>=20
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>> Sent: Wednesday, April 25, 2012 12:00 PM
>>>> To: Eran Hammer
>>>> Cc: Paul E. Jones; apps-discuss@ietf.org
>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>>=20
>>>> OK so host-meta is one level of lrdd link processing for a resource =
(not
>> host).
>>>>=20
>>>> Multiple lrdd links are not precluded, but are an abuse.
>>>>=20
>>>> If you want to redirect to an alternate host-meta location you use =
3xx and
>>>> the client will follow.
>>>> (I heard some complaining about what if my site can't support =
redirects
>>>> earlier.)
>>>>=20
>>>> The links are aggregated with host-meta links and filtered by =
"rel".
>>>>=20
>>>> So if in host-meta I have:
>>>> {
>>>>      "rel" : "http://openid.net/specs/connect/issuer",
>>>>      "href" : "https://server.example.com"
>>>>    }
>>>>=20
>>>> before my lrdd entry
>>>=20
>>> Only if you change 'href' above to 'template'. 'href' are host-wide =
only and
>> do not apply to resource-specific.
>>>=20
>>> If you make a host-wide request, lrdd links and all templates are =
ignored.
>>> If you make a resource-specific request, all href links in host-meta =
are
>> ignored, templates expanded, and lrdd templates followed and included
>> inline.
>>>=20
>>> EH
>>>=20
>>>> That would be returned in the filtered list before any resource =
specific
>> "rel" ?
>>>>=20
>>>> Thus making a global setting for all resources.
>>>>=20
>>>> I don't think the original Connect proposal had per user discovery =
only per
>>>> host via host meta without following lrdd.
>>>>=20
>>>> If aggrigating and sorting links are a requirement, that needs to =
be done
>>>> server side for Connect clients.
>>>>=20
>>>> John B.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On 2012-04-25, at 3:29 PM, Eran Hammer wrote:
>>>>=20
>>>>>=20
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>>>> Sent: Wednesday, April 25, 2012 10:38 AM
>>>>>> To: Eran Hammer
>>>>>> Cc: Paul E. Jones; apps-discuss@ietf.org
>>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>>>>=20
>>>>>> Eran,
>>>>>>=20
>>>>>> It was unclear, at least to me that the server side host-meta =
processing
>>>> rule
>>>>>> specified in WF requires all the templates (or just the LRDD =
ones) to be
>>>>>> processed substituting inserting "resource" for URI and then =
retrieving
>>>> and
>>>>>> merging all the resource JRD before processing the filter on the =
"rel".
>>>>>>=20
>>>>>> If I defined a rel of FOO would WF fill the template and retrieve =
the JRD
>>>> and
>>>>>> merge its links with the lrdd JRD?
>>>>>> I might think that would be a touch confusing to clients.
>>>>>=20
>>>>> No. It only does *one* level of LRDD import (in order). See:
>>>>>=20
>>>>> http://tools.ietf.org/html/rfc6415#section-4.2
>>>>>=20
>>>>>> So I go back to the rational explanation that lrdd templates are
>> expanded
>>>> and
>>>>>> those links rolled up and filtered.
>>>>>>=20
>>>>>> Now I am guessing that some of the SWD people are thinking that
>> when
>>>> the
>>>>>> server is using flat files that puts a lot of burden onto the =
client.
>>>>>>=20
>>>>>> Probably why you added the server side processing.
>>>>>=20
>>>>> The idea of adding server-side processing and filtering via the =
query
>> came
>>>> out of the original OpenID Connect proposal that David Recordon and =
I
>>>> wrote, trying to keep the clients super simple and avoid the need =
to go
>> fetch
>>>> host-meta, then one or more LRDD documents.
>>>>>=20
>>>>> Complexity is very much implementation specific on the server =
side.
>> Yahoo
>>>> doesn't have LRDD documents and puts everything as link templates =
in
>> host-
>>>> meta while others like the ability to customize. The most likely =
scenario of
>>>> servers including LRDD links in host-meta is that the host-meta =
document
>> is
>>>> static, while the LRDD links are dynamically generated. Otherwise, =
there is
>>>> very little value in the added complexity. In that case, the client =
will
>> typically
>>>> be faced with 2 requests.
>>>>>=20
>>>>> I would argue that a server using multiple LRDD links in host-meta =
is
>> abusing
>>>> the system, very much like a server using multiple 3xx redirections
>> between
>>>> its initial host-meta endpoint to where the document actually =
lives.
>>>>>=20
>>>>> IOW, there are many ways to inflict pain on the client.
>>>>>=20
>>>>>> Given that WF takes the liberty of adding query parameters to =
host-
>> meta
>>>>>> and seems to define host-meta processing rules (perhaps for non
>> lrdd?), I
>>>>>> am not finding the separation of the two specs as clean as =
possible.
>>>>>> It seems a bit like there is there a RFC 6415 dependency on WF.
>> Though
>>>> that
>>>>>> is a touch strange for a RFC.
>>>>>=20
>>>>> The WF draft should not introduce any new processing rules. It =
should
>> only
>>>> add the query optimization but that must result in exactly the same =
set of
>>>> links as defined by 6415. If this is the case, it's a bug.
>>>>>=20
>>>>>> What stops someone from defining a relation of super-discovery =
and
>>>> adding
>>>>>> some query parameters to host-meta.json to hover up some lrdd
>> based
>>>> on a
>>>>>> template expansion of  "super-discovery" rel types, and filter on =
"rel"?
>>>>>>=20
>>>>>> I wouldn't have thought to do that because stepping on the RFC =
6415
>>>>>> endpoint seems slightly wrong to me.
>>>>>>=20
>>>>>> I would probably define a new endpoint =
/.well-known/super-discovery
>>>> with
>>>>>> my own query parameters and processing rules for JRD documents.
>>>>>=20
>>>>> That would be the right approach. Note that 6415 registers both =
host-
>> meta
>>>> (defaults to XML) and host-meta.json (JSON required).
>>>>>=20
>>>>>> Without being able to make server-side processing of host-meta
>>>> required,
>>>>>> we need someway to delegate that to another endpoint.
>>>>>>=20
>>>>>> In XRD we did discuss delegating the entire XRD.  Is there a way =
to do
>> that
>>>> in
>>>>>> host-meta?
>>>>>=20
>>>>> 3xx.
>>>>>=20
>>>>> EH
>>>>>=20
>>>>>> At the moment all of the processing gets pushed back on the =
client if
>> the
>>>>>> host only supports static files in /.well-known
>>>>>>=20
>>>>>> John B.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 2012-04-25, at 1:34 PM, Eran Hammer wrote:
>>>>>>=20
>>>>>>> It is important to understand the semantics of host-meta, which =
I
>> think
>>>>>> there is some confusion about here.
>>>>>>>=20
>>>>>>> As a mechanism, host-meta providers you with a method of =
obtaining
>>>> both
>>>>>> host-wide and resource-specific links (and properties). To =
accomplish
>>>> that, it
>>>>>> provides with both a document and processing rules.
>>>>>>>=20
>>>>>>> WebFinger - the name given for the host-meta *use-case* of
>> retrieving
>>>>>> user information - is a specialization of obtaining =
resource-specific links.
>>>>>>>=20
>>>>>>> The 'rel' and 'resource' query parameters (as proposed) apply to =
the
>>>>>> endpoint *after* executing the processing rules (which include
>> expanding
>>>>>> templates and importing links from one level LRDD documents).
>>>>>>>=20
>>>>>>> LRDD documents only apply to resource-specific links, which =
means
>> they
>>>>>> are ignored for any host-wide query. For example, the location of =
the
>>>> site's
>>>>>> TOS document. =46rom the host-meta perspective, LRDD documents =
are
>>>> just a
>>>>>> deployment tool to provide customization not possible using just =
link
>>>>>> templates at the host-meta document level. It's just a =
link-include
>>>>>> mechanism, and host-meta uses it restrictively.
>>>>>>>=20
>>>>>>> IMO, the 'rel' and 'resource' optimization should only apply to =
the
>> host-
>>>>>> meta endpoint, and act as a filter post the processing rules. If =
'resource'
>> is
>>>>>> specified, it is a resource-specific request, otherwise, =
host-wide.
>>>>>>>=20
>>>>>>> Let me know if this helps or if it is still unclear.
>>>>>>>=20
>>>>>>> EH
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>>>>>> Sent: Wednesday, April 25, 2012 8:27 AM
>>>>>>>> To: Eran Hammer
>>>>>>>> Cc: Paul E. Jones; apps-discuss@ietf.org
>>>>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>>>>>>=20
>>>>>>>> That was one thing that initially confused me.  The rel filter =
is not
>>>> applied
>>>>>> to
>>>>>>>> host-meta, but rather the linked lrdd resource JRD.
>>>>>>>>=20
>>>>>>>> The currently defined "resource" parameter has an implicit =
host-
>> meta
>>>>>> "rel"
>>>>>>>> of "lrdd".
>>>>>>>>=20
>>>>>>>> To use this mechanism for other relations you would need to =
make
>> that
>>>>>>>> parameter explicit.
>>>>>>>>=20
>>>>>>>> That then raises the question of the filter being part of =
host-meta or
>>>> WF if
>>>>>> it
>>>>>>>> applies to relationships other than lrdd.
>>>>>>>>=20
>>>>>>>> If you are asking if filtering should be supported by lrdd =
where you
>> start
>>>>>>>> discovery from a link header, then it probably should be =
possible as
>>>> well.
>>>>>>>>=20
>>>>>>>> Though I thought lrdd stopped being updated over a year a year =
ago.
>>>>>> Sorry if
>>>>>>>> I am out of date.
>>>>>>>>=20
>>>>>>>> So XRD/JRD documents SHOULD be filterable by "rel" independent
>> of if
>>>>>> you
>>>>>>>> get to them via lrdd or host-meta.
>>>>>>>>=20
>>>>>>>> Host-meta SHOULD support a mechanism to filter by "rel" or =
filter by
>> a
>>>>>>>> combination of "resource" (uri) , host-meta-rel and =
resource-rel (the
>>>>>> host-
>>>>>>>> meta-rel is currently implicit.)
>>>>>>>>=20
>>>>>>>> I recall discussing this in the XRI TC when we did XRD years =
ago,
>> though
>>>>>> that
>>>>>>>> was more around using XRI identifiers.
>>>>>>>>=20
>>>>>>>> The same principal still holds.  I should be able to ask for.
>>>>>>>> GET /.well-known/host-meta.json
>>>>>>>>  ?resource=3Djoe@example.com
>>>>>>>>  &host-meta-rel=3Dlrdd
>>>>>>>>=20
>>>>>>=20
>> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>>>>>>>> HTTP/1.1
>>>>>>>> Host: example.com
>>>>>>>>=20
>>>>>>>> (personally I think calling the parameter "resource" and the =
template
>>>> {uri}
>>>>>>>> will be confusing to people)
>>>>>>>>=20
>>>>>>>> In SWD we used fixed the parameter names and the base URI is =
the
>>>> part
>>>>>> that
>>>>>>>> gets changed when the /.well-known can't host a script.
>>>>>>>> That makes the template simpler for the client to process.  The
>>>> equivalent
>>>>>> to
>>>>>>>> "rel" is always passed to make processing simpler.
>>>>>>>>=20
>>>>>>>> As Blaine has pointed out several times SWD and WF largely get =
us to
>>>> the
>>>>>>>> same place.
>>>>>>>>=20
>>>>>>>> I am trying to find a way to close the gap.
>>>>>>>>=20
>>>>>>>> John B.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 2012-04-25, at 11:41 AM, Eran Hammer wrote:
>>>>>>>>=20
>>>>>>>>> Purely from a practical standpoint, do you think it is likely =
that a
>> server
>>>>>> will
>>>>>>>> support the query filter for the lrdd documents but not for =
host-
>> meta?
>>>>>>>>>=20
>>>>>>>>> EH
>>>>>>>>>=20
>>>>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>>>>>>>> bounces@ietf.org] On Behalf Of John Bradley
>>>>>>>>> Sent: Wednesday, April 25, 2012 6:17 AM
>>>>>>>>> To: Paul E. Jones
>>>>>>>>> Cc: apps-discuss@ietf.org
>>>>>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>>>>>>>=20
>>>>>>>>> Paul,
>>>>>>>>>=20
>>>>>>>>> "rel" as a filter is something WF has for host-meta.  It =
however
>> doesn't
>>>>>>>> seem to have that for user JRD in the case where host-meta is
>>>> returned,
>>>>>> and
>>>>>>>> the template is used.
>>>>>>>>>=20
>>>>>>>>> The "resource" and "rel" parameters are already an =
optimization
>> for
>>>>>> LRDD
>>>>>>>> and not part of host-meta.
>>>>>>>>> Adding LRDD specific parameters to host-meta/host-meta.json =
will
>>>>>>>> probably raise some eyebrows in review, but I am OK with it.
>>>>>>>>>=20
>>>>>>>>> I think there are use cases where size matters.  Where a =
host-meta
>> or
>>>>>>>> resource JRD may be large and it is more efficient not to send =
the
>>>> whole
>>>>>>>> thing to a mobile client.
>>>>>>>>> It seems to be one of Mike Jones requirements.
>>>>>>>>>=20
>>>>>>>>> Using RFC6570 for LRDD is a possibility for passing through =
the filter
>>>>>> request
>>>>>>>> for sites that support filtering on resource JRD.
>>>>>>>>>=20
>>>>>>>>> What other proposals do you have.  I am guessing that =
filtering on
>>>>>> resource
>>>>>>>> JRD is not a totally new topic.
>>>>>>>>>=20
>>>>>>>>> LRDD is the one really doing the optimization  in any event,  =
it may
>> be
>>>>>> done
>>>>>>>> at the host-meta GET but it is a LRDD specific extension.
>>>>>>>>> Having it in the template allows LRDD to filter at the =
resource JRD in
>>>>>> cases
>>>>>>>> where it is not possible to do it at the host-meta level, due =
to some
>> no
>>>>>> script
>>>>>>>> or other restriction.
>>>>>>>>>=20
>>>>>>>>> I agree that it should be filtered at the how-meta request but =
you
>> and
>>>>>>>> others say that is not always possible.
>>>>>>>>>=20
>>>>>>>>> John B.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> John,
>>>>>>>>>=20
>>>>>>>>> The "rel" parameter is something we still need to discuss, so =
not is
>> as
>>>>>> good
>>>>>>>> a time as any.
>>>>>>>>>=20
>>>>>>>>> What "rel" does is act as a filter.  For the most part, the =
only
>> purpose it
>>>>>>>> serves is to help reduce the number of link relations that =
might be
>> sent
>>>>>> from
>>>>>>>> the server.  So, if a user had 1,000 different link relations, =
this might
>>>>>> reduce
>>>>>>>> the returned message to containing only 1.  However, if a user =
has
>>>> more
>>>>>> than
>>>>>>>> one link relation of the same type, all of them would match and =
be
>>>>>> returned.
>>>>>>>>>=20
>>>>>>>>> When you say the host cannot support re-write rules, I assume =
you
>>>>>> mean it
>>>>>>>> does not support the URI parameters on host-meta?  In that =
case,
>> yes,
>>>>>> the
>>>>>>>> parameters are ignored and you get just the host-meta document.
>>>>>>>>>=20
>>>>>>>>> The only URI template defined in RFC 6415 is "{uri}" (see =
3.1.1.1).
>>>> There
>>>>>> are
>>>>>>>> no other URI template values defined.  (Note: this whole =
section
>> exists
>>>>>> only
>>>>>>>> because RFC  6570 did not yet exist, I think.
>>>>>>>>>=20
>>>>>>>>> In any case, we could define a new URI template, but then we
>> would
>>>> be
>>>>>>>> putting an optimization in place for LRDD.  If host-meta is not =
going
>> to
>>>>>>>> support the "rel" URI parameter, why would LRDD?  It would also
>> mean
>>>>>> that
>>>>>>>> the LRDD logic would have to be ready to receive a URI =
parameter
>> that
>>>> is
>>>>>> not
>>>>>>>> replaced, since some clients would only change {uri} and leave =
{rel}
>>>> there.
>>>>>>>> That would introduce more conditional logic in the server.  =
This
>> would
>>>> also
>>>>>>>> present issues with static sites.  (Of course, one might be =
able to use
>>>>>> Apache
>>>>>>>> re-writing rules to get around that problem, but it certainly =
would
>> not
>>>>>> work
>>>>>>>> for "real" static sites.)
>>>>>>>>>=20
>>>>>>>>> Personally,  I'd prefer to not add the "rel" parameter to =
LRDD, since
>> I
>>>>>> think
>>>>>>>> optimization using "rel" would always be done on host-meta.  =
That
>> said,
>>>> I
>>>>>>>> question the value of "rel" entirely.  Do you think it's useful =
to have
>> this
>>>>>> filter
>>>>>>>> at all?  Is there really a risk that a site might return 1,000 =
link relations
>>>> that
>>>>>> the
>>>>>>>> client would have to step over?
>>>>>>>>>=20
>>>>>>>>> Paul
>>>>>>>>>=20
>>>>>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>>>>>>> Sent: Tuesday, April 24, 2012 10:17 PM
>>>>>>>>> To: Paul E. Jones
>>>>>>>>> Cc: apps-discuss@ietf.org
>>>>>>>>> Subject: WF flow with rel parameter
>>>>>>>>>=20
>>>>>>>>> Paul,
>>>>>>>>>=20
>>>>>>>>> Sorry I hit send on the previous message with a typo.
>>>>>>>>>=20
>>>>>>>>> I am looking at how the flows in WF might work for openID.
>>>>>>>>>=20
>>>>>>>>> Let's set aside the XML issue for the moment and focus on the
>> JSON
>>>>>> flow.
>>>>>>>>>=20
>>>>>>>>> Please correct anything I get wrong.
>>>>>>>>>=20
>>>>>>>>> The openID Connect defines a relation of
>>>>>>>> http://openid.net/specs/connect/issuer
>>>>>>>>>=20
>>>>>>>>> WF allows for a JSON host-meta that takes two parameters,
>>>> "resource"
>>>>>> and
>>>>>>>> "rel"
>>>>>>>>>=20
>>>>>>>>> An example request and response (line-brakes for readability)
>>>>>>>>>=20
>>>>>>>>> GET /.well-known/host-meta.json
>>>>>>>>>  ?resource=3Djoe@example.com
>>>>>>>>>=20
>>>>>>=20
>> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>>>>>>>> HTTP/1.1
>>>>>>>>> Host: example.com
>>>>>>>>>=20
>>>>>>>>> HTTP/1.1 200 OK
>>>>>>>>>=20
>>>>>>>>> Access-Control-Allow-Origin: *
>>>>>>>>> Content-Type: application/json; charset=3DUTF-8
>>>>>>>>>=20
>>>>>>>>> {
>>>>>>>>>  "subject" : "joe@example.com",
>>>>>>>>>  "links" :
>>>>>>>>>  [
>>>>>>>>>    {
>>>>>>>>>      "rel" : "http://openid.net/specs/connect/issuer",
>>>>>>>>>      "href" : "https://server.example.com"
>>>>>>>>>    }
>>>>>>>>>  ]
>>>>>>>>> }
>>>>>>>>>=20
>>>>>>>>> If the host can't support rewrite rules or scripts the =
exchange
>> would
>>>> look
>>>>>>>> like:
>>>>>>>>>=20
>>>>>>>>> GET /.well-known/host-meta.json
>>>>>>>>>  ?resource=3Djoe@example.com
>>>>>>>>>=20
>>>>>>=20
>> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>>>>>>>> HTTP/1.1
>>>>>>>>> Host: example.com
>>>>>>>>>=20
>>>>>>>>> HTTP/1.1 200 OK
>>>>>>>>> Access-Control-Allow-Origin: *
>>>>>>>>> Content-Type: application/json; charset=3DUTF-8
>>>>>>>>> {
>>>>>>>>>  "expires" : "2012-03-13T20:56:11Z",
>>>>>>>>>  "links" :
>>>>>>>>>  [
>>>>>>>>>    {
>>>>>>>>>      "rel" : "lrdd",
>>>>>>>>>      "type" : "application/json",
>>>>>>>>>      "template" :
>>>>>>>>>        "https://example.com/lrdd/?format=3Djson&resource=3D{uri}=
"
>>>>>>>>>    }
>>>>>>>>>=20
>>>>>>>>> GET /lrdd/
>>>>>>>>>  ?format=3Djson
>>>>>>>>>  &resource=3Djoe@example.com
>>>>>>>>> Host: example.com
>>>>>>>>>=20
>>>>>>>>> HTTP/1.1 200 OK
>>>>>>>>>=20
>>>>>>>>> Access-Control-Allow-Origin: *
>>>>>>>>> Content-Type: application/json; charset=3DUTF-8
>>>>>>>>>=20
>>>>>>>>> {
>>>>>>>>>  "subject" : "joe@example.com",
>>>>>>>>>  "links" :
>>>>>>>>>  [
>>>>>>>>>    {
>>>>>>>>>      "rel" : "http://openid.net/specs/connect/issuer",
>>>>>>>>>      "href" : "https://server.example.com"
>>>>>>>>>    },
>>>>>>>>>    {
>>>>>>>>>      "rel" : "http://webfinger.net/rel/avatar",
>>>>>>>>>      "href" : "http://example.com/~joe/joe.jpg"
>>>>>>>>>    }
>>>>>>>>>=20
>>>>>>>>>  ]
>>>>>>>>> }
>>>>>>>>>=20
>>>>>>>>> I can't find a template parameter for "rel".  The host-meta =
spec
>> allows
>>>>>> for
>>>>>>>> extension but it is missing.
>>>>>>>>>=20
>>>>>>>>> What if the server wants to support filtering on rel but can't
>> support it
>>>> in
>>>>>>>> the root for some reason?
>>>>>>>>>=20
>>>>>>>>> Is it possible to have a template like:
>>>>>>>>>=20
>> "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}"
>>>>>>>>>=20
>>>>>>>>> That simple addition may solve a number of problems for =
openID.
>>>>>>>>>=20
>>>>>>>>> John B.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>=20
>>>>>=20
>>>=20
>=20


--Apple-Mail=_7BE170EC-C17F-438D-9B3B-F4DF7534A34C
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
NTIyNDcxOVowIwYJKoZIhvcNAQkEMRYEFJgotYgEoOCts7Yvnwz44tf3VjBDMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
ACn8UxV9df0it8Zc/xCjYLY+aTSqwRTDRA1EJ9miXM6siwtfA61FR814Uw7cs231lz1tMVl4r8PU
gwqB09F5bLs25Cq4Xid4yhwgDfm3y2bQPfIergWeM8Hv90hpbBQhmtaJLzK2sR7gpTMoEkyzgUa8
JosjvNPijm3Gf0Ib7xZNYqzj5/qcJRHy5YNtrASowkdpMztbryAs5yR+EqK39g2QjDEVPDktVP5k
Lr5OgioarzDNv4CDv/4ooN8vnkBf8jMT3yeHtAokigSyur7Fy6bt9Yv+hYeJJYroc8M8IWaIECHu
7QnX/Hsl5vuO9B+cI3JiqNTTAi2A52Ekz4Uc9S4AAAAAAAA=

--Apple-Mail=_7BE170EC-C17F-438D-9B3B-F4DF7534A34C--

From eran@hueniverse.com  Wed Apr 25 15:56: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 1C2CF21E8051 for ; Wed, 25 Apr 2012 15:56:06 -0700 (PDT)
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=[AWL=-0.337, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_44=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzdHByYLzhYk for ; Wed, 25 Apr 2012 15:56:04 -0700 (PDT)
Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id 720F321E804D for ; Wed, 25 Apr 2012 15:56:04 -0700 (PDT)
Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id 2Nw41j0020EuLVk01Nw4Qi; Wed, 25 Apr 2012 15:56:04 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Wed, 25 Apr 2012 15:56:04 -0700
From: Eran Hammer 
To: John Bradley 
Thread-Topic: [apps-discuss] WF flow with rel parameter
Thread-Index: AQHNIomKaCym1aAtdUm4KjKnInrNO5ard+qAgACDoID//6IRMIAAgkAA//+ZoSCAAIr5AP//lX+QABAztYAADUhqUP//qJcAgABmnVD//8X4AIAAdKhQ
Date: Wed, 25 Apr 2012 22:56:03 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20100B529@P3PWEX2MB008.ex2.secureserver.net>
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201007020@P3PWEX2MB008.ex2.secureserver.net> <515663DA-67BF-4367-9AD9-6E940424CBCD@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20100990A@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA201009E4D@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA20100AEA2@P3PWEX2MB008.ex2.secureserver.net> <1699AC2D-56DD-44F1-BA51-5E01CCA43E26@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20100B18C@P3PWEX2MB008.ex2.secureserver.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 22:56:06 -0000

> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Wednesday, April 25, 2012 3:47 PM
> To: Eran Hammer
> Cc: Paul E. Jones; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] WF flow with rel parameter
>=20
> Thanks,
>=20
> I think the example may be wrong though.
>=20
> Shouldn't  the response to:
> > GET /.well-known/host-
> meta.json?resource=3Dhttp://example.com/resource
>=20
> be:
> > {
> >  "links":[
> >    {
> >      "rel":"example",
> >      "href":"http://example.com/3"
> >    },
> >    {
> >      "rel":"example",
> >      "href":"http://example.com/2"
> >    }
> >  ]
> > }

Yes, sorry. I was on a conference call and got distracted.

> What bit of magic logic turns the template to a href in the response?   I=
 would
> not have guessed that, part of my confusion.

When you perform resource-specific discovery, you apply the resource URI to=
 the templates. In this example, the template in host-meta just doesn't hav=
e any variables.

> So "template" gets expanded and  converted to href in the host-meta along
> with the "subject" becoming a canonical synonym for "resource"?
>=20
> The "subject" value indicating that host side processing succeeded?

This is part of the WF extension which I have not synced up on the recent d=
raft. I think that's correct.

> I feel like I am closer to understanding,  though perhaps farther away on
> convincing people of WF's simplicity for clients.

The complexity comes from requirements in the original work:

1. Ability to represent data in static files / documents
2. Ability to define the order of links between the generic host-meta to th=
e specific lrdd documents

We debated whether we should allow multiple lrdd documents, as well as if w=
e should always process lrdd documents at the end. There are ways to simpli=
fy the processing rules (which are really pretty short and simple if you fo=
llow the specification and not try to reverse engineer the examples), but e=
very simplification comes at reduced functionality.

The biggest difficulty is to decide what are the real requirements. Since t=
his is a very generic discovery framework, everyone has an opinion and ther=
e isn't a clear answer that will make everyone happy.

EH

=20
> John B.
>=20
>=20
> On 2012-04-25, at 6:11 PM, Eran Hammer wrote:
>=20
> > If your host-meta is:
> >
> > {
> >  "links":[
> >    {
> >      "rel":"example",
> >      "href":"http://example.com/1"
> >    },
> >    {
> >      "rel":"lrdd",
> >      "template":"http://example.com/lrdd?resource=3D{uri}"
> >    },
> >    {
> >      "rel":"example",
> >      "template":"http://example.com/2"
> >    }
> >  ]
> > }
> >
> > And your LRDD document always return:
> >
> > {
> >  "links":[
> >    {
> >      "rel":"example",
> >      "template":"http://example.com/3"
> >    }
> >  ]
> > }
> >
> > Then a host-wide request:
> >
> > GET /.well-known/host-meta.json?rel=3Dexample
> >
> > Will return (I haven't checked the exact format of the latest draft so =
the
> syntax might be wrong here):
> >
> > {
> >  "links":[
> >    {
> >      "rel":"example",
> >      "href":"http://example.com/1"
> >    }
> >  ]
> > }
> >
> > And a resource-specific request (not escaped for readability):
> >
> > GET /.well-known/host-
> meta.json?resource=3Dhttp://example.com/resource
> >
> > Will return:
> >
> > {
> >  "links":[
> >    {
> >      "rel":"example",
> >      "href":"http://example.com/1"
> >    },
> >    {
> >      "rel":"example",
> >      "href":"http://example.com/2"
> >    }
> >  ]
> > }
> >
> > Does this help?
> >
> > EH
> >
> >> -----Original Message-----
> >> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >> Sent: Wednesday, April 25, 2012 1:08 PM
> >> To: Eran Hammer
> >> Cc: Paul E. Jones; apps-discuss@ietf.org
> >> Subject: Re: [apps-discuss] WF flow with rel parameter
> >>
> >> So the merged output if there is one in the host-meta and one in the
> >> resource JRD is more like:
> >> "links" :
> >> {
> >>      "rel" : "http://openid.net/specs/connect/issuer",
> >>      "template" : "https://server.example.com"
> >>    },
> >> {
> >>      "rel" : "http://openid.net/specs/connect/issuer",
> >>      "href" : "https://server.example.com"
> >>    }
> >> }
> >>
> >> Is that correct?
> >>
> >> John B.
> >>
> >> On 2012-04-25, at 4:42 PM, Eran Hammer wrote:
> >>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >>>> Sent: Wednesday, April 25, 2012 12:00 PM
> >>>> To: Eran Hammer
> >>>> Cc: Paul E. Jones; apps-discuss@ietf.org
> >>>> Subject: Re: [apps-discuss] WF flow with rel parameter
> >>>>
> >>>> OK so host-meta is one level of lrdd link processing for a resource =
(not
> >> host).
> >>>>
> >>>> Multiple lrdd links are not precluded, but are an abuse.
> >>>>
> >>>> If you want to redirect to an alternate host-meta location you use 3=
xx
> and
> >>>> the client will follow.
> >>>> (I heard some complaining about what if my site can't support redire=
cts
> >>>> earlier.)
> >>>>
> >>>> The links are aggregated with host-meta links and filtered by "rel".
> >>>>
> >>>> So if in host-meta I have:
> >>>> {
> >>>>      "rel" : "http://openid.net/specs/connect/issuer",
> >>>>      "href" : "https://server.example.com"
> >>>>    }
> >>>>
> >>>> before my lrdd entry
> >>>
> >>> Only if you change 'href' above to 'template'. 'href' are host-wide o=
nly
> and
> >> do not apply to resource-specific.
> >>>
> >>> If you make a host-wide request, lrdd links and all templates are ign=
ored.
> >>> If you make a resource-specific request, all href links in host-meta =
are
> >> ignored, templates expanded, and lrdd templates followed and included
> >> inline.
> >>>
> >>> EH
> >>>
> >>>> That would be returned in the filtered list before any resource spec=
ific
> >> "rel" ?
> >>>>
> >>>> Thus making a global setting for all resources.
> >>>>
> >>>> I don't think the original Connect proposal had per user discovery o=
nly
> per
> >>>> host via host meta without following lrdd.
> >>>>
> >>>> If aggrigating and sorting links are a requirement, that needs to be
> done
> >>>> server side for Connect clients.
> >>>>
> >>>> John B.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 2012-04-25, at 3:29 PM, Eran Hammer wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >>>>>> Sent: Wednesday, April 25, 2012 10:38 AM
> >>>>>> To: Eran Hammer
> >>>>>> Cc: Paul E. Jones; apps-discuss@ietf.org
> >>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
> >>>>>>
> >>>>>> Eran,
> >>>>>>
> >>>>>> It was unclear, at least to me that the server side host-meta
> processing
> >>>> rule
> >>>>>> specified in WF requires all the templates (or just the LRDD ones)=
 to
> be
> >>>>>> processed substituting inserting "resource" for URI and then
> retrieving
> >>>> and
> >>>>>> merging all the resource JRD before processing the filter on the "=
rel".
> >>>>>>
> >>>>>> If I defined a rel of FOO would WF fill the template and retrieve =
the
> JRD
> >>>> and
> >>>>>> merge its links with the lrdd JRD?
> >>>>>> I might think that would be a touch confusing to clients.
> >>>>>
> >>>>> No. It only does *one* level of LRDD import (in order). See:
> >>>>>
> >>>>> http://tools.ietf.org/html/rfc6415#section-4.2
> >>>>>
> >>>>>> So I go back to the rational explanation that lrdd templates are
> >> expanded
> >>>> and
> >>>>>> those links rolled up and filtered.
> >>>>>>
> >>>>>> Now I am guessing that some of the SWD people are thinking that
> >> when
> >>>> the
> >>>>>> server is using flat files that puts a lot of burden onto the clie=
nt.
> >>>>>>
> >>>>>> Probably why you added the server side processing.
> >>>>>
> >>>>> The idea of adding server-side processing and filtering via the que=
ry
> >> came
> >>>> out of the original OpenID Connect proposal that David Recordon and =
I
> >>>> wrote, trying to keep the clients super simple and avoid the need to=
 go
> >> fetch
> >>>> host-meta, then one or more LRDD documents.
> >>>>>
> >>>>> Complexity is very much implementation specific on the server side.
> >> Yahoo
> >>>> doesn't have LRDD documents and puts everything as link templates in
> >> host-
> >>>> meta while others like the ability to customize. The most likely sce=
nario
> of
> >>>> servers including LRDD links in host-meta is that the host-meta
> document
> >> is
> >>>> static, while the LRDD links are dynamically generated. Otherwise,
> there is
> >>>> very little value in the added complexity. In that case, the client =
will
> >> typically
> >>>> be faced with 2 requests.
> >>>>>
> >>>>> I would argue that a server using multiple LRDD links in host-meta =
is
> >> abusing
> >>>> the system, very much like a server using multiple 3xx redirections
> >> between
> >>>> its initial host-meta endpoint to where the document actually lives.
> >>>>>
> >>>>> IOW, there are many ways to inflict pain on the client.
> >>>>>
> >>>>>> Given that WF takes the liberty of adding query parameters to host=
-
> >> meta
> >>>>>> and seems to define host-meta processing rules (perhaps for non
> >> lrdd?), I
> >>>>>> am not finding the separation of the two specs as clean as possibl=
e.
> >>>>>> It seems a bit like there is there a RFC 6415 dependency on WF.
> >> Though
> >>>> that
> >>>>>> is a touch strange for a RFC.
> >>>>>
> >>>>> The WF draft should not introduce any new processing rules. It shou=
ld
> >> only
> >>>> add the query optimization but that must result in exactly the same =
set
> of
> >>>> links as defined by 6415. If this is the case, it's a bug.
> >>>>>
> >>>>>> What stops someone from defining a relation of super-discovery and
> >>>> adding
> >>>>>> some query parameters to host-meta.json to hover up some lrdd
> >> based
> >>>> on a
> >>>>>> template expansion of  "super-discovery" rel types, and filter on
> "rel"?
> >>>>>>
> >>>>>> I wouldn't have thought to do that because stepping on the RFC 641=
5
> >>>>>> endpoint seems slightly wrong to me.
> >>>>>>
> >>>>>> I would probably define a new endpoint /.well-known/super-
> discovery
> >>>> with
> >>>>>> my own query parameters and processing rules for JRD documents.
> >>>>>
> >>>>> That would be the right approach. Note that 6415 registers both hos=
t-
> >> meta
> >>>> (defaults to XML) and host-meta.json (JSON required).
> >>>>>
> >>>>>> Without being able to make server-side processing of host-meta
> >>>> required,
> >>>>>> we need someway to delegate that to another endpoint.
> >>>>>>
> >>>>>> In XRD we did discuss delegating the entire XRD.  Is there a way t=
o do
> >> that
> >>>> in
> >>>>>> host-meta?
> >>>>>
> >>>>> 3xx.
> >>>>>
> >>>>> EH
> >>>>>
> >>>>>> At the moment all of the processing gets pushed back on the client=
 if
> >> the
> >>>>>> host only supports static files in /.well-known
> >>>>>>
> >>>>>> John B.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 2012-04-25, at 1:34 PM, Eran Hammer wrote:
> >>>>>>
> >>>>>>> It is important to understand the semantics of host-meta, which I
> >> think
> >>>>>> there is some confusion about here.
> >>>>>>>
> >>>>>>> As a mechanism, host-meta providers you with a method of
> obtaining
> >>>> both
> >>>>>> host-wide and resource-specific links (and properties). To
> accomplish
> >>>> that, it
> >>>>>> provides with both a document and processing rules.
> >>>>>>>
> >>>>>>> WebFinger - the name given for the host-meta *use-case* of
> >> retrieving
> >>>>>> user information - is a specialization of obtaining resource-speci=
fic
> links.
> >>>>>>>
> >>>>>>> The 'rel' and 'resource' query parameters (as proposed) apply to
> the
> >>>>>> endpoint *after* executing the processing rules (which include
> >> expanding
> >>>>>> templates and importing links from one level LRDD documents).
> >>>>>>>
> >>>>>>> LRDD documents only apply to resource-specific links, which means
> >> they
> >>>>>> are ignored for any host-wide query. For example, the location of
> the
> >>>> site's
> >>>>>> TOS document. From the host-meta perspective, LRDD documents
> are
> >>>> just a
> >>>>>> deployment tool to provide customization not possible using just l=
ink
> >>>>>> templates at the host-meta document level. It's just a link-includ=
e
> >>>>>> mechanism, and host-meta uses it restrictively.
> >>>>>>>
> >>>>>>> IMO, the 'rel' and 'resource' optimization should only apply to t=
he
> >> host-
> >>>>>> meta endpoint, and act as a filter post the processing rules. If
> 'resource'
> >> is
> >>>>>> specified, it is a resource-specific request, otherwise, host-wide=
.
> >>>>>>>
> >>>>>>> Let me know if this helps or if it is still unclear.
> >>>>>>>
> >>>>>>> EH
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >>>>>>>> Sent: Wednesday, April 25, 2012 8:27 AM
> >>>>>>>> To: Eran Hammer
> >>>>>>>> Cc: Paul E. Jones; apps-discuss@ietf.org
> >>>>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
> >>>>>>>>
> >>>>>>>> That was one thing that initially confused me.  The rel filter i=
s not
> >>>> applied
> >>>>>> to
> >>>>>>>> host-meta, but rather the linked lrdd resource JRD.
> >>>>>>>>
> >>>>>>>> The currently defined "resource" parameter has an implicit host-
> >> meta
> >>>>>> "rel"
> >>>>>>>> of "lrdd".
> >>>>>>>>
> >>>>>>>> To use this mechanism for other relations you would need to
> make
> >> that
> >>>>>>>> parameter explicit.
> >>>>>>>>
> >>>>>>>> That then raises the question of the filter being part of host-m=
eta
> or
> >>>> WF if
> >>>>>> it
> >>>>>>>> applies to relationships other than lrdd.
> >>>>>>>>
> >>>>>>>> If you are asking if filtering should be supported by lrdd where
> you
> >> start
> >>>>>>>> discovery from a link header, then it probably should be possibl=
e
> as
> >>>> well.
> >>>>>>>>
> >>>>>>>> Though I thought lrdd stopped being updated over a year a year
> ago.
> >>>>>> Sorry if
> >>>>>>>> I am out of date.
> >>>>>>>>
> >>>>>>>> So XRD/JRD documents SHOULD be filterable by "rel"
> independent
> >> of if
> >>>>>> you
> >>>>>>>> get to them via lrdd or host-meta.
> >>>>>>>>
> >>>>>>>> Host-meta SHOULD support a mechanism to filter by "rel" or filte=
r
> by
> >> a
> >>>>>>>> combination of "resource" (uri) , host-meta-rel and resource-rel
> (the
> >>>>>> host-
> >>>>>>>> meta-rel is currently implicit.)
> >>>>>>>>
> >>>>>>>> I recall discussing this in the XRI TC when we did XRD years ago=
,
> >> though
> >>>>>> that
> >>>>>>>> was more around using XRI identifiers.
> >>>>>>>>
> >>>>>>>> The same principal still holds.  I should be able to ask for.
> >>>>>>>> GET /.well-known/host-meta.json
> >>>>>>>>  ?resource=3Djoe@example.com
> >>>>>>>>  &host-meta-rel=3Dlrdd
> >>>>>>>>
> >>>>>>
> >> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> >>>>>>>> HTTP/1.1
> >>>>>>>> Host: example.com
> >>>>>>>>
> >>>>>>>> (personally I think calling the parameter "resource" and the
> template
> >>>> {uri}
> >>>>>>>> will be confusing to people)
> >>>>>>>>
> >>>>>>>> In SWD we used fixed the parameter names and the base URI is
> the
> >>>> part
> >>>>>> that
> >>>>>>>> gets changed when the /.well-known can't host a script.
> >>>>>>>> That makes the template simpler for the client to process.  The
> >>>> equivalent
> >>>>>> to
> >>>>>>>> "rel" is always passed to make processing simpler.
> >>>>>>>>
> >>>>>>>> As Blaine has pointed out several times SWD and WF largely get u=
s
> to
> >>>> the
> >>>>>>>> same place.
> >>>>>>>>
> >>>>>>>> I am trying to find a way to close the gap.
> >>>>>>>>
> >>>>>>>> John B.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 2012-04-25, at 11:41 AM, Eran Hammer wrote:
> >>>>>>>>
> >>>>>>>>> Purely from a practical standpoint, do you think it is likely t=
hat a
> >> server
> >>>>>> will
> >>>>>>>> support the query filter for the lrdd documents but not for host=
-
> >> meta?
> >>>>>>>>>
> >>>>>>>>> EH
> >>>>>>>>>
> >>>>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> >>>>>>>> bounces@ietf.org] On Behalf Of John Bradley
> >>>>>>>>> Sent: Wednesday, April 25, 2012 6:17 AM
> >>>>>>>>> To: Paul E. Jones
> >>>>>>>>> Cc: apps-discuss@ietf.org
> >>>>>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
> >>>>>>>>>
> >>>>>>>>> Paul,
> >>>>>>>>>
> >>>>>>>>> "rel" as a filter is something WF has for host-meta.  It howeve=
r
> >> doesn't
> >>>>>>>> seem to have that for user JRD in the case where host-meta is
> >>>> returned,
> >>>>>> and
> >>>>>>>> the template is used.
> >>>>>>>>>
> >>>>>>>>> The "resource" and "rel" parameters are already an optimization
> >> for
> >>>>>> LRDD
> >>>>>>>> and not part of host-meta.
> >>>>>>>>> Adding LRDD specific parameters to host-meta/host-meta.json
> will
> >>>>>>>> probably raise some eyebrows in review, but I am OK with it.
> >>>>>>>>>
> >>>>>>>>> I think there are use cases where size matters.  Where a host-
> meta
> >> or
> >>>>>>>> resource JRD may be large and it is more efficient not to send t=
he
> >>>> whole
> >>>>>>>> thing to a mobile client.
> >>>>>>>>> It seems to be one of Mike Jones requirements.
> >>>>>>>>>
> >>>>>>>>> Using RFC6570 for LRDD is a possibility for passing through the
> filter
> >>>>>> request
> >>>>>>>> for sites that support filtering on resource JRD.
> >>>>>>>>>
> >>>>>>>>> What other proposals do you have.  I am guessing that filtering
> on
> >>>>>> resource
> >>>>>>>> JRD is not a totally new topic.
> >>>>>>>>>
> >>>>>>>>> LRDD is the one really doing the optimization  in any event,  i=
t
> may
> >> be
> >>>>>> done
> >>>>>>>> at the host-meta GET but it is a LRDD specific extension.
> >>>>>>>>> Having it in the template allows LRDD to filter at the resource=
 JRD
> in
> >>>>>> cases
> >>>>>>>> where it is not possible to do it at the host-meta level, due to
> some
> >> no
> >>>>>> script
> >>>>>>>> or other restriction.
> >>>>>>>>>
> >>>>>>>>> I agree that it should be filtered at the how-meta request but
> you
> >> and
> >>>>>>>> others say that is not always possible.
> >>>>>>>>>
> >>>>>>>>> John B.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> John,
> >>>>>>>>>
> >>>>>>>>> The "rel" parameter is something we still need to discuss, so n=
ot
> is
> >> as
> >>>>>> good
> >>>>>>>> a time as any.
> >>>>>>>>>
> >>>>>>>>> What "rel" does is act as a filter.  For the most part, the onl=
y
> >> purpose it
> >>>>>>>> serves is to help reduce the number of link relations that might=
 be
> >> sent
> >>>>>> from
> >>>>>>>> the server.  So, if a user had 1,000 different link relations, t=
his
> might
> >>>>>> reduce
> >>>>>>>> the returned message to containing only 1.  However, if a user h=
as
> >>>> more
> >>>>>> than
> >>>>>>>> one link relation of the same type, all of them would match and
> be
> >>>>>> returned.
> >>>>>>>>>
> >>>>>>>>> When you say the host cannot support re-write rules, I assume
> you
> >>>>>> mean it
> >>>>>>>> does not support the URI parameters on host-meta?  In that case,
> >> yes,
> >>>>>> the
> >>>>>>>> parameters are ignored and you get just the host-meta
> document.
> >>>>>>>>>
> >>>>>>>>> The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1=
.1).
> >>>> There
> >>>>>> are
> >>>>>>>> no other URI template values defined.  (Note: this whole section
> >> exists
> >>>>>> only
> >>>>>>>> because RFC  6570 did not yet exist, I think.
> >>>>>>>>>
> >>>>>>>>> In any case, we could define a new URI template, but then we
> >> would
> >>>> be
> >>>>>>>> putting an optimization in place for LRDD.  If host-meta is not
> going
> >> to
> >>>>>>>> support the "rel" URI parameter, why would LRDD?  It would also
> >> mean
> >>>>>> that
> >>>>>>>> the LRDD logic would have to be ready to receive a URI parameter
> >> that
> >>>> is
> >>>>>> not
> >>>>>>>> replaced, since some clients would only change {uri} and leave
> {rel}
> >>>> there.
> >>>>>>>> That would introduce more conditional logic in the server.  This
> >> would
> >>>> also
> >>>>>>>> present issues with static sites.  (Of course, one might be able=
 to
> use
> >>>>>> Apache
> >>>>>>>> re-writing rules to get around that problem, but it certainly wo=
uld
> >> not
> >>>>>> work
> >>>>>>>> for "real" static sites.)
> >>>>>>>>>
> >>>>>>>>> Personally,  I'd prefer to not add the "rel" parameter to LRDD,
> since
> >> I
> >>>>>> think
> >>>>>>>> optimization using "rel" would always be done on host-meta.
> That
> >> said,
> >>>> I
> >>>>>>>> question the value of "rel" entirely.  Do you think it's useful =
to
> have
> >> this
> >>>>>> filter
> >>>>>>>> at all?  Is there really a risk that a site might return 1,000 l=
ink
> relations
> >>>> that
> >>>>>> the
> >>>>>>>> client would have to step over?
> >>>>>>>>>
> >>>>>>>>> Paul
> >>>>>>>>>
> >>>>>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >>>>>>>>> Sent: Tuesday, April 24, 2012 10:17 PM
> >>>>>>>>> To: Paul E. Jones
> >>>>>>>>> Cc: apps-discuss@ietf.org
> >>>>>>>>> Subject: WF flow with rel parameter
> >>>>>>>>>
> >>>>>>>>> Paul,
> >>>>>>>>>
> >>>>>>>>> Sorry I hit send on the previous message with a typo.
> >>>>>>>>>
> >>>>>>>>> I am looking at how the flows in WF might work for openID.
> >>>>>>>>>
> >>>>>>>>> Let's set aside the XML issue for the moment and focus on the
> >> JSON
> >>>>>> flow.
> >>>>>>>>>
> >>>>>>>>> Please correct anything I get wrong.
> >>>>>>>>>
> >>>>>>>>> The openID Connect defines a relation of
> >>>>>>>> http://openid.net/specs/connect/issuer
> >>>>>>>>>
> >>>>>>>>> WF allows for a JSON host-meta that takes two parameters,
> >>>> "resource"
> >>>>>> and
> >>>>>>>> "rel"
> >>>>>>>>>
> >>>>>>>>> An example request and response (line-brakes for readability)
> >>>>>>>>>
> >>>>>>>>> GET /.well-known/host-meta.json
> >>>>>>>>>  ?resource=3Djoe@example.com
> >>>>>>>>>
> >>>>>>
> >> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> >>>>>>>> HTTP/1.1
> >>>>>>>>> Host: example.com
> >>>>>>>>>
> >>>>>>>>> HTTP/1.1 200 OK
> >>>>>>>>>
> >>>>>>>>> Access-Control-Allow-Origin: *
> >>>>>>>>> Content-Type: application/json; charset=3DUTF-8
> >>>>>>>>>
> >>>>>>>>> {
> >>>>>>>>>  "subject" : "joe@example.com",
> >>>>>>>>>  "links" :
> >>>>>>>>>  [
> >>>>>>>>>    {
> >>>>>>>>>      "rel" : "http://openid.net/specs/connect/issuer",
> >>>>>>>>>      "href" : "https://server.example.com"
> >>>>>>>>>    }
> >>>>>>>>>  ]
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> If the host can't support rewrite rules or scripts the exchange
> >> would
> >>>> look
> >>>>>>>> like:
> >>>>>>>>>
> >>>>>>>>> GET /.well-known/host-meta.json
> >>>>>>>>>  ?resource=3Djoe@example.com
> >>>>>>>>>
> >>>>>>
> >> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> >>>>>>>> HTTP/1.1
> >>>>>>>>> Host: example.com
> >>>>>>>>>
> >>>>>>>>> HTTP/1.1 200 OK
> >>>>>>>>> Access-Control-Allow-Origin: *
> >>>>>>>>> Content-Type: application/json; charset=3DUTF-8
> >>>>>>>>> {
> >>>>>>>>>  "expires" : "2012-03-13T20:56:11Z",
> >>>>>>>>>  "links" :
> >>>>>>>>>  [
> >>>>>>>>>    {
> >>>>>>>>>      "rel" : "lrdd",
> >>>>>>>>>      "type" : "application/json",
> >>>>>>>>>      "template" :
> >>>>>>>>>        "https://example.com/lrdd/?format=3Djson&resource=3D{uri=
}"
> >>>>>>>>>    }
> >>>>>>>>>
> >>>>>>>>> GET /lrdd/
> >>>>>>>>>  ?format=3Djson
> >>>>>>>>>  &resource=3Djoe@example.com
> >>>>>>>>> Host: example.com
> >>>>>>>>>
> >>>>>>>>> HTTP/1.1 200 OK
> >>>>>>>>>
> >>>>>>>>> Access-Control-Allow-Origin: *
> >>>>>>>>> Content-Type: application/json; charset=3DUTF-8
> >>>>>>>>>
> >>>>>>>>> {
> >>>>>>>>>  "subject" : "joe@example.com",
> >>>>>>>>>  "links" :
> >>>>>>>>>  [
> >>>>>>>>>    {
> >>>>>>>>>      "rel" : "http://openid.net/specs/connect/issuer",
> >>>>>>>>>      "href" : "https://server.example.com"
> >>>>>>>>>    },
> >>>>>>>>>    {
> >>>>>>>>>      "rel" : "http://webfinger.net/rel/avatar",
> >>>>>>>>>      "href" : "http://example.com/~joe/joe.jpg"
> >>>>>>>>>    }
> >>>>>>>>>
> >>>>>>>>>  ]
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> I can't find a template parameter for "rel".  The host-meta spe=
c
> >> allows
> >>>>>> for
> >>>>>>>> extension but it is missing.
> >>>>>>>>>
> >>>>>>>>> What if the server wants to support filtering on rel but can't
> >> support it
> >>>> in
> >>>>>>>> the root for some reason?
> >>>>>>>>>
> >>>>>>>>> Is it possible to have a template like:
> >>>>>>>>>
> >> "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}"
> >>>>>>>>>
> >>>>>>>>> That simple addition may solve a number of problems for
> openID.
> >>>>>>>>>
> >>>>>>>>> John B.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >


From eran@hueniverse.com  Wed Apr 25 16:01: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 4191421E8051 for ; Wed, 25 Apr 2012 16:01:39 -0700 (PDT)
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.042,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-n5wWsiAEIN for ; Wed, 25 Apr 2012 16:01:38 -0700 (PDT)
Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1258021E804D for ; Wed, 25 Apr 2012 16:01:38 -0700 (PDT)
Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id 2P1d1j0020Dcg9U01P1dTT; Wed, 25 Apr 2012 16:01:37 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Wed, 25 Apr 2012 16:01:37 -0700
From: Eran Hammer 
To: Mike Jones , Blaine Cook ,  "apps-discuss@ietf.org" 
Thread-Topic: [apps-discuss] Webfinger / SWD Issue #3: direct	versus indirect	discovery
Thread-Index: AQHNIzVdg2a00Y4ze0S4yK/nZ61jVpasJr0w
Date: Wed, 25 Apr 2012 23:01:36 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20100B53A@P3PWEX2MB008.ex2.secureserver.net>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com> <054901cd2311$87a24fb0$96e6ef10$@packetizer.com> <4CC716F1-F6A4-46CF-86FD-6636B1F84500@ve7jtb.com>  <4E1F6AAD24975D4BA5B168042967394366499664@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20100B46D@P3PWEX2MB008.ex2.secureserver.net>
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20100B46D@P3PWEX2MB008.ex2.secureserver.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA20100B53AP3PWEX2MB008ex2_"
MIME-Version: 1.0
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct	versus	indirect	discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 23:01:39 -0000

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA20100B53AP3PWEX2MB008ex2_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SeKAmWxsIGFkZCBvbmUgbW9yZSBvYnNlcnZhdGlvbi4NCg0KVGhyb3VnaG91dCB0aGlzIHdvcmss
IHRoZSBtYWluIGNoYWxsZW5nZSDigJMgOTUlIG9mIHRoZSBwcm9ibGVtIOKAkyBoYXMgYWx3YXlz
IGJlZW4gYWRvcHRpb24uIE1heWJlIGNvbXByb21pc2VzIHdlcmUgbWFkZSBhbG9uZyB0aGUgd2F5
IHRvIHdpbiB0aGUgc3VwcG9ydCBvZiBtYWpvciBwbGF5ZXJzLiBUaGUgcGFydCBwZW9wbGUgb24g
dGhpcyBsaXN0IGhhdmUgYSBoYXJkIHRpbWUgYWdyZWVpbmcgaXMgd2hhdCBpcyB0aGUgYmVzdCBz
b2x1dGlvbiB0aGF0IHdpbGwgbGVhZCB0byB0aGUgZmFzdGVzdCBhZG9wdGlvbiwgYW5kIHdobyBh
cmUgdGhlIG1vc3QgaW1wb3J0YW50IGVhcmx5IGFkb3B0ZXJzLg0KDQpJIGhhdmUgc3RvcHBlZCBj
aGltaW5nIGluIHdpdGggbXkgb3BpbmlvbnMgYW5kIHBvc2l0aW9ucyBiZWNhdXNlIEkgaGF2ZSBu
byBwbGFucyBpbiB0aGUgZm9yZXNlZWFibGUgZnV0dXJlIHRvIGltcGxlbWVudCB0aGlzIG9uIHRo
ZSBjbGllbnQgb3Igc2VydmVyLiBUaGVyZSBpcyBsaXR0bGUgdmFsdWUgaW4gYSBnZW5lcmljIGRp
c2NvdmVyeSBmcmFtZXdvcmsgdGhhdCBpcyBub3Qgd2lkZWx5IGFkb3B0ZWQuIFRoaXMgZGlzY3Vz
c2lvbiB3b3VsZCBiZSBtdWNoIG1vcmUgZWZmZWN0aXZlIGlmIGl0IHdhcyBoZWxkIGluIHByaXZh
dGUgYW1vbmcgYSBzZWxlY3QgZmV3IHdobyBjYW4gcXVpY2tseSBhZ3JlZSBvbiBzb21ldGhpbmcg
KnRoZXkqIGNhbiBhY3R1YWxseSBzaGlwIHRvIGdldCB0byBhIGNyaXRpY2FsIG1hc3MuIEJ1dCBv
ZiBjb3Vyc2UsIHRoaXMgaXMgbm90IGhvdyB0aGlzIGNvbW11bml0eSB3b3Jrcy4NCg0KVGhlIHRl
Y2huaWNhbCBkZXRhaWxzIGJlaW5nIGRlYmF0ZWQgaGVyZSBtYXR0ZXIsIGJ1dCBub3QgbXVjaC4g
RXZlcnl0aGluZyBzdWdnZXN0ZWQgc28gZmFyIHdpbGwgd29yayDigJMgaWYgZW5vdWdoIHBlb3Bs
ZSBhZG9wdCBpdC4NCg0KRUgNCg0KDQoNCkZyb206IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYu
b3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBF
cmFuIEhhbW1lcg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAxMiAzOjQ3IFBNDQpUbzog
TWlrZSBKb25lczsgQmxhaW5lIENvb2s7IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KU3ViamVjdDog
UmU6IFthcHBzLWRpc2N1c3NdIFdlYmZpbmdlciAvIFNXRCBJc3N1ZSAjMzogZGlyZWN0IHZlcnN1
cyBpbmRpcmVjdCBkaXNjb3ZlcnkNCg0KSSB3b3VsZCBhcmd1ZSB0aGF0IG11Y2ggb2YgdGhlIGNv
bmZ1c2lvbiBpcyBjb21pbmcgZnJvbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCBob3N0LW1ldGEgZnJv
bSBhIGZldyBleGFtcGxlcyByYXRoZXIgdGhhbiByZWFkIHRoZSAodmVyeSBzaG9ydCkgc3BlY2lm
aWNhdGlvbi4gVGhlcmUgaXMgdmFsdWUgaW4gYm90aCBwcm9wb3NhbHMgaW4gdGhhdCB0aGV5IHJl
cHJlc2VudCB2ZXJ5IGRpZmZlcmVudCB1c2UgY2FzZXMgYW5kIGRldmVsb3BtZW50IGV4cGVyaWVu
Y2UuDQoNCkkgYW0gbm90IGFkdm9jYXRpbmcgYW55IHBhcnRpY3VsYXIgZW5kIHJlc3VsdCBoZXJl
IOKAkyBJIGFtIGNvbmZpZGVudCBJIHdpbGwgbmV2ZXIgbmVlZCB0byBpbXBsZW1lbnQgYW55IG9m
IHRoaXMsIHNvIG15IHBhcnRpY2lwYXRpb24gaGVyZSBpcyBsaW1pdGVkIHRvIG9mZmVyaW5nIGNs
YXJpZmljYXRpb24gb24gaG9zdC1tZXRhIGFuZCByZXByZXNlbnRpbmcgYWJvdXQgNSB5ZWFycyBv
ZiBjb21tdW5pdHkgd29yayBJ4oCZdmUgYmVlbiBwYXJ0IG9mLg0KDQpFSA0KDQoNCkZyb206IGFw
cHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0Bp
ZXRmLm9yZz4gW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOltt
YWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgTWlrZSBK
b25lcw0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAxMiAzOjE0IFBNDQpUbzogQmxhaW5l
IENvb2s7IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3Jn
Pg0KU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFdlYmZpbmdlciAvIFNXRCBJc3N1ZSAjMzog
ZGlyZWN0IHZlcnN1cyBpbmRpcmVjdCBkaXNjb3ZlcnkNCg0KSSBhZ3JlZSB0aGF0IGlmIHdl4oCZ
cmUgY29uZnVzZWQgYWJvdXQgdGhlIGhvc3QtbWV0YSBwcm9jZXNzaW5nIHJ1bGVzLCBldGMuIGl0
4oCZcyBhIHNpZ24gdGhhdCB3ZeKAmXJlIG1ha2luZyB0aGluZ3MgdG9vIGhhcmQuICBJIGJlbGll
dmUgdGhlc2UgYXJlIGV4YWN0bHkgdGhlIGtpbmRzIG9mIHJlYXNvbnMgdGhhdCBsZWQgWWFyb24g
dG8gZGV2ZWxvcCBTaW1wbGUgV2ViIERpc2NvdmVyeS4NCg0KTWF5YmUgaXTigJlzIHRpbWUgZm9y
IHBlb3BsZSB0byByZXJlYWQgaHR0cDovL3d3dy5nb2xhbmQub3JnL3NpbXBsZXdlYmZpbmdlci8g
YW5kIGh0dHA6Ly93d3cuZ29sYW5kLm9yZy9tYW5hZ2luZ2ZpbmdlcnNlcnZpY2UvIChvciB0byBy
ZWFkIHRoZW0gZm9yIHRoZSBmaXJzdCB0aW1lKS4gIEkgc3VzcGVjdCB0aGUgcmVhc29uaW5nIGlu
IHRoZW0gd2lsbCByZXNvbmF0ZSBtb3JlIGluIHRoZSBjb250ZXh0IG9mIHRoZSBjdXJyZW50IGRp
c2N1c3Npb24sIGZvciB3aGF0IGl04oCZcyB3b3J0aOKApg0KDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNClAuUy4g
IFlvdSBjYW4gdGFrZSB0aGUgdmlld3BvaW50IHRoaXMgaXMgYWJvdXQgTWljcm9zb2Z0IGFuZCBH
b29nbGUgaWYgeW91IGxpa2UsIGJ1dCBpbiBteSBtaW5kLCB0aGlzIGlzIGFib3V0IHViaXF1aXRv
dXMgZGlzY292ZXJ5IGZvciB0aGUgb3BlbiBXZWIuDQoNCkZyb206IGFwcHMtZGlzY3Vzcy1ib3Vu
Y2VzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0
bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOlttYWlsdG86YXBwcy1kaXNj
dXNzLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgQmxhaW5lIENvb2sNClNlbnQ6IFdl
ZG5lc2RheSwgQXByaWwgMjUsIDIwMTIgMjo0NSBQTQ0KVG86IGFwcHMtZGlzY3Vzc0BpZXRmLm9y
ZzxtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFthcHBzLWRpc2N1
c3NdIFdlYmZpbmdlciAvIFNXRCBJc3N1ZSAjMzogZGlyZWN0IHZlcnN1cyBpbmRpcmVjdCBkaXNj
b3ZlcnkNCg0KKnNpZ2gqDQoNClRoaXMgaXMgY3JhenkuIFRoZXJlIGFyZSBhIGhhbGYtZG96ZW4g
b2YgdXMgZGViYXRpbmcgdGhlb3JldGljYWwgd2F5cyB0byBzdHJ1Y3R1cmUgYSB0aGluZyB0aGF0
IG1heSBvciBtYXkgbm90IGV2ZXIgZ2V0IHVzZWQsIHNvIHRoYXQgc29tZSBzcGVjcyBjYW4gZ2V0
IGZpbmFsaXNlZCBzbyB0aGF0ICptYXliZSogTWljcm9zb2Z0IGFuZCBHb29nbGUgY2FuIHNoaXAg
YSBuZXcgdmVyc2lvbiBvZiBPcGVuSUQgKHRoYXQgZG9lc24ndCBhZGVxdWF0ZWx5IGFkZHJlc3Mg
b25lIG9mIHRoZSBjb3JlIHVzYWJpbGl0eSBzaG9ydGNvbWluZ3Mgb2YgdGhlIGZpcnN0IHR3byBP
cGVuSURzKS4NCg0KSSBkb24ndCBrbm93IGlmIEV2YW4gUHJvZHJvbW91IG9yIGFueW9uZSBmcm9t
IERpYXNwb3JhIG9yIGFueW9uZSBlbHNlIHdobyBoYXMgKmFjdHVhbGx5IHRyaWVkIHRvIGRlcGxv
eSogc2ltaWxhciB0aGluZ3MgaXMgd2F0Y2hpbmcgdGhpcyB0aHJlYWQsIGJ1dCBpZiB0aGV5IGFy
ZSwgSSBob3BlIHRoZXkgcGlwZSB1cCwgYmVjYXVzZSB0aGVyZSBpcyBhYnNvbHV0ZWx5IHplcm8g
Y29uc2lkZXJhdGlvbiBmb3IgYWN0dWFsIGltcGxlbWVudGF0aW9ucyBoYXBwZW5pbmcgaW4gdGhp
cyBkaXNjdXNzaW9uLg0KDQpBbHNvLCBrZWVwIGluIG1pbmQgdGhhdCBpZiAqd2UncmUqIGNvbmZ1
c2VkIGFib3V0IHRoZSBob3N0LW1ldGEgcHJvY2Vzc2luZyBydWxlcywgb3IgaWYgbXkgInNpbmds
ZS1jb2RlLXBhdGgiIGFyZ3VtZW50cyBhcmUgYmVpbmcgZGlzbWlzc2VkIGJlY2F1c2UgIml0J3Mg
ZWFzeSBlaXRoZXIgd2F5IiwgdGhlbiB3ZSdyZSBpbiBhIGxvdCBvZiB0cm91YmxlLiBSZWZlciB0
byB0aGUgZmFjdCB0aGF0IHdlJ3ZlIHN3aXRjaGVkIGZyb20gWE1MIHRvIEpTT04gYmVjYXVzZSBY
TUwgaXMgdG9vIGhhcmQgZm9yIG1vc3QgZGV2ZWxvcGVycy4NCg0KVGhlIHBvaW50IG9mIGFsbCB0
aGlzIGlzIHRvIG1ha2UgaXQgYWNjZXNzaWJsZSBhbmQgZWFzeSwgc2luY2Ugd2UgaGF2ZSBhIGNo
aWNrZW4tYW5kLWVnZyBwcm9ibGVtLiBJZiB0aGlzIGlzIGdvaW5nIHRvIHdvcmssIGl0J3MgZ29p
bmcgdG8gdGFrZSB0aGUgd2hvbGUgbG9uZyB0YWlsLCBub3QganVzdCBNaWNyb3NvZnQgYW5kIEdv
b2dsZS4gVGhlIHNwZWNzIHdlIGhhdmUgcmlnaHQgbm93IGNsZWFybHkgZG9uJ3Qgd29yaywgYnV0
IGlkbGUgc3BlY3VsYXRpb24gb24gb3VyIHBhcnQgaXNuJ3QgZ29pbmcgdG8gbWFrZSBhbnkgb2Yg
dGhpcyB3b3JrLg0KDQpiLg0K

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA20100B53AP3PWEX2MB008ex2_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv
QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp
bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28t
c3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwi
c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u
YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE
O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt
YWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA
cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu
MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw
bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZbGwgYWRkIG9uZSBt
b3JlIG9ic2VydmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhyb3VnaG91dCB0aGlzIHdvcmssIHRoZSBtYWlu
IGNoYWxsZW5nZSDigJMgOTUlIG9mIHRoZSBwcm9ibGVtIOKAkyBoYXMgYWx3YXlzIGJlZW4gYWRv
cHRpb24uIE1heWJlIGNvbXByb21pc2VzIHdlcmUgbWFkZSBhbG9uZyB0aGUgd2F5IHRvIHdpbiB0
aGUgc3VwcG9ydCBvZiBtYWpvcg0KIHBsYXllcnMuIFRoZSBwYXJ0IHBlb3BsZSBvbiB0aGlzIGxp
c3QgaGF2ZSBhIGhhcmQgdGltZSBhZ3JlZWluZyBpcyB3aGF0IGlzIHRoZSBiZXN0IHNvbHV0aW9u
IHRoYXQgd2lsbCBsZWFkIHRvIHRoZSBmYXN0ZXN0IGFkb3B0aW9uLCBhbmQgd2hvIGFyZSB0aGUg
bW9zdCBpbXBvcnRhbnQgZWFybHkgYWRvcHRlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhhdmUgc3RvcHBlZCBj
aGltaW5nIGluIHdpdGggbXkgb3BpbmlvbnMgYW5kIHBvc2l0aW9ucyBiZWNhdXNlIEkgaGF2ZSBu
byBwbGFucyBpbiB0aGUgZm9yZXNlZWFibGUgZnV0dXJlIHRvIGltcGxlbWVudCB0aGlzIG9uIHRo
ZSBjbGllbnQgb3Igc2VydmVyLiBUaGVyZQ0KIGlzIGxpdHRsZSB2YWx1ZSBpbiBhIGdlbmVyaWMg
ZGlzY292ZXJ5IGZyYW1ld29yayB0aGF0IGlzIG5vdCB3aWRlbHkgYWRvcHRlZC4gVGhpcyBkaXNj
dXNzaW9uIHdvdWxkIGJlIG11Y2ggbW9yZSBlZmZlY3RpdmUgaWYgaXQgd2FzIGhlbGQgaW4gcHJp
dmF0ZSBhbW9uZyBhIHNlbGVjdCBmZXcgd2hvIGNhbiBxdWlja2x5IGFncmVlIG9uIHNvbWV0aGlu
ZyAqPGI+dGhleTwvYj4qIGNhbiBhY3R1YWxseSBzaGlwIHRvIGdldCB0byBhIGNyaXRpY2FsIG1h
c3MuDQogQnV0IG9mIGNvdXJzZSwgdGhpcyBpcyBub3QgaG93IHRoaXMgY29tbXVuaXR5IHdvcmtz
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+VGhlIHRlY2huaWNhbCBkZXRhaWxzIGJlaW5nIGRlYmF0ZWQgaGVyZSBtYXR0
ZXIsIGJ1dCBub3QgbXVjaC4gRXZlcnl0aGluZyBzdWdnZXN0ZWQgc28gZmFyIHdpbGwgd29yayDi
gJMgaWYgZW5vdWdoIHBlb3BsZSBhZG9wdCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVIPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw
dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu
IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gYXBwcy1kaXNj
dXNzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9y
Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJhbiBIYW1tZXI8YnI+DQo8Yj5TZW50OjwvYj4gV2Vk
bmVzZGF5LCBBcHJpbCAyNSwgMjAxMiAzOjQ3IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVz
OyBCbGFpbmUgQ29vazsgYXBwcy1kaXNjdXNzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+
IFJlOiBbYXBwcy1kaXNjdXNzXSBXZWJmaW5nZXIgLyBTV0QgSXNzdWUgIzM6IGRpcmVjdCB2ZXJz
dXMgaW5kaXJlY3QgZGlzY292ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg
d291bGQgYXJndWUgdGhhdCBtdWNoIG9mIHRoZSBjb25mdXNpb24gaXMgY29taW5nIGZyb20gdHJ5
aW5nIHRvIHVuZGVyc3RhbmQgaG9zdC1tZXRhIGZyb20gYSBmZXcgZXhhbXBsZXMgcmF0aGVyIHRo
YW4gcmVhZCB0aGUgKHZlcnkgc2hvcnQpIHNwZWNpZmljYXRpb24uDQogVGhlcmUgaXMgdmFsdWUg
aW4gYm90aCBwcm9wb3NhbHMgaW4gdGhhdCB0aGV5IHJlcHJlc2VudCB2ZXJ5IGRpZmZlcmVudCB1
c2UgY2FzZXMgYW5kIGRldmVsb3BtZW50IGV4cGVyaWVuY2UuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFtIG5vdCBh
ZHZvY2F0aW5nIGFueSBwYXJ0aWN1bGFyIGVuZCByZXN1bHQgaGVyZSDigJMgSSBhbSBjb25maWRl
bnQgSSB3aWxsIG5ldmVyIG5lZWQgdG8gaW1wbGVtZW50IGFueSBvZiB0aGlzLCBzbyBteSBwYXJ0
aWNpcGF0aW9uIGhlcmUgaXMgbGltaXRlZCB0byBvZmZlcmluZw0KIGNsYXJpZmljYXRpb24gb24g
aG9zdC1tZXRhIGFuZCByZXByZXNlbnRpbmcgYWJvdXQgNSB5ZWFycyBvZiBjb21tdW5pdHkgd29y
ayBJ4oCZdmUgYmVlbiBwYXJ0IG9mLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RUg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+DQo8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmciPmFwcHMt
ZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPC9hPiA8YSBocmVmPSJtYWlsdG86W21haWx0bzphcHBz
LWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10iPg0KW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNl
c0BpZXRmLm9yZ108L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4NCjxiPlNl
bnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDI1LCAyMDEyIDM6MTQgUE08YnI+DQo8Yj5Ubzo8L2I+
IEJsYWluZSBDb29rOyA8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnIj5hcHBz
LWRpc2N1c3NAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbYXBwcy1kaXNj
dXNzXSBXZWJmaW5nZXIgLyBTV0QgSXNzdWUgIzM6IGRpcmVjdCB2ZXJzdXMgaW5kaXJlY3QgZGlz
Y292ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCBpZiB3
ZeKAmXJlIGNvbmZ1c2VkIGFib3V0IHRoZSBob3N0LW1ldGEgcHJvY2Vzc2luZyBydWxlcywgZXRj
LiBpdOKAmXMgYSBzaWduIHRoYXQgd2XigJlyZSBtYWtpbmcgdGhpbmdzIHRvbyBoYXJkLiZuYnNw
OyBJIGJlbGlldmUgdGhlc2UgYXJlIGV4YWN0bHkgdGhlIGtpbmRzDQogb2YgcmVhc29ucyB0aGF0
IGxlZCBZYXJvbiB0byBkZXZlbG9wIFNpbXBsZSBXZWIgRGlzY292ZXJ5LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWF5
YmUgaXTigJlzIHRpbWUgZm9yIHBlb3BsZSB0byByZXJlYWQNCjxhIGhyZWY9Imh0dHA6Ly93d3cu
Z29sYW5kLm9yZy9zaW1wbGV3ZWJmaW5nZXIvIj5odHRwOi8vd3d3LmdvbGFuZC5vcmcvc2ltcGxl
d2ViZmluZ2VyLzwvYT4gYW5kDQo8YSBocmVmPSJodHRwOi8vd3d3LmdvbGFuZC5vcmcvbWFuYWdp
bmdmaW5nZXJzZXJ2aWNlLyI+aHR0cDovL3d3dy5nb2xhbmQub3JnL21hbmFnaW5nZmluZ2Vyc2Vy
dmljZS88L2E+IChvciB0byByZWFkIHRoZW0gZm9yIHRoZSBmaXJzdCB0aW1lKS4mbmJzcDsgSSBz
dXNwZWN0IHRoZSByZWFzb25pbmcgaW4gdGhlbSB3aWxsIHJlc29uYXRlIG1vcmUgaW4gdGhlIGNv
bnRleHQgb2YgdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbiwgZm9yIHdoYXQgaXTigJlzIHdvcnRo4oCm
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UC5TLiZuYnNwOyBZb3Ug
Y2FuIHRha2UgdGhlIHZpZXdwb2ludCB0aGlzIGlzIGFib3V0IE1pY3Jvc29mdCBhbmQgR29vZ2xl
IGlmIHlvdSBsaWtlLCBidXQgaW4gbXkgbWluZCwgdGhpcyBpcyBhYm91dCB1YmlxdWl0b3VzIGRp
c2NvdmVyeSBmb3IgdGhlIG9wZW4gV2ViLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9y
ZyI+YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Im1haWx0bzpbbWFp
bHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSI+DQpbbWFpbHRvOmFwcHMtZGlzY3Vz
cy1ib3VuY2VzQGlldGYub3JnXTwvYT4gPGI+T24gQmVoYWxmIE9mIDwvYj5CbGFpbmUgQ29vazxi
cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDI1LCAyMDEyIDI6NDUgUE08YnI+DQo8
Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmciPmFwcHMtZGlz
Y3Vzc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFthcHBzLWRpc2N1c3Nd
IFdlYmZpbmdlciAvIFNXRCBJc3N1ZSAjMzogZGlyZWN0IHZlcnN1cyBpbmRpcmVjdCBkaXNjb3Zl
cnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qc2lnaCo8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBjcmF6
eS4gVGhlcmUgYXJlIGEgaGFsZi1kb3plbiBvZiB1cyBkZWJhdGluZyB0aGVvcmV0aWNhbCB3YXlz
IHRvIHN0cnVjdHVyZSBhIHRoaW5nIHRoYXQgbWF5IG9yIG1heSBub3QgZXZlciBnZXQgdXNlZCwg
c28gdGhhdCBzb21lIHNwZWNzIGNhbiBnZXQgZmluYWxpc2VkIHNvIHRoYXQgKm1heWJlKiBNaWNy
b3NvZnQgYW5kIEdvb2dsZSBjYW4gc2hpcCBhIG5ldyB2ZXJzaW9uIG9mIE9wZW5JRCAodGhhdA0K
IGRvZXNuJ3QgYWRlcXVhdGVseSBhZGRyZXNzIG9uZSBvZiB0aGUgY29yZSB1c2FiaWxpdHkgc2hv
cnRjb21pbmdzIG9mIHRoZSBmaXJzdCB0d28gT3BlbklEcykuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3Qga25vdyBpZiBFdmFuIFBy
b2Ryb21vdSBvciBhbnlvbmUgZnJvbSBEaWFzcG9yYSBvciBhbnlvbmUgZWxzZSB3aG8gaGFzICph
Y3R1YWxseSB0cmllZCB0byBkZXBsb3kqIHNpbWlsYXIgdGhpbmdzIGlzIHdhdGNoaW5nIHRoaXMg
dGhyZWFkLCBidXQgaWYgdGhleSBhcmUsIEkgaG9wZSB0aGV5IHBpcGUgdXAsIGJlY2F1c2UgdGhl
cmUgaXMgYWJzb2x1dGVseSB6ZXJvIGNvbnNpZGVyYXRpb24gZm9yIGFjdHVhbA0KIGltcGxlbWVu
dGF0aW9ucyBoYXBwZW5pbmcgaW4gdGhpcyBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCBrZWVwIGluIG1pbmQgdGhh
dCBpZiAqd2UncmUqIGNvbmZ1c2VkIGFib3V0IHRoZSBob3N0LW1ldGEgcHJvY2Vzc2luZyBydWxl
cywgb3IgaWYgbXkgJnF1b3Q7c2luZ2xlLWNvZGUtcGF0aCZxdW90OyBhcmd1bWVudHMgYXJlIGJl
aW5nIGRpc21pc3NlZCBiZWNhdXNlICZxdW90O2l0J3MgZWFzeSBlaXRoZXIgd2F5JnF1b3Q7LCB0
aGVuIHdlJ3JlIGluIGEgbG90IG9mIHRyb3VibGUuIFJlZmVyIHRvIHRoZSBmYWN0IHRoYXQgd2Un
dmUgc3dpdGNoZWQNCiBmcm9tIFhNTCB0byBKU09OIGJlY2F1c2UgWE1MIGlzIHRvbyBoYXJkIGZv
ciBtb3N0IGRldmVsb3BlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlRoZSBwb2ludCBvZiBhbGwgdGhpcyBpcyB0byBtYWtlIGl0IGFjY2Vz
c2libGUgYW5kIGVhc3ksIHNpbmNlIHdlIGhhdmUgYSBjaGlja2VuLWFuZC1lZ2cgcHJvYmxlbS4g
SWYgdGhpcyBpcyBnb2luZyB0byB3b3JrLCBpdCdzIGdvaW5nIHRvIHRha2UgdGhlIHdob2xlIGxv
bmcgdGFpbCwgbm90IGp1c3QgTWljcm9zb2Z0IGFuZCBHb29nbGUuIFRoZSBzcGVjcyB3ZSBoYXZl
IHJpZ2h0IG5vdyBjbGVhcmx5IGRvbid0DQogd29yaywgYnV0IGlkbGUgc3BlY3VsYXRpb24gb24g
b3VyIHBhcnQgaXNuJ3QgZ29pbmcgdG8gbWFrZSBhbnkgb2YgdGhpcyB3b3JrLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA20100B53AP3PWEX2MB008ex2_--

From ve7jtb@ve7jtb.com  Wed Apr 25 16:08: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 DE19021F864C for ; Wed, 25 Apr 2012 16:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.154
X-Spam-Level: 
X-Spam-Status: No, score=-3.154 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMVmUSvKXojx for ; Wed, 25 Apr 2012 16:08:15 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 153A521F853E for ; Wed, 25 Apr 2012 16:08:11 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so667362yhk.31 for ; Wed, 25 Apr 2012 16:08:11 -0700 (PDT)
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=dFdrrIOHLP2juqxT1YRrDz61jQ3/KwiMNAKTlpWIohA=; b=HC9LUpQ3VURdpjk+R/GfLxTXQ6QJZA5fNDbvghJlUoW7nBl1pUnZON71Oh/q9Hmq2o JXVeAaF2pO35ja9zh2NvkUdVApLOraWR/UOiJumRPiWz0Xiitg2fQeqT86/laC5hPv5V ydGrHWoehYNjCb+pIRQwoqV/E+8F1ZOAXgqvxyrxR9LUIajJPjlN0OPhObRXmxBozt6P 01b/GzFIH4M7A/wZMWeGkSMtZ5j8O9AQU5vNMhheUeMGnUJD7EciEfhLECu5QKtmZ0Ym OrLIf1/nHzCr5pymfQZItU1qOZpiY46YtRhbLNoc/AnxyPh7IIdy5GNvGKpCtcyNlCpQ 3ubw==
Received: by 10.236.176.167 with SMTP id b27mr4183493yhm.55.1335395291414; Wed, 25 Apr 2012 16:08:11 -0700 (PDT)
Received: from [192.168.1.213] (190-20-63-108.baf.movistar.cl. [190.20.63.108]) by mx.google.com with ESMTPS id a24sm879700ana.10.2012.04.25.16.08.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 16:08:08 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_055B464A-5938-48E8-91D5-54F674C49179"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20100B529@P3PWEX2MB008.ex2.secureserver.net>
Date: Wed, 25 Apr 2012 20:07:52 -0300
Message-Id: <8E28B8E7-88EC-45AF-8899-D8B22536A7F9@ve7jtb.com>
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201007020@P3PWEX2MB008.ex2.secureserver.net> <515663DA-67BF-4367-9AD9-6E940424CBCD@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20100990A@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA201009E4D@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA20100AEA2@P3PWEX2MB008.ex2.secureserver.net> <1699AC2D-56DD-44F1-BA51-5E01CCA43E26@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20100B18C@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA20100B529@P3PWEX2MB008.ex2.secureserver.net>
To: Eran Hammer 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQkHQjKFMNR2V4W+P3UMXPcA26S74EWcVYJjH13K+ecGxtW82sRV59iTiZIAWojXLjZBr9j8
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Apr 2012 23:08:17 -0000

--Apple-Mail=_055B464A-5938-48E8-91D5-54F674C49179
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Thanks,

Understood,  It isn't like people haven't accused me of not finding the =
function vs simplicity sweet spot myself:)

The static files requirement is a hard one to work around without having =
every client prepared to do the processing.

John B.
On 2012-04-25, at 7:56 PM, Eran Hammer wrote:

>=20
>=20
>> -----Original Message-----
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>> Sent: Wednesday, April 25, 2012 3:47 PM
>> To: Eran Hammer
>> Cc: Paul E. Jones; apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>=20
>> Thanks,
>>=20
>> I think the example may be wrong though.
>>=20
>> Shouldn't  the response to:
>>> GET /.well-known/host-
>> meta.json?resource=3Dhttp://example.com/resource
>>=20
>> be:
>>> {
>>> "links":[
>>>   {
>>>     "rel":"example",
>>>     "href":"http://example.com/3"
>>>   },
>>>   {
>>>     "rel":"example",
>>>     "href":"http://example.com/2"
>>>   }
>>> ]
>>> }
>=20
> Yes, sorry. I was on a conference call and got distracted.
>=20
>> What bit of magic logic turns the template to a href in the response? =
  I would
>> not have guessed that, part of my confusion.
>=20
> When you perform resource-specific discovery, you apply the resource =
URI to the templates. In this example, the template in host-meta just =
doesn't have any variables.
>=20
>> So "template" gets expanded and  converted to href in the host-meta =
along
>> with the "subject" becoming a canonical synonym for "resource"?
>>=20
>> The "subject" value indicating that host side processing succeeded?
>=20
> This is part of the WF extension which I have not synced up on the =
recent draft. I think that's correct.
>=20
>> I feel like I am closer to understanding,  though perhaps farther =
away on
>> convincing people of WF's simplicity for clients.
>=20
> The complexity comes from requirements in the original work:
>=20
> 1. Ability to represent data in static files / documents
> 2. Ability to define the order of links between the generic host-meta =
to the specific lrdd documents
>=20
> We debated whether we should allow multiple lrdd documents, as well as =
if we should always process lrdd documents at the end. There are ways to =
simplify the processing rules (which are really pretty short and simple =
if you follow the specification and not try to reverse engineer the =
examples), but every simplification comes at reduced functionality.
>=20
> The biggest difficulty is to decide what are the real requirements. =
Since this is a very generic discovery framework, everyone has an =
opinion and there isn't a clear answer that will make everyone happy.
>=20
> EH
>=20
>=20
>> John B.
>>=20
>>=20
>> On 2012-04-25, at 6:11 PM, Eran Hammer wrote:
>>=20
>>> If your host-meta is:
>>>=20
>>> {
>>> "links":[
>>>   {
>>>     "rel":"example",
>>>     "href":"http://example.com/1"
>>>   },
>>>   {
>>>     "rel":"lrdd",
>>>     "template":"http://example.com/lrdd?resource=3D{uri}"
>>>   },
>>>   {
>>>     "rel":"example",
>>>     "template":"http://example.com/2"
>>>   }
>>> ]
>>> }
>>>=20
>>> And your LRDD document always return:
>>>=20
>>> {
>>> "links":[
>>>   {
>>>     "rel":"example",
>>>     "template":"http://example.com/3"
>>>   }
>>> ]
>>> }
>>>=20
>>> Then a host-wide request:
>>>=20
>>> GET /.well-known/host-meta.json?rel=3Dexample
>>>=20
>>> Will return (I haven't checked the exact format of the latest draft =
so the
>> syntax might be wrong here):
>>>=20
>>> {
>>> "links":[
>>>   {
>>>     "rel":"example",
>>>     "href":"http://example.com/1"
>>>   }
>>> ]
>>> }
>>>=20
>>> And a resource-specific request (not escaped for readability):
>>>=20
>>> GET /.well-known/host-
>> meta.json?resource=3Dhttp://example.com/resource
>>>=20
>>> Will return:
>>>=20
>>> {
>>> "links":[
>>>   {
>>>     "rel":"example",
>>>     "href":"http://example.com/1"
>>>   },
>>>   {
>>>     "rel":"example",
>>>     "href":"http://example.com/2"
>>>   }
>>> ]
>>> }
>>>=20
>>> Does this help?
>>>=20
>>> EH
>>>=20
>>>> -----Original Message-----
>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>> Sent: Wednesday, April 25, 2012 1:08 PM
>>>> To: Eran Hammer
>>>> Cc: Paul E. Jones; apps-discuss@ietf.org
>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>>=20
>>>> So the merged output if there is one in the host-meta and one in =
the
>>>> resource JRD is more like:
>>>> "links" :
>>>> {
>>>>     "rel" : "http://openid.net/specs/connect/issuer",
>>>>     "template" : "https://server.example.com"
>>>>   },
>>>> {
>>>>     "rel" : "http://openid.net/specs/connect/issuer",
>>>>     "href" : "https://server.example.com"
>>>>   }
>>>> }
>>>>=20
>>>> Is that correct?
>>>>=20
>>>> John B.
>>>>=20
>>>> On 2012-04-25, at 4:42 PM, Eran Hammer wrote:
>>>>=20
>>>>>=20
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>>>> Sent: Wednesday, April 25, 2012 12:00 PM
>>>>>> To: Eran Hammer
>>>>>> Cc: Paul E. Jones; apps-discuss@ietf.org
>>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>>>>=20
>>>>>> OK so host-meta is one level of lrdd link processing for a =
resource (not
>>>> host).
>>>>>>=20
>>>>>> Multiple lrdd links are not precluded, but are an abuse.
>>>>>>=20
>>>>>> If you want to redirect to an alternate host-meta location you =
use 3xx
>> and
>>>>>> the client will follow.
>>>>>> (I heard some complaining about what if my site can't support =
redirects
>>>>>> earlier.)
>>>>>>=20
>>>>>> The links are aggregated with host-meta links and filtered by =
"rel".
>>>>>>=20
>>>>>> So if in host-meta I have:
>>>>>> {
>>>>>>     "rel" : "http://openid.net/specs/connect/issuer",
>>>>>>     "href" : "https://server.example.com"
>>>>>>   }
>>>>>>=20
>>>>>> before my lrdd entry
>>>>>=20
>>>>> Only if you change 'href' above to 'template'. 'href' are =
host-wide only
>> and
>>>> do not apply to resource-specific.
>>>>>=20
>>>>> If you make a host-wide request, lrdd links and all templates are =
ignored.
>>>>> If you make a resource-specific request, all href links in =
host-meta are
>>>> ignored, templates expanded, and lrdd templates followed and =
included
>>>> inline.
>>>>>=20
>>>>> EH
>>>>>=20
>>>>>> That would be returned in the filtered list before any resource =
specific
>>>> "rel" ?
>>>>>>=20
>>>>>> Thus making a global setting for all resources.
>>>>>>=20
>>>>>> I don't think the original Connect proposal had per user =
discovery only
>> per
>>>>>> host via host meta without following lrdd.
>>>>>>=20
>>>>>> If aggrigating and sorting links are a requirement, that needs to =
be
>> done
>>>>>> server side for Connect clients.
>>>>>>=20
>>>>>> John B.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 2012-04-25, at 3:29 PM, Eran Hammer wrote:
>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>>>>>> Sent: Wednesday, April 25, 2012 10:38 AM
>>>>>>>> To: Eran Hammer
>>>>>>>> Cc: Paul E. Jones; apps-discuss@ietf.org
>>>>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>>>>>>=20
>>>>>>>> Eran,
>>>>>>>>=20
>>>>>>>> It was unclear, at least to me that the server side host-meta
>> processing
>>>>>> rule
>>>>>>>> specified in WF requires all the templates (or just the LRDD =
ones) to
>> be
>>>>>>>> processed substituting inserting "resource" for URI and then
>> retrieving
>>>>>> and
>>>>>>>> merging all the resource JRD before processing the filter on =
the "rel".
>>>>>>>>=20
>>>>>>>> If I defined a rel of FOO would WF fill the template and =
retrieve the
>> JRD
>>>>>> and
>>>>>>>> merge its links with the lrdd JRD?
>>>>>>>> I might think that would be a touch confusing to clients.
>>>>>>>=20
>>>>>>> No. It only does *one* level of LRDD import (in order). See:
>>>>>>>=20
>>>>>>> http://tools.ietf.org/html/rfc6415#section-4.2
>>>>>>>=20
>>>>>>>> So I go back to the rational explanation that lrdd templates =
are
>>>> expanded
>>>>>> and
>>>>>>>> those links rolled up and filtered.
>>>>>>>>=20
>>>>>>>> Now I am guessing that some of the SWD people are thinking that
>>>> when
>>>>>> the
>>>>>>>> server is using flat files that puts a lot of burden onto the =
client.
>>>>>>>>=20
>>>>>>>> Probably why you added the server side processing.
>>>>>>>=20
>>>>>>> The idea of adding server-side processing and filtering via the =
query
>>>> came
>>>>>> out of the original OpenID Connect proposal that David Recordon =
and I
>>>>>> wrote, trying to keep the clients super simple and avoid the need =
to go
>>>> fetch
>>>>>> host-meta, then one or more LRDD documents.
>>>>>>>=20
>>>>>>> Complexity is very much implementation specific on the server =
side.
>>>> Yahoo
>>>>>> doesn't have LRDD documents and puts everything as link templates =
in
>>>> host-
>>>>>> meta while others like the ability to customize. The most likely =
scenario
>> of
>>>>>> servers including LRDD links in host-meta is that the host-meta
>> document
>>>> is
>>>>>> static, while the LRDD links are dynamically generated. =
Otherwise,
>> there is
>>>>>> very little value in the added complexity. In that case, the =
client will
>>>> typically
>>>>>> be faced with 2 requests.
>>>>>>>=20
>>>>>>> I would argue that a server using multiple LRDD links in =
host-meta is
>>>> abusing
>>>>>> the system, very much like a server using multiple 3xx =
redirections
>>>> between
>>>>>> its initial host-meta endpoint to where the document actually =
lives.
>>>>>>>=20
>>>>>>> IOW, there are many ways to inflict pain on the client.
>>>>>>>=20
>>>>>>>> Given that WF takes the liberty of adding query parameters to =
host-
>>>> meta
>>>>>>>> and seems to define host-meta processing rules (perhaps for non
>>>> lrdd?), I
>>>>>>>> am not finding the separation of the two specs as clean as =
possible.
>>>>>>>> It seems a bit like there is there a RFC 6415 dependency on WF.
>>>> Though
>>>>>> that
>>>>>>>> is a touch strange for a RFC.
>>>>>>>=20
>>>>>>> The WF draft should not introduce any new processing rules. It =
should
>>>> only
>>>>>> add the query optimization but that must result in exactly the =
same set
>> of
>>>>>> links as defined by 6415. If this is the case, it's a bug.
>>>>>>>=20
>>>>>>>> What stops someone from defining a relation of super-discovery =
and
>>>>>> adding
>>>>>>>> some query parameters to host-meta.json to hover up some lrdd
>>>> based
>>>>>> on a
>>>>>>>> template expansion of  "super-discovery" rel types, and filter =
on
>> "rel"?
>>>>>>>>=20
>>>>>>>> I wouldn't have thought to do that because stepping on the RFC =
6415
>>>>>>>> endpoint seems slightly wrong to me.
>>>>>>>>=20
>>>>>>>> I would probably define a new endpoint /.well-known/super-
>> discovery
>>>>>> with
>>>>>>>> my own query parameters and processing rules for JRD documents.
>>>>>>>=20
>>>>>>> That would be the right approach. Note that 6415 registers both =
host-
>>>> meta
>>>>>> (defaults to XML) and host-meta.json (JSON required).
>>>>>>>=20
>>>>>>>> Without being able to make server-side processing of host-meta
>>>>>> required,
>>>>>>>> we need someway to delegate that to another endpoint.
>>>>>>>>=20
>>>>>>>> In XRD we did discuss delegating the entire XRD.  Is there a =
way to do
>>>> that
>>>>>> in
>>>>>>>> host-meta?
>>>>>>>=20
>>>>>>> 3xx.
>>>>>>>=20
>>>>>>> EH
>>>>>>>=20
>>>>>>>> At the moment all of the processing gets pushed back on the =
client if
>>>> the
>>>>>>>> host only supports static files in /.well-known
>>>>>>>>=20
>>>>>>>> John B.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 2012-04-25, at 1:34 PM, Eran Hammer wrote:
>>>>>>>>=20
>>>>>>>>> It is important to understand the semantics of host-meta, =
which I
>>>> think
>>>>>>>> there is some confusion about here.
>>>>>>>>>=20
>>>>>>>>> As a mechanism, host-meta providers you with a method of
>> obtaining
>>>>>> both
>>>>>>>> host-wide and resource-specific links (and properties). To
>> accomplish
>>>>>> that, it
>>>>>>>> provides with both a document and processing rules.
>>>>>>>>>=20
>>>>>>>>> WebFinger - the name given for the host-meta *use-case* of
>>>> retrieving
>>>>>>>> user information - is a specialization of obtaining =
resource-specific
>> links.
>>>>>>>>>=20
>>>>>>>>> The 'rel' and 'resource' query parameters (as proposed) apply =
to
>> the
>>>>>>>> endpoint *after* executing the processing rules (which include
>>>> expanding
>>>>>>>> templates and importing links from one level LRDD documents).
>>>>>>>>>=20
>>>>>>>>> LRDD documents only apply to resource-specific links, which =
means
>>>> they
>>>>>>>> are ignored for any host-wide query. For example, the location =
of
>> the
>>>>>> site's
>>>>>>>> TOS document. =46rom the host-meta perspective, LRDD documents
>> are
>>>>>> just a
>>>>>>>> deployment tool to provide customization not possible using =
just link
>>>>>>>> templates at the host-meta document level. It's just a =
link-include
>>>>>>>> mechanism, and host-meta uses it restrictively.
>>>>>>>>>=20
>>>>>>>>> IMO, the 'rel' and 'resource' optimization should only apply =
to the
>>>> host-
>>>>>>>> meta endpoint, and act as a filter post the processing rules. =
If
>> 'resource'
>>>> is
>>>>>>>> specified, it is a resource-specific request, otherwise, =
host-wide.
>>>>>>>>>=20
>>>>>>>>> Let me know if this helps or if it is still unclear.
>>>>>>>>>=20
>>>>>>>>> EH
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>>>>>>>> Sent: Wednesday, April 25, 2012 8:27 AM
>>>>>>>>>> To: Eran Hammer
>>>>>>>>>> Cc: Paul E. Jones; apps-discuss@ietf.org
>>>>>>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>>>>>>>>=20
>>>>>>>>>> That was one thing that initially confused me.  The rel =
filter is not
>>>>>> applied
>>>>>>>> to
>>>>>>>>>> host-meta, but rather the linked lrdd resource JRD.
>>>>>>>>>>=20
>>>>>>>>>> The currently defined "resource" parameter has an implicit =
host-
>>>> meta
>>>>>>>> "rel"
>>>>>>>>>> of "lrdd".
>>>>>>>>>>=20
>>>>>>>>>> To use this mechanism for other relations you would need to
>> make
>>>> that
>>>>>>>>>> parameter explicit.
>>>>>>>>>>=20
>>>>>>>>>> That then raises the question of the filter being part of =
host-meta
>> or
>>>>>> WF if
>>>>>>>> it
>>>>>>>>>> applies to relationships other than lrdd.
>>>>>>>>>>=20
>>>>>>>>>> If you are asking if filtering should be supported by lrdd =
where
>> you
>>>> start
>>>>>>>>>> discovery from a link header, then it probably should be =
possible
>> as
>>>>>> well.
>>>>>>>>>>=20
>>>>>>>>>> Though I thought lrdd stopped being updated over a year a =
year
>> ago.
>>>>>>>> Sorry if
>>>>>>>>>> I am out of date.
>>>>>>>>>>=20
>>>>>>>>>> So XRD/JRD documents SHOULD be filterable by "rel"
>> independent
>>>> of if
>>>>>>>> you
>>>>>>>>>> get to them via lrdd or host-meta.
>>>>>>>>>>=20
>>>>>>>>>> Host-meta SHOULD support a mechanism to filter by "rel" or =
filter
>> by
>>>> a
>>>>>>>>>> combination of "resource" (uri) , host-meta-rel and =
resource-rel
>> (the
>>>>>>>> host-
>>>>>>>>>> meta-rel is currently implicit.)
>>>>>>>>>>=20
>>>>>>>>>> I recall discussing this in the XRI TC when we did XRD years =
ago,
>>>> though
>>>>>>>> that
>>>>>>>>>> was more around using XRI identifiers.
>>>>>>>>>>=20
>>>>>>>>>> The same principal still holds.  I should be able to ask for.
>>>>>>>>>> GET /.well-known/host-meta.json
>>>>>>>>>> ?resource=3Djoe@example.com
>>>>>>>>>> &host-meta-rel=3Dlrdd
>>>>>>>>>>=20
>>>>>>>>=20
>>>> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>>>>>>>>>> HTTP/1.1
>>>>>>>>>> Host: example.com
>>>>>>>>>>=20
>>>>>>>>>> (personally I think calling the parameter "resource" and the
>> template
>>>>>> {uri}
>>>>>>>>>> will be confusing to people)
>>>>>>>>>>=20
>>>>>>>>>> In SWD we used fixed the parameter names and the base URI is
>> the
>>>>>> part
>>>>>>>> that
>>>>>>>>>> gets changed when the /.well-known can't host a script.
>>>>>>>>>> That makes the template simpler for the client to process.  =
The
>>>>>> equivalent
>>>>>>>> to
>>>>>>>>>> "rel" is always passed to make processing simpler.
>>>>>>>>>>=20
>>>>>>>>>> As Blaine has pointed out several times SWD and WF largely =
get us
>> to
>>>>>> the
>>>>>>>>>> same place.
>>>>>>>>>>=20
>>>>>>>>>> I am trying to find a way to close the gap.
>>>>>>>>>>=20
>>>>>>>>>> John B.
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On 2012-04-25, at 11:41 AM, Eran Hammer wrote:
>>>>>>>>>>=20
>>>>>>>>>>> Purely from a practical standpoint, do you think it is =
likely that a
>>>> server
>>>>>>>> will
>>>>>>>>>> support the query filter for the lrdd documents but not for =
host-
>>>> meta?
>>>>>>>>>>>=20
>>>>>>>>>>> EH
>>>>>>>>>>>=20
>>>>>>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>>>>>>>>>> bounces@ietf.org] On Behalf Of John Bradley
>>>>>>>>>>> Sent: Wednesday, April 25, 2012 6:17 AM
>>>>>>>>>>> To: Paul E. Jones
>>>>>>>>>>> Cc: apps-discuss@ietf.org
>>>>>>>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
>>>>>>>>>>>=20
>>>>>>>>>>> Paul,
>>>>>>>>>>>=20
>>>>>>>>>>> "rel" as a filter is something WF has for host-meta.  It =
however
>>>> doesn't
>>>>>>>>>> seem to have that for user JRD in the case where host-meta is
>>>>>> returned,
>>>>>>>> and
>>>>>>>>>> the template is used.
>>>>>>>>>>>=20
>>>>>>>>>>> The "resource" and "rel" parameters are already an =
optimization
>>>> for
>>>>>>>> LRDD
>>>>>>>>>> and not part of host-meta.
>>>>>>>>>>> Adding LRDD specific parameters to host-meta/host-meta.json
>> will
>>>>>>>>>> probably raise some eyebrows in review, but I am OK with it.
>>>>>>>>>>>=20
>>>>>>>>>>> I think there are use cases where size matters.  Where a =
host-
>> meta
>>>> or
>>>>>>>>>> resource JRD may be large and it is more efficient not to =
send the
>>>>>> whole
>>>>>>>>>> thing to a mobile client.
>>>>>>>>>>> It seems to be one of Mike Jones requirements.
>>>>>>>>>>>=20
>>>>>>>>>>> Using RFC6570 for LRDD is a possibility for passing through =
the
>> filter
>>>>>>>> request
>>>>>>>>>> for sites that support filtering on resource JRD.
>>>>>>>>>>>=20
>>>>>>>>>>> What other proposals do you have.  I am guessing that =
filtering
>> on
>>>>>>>> resource
>>>>>>>>>> JRD is not a totally new topic.
>>>>>>>>>>>=20
>>>>>>>>>>> LRDD is the one really doing the optimization  in any event, =
 it
>> may
>>>> be
>>>>>>>> done
>>>>>>>>>> at the host-meta GET but it is a LRDD specific extension.
>>>>>>>>>>> Having it in the template allows LRDD to filter at the =
resource JRD
>> in
>>>>>>>> cases
>>>>>>>>>> where it is not possible to do it at the host-meta level, due =
to
>> some
>>>> no
>>>>>>>> script
>>>>>>>>>> or other restriction.
>>>>>>>>>>>=20
>>>>>>>>>>> I agree that it should be filtered at the how-meta request =
but
>> you
>>>> and
>>>>>>>>>> others say that is not always possible.
>>>>>>>>>>>=20
>>>>>>>>>>> John B.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> John,
>>>>>>>>>>>=20
>>>>>>>>>>> The "rel" parameter is something we still need to discuss, =
so not
>> is
>>>> as
>>>>>>>> good
>>>>>>>>>> a time as any.
>>>>>>>>>>>=20
>>>>>>>>>>> What "rel" does is act as a filter.  For the most part, the =
only
>>>> purpose it
>>>>>>>>>> serves is to help reduce the number of link relations that =
might be
>>>> sent
>>>>>>>> from
>>>>>>>>>> the server.  So, if a user had 1,000 different link =
relations, this
>> might
>>>>>>>> reduce
>>>>>>>>>> the returned message to containing only 1.  However, if a =
user has
>>>>>> more
>>>>>>>> than
>>>>>>>>>> one link relation of the same type, all of them would match =
and
>> be
>>>>>>>> returned.
>>>>>>>>>>>=20
>>>>>>>>>>> When you say the host cannot support re-write rules, I =
assume
>> you
>>>>>>>> mean it
>>>>>>>>>> does not support the URI parameters on host-meta?  In that =
case,
>>>> yes,
>>>>>>>> the
>>>>>>>>>> parameters are ignored and you get just the host-meta
>> document.
>>>>>>>>>>>=20
>>>>>>>>>>> The only URI template defined in RFC 6415 is "{uri}" (see =
3.1.1.1).
>>>>>> There
>>>>>>>> are
>>>>>>>>>> no other URI template values defined.  (Note: this whole =
section
>>>> exists
>>>>>>>> only
>>>>>>>>>> because RFC  6570 did not yet exist, I think.
>>>>>>>>>>>=20
>>>>>>>>>>> In any case, we could define a new URI template, but then we
>>>> would
>>>>>> be
>>>>>>>>>> putting an optimization in place for LRDD.  If host-meta is =
not
>> going
>>>> to
>>>>>>>>>> support the "rel" URI parameter, why would LRDD?  It would =
also
>>>> mean
>>>>>>>> that
>>>>>>>>>> the LRDD logic would have to be ready to receive a URI =
parameter
>>>> that
>>>>>> is
>>>>>>>> not
>>>>>>>>>> replaced, since some clients would only change {uri} and =
leave
>> {rel}
>>>>>> there.
>>>>>>>>>> That would introduce more conditional logic in the server.  =
This
>>>> would
>>>>>> also
>>>>>>>>>> present issues with static sites.  (Of course, one might be =
able to
>> use
>>>>>>>> Apache
>>>>>>>>>> re-writing rules to get around that problem, but it certainly =
would
>>>> not
>>>>>>>> work
>>>>>>>>>> for "real" static sites.)
>>>>>>>>>>>=20
>>>>>>>>>>> Personally,  I'd prefer to not add the "rel" parameter to =
LRDD,
>> since
>>>> I
>>>>>>>> think
>>>>>>>>>> optimization using "rel" would always be done on host-meta.
>> That
>>>> said,
>>>>>> I
>>>>>>>>>> question the value of "rel" entirely.  Do you think it's =
useful to
>> have
>>>> this
>>>>>>>> filter
>>>>>>>>>> at all?  Is there really a risk that a site might return =
1,000 link
>> relations
>>>>>> that
>>>>>>>> the
>>>>>>>>>> client would have to step over?
>>>>>>>>>>>=20
>>>>>>>>>>> Paul
>>>>>>>>>>>=20
>>>>>>>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>>>>>>>>> Sent: Tuesday, April 24, 2012 10:17 PM
>>>>>>>>>>> To: Paul E. Jones
>>>>>>>>>>> Cc: apps-discuss@ietf.org
>>>>>>>>>>> Subject: WF flow with rel parameter
>>>>>>>>>>>=20
>>>>>>>>>>> Paul,
>>>>>>>>>>>=20
>>>>>>>>>>> Sorry I hit send on the previous message with a typo.
>>>>>>>>>>>=20
>>>>>>>>>>> I am looking at how the flows in WF might work for openID.
>>>>>>>>>>>=20
>>>>>>>>>>> Let's set aside the XML issue for the moment and focus on =
the
>>>> JSON
>>>>>>>> flow.
>>>>>>>>>>>=20
>>>>>>>>>>> Please correct anything I get wrong.
>>>>>>>>>>>=20
>>>>>>>>>>> The openID Connect defines a relation of
>>>>>>>>>> http://openid.net/specs/connect/issuer
>>>>>>>>>>>=20
>>>>>>>>>>> WF allows for a JSON host-meta that takes two parameters,
>>>>>> "resource"
>>>>>>>> and
>>>>>>>>>> "rel"
>>>>>>>>>>>=20
>>>>>>>>>>> An example request and response (line-brakes for =
readability)
>>>>>>>>>>>=20
>>>>>>>>>>> GET /.well-known/host-meta.json
>>>>>>>>>>> ?resource=3Djoe@example.com
>>>>>>>>>>>=20
>>>>>>>>=20
>>>> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>>>>>>>>>> HTTP/1.1
>>>>>>>>>>> Host: example.com
>>>>>>>>>>>=20
>>>>>>>>>>> HTTP/1.1 200 OK
>>>>>>>>>>>=20
>>>>>>>>>>> Access-Control-Allow-Origin: *
>>>>>>>>>>> Content-Type: application/json; charset=3DUTF-8
>>>>>>>>>>>=20
>>>>>>>>>>> {
>>>>>>>>>>> "subject" : "joe@example.com",
>>>>>>>>>>> "links" :
>>>>>>>>>>> [
>>>>>>>>>>>   {
>>>>>>>>>>>     "rel" : "http://openid.net/specs/connect/issuer",
>>>>>>>>>>>     "href" : "https://server.example.com"
>>>>>>>>>>>   }
>>>>>>>>>>> ]
>>>>>>>>>>> }
>>>>>>>>>>>=20
>>>>>>>>>>> If the host can't support rewrite rules or scripts the =
exchange
>>>> would
>>>>>> look
>>>>>>>>>> like:
>>>>>>>>>>>=20
>>>>>>>>>>> GET /.well-known/host-meta.json
>>>>>>>>>>> ?resource=3Djoe@example.com
>>>>>>>>>>>=20
>>>>>>>>=20
>>>> &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
>>>>>>>>>> HTTP/1.1
>>>>>>>>>>> Host: example.com
>>>>>>>>>>>=20
>>>>>>>>>>> HTTP/1.1 200 OK
>>>>>>>>>>> Access-Control-Allow-Origin: *
>>>>>>>>>>> Content-Type: application/json; charset=3DUTF-8
>>>>>>>>>>> {
>>>>>>>>>>> "expires" : "2012-03-13T20:56:11Z",
>>>>>>>>>>> "links" :
>>>>>>>>>>> [
>>>>>>>>>>>   {
>>>>>>>>>>>     "rel" : "lrdd",
>>>>>>>>>>>     "type" : "application/json",
>>>>>>>>>>>     "template" :
>>>>>>>>>>>       "https://example.com/lrdd/?format=3Djson&resource=3D{uri=
}"
>>>>>>>>>>>   }
>>>>>>>>>>>=20
>>>>>>>>>>> GET /lrdd/
>>>>>>>>>>> ?format=3Djson
>>>>>>>>>>> &resource=3Djoe@example.com
>>>>>>>>>>> Host: example.com
>>>>>>>>>>>=20
>>>>>>>>>>> HTTP/1.1 200 OK
>>>>>>>>>>>=20
>>>>>>>>>>> Access-Control-Allow-Origin: *
>>>>>>>>>>> Content-Type: application/json; charset=3DUTF-8
>>>>>>>>>>>=20
>>>>>>>>>>> {
>>>>>>>>>>> "subject" : "joe@example.com",
>>>>>>>>>>> "links" :
>>>>>>>>>>> [
>>>>>>>>>>>   {
>>>>>>>>>>>     "rel" : "http://openid.net/specs/connect/issuer",
>>>>>>>>>>>     "href" : "https://server.example.com"
>>>>>>>>>>>   },
>>>>>>>>>>>   {
>>>>>>>>>>>     "rel" : "http://webfinger.net/rel/avatar",
>>>>>>>>>>>     "href" : "http://example.com/~joe/joe.jpg"
>>>>>>>>>>>   }
>>>>>>>>>>>=20
>>>>>>>>>>> ]
>>>>>>>>>>> }
>>>>>>>>>>>=20
>>>>>>>>>>> I can't find a template parameter for "rel".  The host-meta =
spec
>>>> allows
>>>>>>>> for
>>>>>>>>>> extension but it is missing.
>>>>>>>>>>>=20
>>>>>>>>>>> What if the server wants to support filtering on rel but =
can't
>>>> support it
>>>>>> in
>>>>>>>>>> the root for some reason?
>>>>>>>>>>>=20
>>>>>>>>>>> Is it possible to have a template like:
>>>>>>>>>>>=20
>>>> "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}=
"
>>>>>>>>>>>=20
>>>>>>>>>>> That simple addition may solve a number of problems for
>> openID.
>>>>>>>>>>>=20
>>>>>>>>>>> John B.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>=20
>>>>>=20
>>>=20
>=20


--Apple-Mail=_055B464A-5938-48E8-91D5-54F674C49179
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
NTIzMDc1M1owIwYJKoZIhvcNAQkEMRYEFCnEXhqNzrUIkBOWR20Bz0BcJINgMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AII1WBfjbYwz4H+thWC2J6j0A/Rumb6v4zBZhfdPFljqhjeZhAV3pA++TvM2M/YVEYwhTmuyEHS6
Dz5pOvEcH6pkLDvRa7lAw9mcEujzo9M6O8JGtLa6Kfbc/Qtb5AJYlQt4GFv9uYPpTpUkXRMBmhV/
O5al7kMa9KQsY4lGR1lyo0JhP+SK8jZZSZA7EYvB5IGGn3tmtwq9WtSm/jZlQqx8jfrxcwtk23hq
eF1XRyamSMvkVRCoiED1645LzijVnZ7hzmmTnJSClUd3yF8jfrmMUpYZGhypLkE7XwsPL+5y48Oj
uGdA85kXVTx1XBFM/AbS4dtu+WAHJnSFxKe+f6IAAAAAAAA=

--Apple-Mail=_055B464A-5938-48E8-91D5-54F674C49179--

From paulej@packetizer.com  Wed Apr 25 17:37: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 31B1811E8091 for ; Wed, 25 Apr 2012 17:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.403
X-Spam-Level: 
X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.195,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQbl9ZOotR7I for ; Wed, 25 Apr 2012 17:37:10 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 37D5D11E8076 for ; Wed, 25 Apr 2012 17:37:10 -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 q3Q0b6pJ008965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Apr 2012 20:37:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335400626; bh=AHp9IRxBopF8F7sqA2F/AJpg05Duelch8Z7QxXe9Vxg=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=JZrDA7a8m3AqCUm2NYyhch3j+JmQ+bpcM6X4yf2LTcJEeL/iauO/hLcYPbLrekslP L6Ao7tsz+dq168IQro4TgnpHFxMcJenICtVRIl0riWlUtHzAuKpEQF3WDMGma0ptRU WVdjpYcAqQLRpv73mXtY94gNA8ZVVCzfF49YIREk=
From: "Paul E. Jones" 
To: "'Eran Hammer'" , "'William Mills'" , "'Mike Jones'" , "'Blaine Cook'" , 
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com>	<1335194949.12040.YahooMailNeo@web31812.mail.mud.yahoo.com> <053c01cd2310$7aea0b60$70be2220$@packetizer.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201009E7E@P3PWEX2MB008.ex2.secureserver.net>
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201009E7E@P3PWEX2MB008.ex2.secureserver.net>
Date: Wed, 25 Apr 2012 20:37:13 -0400
Message-ID: <05cd01cd2344$b9db7cd0$2d927670$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_05CE_01CD2323.32CC9BF0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIJGNvIkGmsH/dlhis4V9nZDOGpGAEfNpTdAvGkRC0Cz6UefZX9Uf2A
Content-Language: en-us
Subject: Re: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD	Issue	#3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Apr 2012 00:37:12 -0000

This is a multipart message in MIME format.

------=_NextPart_000_05CE_01CD2323.32CC9BF0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Eran,

=20

I agree that it=E2=80=99s odd, but clients would never see XML unless =
they explicitly asked for it.  And, if they do ask for it, it would be =
equally odd to return JSON, IMO.

=20

For LRDD, if the requestor asks for JSON, I ensure the LRDD link =
relation returned will also result in JSON being selected.  Ditto for =
XML.  Again, though, if you visit the LRDD resource that was intended to =
serve JSON and you explicitly ask for XML, I=E2=80=99ll return XML.

=20

I=E2=80=99m having a hard time justifying ignoring the Accept header.  I =
think it should always be given priority.

=20

Paul

=20

From: Eran Hammer [mailto:eran@hueniverse.com]=20
Sent: Wednesday, April 25, 2012 2:34 PM
To: Paul E. Jones; 'William Mills'; 'Mike Jones'; 'Blaine Cook'; =
apps-discuss@ietf.org
Subject: RE: [apps-discuss] Is host-meta.json viable? Re: Webfinger / =
SWD Issue #3: direct versus indirect discovery

=20

Serving anything other than JRD on host-meta.json, while legal HTTP, is =
odd. I would reject the request if the Accept header is specifying =
anything other than JRD. The benefit of this approach is that it allows =
protocol to explicitly specify host-meta.json as the discovery endpoint, =
which has the same effect of making JSON the required and only format. =
One issue is that this doesn=E2=80=99t extend to LRDD which means, if =
the server doesn=E2=80=99t support the query parameters, the client =
might end up with XML in LRDD links.

=20

We should first decide on how to approach the format issue, then just go =
and update/replace 6415 accordingly. I don=E2=80=99t think the scale of =
existing deployment is significant enough to play a major role. =
It=E2=80=99s ok to break some stuff for a cleaner, clearer future.

=20

EH

=20

=20

From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Wednesday, April 25, 2012 11:23 AM
To: 'William Mills'; 'Mike Jones'; 'Blaine Cook'; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Is host-meta.json viable? Re: Webfinger / =
SWD Issue #3: direct versus indirect discovery

=20

Bill,

=20

Host-meta.json was introduced in RFC 6415 as a means of selecting JSON, =
particularly when the client does not have the ability to indicate via =
the =E2=80=9CAccept=E2=80=9D header that it wants =
=E2=80=9Capplication/json=E2=80=9D.  On my server, I return XML by =
default.  I also honor the =E2=80=9CAccept=E2=80=9D header and return =
the type requested.  And, I support host-meta.json, which will return =
JSON by default (i.e., =E2=80=9CAccept=E2=80=9D is =
=E2=80=9C*/*=E2=80=9D), but I still honor the =E2=80=9CAccept=E2=80=9D =
header.  I always given preference to the Accept header, which I think =
is appropriate, though not explicitly documented anywhere.  This is =
where the =E2=80=9Chack=E2=80=9D part comes in.  One should honor what =
HTTP says, but then how to we treat a request based on the URI path?  =
Not sure, but I=E2=80=99m inclined to leave it that way until somebody =
tells me why it=E2=80=99s a bad idea.

=20

In any case, this was not invented as a part of the current draft; it =
was already defined.

=20

Paul

=20

From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of William Mills
Sent: Monday, April 23, 2012 11:29 AM
To: Mike Jones; Blaine Cook; apps-discuss@ietf.org
Subject: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD =
Issue #3: direct versus indirect discovery

=20

I note that some examples are now using the construct (Eran called it a =
hack, which it probably is, but I like it) host-meta.json to select the =
data format.  This seems to me to be a workable way to:

=20

-    extend the current WF stuff keeping compatibility=20

-    support for JSON without funky logic

-    allow the clients to implement a single simple code path

=20

-bill

=20


  _____ =20


From: Mike Jones 
To: Blaine Cook ; "apps-discuss@ietf.org" =
=20
Sent: Sunday, April 22, 2012 9:11 PM
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus =
indirect discovery

=20

I agree with your goal of simplicity for clients.  Paul=E2=80=99s =
example seems about as simple as it can get for clients:

               curl -v =
https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paulej@=
packetizer.com

It shares the property with your earlier example (below) that clients =
have a no-branches code path to do discovery:

               curl -s http://example.com/.well-known/host-meta| =
=20

               awk "/lrdd/,/template/"|tr -d '\n'|sed -e =
"s/^.*template=3D'\([^']*\)'.*$/\1/"|

               sed -e "s/{uri}/user@example.com/ =
 "|xargs curl =E2=80=93s

=20

However, I challenge the assumption in your note below that servers =
using only static pages must be supported.  I just don=E2=80=99t see the =
requirement to implement a query parameter as being an impediment in =
practice, even for hosted domains.  I know of no hosting company that =
doesn=E2=80=99t provide a means of putting executable code behind web =
pages, be it PHP, Perl, Ruby, ASP, JSP, etc.  I know you=E2=80=99re =
trying to make the case for static pages, but in practice, I believe =
that dynamic pages are always easily available.

=20

Assuming that we=E2=80=99re in an either-or situation with regard to =
either having single-GET discovery or supporting discovery using only =
static server pages (and I=E2=80=99d love to have someone demonstrate to =
us that we=E2=80=99re not), I=E2=80=99d take single-GET discovery for =
sure, as in some cases, it makes an appreciable difference in user =
interface latency, and per the paragraph above, I believe that dynamic =
queries can be implemented on all hosting platforms.

=20

Assuming the WebFinger authors agree, I=E2=80=99d suggest that a logical =
next step would be for a -04 version of draft-jones-appsawg-webfinger to =
be published that changes support for the resource parameter from =
RECOMMENDED to REQUIRED, as that could provide a starting point for a =
common discovery spec.

=20

                                                            -- Mike

 =20

P.S.  As long as draft-jones-appsawg-webfinger is being revised, =
I=E2=80=99d also suggest adding text making explicit what has been an =
implicit assumption in both WebFinger and SWD - that depending upon =
whether and how the client is authenticated, the set of resources =
returned may vary (as Blaine had pointed out earlier).  That could help =
deal with some of the privacy perceptions.

=20

From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of Blaine Cook
Sent: Sunday, April 22, 2012 2:15 PM
To: apps-discuss@ietf.org
Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect =
discovery

=20

This is the last issue that I've flagged as blocking a new Webfinger / =
SWD draft.

=20

Mike suggested that being able to request a user's profile with a single =
request (i.e., that the /.well-known/ profile resource should be able to =
respond with full profile data immediately, rather than pointing at a =
second URL that will fulfil the request) is a requirement for this =
standard.

=20

I'd like to challenge that requirement. The arguments for a direct =
discovery endpoint are:

=20

1. Fewer requests against the server, since we save (in the worst-case) =
50% of requests by bypassing the indirect lookup phase.

2. Lower latency for clients (e.g., mobile clients) owing to the reduced =
number of lookups.

=20

The arguments for an indirect discovery endpoint are:

=20

1. Trivial and web-standards friendly deployment for domains that won't =
host their own webfinger/swd profile servers, but want to enable =
accounts on their domains (e.g., statically hosted sites).

2. A loosening of the requirement that URLs at the bare domain must run =
dynamic scripts that respond to requests to the /.well-known/ path.

=20

My opinion is that the approach that SWD has proposed for the redirect =
is problematic. First, the format is very similar in form to the HTML =
"meta refresh" tag that provided HTTP redirect support from within HTML. =
That format has been widely deprecated, and in these more enlightened =
times, we just use the 3xx response codes with Location headers, =
instead.

=20

Secondly, the SWD request format means that for smaller sites, often =
those with the least resources, will end up serving static content in a =
way that's difficult to cache; certainly, more difficult to cache than =
just serving static content. This is due to the request parameters =
present in all SWD requests; those request parameters will bust caches.

=20

As for the first argument *for* SWD's approach, I'd suggest we look to =
DNS, which uses the same indirection approach for NS records, relying on =
a (relatively) very small set of root servers to handle the traffic for =
the whole internet. Clearly, this approach works, and webfinger/swd =
servers are in a much better position to handle this additional traffic. =
Most of this traffic will be heavily cached, especially for the largest =
providers.

=20

In fact, in terms of real deployments, hosting a script at, e.g., =
google.com/.well-known/simple-web-discovery is much harder than hosting =
a script at profiles.google.com/profile.json for all sorts of reasons, =
so it's my belief that the first argument is a red herring.

=20

The second argument is legitimate, but only if mobile clients will =
actually be making requests to diverse webfinger/swd hosts. Instead, I =
strongly believe that we'll see the emergence of DNS-like servers that =
provide both profile hosting as well as proxy services. For a mobile =
client, the optimal approach will be to use SPDY to connect to a single =
host that performs webfinger/swd lookups on the mobile client's behalf, =
eliminating the latency concerns.

=20

I offer that the two-step lookup can be implemented without conditionals =
on the client, whereas the direct-unless-not approach cannot be =
implemented that way (see my earlier curl example for proof). It's =
simpler, and easier to explain to the (hopefully many) small site owners =
who we'd like to implement this technology.

=20

Thoughts? Am I missing something?

=20

b.


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


------=_NextPart_000_05CE_01CD2323.32CC9BF0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Eran,
 
I agree that it=E2=80=99s odd, but clients would never see XML unless =
they explicitly asked for it.=C2=A0 And, if they do ask for it, it would =
be equally odd to return JSON, IMO.
 
For LRDD, if the requestor asks for JSON, I ensure the LRDD link =
relation returned will also result in JSON being selected.=C2=A0 Ditto =
for XML.=C2=A0 Again, though, if you visit the LRDD resource that was =
intended to serve JSON and you explicitly ask for XML, I=E2=80=99ll =
return XML.
 
I=E2=80=99m having a hard time justifying ignoring the Accept =
header.=C2=A0 I think it should always be given =
priority.
 
Paul
 
From:=
 =
Eran Hammer [mailto:eran@hueniverse.com] 
Sent: Wednesday, =
April 25, 2012 2:34 PM
To: Paul E. Jones; 'William Mills'; =
'Mike Jones'; 'Blaine Cook'; apps-discuss@ietf.org
Subject: =
RE: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD Issue =
#3: direct versus indirect discovery
 
Serving anything other than JRD on host-meta.json, while legal HTTP, =
is odd. I would reject the request if the Accept header is specifying =
anything other than JRD. The benefit of this approach is that it allows =
protocol to explicitly specify host-meta.json as the discovery endpoint, =
which has the same effect of making JSON the required and only format. =
One issue is that this doesn=E2=80=99t extend to LRDD which means, if =
the server doesn=E2=80=99t support the query parameters, the client =
might end up with XML in LRDD links.
 
We should first decide on how to approach the format issue, then just =
go and update/replace 6415 accordingly. I don=E2=80=99t think the scale =
of existing deployment is significant enough to play a major role. =
It=E2=80=99s ok to break some stuff for a cleaner, clearer =
future.
 
EH
 
 
From:=
 =
apps-discuss-bounces@ietf.o=
rg [mailto:apps-discu=
ss-bounces@ietf.org] On Behalf Of Paul E. =
Jones
Sent: Wednesday, April 25, 2012 11:23 AM
To: =
'William Mills'; 'Mike Jones'; 'Blaine Cook'; apps-discuss@ietf.org
Sub=
ject: Re: [apps-discuss] Is host-meta.json viable? Re: Webfinger / =
SWD Issue #3: direct versus indirect =
discovery
 
Bill,
 
Host-meta.json was introduced in RFC 6415 as a means of selecting =
JSON, particularly when the client does not have the ability to indicate =
via the =E2=80=9CAccept=E2=80=9D header that it wants =
=E2=80=9Capplication/json=E2=80=9D.  On my server, I return XML by =
default.  I also honor the =E2=80=9CAccept=E2=80=9D header and =
return the type requested.  And, I support host-meta.json, which =
will return JSON by default (i.e., =E2=80=9CAccept=E2=80=9D is =
=E2=80=9C*/*=E2=80=9D), but I still honor the =E2=80=9CAccept=E2=80=9D =
header.  I always given preference to the Accept header, which I =
think is appropriate, though not explicitly documented anywhere.  =
This is where the =E2=80=9Chack=E2=80=9D part comes in.  One should =
honor what HTTP says, but then how to we treat a request based on the =
URI path?  Not sure, but I=E2=80=99m inclined to leave it that way =
until somebody tells me why it=E2=80=99s a bad =
idea.
 
In any case, this was not invented as a part of the current draft; it =
was already defined.
 
Paul
 
From:=
 =
apps-discuss-bounces@ietf.o=
rg [mailto:apps-discu=
ss-bounces@ietf.org] On Behalf Of William =
Mills
Sent: Monday, April 23, 2012 11:29 AM
To: Mike =
Jones; Blaine Cook; apps-discuss@ietf.org
Sub=
ject: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD =
Issue #3: direct versus indirect =
discovery
 
I note =
that some examples are now using the construct (Eran called it a hack, =
which it probably is, but I like it) host-meta.json to select the data =
format.  This seems to me to be a workable way =
to:
 
-    extend the current WF stuff =
keeping compatibility 
-    support for JSON without funky =
logic
-    allow the clients to implement a =
single simple code path
 
-bill
 
<=
hr size=3D1 width=3D"100%" align=3Dcenter>
F=
rom: =
Mike Jones <Michael.Jones@microsoft.com>
To: Blaine Cook <romeda@gmail.com>; "apps-discuss@ietf.org" =
<apps-discuss@ietf.org> =

Sent: Sunday, April 22, 2012 9:11 PM
Subject: Re: =
[apps-discuss] Webfinger / SWD Issue #3: direct versus indirect =
discovery
 
I agree with your goal of =
simplicity for clients.  Paul=E2=80=99s example seems about as =
simple as it can get for clients:
It shares the property with =
your earlier example (below) that clients have a no-branches code path =
to do discovery:
     &n=
bsp;         curl -s http://example.com/.well-known/host-meta|
     &n=
bsp;         awk =
"/lrdd/,/template/"|tr -d '\n'|sed -e =
"s/^.*template=3D'\([^']*\)'.*$/\1/"|
     &n=
bsp;         sed -e "s/{uri}/user@example.com/"|xargs curl =E2=80=93s
From: apps-discuss-bounces@ietf.o=
rg [mailto:apps-discu=
ss-bounces@ietf.org] On Behalf Of Blaine Cook
Sent: =
Sunday, April 22, 2012 2:15 PM
To: apps-discuss@ietf.org
Sub=
ject: [apps-discuss] Webfinger / SWD Issue #3: direct versus =
indirect discovery
 
This is the last issue that I've flagged as =
blocking a new Webfinger / SWD =
draft.
 
<=
p class=3DMsoNormal style=3D'background:white'>Mike suggested that being able to request a user's =
profile with a single request (i.e., that the /.well-known/ profile =
resource should be able to respond with full profile data immediately, =
rather than pointing at a second URL that will fulfil the request) is a =
requirement for this =
standard.
 
<=
p class=3DMsoNormal style=3D'background:white'>I'd like to challenge that requirement. The =
arguments for a direct discovery endpoint =
are:
 
<=
p class=3DMsoNormal style=3D'background:white'>1. Fewer requests against the server, since we =
save (in the worst-case) 50% of requests by bypassing the indirect =
lookup phase.
2. Lower latency for clients (e.g., mobile =
clients) owing to the reduced number of =
lookups.
 
<=
p class=3DMsoNormal style=3D'background:white'>The arguments for an indirect discovery endpoint =
are:
 
<=
p class=3DMsoNormal style=3D'background:white'>1. Trivial and web-standards friendly deployment =
for domains that won't host their own webfinger/swd profile servers, but =
want to enable accounts on their domains (e.g., statically hosted =
sites).
2. A loosening of =
the requirement that URLs at the bare domain must run dynamic scripts =
that respond to requests to the /.well-known/ =
path.
 
<=
p class=3DMsoNormal style=3D'background:white'>My opinion is that the approach that SWD has =
proposed for the redirect is problematic. First, the format is very =
similar in form to the HTML "meta refresh" tag that provided =
HTTP redirect support from within HTML. That format has been widely =
deprecated, and in these more enlightened times, we just use the 3xx =
response codes with Location headers, =
instead.
 
<=
p class=3DMsoNormal style=3D'background:white'>Secondly, the SWD request format means that for =
smaller sites, often those with the least resources, will end up serving =
static content in a way that's difficult to cache; certainly, more =
difficult to cache than just serving static content. This is due to the =
request parameters present in all SWD requests; those request parameters =
will bust caches.
 
<=
p class=3DMsoNormal style=3D'background:white'>As for the first argument *for* SWD's approach, =
I'd suggest we look to DNS, which uses the same indirection approach for =
NS records, relying on a (relatively) very small set of root servers to =
handle the traffic for the whole internet. Clearly, this approach works, =
and webfinger/swd servers are in a much better position to handle this =
additional traffic. Most of this traffic will be heavily cached, =
especially for the largest =
providers.
 
<=
p class=3DMsoNormal style=3D'background:white'>In fact, in terms of real deployments, hosting a =
script at, e.g., google.com/.well-known/simple-web-discovery is =
much harder than hosting a script at profiles.google.com/profile.json for all sorts of =
reasons, so it's my belief that the first argument is a red =
herring.
 
<=
p class=3DMsoNormal style=3D'background:white'>The second argument is legitimate, but only if =
mobile clients will actually be making requests to diverse webfinger/swd =
hosts. Instead, I strongly believe that we'll see the emergence of =
DNS-like servers that provide both profile hosting as well as proxy =
services. For a mobile client, the optimal approach will be to use SPDY =
to connect to a single host that performs webfinger/swd lookups on the =
mobile client's behalf, eliminating the latency =
concerns.
 
<=
p class=3DMsoNormal style=3D'background:white'>I offer that the two-step lookup can be =
implemented without conditionals on the client, whereas the =
direct-unless-not approach cannot be implemented that way (see my =
earlier curl example for proof). It's simpler, and easier to explain to =
the (hopefully many) small site owners who we'd like to implement this =
technology.
 
<=
p class=3DMsoNormal style=3D'background:white'>Thoughts? Am I missing =
something?
 
<=
p class=3DMsoNormal style=3D'background:white'>b.

_______________________________________________=

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

------=_NextPart_000_05CE_01CD2323.32CC9BF0--


From paulej@packetizer.com  Wed Apr 25 18:09:29 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1C311E80AC for ; Wed, 25 Apr 2012 18:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.407
X-Spam-Level: 
X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.191,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um5x+KEa5bvW for ; Wed, 25 Apr 2012 18:09:23 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 695D811E8076 for ; Wed, 25 Apr 2012 18:08:35 -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 q3Q18XcI009835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Apr 2012 21:08:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335402514; bh=hXucj2nbrzxKKhsnJwpuN0mhSeuWoa1NFJ5F8xUQTds=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=KMysWmNnRqbmkCiDy1W5GUsz6MpsWRjes655RKTfGNmTtVlRKhubszVsrpgFipqf2 Yz8Ly4yHNUFQMym3hprBxOwMKbHvAI+1hZxEv0svY92JqLpyf2S96+atwIz1InbVTc cdWqoL0IiOY8KNO7IDjcZb9fBW/5Wv8zOiB+/5Jw=
From: "Paul E. Jones" 
To: "'John Bradley'" 
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com> <054901cd2311$87a24fb0$96e6ef10$@packetizer.com> <4CC716F1-F6A4-46CF-86FD-6636B1F84500@ve7jtb.com>
In-Reply-To: <4CC716F1-F6A4-46CF-86FD-6636B1F84500@ve7jtb.com>
Date: Wed, 25 Apr 2012 21:08:41 -0400
Message-ID: <05fc01cd2349$1f281e00$5d785a00$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_05FD_01CD2327.98193D20"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIJGNvIkGmsH/dlhis4V9nZDOGpGAKB6SPgAbGhC8kDARG59AGQmEgUATnvVS6V5GcYYA==
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Apr 2012 01:09:30 -0000

This is a multipart message in MIME format.

------=_NextPart_000_05FD_01CD2327.98193D20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

That's exactly what I'd suggest for static sites. don't put resource
specific stuff in host-meta.  For non-static sites, one could be more
flexible.

 

Paul

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, April 25, 2012 3:13 PM
To: Paul E. Jones
Cc: 'Bob Wyman'; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect
discovery

 

If WF were to make resource REQUIRED and rel optional that would be a
significant step forward.

 

Though the Apache http rewrite probably violates the host-meta processing
rules Eran just described, if the links from host-meta must be included in
order.

You could get around it by restricting the contents of host-meta if you are
doing that I suppose.

 

John B.

 

 

On 2012-04-25, at 3:30 PM, Paul E. Jones wrote:





John,

 

I don't think we need to decide specific environments we want to support,
but *if* people want to use static files, there are choices we can make
where the resource parameter will still work, even in a static environment.
Previously, I sent out a sample config that allows Apache to handle the
"resource" parameter and still map that to static files.  However, I cannot
do the same with the "rel" parameter, thus we could never mandate that if we
want to have any hope at all for allowing static sites.

 

I appreciate having the "resource" parameter, but I also appreciate some do
not need (or have the ability to support) an elaborate server.

 

Paul

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of John Bradley
Sent: Monday, April 23, 2012 12:19 PM
To: Bob Wyman
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect
discovery

 

I understand that in some environments you may not have access to http
rewrite rules.  

Others may preclude any scripts.

 

We do have to decide what environments we are going to support.

 

If we stick to static files only then we are just putting some lipstick on
Yadis by adding a way to map a email like address to a file.

 

So yes there are those environments, but that needs to be balanced against
the additional overhead on the clients to support that environment.

 

John B.

 

On 2012-04-23, at 12:26 PM, Bob Wyman wrote:






 

On Mon, Apr 23, 2012 at 11:08 AM, John Bradley  wrote:

Mike,

 

I think there is less resistance to making resource parameter REQUIRED than
there is to removing the initial host-meta lookup to get the template.

 

We should probably keep those issues separate.

 

I agree that supporting indirect discovery of the template via
host-meta.jason should probably stay.

 

The question is if their can be an optimization that allows shortcutting
that step if you know that all you want is web finger.

 

A possible option for that could be using a fixed template in /.well-known/.

 

That endpoint would return:

a The terminal JRD (like SWD)

b a 3xx redirect to the real endpoint

Causing a 3xx redirect typically requires modification to the configuration
files of a multi-host shared web server. Access to such configuration files
is often restricted in such a way that those responsible from just one or a
few of the sites sharing the common server are not permitted to make
modifications to those files. In many cases, such modifications can be
requested and will only be made after lengthy delays or the payment of
support and maintenance fees. 

 

If we want this sort of discovery to become generally available, and not
just be limited to the "large" sites, we should ensure that it is as simple
as possible to deploy.

 

c a copy of the host-meta.jrd

 

We would probably only do one of b or c.

 

c has the advantage of being a static file and you being no worse off than
having started with host-meta.json.

b is the simplest for the client and only requires common rewriting rules.

 

If the redirect is to the same host you could avoid the overhead of two
connections by pipelining the requests over the same TCP connection.

SPDY in the future will make that even more efficient.

 

I will grant Blaine that most openID Connect discovery requests are Server
to Server,  However there are Apps that are also clients that should not be
ignored.

I personally like the fixed template with a 3xx redirect and  resource
parameter returning a JRD due to the simplicity of client coding.

 

Things needing other sorts of information about the host would still use
host-meta or host-meta.json.

 

John B.

 

 

On 2012-04-23, at 1:11 AM, Mike Jones wrote:

 

I agree with your goal of simplicity for clients.  Paul's example seems
about as simple as it can get for clients:

               curl -v
https://packetizer.com/.well-known/host-meta.json?resource=acct:paulej@packe
tizer.com

It shares the property with your earlier example (below) that clients have a
no-branches code path to do discovery:

               curl -s http://example.com/.well-known/host-meta|
 

               awk "/lrdd/,/template/"|tr -d '\n'|sed -e
"s/^.*template='\([^']*\)'.*$/\1/"|

               sed -e "s/{uri}/user@example.com/"|xargs curl -s

 

However, I challenge the assumption in your note below that servers using
only static pages must be supported.  I just don't see the requirement to
implement a query parameter as being an impediment in practice, even for
hosted domains.  I know of no hosting company that doesn't provide a means
of putting executable code behind web pages, be it PHP, Perl, Ruby, ASP,
JSP, etc.  I know you're trying to make the case for static pages, but in
practice, I believe that dynamic pages are always easily available.

 

Assuming that we're in an either-or situation with regard to either having
single-GET discovery or supporting discovery using only static server pages
(and I'd love to have someone demonstrate to us that we're not), I'd take
single-GET discovery for sure, as in some cases, it makes an appreciable
difference in user interface latency, and per the paragraph above, I believe
that dynamic queries can be implemented on all hosting platforms.

 

Assuming the WebFinger authors agree, I'd suggest that a logical next step
would be for a -04 version of draft-jones-appsawg-webfinger to be published
that changes support for the resource parameter from RECOMMENDED to
REQUIRED, as that could provide a starting point for a common discovery
spec.

 

                                                            -- Mike

 

P.S.  As long as draft-jones-appsawg-webfinger is being revised, I'd also
suggest adding text making explicit what has been an implicit assumption in
both WebFinger and SWD - that depending upon whether and how the client is
authenticated, the set of resources returned may vary (as Blaine had pointed
out earlier).  That could help deal with some of the privacy perceptions.

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of Blaine Cook
Sent: Sunday, April 22, 2012 2:15 PM
To: apps-discuss@ietf.org
Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect
discovery

 

This is the last issue that I've flagged as blocking a new Webfinger / SWD
draft.

 

Mike suggested that being able to request a user's profile with a single
request (i.e., that the /.well-known/ profile resource should be able to
respond with full profile data immediately, rather than pointing at a second
URL that will fulfil the request) is a requirement for this standard.

 

I'd like to challenge that requirement. The arguments for a direct discovery
endpoint are:

 

1. Fewer requests against the server, since we save (in the worst-case) 50%
of requests by bypassing the indirect lookup phase.

2. Lower latency for clients (e.g., mobile clients) owing to the reduced
number of lookups.

 

The arguments for an indirect discovery endpoint are:

 

1. Trivial and web-standards friendly deployment for domains that won't host
their own webfinger/swd profile servers, but want to enable accounts on
their domains (e.g., statically hosted sites).

2. A loosening of the requirement that URLs at the bare domain must run
dynamic scripts that respond to requests to the /.well-known/ path.

 

My opinion is that the approach that SWD has proposed for the redirect is
problematic. First, the format is very similar in form to the HTML "meta
refresh" tag that provided HTTP redirect support from within HTML. That
format has been widely deprecated, and in these more enlightened times, we
just use the 3xx response codes with Location headers, instead.

 

Secondly, the SWD request format means that for smaller sites, often those
with the least resources, will end up serving static content in a way that's
difficult to cache; certainly, more difficult to cache than just serving
static content. This is due to the request parameters present in all SWD
requests; those request parameters will bust caches.

 

As for the first argument *for* SWD's approach, I'd suggest we look to DNS,
which uses the same indirection approach for NS records, relying on a
(relatively) very small set of root servers to handle the traffic for the
whole internet. Clearly, this approach works, and webfinger/swd servers are
in a much better position to handle this additional traffic. Most of this
traffic will be heavily cached, especially for the largest providers.

 

In fact, in terms of real deployments, hosting a script at, e.g.,
google.com/.well-known/simple-web-discovery is much harder than hosting a
script atprofiles.google.com/profile.json for all sorts of reasons, so it's
my belief that the first argument is a red herring.

 

The second argument is legitimate, but only if mobile clients will actually
be making requests to diverse webfinger/swd hosts. Instead, I strongly
believe that we'll see the emergence of DNS-like servers that provide both
profile hosting as well as proxy services. For a mobile client, the optimal
approach will be to use SPDY to connect to a single host that performs
webfinger/swd lookups on the mobile client's behalf, eliminating the latency
concerns.

 

I offer that the two-step lookup can be implemented without conditionals on
the client, whereas the direct-unless-not approach cannot be implemented
that way (see my earlier curl example for proof). It's simpler, and easier
to explain to the (hopefully many) small site owners who we'd like to
implement this technology.

 

Thoughts? Am I missing something?

 

b.

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

 


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

 

 


------=_NextPart_000_05FD_01CD2327.98193D20
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


That’s exactly what I’d suggest for static sites… =
don’t put resource specific stuff in host-meta.  For =
non-static sites, one could be more flexible.
 
Paul
 
From:=
 =
John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, =
April 25, 2012 3:13 PM
To: Paul E. Jones
Cc: 'Bob =
Wyman'; apps-discuss@ietf.org
Subject: Re: [apps-discuss] =
Webfinger / SWD Issue #3: direct versus indirect =
discovery
 
If WF were =
to make resource REQUIRED and rel optional that would be a significant =
step forward.
 
Though the Apache http rewrite probably violates the =
host-meta processing rules Eran just described, if the links from =
host-meta must be included in order.
You could get around it by restricting the contents of =
host-meta if you are doing that I suppose.
 
John B.
 
 
On =
2012-04-25, at 3:30 PM, Paul E. Jones wrote:


John,
 
I don’t think we need to decide specific environments we want =
to support, but *if* people want to use static files, there are =
choices we can make where the resource parameter will still work, even =
in a static environment.  Previously, I sent out a sample config =
that allows Apache to handle the “resource” parameter and =
still map that to static files.  However, I cannot do the same with =
the “rel” parameter, thus we could never mandate that if we =
want to have any hope at all for allowing static =
sites.
 
I appreciate having the “resource” parameter, but I also =
appreciate some do not need (or have the ability to support) an =
elaborate server.
 
Paul
 
From:=
 apps-discuss-bounces@ietf.o=
rg [mailto:apps-discu=
ss-bounces@ietf.org] On Behalf Of John =
Bradley
Sent: Monday, April 23, 2012 12:19 =
PM
To: Bob =
Wyman
Cc: apps-discuss@ietf.org
Sub=
ject: Re: =
[apps-discuss] Webfinger / SWD Issue #3: direct versus indirect =
discovery
 
I =
understand that in some environments you may not have access to http =
rewrite rules.  
Others may preclude any =
scripts.
 
We do have to decide what environments we are going to =
support.
 
If we stick to static files only then we are just =
putting some lipstick on Yadis by adding a way to map a email like =
address to a file.
 
So yes there are those environments, but that needs to =
be balanced against the additional overhead on the clients to support =
that environment.
 
John B.
 
On 2012-04-23, at 12:26 PM, Bob Wyman =
wrote:



 
On Mon, Apr 23, 2012 at 11:08 AM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:
Mike,
 
I think there is less resistance to making resource =
parameter REQUIRED than there is to removing the initial host-meta =
lookup to get the template.
 
We should probably keep those issues =
separate.
 
I agree that supporting indirect discovery of the =
template via host-meta.jason should probably =
stay.
 
The question is if their can be an optimization that =
allows shortcutting that step if you know that all you want is web =
finger.
 
A possible option for that could be using a fixed =
template in /.well-known/.
 
That endpoint would =
return:
a The =
terminal JRD (like SWD)
b a 3xx redirect to the real =
endpoint
Causing a 3xx redirect typically requires modification =
to the configuration files of a multi-host shared web server. Access to =
such configuration files is often restricted in such a way that those =
responsible from just one or a few of the sites sharing the common =
server are not permitted to make modifications to those files. In many =
cases, such modifications can be requested and will only be made after =
lengthy delays or the payment of support and maintenance =
fees. 
 
If we want this sort of discovery to become generally =
available, and not just be limited to the "large" sites, we =
should ensure that it is as simple as possible to =
deploy.
 
c a copy of the =
host-meta.jrd
 
We would probably only do one of b or =
c.
 
c has the advantage of being a static file and you =
being no worse off than having started with =
host-meta.json.
b is the simplest for the client and only requires =
common rewriting rules.
 
If the redirect is to the same host you could avoid =
the overhead of two connections by pipelining the requests over the same =
TCP connection.
SPDY in the future will make that even more =
efficient.
 
I will grant Blaine that most openID Connect discovery =
requests are Server to Server,  However there are Apps that are =
also clients that should not be =
ignored.
I =
personally like the fixed template with a 3xx redirect and =
 resource parameter returning a JRD due to the simplicity of client =
coding.
 
Things needing other sorts of information about the =
host would still use host-meta or =
host-meta.json.
 
John B.
 
 
On 2012-04-23, at 1:11 AM, Mike Jones =
wrote:
 
<=
div>
I agree with your goal of simplicity for clients.  Paul’s =
example seems about as simple as it can get for =
clients:
It shares the property with your earlier example (below) that clients =
have a no-branches code path to do =
discovery:
           &nbs=
p;   curl -s http://example.com/.well-known/host-meta|
           &nbs=
p;   awk "/lrdd/,/template/"|tr -d '\n'|sed -e =
"s/^.*template=3D'\([^']*\)'.*$/\1/"|
           &nbs=
p;   sed -e "s/{uri}/user@example.com/"|xargs curl =
–s
 
However, I challenge the assumption in your note below that servers =
using only static pages must be supported.  I just don’t =
see the requirement to implement a query parameter as being an =
impediment in practice, even for hosted domains.  I know of no =
hosting company that doesn’t provide a means of putting executable =
code behind web pages, be it PHP, Perl, Ruby, ASP, JSP, etc.  I =
know you’re trying to make the case for static pages, but in =
practice, I believe that dynamic pages are always easily =
available.
 
Assuming that we’re in an either-or situation with regard to =
either having single-GET discovery or supporting discovery using only =
static server pages (and I’d love to have someone demonstrate to =
us that we’re not), I’d take single-GET discovery for sure, =
as in some cases, it makes an appreciable difference in user interface =
latency, and per the paragraph above, I believe that dynamic queries can =
be implemented on all hosting =
platforms.
 
Assuming the WebFinger authors agree, I’d suggest that a =
logical next step would be for a -04 version of =
draft-jones-appsawg-webfinger to be published that changes support for =
the resource parameter from RECOMMENDED to REQUIRED, as that could =
provide a starting point for a common discovery =
spec.
 
           &nbs=
p;            =
;            =
            &=
nbsp;           -- =
Mike
 
P.S.  As long as draft-jones-appsawg-webfinger is being revised, =
I’d also suggest adding text making explicit what has been an =
implicit assumption in both WebFinger and SWD - that depending upon =
whether and how the client is authenticated, the set of resources =
returned may vary (as Blaine had pointed out earlier).  That could =
help deal with some of the privacy =
perceptions.
 
From:=
 apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf =
Of Blaine Cook
Sent: Sunday, April 22, 2012 2:15 =
PM
To: apps-discuss@ietf.org
Subject: [apps=
-discuss] Webfinger / SWD Issue #3: direct versus indirect =
discovery
 
This is the last issue that I've flagged as blocking a =
new Webfinger / SWD draft.
 
<=
p class=3DMsoNormal>Mike suggested that being able to request a user's =
profile with a single request (i.e., that the /.well-known/ profile =
resource should be able to respond with full profile data immediately, =
rather than pointing at a second URL that will fulfil the request) is a =
requirement for this =
standard.
 
<=
p class=3DMsoNormal>I'd like to challenge that requirement. The =
arguments for a direct discovery endpoint =
are:
 
<=
p class=3DMsoNormal>1. Fewer requests against the server, since we save =
(in the worst-case) 50% of requests by bypassing the indirect lookup =
phase.
2. Lower latency for clients (e.g., mobile clients) =
owing to the reduced number of =
lookups.
 
<=
p class=3DMsoNormal>The arguments for an indirect discovery endpoint =
are:
 
<=
p class=3DMsoNormal>1. Trivial and web-standards friendly deployment for =
domains that won't host their own webfinger/swd profile servers, but =
want to enable accounts on their domains (e.g., statically hosted =
sites).
2. A loosening of the requirement that URLs at the =
bare domain must run dynamic scripts that respond to requests to the =
/.well-known/ path.
 
<=
p class=3DMsoNormal>My opinion is that the approach that SWD has =
proposed for the redirect is problematic. First, the format is very =
similar in form to the HTML "meta refresh" tag that provided =
HTTP redirect support from within HTML. That format has been widely =
deprecated, and in these more enlightened times, we just use the 3xx =
response codes with Location headers, =
instead.
 
<=
p class=3DMsoNormal>Secondly, the SWD request format means that for =
smaller sites, often those with the least resources, will end up serving =
static content in a way that's difficult to cache; certainly, more =
difficult to cache than just serving static content. This is due to the =
request parameters present in all SWD requests; those request parameters =
will bust caches.
 
<=
p class=3DMsoNormal>As for the first argument *for* SWD's approach, I'd =
suggest we look to DNS, which uses the same indirection approach for NS =
records, relying on a (relatively) very small set of root servers to =
handle the traffic for the whole internet. Clearly, this approach works, =
and webfinger/swd servers are in a much better position to handle this =
additional traffic. Most of this traffic will be heavily cached, =
especially for the largest =
providers.
 
In fact, in terms of real deployments, =
hosting a script at, e.g., google.com/.well-known/simple-web-discovery is=
 much harder than hosting a script atprofiles.google.com/profile.json for all =
sorts of reasons, so it's my belief that the first argument is a red =
herring.
 
<=
p class=3DMsoNormal>The second argument is legitimate, but only if =
mobile clients will actually be making requests to diverse webfinger/swd =
hosts. Instead, I strongly believe that we'll see the emergence of =
DNS-like servers that provide both profile hosting as well as proxy =
services. For a mobile client, the optimal approach will be to use SPDY =
to connect to a single host that performs webfinger/swd lookups on the =
mobile client's behalf, eliminating the latency =
concerns.
 
<=
p class=3DMsoNormal>I offer that the two-step lookup can be implemented =
without conditionals on the client, whereas the direct-unless-not =
approach cannot be implemented that way (see my earlier curl example for =
proof). It's simpler, and easier to explain to the (hopefully many) =
small site owners who we'd like to implement this =
technology.
 
<=
p class=3DMsoNormal>Thoughts? Am I missing =
something?
 
<=
p =
class=3DMsoNormal>b.
_________=
______________________________________
apps-discuss mailing =
list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<=
/span>
 

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

------=_NextPart_000_05FD_01CD2327.98193D20--


From eran@hueniverse.com  Wed Apr 25 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 4AD5D11E80B2 for ; Wed, 25 Apr 2012 18:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level: 
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFUN2sHJUR8K for ; Wed, 25 Apr 2012 18:24:57 -0700 (PDT)
Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5C94011E80B1 for ; Wed, 25 Apr 2012 18:24:57 -0700 (PDT)
Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id 2RQw1j0020EuLVk01RQwfd; Wed, 25 Apr 2012 18:24:56 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Wed, 25 Apr 2012 18:24:56 -0700
From: Eran Hammer 
To: John Bradley 
Thread-Topic: [apps-discuss] WF flow with rel parameter
Thread-Index: AQHNIomKaCym1aAtdUm4KjKnInrNO5ard+qAgACDoID//6IRMIAAgkAA//+ZoSCAAIr5AP//lX+QABAztYAADUhqUP//qJcAgABmnVCAAIQo4A==
Date: Thu, 26 Apr 2012 01:24:56 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20100B8A3@P3PWEX2MB008.ex2.secureserver.net>
References: <2462F73D-62A4-4DAB-B3F7-806B65BCB96F@mac.com> <23240850-53E2-482F-BC71-C3EF7D08E232@ve7jtb.com> <042501cd22a3$d37d24a0$7a776de0$@packetizer.com> <7528AA0D-4BF5-46BE-8AD1-128CB48A8ED1@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201007020@P3PWEX2MB008.ex2.secureserver.net> <515663DA-67BF-4367-9AD9-6E940424CBCD@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20100990A@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA201009E4D@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA20100AEA2@P3PWEX2MB008.ex2.secureserver.net> <1699AC2D-56DD-44F1-BA51-5E01CCA43E26@ve7jtb.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WF flow with rel parameter
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Apr 2012 01:24:59 -0000

I messed this up and ended up confusing everyone. Here is the corrected res=
ponse:

If your host-meta is:

{
  "links":[
    {
      "rel":"example",
      "href":"http://example.com/1"
    },
    {
      "rel":"lrdd",
      "template":"http://example.com/lrdd?resource=3D{uri}"
    },
    {
      "rel":"example",
      "template":"http://example.com/2?q=3D{uri}"
    }
  ]
}

And your LRDD document always return:

{
  "links":[
    {
      "rel":"example",
      "href":"http://example.com/3"
    }
  ]
}

Then a host-wide request:

GET /.well-known/host-meta.json?rel=3Dexample

Will return (I haven't checked the exact format of the latest draft so the =
syntax might be wrong here):

{
  "links":[
    {
      "rel":"example",
      "href":"http://example.com/1"
    }
  ]
}

And a resource-specific request (not escaped for readability):

GET /.well-known/host-meta.json?resource=3Dhttp://example.com/resource

Will return:

{
  "links":[
    {
      "rel":"example",
      "href":"http://example.com/3"
    },
    {
      "rel":"example",
      "href":"http://example.com/2?q=3Dhttp://example.com/resource"
    }
  ]
}

EH


> -----Original Message-----
> From: Eran Hammer
> Sent: Wednesday, April 25, 2012 2:12 PM
> To: 'John Bradley'
> Cc: Paul E. Jones; apps-discuss@ietf.org
> Subject: RE: [apps-discuss] WF flow with rel parameter
>=20
> If your host-meta is:
>=20
> {
>   "links":[
>     {
>       "rel":"example",
>       "href":"http://example.com/1"
>     },
>     {
>       "rel":"lrdd",
>       "template":"http://example.com/lrdd?resource=3D{uri}"
>     },
>     {
>       "rel":"example",
>       "template":"http://example.com/2"
>     }
>   ]
> }
>=20
> And your LRDD document always return:
>=20
> {
>   "links":[
>     {
>       "rel":"example",
>       "template":"http://example.com/3"
>     }
>   ]
> }
>=20
> Then a host-wide request:
>=20
> GET /.well-known/host-meta.json?rel=3Dexample
>=20
> Will return (I haven't checked the exact format of the latest draft so th=
e
> syntax might be wrong here):
>=20
> {
>   "links":[
>     {
>       "rel":"example",
>       "href":"http://example.com/1"
>     }
>   ]
> }
>=20
> And a resource-specific request (not escaped for readability):
>=20
> GET /.well-known/host-meta.json?resource=3Dhttp://example.com/resource
>=20
> Will return:
>=20
> {
>   "links":[
>     {
>       "rel":"example",
>       "href":"http://example.com/1"
>     },
>     {
>       "rel":"example",
>       "href":"http://example.com/2"
>     }
>   ]
> }
>=20
> Does this help?
>=20
> EH
>=20
> > -----Original Message-----
> > From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> > Sent: Wednesday, April 25, 2012 1:08 PM
> > To: Eran Hammer
> > Cc: Paul E. Jones; apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] WF flow with rel parameter
> >
> > So the merged output if there is one in the host-meta and one in the
> > resource JRD is more like:
> > "links" :
> > {
> >       "rel" : "http://openid.net/specs/connect/issuer",
> >       "template" : "https://server.example.com"
> >     },
> > {
> >       "rel" : "http://openid.net/specs/connect/issuer",
> >       "href" : "https://server.example.com"
> >     }
> > }
> >
> > Is that correct?
> >
> > John B.
> >
> > On 2012-04-25, at 4:42 PM, Eran Hammer wrote:
> >
> > >
> > >
> > >> -----Original Message-----
> > >> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> > >> Sent: Wednesday, April 25, 2012 12:00 PM
> > >> To: Eran Hammer
> > >> Cc: Paul E. Jones; apps-discuss@ietf.org
> > >> Subject: Re: [apps-discuss] WF flow with rel parameter
> > >>
> > >> OK so host-meta is one level of lrdd link processing for a resource
> > >> (not
> > host).
> > >>
> > >> Multiple lrdd links are not precluded, but are an abuse.
> > >>
> > >> If you want to redirect to an alternate host-meta location you use
> > >> 3xx and the client will follow.
> > >> (I heard some complaining about what if my site can't support
> > >> redirects
> > >> earlier.)
> > >>
> > >> The links are aggregated with host-meta links and filtered by "rel".
> > >>
> > >> So if in host-meta I have:
> > >> {
> > >>       "rel" : "http://openid.net/specs/connect/issuer",
> > >>       "href" : "https://server.example.com"
> > >>     }
> > >>
> > >> before my lrdd entry
> > >
> > > Only if you change 'href' above to 'template'. 'href' are host-wide
> > > only and
> > do not apply to resource-specific.
> > >
> > > If you make a host-wide request, lrdd links and all templates are ign=
ored.
> > > If you make a resource-specific request, all href links in host-meta
> > > are
> > ignored, templates expanded, and lrdd templates followed and included
> > inline.
> > >
> > > EH
> > >
> > >> That would be returned in the filtered list before any resource
> > >> specific
> > "rel" ?
> > >>
> > >> Thus making a global setting for all resources.
> > >>
> > >> I don't think the original Connect proposal had per user discovery
> > >> only per host via host meta without following lrdd.
> > >>
> > >> If aggrigating and sorting links are a requirement, that needs to
> > >> be done server side for Connect clients.
> > >>
> > >> John B.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On 2012-04-25, at 3:29 PM, Eran Hammer wrote:
> > >>
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> > >>>> Sent: Wednesday, April 25, 2012 10:38 AM
> > >>>> To: Eran Hammer
> > >>>> Cc: Paul E. Jones; apps-discuss@ietf.org
> > >>>> Subject: Re: [apps-discuss] WF flow with rel parameter
> > >>>>
> > >>>> Eran,
> > >>>>
> > >>>> It was unclear, at least to me that the server side host-meta
> > >>>> processing
> > >> rule
> > >>>> specified in WF requires all the templates (or just the LRDD
> > >>>> ones) to be processed substituting inserting "resource" for URI
> > >>>> and then retrieving
> > >> and
> > >>>> merging all the resource JRD before processing the filter on the "=
rel".
> > >>>>
> > >>>> If I defined a rel of FOO would WF fill the template and retrieve
> > >>>> the JRD
> > >> and
> > >>>> merge its links with the lrdd JRD?
> > >>>> I might think that would be a touch confusing to clients.
> > >>>
> > >>> No. It only does *one* level of LRDD import (in order). See:
> > >>>
> > >>> http://tools.ietf.org/html/rfc6415#section-4.2
> > >>>
> > >>>> So I go back to the rational explanation that lrdd templates are
> > expanded
> > >> and
> > >>>> those links rolled up and filtered.
> > >>>>
> > >>>> Now I am guessing that some of the SWD people are thinking that
> > when
> > >> the
> > >>>> server is using flat files that puts a lot of burden onto the clie=
nt.
> > >>>>
> > >>>> Probably why you added the server side processing.
> > >>>
> > >>> The idea of adding server-side processing and filtering via the
> > >>> query
> > came
> > >> out of the original OpenID Connect proposal that David Recordon and
> > >> I wrote, trying to keep the clients super simple and avoid the need
> > >> to go
> > fetch
> > >> host-meta, then one or more LRDD documents.
> > >>>
> > >>> Complexity is very much implementation specific on the server side.
> > Yahoo
> > >> doesn't have LRDD documents and puts everything as link templates
> > >> in
> > host-
> > >> meta while others like the ability to customize. The most likely
> > >> scenario of servers including LRDD links in host-meta is that the
> > >> host-meta document
> > is
> > >> static, while the LRDD links are dynamically generated. Otherwise,
> > >> there is very little value in the added complexity. In that case,
> > >> the client will
> > typically
> > >> be faced with 2 requests.
> > >>>
> > >>> I would argue that a server using multiple LRDD links in host-meta
> > >>> is
> > abusing
> > >> the system, very much like a server using multiple 3xx redirections
> > between
> > >> its initial host-meta endpoint to where the document actually lives.
> > >>>
> > >>> IOW, there are many ways to inflict pain on the client.
> > >>>
> > >>>> Given that WF takes the liberty of adding query parameters to
> > >>>> host-
> > meta
> > >>>> and seems to define host-meta processing rules (perhaps for non
> > lrdd?), I
> > >>>> am not finding the separation of the two specs as clean as possibl=
e.
> > >>>> It seems a bit like there is there a RFC 6415 dependency on WF.
> > Though
> > >> that
> > >>>> is a touch strange for a RFC.
> > >>>
> > >>> The WF draft should not introduce any new processing rules. It
> > >>> should
> > only
> > >> add the query optimization but that must result in exactly the same
> > >> set of links as defined by 6415. If this is the case, it's a bug.
> > >>>
> > >>>> What stops someone from defining a relation of super-discovery
> > >>>> and
> > >> adding
> > >>>> some query parameters to host-meta.json to hover up some lrdd
> > based
> > >> on a
> > >>>> template expansion of  "super-discovery" rel types, and filter on
> "rel"?
> > >>>>
> > >>>> I wouldn't have thought to do that because stepping on the RFC
> > >>>> 6415 endpoint seems slightly wrong to me.
> > >>>>
> > >>>> I would probably define a new endpoint
> > >>>> /.well-known/super-discovery
> > >> with
> > >>>> my own query parameters and processing rules for JRD documents.
> > >>>
> > >>> That would be the right approach. Note that 6415 registers both
> > >>> host-
> > meta
> > >> (defaults to XML) and host-meta.json (JSON required).
> > >>>
> > >>>> Without being able to make server-side processing of host-meta
> > >> required,
> > >>>> we need someway to delegate that to another endpoint.
> > >>>>
> > >>>> In XRD we did discuss delegating the entire XRD.  Is there a way
> > >>>> to do
> > that
> > >> in
> > >>>> host-meta?
> > >>>
> > >>> 3xx.
> > >>>
> > >>> EH
> > >>>
> > >>>> At the moment all of the processing gets pushed back on the
> > >>>> client if
> > the
> > >>>> host only supports static files in /.well-known
> > >>>>
> > >>>> John B.
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 2012-04-25, at 1:34 PM, Eran Hammer wrote:
> > >>>>
> > >>>>> It is important to understand the semantics of host-meta, which
> > >>>>> I
> > think
> > >>>> there is some confusion about here.
> > >>>>>
> > >>>>> As a mechanism, host-meta providers you with a method of
> > >>>>> obtaining
> > >> both
> > >>>> host-wide and resource-specific links (and properties). To
> > >>>> accomplish
> > >> that, it
> > >>>> provides with both a document and processing rules.
> > >>>>>
> > >>>>> WebFinger - the name given for the host-meta *use-case* of
> > retrieving
> > >>>> user information - is a specialization of obtaining resource-speci=
fic
> links.
> > >>>>>
> > >>>>> The 'rel' and 'resource' query parameters (as proposed) apply to
> > >>>>> the
> > >>>> endpoint *after* executing the processing rules (which include
> > expanding
> > >>>> templates and importing links from one level LRDD documents).
> > >>>>>
> > >>>>> LRDD documents only apply to resource-specific links, which
> > >>>>> means
> > they
> > >>>> are ignored for any host-wide query. For example, the location of
> > >>>> the
> > >> site's
> > >>>> TOS document. From the host-meta perspective, LRDD documents
> are
> > >> just a
> > >>>> deployment tool to provide customization not possible using just
> > >>>> link templates at the host-meta document level. It's just a
> > >>>> link-include mechanism, and host-meta uses it restrictively.
> > >>>>>
> > >>>>> IMO, the 'rel' and 'resource' optimization should only apply to
> > >>>>> the
> > host-
> > >>>> meta endpoint, and act as a filter post the processing rules. If
> 'resource'
> > is
> > >>>> specified, it is a resource-specific request, otherwise, host-wide=
.
> > >>>>>
> > >>>>> Let me know if this helps or if it is still unclear.
> > >>>>>
> > >>>>> EH
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> > >>>>>> Sent: Wednesday, April 25, 2012 8:27 AM
> > >>>>>> To: Eran Hammer
> > >>>>>> Cc: Paul E. Jones; apps-discuss@ietf.org
> > >>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
> > >>>>>>
> > >>>>>> That was one thing that initially confused me.  The rel filter
> > >>>>>> is not
> > >> applied
> > >>>> to
> > >>>>>> host-meta, but rather the linked lrdd resource JRD.
> > >>>>>>
> > >>>>>> The currently defined "resource" parameter has an implicit
> > >>>>>> host-
> > meta
> > >>>> "rel"
> > >>>>>> of "lrdd".
> > >>>>>>
> > >>>>>> To use this mechanism for other relations you would need to
> > >>>>>> make
> > that
> > >>>>>> parameter explicit.
> > >>>>>>
> > >>>>>> That then raises the question of the filter being part of
> > >>>>>> host-meta or
> > >> WF if
> > >>>> it
> > >>>>>> applies to relationships other than lrdd.
> > >>>>>>
> > >>>>>> If you are asking if filtering should be supported by lrdd
> > >>>>>> where you
> > start
> > >>>>>> discovery from a link header, then it probably should be
> > >>>>>> possible as
> > >> well.
> > >>>>>>
> > >>>>>> Though I thought lrdd stopped being updated over a year a year
> ago.
> > >>>> Sorry if
> > >>>>>> I am out of date.
> > >>>>>>
> > >>>>>> So XRD/JRD documents SHOULD be filterable by "rel" independent
> > of if
> > >>>> you
> > >>>>>> get to them via lrdd or host-meta.
> > >>>>>>
> > >>>>>> Host-meta SHOULD support a mechanism to filter by "rel" or
> > >>>>>> filter by
> > a
> > >>>>>> combination of "resource" (uri) , host-meta-rel and
> > >>>>>> resource-rel (the
> > >>>> host-
> > >>>>>> meta-rel is currently implicit.)
> > >>>>>>
> > >>>>>> I recall discussing this in the XRI TC when we did XRD years
> > >>>>>> ago,
> > though
> > >>>> that
> > >>>>>> was more around using XRI identifiers.
> > >>>>>>
> > >>>>>> The same principal still holds.  I should be able to ask for.
> > >>>>>> GET /.well-known/host-meta.json
> > >>>>>>   ?resource=3Djoe@example.com
> > >>>>>>   &host-meta-rel=3Dlrdd
> > >>>>>>
> > >>>>
> > &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> > >>>>>> HTTP/1.1
> > >>>>>> Host: example.com
> > >>>>>>
> > >>>>>> (personally I think calling the parameter "resource" and the
> > >>>>>> template
> > >> {uri}
> > >>>>>> will be confusing to people)
> > >>>>>>
> > >>>>>> In SWD we used fixed the parameter names and the base URI is
> > >>>>>> the
> > >> part
> > >>>> that
> > >>>>>> gets changed when the /.well-known can't host a script.
> > >>>>>> That makes the template simpler for the client to process.  The
> > >> equivalent
> > >>>> to
> > >>>>>> "rel" is always passed to make processing simpler.
> > >>>>>>
> > >>>>>> As Blaine has pointed out several times SWD and WF largely get
> > >>>>>> us to
> > >> the
> > >>>>>> same place.
> > >>>>>>
> > >>>>>> I am trying to find a way to close the gap.
> > >>>>>>
> > >>>>>> John B.
> > >>>>>>
> > >>>>>>
> > >>>>>> On 2012-04-25, at 11:41 AM, Eran Hammer wrote:
> > >>>>>>
> > >>>>>>> Purely from a practical standpoint, do you think it is likely
> > >>>>>>> that a
> > server
> > >>>> will
> > >>>>>> support the query filter for the lrdd documents but not for
> > >>>>>> host-
> > meta?
> > >>>>>>>
> > >>>>>>> EH
> > >>>>>>>
> > >>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> > >>>>>> bounces@ietf.org] On Behalf Of John Bradley
> > >>>>>>> Sent: Wednesday, April 25, 2012 6:17 AM
> > >>>>>>> To: Paul E. Jones
> > >>>>>>> Cc: apps-discuss@ietf.org
> > >>>>>>> Subject: Re: [apps-discuss] WF flow with rel parameter
> > >>>>>>>
> > >>>>>>> Paul,
> > >>>>>>>
> > >>>>>>> "rel" as a filter is something WF has for host-meta.  It
> > >>>>>>> however
> > doesn't
> > >>>>>> seem to have that for user JRD in the case where host-meta is
> > >> returned,
> > >>>> and
> > >>>>>> the template is used.
> > >>>>>>>
> > >>>>>>> The "resource" and "rel" parameters are already an
> > >>>>>>> optimization
> > for
> > >>>> LRDD
> > >>>>>> and not part of host-meta.
> > >>>>>>> Adding LRDD specific parameters to host-meta/host-meta.json
> > >>>>>>> will
> > >>>>>> probably raise some eyebrows in review, but I am OK with it.
> > >>>>>>>
> > >>>>>>> I think there are use cases where size matters.  Where a
> > >>>>>>> host-meta
> > or
> > >>>>>> resource JRD may be large and it is more efficient not to send
> > >>>>>> the
> > >> whole
> > >>>>>> thing to a mobile client.
> > >>>>>>> It seems to be one of Mike Jones requirements.
> > >>>>>>>
> > >>>>>>> Using RFC6570 for LRDD is a possibility for passing through
> > >>>>>>> the filter
> > >>>> request
> > >>>>>> for sites that support filtering on resource JRD.
> > >>>>>>>
> > >>>>>>> What other proposals do you have.  I am guessing that
> > >>>>>>> filtering on
> > >>>> resource
> > >>>>>> JRD is not a totally new topic.
> > >>>>>>>
> > >>>>>>> LRDD is the one really doing the optimization  in any event,
> > >>>>>>> it may
> > be
> > >>>> done
> > >>>>>> at the host-meta GET but it is a LRDD specific extension.
> > >>>>>>> Having it in the template allows LRDD to filter at the
> > >>>>>>> resource JRD in
> > >>>> cases
> > >>>>>> where it is not possible to do it at the host-meta level, due
> > >>>>>> to some
> > no
> > >>>> script
> > >>>>>> or other restriction.
> > >>>>>>>
> > >>>>>>> I agree that it should be filtered at the how-meta request but
> > >>>>>>> you
> > and
> > >>>>>> others say that is not always possible.
> > >>>>>>>
> > >>>>>>> John B.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> John,
> > >>>>>>>
> > >>>>>>> The "rel" parameter is something we still need to discuss, so
> > >>>>>>> not is
> > as
> > >>>> good
> > >>>>>> a time as any.
> > >>>>>>>
> > >>>>>>> What "rel" does is act as a filter.  For the most part, the
> > >>>>>>> only
> > purpose it
> > >>>>>> serves is to help reduce the number of link relations that
> > >>>>>> might be
> > sent
> > >>>> from
> > >>>>>> the server.  So, if a user had 1,000 different link relations,
> > >>>>>> this might
> > >>>> reduce
> > >>>>>> the returned message to containing only 1.  However, if a user
> > >>>>>> has
> > >> more
> > >>>> than
> > >>>>>> one link relation of the same type, all of them would match and
> > >>>>>> be
> > >>>> returned.
> > >>>>>>>
> > >>>>>>> When you say the host cannot support re-write rules, I assume
> > >>>>>>> you
> > >>>> mean it
> > >>>>>> does not support the URI parameters on host-meta?  In that
> > >>>>>> case,
> > yes,
> > >>>> the
> > >>>>>> parameters are ignored and you get just the host-meta document.
> > >>>>>>>
> > >>>>>>> The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1=
.1).
> > >> There
> > >>>> are
> > >>>>>> no other URI template values defined.  (Note: this whole
> > >>>>>> section
> > exists
> > >>>> only
> > >>>>>> because RFC  6570 did not yet exist, I think.
> > >>>>>>>
> > >>>>>>> In any case, we could define a new URI template, but then we
> > would
> > >> be
> > >>>>>> putting an optimization in place for LRDD.  If host-meta is not
> > >>>>>> going
> > to
> > >>>>>> support the "rel" URI parameter, why would LRDD?  It would also
> > mean
> > >>>> that
> > >>>>>> the LRDD logic would have to be ready to receive a URI
> > >>>>>> parameter
> > that
> > >> is
> > >>>> not
> > >>>>>> replaced, since some clients would only change {uri} and leave
> > >>>>>> {rel}
> > >> there.
> > >>>>>> That would introduce more conditional logic in the server.
> > >>>>>> This
> > would
> > >> also
> > >>>>>> present issues with static sites.  (Of course, one might be
> > >>>>>> able to use
> > >>>> Apache
> > >>>>>> re-writing rules to get around that problem, but it certainly
> > >>>>>> would
> > not
> > >>>> work
> > >>>>>> for "real" static sites.)
> > >>>>>>>
> > >>>>>>> Personally,  I'd prefer to not add the "rel" parameter to
> > >>>>>>> LRDD, since
> > I
> > >>>> think
> > >>>>>> optimization using "rel" would always be done on host-meta.
> > >>>>>> That
> > said,
> > >> I
> > >>>>>> question the value of "rel" entirely.  Do you think it's useful
> > >>>>>> to have
> > this
> > >>>> filter
> > >>>>>> at all?  Is there really a risk that a site might return 1,000
> > >>>>>> link relations
> > >> that
> > >>>> the
> > >>>>>> client would have to step over?
> > >>>>>>>
> > >>>>>>> Paul
> > >>>>>>>
> > >>>>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> > >>>>>>> Sent: Tuesday, April 24, 2012 10:17 PM
> > >>>>>>> To: Paul E. Jones
> > >>>>>>> Cc: apps-discuss@ietf.org
> > >>>>>>> Subject: WF flow with rel parameter
> > >>>>>>>
> > >>>>>>> Paul,
> > >>>>>>>
> > >>>>>>> Sorry I hit send on the previous message with a typo.
> > >>>>>>>
> > >>>>>>> I am looking at how the flows in WF might work for openID.
> > >>>>>>>
> > >>>>>>> Let's set aside the XML issue for the moment and focus on the
> > JSON
> > >>>> flow.
> > >>>>>>>
> > >>>>>>> Please correct anything I get wrong.
> > >>>>>>>
> > >>>>>>> The openID Connect defines a relation of
> > >>>>>> http://openid.net/specs/connect/issuer
> > >>>>>>>
> > >>>>>>> WF allows for a JSON host-meta that takes two parameters,
> > >> "resource"
> > >>>> and
> > >>>>>> "rel"
> > >>>>>>>
> > >>>>>>> An example request and response (line-brakes for readability)
> > >>>>>>>
> > >>>>>>> GET /.well-known/host-meta.json
> > >>>>>>>   ?resource=3Djoe@example.com
> > >>>>>>>
> > >>>>
> > &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> > >>>>>> HTTP/1.1
> > >>>>>>> Host: example.com
> > >>>>>>>
> > >>>>>>> HTTP/1.1 200 OK
> > >>>>>>>
> > >>>>>>> Access-Control-Allow-Origin: *
> > >>>>>>> Content-Type: application/json; charset=3DUTF-8
> > >>>>>>>
> > >>>>>>> {
> > >>>>>>>   "subject" : "joe@example.com",
> > >>>>>>>   "links" :
> > >>>>>>>   [
> > >>>>>>>     {
> > >>>>>>>       "rel" : "http://openid.net/specs/connect/issuer",
> > >>>>>>>       "href" : "https://server.example.com"
> > >>>>>>>     }
> > >>>>>>>   ]
> > >>>>>>> }
> > >>>>>>>
> > >>>>>>> If the host can't support rewrite rules or scripts the
> > >>>>>>> exchange
> > would
> > >> look
> > >>>>>> like:
> > >>>>>>>
> > >>>>>>> GET /.well-known/host-meta.json
> > >>>>>>>   ?resource=3Djoe@example.com
> > >>>>>>>
> > >>>>
> > &rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> > >>>>>> HTTP/1.1
> > >>>>>>> Host: example.com
> > >>>>>>>
> > >>>>>>> HTTP/1.1 200 OK
> > >>>>>>> Access-Control-Allow-Origin: *
> > >>>>>>> Content-Type: application/json; charset=3DUTF-8 {
> > >>>>>>>   "expires" : "2012-03-13T20:56:11Z",
> > >>>>>>>   "links" :
> > >>>>>>>   [
> > >>>>>>>     {
> > >>>>>>>       "rel" : "lrdd",
> > >>>>>>>       "type" : "application/json",
> > >>>>>>>       "template" :
> > >>>>>>>         "https://example.com/lrdd/?format=3Djson&resource=3D{ur=
i}"
> > >>>>>>>     }
> > >>>>>>>
> > >>>>>>> GET /lrdd/
> > >>>>>>>   ?format=3Djson
> > >>>>>>>   &resource=3Djoe@example.com
> > >>>>>>> Host: example.com
> > >>>>>>>
> > >>>>>>> HTTP/1.1 200 OK
> > >>>>>>>
> > >>>>>>> Access-Control-Allow-Origin: *
> > >>>>>>> Content-Type: application/json; charset=3DUTF-8
> > >>>>>>>
> > >>>>>>> {
> > >>>>>>>   "subject" : "joe@example.com",
> > >>>>>>>   "links" :
> > >>>>>>>   [
> > >>>>>>>     {
> > >>>>>>>       "rel" : "http://openid.net/specs/connect/issuer",
> > >>>>>>>       "href" : "https://server.example.com"
> > >>>>>>>     },
> > >>>>>>>     {
> > >>>>>>>       "rel" : "http://webfinger.net/rel/avatar",
> > >>>>>>>       "href" : "http://example.com/~joe/joe.jpg"
> > >>>>>>>     }
> > >>>>>>>
> > >>>>>>>   ]
> > >>>>>>> }
> > >>>>>>>
> > >>>>>>> I can't find a template parameter for "rel".  The host-meta
> > >>>>>>> spec
> > allows
> > >>>> for
> > >>>>>> extension but it is missing.
> > >>>>>>>
> > >>>>>>> What if the server wants to support filtering on rel but can't
> > support it
> > >> in
> > >>>>>> the root for some reason?
> > >>>>>>>
> > >>>>>>> Is it possible to have a template like:
> > >>>>>>>
> > "https://example.com/lrdd/?format=3Djson&resource=3D{uri}&rel=3D{rel}"
> > >>>>>>>
> > >>>>>>> That simple addition may solve a number of problems for openID.
> > >>>>>>>
> > >>>>>>> John B.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> > >


From ve7jtb@ve7jtb.com  Wed Apr 25 18:27: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 2B08221F8619 for ; Wed, 25 Apr 2012 18:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.512
X-Spam-Level: 
X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52qvannOsCan for ; Wed, 25 Apr 2012 18:27:57 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E8B3821F8618 for ; Wed, 25 Apr 2012 18:27:56 -0700 (PDT)
Received: by qaea16 with SMTP id a16so1201720qae.10 for ; Wed, 25 Apr 2012 18:27:56 -0700 (PDT)
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=mkXr8YSGts8lHhOzJxAb/XSgwMBLc3OGkE2IGcsYQjo=; b=Z/UpAjJ9Ik6mDKJqqf+LjI++4F7LqwuMZCvhM8175mACTE8wAQFn3n2ggZ950/vfmg bbbGcMW+N2Ukk6p1oKejP/AEoC4RlvyR+HB8sD/6xyMMacHHnqnyvcKx5BJyWp/Ul7fg oeRPa1x/C47V4Uk+IyYnbzkerfkFPEB+qcqPNTIgMz4NHZ3XkSj0ETUhGDkGNIUmbAaP SqzE7xdc3ttdEnddjPWv6GhbrRwocfvgprPALJ++kenQ77lqpWi6MtHnSQMwhNt4UE2O bHxskKG1FKUldn4Le0MwsPIlWDDV7yyiFCUXtHeN1s/4PRixLeG6hNf+zPhaaBFEvc3Q sVxg==
Received: by 10.224.202.66 with SMTP id fd2mr3963751qab.9.1335403675704; Wed, 25 Apr 2012 18:27:55 -0700 (PDT)
Received: from [192.168.1.213] (190-20-63-108.baf.movistar.cl. [190.20.63.108]) by mx.google.com with ESMTPS id gy2sm3189451qab.10.2012.04.25.18.27.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 18:27:54 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_BC63C53A-7140-4F0E-9962-2F61C975AC78"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <05fc01cd2349$1f281e00$5d785a00$@packetizer.com>
Date: Wed, 25 Apr 2012 22:27:47 -0300
Message-Id: <930BD33E-BCB8-4158-868D-575CB97248E1@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com> <054901cd2311$87a24fb0$96e6ef10$@packetizer.com> <4CC716F1-F6A4-46CF-86FD-6636B1F84500@ve7jtb.com> <05fc01cd2349$1f281e00$5d785a00$@packetizer.com>
To: "Paul E. Jones" 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQnOfb0GtiJDh3o0tGexfcSjQrTFEm/mEpdSCfFeOXyQm7hxTyIov1nSPR9vkheUUiM0pfxr
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Apr 2012 01:27:59 -0000

--Apple-Mail=_BC63C53A-7140-4F0E-9962-2F61C975AC78
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_CABEDAFB-F959-45A6-ADF7-C87057127316"


--Apple-Mail=_CABEDAFB-F959-45A6-ADF7-C87057127316
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Some of the rewriting rules Eran described make putting resource =
specific stuff in host-meta a challenge for a simple site.

Is their agreement on making resource REQUIRED.   I still have a feeling =
that some people (Blaine?) may not be bought into that.

I agree that you have a simple solution that covers most of the =
situations as long as you don't put resource specific stuff in =
host-meta.

John B.
On 2012-04-25, at 10:08 PM, Paul E. Jones wrote:

> That=92s exactly what I=92d suggest for static sites=85 don=92t put =
resource specific stuff in host-meta.  For non-static sites, one could =
be more flexible.
> =20
> Paul
> =20
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Wednesday, April 25, 2012 3:13 PM
> To: Paul E. Jones
> Cc: 'Bob Wyman'; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus =
indirect discovery
> =20
> If WF were to make resource REQUIRED and rel optional that would be a =
significant step forward.
> =20
> Though the Apache http rewrite probably violates the host-meta =
processing rules Eran just described, if the links from host-meta must =
be included in order.
> You could get around it by restricting the contents of host-meta if =
you are doing that I suppose.
> =20
> John B.
> =20
> =20
> On 2012-04-25, at 3:30 PM, Paul E. Jones wrote:
>=20
>=20
> John,
> =20
> I don=92t think we need to decide specific environments we want to =
support, but *if* people want to use static files, there are choices we =
can make where the resource parameter will still work, even in a static =
environment.  Previously, I sent out a sample config that allows Apache =
to handle the =93resource=94 parameter and still map that to static =
files.  However, I cannot do the same with the =93rel=94 parameter, thus =
we could never mandate that if we want to have any hope at all for =
allowing static sites.
> =20
> I appreciate having the =93resource=94 parameter, but I also =
appreciate some do not need (or have the ability to support) an =
elaborate server.
> =20
> Paul
> =20
> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley
> Sent: Monday, April 23, 2012 12:19 PM
> To: Bob Wyman
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus =
indirect discovery
> =20
> I understand that in some environments you may not have access to http =
rewrite rules. =20
> Others may preclude any scripts.
> =20
> We do have to decide what environments we are going to support.
> =20
> If we stick to static files only then we are just putting some =
lipstick on Yadis by adding a way to map a email like address to a file.
> =20
> So yes there are those environments, but that needs to be balanced =
against the additional overhead on the clients to support that =
environment.
> =20
> John B.
> =20
> On 2012-04-23, at 12:26 PM, Bob Wyman wrote:
>=20
>=20
>=20
> =20
>=20
> On Mon, Apr 23, 2012 at 11:08 AM, John Bradley  =
wrote:
> Mike,
> =20
> I think there is less resistance to making resource parameter REQUIRED =
than there is to removing the initial host-meta lookup to get the =
template.
> =20
> We should probably keep those issues separate.
> =20
> I agree that supporting indirect discovery of the template via =
host-meta.jason should probably stay.
> =20
> The question is if their can be an optimization that allows =
shortcutting that step if you know that all you want is web finger.
> =20
> A possible option for that could be using a fixed template in =
/.well-known/.
> =20
> That endpoint would return:
> a The terminal JRD (like SWD)
> b a 3xx redirect to the real endpoint
> Causing a 3xx redirect typically requires modification to the =
configuration files of a multi-host shared web server. Access to such =
configuration files is often restricted in such a way that those =
responsible from just one or a few of the sites sharing the common =
server are not permitted to make modifications to those files. In many =
cases, such modifications can be requested and will only be made after =
lengthy delays or the payment of support and maintenance fees.=20
> =20
> If we want this sort of discovery to become generally available, and =
not just be limited to the "large" sites, we should ensure that it is as =
simple as possible to deploy.
> =20
> c a copy of the host-meta.jrd
> =20
> We would probably only do one of b or c.
> =20
> c has the advantage of being a static file and you being no worse off =
than having started with host-meta.json.
> b is the simplest for the client and only requires common rewriting =
rules.
> =20
> If the redirect is to the same host you could avoid the overhead of =
two connections by pipelining the requests over the same TCP connection.
> SPDY in the future will make that even more efficient.
> =20
> I will grant Blaine that most openID Connect discovery requests are =
Server to Server,  However there are Apps that are also clients that =
should not be ignored.
> I personally like the fixed template with a 3xx redirect and  resource =
parameter returning a JRD due to the simplicity of client coding.
> =20
> Things needing other sorts of information about the host would still =
use host-meta or host-meta.json.
> =20
> John B.
> =20
> =20
> On 2012-04-23, at 1:11 AM, Mike Jones wrote:
> =20
> I agree with your goal of simplicity for clients.  Paul=92s example =
seems about as simple as it can get for clients:
>                curl -v =
https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paulej@p=
acketizer.com
> It shares the property with your earlier example (below) that clients =
have a no-branches code path to do discovery:
>                curl -s http://example.com/.well-known/host-meta|
>                awk "/lrdd/,/template/"|tr -d '\n'|sed -e =
"s/^.*template=3D'\([^']*\)'.*$/\1/"|
>                sed -e "s/{uri}/user@example.com/"|xargs curl =96s
> =20
> However, I challenge the assumption in your note below that servers =
using only static pages must be supported.  I just don=92t see the =
requirement to implement a query parameter as being an impediment in =
practice, even for hosted domains.  I know of no hosting company that =
doesn=92t provide a means of putting executable code behind web pages, =
be it PHP, Perl, Ruby, ASP, JSP, etc.  I know you=92re trying to make =
the case for static pages, but in practice, I believe that dynamic pages =
are always easily available.
> =20
> Assuming that we=92re in an either-or situation with regard to either =
having single-GET discovery or supporting discovery using only static =
server pages (and I=92d love to have someone demonstrate to us that =
we=92re not), I=92d take single-GET discovery for sure, as in some =
cases, it makes an appreciable difference in user interface latency, and =
per the paragraph above, I believe that dynamic queries can be =
implemented on all hosting platforms.
> =20
> Assuming the WebFinger authors agree, I=92d suggest that a logical =
next step would be for a -04 version of draft-jones-appsawg-webfinger to =
be published that changes support for the resource parameter from =
RECOMMENDED to REQUIRED, as that could provide a starting point for a =
common discovery spec.
> =20
>                                                             -- Mike
> =20
> P.S.  As long as draft-jones-appsawg-webfinger is being revised, I=92d =
also suggest adding text making explicit what has been an implicit =
assumption in both WebFinger and SWD - that depending upon whether and =
how the client is authenticated, the set of resources returned may vary =
(as Blaine had pointed out earlier).  That could help deal with some of =
the privacy perceptions.
> =20
> From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of Blaine Cook
> Sent: Sunday, April 22, 2012 2:15 PM
> To: apps-discuss@ietf.org
> Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus =
indirect discovery
> =20
> This is the last issue that I've flagged as blocking a new Webfinger / =
SWD draft.
> =20
> Mike suggested that being able to request a user's profile with a =
single request (i.e., that the /.well-known/ profile resource should be =
able to respond with full profile data immediately, rather than pointing =
at a second URL that will fulfil the request) is a requirement for this =
standard.
> =20
> I'd like to challenge that requirement. The arguments for a direct =
discovery endpoint are:
> =20
> 1. Fewer requests against the server, since we save (in the =
worst-case) 50% of requests by bypassing the indirect lookup phase.
> 2. Lower latency for clients (e.g., mobile clients) owing to the =
reduced number of lookups.
> =20
> The arguments for an indirect discovery endpoint are:
> =20
> 1. Trivial and web-standards friendly deployment for domains that =
won't host their own webfinger/swd profile servers, but want to enable =
accounts on their domains (e.g., statically hosted sites).
> 2. A loosening of the requirement that URLs at the bare domain must =
run dynamic scripts that respond to requests to the /.well-known/ path.
> =20
> My opinion is that the approach that SWD has proposed for the redirect =
is problematic. First, the format is very similar in form to the HTML =
"meta refresh" tag that provided HTTP redirect support from within HTML. =
That format has been widely deprecated, and in these more enlightened =
times, we just use the 3xx response codes with Location headers, =
instead.
> =20
> Secondly, the SWD request format means that for smaller sites, often =
those with the least resources, will end up serving static content in a =
way that's difficult to cache; certainly, more difficult to cache than =
just serving static content. This is due to the request parameters =
present in all SWD requests; those request parameters will bust caches.
> =20
> As for the first argument *for* SWD's approach, I'd suggest we look to =
DNS, which uses the same indirection approach for NS records, relying on =
a (relatively) very small set of root servers to handle the traffic for =
the whole internet. Clearly, this approach works, and webfinger/swd =
servers are in a much better position to handle this additional traffic. =
Most of this traffic will be heavily cached, especially for the largest =
providers.
> =20
> In fact, in terms of real deployments, hosting a script at, e.g., =
google.com/.well-known/simple-web-discovery is much harder than hosting =
a script atprofiles.google.com/profile.json for all sorts of reasons, so =
it's my belief that the first argument is a red herring.
> =20
> The second argument is legitimate, but only if mobile clients will =
actually be making requests to diverse webfinger/swd hosts. Instead, I =
strongly believe that we'll see the emergence of DNS-like servers that =
provide both profile hosting as well as proxy services. For a mobile =
client, the optimal approach will be to use SPDY to connect to a single =
host that performs webfinger/swd lookups on the mobile client's behalf, =
eliminating the latency concerns.
> =20
> I offer that the two-step lookup can be implemented without =
conditionals on the client, whereas the direct-unless-not approach =
cannot be implemented that way (see my earlier curl example for proof). =
It's simpler, and easier to explain to the (hopefully many) small site =
owners who we'd like to implement this technology.
> =20
> Thoughts? Am I missing something?
> =20
> b.
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> =20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> =20


--Apple-Mail=_CABEDAFB-F959-45A6-ADF7-C87057127316
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Some of the rewriting rules Eran described make =
putting resource specific stuff in host-meta a challenge for a simple =
site.

Is their agreement on making resource REQUIRED. =
  I still have a feeling that some people (Blaine?) may not be =
bought into that.

I agree that you have a =
simple solution that covers most of the situations as long as you don't =
put resource specific stuff in host-meta.

John =
B.
On 2012-04-25, at 10:08 PM, Paul E. Jones =
wrote:

 
Paul
 John =
Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, April 25, 2012 =
3:13 PM
To: Paul E. =
Jones
Cc: 'Bob=
 Wyman';  Re: [apps-discuss] =
Webfinger / SWD Issue #3: direct versus indirect =
discovery
 
<=
div>

_______________________________________________
apps-discuss =
mailing list
apps-discuss@ietf.org

To: "'John Bradley'" 
References: <4E1F6AAD24975D4BA5B168042967394366492EE5@TK5EX14MBXC284.redmond.corp.microsoft.com> <7AF88E80-2515-49A5-92F8-8C0CB9ED7F47@ve7jtb.com>  <943DD28B-D2AB-4247-B486-06C074C4BA12@ve7jtb.com> <054901cd2311$87a24fb0$96e6ef10$@packetizer.com> <4CC716F1-F6A4-46CF-86FD-6636B1F84500@ve7jtb.com> <05fc01cd2349$1f281e00$5d785a00$@packetizer.com> <930BD33E-BCB8-4158-868D-575CB97248E1@ve7jtb.com>
In-Reply-To: <930BD33E-BCB8-4158-868D-575CB97248E1@ve7jtb.com>
Date: Wed, 25 Apr 2012 21:59:13 -0400
Message-ID: <062901cd2350$2e161f50$8a425df0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_062A_01CD232E.A70828D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIJGNvIkGmsH/dlhis4V9nZDOGpGAKB6SPgAbGhC8kDARG59AGQmEgUATnvVS4CBfRbugK+pK75lb5PGrA=
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Apr 2012 01:59:16 -0000

This is a multipart message in MIME format.

------=_NextPart_000_062A_01CD232E.A70828D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

John,

 

For a static sites, I would expect either everything would come from
host-meta or LRDD, but not both.  I would only expect sites that are running
code to support WebFinger to put stuff in both host-meta and LRDD.

 

Here's an example of how to do a static site on Apache:

http://www.packetizer.com/webfinger/server.html

 

(I just wrote that, so I hope it's not full of errors.  It's not even that
late at night, yet, so I have little excuse for the typos I tend to produce
as the evening wears.)

 

For non-static sites, including small ones and large ones, then it does not
matter.  Size of the site is not a big deal.  It's really 'static' vs
'non-static'.  My site is relatively small, but it's got running code with
live examples pulled from a database.  So, for those who want to run an
"active" server, it's trivial to do.

 

Paul

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, April 25, 2012 9:28 PM
To: Paul E. Jones
Cc: 'Bob Wyman'; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect
discovery

 

Some of the rewriting rules Eran described make putting resource specific
stuff in host-meta a challenge for a simple site.

 

Is their agreement on making resource REQUIRED.   I still have a feeling
that some people (Blaine?) may not be bought into that.

 

I agree that you have a simple solution that covers most of the situations
as long as you don't put resource specific stuff in host-meta.

 

John B.

On 2012-04-25, at 10:08 PM, Paul E. Jones wrote:





That's exactly what I'd suggest for static sites. don't put resource
specific stuff in host-meta.  For non-static sites, one could be more
flexible.

 

Paul

 

From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, April 25, 2012 3:13 PM
To: Paul E. Jones
Cc: 'Bob Wyman'; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect
discovery

 

If WF were to make resource REQUIRED and rel optional that would be a
significant step forward.

 

Though the Apache http rewrite probably violates the host-meta processing
rules Eran just described, if the links from host-meta must be included in
order.

You could get around it by restricting the contents of host-meta if you are
doing that I suppose.

 

John B.

 

 

On 2012-04-25, at 3:30 PM, Paul E. Jones wrote:






John,

 

I don't think we need to decide specific environments we want to support,
but *if* people want to use static files, there are choices we can make
where the resource parameter will still work, even in a static environment.
Previously, I sent out a sample config that allows Apache to handle the
"resource" parameter and still map that to static files.  However, I cannot
do the same with the "rel" parameter, thus we could never mandate that if we
want to have any hope at all for allowing static sites.

 

I appreciate having the "resource" parameter, but I also appreciate some do
not need (or have the ability to support) an elaborate server.

 

Paul

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of John Bradley
Sent: Monday, April 23, 2012 12:19 PM
To: Bob Wyman
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect
discovery

 

I understand that in some environments you may not have access to http
rewrite rules.  

Others may preclude any scripts.

 

We do have to decide what environments we are going to support.

 

If we stick to static files only then we are just putting some lipstick on
Yadis by adding a way to map a email like address to a file.

 

So yes there are those environments, but that needs to be balanced against
the additional overhead on the clients to support that environment.

 

John B.

 

On 2012-04-23, at 12:26 PM, Bob Wyman wrote:







 

On Mon, Apr 23, 2012 at 11:08 AM, John Bradley  wrote:

Mike,

 

I think there is less resistance to making resource parameter REQUIRED than
there is to removing the initial host-meta lookup to get the template.

 

We should probably keep those issues separate.

 

I agree that supporting indirect discovery of the template via
host-meta.jason should probably stay.

 

The question is if their can be an optimization that allows shortcutting
that step if you know that all you want is web finger.

 

A possible option for that could be using a fixed template in /.well-known/.

 

That endpoint would return:

a The terminal JRD (like SWD)

b a 3xx redirect to the real endpoint

Causing a 3xx redirect typically requires modification to the configuration
files of a multi-host shared web server. Access to such configuration files
is often restricted in such a way that those responsible from just one or a
few of the sites sharing the common server are not permitted to make
modifications to those files. In many cases, such modifications can be
requested and will only be made after lengthy delays or the payment of
support and maintenance fees. 

 

If we want this sort of discovery to become generally available, and not
just be limited to the "large" sites, we should ensure that it is as simple
as possible to deploy.

 

c a copy of the host-meta.jrd

 

We would probably only do one of b or c.

 

c has the advantage of being a static file and you being no worse off than
having started with host-meta.json.

b is the simplest for the client and only requires common rewriting rules.

 

If the redirect is to the same host you could avoid the overhead of two
connections by pipelining the requests over the same TCP connection.

SPDY in the future will make that even more efficient.

 

I will grant Blaine that most openID Connect discovery requests are Server
to Server,  However there are Apps that are also clients that should not be
ignored.

I personally like the fixed template with a 3xx redirect and  resource
parameter returning a JRD due to the simplicity of client coding.

 

Things needing other sorts of information about the host would still use
host-meta or host-meta.json.

 

John B.

 

 

On 2012-04-23, at 1:11 AM, Mike Jones wrote:

 

I agree with your goal of simplicity for clients.  Paul's example seems
about as simple as it can get for clients:

               curl -v
https://packetizer.com/.well-known/host-meta.json?resource=acct:paulej@packe
tizer.com

It shares the property with your earlier example (below) that clients have a
no-branches code path to do discovery:

               curl -s http://example.com/.well-known/host-meta|
 

               awk "/lrdd/,/template/"|tr -d '\n'|sed -e
"s/^.*template='\([^']*\)'.*$/\1/"|

               sed -e "s/{uri}/user@example.com/"|xargs curl -s

 

However, I challenge the assumption in your note below that servers using
only static pages must be supported.  I just don't see the requirement to
implement a query parameter as being an impediment in practice, even for
hosted domains.  I know of no hosting company that doesn't provide a means
of putting executable code behind web pages, be it PHP, Perl, Ruby, ASP,
JSP, etc.  I know you're trying to make the case for static pages, but in
practice, I believe that dynamic pages are always easily available.

 

Assuming that we're in an either-or situation with regard to either having
single-GET discovery or supporting discovery using only static server pages
(and I'd love to have someone demonstrate to us that we're not), I'd take
single-GET discovery for sure, as in some cases, it makes an appreciable
difference in user interface latency, and per the paragraph above, I believe
that dynamic queries can be implemented on all hosting platforms.

 

Assuming the WebFinger authors agree, I'd suggest that a logical next step
would be for a -04 version of draft-jones-appsawg-webfinger to be published
that changes support for the resource parameter from RECOMMENDED to
REQUIRED, as that could provide a starting point for a common discovery
spec.

 

                                                            -- Mike

 

P.S.  As long as draft-jones-appsawg-webfinger is being revised, I'd also
suggest adding text making explicit what has been an implicit assumption in
both WebFinger and SWD - that depending upon whether and how the client is
authenticated, the set of resources returned may vary (as Blaine had pointed
out earlier).  That could help deal with some of the privacy perceptions.

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of Blaine Cook
Sent: Sunday, April 22, 2012 2:15 PM
To: apps-discuss@ietf.org
Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect
discovery

 

This is the last issue that I've flagged as blocking a new Webfinger / SWD
draft.

 

Mike suggested that being able to request a user's profile with a single
request (i.e., that the /.well-known/ profile resource should be able to
respond with full profile data immediately, rather than pointing at a second
URL that will fulfil the request) is a requirement for this standard.

 

I'd like to challenge that requirement. The arguments for a direct discovery
endpoint are:

 

1. Fewer requests against the server, since we save (in the worst-case) 50%
of requests by bypassing the indirect lookup phase.

2. Lower latency for clients (e.g., mobile clients) owing to the reduced
number of lookups.

 

The arguments for an indirect discovery endpoint are:

 

1. Trivial and web-standards friendly deployment for domains that won't host
their own webfinger/swd profile servers, but want to enable accounts on
their domains (e.g., statically hosted sites).

2. A loosening of the requirement that URLs at the bare domain must run
dynamic scripts that respond to requests to the /.well-known/ path.

 

My opinion is that the approach that SWD has proposed for the redirect is
problematic. First, the format is very similar in form to the HTML "meta
refresh" tag that provided HTTP redirect support from within HTML. That
format has been widely deprecated, and in these more enlightened times, we
just use the 3xx response codes with Location headers, instead.

 

Secondly, the SWD request format means that for smaller sites, often those
with the least resources, will end up serving static content in a way that's
difficult to cache; certainly, more difficult to cache than just serving
static content. This is due to the request parameters present in all SWD
requests; those request parameters will bust caches.

 

As for the first argument *for* SWD's approach, I'd suggest we look to DNS,
which uses the same indirection approach for NS records, relying on a
(relatively) very small set of root servers to handle the traffic for the
whole internet. Clearly, this approach works, and webfinger/swd servers are
in a much better position to handle this additional traffic. Most of this
traffic will be heavily cached, especially for the largest providers.

 

In fact, in terms of real deployments, hosting a script at, e.g.,
google.com/.well-known/simple-web-discovery is much harder than hosting a
script atprofiles.google.com/profile.json for all sorts of reasons, so it's
my belief that the first argument is a red herring.

 

The second argument is legitimate, but only if mobile clients will actually
be making requests to diverse webfinger/swd hosts. Instead, I strongly
believe that we'll see the emergence of DNS-like servers that provide both
profile hosting as well as proxy services. For a mobile client, the optimal
approach will be to use SPDY to connect to a single host that performs
webfinger/swd lookups on the mobile client's behalf, eliminating the latency
concerns.

 

I offer that the two-step lookup can be implemented without conditionals on
the client, whereas the direct-unless-not approach cannot be implemented
that way (see my earlier curl example for proof). It's simpler, and easier
to explain to the (hopefully many) small site owners who we'd like to
implement this technology.

 

Thoughts? Am I missing something?

 

b.

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

 


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

 

 


------=_NextPart_000_062A_01CD232E.A70828D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


John,
 
For a static sites, I would expect either everything would come from =
host-meta or LRDD, but not both.  I would only expect sites that =
are running code to support WebFinger to put stuff in both host-meta and =
LRDD.
 
Here’s an example of how to do a static site on =
Apache:
http://www.packe=
tizer.com/webfinger/server.html
 
(I just wrote that, so I hope it’s not full of errors.  =
It’s not even that late at night, yet, so I have little excuse for =
the typos I tend to produce as the evening =
wears…)
 
For non-static sites, including small ones and large ones, then it =
does not matter.  Size of the site is not a big deal.  =
It’s really ‘static’ vs =
‘non-static’.  My site is relatively small, but =
it’s got running code with live examples pulled from a =
database.  So, for those who want to run an “active” =
server, it’s trivial to do.
 
Paul
 
From:=
 =
John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, =
April 25, 2012 9:28 PM
To: Paul E. Jones
Cc: 'Bob =
Wyman'; apps-discuss@ietf.org
Subject: Re: [apps-discuss] =
Webfinger / SWD Issue #3: direct versus indirect =
discovery
 
Some of the =
rewriting rules Eran described make putting resource specific stuff in =
host-meta a challenge for a simple site.
 
Is their agreement on making resource REQUIRED.   =
I still have a feeling that some people (Blaine?) may not be bought into =
that.
 
I =
agree that you have a simple solution that covers most of the situations =
as long as you don't put resource specific stuff in =
host-meta.
 
John B.
On 2012-04-25, at 10:08 PM, Paul E. Jones =
wrote:


That’s exactly what I’d suggest for static sites… =
don’t put resource specific stuff in host-meta.  For =
non-static sites, one could be more =
flexible.
 
Paul
 
From:=
 John =
Bradley [mailto:ve7jtb@ve7jtb.com]=
 
Sent: Wednesday, April 25, 2012 =
3:13 PM
To: Paul E. =
Jones
Cc: 'Bob =
Wyman'; apps-discuss@ietf.org
Sub=
ject: Re: =
[apps-discuss] Webfinger / SWD Issue #3: direct versus indirect =
discovery
 
If WF were to make resource REQUIRED and rel optional =
that would be a significant step =
forward.
 
Though the Apache http rewrite probably violates the =
host-meta processing rules Eran just described, if the links from =
host-meta must be included in =
order.
You =
could get around it by restricting the contents of host-meta if you are =
doing that I suppose.
 
John B.
 
 
On 2012-04-25, at 3:30 PM, Paul E. Jones =
wrote:



John,
 
I don’t think we need to decide specific environments we want =
to support, but *if* people want to use static files, there are =
choices we can make where the resource parameter will still work, even =
in a static environment.  Previously, I sent out a sample config =
that allows Apache to handle the “resource” parameter and =
still map that to static files.  However, I cannot do the same with =
the “rel” parameter, thus we could never mandate that if we =
want to have any hope at all for allowing static =
sites.
 
I appreciate having the “resource” parameter, but I also =
appreciate some do not need (or have the ability to support) an =
elaborate server.
 
Paul
 
From:=
 apps-discuss-bounces@ietf.o=
rg [mailto:apps-discu=
ss-bounces@ietf.org] On Behalf Of John =
Bradley
Sent: Monday, April 23, 2012 12:19 =
PM
To: Bob =
Wyman
Cc: apps-discuss@ietf.org
Sub=
ject: Re: =
[apps-discuss] Webfinger / SWD Issue #3: direct versus indirect =
discovery
 
I understand that in some environments you may not =
have access to http rewrite rules. =
 
Others may preclude any =
scripts.
 
<=
p class=3DMsoNormal>We do have to decide what environments we are going =
to support.
 
<=
p class=3DMsoNormal>If we stick to static files only then we are just =
putting some lipstick on Yadis by adding a way to map a email like =
address to a file.
 
<=
p class=3DMsoNormal>So yes there are those environments, but that needs =
to be balanced against the additional overhead on the clients to support =
that environment.
 
<=
p class=3DMsoNormal>John =
B.
 
On 2012-04-23, at 12:26 PM, Bob Wyman =
wrote:




 
On Mon, Apr 23, 2012 at 11:08 AM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:
Mike,
 
<=
p class=3DMsoNormal>I think there is less resistance to making resource =
parameter REQUIRED than there is to removing the initial host-meta =
lookup to get the =
template.
 
<=
p class=3DMsoNormal>We should probably keep those issues =
separate.
 
<=
p class=3DMsoNormal>I agree that supporting indirect discovery of the =
template via host-meta.jason should probably =
stay.
 
<=
p class=3DMsoNormal>The question is if their can be an optimization that =
allows shortcutting that step if you know that all you want is web =
finger.
 
<=
p class=3DMsoNormal>A possible option for that could be using a fixed =
template in /.well-known/.
 
<=
p class=3DMsoNormal>That endpoint would =
return:
a The terminal JRD (like =
SWD)
b a 3xx redirect to the real =
endpoint
Causing a 3xx redirect typically requires modification =
to the configuration files of a multi-host shared web server. Access to =
such configuration files is often restricted in such a way that those =
responsible from just one or a few of the sites sharing the common =
server are not permitted to make modifications to those files. In many =
cases, such modifications can be requested and will only be made after =
lengthy delays or the payment of support and maintenance =
fees. 
 
<=
p class=3DMsoNormal>If we want this sort of discovery to become =
generally available, and not just be limited to the "large" =
sites, we should ensure that it is as simple as possible to =
deploy.
 
c a copy of =
the host-meta.jrd
 
<=
p class=3DMsoNormal>We would probably only do one of b or =
c.
 
<=
p class=3DMsoNormal>c has the advantage of being a static file and you =
being no worse off than having started with =
host-meta.json.
b is the simplest for the client and only requires =
common rewriting =
rules.
 
<=
p class=3DMsoNormal>If the redirect is to the same host you could avoid =
the overhead of two connections by pipelining the requests over the same =
TCP connection.
SPDY in the future will make that even more =
efficient.
 
<=
p class=3DMsoNormal>I will grant Blaine that most openID Connect =
discovery requests are Server to Server,  However there are Apps =
that are also clients that should not be =
ignored.
I personally like the fixed template with a 3xx =
redirect and  resource parameter returning a JRD due to the =
simplicity of client =
coding.
 
<=
p class=3DMsoNormal>Things needing other sorts of information about the =
host would still use host-meta or =
host-meta.json.
 
<=
p class=3DMsoNormal>John =
B.
 
<=
p =
class=3DMsoNormal> 
<=
div>
On 2012-04-23, at 1:11 AM, Mike =
Jones wrote:
 
<=
div>
I agree with your goal of simplicity for clients.  Paul’s =
example seems about as simple as it can get for =
clients:
It shares the property with your earlier example (below) that clients =
have a no-branches code path to do =
discovery:
           &nbs=
p;   curl -s http://example.com/.well-known/host-meta|
           &nbs=
p;   awk "/lrdd/,/template/"|tr -d '\n'|sed -e =
"s/^.*template=3D'\([^']*\)'.*$/\1/"|
           &nbs=
p;   sed -e "s/{uri}/user@example.com/"|xargs curl =
–s
 
However, I challenge the assumption in your note below that servers =
using only static pages must be supported.  I just don’t =
see the requirement to implement a query parameter as being an =
impediment in practice, even for hosted domains.  I know of no =
hosting company that doesn’t provide a means of putting executable =
code behind web pages, be it PHP, Perl, Ruby, ASP, JSP, etc.  I =
know you’re trying to make the case for static pages, but in =
practice, I believe that dynamic pages are always easily =
available.
 
Assuming that we’re in an either-or situation with regard to =
either having single-GET discovery or supporting discovery using only =
static server pages (and I’d love to have someone demonstrate to =
us that we’re not), I’d take single-GET discovery for sure, =
as in some cases, it makes an appreciable difference in user interface =
latency, and per the paragraph above, I believe that dynamic queries can =
be implemented on all hosting =
platforms.
 
Assuming the WebFinger authors agree, I’d suggest that a =
logical next step would be for a -04 version of =
draft-jones-appsawg-webfinger to be published that changes support for =
the resource parameter from RECOMMENDED to REQUIRED, as that could =
provide a starting point for a common discovery =
spec.
 
           &nbs=
p;            =
;            =
            &=
nbsp;           -- =
Mike
 
P.S.  As long as draft-jones-appsawg-webfinger is being revised, =
I’d also suggest adding text making explicit what has been an =
implicit assumption in both WebFinger and SWD - that depending upon =
whether and how the client is authenticated, the set of resources =
returned may vary (as Blaine had pointed out earlier).  That could =
help deal with some of the privacy =
perceptions.
 
From:=
 apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf =
Of Blaine Cook
Sent: Sunday, April 22, 2012 2:15 =
PM
To: apps-discuss@ietf.org
Subject: [apps=
-discuss] Webfinger / SWD Issue #3: direct versus indirect =
discovery
 
<=
p class=3DMsoNormal>This is the last issue that I've flagged as blocking =
a new Webfinger / SWD =
draft.
 
=

Mike suggested that being able to request =
a user's profile with a single request (i.e., that the /.well-known/ =
profile resource should be able to respond with full profile data =
immediately, rather than pointing at a second URL that will fulfil the =
request) is a requirement for this =
standard.
 
=

I'd like to challenge that requirement. =
The arguments for a direct discovery endpoint =
are:
 
=

1. Fewer requests against the server, =
since we save (in the worst-case) 50% of requests by bypassing the =
indirect lookup =
phase.
2. Lower latency for clients (e.g., mobile clients) =
owing to the reduced number of =
lookups.
 
=

The arguments for an indirect discovery =
endpoint =
are:
 
=

1. Trivial and web-standards friendly =
deployment for domains that won't host their own webfinger/swd profile =
servers, but want to enable accounts on their domains (e.g., statically =
hosted =
sites).
2. A loosening of the requirement that URLs at the =
bare domain must run dynamic scripts that respond to requests to the =
/.well-known/ =
path.
 
=

My opinion is that the approach that SWD =
has proposed for the redirect is problematic. First, the format is very =
similar in form to the HTML "meta refresh" tag that provided =
HTTP redirect support from within HTML. That format has been widely =
deprecated, and in these more enlightened times, we just use the 3xx =
response codes with Location headers, =
instead.
 
=

Secondly, the SWD request format means =
that for smaller sites, often those with the least resources, will end =
up serving static content in a way that's difficult to cache; certainly, =
more difficult to cache than just serving static content. This is due to =
the request parameters present in all SWD requests; those request =
parameters will bust =
caches.
 
=

As for the first argument *for* SWD's =
approach, I'd suggest we look to DNS, which uses the same indirection =
approach for NS records, relying on a (relatively) very small set of =
root servers to handle the traffic for the whole internet. Clearly, this =
approach works, and webfinger/swd servers are in a much better position =
to handle this additional traffic. Most of this traffic will be heavily =
cached, especially for the largest =
providers.
 
In fact, in terms of real =
deployments, hosting a script at, e.g., google.com/.well-known/simple-web-discovery is=
 much harder than hosting a script atprofiles.google.com/profile.json for all =
sorts of reasons, so it's my belief that the first argument is a red =
herring.
<=
p =
class=3DMsoNormal> 
=

The second argument is legitimate, but =
only if mobile clients will actually be making requests to diverse =
webfinger/swd hosts. Instead, I strongly believe that we'll see the =
emergence of DNS-like servers that provide both profile hosting as well =
as proxy services. For a mobile client, the optimal approach will be to =
use SPDY to connect to a single host that performs webfinger/swd lookups =
on the mobile client's behalf, eliminating the latency =
concerns.
 
=

I offer that the two-step lookup can be =
implemented without conditionals on the client, whereas the =
direct-unless-not approach cannot be implemented that way (see my =
earlier curl example for proof). It's simpler, and easier to explain to =
the (hopefully many) small site owners who we'd like to implement this =
technology.
 
=

Thoughts? Am I missing =
something?
 
=

b.
_________=
______________________________________
apps-discuss mailing =
list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<=
/span>
 

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

------=_NextPart_000_062A_01CD232E.A70828D0--


From internet-drafts@ietf.org  Thu Apr 26 06: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 9836621F87AA; Thu, 26 Apr 2012 06:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.509
X-Spam-Level: 
X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TsoJbixM1JV; Thu, 26 Apr 2012 06:19:12 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257C321F8763; Thu, 26 Apr 2012 06:19:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.01p1
Message-ID: <20120426131912.32053.74050.idtracker@ietfa.amsl.com>
Date: Thu, 26 Apr 2012 06:19:12 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-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, 26 Apr 2012 13:19:12 -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 Worki=
ng Group of the IETF.

	Title           : Additional Media Type Structured Syntax Suffixes
	Author(s)       : Tony Hansen
	Filename        : draft-ietf-appsawg-media-type-suffix-regs-00.txt
	Pages           : 9
	Date            : 2012-04-26

   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 updates the "+xml" Structured Syntax
   Suffix registration.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-suffix-re=
gs-00.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-suffix-reg=
s-00.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs/


From internet-drafts@ietf.org  Thu Apr 26 09:57: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 7762321E80B1; Thu, 26 Apr 2012 09:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.503
X-Spam-Level: 
X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jf-orpv54VTp; Thu, 26 Apr 2012 09:57:12 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D711F21F8652; Thu, 26 Apr 2012 09:57:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.01p1
Message-ID: <20120426165712.27154.95209.idtracker@ietfa.amsl.com>
Date: Thu, 26 Apr 2012 09:57:12 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-09.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, 26 Apr 2012 16:57:13 -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 Worki=
ng Group of the IETF.

	Title           : Email Greylisting: An Applicability Statement for SMTP
	Author(s)       : Murray S. Kucherawy
                          D. Crocker
	Filename        : draft-ietf-appsawg-greylisting-09.txt
	Pages           : 17
	Date            : 2012-04-26

   This document describes the art of email greylisting, the practice of
   providing temporarily degraded service to unknown email clients as an
   anti-abuse mechanism.

   Greylisting is an established mechanism deemed essential to the
   repertoire of current anti-abuse email filtering systems.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-09.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-09.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-greylisting/


From internet-drafts@ietf.org  Thu Apr 26 12:25: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 EFD6921F8527; Thu, 26 Apr 2012 12:25:53 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3MGFXfEyD1L; Thu, 26 Apr 2012 12:25:52 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBA221F8716; Thu, 26 Apr 2012 12:25:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.01p1
Message-ID: <20120426192552.2605.75708.idtracker@ietfa.amsl.com>
Date: Thu, 26 Apr 2012 12:25:52 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-06.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, 26 Apr 2012 19:25: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 Worki=
ng Group of the IETF.

	Title           : Media Type Specifications and Registration Procedures
	Author(s)       : Ned Freed
                          John C. Klensin
                          Tony Hansen
	Filename        : draft-ietf-appsawg-media-type-regs-06.txt
	Pages           : 31
	Date            : 2012-04-26

   This document defines procedures for the specification and
   registration of media types for use in HTTP, MIME and other Internet
   protocols.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-06.t=
xt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-06.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/


From ted.ietf@gmail.com  Thu Apr 26 14:40: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 8444A11E809B for ; Thu, 26 Apr 2012 14:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.569
X-Spam-Level: 
X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU8gz2w5jNfH for ; Thu, 26 Apr 2012 14:40:30 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0486821F883A for ; Thu, 26 Apr 2012 14:40:29 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so73850vcb.31 for ; Thu, 26 Apr 2012 14:40:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vOqYhJorrJWhHncrw26vOJE50g5SJ0HaAtkDr8y+UJE=; b=vTPSbdU1n4kU/ka8urOSO/ImeOe3H0MXxSn6eyvLkGli9TKxo18SAdT1M5ayDhOzoQ YuPjxv2d5QTTfJ/iBCf/1BfxRnzQykVkfwhgLN8Yor+NOLdEoY1SIqRqCbwJZ3QjmhN/ dTSek/bt/nK0H3GDoWEZQlCC+PD4779VLgfpAQIkuxZ9shipNXNkmYJhb20OUAc+PMVU fd7EItZD7F0S5bOcEQr4YbdND9S0mICTvi+i9Q8vdRxnBA8pFjsjNbuCHO8mVVL9pGGj m57e9PJ1t1TF/rEhQPJgK2DjNEiWVyg8LtiEFTbasVjGXM1sQi3A3M5qL+oflwpy1P3Z rt/A==
MIME-Version: 1.0
Received: by 10.220.149.79 with SMTP id s15mr8743370vcv.60.1335476429508; Thu, 26 Apr 2012 14:40:29 -0700 (PDT)
Received: by 10.52.162.99 with HTTP; Thu, 26 Apr 2012 14:40:29 -0700 (PDT)
Date: Thu, 26 Apr 2012 14:40:29 -0700
Message-ID: 
From: Ted Hardie 
To: draft-ietf-alto-protocol.all@tools.ietf.org, apps-discuss@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] Review of draft-ietf-alto-protocol-11.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, 26 Apr 2012 21:40:31 -0000

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-alto-protocol-11.txt
Title: ALTO Protocol
Reviewer: Ted Hardie
Review Date: April 26, 2012

Summary: Despite the length of this review, the document is
fundamentally ready for publication on the standards track.  There
are sections which need clarification or re-consideration, but
they are not fundamental to the protocol's operation.

Major:

Section 5.1 needs clarification.  While it clearly introduces the
types for the cost type and cost mode parameters, it buries the type
for the cost itself within the description of the ordinal cost mode:

5.1.2.2. Cost Mode: ordinal


   This Cost Mode is indicated by the string 'ordinal'.  This mode
   indicates that the costs values to a set of Destination Network
   Locations from a particular Source Network Location are a ranking,
   with lower values indicating a higher preference.  The values are
   non-negative integers.

This makes it unclear whether Costs of the numerical Cost Type are
similarly restricted to non-negative integers. Based on other
descriptions of ordinal comparison (e.g. q values in content
negotiation), I also presume that the clients are not expected to
infer anything about the weights based on the integers chosen for the
ordinal type. That is: 3 PIDS with costs of 2, 4, 6 should be treated
the same if the assigned values are 3, 17, 18, because the order is
the same.  Additional text to highlight this (or provide the
appropriate treatment) would be useful.  The section would also
benefit from an example of a numerical operation other than
normalization.

In Section 7.2, the document describes the request/response traffic as
based on "standard HTTP"; the security considerations sections appears
to recommend TLS for integrity protection in 11.3 (this property is
not mentioned in 7.2.5, which lists TLS as MAY for authentication and
encryption).  This should be reconciled; if 11.3 is not recommending
TLS or any object-based security, more detail is probably needed on
the consequences of an attacker controlling this data.

Minor:

General comment: there is a great deal of material in this document
that is either tutorial in nature or which defends a particular set of
design choices (e.g. section 6.1).  While this material is not
inherently bad, it is interleaved into the specification in ways that
make it difficult to extract the concrete protocol specification.  If
there were sections that the WG felt could be moved to an appendix
summarizing the benefits of the ALTO approach and its choices, the
spec might get significantly tighter and easier to read.

In Section 4.1, the concept of a PID as an identifier is introduced,
but without a pointer to the definition of the identifier type.  There
is a forward reference to section 5, but this describes cost maps, not
the PID identifier itself.  Reading (or grepping) forward provides a
pointer to PIDName, but without a succinct relationship defined.  I
suggest adapting the description in 7.7.1.1.5 for this purpose:

"A PID is a US-ASCII string of type PIDName (see section 7.5.1) and
its associated set of endpoint addresses."

I believe this could be inserted between the first two sentences of
the first paragraph in section 4.1

In Section 4.2.1, the document says:

    A RECOMMENDED way to satisfy this property is to define a PID that
   contains the 0.0.0.0/0 prefix for IPv4 or ::/0 (for IPv6).

This assumes that the cost map provided includes all IP addresses.
While this may be true for some use cases, there are other use cases
where it may not be true, and the text here should probably be
modified to handle those cases.  Something like

"A RECOMMENDED way to satisfy this property is to define a PID with
the shortest enclosing prefix of the addresses provided in the map.
For a map with full IPv4 reachability, this would mean including the
0.0.0.0/ prefix in a PID; for full IPv6 reachability, this would be
the ::/0 prefix"

might suit the case.

In section 7.2.2, the document says:

   "Note that it is possible for an ALTO Server to employ caching for the
   response to a POST request.  This can be accomplished by returning an
   HTTP 303 status code ("See Other") indicating to the ALTO Client that
   the resulting Cost Map is available via a GET request to an alternate
   URL (which may be cached)."

The phrase "employ caching" is ambiguous here, as the results of the
initial POST are not cacheable even in the case of a 303; only
the results of the later GET request are cachable.  Since cachability
is a major reason cited for the re-use of HTTP, some additional text
on the use cache control directives ("public" and "Max-age" seem
particularly important in this context) might also be useful.

In 7.4.2, the document describes the error resource, and notes this:

 reason  A (free-form) human-readable explanation of the particular
      error

If I understand JASONString correctly, no language tag is supplied,
so human readability will be highly variable,  Fixing that, rather
than relying on a local mapping of the underlying code, is hard
work.  Dropping this optional aspect of the error resource may
be something for the WG to consider; this pushes localization
of the error code description to the endpoint.

The endpoint property resource seems to be specified in too many
sections for easy comprehension.  Section 7.7.3.1 describes it, but
points to 7.7.3.1.4 (the related capabilities) which in turn points to
3.1.3, which says:

   This service allows ALTO Clients to look up properties for individual
   endpoints.  An example endpoint property is its Network Location (its
   grouping defined by the ALTO Server) or connectivity type (e.g.,
   ADSL, Cable, or FTTH).

It is only in Section 10.3, with the creation of the registry, that
it is clear that these are registered tokens, rather than free text.
I suggest that this be clarified early, with a forward pointer to
the actual registry.

In section 9.3, the document notes that the ALTO client SHOULD use
STUN to determine a public IP for a source address.  However,
the description of the Endpoint Cost Service contains this text:

      If the list of Source
      Endpoints is empty (or not included), the ALTO Server MUST
      interpret it as if it contained the Endpoint Address corresponding
      to the client IP address from the incoming connection

It would seem a valid recommendation here would be to propose that the
CLIENT omit the Source Endpoint where it currently recommends the use
of STUN.  I infer that this is not recommended because the Endpoint
Address service may be provided within a NAT boundary shared with the
CLIENT, thus making the source address of the packet different from
that which would be seen externally (resolving this would require the
ALTO service to have general knowledge of the NAT bindings).  But the
opposite case is not handled.  What happens when the destination
address is within the NAT boundary of the client?  Won't the external
address determined by STUN will have a similar mismatch to the true
origin address for packets destined to the internal destination?

In 9.4, it may be useful to note that there are private ASNs which
are not unique, and that a single looking glass may therefore give
an incomplete view of the full mapping of IP addresses to ASNs.  In
general, this section seems to point to future work, and I suggest
that it more clearly say that a standardized method for this mapping
is left to future work.


In section 10.4, it may be useful to advise the Expert Reviewer
on how to handle registrations which differ only as to case;
for example, would PRIV: or EXP: be permitted in a registration?

Nits:

The Abstract says:

   These maps provide simplified,
   yet enough information of a network for applications to effectively
   utilize.

This seems to be missing a noun or to require restructuring.  Possibly:

"These maps provide simplified information, but it is enough for
applications to effectively use."?

"Additional services are built on top the maps."  should be "on top of
the maps".

In the Introduction, "see below" could be shifted to a more precise
forward reference to a specific section.

In section 2.2, the document says:

   In particular, an ALTO Server defines network
   Endpoints (and aggregations thereof) and generic costs amongst them,
   both from the network region's own perspective.

I personally found this hard to parse.  Some re-wording may be useful.
(Possibly eliminating the ", both"?)

In Figure 1, the top most enclosing box is labelled "ISP".  While that is
certainly a common use case, there seem to be others. Given the
preceding text, would it be more general to use the term "Network
Region"?

In section 3, the document says:

"Note that functionality offered in different
   services are not totally non-overlapping (e.g., the Map Service and
   Map Filtering Service)."

Would it be equivalent to say "functionality offered in different
services may overlap"?

Section 3 is titled "Protocol Structure", but the subsections are about
specific services, and the base text doesn't really describe what
most IETF readers will understand as a description of the structure of
the protocol (that seems to be in Section 7).  A different title (maybe
"Service framework"?) would seem to be a better fit.

I believe Section 4 might read more naturally if the second paragraph
were moved up to be first.

In 7.5.1, the encoding of PID Name is given in relation to a permitted
US-ASCII code range, except for the "." separator.  Providing the
related code point would be useful.  Several other sections use
"alphanumeric" as a limitation without giving the code point ranges;
in those cases, the actual code point ranges would be useful.

The Content-Length in some examples (e.g. in 7.6.3) are listed
as [TODO]; this should be fixed.

In section 9.2, the document says "one path my have a NAT64 middlebox)",
where my should be "may".

In Section 10.1, it is common for the change controller to be the IESG,
rather than the individual editors of the draft.

From ned.freed@mrochek.com  Thu Apr 26 19:11: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 E4BFB11E8079 for ; Thu, 26 Apr 2012 19:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zMBKtoudWZc for ; Thu, 26 Apr 2012 19:11:22 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D778511E8096 for ; Thu, 26 Apr 2012 19:11:22 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OESA7C4ZPC000C7P@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 26 Apr 2012 19:11:20 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Thu, 26 Apr 2012 19:11:18 -0700 (PDT)
Message-id: <01OESA7AW0OK0006TF@mauve.mrochek.com>
Date: Thu, 26 Apr 2012 19:08:56 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Wed, 25 Apr 2012 05:23:17 +0000" <20120425052317.77243.qmail@joyce.lan>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <9452079D1A51524AA5749AD23E003928100E82@exch-mbx901.corp.cloudmark.com> <20120425052317.77243.qmail@joyce.lan>
To: John Levine 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Call for	Adoption:	draft-kucherawy-received-state-02.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, 27 Apr 2012 02:11:24 -0000

> >> Please indicate your support or objection, and opinions thereto before
> >> the close of business on May 1st.

> I have my doubts about the utility of this feature, but it is at worst
> harmless so it's fine to publish it.  The quality of the draft is good,
> didn't see anything that needed to change.

I think there's some utility here - additional trace information is almost
always a good thing - but even ore important is breaking the impasse
that has prevent extensions to Received:. This seems as good a document as
any to do it.

So: +1 to this becoming a WG draft.

				Ned

From msk@cloudmark.com  Thu Apr 26 23:09: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 0DDF821F8711 for ; Thu, 26 Apr 2012 23:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.628
X-Spam-Level: 
X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9v3cLnFRKR8 for ; Thu, 26 Apr 2012 23:09:30 -0700 (PDT)
Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4D20821F870E for ; Thu, 26 Apr 2012 23:09:30 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 2u9V1j0010ZaKgw01u9VxF; Thu, 26 Apr 2012 23:09:29 -0700
X-CMAE-Match: 0
X-CMAE-Score: 0.00
X-CMAE-Analysis: v=2.0 cv=VPNfbqzX c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=yN7sq60MiGU1UY3CXzcA:9 a=wPNLvfGTeEIA:10 a=PHT45R3K67X32fjDyOEA:9 a=3BjMsXJDH9PbPsy-GgoA:7 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=LdFkGDrDWH2mcjCZERnC4w==:117
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 23:09:29 -0700
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Thread-Topic: IETF 83 APPSAWG Minutes uploaded
Thread-Index: Ac0kPE22078g8gEQTSiXG4lJYA4pTA==
Date: Fri, 27 Apr 2012 06:09:28 +0000
Message-ID: <9452079D1A51524AA5749AD23E003928104747@exch-mbx901.corp.cloudmark.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [67.160.203.60]
Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E003928104747exchmbx901corpclo_"
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335506969; bh=k35RdZM6TFqlSPqSFgb7b1srZxjgZwUtwN7IyLtd9UI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=vWnL2Vd6yC+hcoRQ7bZdnsYcvWfa4/XZBfqW+B2No62S2GxOJMzJlzgc8K5yhhu9O 1kFi9LRZn16BmNX4AqoTk3PzU0D8d55keWQ4L5lRL82k9wgRMbTl4aonsPvsU1Lt9f HBd61lSV3+ckqkpVHN7k62306SgJSU72E699bP6U=
Subject: [apps-discuss] IETF 83 APPSAWG Minutes uploaded
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Apr 2012 06:09:31 -0000

--_000_9452079D1A51524AA5749AD23E003928104747exchmbx901corpclo_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I've uploaded the minutes from our Paris meeting, based largely on the Ethe=
rpad minutes taken by Joe Hildebrand and others.  Thanks to those of you th=
at volunteered to do that.

The minutes are visible here: http://www.ietf.org/proceedings/83/minutes/mi=
nutes-83-appsawg.txt

Please take a moment to review them and see if anything was either missed o=
r incorrectly represented.

(I know the formatting isn't the greatest.  I'll work on fixing that.  The =
deadline for these is Friday, however, so better this than nothing.)

-MSK, APPSAWG co-chair

--_000_9452079D1A51524AA5749AD23E003928104747exchmbx901corpclo_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








I've uploaded the minutes from our Paris meeting, based largely on t=
he Etherpad minutes taken by Joe Hildebrand and others.  Thanks to tho=
se of you that volunteered to do that.



The minutes are visible here: 
http://www.ietf.org/proceedings/83/minutes/minutes-83-appsawg.txt



Please take a moment to review them and see if anything was either missed o=
r incorrectly represented.



(I know the formatting isn't the greatest.  I'll work on fixing that.&=
nbsp; The deadline for these is Friday, however, so better this than nothin=
g.)



-MSK, APPSAWG co-chair






--_000_9452079D1A51524AA5749AD23E003928104747exchmbx901corpclo_--

From ari.keranen@nomadiclab.com  Fri Apr 27 09:34: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 DD44621F863F for ; Fri, 27 Apr 2012 09:34:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4ybp7a9MxO5 for ; Fri, 27 Apr 2012 09:34:14 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED4D21F863D for ; Fri, 27 Apr 2012 09:34:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 6B7904E6EE; Fri, 27 Apr 2012 19:34:10 +0300 (EEST)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7KxdMoJBeQq; Fri, 27 Apr 2012 19:34:09 +0300 (EEST)
Received: from As-MacBook-Air.local (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 1B3924E6E9; Fri, 27 Apr 2012 19:34:08 +0300 (EEST)
Message-ID: <4F9ACA89.4000101@nomadiclab.com>
Date: Fri, 27 Apr 2012 11:34:17 -0500
From: Ari Keranen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Manger, James H" 
References: <4F7DFC47.2020604@cs.tcd.ie>  <255B9BB34FB7D647A506DC292726F6E114F0499619@WSMSG3153V.srv.dir.telstra.com> <4F84EDAE.5030207@cs.tcd.ie>
In-Reply-To: <4F84EDAE.5030207@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] draft-farrell-decade-ni-02: glitch in examples
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Apr 2012 16:34:15 -0000

Hi James,

Thanks for the comments! And sorry for the late reply.

The base32 encoded versions of the CRCs were indeed wrong in the draft. 
Good catch. After getting it right only after a considerable amount of 
hacking, we came into conclusion that it's not worth the effort. If it's 
really that hard to get right, it should be made more simple.

Therefore, we changed the encoding from base32 to base16 (hex) for both 
the hash and the CRC. While adding a few character of length to the 
hashes (but not to CRCs since now the lengths align perfectly), this 
also removed all the complexities with padding that was a bit pain to 
both specify and implement.

Yet, I think it's better to calculate the CRC over the whole string 
since then we protect also the hash-algorithm part. Also, it's a bit 
simpler to implement since you don't have to parse the string and 
convert hash back to binary for the checksum (e.g., if you do the check 
in the UI). We clarified that the input needs to be in UTF-8.


Cheers,
Ari

On 4/11/12 5:34 AM, Stephen Farrell wrote:
>>
>> I am not sure what the correct checksums are.
>>
>> The example checksums (eokv and csdh) look wrong. I assume the 4
>> base32 chars in the checksum should encode 5+5+5+1 bits respectively
>> of the 16-bit CRC. Hence the last char encodes 1 bit, padded with 4
>> zeros: either 00000 or 10000, which should give 'a' or 'q' (not 'v' or
>> 'h').
>>
>> P.S. A CRC16 is calculated over an array of bytes. However the input
>> is defined as a text string. I guess ASCII/UTF-8 encoding is assumed.
>> It might be better to calculate the CRC over the bytes of the
>> truncated hash.
>
> Fair point. OTOH, that'd mean omitting the "nih:sha-256;" part but
> I guess that'd be not much harm.
>
> I suspect that you may be right about the checksum. Will check with
> co-authors more involved with CoAP (Ari basically) to see what they
> prefer, since its them that want the CRC.


From paul.hoffman@vpnc.org  Fri Apr 27 11:01: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 66D1721F86E8; Fri, 27 Apr 2012 11:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Level: 
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR4Gmt9HI-Yk; Fri, 27 Apr 2012 11:01:23 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9688921F8687; Fri, 27 Apr 2012 11:01:23 -0700 (PDT)
Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3RI1M5F089778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Apr 2012 11:01:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman 
In-Reply-To: <4F95CA0B.8050202@stpeter.im>
Date: Fri, 27 Apr 2012 11:01:21 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <24B5BD30-385D-4780-AD42-A4D1271DFA83@vpnc.org>
References: <4F95CA0B.8050202@stpeter.im>
To: Peter Saint-Andre 
X-Mailer: Apple Mail (2.1257)
Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Apr 2012 18:01:24 -0000

On Apr 23, 2012, at 2:30 PM, Peter Saint-Andre wrote:

> Major Issue:
>=20
> This document does not mention that TLSA records cannot be used
> directly in application protocols that depend on SRV (or NAPTR or
> similar technologies). Although I realize that the DANE WG decided,
> after much discussion, that the interaction between TLSA records and
> SRV records is out of scope for this specification (and I do not mean
> to reopen that discussion now), it would be very helpful for this
> specification to reflect the results of that discussion. Although I
> make specific suggestions regarding text under the Minor Issues below,
> in general I think this document needs to be clearer about the
> assumptions it has made in this regard; in fact, it seems to me that
> an explicit applicability statement is warranted to avoid confusion of
> the kind that Dave Cridland experienced (see his Last Call comments).

Now covered in section 1.3, and includes a note that this document might =
be updated in the future to cover such things. (Note: it would be grand =
if an XMPPer would start work on this soon so we still have momentum.)

> 5. To those of us accustomed to SRV records, at first glance the
> prefixed DNS domain name format defined in Section 3 looks strange:
> why not _http._tcp.www.example.com instead of
> _443._tcp.www.example.com? But when we take off our SRV-colored
> glasses and realize that DANE assumes a DNS A/AAAA lookup on the
> domain name, it all makes sense. Perhaps it would be helpful to
> mention the reasoning behind the port number (instead of application
> name) here?

I would rather not try to summarize the debate in the spec, given that =
the result (numbers) are completely clear.

> 6. In section 4, no mention is made of the application service that
> the TLS expects to encounter at the TLS server:
>=20
>   The TLS session that is to be set up MUST be for the specific port
>   number and transport name that was given in the TLSA query.
>=20
> Yet surely the application protocol can matter here, no?

No.

> In
> particular, given that 443 is the one true port, we know that folks
> might run non-HTTP applications over that port (for evil reasons, of
> course).

Sure. But...

> Does DANE elide over the application protocol because we
> simply assume that the "right" service is being served over any
> particular port?

Yes, that's the only sane way to do things currently. (The TLS WG is =
discussing adopting a protocol that would complicate this, but that's a =
long way off, I suspect.)

> What about service providers that wish to restrict
> the usage of a certificate to a particular application service type
> (cf. RFC 6125)?

I'm not sure how this is relevant. There is only one application =
protocol that can be running on 443 after TLS is established.

> Or do we assume that it is enough to differentiate
> among application services based on the underlying transport (as seems
> to be the case in the text on "Multiple Ports" in Section 5)?

Yes.

> IMHO we
> have a bit of a muddle here.

I don't see it.

> 7. The paragraph about SSL proxies in Section 8 says that "the TLS
> client will get a certificate association from the DNS that will not
> match the certificate that the SSL proxy uses with the client";
> however, if the SSL proxy is working in concert with an external DNS
> validator, is it possible to mimic the behavior of current SSL =
proxies?

Maybe, but they are undefined.

--Paul Hoffman


From creed@opengeospatial.org  Fri Apr 27 14:31: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 609F311E8087 for ; Fri, 27 Apr 2012 14:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.676
X-Spam-Level: 
X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLYFKaZwvldh for ; Fri, 27 Apr 2012 14:31:24 -0700 (PDT)
Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 862F921F85F6 for ; Fri, 27 Apr 2012 14:31:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 72B275A33B for ; Fri, 27 Apr 2012 17:31:23 -0400 (EDT)
X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net
Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vLIFAo20Tup for ; Fri, 27 Apr 2012 17:31:23 -0400 (EDT)
Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id EFA5B5A32D for ; Fri, 27 Apr 2012 17:31:22 -0400 (EDT)
Message-ID: 
From: "Carl Reed" 
To: "apps-discuss IETF" 
Date: Fri, 27 Apr 2012 15:30:35 -0600
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_05C2_01CD248A.B110D6D0"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3538.513
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513
Subject: [apps-discuss] SenML, sensor tasking, etc. From the Open Geospatial Consortium
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Apr 2012 21:31:25 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_05C2_01CD248A.B110D6D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

All -

I have just become aware of the SenML and related sensor standard =
activities in the IETF. I would like to consider how the sensor work in =
the IETF community and the work on sensor standards in the OGC can be =
possibly coordinated. By way of background.

I am the CTO and Executive Director Standards for the Open Geospatial =
Consortium (OGC). The OGC focus is on standards that enable the =
integration and interoperable integration of geospatial services and =
content into any application.

Since 2000, a number of OGC Member organizations have been working an =
activity we call Sensor Web Enablement (SWE). This activity has resulted =
in a baseline of standards for describing, tasking, accessing, and =
managing network accessible sensors. These standards work with both =
in-situ and dynamic sensors. The SWE standards have been widely =
implemented in a variety of domains, such as for ocean sensing, early =
warning systems, hydrology, satellite ground stations, and mobile =
location services. Due to the OGC focus on location enabled, network =
accessible sensors, we have been collaborating with JTC1 Working Group =
7, the W3C, ISO TC 211, KRONOS, IEEE, and other organizations to insure =
that the standards stack for integrating sensor observations into =
applications is as consistent as possible.
There is a high level OGC White Paper that describes the SWE standards =
and architecture. This WP just underwent a major revision and has not =
been publicly released yet. There is also a much more detailed technical =
SWE document here: =
http://portal.opengeospatial.org/files/?artifact_id=3D29405=20

Looking forward to this groups thoughts.

Regards

Carl Reed, PhD
CTO and Executive Director Standards Program
Open Geospatial Consortium
www.opengeospatial.org

The OGC: Making Location Count!

---------------------

This communication, including attachments, is for the exclusive use of =
addressee and may contain proprietary, confidential or privileged =
information. If you are not the intended recipient, any use, copying, =
disclosure, dissemination or distribution is strictly prohibited. If you =
are not the intended recipient, please notify the sender immediately by =
return email and delete this communication and destroy all copies.

"The important thing is not to stop questioning." -- Albert Einstein=20
"Security is mostly a superstition. It does not exist in nature. Life is =
either a daring adventure or nothing." -- Helen Keller 
------=_NextPart_000_05C2_01CD248A.B110D6D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








All -


 




I have just become aware of the =
SenML and=20
related sensor standard activities in the IETF. I would like to consider =
how the=20
sensor work in the IETF community and the work on sensor standards in =
the OGC=20
can be possibly coordinated. By way of background.


 




I am the CTO and Executive =
Director=20
Standards for the Open Geospatial Consortium (OGC). The OGC focus is on=20
standards that enable the integration and interoperable integration of=20
geospatial services and content into any application.


 




Since 2000, a number of OGC Member =

organizations have been working an activity we call Sensor Web =
Enablement (SWE).=20
This activity has resulted in a baseline of standards for describing, =
tasking,=20
accessing, and managing network accessible sensors. These standards work =
with=20
both in-situ and dynamic sensors. The SWE standards have been widely =
implemented=20
in a variety of domains, such as for ocean sensing, early warning =
systems,=20
hydrology, satellite ground stations, and mobile location services. Due =
to the=20
OGC focus on location enabled, network accessible sensors, we have been=20
collaborating with JTC1 Working Group 7, the W3C, ISO TC 211, KRONOS, =
IEEE, and=20
other organizations to insure that the standards stack for integrating =
sensor=20
observations into applications is as consistent as possible.




There is a high level OGC White =
Paper that=20
describes the SWE standards and architecture. This WP just underwent a =
major=20
revision and has not been publicly released yet. There is also a much =
more=20
detailed technical SWE document here: http=
://portal.opengeospatial.org/files/?artifact_id=3D29405=20



 




Looking forward to this groups=20
thoughts.


 




Regards


 

Carl=20
Reed, PhD
CTO and Executive Director Standards Program
Open =
Geospatial=20
Consortium
www.opengeospatial.org

The OGC: Making Location=20
Count!

---------------------

This communication, including =

attachments, is for the exclusive use of addressee and may contain =
proprietary,=20
confidential or privileged information. If you are not the intended =
recipient,=20
any use, copying, disclosure, dissemination or distribution is strictly=20
prohibited. If you are not the intended recipient, please notify the =
sender=20
immediately by return email and delete this communication and destroy =
all=20
copies.

"The important thing is not to stop questioning." -- =
Albert=20
Einstein 
"Security is mostly a superstition. It does not exist in =
nature.=20
Life is either a daring adventure or nothing." -- Helen Keller=20



------=_NextPart_000_05C2_01CD248A.B110D6D0--


From barryleiba.mailing.lists@gmail.com  Fri Apr 27 15:33: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 F2F8721F85CF for ; Fri, 27 Apr 2012 15:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.963
X-Spam-Level: 
X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U234hWtpxhqt for ; Fri, 27 Apr 2012 15:33:55 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B79B221F85C5 for ; Fri, 27 Apr 2012 15:33:54 -0700 (PDT)
Received: by lagj5 with SMTP id j5so929461lag.31 for ; Fri, 27 Apr 2012 15:33:53 -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=cF8rFMSmI17ab2fgIPyzAsT8ky14VqLvZJzknT7nGco=; b=y/afqPDUZD8hfI5v999TejEh3yZD201208KTHXV826WhUrCBSe2QNJv28R06+aH1j7 QSauVwZ2ImQqMuUoUS1EhEgmCepyTaXENWJXZC3ImriNBk/7Cy5A3b5Pk4gtp0u+bl0S y1DojXV2nUduVIxE5Ls15DpkkbmGvZ0ad0euTBzy6ZNDZFBLjOgmLFWbPhR3gqeTEOn9 kOPM+HjFt+oC7/gXB3Yyb51r2hXONKZdb5aYIIBh5SJERAcDuVUCP7baq5UZ5eed04Cc D+CbBut2d19enRGkWOYbP3l04lI8U95WDyi6nDZGthqcV0bUQ6SjMB1vz0j4z5CGjAAz OlEQ==
MIME-Version: 1.0
Received: by 10.152.105.19 with SMTP id gi19mr12309474lab.11.1335566033726; Fri, 27 Apr 2012 15:33:53 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.112.7.7 with HTTP; Fri, 27 Apr 2012 15:33:53 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 27 Apr 2012 18:33:53 -0400
X-Google-Sender-Auth: DGroZcByNUfXS57ZDAMk3-5zunI
Message-ID: 
From: Barry Leiba 
To: Carl Reed 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss IETF 
Subject: Re: [apps-discuss] SenML, sensor tasking, etc. From the Open Geospatial Consortium
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Apr 2012 22:33:56 -0000

Hi, Carl.
There is no work on SenML going on in the IETF at this time, so
there's nothing for us to coordinate.

The IAB, however, has held a workshop on "smart objects"; see here:
http://www.iab.org/activities/workshops/smartobjects/

You can contact the IAB, of which Jari Arkko and Hannes Tschofenig are
active in this space, and see what their plans are and what they
suggest.  You can reach the IAB at .

Barry Leiba, Applications Area Director


On Fri, Apr 27, 2012 at 5:30 PM, Carl Reed  wrote:
> All -
>
> I have just become aware of the SenML and related sensor standard activities
> in the IETF. I would like to consider how the sensor work in the IETF
> community and the work on sensor standards in the OGC can be possibly
> coordinated. By way of background.
>
> I am the CTO and Executive Director Standards for the Open Geospatial
> Consortium (OGC). The OGC focus is on standards that enable the integration
> and interoperable integration of geospatial services and content into any
> application.
>
> Since 2000, a number of OGC Member organizations have been working an
> activity we call Sensor Web Enablement (SWE). This activity has resulted in
> a baseline of standards for describing, tasking, accessing, and managing
> network accessible sensors. These standards work with both in-situ and
> dynamic sensors. The SWE standards have been widely implemented in a variety
> of domains, such as for ocean sensing, early warning systems, hydrology,
> satellite ground stations, and mobile location services. Due to the OGC
> focus on location enabled, network accessible sensors, we have been
> collaborating with JTC1 Working Group 7, the W3C, ISO TC 211, KRONOS, IEEE,
> and other organizations to insure that the standards stack for integrating
> sensor observations into applications is as consistent as possible.
> There is a high level OGC White Paper that describes the SWE standards and
> architecture. This WP just underwent a major revision and has not been
> publicly released yet. There is also a much more detailed technical SWE
> document here: http://portal.opengeospatial.org/files/?artifact_id=29405
>
> Looking forward to this groups thoughts.
>
> Regards
>
> Carl Reed, PhD
> CTO and Executive Director Standards Program
> Open Geospatial Consortium
> www.opengeospatial.org
>

From paul.hoffman@vpnc.org  Fri Apr 27 17:09: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 599D821E802B; Fri, 27 Apr 2012 17:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Level: 
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZysItmHjQLA; Fri, 27 Apr 2012 17:09:56 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A62DF21E8027; Fri, 27 Apr 2012 17:09:56 -0700 (PDT)
Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3S09pbD001221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Apr 2012 17:09:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman 
In-Reply-To: <4F96D157.7020504@isode.com>
Date: Fri, 27 Apr 2012 17:09:51 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>
References: <4F96D157.7020504@isode.com>
To: Alexey Melnikov 
X-Mailer: Apple Mail (2.1257)
Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Apr 2012 00:09:57 -0000

On Apr 24, 2012, at 9:14 AM, Alexey Melnikov wrote:

> Major Issue: none, although a) I am agreeing with Peter Saint-Andre's =
major issue and b) I would like to see a reply to my minor issues

Here you go.

> Minor Issues:
>=20
> 2.2.  TLSA RR Presentation Format
>=20
>   The presentation format of the RDATA portion is as follows:
>=20
> Presentation for what purpose? In management UIs? Is this a required =
presentation format for DNS tools that can retrieve and update TLSA =
records?

Added a pointer to RFC 1035.

> [...]
>=20
>   o  The certificate association data field MUST be represented as a
>      string of hexadecimal characters.  Whitespace is allowed within
>      the string of hexadecimal characters.
>=20
> Please define what you mean by whitespace here? CR & LFs allowed?
> Examples in the Section 2.3 seem to suggest that.

Should be covered by the (new) reference to RFC 1035.

> 3.  Domain Names for TLS Certificate Associations
>=20
>   2.  The protocol name of the transport on which a TLS-based service
>       is assumed to exist is prepended with an underscore character
>       ("_") to become the second left-most label in the prepared =
domain
>       name.  The transport names defined for this protocol are "tcp",
>       "udp" and "sctp".
>=20
> DCCP?

No.

> Should there be a registry?

Seems like overkill for how rarely new popular transports get added. =
Such a transport is going to need to have an RFC for this anyway.

> 4.  Use of TLSA Records in TLS
>=20
>   Section 2.1 of this document defines the mandatory matching rules =
for
>   the data from the TLSA certificate associations and the certificates
>   received from the TLS server.
>=20
>   The TLS session that is to be set up MUST be for the specific port
>   number and transport name that was given in the TLSA query.
>=20
> So this will not work for any type of DNS indirection mechanism, such =
as MX, SRV, etc?

Correct.

> Or does DNS retrieval of such records also requires DNSSec?

Undefined, as the draft says.

--Paul Hoffman


From adrian@olddog.co.uk  Sat Apr 28 04:57: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 C935121F86DF for ; Sat, 28 Apr 2012 04:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level: 
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nuiIhban2MQ for ; Sat, 28 Apr 2012 04:57:36 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0BD21F86DA for ; Sat, 28 Apr 2012 04:57:35 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3SBvT1Q013575;  Sat, 28 Apr 2012 12:57:29 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3SBvS9Q013560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 Apr 2012 12:57:29 +0100
From: "Adrian Farrel" 
To: "'Barry Leiba'" , "'Carl Reed'" 
References:  
In-Reply-To: 
Date: Sat, 28 Apr 2012 12:57:25 +0100
Message-ID: <044601cd2536$14caa920$3e5ffb60$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIsUJlhV4ODBkgCv1C4k0PxoTo5JAHr+OzUleJprIA=
Content-Language: en-gb
Cc: 'apps-discuss IETF' 
Subject: Re: [apps-discuss] SenML, sensor tasking, etc. From the Open Geospatial Consortium
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Apr 2012 11:57:36 -0000

Hi all,

I think Carl will want to be aware of
http://www.ietf.org/internet-drafts/draft-jennings-senml-08.txt and maybe
contact the authors listed on the document.

There was some discussion of the document on the Apps Discuss mailing list
starting with
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04361.html on 23rd
Feb this year.

Cheers,
Adrian (Not an Apps person, but understands how to use grep)

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of Barry Leiba
> Sent: 27 April 2012 23:34
> To: Carl Reed
> Cc: apps-discuss IETF
> Subject: Re: [apps-discuss] SenML, sensor tasking, etc. From the Open
Geospatial
> Consortium
> 
> Hi, Carl.
> There is no work on SenML going on in the IETF at this time, so
> there's nothing for us to coordinate.
> 
> The IAB, however, has held a workshop on "smart objects"; see here:
> http://www.iab.org/activities/workshops/smartobjects/
> 
> You can contact the IAB, of which Jari Arkko and Hannes Tschofenig are
> active in this space, and see what their plans are and what they
> suggest.  You can reach the IAB at .
> 
> Barry Leiba, Applications Area Director
> 
> 
> On Fri, Apr 27, 2012 at 5:30 PM, Carl Reed  wrote:
> > All -
> >
> > I have just become aware of the SenML and related sensor standard activities
> > in the IETF. I would like to consider how the sensor work in the IETF
> > community and the work on sensor standards in the OGC can be possibly
> > coordinated. By way of background.
> >
> > I am the CTO and Executive Director Standards for the Open Geospatial
> > Consortium (OGC). The OGC focus is on standards that enable the integration
> > and interoperable integration of geospatial services and content into any
> > application.
> >
> > Since 2000, a number of OGC Member organizations have been working an
> > activity we call Sensor Web Enablement (SWE). This activity has resulted in
> > a baseline of standards for describing, tasking, accessing, and managing
> > network accessible sensors. These standards work with both in-situ and
> > dynamic sensors. The SWE standards have been widely implemented in a
> variety
> > of domains, such as for ocean sensing, early warning systems, hydrology,
> > satellite ground stations, and mobile location services. Due to the OGC
> > focus on location enabled, network accessible sensors, we have been
> > collaborating with JTC1 Working Group 7, the W3C, ISO TC 211, KRONOS, IEEE,
> > and other organizations to insure that the standards stack for integrating
> > sensor observations into applications is as consistent as possible.
> > There is a high level OGC White Paper that describes the SWE standards and
> > architecture. This WP just underwent a major revision and has not been
> > publicly released yet. There is also a much more detailed technical SWE
> > document here: http://portal.opengeospatial.org/files/?artifact_id=29405
> >
> > Looking forward to this groups thoughts.
> >
> > Regards
> >
> > Carl Reed, PhD
> > CTO and Executive Director Standards Program
> > Open Geospatial Consortium
> > www.opengeospatial.org
> >
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From barryleiba@gmail.com  Sat Apr 28 06:42: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 339A921F8694 for ; Sat, 28 Apr 2012 06:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.963
X-Spam-Level: 
X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddAa6TkTvjKZ for ; Sat, 28 Apr 2012 06:42:38 -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 7CFB121F85DF for ; Sat, 28 Apr 2012 06:42:38 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so2559066obb.31 for ; Sat, 28 Apr 2012 06:42:38 -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=9+ZH8FP1IeGkbyEmATOR8qD7gZ1oLJgPLiwTCZGMXrs=; b=VS2X1IRMEnQ96Ks8ESkuLv8Ti+/zcKa6RKcYernYvHtbaJ9xeMbpFoKjoZMzbu+WNw r4tk9YTxzNJ8EPVJLMXavXKNVyBYHmc37MoC8+pQNc/1ulBEULG+swUC0kbZbjXyL9vs xXYfW8wuOf8WLCdbQEEzcUPtifIX3YbJm46T9a3lD/wSSMWCIDsLb0lkFXd9uSq3RJP/ hQksyj2HH0WW2tI2zgYa4IPJRFgqSFo+O3mm14SZqA7dS3vGGnhtET9yA+ehqiOaa7RP JkvJx00I8Lebcmf8lczth3k5XrAgE7j968WNpPu5N4GgKLInbH2UdGhr/iUywC8sI5qG dqdQ==
MIME-Version: 1.0
Received: by 10.182.225.2 with SMTP id rg2mr3407594obc.2.1335620558124; Sat, 28 Apr 2012 06:42:38 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.60.10.68 with HTTP; Sat, 28 Apr 2012 06:42:38 -0700 (PDT)
In-Reply-To: <044601cd2536$14caa920$3e5ffb60$@olddog.co.uk>
References:   <044601cd2536$14caa920$3e5ffb60$@olddog.co.uk>
Date: Sat, 28 Apr 2012 09:42:38 -0400
X-Google-Sender-Auth: kBxgFpnLnRt__ETqv3NGLXsmS4I
Message-ID: 
From: Barry Leiba 
To: adrian@olddog.co.uk
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss IETF 
Subject: Re: [apps-discuss] SenML, sensor tasking, etc. From the Open Geospatial Consortium
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Apr 2012 13:42:39 -0000

> I think Carl will want to be aware of
> http://www.ietf.org/internet-drafts/draft-jennings-senml-08.txt and maybe
> contact the authors listed on the document.

Yes, that's what prompted Carl to send his message in the first place
(so he is aware of it), and Jari, whom I suggested in my response, is
one of the authors.  The document is an individual contribution, and
not official IETF work at this point.  I think the IAB workshop is the
best fit, and also the IAB is the right place to go for
inter-organizational coordination.

Apart from that, it turns out that Carl knows Hannes.  So he intends
to contact him.

Barry

From paul@nohats.ca  Sat Apr 28 06:57: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 BB7BD21F8687; Sat, 28 Apr 2012 06:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.526
X-Spam-Level: 
X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[AWL=0.009,  BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,  HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxDyzfeA6MFg; Sat, 28 Apr 2012 06:57:02 -0700 (PDT)
Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 48F8421F8686; Sat, 28 Apr 2012 06:57:01 -0700 (PDT)
Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 5D8328036B; Sat, 28 Apr 2012 09:57:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 4F9DA80358; Sat, 28 Apr 2012 09:57:00 -0400 (EDT)
Date: Sat, 28 Apr 2012 09:57:00 -0400 (EDT)
From: Paul Wouters 
To: Paul Hoffman 
In-Reply-To: <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>
Message-ID: 
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Mailman-Approved-At: Sat, 28 Apr 2012 08:06:58 -0700
Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Apr 2012 13:57:02 -0000

On Fri, 27 Apr 2012, Paul Hoffman wrote:

>> 4.  Use of TLSA Records in TLS
>>
>>   Section 2.1 of this document defines the mandatory matching rules for
>>   the data from the TLSA certificate associations and the certificates
>>   received from the TLS server.
>>
>>   The TLS session that is to be set up MUST be for the specific port
>>   number and transport name that was given in the TLSA query.
>>
>> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc?
>
> Correct.

I'm a little confused here. If I have:

example.com IN MX 5 mail.example.com
mail.example.com IN TLSA [....]

That should still work right? When you do the lookup for
mail.example.com's A or AAAA record, you also lookup the TLSA/HASTLS
record for _25._tcp.mail.example.com ?

If mail.example.com is a CNAME, I understand there are some indirections
at play (though it might be technically incorrect to point an MX to a
CNAME)

Paul

From warren@kumari.net  Fri Apr 27 12:52: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 AACAC11E8086; Fri, 27 Apr 2012 12:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.516
X-Spam-Level: 
X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1F1ENbLyKmE; Fri, 27 Apr 2012 12:52:42 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE1711E8083; Fri, 27 Apr 2012 12:52:40 -0700 (PDT)
Received: from dhcp-172-19-119-246.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E248C1B40316; Fri, 27 Apr 2012 15:52:38 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari 
In-Reply-To: <24B5BD30-385D-4780-AD42-A4D1271DFA83@vpnc.org>
Date: Fri, 27 Apr 2012 15:52:33 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <9934BC7B-3193-44D1-870A-69A6F6A1612C@kumari.net>
References: <4F95CA0B.8050202@stpeter.im> <24B5BD30-385D-4780-AD42-A4D1271DFA83@vpnc.org>
To: Paul Hoffman 
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Sat, 28 Apr 2012 08:07:23 -0700
Cc: "apps-discuss@ietf.org" , Warren Kumari , iesg@ietf.org, dane@ietf.org
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Apr 2012 19:52:48 -0000

On Apr 27, 2012, at 2:01 PM, Paul Hoffman wrote:

> On Apr 23, 2012, at 2:30 PM, Peter Saint-Andre wrote:
>=20
>> Major Issue:
>>=20
>> This document does not mention that TLSA records cannot be used
>> directly in application protocols that depend on SRV (or NAPTR or
>> similar technologies). Although I realize that the DANE WG decided,
>> after much discussion, that the interaction between TLSA records and
>> SRV records is out of scope for this specification (and I do not mean
>> to reopen that discussion now), it would be very helpful for this
>> specification to reflect the results of that discussion. Although I
>> make specific suggestions regarding text under the Minor Issues =
below,
>> in general I think this document needs to be clearer about the
>> assumptions it has made in this regard; in fact, it seems to me that
>> an explicit applicability statement is warranted to avoid confusion =
of
>> the kind that Dave Cridland experienced (see his Last Call comments).
>=20
> Now covered in section 1.3, and includes a note that this document =
might be updated in the future to cover such things. (Note: it would be =
grand if an XMPPer would start work on this soon so we still have =
momentum.)

Yes -- we decided to take the "instead of boiling the ocean / being all =
things to all people"  approach with the initial doc to instead publish =
this and then have "How to do DANE with protocol foo" documents... This =
does mean that we want  need these docs.=20
They should be fairly simple to write -- submissions gratefully accepted =
:-)

W


>=20
>> 5. To those of us accustomed to SRV records, at first glance the
>> prefixed DNS domain name format defined in Section 3 looks strange:
>> why not _http._tcp.www.example.com instead of
>> _443._tcp.www.example.com? But when we take off our SRV-colored
>> glasses and realize that DANE assumes a DNS A/AAAA lookup on the
>> domain name, it all makes sense. Perhaps it would be helpful to
>> mention the reasoning behind the port number (instead of application
>> name) here?
>=20
> I would rather not try to summarize the debate in the spec, given that =
the result (numbers) are completely clear.
>=20
>> 6. In section 4, no mention is made of the application service that
>> the TLS expects to encounter at the TLS server:
>>=20
>>  The TLS session that is to be set up MUST be for the specific port
>>  number and transport name that was given in the TLSA query.
>>=20
>> Yet surely the application protocol can matter here, no?
>=20
> No.
>=20
>> In
>> particular, given that 443 is the one true port, we know that folks
>> might run non-HTTP applications over that port (for evil reasons, of
>> course).
>=20
> Sure. But...
>=20
>> Does DANE elide over the application protocol because we
>> simply assume that the "right" service is being served over any
>> particular port?
>=20
> Yes, that's the only sane way to do things currently. (The TLS WG is =
discussing adopting a protocol that would complicate this, but that's a =
long way off, I suspect.)
>=20
>> What about service providers that wish to restrict
>> the usage of a certificate to a particular application service type
>> (cf. RFC 6125)?
>=20
> I'm not sure how this is relevant. There is only one application =
protocol that can be running on 443 after TLS is established.
>=20
>> Or do we assume that it is enough to differentiate
>> among application services based on the underlying transport (as =
seems
>> to be the case in the text on "Multiple Ports" in Section 5)?
>=20
> Yes.
>=20
>> IMHO we
>> have a bit of a muddle here.
>=20
> I don't see it.
>=20
>> 7. The paragraph about SSL proxies in Section 8 says that "the TLS
>> client will get a certificate association from the DNS that will not
>> match the certificate that the SSL proxy uses with the client";
>> however, if the SSL proxy is working in concert with an external DNS
>> validator, is it possible to mimic the behavior of current SSL =
proxies?
>=20
> Maybe, but they are undefined.
>=20
> --Paul Hoffman
>=20
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
>=20


From alexey.melnikov@isode.com  Sat Apr 28 15:44: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 B0ED521F8618; Sat, 28 Apr 2012 15:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.203
X-Spam-Level: 
X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KjEXLWGbUFa; Sat, 28 Apr 2012 15:44:02 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id C38A021F8611; Sat, 28 Apr 2012 15:44:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335653040; d=isode.com; s=selector; i=@isode.com; bh=LMKtB8vPwjd1IriNbxnuKgE7HOalzIB8hOs8GTOA764=; 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=BV8cq6qO6m6z0P2DbxqLBhd67rrrSRnopeC3o/XognStmlmk4eVyW15ReKIdhw9QXlHnhv BT0chmhC9JbfTIZw3EaJ455eFwXFZgi0x0NeIIhqZFE2mzfUMxZGBkOVOsx0ARsPLVedov 8As8KNzYb7NmHJ3NMy7z34Tt0qNnUbs=;
Received: from [188.29.41.183] (188.29.41.183.threembb.co.uk [188.29.41.183])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Sat, 28 Apr 2012 23:43:59 +0100
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>
In-Reply-To: <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>
Message-Id: <243C7ECF-1936-43AC-9F1C-C2E7401BB700@isode.com>
X-Mailer: iPad Mail (9B176)
From: Alexey Melnikov 
Date: Sat, 28 Apr 2012 23:40:59 +0100
To: Paul Hoffman 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" , "dane@ietf.org" 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Apr 2012 22:44:02 -0000

Hi Paul,

On 28 Apr 2012, at 01:09, Paul Hoffman  wrote:

> On Apr 24, 2012, at 9:14 AM, Alexey Melnikov wrote:
>=20
>> Major Issue: none, although a) I am agreeing with Peter Saint-Andre's maj=
or issue and b) I would like to see a reply to my minor issues
>=20
> Here you go.
>=20
>> Minor Issues:
>>=20
>> 2.2.  TLSA RR Presentation Format
>>=20
>>  The presentation format of the RDATA portion is as follows:
>>=20
>> Presentation for what purpose? In management UIs? Is this a required pres=
entation format for DNS tools that can retrieve and update TLSA records?
>=20
> Added a pointer to RFC 1035.
>=20
>> [...]
>>=20
>>  o  The certificate association data field MUST be represented as a
>>     string of hexadecimal characters.  Whitespace is allowed within
>>     the string of hexadecimal characters.
>>=20
>> Please define what you mean by whitespace here? CR & LFs allowed?
>> Examples in the Section 2.3 seem to suggest that.
>=20
> Should be covered by the (new) reference to RFC 1035.

We shall see ;)
>=20
>> 3.  Domain Names for TLS Certificate Associations
>>=20
>>  2.  The protocol name of the transport on which a TLS-based service
>>      is assumed to exist is prepended with an underscore character
>>      ("_") to become the second left-most label in the prepared domain
>>      name.  The transport names defined for this protocol are "tcp",
>>      "udp" and "sctp".
>>=20
>> DCCP?
>=20
> No.

Why not?
>=20
>> Should there be a registry?
>=20
> Seems like overkill for how rarely new popular transports get added. Such a=
 transport is going to need to have an RFC for this anyway.

I don't see a point though, unless the new transport doesn't use ports.
But anyway, I am sure that you can just piggyback on an existing registry.
>=20
>> 4.  Use of TLSA Records in TLS
>>=20
>>  Section 2.1 of this document defines the mandatory matching rules for
>>  the data from the TLSA certificate associations and the certificates
>>  received from the TLS server.
>>=20
>>  The TLS session that is to be set up MUST be for the specific port
>>  number and transport name that was given in the TLSA query.
>>=20
>> So this will not work for any type of DNS indirection mechanism, such as M=
X, SRV, etc?
>=20
> Correct.

How?
>=20
>> Or does DNS retrieval of such records also requires DNSSec?
>=20
> Undefined, as the draft says.

>=20

Best Regards,
Alexey


From paul.hoffman@vpnc.org  Sat Apr 28 16:55: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 3722821F860B; Sat, 28 Apr 2012 16:55:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.535
X-Spam-Level: 
X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5GDRyebCKcD; Sat, 28 Apr 2012 16:55:11 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6D421F8607; Sat, 28 Apr 2012 16:55:11 -0700 (PDT)
Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3SNt9Wr045896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 Apr 2012 16:55:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman 
In-Reply-To: <243C7ECF-1936-43AC-9F1C-C2E7401BB700@isode.com>
Date: Sat, 28 Apr 2012 16:55:09 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B0B9F1C-1ADB-4965-9632-C902245DB0E5@vpnc.org>
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <243C7ECF-1936-43AC-9F1C-C2E7401BB700@isode.com>
To: Alexey Melnikov 
X-Mailer: Apple Mail (2.1257)
Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" , "dane@ietf.org" 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Apr 2012 23:55:12 -0000

On Apr 28, 2012, at 3:40 PM, Alexey Melnikov wrote:

>>> DCCP?
>>=20
>> No.
>=20
> Why not?

Because DCCP is a thinly-used protocol that nearly no one in this WG has =
experience with. What's the chance we will get inclusion of it correct? =
It would be better to have someone write a DCCP-specific update that =
covers the topic well.


>>> So this will not work for any type of DNS indirection mechanism, =
such as MX, SRV, etc?
>>=20
>> Correct.
>=20
> How?

How will it not work? Quite well, I expect. :-)

This was discussed extensively on the list, and the WG decided that =
indirection mechanisms need to define the relationship between the name =
used in the lookup and certificate association from DANE TLS. There is =
text about this in the document, and more going in the next draft at the =
request of Peter St. Andre. The experience with RFC 6125 pretty much =
assures that any generic solution will not be interoperable and might =
cause security problems based on false matches, and we wanted to avoid =
that.

--Paul Hoffman


From cloos@jhcloos.com  Sat Apr 28 17:22: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 12C2521F85BD; Sat, 28 Apr 2012 17:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.744
X-Spam-Level: 
X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=0.857,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPBkAgsjz9l1; Sat, 28 Apr 2012 17:22:02 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE2921F84EC; Sat, 28 Apr 2012 17:22:02 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 87987401BD; Sun, 29 Apr 2012 00:21:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1335658920; bh=J4OSoBvus2+aaauV27ERSEFgFjujuTxPu956MK11cvQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=lnLn/6qdTROtMLNKwnsoFDBaxVqGEofOT6liaYSjGlR8sGDHvVtdSYVfXGiS/eHJf gcP9veI7+CduSux+Me3euRi4/pdRZisYYJJ5v43JR9KpCGCuo4YCLKqZpolERrxCXZ LFmSdQoXqxhd34RhGbNrF+yuPWjGSJMyuD2Z7foM=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id E93F636004C; Sun, 29 Apr 2012 00:19:22 +0000 (UTC)
From: James Cloos 
To: Paul Hoffman 
In-Reply-To: <6B0B9F1C-1ADB-4965-9632-C902245DB0E5@vpnc.org> (Paul Hoffman's message of "Sat, 28 Apr 2012 16:55:09 -0700")
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <243C7ECF-1936-43AC-9F1C-C2E7401BB700@isode.com> <6B0B9F1C-1ADB-4965-9632-C902245DB0E5@vpnc.org>
User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2012 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Sat, 28 Apr 2012 20:19:22 -0400
Message-ID: 
Lines: 22
MIME-Version: 1.0
Content-Type: text/plain
Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" , "dane@ietf.org" 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Apr 2012 00:22:03 -0000

>>>>> "PH" == Paul Hoffman  writes:

PH> Because DCCP is a thinly-used protocol that nearly no one in this WG
PH> has experience with. What's the chance we will get inclusion of it
PH> correct? It would be better to have someone write a DCCP-specific
PH> update that covers the topic well.

What is there to get wrong?  For SRV, rfc-2782 says:

   Proto
        The symbolic name of the desired protocol, with an underscore
        (_) prepended to prevent collisions with DNS labels that occur
        in nature.  _TCP and _UDP are at present the most useful values
        for this field, though any name defined by Assigned Numbers or
        locally may be used (as for Service).  The Proto is case
        insensitive.

and that is the type of language TLSA should use for the proto.

-JimC
-- 
James Cloos          OpenPGP: 1024D/ED7DAEA6

From msk@cloudmark.com  Sun Apr 29 00:11: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 23F6A21F849B for ; Sun, 29 Apr 2012 00:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level: 
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xELGNzkQx4Xp for ; Sun, 29 Apr 2012 00:11:44 -0700 (PDT)
Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF2921F849A for ; Sun, 29 Apr 2012 00:11:44 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 3jBi1j0010as01C01jBi3Q; Sun, 29 Apr 2012 00:11:45 -0700
X-CMAE-Match: 0
X-CMAE-Score: 0.00
X-CMAE-Analysis: v=2.0 cv=K4ag7lqI c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=avgx2eInZzkA:10 a=-w2GM7y7aYgA:10 a=zutiEJmiVI4A:10 a=WoLjiF6ve7AA:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=TDYAGFK6AAAA:8 a=A1X0JdhQAAAA:8 a=YLdlEpOvAAAA:8 a=_0Nle5OOUZlvcOWdENMA:9 a=3TrdVEZvrVe5i4CMYjUA:7 a=CjuIK1q_8ugA:10 a=vYwTUIGbb5EA:10 a=Hn6JTXX_6TUA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=6xKn5IHmBtXPfkRWwCUA:9 a=Q3ccDL5MLOD-0PAdZzoA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=KWZX7jh02wsA:10 a=WNhuW-6je1UA:10 a=QMZKka45TBd+hNGtXG2bIg==:117
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Sun, 29 Apr 2012 00:11:19 -0700
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" , "websec@ietf.org" , "draft-ietf-websec-strict-transport-sec@tools.ietf.org" 
Thread-Topic: AppsDir review of draft-ietf-websec-strict-transport-sec
Thread-Index: Ac0l10W9SlaETdSSRZWdVKRKL9Sksw==
Date: Sun, 29 Apr 2012 07:11:18 +0000
Message-ID: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.22.1.158]
Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E003928106147exchmbx901corpclo_"
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335683505; bh=1wfW6vtGHAxRPLbEdKUy+G1EqpPiwbwzD+K8umLlwBE=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=WCG5IvbomSCvLpnjSAh/Q6UExXXsX+jxblY+z4j7XytfTc9+/P4uwFmne8tHVUwCD rbOXOPYLFl5AcLXqBwwF11Nri0hWlQ1AJCgy2WAxF6jvME65bxUbXwGFko5Mj6iZH4 upS2ConI/7F9MyDKLfC9qDEvIUyv+wMeo69s6x+g=
Subject: [apps-discuss] AppsDir review of draft-ietf-websec-strict-transport-sec
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Apr 2012 07:11:46 -0000

--_000_9452079D1A51524AA5749AD23E003928106147exchmbx901corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

[NOTE: This is a pre-Last Call review requested by the Applications Area Di=
rectors.  Please disregard any boilerplate indicating otherwise.]

Please resolve these comments along with any other Last Call comments you m=
ay receive.  Please wait for direction from your document shepherd or AD be=
fore posting a new version of the draft.

Document: draft-ietf-websec-strict-transport-sec-06
Title: HTTP Strict Transport Security (HSTS)
Reviewer: Murray S. Kucherawy
Review Date: April 28, 2012
IETF Last Call Date: n/a
IESG Telechat Date: n/a

Summary: This draft is almost ready for publication as a Standards Track RF=
C, but has a few issues that should be fixed before publication.

Reviewer Synopsis: The document specifies methods by which providers of web=
-based services can signal to users (and their web clients) that their serv=
ices should only be accessed via secure mechanisms.  It also gives a detail=
ed treatment of the threat model leading to the proposal it contains.

This is one of the more well-written drafts I've reviewed in some time.  It=
's clear and very complete in terms of presenting the background, which is =
very helpful to readers (and reviewers!) not expert in this area.

MAJOR ISSUES:

None.

MINOR ISSUES:

Section 2.3.2: Your Security Considerations section should probably include=
 a pointer to this section.

Section 3: Are the latter two paragraphs really necessary?  I only find suc=
h statements useful when minimum conformance is not the same thing as full =
conformance.

Section 4, HTTP Strict Transport Security Host: Should this say "for all we=
b pages it serves" or similar?

Section 4: Expand ABNF on first use, and include a reference to RFC5234.  (=
The reference could instead go in Section 6.)

Section 6.1: The ABNF you have there requires a leading semi-colon.  Based =
on your examples, I think instead you want:

        Strict-Transport-Security =3D "Strict-Transport-Security" ":"
                                    directive *( ";" [directive] )

Note that this also allows:

        Strict-Transport-Security: foobar;;;;;;;;;;;;

Is that okay?

Section 6.1: What's "the STS directive extension point"?

Section 6.1.1: I think the "delta-seconds" should be:

        delta-seconds =3D 1*DIGIT
                      ; defined in Section 3.3.2 of [RFC2616]

The angle-bracket notation you have there doesn't seem to be normal.

Section 6.2: The second example isn't strictly correct because no space is =
allowed around the semi-colon in the ABNF in Section 6.1.  It looks like yo=
u'll need to add optional whitespace at various points in the ABNF, or corr=
ect the example.

Section 8.1: The "Note:" includes stuff that should be normative, and thus =
is not appropriate for a side discussion note.  It doesn't quite jive with =
how you've defined use of "Note:" as a document convention.

Section 8.2: The "Note that..." at the end threw me for a loop.  How does w=
hat's said in 8.2 imply what's stated here?  For example, what does it say =
about SMTP or FTP?

Section 10.1: This discussion got me wondering why an absolute time for HST=
S Policy expiration isn't used instead of a delta.  Perhaps that could be e=
xplained somewhere like Appendix A.  (Yes, I know about time synchronizatio=
n, but this text gave me pause.)

Section 10.3: "example-ca.com" is not a reserved domain name for use in exa=
mples.  Suggest "ca.example.com" or "ca.example".  Same issue with "example=
-ca-services.net".

Section 14.2: The "but the attacker has established somewhere" clause doesn=
't parse for me.  What's it trying to say?

NITS (mostly trying to save the RFC Editor some work here):

There are so many important references to [ForceHTTPS] that I think it migh=
t be helpful to include page or section numbers for those.

Section 1: The Abstract uses "Web" as a proper noun, but this section inclu=
des uses of it that are all lowercase.  I believe it should be used one way=
 or the other throughout the document.

Section 1: "Section", when referring to a section of a document, should be =
capitalized.  (Also occurs in a few other places.)

Section 2.2: s/known as a HSTS Host/known as an HSTS Host/

Section 2.2, bullet 1: s/to be/such that they are replaced by/

Section 2.2, bullet 3: s/to a HSTS Host/to an HSTS Host/

Section 2.3.1.1: Define or provide a reference for what Firefox is, in case=
 it's somehow not in common use at the time some future reader gets this.

Section 2.3.1.2: Define or expand "CA" on first use.  For that matter, woul=
d it be possible to reference something that talks about the difference bet=
ween self-signed and CA-signed certificates, and why they get different tre=
atment?

Section 2.3.1.3: Define or expand "SWF" on first use.

Section 2.3.1.3: s/by injecting script/by injecting a script/

Section 2.4.1.1, bullet 1: s/interacted with/accessed/

Section 2.4.1.1, bullet 3: s/to persistently remember/to retain persistent =
data about/

Section 2.4.1.1, ending Note: The last "," should be a ";", or a period fol=
lowed by a new sentence.

Section 4: Suggest ending terms with ":" so that you don't get things like =
how "domain name label" looks in this version of the draft.

Section 4, "HTTP Strict Transport Security Host": s/policy/Policy/, so it's=
 clear we're using your definition.

Section 4, "HTTP Strict Transport Security Policy": Is "Policy" right here?=
  Isn't it really a "Protocol"?

Section 4, "HTTP Strict Transport Security Policy": s/specified/defined/ (s=
o as to avoid "specified in this specification")

Section 4, "Known HSTS Host": s/a HSTS/an HSTS/; two instances

Section 4, "Local policy": Why is "configuration settings" quoted?

Section 4, "unknown HSTS Host": s/a HSTS/an HSTS/

Section 5 and beyond: You define "HSTS Policy" and "HSTS Host" (note capita=
lization), but use "HSTS policy" and "HSTS host" in numerous places.  Best =
to be consistent, so it's clear you're referring to the defined term.

Section 5, second paragraph: All-lowercase "may" should probably be "MAY".

Section 6.1.2: s/which/that/

Section 7: s/facets:/facets,/; s/the second/and the second/

Section 7.1: s/a STS header/an STS header/; two instances

Section 7.1: s/difficult to uniformly emit STS header fields/difficult to e=
mit STS header fields uniformly/

Section 7.2, second bullet: Add a matching "--" after "components".

Section 8.1: s/a STS header/an STS header/; s/field, /field /

Section 8.1.1: s/a HSTS Host/an HSTS Host/

Section 8.1.1: s/that the host responded to/to which the host responded/

Section 8.1.1: That last paragraph is one big long sentence.  Suggest break=
ing it up.

Section 8.5: The "For example, ..." is a sentence fragment.

Section 9, bullet 2: Remove the "," after "label".

Section 9, bullet 2: s/latter,/latter;/

Section 9, bullet 3: The (".") should come after the hex.

Section 10: "This section is non-normative."  (cringe; I'm still of the opi=
nion that a section is implicitly non-normative if it has no normative text=
 in it, an
d these notations are extraneous)

Section 10.1, fourth paragraph: This is another sentence fragment.

Section 10.2: s/their own/its own/ (the noun is singular, the verb has to a=
gree)

Section 10.2, second paragraph: s/certificates, and their own/certificates =
and its own/; various other "their/they" to "its/it", because "organization=
" isn't plural

Section 10.2, note: s/attack, see/attack.  See/

Section 10.3: s/implications -- for/implications.  For/

Section 10.3, second paragraph: s/which/that/

Section 10.3: s/HSTS, and that have/HSTS that have/; s/application, would/a=
pplication would/

Section 11: (cringe)

Section 11: You variably spell it "implementors" and "implementers".  I'm p=
retty sure the latter is correct, but either way, some of them are not.  :-=
)

Section 11.1: s/Establishment"),/Establishment")/

Section 11.2: s/a HSTS Host/an HSTS Host/

Section 11.2, Note: s/basis -- see/basis.  See/

Section 11.2, Note: s/is independent of/is independent of,/

Section 11.2: Opens with a non-sentence.

Section 11.3: Opens with a non-sentence.

Section 11.4: Opens with a non-sentence.

Section 11.4, Note: s/to more clearly define the term(s)/to define the term=
(s) more clearly/

Section 11.5: Opens with a non-sentence.

Section 12: All lowercase MUST here.

Section 12.2: Seriously nitty here: The "host, and the port (if present)" d=
oesn't make it clear if the separating colon is included.

Section 14.1, first bullet: Missing close parenthesis.

Section 14.1, second bullet: s/to no longer be regarded/to cease being rega=
rded/

Section 14.1: s/And even if the risk/Even if the risk/

Section 14.1: s/as a HSTS Host.  Thus as/as an HSTS Host.  Thus, as/

Section 14.1: s/But once/Once/

Section 14.2: s/to adequately protect/to provide adequate protection for/

Section 14.3: s/to manually configure HSTS Policy/to configure HSTS Policy =
manually/

Section 14.3, third "*" bullet: Contains two sentence fragments.

Section 14.3, final paragraph: s/to automatically regard/to regard automati=
cally/

Section 14.5: Expand NTP on first use, and provide a reference.

Section 14.6: Opens with a sentence fragment.

-MSK

--_000_9452079D1A51524AA5749AD23E003928106147exchmbx901corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











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


 


[NOTE: This is a pre-Last Call review requested by t=
he Applications Area Directors.  Please disregard any boilerplate indi=
cating otherwise.]


 


Please resolve these comments along with any other L=
ast Call comments you may receive.  Please wait for direction from you=
r document shepherd or AD before posting a new version of the draft.


 


Document: draft-ietf-websec-strict-transport-sec-06<=
o:p>


Title: HTTP Strict Transport Security (HSTS)


Reviewer: Murray S. Kucherawy


Review Date: April 28, 2012


IETF Last Call Date: n/a


IESG Telechat Date: n/a


 


Summary: This draft is almost ready for publication =
as a Standards Track RFC, but has a few issues that should be fixed before =
publication.


 


Reviewer Synopsis: The document specifies methods by=
 which providers of web-based services can signal to users (and their web c=
lients) that their services should only be accessed via secure mechanisms.&=
nbsp; It also gives a detailed treatment
 of the threat model leading to the proposal it contains.


 


This is one of the more well-written drafts I've rev=
iewed in some time.  It's clear and very complete in terms of presenti=
ng the background, which is very helpful to readers (and reviewers!) not ex=
pert in this area.


 


MAJOR ISSUES:


 


None.


 


MINOR ISSUES:


 


Section 2.3.2: Your Security Considerations section =
should probably include a pointer to this section.


 


Section 3: Are the latter two paragraphs really nece=
ssary?  I only find such statements useful when minimum conformance is=
 not the same thing as full conformance.


 


Section 4, HTTP Strict Transport Security Host: Shou=
ld this say "for all web pages it serves" or similar?<=
/p>

 


Section 4: Expand ABNF on first use, and include a r=
eference to RFC5234.  (The reference could instead go in Section 6.)


 


Section 6.1: The ABNF you have there requires a lead=
ing semi-colon.  Based on your examples, I think instead you want:


 


        Strict-Tr=
ansport-Security =3D "Strict-Transport-Security" ":"


        &nbs=
p;            &=
nbsp;           &nbs=
p;  directive *( ";" [directive] )


 


Note that this also allows:


 


        Strict-Tr=
ansport-Security: foobar;;;;;;;;;;;;


 


Is that okay?


 


Section 6.1: What's "the STS directive extensio=
n point"?


 


Section 6.1.1: I think the "delta-seconds"=
 should be:


 


        delta-sec=
onds =3D 1*DIGIT


        &nbs=
p;             =
; defined in Section 3.3.2 of [RFC2616]


 


The angle-bracket notation you have there doesn't se=
em to be normal.


 


Section 6.2: The second example isn't strictly corre=
ct because no space is allowed around the semi-colon in the ABNF in Section=
 6.1.  It looks like you'll need to add optional whitespace at various=
 points in the ABNF, or correct the example.


 


Section 8.1: The "Note:" includes stuff th=
at should be normative, and thus is not appropriate for a side discussion n=
ote.  It doesn't quite jive with how you've defined use of "Note:=
" as a document convention.


 


Section 8.2: The "Note that..." at the end=
 threw me for a loop.  How does what's said in 8.2 imply what's stated=
 here?  For example, what does it say about SMTP or FTP?

 


Section 10.1: This discussion got me wondering why a=
n absolute time for HSTS Policy expiration isn't used instead of a delta.&n=
bsp; Perhaps that could be explained somewhere like Appendix A.  (Yes,=
 I know about time synchronization, but this
 text gave me pause.)


 


Section 10.3: "example-ca.com" is not a re=
served domain name for use in examples.  Suggest "ca.example.com&=
quot; or "ca.example".  Same issue with "example-ca-ser=
vices.net".


 


Section 14.2: The "but the attacker has establi=
shed somewhere" clause doesn't parse for me.  What's it trying to=
 say?


 


NITS (mostly trying to save the RFC Editor some work=
 here):


 


There are so many important references to [ForceHTTP=
S] that I think it might be helpful to include page or section numbers for =
those.


 


Section 1: The Abstract uses "Web" as a pr=
oper noun, but this section includes uses of it that are all lowercase.&nbs=
p; I believe it should be used one way or the other throughout the document=
.


 


Section 1: "Section", when referring to a =
section of a document, should be capitalized.  (Also occurs in a few o=
ther places.)


 


Section 2.2: s/known as a HSTS Host/known as an HSTS=
 Host/


 


Section 2.2, bullet 1: s/to be/such that they are re=
placed by/


 


Section 2.2, bullet 3: s/to a HSTS Host/to an HSTS H=
ost/


 


Section 2.3.1.1: Define or provide a reference for w=
hat Firefox is, in case it's somehow not in common use at the time some fut=
ure reader gets this.


 


Section 2.3.1.2: Define or expand "CA" on =
first use.  For that matter, would it be possible to reference somethi=
ng that talks about the difference between self-signed and CA-signed certif=
icates, and why they get different treatment?


 


Section 2.3.1.3: Define or expand "SWF" on=
 first use.


 


Section 2.3.1.3: s/by injecting script/by injecting =
a script/


 


Section 2.4.1.1, bullet 1: s/interacted with/accesse=
d/


 


Section 2.4.1.1, bullet 3: s/to persistently remembe=
r/to retain persistent data about/


 


Section 2.4.1.1, ending Note: The last ","=
 should be a ";", or a period followed by a new sentence.


 


Section 4: Suggest ending terms with ":" s=
o that you don't get things like how "domain name label" looks in=
 this version of the draft.


 


Section 4, "HTTP Strict Transport Security Host=
": s/policy/Policy/, so it's clear we're using your definition.


 


Section 4, "HTTP Strict Transport Security Poli=
cy": Is "Policy" right here?  Isn't it really a "P=
rotocol"?


 


Section 4, "HTTP Strict Transport Security Poli=
cy": s/specified/defined/ (so as to avoid "specified in this spec=
ification")


 


Section 4, "Known HSTS Host": s/a HSTS/an =
HSTS/; two instances


 


Section 4, "Local policy": Why is "co=
nfiguration settings" quoted?


 


Section 4, "unknown HSTS Host": s/a HSTS/a=
n HSTS/


 


Section 5 and beyond: You define "HSTS Policy&q=
uot; and "HSTS Host" (note capitalization), but use "HSTS po=
licy" and "HSTS host" in numerous places.  Best to be c=
onsistent, so it's clear you're referring to the defined term.

 


Section 5, second paragraph: All-lowercase "may=
" should probably be "MAY".


 


Section 6.1.2: s/which/that/


 


Section 7: s/facets:/facets,/; s/the second/and the =
second/


 


Section 7.1: s/a STS header/an STS header/; two inst=
ances


 


Section 7.1: s/difficult to uniformly emit STS heade=
r fields/difficult to emit STS header fields uniformly/


 


Section 7.2, second bullet: Add a matching "--&=
quot; after "components".


 


Section 8.1: s/a STS header/an STS header/; s/field,=
 /field /


 


Section 8.1.1: s/a HSTS Host/an HSTS Host/


 


Section 8.1.1: s/that the host responded to/to which=
 the host responded/


 


Section 8.1.1: That last paragraph is one big long s=
entence.  Suggest breaking it up.


 


Section 8.5: The "For example, ..." is a s=
entence fragment.


 


Section 9, bullet 2: Remove the "," after =
"label".


 


Section 9, bullet 2: s/latter,/latter;/

 


Section 9, bullet 3: The (".") should come=
 after the hex.


 


Section 10: "This section is non-normative.&quo=
t;  (cringe; I'm still of the opinion that a section is implicitly non=
-normative if it has no normative text in it, an


d these notations are extraneous)


 


Section 10.1, fourth paragraph: This is another sent=
ence fragment.


 


Section 10.2: s/their own/its own/ (the noun is sing=
ular, the verb has to agree)


 


Section 10.2, second paragraph: s/certificates, and =
their own/certificates and its own/; various other "their/they" t=
o "its/it", because "organization" isn't plural


 


Section 10.2, note: s/attack, see/attack.  See/=



 


Section 10.3: s/implications -- for/implications.&nb=
sp; For/


 


Section 10.3, second paragraph: s/which/that/


 


Section 10.3: s/HSTS, and that have/HSTS that have/;=
 s/application, would/application would/


 


Section 11: (cringe)


 


Section 11: You variably spell it "implementors=
" and "implementers".  I'm pretty sure the latter is co=
rrect, but either way, some of them are not.  :-)


 


Section 11.1: s/Establishment"),/Establishment&=
quot;)/


 


Section 11.2: s/a HSTS Host/an HSTS Host/=



 


Section 11.2, Note: s/basis -- see/basis.  See/=



 


Section 11.2, Note: s/is independent of/is independe=
nt of,/


 


Section 11.2: Opens with a non-sentence.<=
/p>

 


Section 11.3: Opens with a non-sentence.<=
/p>

 


Section 11.4: Opens with a non-sentence.<=
/p>

 


Section 11.4, Note: s/to more clearly define the ter=
m(s)/to define the term(s) more clearly/


 


Section 11.5: Opens with a non-sentence.<=
/p>

 


Section 12: All lowercase MUST here.


 


Section 12.2: Seriously nitty here: The "host, =
and the port (if present)" doesn't make it clear if the separating col=
on is included.


 


Section 14.1, first bullet: Missing close parenthesi=
s.


 


Section 14.1, second bullet: s/to no longer be regar=
ded/to cease being regarded/


 


Section 14.1: s/And even if the risk/Even if the ris=
k/


 


Section 14.1: s/as a HSTS Host.  Thus as/as an =
HSTS Host.  Thus, as/


 


Section 14.1: s/But once/Once/


 


Section 14.2: s/to adequately protect/to provide ade=
quate protection for/


 


Section 14.3: s/to manually configure HSTS Policy/to=
 configure HSTS Policy manually/


 


Section 14.3, third "*" bullet: Contains t=
wo sentence fragments.


 


Section 14.3, final paragraph: s/to automatically re=
gard/to regard automatically/


 


Section 14.5: Expand NTP on first use, and provide a=
 reference.


 


Section 14.6: Opens with a sentence fragment.


 


-MSK






--_000_9452079D1A51524AA5749AD23E003928106147exchmbx901corpclo_--

From alexey.melnikov@isode.com  Sun Apr 29 03:42: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 51A6121F8542; Sun, 29 Apr 2012 03:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.203
X-Spam-Level: 
X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRx5JK9IOrJh; Sun, 29 Apr 2012 03:42:19 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E34421F8540; Sun, 29 Apr 2012 03:42:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335696136; d=isode.com; s=selector; i=@isode.com; bh=W2sohSlhAlyC8znkLMjJ/30Y/6EGJiPJ9bh3fjtDTYc=; 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=WnC0407p677VY2pjm9gkqfqE04S6uVS9aWwbgfVpL1HtvW7m9E/3TsbTn832g4e3ifIYMZ /A2pY3nzWZ/75ZArwg/xZFhhVx89mLHi4fy5oA+4BIbWxRVtOZ17S1qJfnC7t9i79LFVeY E8SMrRCbW6c8ZyvgBtDCjCy5S7tk2rI=;
Received: from [188.29.134.82] (188.29.134.82.threembb.co.uk [188.29.134.82])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Sun, 29 Apr 2012 11:42:16 +0100
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <243C7ECF-1936-43AC-9F1C-C2E7401BB700@isode.com> <6B0B9F1C-1ADB-4965-9632-C902245DB0E5@vpnc.org>
In-Reply-To: <6B0B9F1C-1ADB-4965-9632-C902245DB0E5@vpnc.org>
Message-Id: <16165BCD-33C7-4B37-A3C8-89260CA4A934@isode.com>
X-Mailer: iPad Mail (9B176)
From: Alexey Melnikov 
Date: Sun, 29 Apr 2012 11:42:15 +0100
To: Paul Hoffman 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" , "dane@ietf.org" 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Apr 2012 10:42:20 -0000

On 29 Apr 2012, at 00:55, Paul Hoffman  wrote:

> On Apr 28, 2012, at 3:40 PM, Alexey Melnikov wrote:
>=20
>>>> DCCP?
>>>=20
>>> No.
>>=20
>> Why not?
>=20
> Because DCCP is a thinly-used protocol that nearly no one in this WG has e=
xperience with. What's the chance we will get inclusion of it correct? It wo=
uld be better to have someone write a DCCP-specific update that covers the t=
opic well.

I think this requires inserting 2 words. But Transport ADs will get on your c=
ase if they care.
>=20
>>>> So this will not work for any type of DNS indirection mechanism, such a=
s MX, SRV, etc?
>>>=20
>>> Correct.
>>=20
>> How?
>=20
> How will it not work? Quite well, I expect. :-)

Sorry, missed "not" in my own earlier email ;).
>=20
> This was discussed extensively on the list, and the WG decided that indire=
ction mechanisms need to define the relationship between the name used in th=
e lookup and certificate association from DANE TLS. There is text about this=
 in the document, and more going in the next draft at the request of Peter S=
t. Andre. The experience with RFC 6125 pretty much assures that any generic s=
olution will not be interoperable and might cause security problems based on=
 false matches, and we wanted to avoid that.


From paul.hoffman@vpnc.org  Sun Apr 29 06:58: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 0B1D221F84EB; Sun, 29 Apr 2012 06:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.536
X-Spam-Level: 
X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epE4oE+GCbcc; Sun, 29 Apr 2012 06:58:53 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA2921F84E7; Sun, 29 Apr 2012 06:58:53 -0700 (PDT)
Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3TDwopa065921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 29 Apr 2012 06:58:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman 
In-Reply-To: <16165BCD-33C7-4B37-A3C8-89260CA4A934@isode.com>
Date: Sun, 29 Apr 2012 06:58:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0876ADD6-999C-43E3-9EFB-31F256CCCD3A@vpnc.org>
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <243C7ECF-1936-43AC-9F1C-C2E7401BB700@isode.com> <6B0B9F1C-1ADB-4965-9632-C902245DB0E5@vpnc.org> <16165BCD-33C7-4B37-A3C8-89260CA4A934@isode.com>
To: Alexey Melnikov 
X-Mailer: Apple Mail (2.1257)
Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" , "dane@ietf.org" 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Apr 2012 13:58:54 -0000

On Apr 29, 2012, at 3:42 AM, Alexey Melnikov wrote:

> On 29 Apr 2012, at 00:55, Paul Hoffman  wrote:
>=20
>> On Apr 28, 2012, at 3:40 PM, Alexey Melnikov wrote:
>>=20
>>>>> DCCP?
>>>>=20
>>>> No.
>>>=20
>>> Why not?
>>=20
>> Because DCCP is a thinly-used protocol that nearly no one in this WG =
has experience with. What's the chance we will get inclusion of it =
correct? It would be better to have someone write a DCCP-specific update =
that covers the topic well.
>=20
> I think this requires inserting 2 words. But Transport ADs will get on =
your case if they care.

If the Transport ADs care and are willing to say "the spec doesn't need =
to know anything about DCCP, just add it", I suspect the WG would be =
happy to add it. (We're happy to hear from them now, before we do the =
final draft before IESG review, of course.)

--Paul Hoffman


From ned.freed@mrochek.com  Sun Apr 29 11:19: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 63E0321F8548 for ; Sun, 29 Apr 2012 11:19:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Level: 
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zCVL4zaJNf1 for ; Sun, 29 Apr 2012 11:19:19 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E65EF21F8541 for ; Sun, 29 Apr 2012 11:19:18 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEW0L11ONK000LO4@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 29 Apr 2012 11:19:13 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Sun, 29 Apr 2012 11:19:08 -0700 (PDT)
Message-id: <01OEW0KXOB9A0006TF@mauve.mrochek.com>
Date: Sun, 29 Apr 2012 11:16:52 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Sat, 28 Apr 2012 12:57:25 +0100" <044601cd2536$14caa920$3e5ffb60$@olddog.co.uk>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References:   <044601cd2536$14caa920$3e5ffb60$@olddog.co.uk>
To: Adrian Farrel 
Cc: 'Barry Leiba' , 'apps-discuss IETF' 
Subject: Re: [apps-discuss] SenML, sensor tasking, etc. From the Open Geospatial Consortium
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Apr 2012 18:19:19 -0000

> I think Carl will want to be aware of
> http://www.ietf.org/internet-drafts/draft-jennings-senml-08.txt and maybe
> contact the authors listed on the document.

One interesting thing about this draft is that the cites clearly imply that the
intent is to publish the actual SENML specification as an RFC. (I note in
passing that publication by some standards body is necessary for the types to
be in the standards tree.)

				Ned

From hub.ryck@gmail.com  Sun Apr 29 09:59: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 F307021F84E4 for ; Sun, 29 Apr 2012 09:59:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.111
X-Spam-Level: 
X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[AWL=0.486,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5TN2sXZzZg3 for ; Sun, 29 Apr 2012 09:59:13 -0700 (PDT)
Received: from mail-pb0-f66.google.com (mail-pb0-f66.google.com [209.85.160.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB0221F84E1 for ; Sun, 29 Apr 2012 09:59:13 -0700 (PDT)
Received: by pbbrp8 with SMTP id rp8so148907pbb.1 for ; Sun, 29 Apr 2012 09:59:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U5pfd3E2yG3ioX2hDEeJkIOKDP+NtsrQNCCVzA5OCBA=; b=bSckrGwsUyF7ilo/z6fAPmOs5iyd8Np3fgCLxia7N3bUQV4HhljQ8Ntmc2NVWx1Gia W/T5T3gptezQjiN1FObzfbVOzGW/7H1b17GdqHWLoQMCehY5OcisKPx07K4TAPTVcpmK tftGraUF9RvG9oUMRff2k9zCwO2S0uEZVnqMdr0vIZWm7NsE1cW13/4xf1o4B+fM1j4K 9lhkslFvfgJl12QY2zS8H58AlmHvJyPnrg0pV/porR8kqy/fDcVwo8cPsCUGDeOSqSLs UUGPP73gdoAgatVLB1Q9JFJZZn8mBi5rzTweKQrZxG0A3plSutyyuQiiUPB76RcjSM7i y8EA==
MIME-Version: 1.0
Received: by 10.68.232.163 with SMTP id tp3mr7076067pbc.70.1335718753205; Sun, 29 Apr 2012 09:59:13 -0700 (PDT)
Received: by 10.68.130.129 with HTTP; Sun, 29 Apr 2012 09:59:13 -0700 (PDT)
In-Reply-To: <6.2.5.6.2.20120421143240.07253358@elandnews.com>
References: <6.2.5.6.2.20120421143240.07253358@elandnews.com>
Date: Sun, 29 Apr 2012 18:59:13 +0200
Message-ID: 
From: hub ryck 
To: SM 
Content-Type: multipart/alternative; boundary=047d7b33d4cccdfc9804bed4410a
X-Mailman-Approved-At: Sun, 29 Apr 2012 13:39:48 -0700
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Comments on draft-hryckelynck-writing-rfcs-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: Sun, 29 Apr 2012 16:59:15 -0000

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

Hello,

[message copied to apps-discuss@ in case other people would like to provide
feedback about this proposal]

*The initial version of draft-hryckelynck-writing-rfcs-01 was posted on
April 1.  I wasn't sure whether the date was intentionally chosen.  I note
that draft-hryckelynck-writing-rfcs is intended to be published as
Experimental.  Do you have a plan about how long this experiment should be
run?
*
About April 1st, I confirm to you this is not a "funny RFC".
I do not have a plan yet about how long this experiment should be run.
If the community gives sympathetic consideration to this idea maybe one day
I would intend another status. But at this time the only intended status is
experimental.



*In the Abstract Section:

 "Mail Accepted by Previous Sending defines a mechanism by which
  incoming unsollicited mails MAY be rejected or penalized by a MTA if
  their sender address domains has never been a destination for the
  outgoing mails treated by this MTA."

The "MAY" should be written as "may".*

Modified in new version "draft-hryckelynck-writing-rfcs-03"


*
In the Introduction Section:

 "Mails with, for example, a pornographic contains are easy to identify
  as mail we MUST intercept."

Some people enjoy pornographic content.  The above requirement forbids
that.  Is that intentional?*

You are right. In fact I was thinking pornographic content should not be
sent to a working environment. But then you could also say that some people
are working in the pornographic business. So I will take another example.

Sentence has been modified in new version
"draft-hryckelynck-writing-rfcs-03" as follows :

 "Mails with, for example, an attempted fraud content are easy to identify
as mails we MUST intercept."



*The RFC 2119 key words in the first section should be removed.
*
Modified in new version "draft-hryckelynck-writing-rfcs-03"



*In Section 2, you are using a "MUST" before the RFC 2119 boilerplate.

 "These words take their normative meanings only when they
  are presented in ALL UPPERCASE."

That's somewhat unusual.  Is that from RFC 2119 or the author's choice?*

Modified in new version "draft-hryckelynck-writing-rfcs-03"



*In Section 3.1:

 "In the SMTP RFC [RFC5321], you will find a responsability notion."

Shouldn't this be about design instead of philosophy?
*
As this section is talking about the responsabilty notion described in
RFC5321,
I replaced in new version "draft-hryckelynck-writing-rfcs-03" the term
"Philosophy" by "responsibility notion" in the entire section 3.



*In Section 3.2.1:

 "Because of the huge quantity of unsollicited mail and to avoid giving
  more information to those whore are sending them, section 6.2 of RFC
  5321 [RFC5321] permit in practice silent dropping and more and
  more MTA are configured to drop silently those mails."

"whore" looks like a typo.*

Modified in new version "draft-hryckelynck-writing-rfcs-03"



*I note that Section 6.2 of RFC 5321 also says:

 "However, it is extremely dangerous and violates a long tradition and
  community expectations that mail is either delivered or returned. If
  silent message-dropping is misused, it could easily undermine
  confidence in the reliability of the Internet's mail systems."
*
Section 3.3.1 has been modified in new version
"draft-hryckelynck-writing-rfcs-03" as follows :

   "If section 6.2 of RFC 5321 [RFC5321] permits in practice silent
   dropping, it also pleads to keep the "delivered or returned" way to
   deal with mails.

   In this sense, those past years, efforts has been made to find some
   ways to check the return path as to stay close from the original
   responsability notion (deliver or notify). You of course need a
   return path in case of notify."



*In Section 3.3.1:

 "But at this time the RFC 5321 [RFC5321]in section 3.6.2 doesn't
  RECOMMENDED any method."

I could not find anything in Section 3.6.2 about Return-path.*

In RFC 5321, section 3.6.2 on page 27 :
                              "A server MAY attempt to verify the return
   path before using its address for delivery notifications, but methods
   of doing so are not defined here nor is any particular method
   recommended at this time."


*In Section 6.2.2:

 "For example, if the MTA receive a mail that SHOULD be dropped because
  it comes from an IP which has a bad reputation."

That sentence could be part of the sentence in the previous paragraph.*

Modified in new version "draft-hryckelynck-writing-rfcs-03"


*In Section 7.1.2.2:

 "When a user wants to be reached by a commercial site, he will only
  have to declare the domain.  This will force commercial site to
  specify clearly which domain they use for their sending."

In the above based upon RFC 706?*

I did not remember of this RFC. Thank you for the information.

The only differences I could find between RFC 706 and my draft are :
- a list of sources to refuse against a list of source to accept
- a list of sources kept per host against a list of sources kept for any
host.

But as RFC 706 described these differences only as possibilities and as it
mentions it is an open issue, we could consider my draft is an attempt to
give an answer to the same problematic. I have then referenced RFC 706
directly in section 1 in new version "draft-hryckelynck-writing-rfcs-03" as
follows :

   "With this in mind, it MAY be useful to find a mechanism for users to
   choose themselves who will be able to send them some mails as that
   was suggested in RFC 706 [RFC706]."


*In Section 9.2:

 "It is not garantied, when a mail which has a sender address from a
  domain you previously accepted, that this mail really come from this
  domain.  For this purpose you will need other mechanism that could be
  viewed as complementary like SPF [RFC4408] or DKIM [RFC6376]."

What is your opinion about the IESG note at the beginning of RFC 4408?*

Last sentence has been modified in new version
"draft-hryckelynck-writing-rfcs-03" as follows :

"For this purpose you may need other mechanism that could be viewed as
complementary like Sender ID [RFC4406], SPF [RFC4408] or DKIM [RFC6376]."



As a newcomer I have a question. Do I need your authorization to reference
your name as contributor in my draft ?

Please tell me if there is anything else you would change.

Thank you very much for your time and your help.


Regards,
Hubert


2012/4/22 SM 

> Hello,
>
> [message copied to apps-discuss@ in case other people would like to
> provide feedback about this proposal]
>
> The initial version of draft-hryckelynck-writing-**rfcs-01 was posted on
> April 1.  I wasn't sure whether the date was intentionally chosen.  I note
> that draft-hryckelynck-writing-rfcs is intended to be published as
> Experimental.  Do you have a plan about how long this experiment should be
> run?
>
> In the Abstract Section:
>
>  "Mail Accepted by Previous Sending defines a mechanism by which
>   incoming unsollicited mails MAY be rejected or penalized by a MTA if
>   their sender address domains has never been a destination for the
>   outgoing mails treated by this MTA."
>
> The "MAY" should be written as "may".
>
> In the Introduction Section:
>
>  "Mails with, for example, a pornographic contains are easy to identify
>   as mail we MUST intercept."
>
> Some people enjoy pornographic content.  The above requirement forbids
> that.  Is that intentional?
>
> The RFC 2119 key words in the first section should be removed.
>
> In Section 2, you are using a "MUST" before the RFC 2119 boilerplate.
>
>  "These words take their normative meanings only when they
>   are presented in ALL UPPERCASE."
>
> That's somewhat unusual.  Is that from RFC 2119 or the author's choice?
>
> In Section 3.1:
>
>  "In the SMTP RFC [RFC5321], you will find a responsability notion."
>
> Shouldn't this be about design instead of philosophy?
>
> In Section 3.2.1:
>
>  "Because of the huge quantity of unsollicited mail and to avoid giving
>   more information to those whore are sending them, section 6.2 of RFC
>   5321 [RFC5321] permit in practice silent dropping and more and
>   more MTA are configured to drop silently those mails."
>
> "whore" looks like a typo.
>
> I note that Section 6.2 of RFC 5321 also says:
>
>  "However, it is extremely dangerous and violates a long tradition and
>   community expectations that mail is either delivered or returned. If
>   silent message-dropping is misused, it could easily undermine
>   confidence in the reliability of the Internet's mail systems."
>
> In Section 3.3.1:
>
>  "But at this time the RFC 5321 [RFC5321]in section 3.6.2 doesn't
>   RECOMMENDED any method."
>
> I could not find anything in Section 3.6.2 about Return-path.
>
> In Section 6.2.2:
>
>  "For example, if the MTA receive a mail that SHOULD be dropped because
>   it comes from an IP which has a bad reputation."
>
> That sentence could be part of the sentence in the previous paragraph.
>
> In Section 7.1.2.2:
>
>  "When a user wants to be reached by a commercial site, he will only
>   have to declare the domain.  This will force commercial site to
>   specify clearly which domain they use for their sending."
>
> In the above based upon RFC 706?
>
> In Section 9.2:
>
>  "It is not garantied, when a mail which has a sender address from a
>   domain you previously accepted, that this mail really come from this
>   domain.  For this purpose you will need other mechanism that could be
>   viewed as complementary like SPF [RFC4408] or DKIM [RFC6376]."
>
> What is your opinion about the IESG note at the beginning of RFC 4408?
>
> The "Mail Accepted by Previous Sending" proposal might need some more work
> before it is ready for publication as a RFC.
>
> Regards,
> -sm
>
>

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

Hello,

[message copied to apps-discuss@ in case other people would l=
ike to provide feedback about this proposal]

The initial version =
of draft-hryckelynck-writing-rfcs-01 was posted on April 1.=A0 I wasn't=
 sure whether the date was intentionally chosen.=A0 I note that draft-hryck=
elynck-writing-rfcs is intended to be published as Experimental.=A0 Do you =
have a plan about how long this experiment should be run?


About April 1st, I confirm to you this is not a "funny RFC&quo=
t;.
I do not have a plan yet about how long this experiment should be ru=
n. 
If the community gives sympathetic consideration to this idea maybe =
one day I would intend another status. But at this time the only intended s=
tatus is experimental.




In the Abstract Section:

=A0"Mail Accepted by Pr=
evious Sending defines a mechanism by which
=A0 incoming unsollicited ma=
ils MAY be rejected or penalized by a MTA if
=A0 their sender address do=
mains has never been a destination for the

=A0 outgoing mails treated by this MTA."

The "MAY" sh=
ould be written as "may".

Modified in new version &quo=
t;draft-hryckelynck-writing-rfcs-03"



In the Introduc=
tion Section:


=A0"Mails with, for example, a pornographic contains are easy to i=
dentify
=A0 as mail we MUST intercept."

Some people enjoy po=
rnographic content.=A0 The above requirement forbids that.=A0 Is that inten=
tional?


You are right. In fact I was thinking pornographic content should not b=
e sent to a working environment. But then you could also say that some peop=
le are working in the pornographic business. So I will take another example=
.


Sentence has been modified in new version "draft-hryckelynck-writi=
ng-rfcs-03" as follows :

=A0"Mails with, for example, an a=
ttempted fraud content are easy to identify as mails we MUST intercept.&quo=
t;




The RFC 2119 key words in the first section should be remove=
d.

Modified in new version "draft-hryckelynck-writing-rfcs-=
03"



In Section 2, you are using a "MUST" b=
efore the RFC 2119 boilerplate.


=A0"These words take their normative meanings only when they
=
=A0 are presented in ALL UPPERCASE."

That's somewhat unusua=
l.=A0 Is that from RFC 2119 or the author's choice?

Modified=
 in new version "draft-hryckelynck-writing-rfcs-03"




In Section 3.1:

=A0"In the SMTP RFC [RFC5321], y=
ou will find a responsability notion."

Shouldn't this be ab=
out design instead of philosophy?

As this section is talking abo=
ut the responsabilty notion described in RFC5321, 

I replaced in new version "draft-hryckelynck-writing-rfcs-03" the=
 term "Philosophy" by "responsibility notion" in the en=
tire section 3.



In Section 3.2.1:

=A0"Because=
 of the huge quantity of unsollicited mail and to avoid giving

=A0 more information to those whore are sending them, section 6.2 of RFC=A0 5321 [RFC5321] permit in practice silent dropping and more and
=A0 =
more MTA are configured to drop silently those mails."

"wh=
ore" looks like a typo.


Modified in new version "draft-hryckelynck-writing-rfcs-03"


I note that Section 6.2 of RFC 5321 also says:

=A0&=
quot;However, it is extremely dangerous and violates a long tradition and
=A0 community expectations that mail is either delivered or returned. If=A0 silent message-dropping is misused, it could easily undermine
=A0 c=
onfidence in the reliability of the Internet's mail systems."
<=
/b>

Section 3.3.1 has been modified in new version "draft-hryckelynck-writ=
ing-rfcs-03" as follows :

=A0=A0 "If section 6.2 of RFC 53=
21 [RFC5321] permits in practice silent 
=A0=A0 dropping, it also pleads=
 to keep the "delivered or returned" way to 

=A0=A0 deal with mails.

=A0=A0 In this sense, those past years, effo=
rts has been made to find some 
=A0=A0 ways to check the return path as =
to stay close from the original 
=A0=A0 responsability notion (deliver o=
r notify). You of course need a 

=A0=A0 return path in case of notify."



In Section 3.=
3.1:

=A0"But at this time the RFC 5321 [RFC5321]in section 3.6.=
2 doesn't
=A0 RECOMMENDED any method."

I could not find =
anything in Section 3.6.2 about Return-path.


In RFC 5321, section 3.6.2 on page 27 : 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "A server=
 MAY attempt to verify the return
=A0=A0 path before using its address f=
or delivery notifications, but methods
=A0=A0 of doing so are not define=
d here nor is any particular method

=A0=A0 recommended at this time."


In Section 6.2.2:
<=
br>=A0"For example, if the MTA receive a mail that SHOULD be dropped b=
ecause
=A0 it comes from an IP which has a bad reputation."

=
That sentence could be part of the sentence in the previous paragraph.<=
br>

Modified in new version "draft-hryckelynck-writing-rfcs-03"

In Section 7.1.2.2:

=A0&=
quot;When a user wants to be reached by a commercial site, he will only

=A0 have to declare the domain.=A0 This will force commercial site to
=
=A0 specify clearly which domain they use for their sending."

I=
n the above based upon RFC 706?

I did not remember of this RFC. =
Thank you for the information.


The only differences I could find between RFC 706 and my draft are :- a list of sources to refuse against a list of source to accept
- a li=
st of sources kept per host against a list of sources kept for any host.

But as RFC 706 described these differences only as possibilities and as=
 it mentions it is an open issue, we could consider my draft is an attempt =
to give an answer to the same problematic. I have then referenced RFC 706 d=
irectly in section 1 in new version "draft-hryckelynck-writing-rfcs-03=
" as follows :


=A0=A0 "With this in mind, it MAY be useful to find a mechanism fo=
r users to
=A0=A0 choose themselves who will be able to send them some m=
ails as that 
=A0=A0 was suggested in RFC 706 [RFC706]."

In Section 9.2:


=A0"It is not garantied, when a mail which has a sender address fr=
om a
=A0 domain you previously accepted, that this mail really come from=
 this
=A0 domain.=A0 For this purpose you will need other mechanism that=
 could be

=A0 viewed as complementary like SPF [RFC4408] or DKIM [RFC6376]."
=

What is your opinion about the IESG note at the beginning of RFC 4408?<=
/b>

Last sentence has been modified in new version "draft-hryck=
elynck-writing-rfcs-03" as follows :


"For this purpose you may need other mechanism that could be viewe=
d as complementary like Sender ID [RFC4406], SPF [RFC4408] or DKIM [RFC6376=
]."



As a newcomer I have a question. Do I need your aut=
horization to reference your name as contributor in my draft ?


Please tell me if there is anything else you would change.

Thank=
 you very much for your time and your help.


Regards,
Hubert

2012/4/22 SM <sm@resistor.net>


Hello,



[message copied to apps-discuss@ in case other people would like to provide=
 feedback about this proposal]



The initial version of draft-hryckelynck-writing-rfcs-01 was posted =
on April 1. =A0I wasn't sure whether the date was intentionally chosen.=
 =A0I note that draft-hryckelynck-writing-rfcs is intended to be published =
as Experimental. =A0Do you have a plan about how long this experiment shoul=
d be run?




In the Abstract Section:



 =A0"Mail Accepted by Previous Sending defines a mechanism by which
 =A0 incoming unsollicited mails MAY be rejected or penalized by a MTA if
 =A0 their sender address domains has never been a destination for the

 =A0 outgoing mails treated by this MTA."



The "MAY" should be written as "may".



In the Introduction Section:



 =A0"Mails with, for example, a pornographic contains are easy to iden=
tify

 =A0 as mail we MUST intercept."



Some people enjoy pornographic content. =A0The above requirement forbids th=
at. =A0Is that intentional?



The RFC 2119 key words in the first section should be removed.



In Section 2, you are using a "MUST" before the RFC 2119 boilerpl=
ate.



 =A0"These words take their normative meanings only when they

 =A0 are presented in ALL UPPERCASE."



That's somewhat unusual. =A0Is that from RFC 2119 or the author's c=
hoice?



In Section 3.1:



 =A0"In the SMTP RFC [RFC5321], you will find a responsability notion.=
"



Shouldn't this be about design instead of philosophy?



In Section 3.2.1:



 =A0"Because of the huge quantity of unsollicited mail and to avoid gi=
ving

 =A0 more information to those whore are sending them, section 6.2 of RFC
 =A0 5321 [RFC5321] permit in practice silent dropping and more and

 =A0 more MTA are configured to drop silently those mails."



"whore" looks like a typo.



I note that Section 6.2 of RFC 5321 also says:



 =A0"However, it is extremely dangerous and violates a long tradition =
and

 =A0 community expectations that mail is either delivered or returned. If
 =A0 silent message-dropping is misused, it could easily undermine

 =A0 confidence in the reliability of the Internet's mail systems."=
;



In Section 3.3.1:



 =A0"But at this time the RFC 5321 [RFC5321]in section 3.6.2 doesn'=
;t

 =A0 RECOMMENDED any method."



I could not find anything in Section 3.6.2 about Return-path.



In Section 6.2.2:



 =A0"For example, if the MTA receive a mail that SHOULD be dropped bec=
ause

 =A0 it comes from an IP which has a bad reputation."



That sentence could be part of the sentence in the previous paragraph.



In Section 7.1.2.2:



 =A0"When a user wants to be reached by a commercial site, he will onl=
y

 =A0 have to declare the domain. =A0This will force commercial site to

 =A0 specify clearly which domain they use for their sending."



In the above based upon RFC 706?



In Section 9.2:



 =A0"It is not garantied, when a mail which has a sender address from =
a

 =A0 domain you previously accepted, that this mail really come from this
 =A0 domain. =A0For this purpose you will need other mechanism that could b=
e

 =A0 viewed as complementary like SPF [RFC4408] or DKIM [RFC6376]."


What is your opinion about the IESG note at the beginning of RFC 4408?



The "Mail Accepted by Previous Sending" proposal might need some =
more work before it is ready for publication as a RFC.



Regards,

-sm







--047d7b33d4cccdfc9804bed4410a--

From dhc@dcrocker.net  Sun Apr 29 13:57: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 47EB321F85A8 for ; Sun, 29 Apr 2012 13:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.878
X-Spam-Level: 
X-Spam-Status: No, score=-5.878 tagged_above=-999 required=5 tests=[AWL=0.721,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVIXFDuxWYJd for ; Sun, 29 Apr 2012 13:57:04 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 52FCB21F85A7 for ; Sun, 29 Apr 2012 13:57:04 -0700 (PDT)
Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q3TKv20u025141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 Apr 2012 13:57:02 -0700
Message-ID: <4F9DAB1E.8080800@dcrocker.net>
Date: Sun, 29 Apr 2012 13:57:02 -0700
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
To: Hubert Ryckelynck 
References: <6.2.5.6.2.20120421143240.07253358@elandnews.com>
In-Reply-To: <6.2.5.6.2.20120421143240.07253358@elandnews.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]); Sun, 29 Apr 2012 13:57:03 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Comments on draft-hryckelynck-writing-rfcs-01
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: Sun, 29 Apr 2012 20:57:05 -0000

Basic concern:

This document appears to be unaware of the established practice of 
greylisting, such as the just-approved document.


    http://tools.ietf.org/html/draft-ietf-appsawg-greylisting-09


Minor:

On 4/21/2012 3:26 PM, SM wrote:
> In the Abstract Section:
>
> "Mail Accepted by Previous Sending defines a mechanism by which
> incoming unsollicited mails MAY be rejected or penalized by a MTA if
> their sender address domains has never been a destination for the
> outgoing mails treated by this MTA."
>
> The "MAY" should be written as "may".

Actually, that changes nothing.  Normative vocabulary does not require 
capitalization. If the document uses the normative terms, it needs to 
use non-normative vocabulary for non-normative meaning, per:

    http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119-01.html


> With this in mind, it may be useful to find a mechanism for users to
>    choose themselves who will be able to send them some mails as that
>    was suggested in RFC 706 [RFC706].

A document that was written 35 years ago, before spam had ever happened, 
cannot reflect the last 20 years of operational experience, no matter 
how insightful the author.

It happens that some of that experience shows quite strongly that a 
mechanism like the one proposed here won't work.


> users to
>    choose themselves who will be able to send them some mails

Too much user effort of the wrong kind.

In addition, the proposal does not seem to require any user choice.


d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From sm@resistor.net  Sun Apr 29 14:55: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 125B021F85A4 for ; Sun, 29 Apr 2012 14:55:13 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPrFhArJ5mJK for ; Sun, 29 Apr 2012 14:55:10 -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 DA9CA21F8546 for ; Sun, 29 Apr 2012 14:55:10 -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 q3TLt2R3021607; Sun, 29 Apr 2012 14:55:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335736508; i=@resistor.net; bh=zFt328gSRtUQfTQVfyVgRVj7T7+LNyunSOPzwXmoFCM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RLVi1BG7RqawagM396LCCLWAo5Brg3saVlGc4QF6pQBtQk1ixCwdxc3cIa0zQcN+9 kUmmdS1nytA7t4rOC3xHjodKLfLX65bhr0xEnBZMh9GIpy7qmgYEGniRmQK4mjwwhi L0fiRx/HEvmCHR2rRpF/gk/yZs/7bF/XNXSAalic=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1335736508; i=@resistor.net; bh=zFt328gSRtUQfTQVfyVgRVj7T7+LNyunSOPzwXmoFCM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=I74k6S5sQe1TfpuMyDm1if4GCnNxWC/qSbpsXF1m9TKk0gsgZ894tPDB0GNvqusch OfEh2Ir2FNlN+dnc4CcsKVuJCif0rUSWdmXhlYLKRBbP3tADCQVhWknKEtjwABOe9m yavNz+A7O482kcl/5u9eHAyTZnxGLyRzs5EctF0I=
Message-Id: <6.2.5.6.2.20120429134847.08f02068@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 29 Apr 2012 14:53:11 -0700
To: hub ryck 
From: SM 
In-Reply-To: 
References: <6.2.5.6.2.20120421143240.07253358@elandnews.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Comments on draft-hryckelynck-writing-rfcs-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: Sun, 29 Apr 2012 21:55:13 -0000

Hi Hubert,
At 09:59 29-04-2012, hub ryck wrote:
>About April 1st, I confirm to you this is not a "funny RFC".
>I do not have a plan yet about how long this experiment should be run.
>If the community gives sympathetic consideration to this idea maybe 
>one day I would intend another status. But at this time the only 
>intended status is experimental.

Ok.

>Modified in new version "draft-hryckelynck-writing-rfcs-03"

You might wish to choose a different filename for the draft as the 
"writing-rfcs" does not say much about the subject of the draft.

>You are right. In fact I was thinking pornographic content should 
>not be sent to a working environment. But then you could also say 
>that some people are working in the pornographic business. So I will 
>take another example.

The draft does not mention that it is applicable to a working 
environment only.  As you mentioned above, it can be argued that 
there are work environments where such content may be used.

>  "Mails with, for example, an attempted fraud content are easy to 
> identify as mails we MUST intercept."

Some people may ask how to identify "fraud content".  It's easy to 
say that fraud MUST be intercepted.  If there is no way to identify 
fraud, it cannot be implemented.

>As this section is talking about the responsabilty notion described 
>in RFC5321,
>I replaced in new version "draft-hryckelynck-writing-rfcs-03" the 
>term "Philosophy" by "responsibility notion" in the entire section 3.

Ok, for now.

>In RFC 5321, section 3.6.2 on page 27 :
>                               "A server MAY attempt to verify the return

I missed that.

>I did not remember of this RFC. Thank you for the information.

There are a lot of RFCs.  Some of them contain good ideas, some of 
them contain bad ideas.  It is up to you to assess whether the 
contents of the RFC are appropriate or not.

>The only differences I could find between RFC 706 and my draft are :
>- a list of sources to refuse against a list of source to accept
>- a list of sources kept per host against a list of sources kept for any host.
>
>But as RFC 706 described these differences only as possibilities and 
>as it mentions it is an open issue, we could consider my draft is an 
>attempt to give an answer to the same problematic. I have then 
>referenced RFC 706 directly in section 1 in new version 
>"draft-hryckelynck-writing-rfcs-03" as follows :
>
>    "With this in mind, it MAY be useful to find a mechanism for users to
>    choose themselves who will be able to send them some mails as that
>    was suggested in RFC 706 [RFC706]."

I suggest not using RFC 706 as a reference unless you are sure that 
you can make a case for why it is relevant.

There were and there still are open issues.  It may help to research 
why some of these open issues remain open after over 25 years and see 
whether the answer you provide was not proposed previously before 
being considered as not workable.

>"For this purpose you may need other mechanism that could be viewed 
>as complementary like Sender ID [RFC4406], SPF [RFC4408] or DKIM [RFC6376]."

That doesn't really answer the question I asked. :-)

>As a newcomer I have a question. Do I need your authorization to 
>reference your name as contributor in my draft ?

You do not need my authorization to provide an acknowledgement.  If 
you were to add me as an author, for example, it is better if you 
seek authorization first.  If you are unsure, it is easier to ask.

>Please tell me if there is anything else you would change.

As I mentioned previously, the draft needs more work.  It would help 
if you could get reviews of the draft from other people involved in email.

There is a lot I would change.  For example, this is from the Abstract section:

   "Mail Accepted by Previous Sending defines a mechanism by which
    incoming unsollicited mails may be rejected or penalized by a MTA if
    their sender address domains has never been a destination for the
    outgoing mails treated by this MTA."

The email I sent to you was unsolicited.  Are you sure that the MTA 
for your mailbox has seen emails with my email address as a 
destination?  If the answer is no, my email would be rejected or 
penalized by the MTA at your end.  There is a higher probability that 
you would not be seeing my previous message.  There is a word in my 
previous message which could get it tagged as containing offensive content.

The draft is more about email practices than a protocol.  There is a 
difference between the notion of responsibility for hand-off 
(relaying messages) and the notion from a non-technical 
perspective.  There is a note in the paragraph before Section 1.2 of 
draft-klensin-rfc2821bis-06.  I suggest that you take a look at it.

Regards,
-sm 


From paul.hoffman@vpnc.org  Sun Apr 29 16:28: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 0770B21F85C9; Sun, 29 Apr 2012 16:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.537
X-Spam-Level: 
X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqzHtNUYcPLb; Sun, 29 Apr 2012 16:28:22 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDE421F85B1; Sun, 29 Apr 2012 16:28:22 -0700 (PDT)
Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3TNSIvW080743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 29 Apr 2012 16:28:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman 
In-Reply-To: <201204292309.q3TN9BcF027057@new.toad.com>
Date: Sun, 29 Apr 2012 16:28:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com>
To: John Gilmore 
X-Mailer: Apple Mail (2.1257)
Cc: Paul Wouters , iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Apr 2012 23:28:23 -0000

On Apr 29, 2012, at 4:09 PM, John Gilmore wrote:

>>>> So this will not work for any type of DNS indirection mechanism, =
such as MX, SRV, etc?
>=20
> TLSA is expected to work with TLS-based services reached via MX
> records, as well as with services that use TLS which are reached via
> SRV records.

You may have missed the earlier discussion of this topic, and the fact =
that the topic was closed with a result different than what you say =
here. Please see .

If the WG chairs think that Jakob and I have not reflected the WG =
consensus from that issue in the document, we are happy to update the =
document yet again.

--Paul Hoffman


From gnu@toad.com  Sun Apr 29 16:09: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 C11B321F8496; Sun, 29 Apr 2012 16:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.404
X-Spam-Level: 
X-Spam-Status: No, score=0.404 tagged_above=-999 required=5 tests=[AWL=0.307,  BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaJYJ8KB6kPB; Sun, 29 Apr 2012 16:09:16 -0700 (PDT)
Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id DCDCE21F85DB; Sun, 29 Apr 2012 16:09:15 -0700 (PDT)
Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3TN9BcF027057; Sun, 29 Apr 2012 16:09:11 -0700
Message-Id: <201204292309.q3TN9BcF027057@new.toad.com>
To: Paul Wouters 
In-reply-to:  
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> 
Comments: In-reply-to Paul Wouters  message dated "Sat, 28 Apr 2012 09:57:00 -0400."
Date: Sun, 29 Apr 2012 16:09:11 -0700
From: John Gilmore 
X-Mailman-Approved-At: Sun, 29 Apr 2012 16:58:51 -0700
Cc: dane@ietf.org, Paul Hoffman , "apps-discuss@ietf.org" , iesg@ietf.org
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Apr 2012 23:09:16 -0000

> >> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc?

TLSA is expected to work with TLS-based services reached via MX
records, as well as with services that use TLS which are reached via
SRV records.

There has been a lot of confused and/or confusing discussion that
started from this unclear question.  ("This will not work...?" -- what
is "this"?  And why in specific do you think it will or won't work?)

I suggest that to eliminate the confusion, we start over with a
clearer question.  Give us a concrete example and ask if it will work.
If the draft doesn't already answer the question, we can fix the draft
so it will.

So, for example, to secure STARTTLS in SMTP, you'd use:

toad.com.		MX	150 new.toad.com.
_25._tcp.new.toad.com.	TLSA	...(a key or certificate for new.toad.com)...
new.toad.com.		A	209.237.225.253
new.toad.com.		AAAA	2607:f3a0:17::2

	John

PS: While I think our document should be readable by people without
deep knowledge (and thus I've contributed a bunch of introductory
text), I'm dismayed to see IETF "Director" reviews that betray
ignorance of very basic concepts around the Domain Name System,
such as presentation formats of resource records, or A and AAAA records.

From marka@isc.org  Sun Apr 29 16:58: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 43D9E21F85D7; Sun, 29 Apr 2012 16:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.468
X-Spam-Level: 
X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28nlu-NodNHH; Sun, 29 Apr 2012 16:58:24 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBC721F85D5; Sun, 29 Apr 2012 16:58:24 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id F413E5F9BE5; Sun, 29 Apr 2012 23:58:08 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:b5d8:f629:ce61:7da7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DAB2D216C31; Sun, 29 Apr 2012 23:58:06 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B8FB32036A98; Mon, 30 Apr 2012 09:58:01 +1000 (EST)
To: John Gilmore 
From: Mark Andrews 
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com>
In-reply-to: Your message of "Sun, 29 Apr 2012 16:09:11 MST." <201204292309.q3TN9BcF027057@new.toad.com>
Date: Mon, 30 Apr 2012 09:58:01 +1000
Message-Id: <20120429235801.B8FB32036A98@drugs.dv.isc.org>
X-Mailman-Approved-At: Sun, 29 Apr 2012 16:59:03 -0700
Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Apr 2012 23:58:25 -0000

In message <201204292309.q3TN9BcF027057@new.toad.com>, John Gilmore writes:
> > >> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc?
> 
> TLSA is expected to work with TLS-based services reached via MX
> records, as well as with services that use TLS which are reached via
> SRV records.
> 
> There has been a lot of confused and/or confusing discussion that
> started from this unclear question.  ("This will not work...?" -- what
> is "this"?  And why in specific do you think it will or won't work?)
> 
> I suggest that to eliminate the confusion, we start over with a
> clearer question.  Give us a concrete example and ask if it will work.
> If the draft doesn't already answer the question, we can fix the draft
> so it will.
> 
> So, for example, to secure STARTTLS in SMTP, you'd use:
> 
> toad.com.		MX	150 new.toad.com.
> _25._tcp.new.toad.com.	TLSA	...(a key or certificate for new.toad.com)...
> new.toad.com.		A	209.237.225.253
> new.toad.com.		AAAA	2607:f3a0:17::2
> 
> 	John

Part of the problem is that there is at least two models "STARTTLS
in SMTP" and "HTTPS".  With "STARTTLS in SMTP" the MX record (implicit
or explicit) defines the expected certificate name.  With "HTTPS"
the user input/href defines the expected certificate name even if you
encounter a CNAME record.

Add a CNAME to your example and it become decidedly less clear which
name to expect in the certificate (mail.toad.com or new.toad.com
or either).  i.e. does the CNAME change the expected certificate
name or not?  We have don't have a clear answer to this in the
current RFCs a far as I am aware.

toad.com.		MX	150 mail.toad.com.
mail.toad.com.		CNAME	new.toad.com.
new.toad.com.		A	209.237.225.253
new.toad.com.		AAAA	2607:f3a0:17::2

Which TLSA record does the client MTA lookup?

_25._tcp.mail.toad.com.	TLSA	...(a key or certificate for mail.toad.com)...

or

_25._tcp.new.toad.com.	TLSA	...(a key or certificate for new.toad.com)...

Then there are CNAMEs when looking up the TLSA record itself.

_25._tcp.new.toad.com.  CNAME   cane.toad.com.
cane.toad.com		TLSA	.....

Mark

> PS: While I think our document should be readable by people without
> deep knowledge (and thus I've contributed a bunch of introductory
> text), I'm dismayed to see IETF "Director" reviews that betray
> ignorance of very basic concepts around the Domain Name System,
> such as presentation formats of resource records, or A and AAAA records.
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From paf@frobbit.se  Sun Apr 29 18:16: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 23FFD21F8554; Sun, 29 Apr 2012 18:16:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.264
X-Spam-Level: 
X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.035,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su7eW-2yPnvU; Sun, 29 Apr 2012 18:16:50 -0700 (PDT)
Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 7F40C21F850C; Sun, 29 Apr 2012 18:16:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id D469713ACFFEE; Mon, 30 Apr 2012 03:16:48 +0200 (CEST)
X-Virus-Scanned: amavisd-new at frobbit.se
Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c47jGgzrV2UB; Mon, 30 Apr 2012 03:16:47 +0200 (CEST)
Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 8A95313ACFFE1; Mon, 30 Apr 2012 03:16:47 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
In-Reply-To: <20120429235801.B8FB32036A98@drugs.dv.isc.org>
Date: Mon, 30 Apr 2012 03:16:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org>
To: Mark Andrews 
X-Mailer: Apple Mail (2.1257)
Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , John Gilmore , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 01:16:51 -0000

On 30 apr 2012, at 01:58, Mark Andrews wrote:

> toad.com.		MX	150 mail.toad.com.
> mail.toad.com.		CNAME	new.toad.com.

Mark, I must admit I do not remember what your personal view is on =
MX->CNAME chains, but I am a strong believer in that this is something =
that is not accepted. Yes, I know for example sendmail and possibly =
other implementations do handle MX->CNAME constructions, but =
recommendations are to not construct the namespace like this. MX target =
should be an address record. Just like NS targets.

   Patrik


From sm@elandsys.com  Sun Apr 29 18:38: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 DC05E21F85D7; Sun, 29 Apr 2012 18:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level: 
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zN5K53C714wW; Sun, 29 Apr 2012 18:38:35 -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 CA13721F852E; Sun, 29 Apr 2012 18:38:35 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.232.53]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3U1cLYF026135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Apr 2012 18:38:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335749913; i=@elandsys.com; bh=zgo69XtG4V4R/YzY5Evwa3vP/dQF6X/78lLw7mfFFDc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pPeowLic8MMFEF88s/viD8Sk5m2QtHNc37hKPTnGynYpZmZsfFXoIpaHQRmVra6RK sL+oEU429FgVBowXN4UDUNe5bny6nEoHMtOpCFRzp1U/l8GyfXQtwHwf4JJKnQGoCD U/lTbqLPQw8frdX46/6jSAErmi1DXpMDTsOIekbE=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335749913; i=@elandsys.com; bh=zgo69XtG4V4R/YzY5Evwa3vP/dQF6X/78lLw7mfFFDc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bVHcg6LrYBcHDNTDWTiCVKDLvSCHannH6usUkVuOHWPAzJ/qo0e4UV4CEIgKFTsEO TU5mu22Bbg4KTJpOSYpwSISeeSrQoMqYSGwek0E7LEtSwIrElt7Pc8MVKEJ8cN//vr lIxHkTdbQEqiYVqgoYSmllDs27q79klaHeamHluo=
Message-Id: <6.2.5.6.2.20120429170402.096d3a20@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 29 Apr 2012 18:33:50 -0700
To: apps-discuss@ietf.org
From: S Moonesamy 
In-Reply-To: <201204292309.q3TN9BcF027057@new.toad.com>
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: dane@ietf.org
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 01:38:39 -0000

At 16:09 29-04-2012, John Gilmore wrote:
>text), I'm dismayed to see IETF "Director" reviews that betray
>ignorance of very basic concepts around the Domain Name System,
>such as presentation formats of resource records, or A and AAAA records.

Application Area Directorate reviews are informal; they do not bear 
more weight than a comment submitted by an individual during a Last Call.

The reviewer who commented on draft-ietf-dane-protocol-19 on behalf 
of the Applications Area Directorate must have understood the 
concepts around the Domain Name System as STD 13 is a normative 
reference in the draft.

That does not mean that the reviews should be considered as 
flawless.  The reviews are posted to apps-discuss@ietf.org, which is 
open to everyone, so that anyone can read and discuss about them.

Regards,
S. Moonesamy 


From James.H.Manger@team.telstra.com  Sun Apr 29 19:23: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 0B2B621F85D9 for ; Sun, 29 Apr 2012 19:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.746
X-Spam-Level: 
X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=0.155,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGxVpAczNfuE for ; Sun, 29 Apr 2012 19:23:23 -0700 (PDT)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id A910D21F85D8 for ; Sun, 29 Apr 2012 19:23:21 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,502,1330866000"; d="scan'208";a="73911997"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 30 Apr 2012 12:23:20 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6696"; a="60920156"
Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcavi.tcif.telstra.com.au with ESMTP; 30 Apr 2012 12:23:20 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Mon, 30 Apr 2012 12:23:19 +1000
From: "Manger, James H" 
To: Ari Keranen , Stephen Farrell , Apps Discuss 
Date: Mon, 30 Apr 2012 12:23:15 +1000
Thread-Topic: draft-farrell-decade-ni-04: more glitches in examples
Thread-Index: Ac0meDKnHxV8j6ISQIyJnPOgpNGAJg==
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [apps-discuss] draft-farrell-decade-ni-04: more glitches in examples
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 02:23:24 -0000

Ari and Stephen,

There are new glitches in the examples in "Naming Things with Hashes" .

The 1st examples are wrong:
  "Hello World!" (without the quotes, being 12 characters)
  ni:///sha-256;A7ogTlDRJuRnTABeBNguhMITZngK8fQ71Uo3gWtqs0A

A7og... is the (base64url-encoded) SHA-256 hash of *13* characters that inc=
ludes a newline char at the end.
Base64url(SHA-256("Hello World!\n")) =3D A7ogTlDRJuRnTABeBNguhMITZngK8fQ71U=
o3gWtqs0A
Base64url(SHA-256("Hello World!")) =3D f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3S=
ABJtkGk

The URI should be
ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk


The 2nd examples are wrong:
  Given the SubjectPublicKeyInfo in Figure 5...
  0000000 82 01 0a 02 82 01 01 00 a2 5f 83 da 9b d9 f1 7a
  0000020 3a 36 67 ba fd 5a 94 0e cf 16 d5 5a 55 3a 5e d4

This is not a SubjectPublicKeyInfo value. It is not even "the value of the =
BIT STRING subjectPublicKey (excluding the tag, length, and number of unuse=
d bits)" -- which is commonly the input to a key-id calculation.
Add an initial 0x30 to make the data a subjectPublicKey value (ie a DER-enc=
oded RSAPublicKey); then add the DER-encoding for the rsaEncryption algorit=
hm id and wrappers.

The full data should be:

  000000 : 30 82 01 22 30 0D 06 09  2A 86 48 86 F7 0D 01 01
  000010 : 01 05 00 03 82 01 0F 00  30 82 01 0A 02 82 01 01
  000020 : 00 A2 5F 83 DA 9B D9 F1  7A 3A 36 67 BA FD 5A 94
  000030 : 0E CF 16 D5 5A 55 3A 5E  D4 03 B1 65 8E 6D CF A3
  000040 : B7 DB A4 E7 CC 0F 52 C6  7D 35 1D C4 68 C2 BD 7B
  000050 : 9D DB E4 0A D7 10 CD F9  53 20 EE 0D D7 56 6E 5B
  000060 : 7A AE 2C 5F 83 0A 19 3C  72 58 96 D6 86 E8 0E E6
  000070 : 94 EB 5C F2 90 3E F3 A8  8A 88 56 B6 CD 36 38 76
  000080 : 22 97 B1 6B 3C 9C 07 F3  4F 97 08 A1 BC 29 38 9B
  000090 : 81 06 2B 74 60 38 7A 93  2F 39 BE 12 34 09 6E 0B
  0000A0 : 57 10 B7 A3 7B F2 C6 EE  D6 C1 E5 EC AE C5 9C 83
  0000B0 : 14 F4 6B 58 E2 DE F2 FF  C9 77 07 E3 F3 4C 97 CF
  0000C0 : 1A 28 9E 38 A1 B3 93 41  75 A1 A4 76 3F 4D 78 D7
  0000D0 : 44 D6 1A E3 CE E2 5D C5  78 4C B5 31 22 2E C7 4B
  0000E0 : 8C 6F 56 78 5C A1 C4 C0  1D CA E5 B9 44 D7 E9 90
  0000F0 : 9C BC EE B0 A2 B1 DC DA  6D A0 0F F6 AD 1E 2C 12
  000100 : A2 A7 66 60 3E 36 D4 91  41 C2 F2 E7 69 39 2C 9D
  000110 : D2 DF B5 A3 44 95 48 7C  87 64 89 DD BF 05 01 EE
  000120 : DD 02 03 01 00 01

The SHA-256 hash and all the subsequent URIs need to be changed to reflect =
the corrected input data.

--
James Manger



From gnu@toad.com  Sun Apr 29 20:16: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 D5A2621F84A0; Sun, 29 Apr 2012 20:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.384
X-Spam-Level: 
X-Spam-Status: No, score=0.384 tagged_above=-999 required=5 tests=[AWL=0.287,  BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugckGaNNeJro; Sun, 29 Apr 2012 20:16:16 -0700 (PDT)
Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 01D4921F847C; Sun, 29 Apr 2012 20:16:15 -0700 (PDT)
Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3U3GFcF002018; Sun, 29 Apr 2012 20:16:15 -0700
Message-Id: <201204300316.q3U3GFcF002018@new.toad.com>
To: Paul Hoffman 
In-reply-to:  
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> 
Comments: In-reply-to Paul Hoffman  message dated "Sun, 29 Apr 2012 16:28:18 -0700."
Date: Sun, 29 Apr 2012 20:16:15 -0700
From: John Gilmore 
X-Mailman-Approved-At: Sun, 29 Apr 2012 22:16:22 -0700
Cc: "apps-discuss@ietf.org" , dane@ietf.org, John Gilmore , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 03:16:17 -0000

[Does this discussion really need to be cc'd to apps-discuss and iesg?
 I am keeping the distribution as it was, but I suggest cutting it
 back to just "dane".  --gnu]

> > TLSA is expected to work with TLS-based services reached via MX
> > records, as well as with services that use TLS which are reached via
> > SRV records.
> 
> You may have missed the earlier discussion of this topic, and the fact that the topic was closed with a result different than what you say here. Please see .

I looked at Ticket 28 and it is not clear to me what the resolution is.
Its resolution was:  

  "use the first name that has a TLSA record, unless there is a
  protocol specific exception"

I don't know what that means in the context of MX nor SRV.  Does that
mean that SRV will work, that SRV will fail, or does it mean something
else entirely?  If it means something else entirely, then it does not
contradict my statement that TLSA is expected to work with SRV.

It is not clear to me what is the "first name" in the above statement,
nor what other names are potentially in line behind it.  The phrase
"first name that has a TLSA record" seems to imply iteration through a
series of names until a TLSA record is found.  I could imagine that it
means, in the context of MX for example, if mail is sent to
gnu@example.com and example.com has an MX to mailserver.example.com,
then you would look for TLSA records "first" at example.com and
"second" at mailserver.example.com and "third" at nowhere else (you'd
decide that there are no TLSA records).  But this is not actually
specified anywhere in the ticket.

So I looked in Draft 20, and I don't see anything that says "MX and
SRV WILL NOT work with TLSA".  Nor do I see anything that says "MX and
SRV WILL work with TLSA".  I don't even see a statement that clients
should "use the first name that has a TLSA record" as recorded in
ticket 28.  Section 4, "Use of TLSA Records in TLS" just says to look
in Section 2.1 for the "mandatory matching rules".  But Section 2.1
mentions nothing about matching NAMES; it is all about matching
certificates, hashes, and keys.  Section 3, "Domain Names for TLSA
Certificate Associations", step 3, just says "The domain name is
appended" without saying WHICH domain name is appended.  So the draft
is unclear.

In the absence of any explicit statement, I apply my experience.
First, MX and SRV appear to me to be different issues.  There seems to
be a consensus among recent discussions on the mailing list that MX
should work without trouble.  Numerous people have posted example sets
of DNS records that the posters believe would work, and there were no
counterexamples other than some byplay about CNAMEs.  There is even an
example TLSA record for SMTP email delivery in Draft 20.

There is an issue about what name should be in the TLS server's
end-user certificate when using a service that has DNS records that
provide one or more domain names of servers which handle that service.
In what follows I call the original name the "service name",
e.g. "example.com", and the names of servers who provide that service
the "server names", e.g. mailserver.example.com.  Does the TLS client
demand a certificate that includes the service's name, or the server's
name?  (Or perhaps it accepts either one, or perhaps requires that both
be included in the certificate)?

Every working TLS implmentation has already solved this issue.  It
doesn't relate to TLSA records or the DANE protocol at all.  If the
certificate provided by the server doesn't include the name(s) that
the client is expecting to validate, TLS will not work.

I do not personally know whether MX clients expect to see the
service's domain name in the certificate, or the server's.  But I know
that many mail servers currently use STARTTLS and it is widely
interoperable with many clients, so the answer is easy to come by.

DANE does introduce an additional issue about what name should be
looked up in the DNS when seeking a TLSA record.  Does the client look
for a TLSA record at _port._tcp.service.name or at
_port._tcp.server.name?  Or does it look at both of them, and if so,
in what order?

The draft does not specify this, perhaps as a result of an inability
to decide, which was codified in the inscrutable resolution of Ticket
28.  However, draft 20 does provide an illuminating example in the
last sentence of section 3:

   To request a TLSA resource record for an SMTP server running the
   STARTTLS protocol on port 25 at "mail.example.com",
   "_25._tcp.mail.example.com" is used.

This example does not match what Ticket 28 seems to say, since
it provides no iteration, nor is the name of the SMTP server likely
to come to the implementer's mind as the "first name".

If it turns out that in the absence of specifying this, there is a
diversity of client implementations, then at worst, when using a
protocol that uses SRV, a server administrator could provide TLSA
records at both the service name and the server name.

This reasoning is why I stated that TLSA is expected to work with
services that use MX and SRV records.

I'm happy for someone to clarify why this won't work, or to refute
some other part of my chain of reasoning.

> If the WG chairs think that Jakob and I have not reflected the WG
> consensus from that issue in the document, we are happy to update
> the document yet again.

I am not a chair, but I don't think Draft 20 is clear about this.

I'd alter section 3, step 3, and add a paragraph below it:

   3.   A domain name is appended to the result of step 2 to produce
	a prefixed domain name.

   When a client is making domain name queries in search of TLSA
   records, it should form a name by appending the first domain name
   provided to it, and make its first query.  If it does not find a
   TLSA record there, it should form a name from the server name which
   it is in the process of contacting (for example, the name of one of
   the servers supplied in MX or SRV records), and seek a TLSA record
   from that server name.

This seems to faithfully reproduce the clear-as-mud description in
Ticket #28.  

However, this results in some semantic confusion, because the prefixed
domain name includes a port number for a specific server, yet a suffix
that is not related to that server.  For example, we'd first look up
_25._tcp.example.com while negotiating TLS to deliver mail on port 25
to mailserver.example.com for gnu@example.com.  But there may be some
completely different service running on port 25 of HOST "example.com",
if example.com actually has an IP address.  (This is even more
confusing for SRV records, which can specify arbitrary port numbers,
which might be more likely to be reused for different protocols on
different machines.)

Also, if there were four MX records for a domain, the client should
not look up a TLSA record for the main domain, then look up a TLSA
record for the first MX server, then look up a TLSA record for the
second MX server.  These lookups happen only in a context of trying to
negotiate TLS with a *specific* server.  When trying to negotiate TLS
with the first server, it should not be looking for TLSA records that
relate to the second server; it should restrict itself to only looking
up the particular server's name that it is talking to (and/or the name
of the original main domain).

I would be much happier if someone who actually knew what the alleged
consensus is would write this update.

	John




From tbray@textuality.com  Sun Apr 29 22:16: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 694A221F8613 for ; Sun, 29 Apr 2012 22:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.2
X-Spam-Level: 
X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=-0.223,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKNuAym3V6Ey for ; Sun, 29 Apr 2012 22:16:29 -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 1486021F8617 for ; Sun, 29 Apr 2012 22:16:29 -0700 (PDT)
Received: by obbeh20 with SMTP id eh20so463784obb.31 for ; Sun, 29 Apr 2012 22:16:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding:x-gm-message-state; bh=SFnBzV8d6+1RFXU2M69GarXTlo91aIZUXWnkOT27Mwk=; b=cazQnU/JoJNWYo3DjpCLuwdQOWRc2w+ZtNBYELD7HNYvlmoK/O31n3c7Sn671dCPQJ P/oD8bS10iF/OgaRYJJhri2IeLF/3EXytJS0SG+sMjw1rxgRoz420svWFVVVickPEuWg JgH09mvGESFfrNGAPbeZXL6KcFJGE1sSyTyvff8+hNNfnKid10syi4uxrLeRxetfXnkW XHrhgy7q64xU1+ZAyAqJ1P/EPHk41/+8dYLxIBSb2OmvdrFM1Ed+G1Llutiu6OIqntyH ZLa8SLRZXk3KBVcMKfkVPNJ+kbGcLyyefbk+hchAioNIglVWjhmrG5bpv1gORrDOrHY7 3xlw==
MIME-Version: 1.0
Received: by 10.182.167.68 with SMTP id zm4mr2973844obb.25.1335762988138; Sun, 29 Apr 2012 22:16:28 -0700 (PDT)
Received: by 10.182.85.105 with HTTP; Sun, 29 Apr 2012 22:16:28 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
Date: Sun, 29 Apr 2012 22:16:28 -0700
Message-ID: 
From: Tim Bray 
To: apps-discuss@ietf.org,  draft-ietf-appsawg-about-uri-scheme.all@tools.ietf.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkb36eFl6m+dlC+rBqKRbsA0YDsoxwMnrWq6gqhgxbeE9D+THSIAyLnZgFHA8oWrFf987xN
Cc: The IESG 
Subject: [apps-discuss] APPSDIR review of draft-ietf-appsawg-about-uri-scheme-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, 30 Apr 2012 05:16: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 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-about-uri-scheme-04
Title: The "about" URI Scheme
Reviewer: Tim Bray
Review Date: April 29th

Summary: This feels like it should perhaps be an informational RFC,
since in reality no sane software developer should rely on the
semantics of any particular =93about=94 token.  Also, it claims to
establish a registry which can impose normative requirements on
browser builders; no standards organization has ever succeeded in
doing this, so why should an RFC include such an implausible
construct?  Aside from that, it feels like a useful reference
document.

Major Issues: [list any major issues such as security concerns,
preferably by section number]

Section 2.2.1 says that tokens defined in the registry MUST be handled
like the registry says. This sounds like putting something in the
registry imposes a normative requirement on Web browsers, which
history has shown no standards organization has ever accomplished.  So
I really don=92t see the point.

Minor Issues: [list any minor issues such as text that is unclear or
confusing, preferably by section number]

The terms =93resolution=94 and =93resolve=94 are used incorrectly.  They ar=
e
defined in RFC3986, chapter 5, which describes the process of turning
a relative to an absolute URI reference.  Running through this draft
looking at usages:
2.2, both instances of =93resolves=94 should be =93refers=94
2.2.1 2nd para should say =93"about:blank" MUST refer to a resource
represented in the browser by a blank page=94 - similarly fix the
=93blank=94 token template in 4.2
4.2, 2nd bullet, =93to which they should refer=94

2.3 =93about=94 IRIs are not permitted. Huh? Why not? I assume this is a
reasonable choice, but it would be friendly to say why this is the
case.

Nits:
1. Introduction - spurious comma after "scheme". Also, "which" would
be better than "that"
1. Introduction "and some other applications" and later "commonplace
in modern user applications", and the claim of other applications also
appears in 4.1 under =93Applications/protocols that use the scheme=94. I
know of no applications other than browsers, so a citation would be
helpful to support this claim
2.2 "The resource referenced ... is application-specific" - I get what
you=92re saying, but might it be clearer to say =93not portable between
applications=94?
2.2 "Applications MAY use internal redirects..." This whole sentence
is unnecessary; the term =93internal redirect=94 is undefined, and anyhow
who cares what the browser does internally?
2.2.1, last para: split infinitive, =93to strongly connect=94
3. missing =93the=94 after =93apply to=94
3. spurious =93a=94 before =93sensitive=94

From stpeter@stpeter.im  Sun Apr 29 22: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 46A4021F856A; Sun, 29 Apr 2012 22:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMox+qqvNnuU; Sun, 29 Apr 2012 22:34:08 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7338D21F8562; Sun, 29 Apr 2012 22:34:08 -0700 (PDT)
Received: from [107.16.139.250] (unknown [209.116.57.2]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6109740058; Sun, 29 Apr 2012 23:48:58 -0600 (MDT)
Message-ID: <4F9E244E.9030007@stpeter.im>
Date: Sun, 29 Apr 2012 22:34:06 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Warren Kumari 
References: <4F95CA0B.8050202@stpeter.im> <24B5BD30-385D-4780-AD42-A4D1271DFA83@vpnc.org> <9934BC7B-3193-44D1-870A-69A6F6A1612C@kumari.net>
In-Reply-To: <9934BC7B-3193-44D1-870A-69A6F6A1612C@kumari.net>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: dane@ietf.org, Paul Hoffman , "apps-discuss@ietf.org" , iesg@ietf.org
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 05:34:09 -0000

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

On 4/27/12 12:52 PM, Warren Kumari wrote:
> 
> On Apr 27, 2012, at 2:01 PM, Paul Hoffman wrote:
> 
>> On Apr 23, 2012, at 2:30 PM, Peter Saint-Andre wrote:
>> 
>>> Major Issue:
>>> 
>>> This document does not mention that TLSA records cannot be
>>> used directly in application protocols that depend on SRV (or
>>> NAPTR or similar technologies). Although I realize that the
>>> DANE WG decided, after much discussion, that the interaction
>>> between TLSA records and SRV records is out of scope for this
>>> specification (and I do not mean to reopen that discussion
>>> now), it would be very helpful for this specification to
>>> reflect the results of that discussion. Although I make
>>> specific suggestions regarding text under the Minor Issues
>>> below, in general I think this document needs to be clearer
>>> about the assumptions it has made in this regard; in fact, it
>>> seems to me that an explicit applicability statement is
>>> warranted to avoid confusion of the kind that Dave Cridland
>>> experienced (see his Last Call comments).
>> 
>> Now covered in section 1.3, and includes a note that this
>> document might be updated in the future to cover such things.
>> (Note: it would be grand if an XMPPer would start work on this
>> soon so we still have momentum.)
> 
> Yes -- we decided to take the "instead of boiling the ocean / being
> all things to all people"  approach with the initial doc to instead
> publish this and then have "How to do DANE with protocol foo"
> documents... This does mean that we want  need these docs. They
> should be fairly simple to write -- submissions gratefully accepted
> :-)

Yes, Matt Miller and I plan to work on that one soonish.

Peter

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


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

iEYEARECAAYFAk+eJE4ACgkQNL8k5A2w/vwsfwCgzyk68CMXNjIn5arQvx8eon1+
rhcAnjsgaTZMzGW0zxejGjocHVug3Gkt
=Upye
-----END PGP SIGNATURE-----

From stpeter@stpeter.im  Sun Apr 29 22:42: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 ADEDE21F85D4; Sun, 29 Apr 2012 22:42:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxazDOoYum46; Sun, 29 Apr 2012 22:42:50 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C186A21F85C2; Sun, 29 Apr 2012 22:42:50 -0700 (PDT)
Received: from [107.16.139.250] (unknown [209.116.57.2]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7221340058; Sun, 29 Apr 2012 23:57:36 -0600 (MDT)
Message-ID: <4F9E2652.2050804@stpeter.im>
Date: Sun, 29 Apr 2012 22:42:42 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Paul Hoffman 
References: <4F95CA0B.8050202@stpeter.im> <24B5BD30-385D-4780-AD42-A4D1271DFA83@vpnc.org>
In-Reply-To: <24B5BD30-385D-4780-AD42-A4D1271DFA83@vpnc.org>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 05:42:51 -0000

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

On 4/27/12 11:01 AM, Paul Hoffman wrote:
> On Apr 23, 2012, at 2:30 PM, Peter Saint-Andre wrote:
> 
>> Major Issue:
>> 
>> This document does not mention that TLSA records cannot be used 
>> directly in application protocols that depend on SRV (or NAPTR or
>>  similar technologies). Although I realize that the DANE WG 
>> decided, after much discussion, that the interaction between
>> TLSA records and SRV records is out of scope for this
>> specification (and I do not mean to reopen that discussion now),
>> it would be very helpful for this specification to reflect the
>> results of that discussion. Although I make specific suggestions
>> regarding text under the Minor Issues below, in general I think
>> this document needs to be clearer about the assumptions it has
>> made in this regard; in fact, it seems to me that an explicit
>> applicability statement is warranted to avoid confusion of the
>> kind that Dave Cridland experienced (see his Last Call
>> comments).
> 
> Now covered in section 1.3, and includes a note that this document 
> might be updated in the future to cover such things.

Thanks.

> (Note: it would be grand if an XMPPer would start work on this soon
> so we still have momentum.)

Yep, it's on my list. :)

>> 5. To those of us accustomed to SRV records, at first glance the
>>  prefixed DNS domain name format defined in Section 3 looks 
>> strange: why not _http._tcp.www.example.com instead of 
>> _443._tcp.www.example.com? But when we take off our SRV-colored 
>> glasses and realize that DANE assumes a DNS A/AAAA lookup on the
>>  domain name, it all makes sense. Perhaps it would be helpful to
>>  mention the reasoning behind the port number (instead of 
>> application name) here?
> 
> I would rather not try to summarize the debate in the spec, given 
> that the result (numbers) are completely clear.
> 
>> 6. In section 4, no mention is made of the application service 
>> that the TLS expects to encounter at the TLS server:
>> 
>> The TLS session that is to be set up MUST be for the specific
>> port number and transport name that was given in the TLSA query.
>> 
>> Yet surely the application protocol can matter here, no?
> 
> No.
> 
>> In particular, given that 443 is the one true port, we know that 
>> folks might run non-HTTP applications over that port (for evil 
>> reasons, of course).
> 
> Sure. But...
> 
>> Does DANE elide over the application protocol because we simply 
>> assume that the "right" service is being served over any
>> particular port?
> 
> Yes, that's the only sane way to do things currently. (The TLS WG
> is discussing adopting a protocol that would complicate this, but
> that's a long way off, I suspect.)
> 
>> What about service providers that wish to restrict the usage of
>> a certificate to a particular application service type (cf. RFC 
>> 6125)?
> 
> I'm not sure how this is relevant. There is only one application 
> protocol that can be running on 443 after TLS is established.
> 
>> Or do we assume that it is enough to differentiate among 
>> application services based on the underlying transport (as seems
>> to be the case in the text on "Multiple Ports" in Section 5)?
> 
> Yes.
> 
>> IMHO we have a bit of a muddle here.
> 
> I don't see it.

OK, your reasoning makes sense to me -- at least your reasoning for
not including more text in the document at this time.

>> 7. The paragraph about SSL proxies in Section 8 says that "the
>> TLS client will get a certificate association from the DNS that
>> will not match the certificate that the SSL proxy uses with the 
>> client"; however, if the SSL proxy is working in concert with an 
>> external DNS validator, is it possible to mimic the behavior of 
>> current SSL proxies?
> 
> Maybe, but they are undefined.

Right, and it's not the job of this document to define them.

One more issue is nagging at me: there is no definition or citation
for "domain name" in Section 3. In particular, there is no indication
of whether internationalized domain names are allowed (and, if so, in
what format). I think it would good to make this clear by saying that
a domain name can be either a "traditional domain name" (RFC 1034) or
an "internationalized domain name" (RFC 5890); for the latter I think
it would be best to say that the IDN's internationalized labels are
represented only as A-labels. IMHO a short paragraph on this matter
would be appropriate in Section 3 or in a new section entitled
"Internationalization Considerations".

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+eJlIACgkQNL8k5A2w/vyyegCfbbR/3uhm7/N8ipyZKHejRMk5
aa8An09szH1LJO1WyJZVlHCTfnbt8ObN
=7Mx5
-----END PGP SIGNATURE-----

From ned.freed@mrochek.com  Sun Apr 29 22:59: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 B63FD21F84E7; Sun, 29 Apr 2012 22:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Level: 
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5pDhHS21UGN; Sun, 29 Apr 2012 22:59:36 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B0F8321F8534; Sun, 29 Apr 2012 22:59:34 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEWP14NLOW000T1E@mauve.mrochek.com>; Sun, 29 Apr 2012 22:59:24 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Sun, 29 Apr 2012 22:59:19 -0700 (PDT)
Message-id: <01OEWP11R5NK0006TF@mauve.mrochek.com>
Date: Sun, 29 Apr 2012 22:42:47 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 30 Apr 2012 09:58:01 +1000" <20120429235801.B8FB32036A98@drugs.dv.isc.org>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org>
To: Mark Andrews 
Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , John Gilmore , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of	draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 05:59:37 -0000

> In message <201204292309.q3TN9BcF027057@new.toad.com>, John Gilmore writes:
> > > >> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc?
> >
> > TLSA is expected to work with TLS-based services reached via MX
> > records, as well as with services that use TLS which are reached via
> > SRV records.
> >
> > There has been a lot of confused and/or confusing discussion that
> > started from this unclear question.  ("This will not work...?" -- what
> > is "this"?  And why in specific do you think it will or won't work?)
> >
> > I suggest that to eliminate the confusion, we start over with a
> > clearer question.  Give us a concrete example and ask if it will work.
> > If the draft doesn't already answer the question, we can fix the draft
> > so it will.
> >
> > So, for example, to secure STARTTLS in SMTP, you'd use:
> >
> > toad.com.		MX	150 new.toad.com.
> > _25._tcp.new.toad.com.	TLSA	...(a key or certificate for new.toad.com)...
> > new.toad.com.		A	209.237.225.253
> > new.toad.com.		AAAA	2607:f3a0:17::2
> >
> > 	John

> Part of the problem is that there is at least two models "STARTTLS
> in SMTP" and "HTTPS".  With "STARTTLS in SMTP" the MX record (implicit
> or explicit) defines the expected certificate name.  With "HTTPS"
> the user input/href defines the expected certificate name even if you
> encounter a CNAME record.

> Add a CNAME to your example and it become decidedly less clear which
> name to expect in the certificate (mail.toad.com or new.toad.com
> or either).  i.e. does the CNAME change the expected certificate
> name or not?  We have don't have a clear answer to this in the
> current RFCs a far as I am aware.

> toad.com.		MX	150 mail.toad.com.
> mail.toad.com.		CNAME	new.toad.com.
> new.toad.com.		A	209.237.225.253
> new.toad.com.		AAAA	2607:f3a0:17::2

> Which TLSA record does the client MTA lookup?

I'm taking no position on TLSA here, but FWIW, it actually isn't clear what
host the client should connect to in this case, or that this is not in fact a
DNS configuration error.

RFC 974 recommended that CNAMEs not be allowed as MX targets. (See the section
on "Minor Special Issues" for details.) I believe RFC 2821 was silent on the
issue, but the current specification, RFC 5321, has this to say:

   When a domain name associated with an MX RR is looked up and the
   associated data field obtained, the data field of that response MUST
   contain a domain name.  That domain name, when queried, MUST return
   at least one address record (e.g., A or AAAA RR) that gives the IP
   address of the SMTP server to which the message should be directed.
   Any other response, specifically including a value that will return a
   CNAME record when queried, lies outside the scope of this Standard.
   The prohibition on labels in the data that resolve to CNAMEs is
   discussed in more detail in RFC 2181, Section 10.3 [38].

My understanding of the reasoning behind this is that we would prefer to ban
CNAMEs in the context for the reasons given in RFC 2181, but since a lot of
software uses A/AAAA record resolvers that support aliasing that cannot be
disabled, this is where things ended up.

Also FWIW, what existing software that suports STARTTLS seems do is  check the
domain in the certificate against the host name in the MX record that was
used to connect to the current host. At least that's been my experience.

				Ned

From sm@resistor.net  Mon Apr 30 01:31: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 64EC621F85FF; Mon, 30 Apr 2012 01:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Level: 
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41kCQ6Qez58g; Mon, 30 Apr 2012 01:31:38 -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 80C0421F85FC; Mon, 30 Apr 2012 01:31:38 -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 q3U8VUJx004957; Mon, 30 Apr 2012 01:31:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335774697; i=@resistor.net; bh=MocHO4x/Y4rKq/WuI2W2voROHgFbfzjiscGyuI2ghqA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oHaTZfq1ovJfZnK0UvP76Ov4cym9BHffhDMgU8nkabBfL8cuHlxdaSrnBsy5+E6bp 9j9760JAwpwfrqfO+jpm2t+qtVKhFyVipR/cAeNmN7deed2xvJwT0qfhoZF5HFR2pp 3Ida45IgAq4flGmP2EH3sxAvWYk4m3lf4USeAfa8=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1335774697; i=@resistor.net; bh=MocHO4x/Y4rKq/WuI2W2voROHgFbfzjiscGyuI2ghqA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DlcTxdZ9Rcs4yoyPnFRUYy9aWBL11uZoXEyYePOPT89f3XKsUj0gG8LNFYtfI5SqU kO3e5kKktwYVE5Zw3q0H+1W2BAfY2RfuzAFSG6KCzNGdFQGQdmSmQqtZ08PMa+Mct/ wNtf9BI4/laJJd/0wwwLK8lJQSg6LatU+0QKgupw=
Message-Id: <6.2.5.6.2.20120429224742.08c3b1f0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 30 Apr 2012 01:23:25 -0700
To: Mark Andrews 
From: SM 
In-Reply-To: <20120429235801.B8FB32036A98@drugs.dv.isc.org>
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: iesg@ietf.org, apps-discuss@ietf.org, dane@ietf.org
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 08:31:39 -0000

At 16:58 29-04-2012, Mark Andrews wrote:
>Part of the problem is that there is at least two models "STARTTLS

Yes.

>Add a CNAME to your example and it become decidedly less clear which
>name to expect in the certificate (mail.toad.com or new.toad.com
>or either).  i.e. does the CNAME change the expected certificate
>name or not?  We have don't have a clear answer to this in the
>current RFCs a far as I am aware.

Section 5.1 of RFC 5321 mentions that MX RRs with a CNAME in the 
R.H.S is out of scope.

It seems that the main question here is about DNS indirection.  Paul 
Hoffman clarified that ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05419.html ).

Section 2 of -20 mentions that:

   'The TLSA DNS resource record (RR) is used to associate a TLS server
    certificate or public key with the domain name where the record is
    found, thus forming a "TLS certificate association".'

Section 3 mentions that:

   'Unless there is a protocol-specific specification that is different
    than this one, TLSA resource records are stored at a prefixed DNS
    domain name.'

Given that HTTPS and STARTTLS is mentioned in the document by 
example, it looks like the specification should be applicable as-is 
for these protocols.  Using www.apple.com as an example for HTTPS:

;; QUESTION SECTION:
;www.apple.com.                 IN      A

;; ANSWER SECTION:
www.apple.com.          1800    IN      CNAME   www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 60 IN     CNAME   www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 18278 IN     CNAME   e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 20      IN      A       184.30.253.15

I assume that the TLS-based service is at e3191.c.akamaiedge.net.  As 
there is a CN-ID (the back-compatibility clause in RFC 6125) of 
www.apple.com, it should be possible to derive a certification association.

Using universalmusic.com and microsoft.com as examples for STARTTLS:

;; QUESTION SECTION:
;universalmusic.com.            IN      MX

;; ANSWER SECTION:
universalmusic.com.     3600    IN      MX      10 mail.global.frontbridge.com.

;; QUESTION SECTION:
;microsoft.com.                 IN      MX

;; ANSWER SECTION:
microsoft.com.          3600    IN      MX      10 
mail.messaging.microsoft.com.

It is not possible to come up with a certificate association in the 
second case.  My reading of prepared DNS domain name in Section 3 of 
draft-ietf-dane-protocol-20 is that it is akin to derived domains in 
RFC 6125.  I encourage the authors of that RFC to correct me as I 
might be doing an egregious extrapolation of the intent of the text.

There is a note in Section 1.3 of the draft as follows:

   "Note that this document does not cover how to associate certificates
    with domain names for application protocols that depend on SRV, NAPTR,
    and similar DNS resource records; it is expected that later updates
    to this document might cover methods for making those associations."

I don't see much difference between SRV and MX in terms of locating a 
service through DNS.

In Section 8:

   "A DNS administrator who goes rogue and changes both the A, AAAA,
    and/or TLSA records for a domain name can cause the user to go to an
    unauthorized server that will appear authorized, unless the client
    performs PKIX certification path validation and rejects the
    certificate."

Does the above also cover a change in CNAME?

BTW, there are a few typos (certifcate).

Regards,
-sm 


From cloos@jhcloos.com  Mon Apr 30 01:50: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 3AFFF21F8582; Mon, 30 Apr 2012 01:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.915
X-Spam-Level: 
X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.685,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TztYYZcSHTFN; Mon, 30 Apr 2012 01:50:20 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id E575221F85CF; Mon, 30 Apr 2012 01:50:18 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 042E34017D; Mon, 30 Apr 2012 08:49:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1335775817; bh=N3tlGOuCkENQlFc/ShmDXF4+jrmYKypcXMuhN2L2WBc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=VsOXTpSUNJOh8ZUleAPyu1ivXPcxRU1PGUe5F4GBLt9a4zsn59AvbsiCyc0sSY1Um Y7lIAJ6eZZtfRF97fHH34dI1uy2B7OnbEK++2vcll8V5PuMkZMRAlRPbIf4I/ZfbMP 8n/PMZjuzj71t6IX2EsLz24J3FQngbL0oDZTG5oU=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id C0EE136004C; Mon, 30 Apr 2012 08:40:33 +0000 (UTC)
From: James Cloos 
To: dane@ietf.org
In-Reply-To: <201204300316.q3U3GFcF002018@new.toad.com> (John Gilmore's message of "Sun, 29 Apr 2012 20:16:15 -0700")
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com>  <201204300316.q3U3GFcF002018@new.toad.com>
User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2012 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Mon, 30 Apr 2012 04:40:33 -0400
Message-ID: 
Lines: 24
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Cc: "apps-discuss@ietf.org" , John Gilmore , Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 08:50:22 -0000

John's post exactly illustrates why I've been advocating always doing
TLSA lookups for the port and name for which the client is making an
A/AAAA or PTR lookup¹.  Ie, from the results of the NAPTR, SRV and/or MX.

Except only for cases which /explicitly/ specify different behaviour. :)

RFC 3923 says that XMPP -- the oft-cited counter example -- requires
certs to have subjectAltName values which look like email addresses,
rather than like host names.  XMPP, therefore, isn't actually relevant
to draft-ietf-dane-protocol, but rather to the forthcoming draft about
public key data for TLS client certs.

The exceptions should be few and far-between.  And they should require
their own rfc referencing and modifying TLSA for their own needs.

1]  If an address rather than a name is supplied, one must choose between
    doing a PTR to get a name and a TLSA on that name to get the cert
    info, or doing a TLSA on the address.  Either way, one shoudl expect
    the cert to have a CN and/or subjectAltName which matches the name
    returned by the PTR lookup.

-JimC
-- 
James Cloos          OpenPGP: 1024D/ED7DAEA6

From fanf2@hermes.cam.ac.uk  Mon Apr 30 03:44: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 AC2C821F85B5; Mon, 30 Apr 2012 03:44:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.433
X-Spam-Level: 
X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2f1Wh6R52LJ; Mon, 30 Apr 2012 03:44:15 -0700 (PDT)
Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8A59F21F85AF; Mon, 30 Apr 2012 03:44:15 -0700 (PDT)
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-2.csi.cam.ac.uk ([131.111.8.54]:38316) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SOo5T-0003sA-EA (Exim 4.72) (return-path ); Mon, 30 Apr 2012 11:44:11 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SOo5T-0008Qp-An (Exim 4.67) (return-path ); Mon, 30 Apr 2012 11:44:11 +0100
Date: Mon, 30 Apr 2012 11:44:11 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: John Gilmore 
In-Reply-To: <201204300316.q3U3GFcF002018@new.toad.com>
Message-ID: 
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com>  <201204300316.q3U3GFcF002018@new.toad.com>
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: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 10:44:16 -0000

John Gilmore  wrote:
>
> I do not personally know whether MX clients expect to see the
> service's domain name in the certificate, or the server's.  But I know
> that many mail servers currently use STARTTLS and it is widely
> interoperable with many clients, so the answer is easy to come by.

There is currently no certificate verification on inter-domain SMTP.
Most MXs present unverifiable certificates.

http://www.imc.org/ietf-smtp/mail-archive/msg05366.html

In order to add authenticated TLS to SMTP we need some extra signalling so
that an MX can say, "not only am I offering STARTTLS, but also I promise
to present a valid certificate!"

> DANE does introduce an additional issue about what name should be
> looked up in the DNS when seeking a TLSA record.  Does the client look
> for a TLSA record at _port._tcp.service.name or at
> _port._tcp.server.name?

I believe the consensus (at least for SMTP) is for the latter. Otherwise
it becomes really hard to support virtual domains, expecially since a
single transaction can transfer a message to recipients at
multiple domains.

More generally, RFC 6125 describes the framework for what identity should
be authenticated by a certificate.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Hebrides, Bailey, Fair Isle, Faeroes: Northeast 5 or 6, becoming variable 4.
Moderate. Occasional rain then fair. Moderate or good.

From stephen.farrell@cs.tcd.ie  Mon Apr 30 05:08: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 21D8B21F8631 for ; Mon, 30 Apr 2012 05:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5scHGlvvcvVy for ; Mon, 30 Apr 2012 05:08:07 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 268EB21F8628 for ; Mon, 30 Apr 2012 05:08:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 9F7301714F3; Mon, 30 Apr 2012 13:08:04 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335787684; bh=7SHeoenFWhEQ9k swqeRpbbGty1FlFyYWEZzHw2p/B2w=; b=M1cq2rBnz3VzSBoLMsNVdq3oHm2Fp3 Z8AUl0poCVgulyEMN/OwVV1Q4+WtH2xWyp4e98QfKILlT3uvI+7pwggUB8YQE9W+ 4YrB0wlugSxZVJgngpX19mT7BYnmj0/pft6qwCwWqOuNFqcP/patI602KQzfL+Zp 6fHP1woeNa2Vo4Ul2Zig9edA5Lpf0kn9TJmZUC6xVeytd969fhFF+0l7lFqZUF0t hdKw+5q2CEQCqHq9gzQgXvfrgtCuVKfktwunDv+EtIMftU7I6+gx3Sfpq/2GVpGJ CFa0C/iVn6LzeGnCG8xfZze/DYtI5K/eD83ZW1hTs+J2Qs4uf+u/zuUg==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id oW+ODrALep65; Mon, 30 Apr 2012 13:08:04 +0100 (IST)
Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id AF9971714F1; Mon, 30 Apr 2012 13:06:45 +0100 (IST)
Message-ID: <4F9E8055.1080209@cs.tcd.ie>
Date: Mon, 30 Apr 2012 13:06:45 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: "Manger, James H" 
References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] draft-farrell-decade-ni-04: more glitches in examples
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 12:08:08 -0000

Thanks James,

Shooting out a -05 shortly to fix that and other comments
from Barry/Alexey.

Cheers,
S.

On 04/30/2012 03:23 AM, Manger, James H wrote:
> Ari and Stephen,
> 
> There are new glitches in the examples in "Naming Things with Hashes" .
> 
> The 1st examples are wrong:
>   "Hello World!" (without the quotes, being 12 characters)
>   ni:///sha-256;A7ogTlDRJuRnTABeBNguhMITZngK8fQ71Uo3gWtqs0A
> 
> A7og... is the (base64url-encoded) SHA-256 hash of *13* characters that includes a newline char at the end.
> Base64url(SHA-256("Hello World!\n")) = A7ogTlDRJuRnTABeBNguhMITZngK8fQ71Uo3gWtqs0A
> Base64url(SHA-256("Hello World!")) = f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
> 
> The URI should be
> ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
> 
> 
> The 2nd examples are wrong:
>   Given the SubjectPublicKeyInfo in Figure 5...
>   0000000 82 01 0a 02 82 01 01 00 a2 5f 83 da 9b d9 f1 7a
>   0000020 3a 36 67 ba fd 5a 94 0e cf 16 d5 5a 55 3a 5e d4
> 
> This is not a SubjectPublicKeyInfo value. It is not even "the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits)" -- which is commonly the input to a key-id calculation.
> Add an initial 0x30 to make the data a subjectPublicKey value (ie a DER-encoded RSAPublicKey); then add the DER-encoding for the rsaEncryption algorithm id and wrappers.
> 
> The full data should be:
> 
>   000000 : 30 82 01 22 30 0D 06 09  2A 86 48 86 F7 0D 01 01
>   000010 : 01 05 00 03 82 01 0F 00  30 82 01 0A 02 82 01 01
>   000020 : 00 A2 5F 83 DA 9B D9 F1  7A 3A 36 67 BA FD 5A 94
>   000030 : 0E CF 16 D5 5A 55 3A 5E  D4 03 B1 65 8E 6D CF A3
>   000040 : B7 DB A4 E7 CC 0F 52 C6  7D 35 1D C4 68 C2 BD 7B
>   000050 : 9D DB E4 0A D7 10 CD F9  53 20 EE 0D D7 56 6E 5B
>   000060 : 7A AE 2C 5F 83 0A 19 3C  72 58 96 D6 86 E8 0E E6
>   000070 : 94 EB 5C F2 90 3E F3 A8  8A 88 56 B6 CD 36 38 76
>   000080 : 22 97 B1 6B 3C 9C 07 F3  4F 97 08 A1 BC 29 38 9B
>   000090 : 81 06 2B 74 60 38 7A 93  2F 39 BE 12 34 09 6E 0B
>   0000A0 : 57 10 B7 A3 7B F2 C6 EE  D6 C1 E5 EC AE C5 9C 83
>   0000B0 : 14 F4 6B 58 E2 DE F2 FF  C9 77 07 E3 F3 4C 97 CF
>   0000C0 : 1A 28 9E 38 A1 B3 93 41  75 A1 A4 76 3F 4D 78 D7
>   0000D0 : 44 D6 1A E3 CE E2 5D C5  78 4C B5 31 22 2E C7 4B
>   0000E0 : 8C 6F 56 78 5C A1 C4 C0  1D CA E5 B9 44 D7 E9 90
>   0000F0 : 9C BC EE B0 A2 B1 DC DA  6D A0 0F F6 AD 1E 2C 12
>   000100 : A2 A7 66 60 3E 36 D4 91  41 C2 F2 E7 69 39 2C 9D
>   000110 : D2 DF B5 A3 44 95 48 7C  87 64 89 DD BF 05 01 EE
>   000120 : DD 02 03 01 00 01
> 
> The SHA-256 hash and all the subsequent URIs need to be changed to reflect the corrected input data.
> 
> --
> James Manger
> 
> 
> 
> 

From barryleiba@gmail.com  Mon Apr 30 05:45: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 73EF021F860E; Mon, 30 Apr 2012 05:45:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.964
X-Spam-Level: 
X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhf4jMUe4pJR; Mon, 30 Apr 2012 05:45: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 B11D621F85B5; Mon, 30 Apr 2012 05:45:32 -0700 (PDT)
Received: by obbeh20 with SMTP id eh20so943316obb.31 for ; Mon, 30 Apr 2012 05:45:32 -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=PrkksiaS91/T8lJYEvTOp3NwhPSxG82xZo3UIS07MVQ=; b=mtIPDJIyKwN/vH+8c23ot9QrK7vdaoTpETandR14nkxpgFcEfcfy2L5WODfEa8Nvdn 83XguBZYkTzxiCLUk+N0JUD2fs/aZwUzN6YODGDORtPVXhA2c5DmEEPniDknnRq/AMff FGtT5033pDIMCve27flLIYrHqQBevGq2aIkJGmBbt5ejsGwnpIOQq088E8AHCF0NFHL0 zLpH9vqG5hrgmFQhbi1FxCM9ASzWcT/ztIsCF0CLmF9OqNsXKtWDAFWxpgHzlU0pbKET aEVvMNdy1U48iA4lLfQRyfv4VBqFGy7pA4gafndwBpfsvkeyf5iHhtmbCV6UxtruBOVN ZHSw==
MIME-Version: 1.0
Received: by 10.182.12.6 with SMTP id u6mr21434590obb.12.1335789932209; Mon, 30 Apr 2012 05:45:32 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.60.10.68 with HTTP; Mon, 30 Apr 2012 05:45:32 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 30 Apr 2012 08:45:32 -0400
X-Google-Sender-Auth: mVMzkPCrsN66MQlwO9TXjoVAlPo
Message-ID: 
From: Barry Leiba 
To: Tim Bray 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: draft-ietf-appsawg-about-uri-scheme.all@tools.ietf.org, apps-discuss@ietf.org, The IESG 
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appsawg-about-uri-scheme-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, 30 Apr 2012 12:45:33 -0000

Just responding to a few of these:

> Summary: This feels like it should perhaps be an informational RFC,

Yes, that seems to be the consensus in last-call review.  The IESG
will decide the ultimate target status, and see the comment about this
in the shepherd writeup.

> Section 2.2.1 says that tokens defined in the registry MUST be handled
> like the registry says.

I agree that we should remove 2119 language from this document,
regardless of what status it winds up with.

> 1. Introduction - spurious comma after "scheme". Also, "which" would
> be better than "that"

No, you can't have it both ways.  Either we remove the comma and make
the "that..." part restrictive, OR we change "that" to "which", making
the "which..." part non-restrictive.  The intent here is the latter,
so the comma should stay there, and "that" should become "which".

> 2.2 "Applications MAY use internal redirects..." This whole sentence
> is unnecessary; the term =93internal redirect=94 is undefined, and anyhow
> who cares what the browser does internally?

This struck me as well in my AD review, but I decided to leave it to
the editor.  Now that there's another opinion too, I think the
sentence should come out.

> 2.2.1, last para: split infinitive, =93to strongly connect=94

Oy.  This is not a rule in English; it's fine as it is.

Barry

From mrex@sap.com  Mon Apr 30 06: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 2F48521F8639; Mon, 30 Apr 2012 06:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.119
X-Spam-Level: 
X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzd5hM6kDGea; Mon, 30 Apr 2012 06:53:40 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3E87E21F8638; Mon, 30 Apr 2012 06:53:39 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3UDrc55017981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Apr 2012 15:53:38 +0200 (MEST)
From: Martin Rex 
Message-Id: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp>
To: gnu@toad.com (John Gilmore)
Date: Mon, 30 Apr 2012 15:53:37 +0200 (MEST)
In-Reply-To: <201204292309.q3TN9BcF027057@new.toad.com> from "John Gilmore" at Apr 29, 12 04:09:11 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Apr 2012 13:53:41 -0000

John Gilmore wrote:
> 
> >> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc?

In many protocols, those indirections create a security problem.
So each and every such protocol should be forced to resolve that
security problem itself.


> 
> So, for example, to secure STARTTLS in SMTP, you'd use:
> 
> toad.com.		MX	150 new.toad.com.
> _25._tcp.new.toad.com.	TLSA	...(a key or certificate for new.toad.com)...
> new.toad.com.		A	209.237.225.253
> new.toad.com.		AAAA	2607:f3a0:17::2


When trying to deliver mail to @toad.com, the only secure
question to ask is whether the server is authorized to process
Email for @toad.com.  For certificates issued from the traditional
PKIX world, that would require a "toad.com" DNSName SAN.

The only reasonable TLSA lookup would be

_25._tcp.toad.com    TLSA   ....

and DANE only checks the DNSSEC properties of that TLSA lookup.


The security properties of any MX, CNAME, A or AAAA lookups during
connection establishment with that server are irrelevant for DANE
(and invisible to PKIX).


-Martin

From Claudio.Allocchio@garr.it  Mon Apr 30 07:17: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 E4AE321F864A; Mon, 30 Apr 2012 07:17:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l62eQRJIehyY; Mon, 30 Apr 2012 07:17:38 -0700 (PDT)
Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id B257F21F863F; Mon, 30 Apr 2012 07:17:37 -0700 (PDT)
Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q3UEHXiM036854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2012 16:17:33 +0200 (CEST)
X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q3UEHXiM036854
DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=m8k1bxR8dcKXrrByAg815bEY3CM+WnFlxo9iJIVhbNZyXVeYvvk5Mt78InDq/VVV3 xcFi7qF5/Ih4yis4g+wde+KTqW/5o/v/PlEJsjjyZPw6VmwcRMXNkACYtHrOeiHeObo Sd3Z9FO8eHcbW5IZa30B+Gp7qXxH9Jb6c6K7qnk=
Date: Mon, 30 Apr 2012 16:17:32 +0200 (CEST)
From: Claudio Allocchio 
X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it
To: apps-discuss@ietf.org, draft-ietf-eai-simpledowngrade.all@tools.ietf.org
Message-ID: 
User-Agent: Alpine 2.02 (OSX 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: iesg@ietf.org
Subject: [apps-discuss] AppsDir Review of draft-ietf-eai-simpledowngrade-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, 30 Apr 2012 14:17:39 -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-eai-simpledowngrade-03
Title: EAI: Simplified POP/IMAP downgrading
Reviewer: Claudio Allocchio
Review Date: April 30th 2012
IETF Last Call Date: n/a
IESG Telechat Date: n/a

Summary:

This specification needs some revision before it can be published. Some of 
them are just clarifications and better text, but in the case of the 
Security Considerations section, it might even need a revision, set of 
suggestions, from the Security area folks, in order to find the best 
possible way to explain involved risks.

I also suggest further thinking about the "Proposed Standards" track 
publication. I do see a good number of pros in doing this, but I'm not 
confident this is the completely correct way to go.

Major Issues:

2.3 Subject

adding or non adding a "DOWNGRADED" or equivalent to the subject is a 
major decision which also impacts on the way the security failure which 
are introduced by this specification are perceived by the user. This issue 
shall be fixed and a decision taken ASAP, in order to publish this.

5. Security Considerations

this section is way too short and simplified, compared to the issues that 
this specification introduces against secure e-mail mechanisms.

This section should give an exaustive list of caveats, and possible 
actions in various cases, in order to make clear that this specification 
breaks explicilty most of the existing security anchors where users should 
rely nowadays. It should also list that, while it is clear that in most of 
the cases where downgrading and/or gatewaying is involved, possible 
security leaks are introduced, and user's security mechanisms become 
invalid. "as is" is not enough.

  Minor Issues:

Abstract:

given the quite invasive action on messages presentation that such a 
specification describes, such a short and "optimistic" abstract is, IMHO, 
misleading. At least insert a sentence to describe the scenario, and what 
this specification is trying to accomplish, what problems it tries to 
solve, and what issues are left open and voluntarily not solved here.

1 Overview:

I disagree on the way the overview present "phylosophically" the problem 
to the reader. This is a technical specification intended for Standards 
Track, not an informational document. Thus, it should not focus on the way 
implementerss spend their time, os users' behaviours. It should state the 
problem and the proposed solutions: (dot)!

Here is my suggested version of this paragraph:

---

1. Overview

It may happen that a conventional IMAP or POP client opens a mailbox 
containing internationalized messages, or even attempt to read 
internationalized messages, for instance when a user has both 
internationalized and conventional MUAs.

When this mismatched sitation happens, various strategies are possible:

  a) the server can hide the existence of such messages entirely, but
     doing that can be both tricky to implement and gives a false mailbox
     status to the user;

  b) the server attempts to present at least some information about these
     messages to the user. It shall be clear that what the user is being
     presented is not the original message, and information is dropped;

  c) the server does nothing, possibly creating problems to the client, and
     providing a bad user's experience.

This document specify a way to implement strategy b), which enables the 
best compromise between a) and c), and promotes a simple to implement 
solution which conveys a better-than-nothing information service to the 
user. Accuracy of information and Security featues of the message will, 
however, not be preserved, and users should rely on an internationalised 
client as much as possible.

The server is assumed to be internationalized internally. When it
needs to present an internationalized message to a conventional
client, it synthesizes a conventional message containing most of the
information and presents that (the "synthetic message").

----

2.1 Email addresses

At lease one sentence clearly stating that this will make impossible to 
reply to such a synthetic message should be present here. Too obvious? 
no... never suppouse that.

Nits:

1 Overwiew

"It may happen that a conventional IMAP or POP client (MUA) opens..."
                                                       ^ add the definition

I suggest coherent use also in other parts of the specification.

6. Acknowledgments

well... clean it up from the call, before publishing!

7. IANA Considerations

ADD the name of the correct registry!

----------------------------

Ok... now I can go and read my co-reviewer report :-)

------------------------------------------------------------------------------
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 stpeter@stpeter.im  Mon Apr 30 07:22: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 E285B21F8642; Mon, 30 Apr 2012 07:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQDTV-9PiwmF; Mon, 30 Apr 2012 07:22:56 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF6D21F8634; Mon, 30 Apr 2012 07:22:56 -0700 (PDT)
Received: from [107.16.139.250] (unknown [209.116.57.2]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 147B740058; Mon, 30 Apr 2012 08:37:47 -0600 (MDT)
Message-ID: <4F9EA03D.2040505@stpeter.im>
Date: Mon, 30 Apr 2012 07:22:53 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: James Cloos 
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com>  <201204300316.q3U3GFcF002018@new.toad.com> 
In-Reply-To: 
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 14:22:57 -0000

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

On 4/30/12 1:40 AM, James Cloos wrote:
> John's post exactly illustrates why I've been advocating always
> doing TLSA lookups for the port and name for which the client is
> making an A/AAAA or PTR lookup¹.  Ie, from the results of the
> NAPTR, SRV and/or MX.
> 
> Except only for cases which /explicitly/ specify different
> behaviour. :)
> 
> RFC 3923 says that XMPP -- the oft-cited counter example --
> requires certs to have subjectAltName values which look like email
> addresses, rather than like host names.  XMPP, therefore, isn't
> actually relevant to draft-ietf-dane-protocol, but rather to the
> forthcoming draft about public key data for TLS client certs.

That's because RFC 3923 is about client-to-client (end-to-end)
encryption, so the certificates used in that context contain
subjectAltName values of the form user@host. See Section 13.7.1.2.1 of
RFC 6120 for the most up-to-date XMPP-specific rules about server
certificates (where the subjectAltName values are domain names).

Peter

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


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

iEYEARECAAYFAk+eoD0ACgkQNL8k5A2w/vxI8ACeOSL3ghOL7tD9D2M3MBNY0ksS
tdQAn2lUP6FvVjQipsvqRKLH5qXUJvPA
=xFXj
-----END PGP SIGNATURE-----

From fanf2@hermes.cam.ac.uk  Mon Apr 30 07:32: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 1C23A21F864B; Mon, 30 Apr 2012 07:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.445
X-Spam-Level: 
X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eg9Is943xM1j; Mon, 30 Apr 2012 07:32:23 -0700 (PDT)
Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEAF21F8630; Mon, 30 Apr 2012 07:32:23 -0700 (PDT)
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-2.csi.cam.ac.uk ([131.111.8.54]:60940) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SOreG-00015i-El (Exim 4.72) (return-path ); Mon, 30 Apr 2012 15:32:20 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SOreG-0006Di-HP (Exim 4.67) (return-path ); Mon, 30 Apr 2012 15:32:20 +0100
Date: Mon, 30 Apr 2012 15:32:20 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Martin Rex 
In-Reply-To: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp>
Message-ID: 
References: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp>
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: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, John Gilmore , iesg@ietf.org, paul@nohats.ca
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 14:32:24 -0000

Martin Rex  wrote:
>
> When trying to deliver mail to @toad.com, the only secure
> question to ask is whether the server is authorized to process
> Email for @toad.com.  For certificates issued from the traditional
> PKIX world, that would require a "toad.com" DNSName SAN.

That is not the only answer if the MX lookup is secured with DNSSEC.

> The security properties of any MX, CNAME, A or AAAA lookups during
> connection establishment with that server are irrelevant for DANE
> (and invisible to PKIX).

RFC 6125 allows for secure name indirections.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
South-east Iceland: Southwesterly 4 or 5, increasing 6 or 7 for a time.
Moderate or rough. Occasional rain. Moderate or good.

From mamille2@cisco.com  Mon Apr 30 07:36: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 45B2021F84EA; Mon, 30 Apr 2012 07:36:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.486
X-Spam-Level: 
X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yoi4PD9fpRs; Mon, 30 Apr 2012 07:36:13 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B35CA21F84D0; Mon, 30 Apr 2012 07:36:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6377; q=dns/txt; s=iport; t=1335796573; x=1337006173; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=b2mkUjuXeHXwOAgQl/kEi/gH9qZgnJaitdJsjcNtgvw=; b=IyTkyReyO9P8MnDrlOztK/Mh8Bjr9gYfPTKi3rJ0vrnN95DzO5b6Lpyt Egq+JrGyHEufVZAHdSf8CACtCPqlrnnUDgDv0i9bH1qzwBXbo51K4JW7C PLPpohrXedcjkOVOzv01Q8lHQovOvPUY8ToLQ35We4p3AJjSNpJWQXmao 0=;
X-Files: smime.p7s, PGP.sig : 2214, 535
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAL2ink+rRDoJ/2dsb2JhbABEr0aDAIEHggkBAQEDAQEBAQ8BWwsFCwtGAiUwBhMih2YEAQuaE59cBJA/YwSIZIYThweOWYFpgweBPQ
X-IronPort-AV: E=Sophos;i="4.75,504,1330905600";  d="sig'?p7s'?scan'208";a="42797888"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 30 Apr 2012 14:36:13 +0000
Received: from dhcp-64-101-72-220.cisco.com (dhcp-64-101-72-220.cisco.com [64.101.72.220]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3UEaCrN006240; Mon, 30 Apr 2012 14:36:13 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-60-1007096773"
From: Matt Miller 
In-Reply-To: 
Date: Mon, 30 Apr 2012 08:36:22 -0600
Message-Id: <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com>
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com>  <201204300316.q3U3GFcF002018@new.toad.com> 
To: James Cloos 
Content-Transfer-Encoding: 7bit
X-Pgp-Agent: GPGMail 1.3.3
X-Mailer: Apple Mail (2.1084)
Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , John Gilmore , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 14:36:14 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-60-1007096773
Content-Type: multipart/signed; boundary=Apple-Mail-59-1007096763; protocol="application/pkcs7-signature"; micalg=sha1


--Apple-Mail-59-1007096763
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


On Apr 30, 2012, at 02:40, James Cloos wrote:

> John's post exactly illustrates why I've been advocating always doing
> TLSA lookups for the port and name for which the client is making an
> A/AAAA or PTR lookup=B9.  Ie, from the results of the NAPTR, SRV =
and/or MX.
>=20
> Except only for cases which /explicitly/ specify different behaviour. =
:)
>=20
> RFC 3923 says that XMPP -- the oft-cited counter example -- requires
> certs to have subjectAltName values which look like email addresses,
> rather than like host names.  XMPP, therefore, isn't actually relevant
> to draft-ietf-dane-protocol, but rather to the forthcoming draft about
> public key data for TLS client certs.
>=20

You are correct that RFC 3923 not relevant to the current discussion; it =
only covers end-to-end object encryption (read: between clients), not =
TLS.

However, 6120 does talk about server certificate expectations with =
regards to TLS; the xmppAddr looks like a host name then. See RFC 6120, =
sections 13.7.1.2 and 13.7.2.1 more details.

> The exceptions should be few and far-between.  And they should require
> their own rfc referencing and modifying TLSA for their own needs.
>=20
> 1]  If an address rather than a name is supplied, one must choose =
between
>    doing a PTR to get a name and a TLSA on that name to get the cert
>    info, or doing a TLSA on the address.  Either way, one shoudl =
expect
>    the cert to have a CN and/or subjectAltName which matches the name
>    returned by the PTR lookup.
>=20

For XMPP, this is not true, and why Peter and I are working on an =
XMPP-specific proposal.

> -JimC
> --=20
> James Cloos          OpenPGP: 1024D/ED7DAEA6
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


- m&m

Matt Miller - 
Cisco Systems, Inc.


--Apple-Mail-59-1007096763
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw
ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x
MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt
YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd
/kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk
cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO
7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV
jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv
NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC
AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo
dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE
AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB
hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN
BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+
SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9
N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT
xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx
s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B
PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2
FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc
/6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg
b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph
p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD
VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo
b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg
ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQzMDE0MzYy
MlowIwYJKoZIhvcNAQkEMRYEFLOlXEEkB9Nef/cryf2Y7Ok1nqtmMIGRBgkrBgEEAYI3EAQxgYMw
gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw
IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0
QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD
QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p
bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq
hkiG9w0BAQEFAASCAQCbxigd7AcGMcJMAV1lqdafDexBbe4iC7S5wjFmQ4xExRscfEC330B6zIg1
dHBEwQ5915yf1PmOwdCkCzv3bBjDI+j3LTxnCVr9cBvon2cnn9NsiHKC59wbAoo39foNq38clmrH
bFpZAabjTL7H3Uvy42G4s/9uggyuucPAUTgiLRlAg3xPL1cbEySVitAPn6MSNsoVBxoxb2zldPVy
ZH9hm4KLaEmwRrRCxdt3tp6SR6hiuA+pc33XYulq5cnv1iu+ktWllSR5kZqgjLyvrPH/nP+xukbJ
Urk1/WDFTGBIIUMOJSU9nqihgYAYJB3bfQ4q3iR8jX42YzwHhR1exaBqAAAAAAAA

--Apple-Mail-59-1007096763--

--Apple-Mail-60-1007096773
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJPnqNmAAoJEJq6Ou0cgrSPd8QH/i+u14fDZDnmiA5vkmMimymi
LwS8qcSLgsS9+brN04XJjq0VpSlXPy5ibqqMSOzCd2G5Qkp3d+9G2FUWKbcDBaBY
4x31cfqy5hrmv7CNk2lKboIYGYxFWQp5uj4x7H535H2AUDvHHhJtUR8STvMw/1d+
oErCBHgK70g9iXN3dboLLqjTLSzP/sma38a9uNgsQ+LYaT34ltBPkXKahuMLOIqh
4zjJp0rNnERin2mGnOz9XiURysDJx/As3VItdotKsBIt2rj8NmO5S+4UZwv4lvnk
4qzMoJUz+1s4WDO3hA2Hv9zkWkOSavcTBoQAhQQnjRml0x96Sy4XepITtkC3DW4=
=kp/M
-----END PGP SIGNATURE-----

--Apple-Mail-60-1007096773--

From mrex@sap.com  Mon Apr 30 07:46: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 6026121F8541; Mon, 30 Apr 2012 07:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.121
X-Spam-Level: 
X-Spam-Status: No, score=-10.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kv0tXitsS3wC; Mon, 30 Apr 2012 07:46:21 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 59A7E21F84D6; Mon, 30 Apr 2012 07:46:21 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3UEkIsH008428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Apr 2012 16:46:18 +0200 (MEST)
From: Martin Rex 
Message-Id: <201204301446.q3UEkH2G010394@fs4113.wdf.sap.corp>
To: dot@dotat.at (Tony Finch)
Date: Mon, 30 Apr 2012 16:46:17 +0200 (MEST)
In-Reply-To:  from "Tony Finch" at Apr 30, 12 03:32:20 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: mrex@sap.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, gnu@toad.com, iesg@ietf.org, paul@nohats.ca
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Apr 2012 14:46:22 -0000

Tony Finch wrote:
> 
> Martin Rex  wrote:
> >
> > When trying to deliver mail to @toad.com, the only secure
> > question to ask is whether the server is authorized to process
> > Email for @toad.com.  For certificates issued from the traditional
> > PKIX world, that would require a "toad.com" DNSName SAN.
> 
> That is not the only answer if the MX lookup is secured with DNSSEC.

Think of DANE as something that works (or is supposed to work) similar
to PKIX.  How and whether other parts of the software perform fancy
indirections through DNS or otherwise, and how and whether those are
secure, is not visible to the DANE module (neither to PKIX) and
should therefore not be relevant for either.  Doing otherwise is
calling for _real_ trouble.

DNS allows for some pretty fancy indirections, and trying to ensure
that *ALL* of those are secure (in particular since they happen in
software modules completely distinct from DANE) and trying to
describe the resulting implications (and dangers) to DNS admins
is IMHO bound to fail badly.


> 
> > The security properties of any MX, CNAME, A or AAAA lookups during
> > connection establishment with that server are irrelevant for DANE
> > (and invisible to PKIX).
> 
> RFC 6125 allows for secure name indirections.

Which _secure_ name indirections are you thinking of?


-Martin

From fanf2@hermes.cam.ac.uk  Mon Apr 30 07:52: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 5258721F865C; Mon, 30 Apr 2012 07:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.455
X-Spam-Level: 
X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltE+WgCORSAH; Mon, 30 Apr 2012 07:52:47 -0700 (PDT)
Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD6B21F8657; Mon, 30 Apr 2012 07:52:45 -0700 (PDT)
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-2.csi.cam.ac.uk ([131.111.8.54]:34716) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SOrxy-00069A-Wo (Exim 4.72) (return-path ); Mon, 30 Apr 2012 15:52:42 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SOrxy-0001Qg-54 (Exim 4.67) (return-path ); Mon, 30 Apr 2012 15:52:42 +0100
Date: Mon, 30 Apr 2012 15:52:42 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Martin Rex 
In-Reply-To: <201204301446.q3UEkH2G010394@fs4113.wdf.sap.corp>
Message-ID: 
References: <201204301446.q3UEkH2G010394@fs4113.wdf.sap.corp>
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: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, gnu@toad.com, iesg@ietf.org, paul@nohats.ca
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 14:52:49 -0000

Martin Rex  wrote:

> > > The security properties of any MX, CNAME, A or AAAA lookups during
> > > connection establishment with that server are irrelevant for DANE
> > > (and invisible to PKIX).
> >
> > RFC 6125 allows for secure name indirections.
>
> Which _secure_ name indirections are you thinking of?

RFC 6125 says:

   The client might need to extract the source domain and application
   service type from the input(s) it has received.  The extracted data
   MUST include only information that can be securely parsed out of the
   inputs (e.g., parsing the fully qualified DNS domain name out of the
   "host" component (or its equivalent) of a URI or deriving the
   application service type from the scheme of a URI) or information
   that is derived in a manner not subject to subversion by network
   attackers (e.g., pulling the data from a delegated domain that is
   explicitly established via client or system configuration, resolving
   the data via [DNSSEC], or obtaining the data from a third-party
   domain mapping service in which a human user has explicitly placed
   trust and with which the client communicates over a connection or
   association that provides both mutual authentication and integrity
   checking).

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
North Bailey, Fair Isle, Faeroes: Variable 3 or 4, becoming southwesterly 5
later in north Bailey and Faeroes. Slight or moderate. Occasional rain.
Moderate or good.

From warren@kumari.net  Mon Apr 30 07:15: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 4220121F864F; Mon, 30 Apr 2012 07:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aR0X6M7eXSRS; Mon, 30 Apr 2012 07:15:41 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 309CB21F864B; Mon, 30 Apr 2012 07:15:41 -0700 (PDT)
Received: from dhcp-172-29-46-50.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id B4CD21B40305; Mon, 30 Apr 2012 10:15:40 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1252
From: Warren Kumari 
In-Reply-To: 
Date: Mon, 30 Apr 2012 10:15:39 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <512A3C9F-B4F2-4C31-9341-7B8C82D6C006@kumari.net>
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> 
To: Paul Hoffman 
X-Mailer: Apple Mail (2.1257)
X-Mailman-Approved-At: Mon, 30 Apr 2012 07:55:34 -0700
Cc: "apps-discuss@ietf.org" , dane@ietf.org, John Gilmore , iesg@ietf.org, Paul Wouters , Warren Kumari 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 14:15:42 -0000

On Apr 29, 2012, at 7:28 PM, Paul Hoffman wrote:

> On Apr 29, 2012, at 4:09 PM, John Gilmore wrote:
>=20
>>>>> So this will not work for any type of DNS indirection mechanism, =
such as MX, SRV, etc?
>>=20
>> TLSA is expected to work with TLS-based services reached via MX
>> records, as well as with services that use TLS which are reached via
>> SRV records.
>=20
> You may have missed the earlier discussion of this topic, and the fact =
that the topic was closed with a result different than what you say =
here. Please see .
>=20
> If the WG chairs think that Jakob and I have not reflected the WG =
consensus from that issue in the document,


Nope -- the chairs believe that WG consensus has been captured and =
reflected in the document=85

The XMPP people have already agreed to do the initial work for the XMPP =
protocol, and others can leverage their work after it is finished.
Different protocols have different expectations / requirements, and so =
we will need differnt means of dealing with them ("How to do DANE with =
protocol foo" type documents=85)

W

> we are happy to update the document yet again.
>=20
> --Paul Hoffman
>=20
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
>=20


From Claudio.Allocchio@garr.it  Mon Apr 30 08:18: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 BEF8621F8667 for ; Mon, 30 Apr 2012 08:18:29 -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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+HDH2KIyjHS for ; Mon, 30 Apr 2012 08:18:29 -0700 (PDT)
Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 2724621F85F4 for ; Mon, 30 Apr 2012 08:18:20 -0700 (PDT)
Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q3UFIH5i039326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2012 17:18:17 +0200 (CEST)
X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q3UFIH5i039326
DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=lMv/JjdY38+qthOpTFoIjYyOHwpqgmCNYVCKToPGbEu5rVLmRLoPpHKHfrhBoGH2t wD3Q3LmmrMvB2V6W/batH7aYPeBZoCV97LUDy7YEH8wlAscS1o3u2ZKfXzTXgpIFdp2 xRfDWA4eaB6HY7os49Xnf4PJP1OOpMV6x+N7McQ=
Date: Mon, 30 Apr 2012 17:18:16 +0200 (CEST)
From: Claudio Allocchio 
X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it
To: apps-discuss@ietf.org, draft-ietf-eai-popimap-downgrade.all@tools.ietf.org
Message-ID: 
User-Agent: Alpine 2.02 (OSX 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Subject: [apps-discuss] AppsDir review of draft-ietf-eai-popimap-downgrade-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, 30 Apr 2012 15:18:29 -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-eai-popimap-downgrade-05
Title: Post-delivery Message Downgrading for Internationalized Email
        Messages
Reviewer: Claudio Allocchio
Review Date: April 30th 2012
IETF Last Call Date: n/a
IESG Telechat Date: n/a

Summary: This document is requires a major decision about updating/non 
updating RFC 5322 before it can go to publication. Once this is done, 
other minor changes are listed below and it can be published. Another 
issue to clarify/fix is its relationship with 
draft-ietf-eai-simpledowngrade-03 specification (and also in that 
document, of course, with respect to this one).

Major Issues:

3. Updating RFC 5322

this is a big major issue in this specification.

I do not believe that stating something like "It is anticipated that when 
existing implementations encounter a downgraded field from this set, many 
will tolerate the appearance of a group" is a possible thing into a 
Standards Track specification.  Th "update" to RFC 5322 is a big major 
one, and cons should be carefully evaluated here, too. As the "Notes in 
Draf" itself states, there is an alternate, much safer mechamism which can 
be used, and convey the same information to the user. This isse must be 
clarified before this specification can be publisehd, and a decision 
taken.

Minor Issues:

there is not cross-reference at all with

draft-ietf-eai-simpledowngrade-03!

many implementers could ge confused about the releationship between these 
specifications. In the Summary this should be explicitly described and 
clearly stated.

Security Considerations

this section describes quite well the possible scenarios which this 
specification introduces (and can also be a good example for re-writing
the same secrion in draft-ietf-eai-simpledowngrade-03); I'd just suggest a 
further review by the Security area folks, too. Just in case...

  Nits:

1.1 Problem statement

I'd suggest removing "Discussions leading to this specification concluded 
that " and just start with "There are four...'

5.1.1 until 5.1.9

in the titles you use the defintions without the <...> surrounding them.
e.g.

   5.1.5 GROUP Downgrading.

I'd suggest changing them all using the < and > ... e.g.

   5.1.5  Downgrading.

etc.

IANA Considerartions:

... to be fixed with IANA before publication!

All over the document (and expecially in the A.1 example):

this document uses a different convetion than 
draft-ietf-eai-simpledowngrade-03 for non ASCII elements in 
addresses/fields. Please unify the used convetion with the other draft 
(whichever of the 2 convetion is better) before publication.

Here you write "NON-ASCII-something..." there you just use UPPERCASE.

------------------------------------------------------------------------------
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 mrex@sap.com  Mon Apr 30 08:37: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 D2E1221F868A; Mon, 30 Apr 2012 08:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.123
X-Spam-Level: 
X-Spam-Status: No, score=-10.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9JeGHdVEwfE; Mon, 30 Apr 2012 08:37:23 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A14DA21F85A5; Mon, 30 Apr 2012 08:37:22 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3UFbK3F015000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Apr 2012 17:37:20 +0200 (MEST)
From: Martin Rex 
Message-Id: <201204301537.q3UFbJic013190@fs4113.wdf.sap.corp>
To: dot@dotat.at (Tony Finch)
Date: Mon, 30 Apr 2012 17:37:19 +0200 (MEST)
In-Reply-To:  from "Tony Finch" at Apr 30, 12 03:52:42 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: mrex@sap.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, gnu@toad.com, iesg@ietf.org, paul@nohats.ca
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Apr 2012 15:37:24 -0000

Tony Finch wrote:
> 
> Martin Rex  wrote:
> 
> > > > The security properties of any MX, CNAME, A or AAAA lookups during
> > > > connection establishment with that server are irrelevant for DANE
> > > > (and invisible to PKIX).
> > >
> > > RFC 6125 allows for secure name indirections.
> >
> > Which _secure_ name indirections are you thinking of?
> 
> RFC 6125 says:
> 
>    The client might need to extract the source domain and application
>    service type from the input(s) it has received.  The extracted data
>    MUST include only information that can be securely parsed out of the
>    inputs (e.g., parsing the fully qualified DNS domain name out of the
>    "host" component (or its equivalent) of a URI or deriving the
>    application service type from the scheme of a URI) or information
>    that is derived in a manner not subject to subversion by network
>    attackers (e.g., pulling the data from a delegated domain that is
>    explicitly established via client or system configuration, resolving
>    the data via [DNSSEC], or obtaining the data from a third-party
>    domain mapping service in which a human user has explicitly placed
>    trust and with which the client communicates over a connection or
>    association that provides both mutual authentication and integrity
>    checking).


One should not confuse DNSSEC protection of DNS records (which provide
only data integrity and data origin authentication) with the concept
of a secure directory service providing name translations.

Sprinkling security equally across all DNS records also seems like
a bad idea.  I think it would be much more sensible to limit the
security-relevant DNS records (and indirections allowed for them)
to _very_ few records, and preferably all _new_ records, because
DNSSEC-less zones will be with us for many years to come, and

I believe it would be a really bad idea to change the sensitivity
of existing DNS records underneath DNS registrar's feet.

For TLSA records it would be OK if DNS software (and DNS servers)
performed some plausibility checks, e.g. warn prominently if TLSA
records are present in a Zone but no DNSSEC is active for the zone.
Something which does not make sense for any of the traditional
DNS records.


Looking at the example from a previous post:

>
> ;; QUESTION SECTION:
> ;universalmusic.com.      IN  MX
>
> ;; ANSWER SECTION:
> universalmusic.com.  3600 IN  MX   10 mail.global.frontbridge.com.


For regular DANE, it is sufficient if (but also necessary that)
the DNS-Domain "universalmusic.com" has DNSSEC active in order to
securely provide a TLSA record for

_25._tcp.universalmusic.com.

and simultaneously independent from the DNSSEC status of frontbridge.com.


If you want to allow DNS-based indirection, and in particular on existing
DNS records, then you would have to enforce that *ALL* domains that
are traversed during all possible DNS indirections have DNSSEC active
and that all lookups are verified, and require that the SMTP-software
aborts if DNSSEC verification of one of the indirections fails or
is not possible, and it may be difficult to impossible for the DNS-Software
(maintenance tools and DNS-Server) to help you maintaining consistency
across all those possible indirections, and close to impossible for the
DNS admins to understand the implications.


-Martin

From cloos@jhcloos.com  Mon Apr 30 08: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 8D21A21F86F0; Mon, 30 Apr 2012 08:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[AWL=0.571,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDh4UeO5296w; Mon, 30 Apr 2012 08:52:25 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id CCFCF21F867E; Mon, 30 Apr 2012 08:52:25 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 0403C4017D; Mon, 30 Apr 2012 15:52:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1335801145; bh=ws9CoPfw/V+c+vTaT/FiWgGvmeaTOUrMAfKnXlY0yn0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=pQnQuTFZtDbCcs6riDLaces6NsBe45lJmepRgjt/hJOp0RL6mujNmtvbBgT+fTqxG cfagd1l57ZG6UGjDbz2xYsJVi3un9jJZyEcD4zf/A02NZVwCjHs5GuAL4QlJbEl5NQ TUL8PlWMyXZ+lBzYLjDl0vNEvYhHOvfKibHJasTc=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 8CA1036004C; Mon, 30 Apr 2012 15:51:26 +0000 (UTC)
From: James Cloos 
To: dane@ietf.org
In-Reply-To: <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> ("Patrik =?iso-8859-1?Q?F=E4ltstr=F6m=22's?= message of "Mon, 30 Apr 2012 03:16:41 +0200")
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>
User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2012 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Mon, 30 Apr 2012 11:51:26 -0400
Message-ID: 
Lines: 21
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Cc: Mark Andrews , "apps-discuss@ietf.org" , Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 15:52:26 -0000

>>>>> "PF" == Patrik Fältström  writes:

PF> On 30 apr 2012, at 01:58, Mark Andrews wrote:

>> toad.com.		MX	150 mail.toad.com.
>> mail.toad.com.		CNAME	new.toad.com.

PF> Mark, I must admit I do not remember what your personal view is on
PF> MX -> CNAME chains, but I am a strong believer in that this is
PF> something that is not accepted.

There is no technical reason to avoid it.  The SMTP app does an MX
lookup and receives a name.  It then does an A and/or AAAA lookup
on that name to get an address.  If that name is handled by way of
a CNAME RR, the resolving DNS server transparently follows it; the
SMTP app doesn't see the CNAME RR, and therefor cannot be harmed
by its existance.

-JimC
-- 
James Cloos          OpenPGP: 1024D/ED7DAEA6

From stephen.farrell@cs.tcd.ie  Mon Apr 30 09:06: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 0234121F86DD for ; Mon, 30 Apr 2012 09:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.384
X-Spam-Level: 
X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHLcGBebOg2q for ; Mon, 30 Apr 2012 09:06:23 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 3686421F86DA for ; Mon, 30 Apr 2012 09:06:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 9FBF91714F1; Mon, 30 Apr 2012 17:06:22 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335801981; bh=zyVomavjhf6Odj M+CDXRmzI7I/MXMSht7XKnPpVXE9A=; b=M2/leacW75Yy3Zvb/2knvxsv/a/pQu +Ki6iLifLLinmp7zAXnmgBMdbT94VuOyKy9gsG3rsMhkx1rky2PJibWPhGi978vL d76h0Vbpo/5g+0Zr7kZVx+UT51CrC1KukFEnLjsZE2y7qDK2quDNI5fYnEkmMhlr P6h+gafHm+m/mT2Ljp8Kmqu2yRZtKlfWRGBZ+oR4msmZH2BL5f8OWQ4hZ+FB1L3T M5OrpQaXYAotzjyJ6S3xleRTQZvhGW72EKq5Uo5Sh+6AYUE9FP6iF0LxFFL4V2iM mEM0M0XgQYmi+D1KOlpgvzCaJsMNEgnaObaBK0HiHEanbTbc5DPx5gtg==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 5SHH6wQW-pSn; Mon, 30 Apr 2012 17:06:21 +0100 (IST)
Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id F4218171476; Mon, 30 Apr 2012 17:06:14 +0100 (IST)
Message-ID: <4F9EB876.5070907@cs.tcd.ie>
Date: Mon, 30 Apr 2012 17:06:14 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: "Manger, James H" 
References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] draft-farrell-decade-ni-04: more glitches in examples
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 16:06:29 -0000

Hi James,

I pushed out a version [1] that I hope fixes this. We'll see I
guess;-)

Thanks for catching those though!

Cheers,
S.

[1] http://tools.ietf.org/html/draft-farrell-decade-ni-05

On 04/30/2012 03:23 AM, Manger, James H wrote:
> Ari and Stephen,
> 
> There are new glitches in the examples in "Naming Things with Hashes" .
> 
> The 1st examples are wrong:
>   "Hello World!" (without the quotes, being 12 characters)
>   ni:///sha-256;A7ogTlDRJuRnTABeBNguhMITZngK8fQ71Uo3gWtqs0A
> 
> A7og... is the (base64url-encoded) SHA-256 hash of *13* characters that includes a newline char at the end.
> Base64url(SHA-256("Hello World!\n")) = A7ogTlDRJuRnTABeBNguhMITZngK8fQ71Uo3gWtqs0A
> Base64url(SHA-256("Hello World!")) = f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
> 
> The URI should be
> ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
> 
> 
> The 2nd examples are wrong:
>   Given the SubjectPublicKeyInfo in Figure 5...
>   0000000 82 01 0a 02 82 01 01 00 a2 5f 83 da 9b d9 f1 7a
>   0000020 3a 36 67 ba fd 5a 94 0e cf 16 d5 5a 55 3a 5e d4
> 
> This is not a SubjectPublicKeyInfo value. It is not even "the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits)" -- which is commonly the input to a key-id calculation.
> Add an initial 0x30 to make the data a subjectPublicKey value (ie a DER-encoded RSAPublicKey); then add the DER-encoding for the rsaEncryption algorithm id and wrappers.
> 
> The full data should be:
> 
>   000000 : 30 82 01 22 30 0D 06 09  2A 86 48 86 F7 0D 01 01
>   000010 : 01 05 00 03 82 01 0F 00  30 82 01 0A 02 82 01 01
>   000020 : 00 A2 5F 83 DA 9B D9 F1  7A 3A 36 67 BA FD 5A 94
>   000030 : 0E CF 16 D5 5A 55 3A 5E  D4 03 B1 65 8E 6D CF A3
>   000040 : B7 DB A4 E7 CC 0F 52 C6  7D 35 1D C4 68 C2 BD 7B
>   000050 : 9D DB E4 0A D7 10 CD F9  53 20 EE 0D D7 56 6E 5B
>   000060 : 7A AE 2C 5F 83 0A 19 3C  72 58 96 D6 86 E8 0E E6
>   000070 : 94 EB 5C F2 90 3E F3 A8  8A 88 56 B6 CD 36 38 76
>   000080 : 22 97 B1 6B 3C 9C 07 F3  4F 97 08 A1 BC 29 38 9B
>   000090 : 81 06 2B 74 60 38 7A 93  2F 39 BE 12 34 09 6E 0B
>   0000A0 : 57 10 B7 A3 7B F2 C6 EE  D6 C1 E5 EC AE C5 9C 83
>   0000B0 : 14 F4 6B 58 E2 DE F2 FF  C9 77 07 E3 F3 4C 97 CF
>   0000C0 : 1A 28 9E 38 A1 B3 93 41  75 A1 A4 76 3F 4D 78 D7
>   0000D0 : 44 D6 1A E3 CE E2 5D C5  78 4C B5 31 22 2E C7 4B
>   0000E0 : 8C 6F 56 78 5C A1 C4 C0  1D CA E5 B9 44 D7 E9 90
>   0000F0 : 9C BC EE B0 A2 B1 DC DA  6D A0 0F F6 AD 1E 2C 12
>   000100 : A2 A7 66 60 3E 36 D4 91  41 C2 F2 E7 69 39 2C 9D
>   000110 : D2 DF B5 A3 44 95 48 7C  87 64 89 DD BF 05 01 EE
>   000120 : DD 02 03 01 00 01
> 
> The SHA-256 hash and all the subsequent URIs need to be changed to reflect the corrected input data.
> 
> --
> James Manger
> 
> 
> 
> 

From fanf2@hermes.cam.ac.uk  Mon Apr 30 09:27: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 A67FA21F873A; Mon, 30 Apr 2012 09:27:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.464
X-Spam-Level: 
X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8BT0QOOpsZF; Mon, 30 Apr 2012 09:27:46 -0700 (PDT)
Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8696521F8790; Mon, 30 Apr 2012 09:27:46 -0700 (PDT)
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-2.csi.cam.ac.uk ([131.111.8.54]:44516) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SOtRw-0007hL-WK (Exim 4.72) (return-path ); Mon, 30 Apr 2012 17:27:44 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SOtRv-0000xl-PH (Exim 4.67) (return-path ); Mon, 30 Apr 2012 17:27:43 +0100
Date: Mon, 30 Apr 2012 17:27:43 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Martin Rex 
In-Reply-To: <201204301537.q3UFbJic013190@fs4113.wdf.sap.corp>
Message-ID: 
References: <201204301537.q3UFbJic013190@fs4113.wdf.sap.corp>
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: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, gnu@toad.com, iesg@ietf.org, paul@nohats.ca
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 16:27:47 -0000

Martin Rex  wrote:
>
> If you want to allow DNS-based indirection, and in particular on existing
> DNS records, then you would have to enforce that *ALL* domains that
> are traversed during all possible DNS indirections have DNSSEC active
> and that all lookups are verified,

Right.

> and require that the SMTP-software aborts if DNSSEC verification of one
> of the indirections fails or is not possible,

Yes if you get a "bogus" result; if it's just insecure then it should fall
back to insecure SMTP (perhaps with unauthenticated TLS) as at present.

> and it may be difficult to impossible for the DNS-Software (maintenance
> tools and DNS-Server) to help you maintaining consistency across all
> those possible indirections, and close to impossible for the DNS admins
> to understand the implications.

That's an argument for putting the TLSA record alongside the server host
name, so that a certificate update only needs to be reflected in the DNS
in one place rather than at all the innumerable virtual domains hosted by
that server.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Sole, Lundy, Fastnet: Cyclonic, becoming easterly or northeasterly for a time,
6 to gale 8, decreasing 4 or 5 later in east Sole. Moderate or rough,
occasionally very rough in Sole. Rain or showers. Moderate or good.

From ned.freed@mrochek.com  Mon Apr 30 09:30: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 2647321F873E; Mon, 30 Apr 2012 09:30:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.504
X-Spam-Level: 
X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVcGoLF8R4mc; Mon, 30 Apr 2012 09:30:36 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4A68221F873A; Mon, 30 Apr 2012 09:30:36 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEXB2JD5F4000I1H@mauve.mrochek.com>; Mon, 30 Apr 2012 09:30:27 -0700 (PDT)
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Mon, 30 Apr 2012 09:30:23 -0700 (PDT)
Message-id: <01OEXB2GEMB20006TF@mauve.mrochek.com>
Date: Mon, 30 Apr 2012 09:27:38 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 30 Apr 2012 11:51:26 -0400" 
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> 
To: James Cloos 
Cc: Mark Andrews , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of	draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 16:30:37 -0000

> >>>>> "PF" == Patrik Fältström  writes:

> PF> On 30 apr 2012, at 01:58, Mark Andrews wrote:

> >> toad.com.		MX	150 mail.toad.com.
> >> mail.toad.com.		CNAME	new.toad.com.

> PF> Mark, I must admit I do not remember what your personal view is on
> PF> MX -> CNAME chains, but I am a strong believer in that this is
> PF> something that is not accepted.

> There is no technical reason to avoid it.  The SMTP app does an MX
> lookup and receives a name.  It then does an A and/or AAAA lookup
> on that name to get an address.  If that name is handled by way of
> a CNAME RR, the resolving DNS server transparently follows it; the
> SMTP app doesn't see the CNAME RR, and therefor cannot be harmed
> by its existance.

That's incorrect. See my previous post on this topic for specifics.

				Ned

From cloos@jhcloos.com  Mon Apr 30 09:44: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 3067D21F87FA; Mon, 30 Apr 2012 09:44:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.111
X-Spam-Level: 
X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.489,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77C06oq1Cimv; Mon, 30 Apr 2012 09:44:03 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 4784721F87EA; Mon, 30 Apr 2012 09:44:03 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 554CD403F4; Mon, 30 Apr 2012 16:43:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1335804242; bh=84xPvztEu4e0pLxdhQA91UGRTWdOwJkh5DqOmUmWgXo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=mLrr+7pkf9O5kly6hzhNwgDIPXaELI1H4q6P0cJAakXgklxD1rGb4jX/bz3K8hNa1 xwd2CLQxHHC6940lBSdBGE9kZM87vfLYrpr8YsvupQLdhp63u5Sf18fV8nEHAqZDqE zAAmpnXSPw7Rd4RZa2GK3ngSOwUGjB0DRRqEDnCY=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id ED1B736004E; Mon, 30 Apr 2012 16:21:22 +0000 (UTC)
From: James Cloos 
To: Tony Finch 
In-Reply-To:  (Tony Finch's message of "Mon, 30 Apr 2012 11:44:11 +0100")
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com>  <201204300316.q3U3GFcF002018@new.toad.com> 
User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2012 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Mon, 30 Apr 2012 12:21:22 -0400
Message-ID: 
Lines: 17
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:120430:dot@dotat.at::zgBYzam/g4mzI3Jm:0000cugBo
X-Hashcash: 1:30:120430:gnu@toad.com::AK6UM9Hcm68vMDto:0000rBkPd
X-Hashcash: 1:30:120430:"apps-discuss\@ietf.org"::/CpsRFiBryqvhn91:000000000000000000000000000000000000U780Z
X-Hashcash: 1:30:120430:apps-discuss@ietf.org::gMISTRgFuZNBzs4h:000000000000000000000000000000000000000z4NRU
X-Hashcash: 1:30:120430:dane@ietf.org::ZdXh3t1RAq9GAL2e:000u6Zis
X-Hashcash: 1:30:120430:paul.hoffman@vpnc.org::kZ4VP82EXrQKrSC7:000000000000000000000000000000000000000Bsvo/
X-Hashcash: 1:30:120430:iesg@ietf.org::IlFrQJDJy69dxzYo:000GGDl4
X-Hashcash: 1:30:120430:alexey.melnikov@isode.com::FE4ouJZeiGJbz3B7:000000000000000000000000000000000002nL7q
X-Hashcash: 1:30:120430:paul@nohats.ca::6/JbCxxLzc7H2Viy:00y6GFZ
Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , John Gilmore , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 16:44:06 -0000

>>>>> "TF" == Tony Finch  writes:

TF> There is currently no certificate verification on inter-domain SMTP.
TF> Most MXs present unverifiable certificates.

Some MTAs can be configured for it.  I currently get valid certs on
incoming mail from a number of sites, including debian, python,
gnumonks, google, ozlabs, cisco, cacert, several universites and a
few others.

But it is certainly true that most MXs do not bother to verify, even
when the same org's outgoing MTA's certs are verifiable.

-JimC
-- 
James Cloos          OpenPGP: 1024D/ED7DAEA6


From julian.reschke@gmx.de  Mon Apr 30 10:03: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 634F721F87DE for ; Mon, 30 Apr 2012 10:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.183
X-Spam-Level: 
X-Spam-Status: No, score=-103.183 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANhqDUOUfjKG for ; Mon, 30 Apr 2012 10:03:21 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 92FC421F86DB for ; Mon, 30 Apr 2012 10:03:20 -0700 (PDT)
Received: (qmail invoked by alias); 30 Apr 2012 17:03:18 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 30 Apr 2012 19:03:18 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18NpVEGLTANJSVuRMcFog+hZCuCbuiyokVIHUvTlJ vCRFms5iVjHdWP
Message-ID: <4F9EC5BD.7000404@gmx.de>
Date: Mon, 30 Apr 2012 19:02:53 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
To: "Murray S. Kucherawy" 
References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "draft-ietf-websec-strict-transport-sec@tools.ietf.org" , "websec@ietf.org" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] [websec] AppsDir review of draft-ietf-websec-strict-transport-sec
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 17:03:23 -0000

On 2012-04-29 09:11, Murray S. Kucherawy wrote:
 > ...
> Section 6.1.1: I think the "delta-seconds" should be:
>
> delta-seconds = 1*DIGIT
>
> ; defined in Section 3.3.2 of [RFC2616]
> ...

That would copy the rule from RFC 2616 "by value".

 > ...
> The angle-bracket notation you have there doesn't seem to be normal.
> ...

It's a prose rule; see RFC 5234 prose-val. It's used here to define the 
ABNF rule "by reference".

The reference form in theory is safer because there's only a single 
definition, so no conflicts are possible.

Best regards, Julian

PS: we use the prose-val style a lot in HTTPbis for referencing ABNF 
from other documents, so if there's a problem with that I'd like to 
learn ASAP about it :-)

From cloos@jhcloos.com  Mon Apr 30 10:32: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 E8B5221F8858; Mon, 30 Apr 2012 10:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.054
X-Spam-Level: 
X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.545,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Btuc+a3DS4hW; Mon, 30 Apr 2012 10:32:12 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0E821F8855; Mon, 30 Apr 2012 10:32:12 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 346CC40019; Mon, 30 Apr 2012 17:31:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1335807131; bh=y7Cs798dAKZIYFmbZvsdnilceK9g9QQNHBJw7Lyepak=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=F+ucqmxLoX4TCkxpU8ewF+/bQ4Sa5MoPgWsY6W56HCF7JLl0SVM6H+eKJ/KfuBxFN F0habNCJhhHg8wi0uB3AeUelQRDQaaaW2FZGT8nK+kum/iGenZ3JEWJUcIaFBW3lwm n9OUNNt0TqewzJT1D4h5zH6WTe1uz/wt4VRv9upY=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 9D6BE36004C; Mon, 30 Apr 2012 17:02:13 +0000 (UTC)
From: James Cloos 
To: Ned Freed 
In-Reply-To: <01OEXB2GEMB20006TF@mauve.mrochek.com> (Ned Freed's message of "Mon, 30 Apr 2012 09:27:38 -0700 (PDT)")
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>  <01OEXB2GEMB20006TF@mauve.mrochek.com>
User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2012 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Mon, 30 Apr 2012 13:02:13 -0400
Message-ID: 
Lines: 11
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:120430:ned.freed@mrochek.com::KLCC3ay+vqGiMAXR:000000000000000000000000000000000000000FJGbK
X-Hashcash: 1:30:120430:dane@ietf.org::cxlE2hLXcqvG7D+2:000KzwbQ
X-Hashcash: 1:30:120430:marka@isc.org::jO5khq0IPdAdApqh:000BDPh2
X-Hashcash: 1:30:120430:"apps-discuss\@ietf.org"::Xc5rQKet4TaWlnGQ:0000000000000000000000000000000000006TPxi
X-Hashcash: 1:30:120430:apps-discuss@ietf.org::wynJwWQtdvO128rz:000000000000000000000000000000000000000GlSmJ
X-Hashcash: 1:30:120430:paul.hoffman@vpnc.org::9ojnXlzsGVOmIGQn:000000000000000000000000000000000000000MCfd/
X-Hashcash: 1:30:120430:iesg@ietf.org::N/TqAy45Db1kYAJj:000pQ1/i
X-Hashcash: 1:30:120430:paul@nohats.ca::agg5g5OXKeNiZiPA:00VE/s9
Cc: Mark Andrews , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of	draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 17:32:13 -0000

>>>>> "NF" == Ned Freed  writes:

NF> That's incorrect. See my previous post on this topic for specifics.

I don't see any previous post from you???

To which list was it posted?

-JimC
-- 
James Cloos          OpenPGP: 1024D/ED7DAEA6

From cloos@jhcloos.com  Mon Apr 30 10:33: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 DD91321F8858; Mon, 30 Apr 2012 10:33:56 -0700 (PDT)
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.128,  BAYES_00=-2.599, J_CHICKENPOX_84=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi2kj3rmaH-z; Mon, 30 Apr 2012 10:33:56 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 4D10D21F8855; Mon, 30 Apr 2012 10:33:56 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id CB1AA40019; Mon, 30 Apr 2012 17:33:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1335807235; bh=5hdMHKV376JhSw5UNgj4tyrKSOugySCXCHvAgZif1W4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=K160azMJt8gxtSm4pqCRUS2Xbr5K5Gzg4HQ9PTR8ifDaKjt/vp9mivKEnfNXMZZS2 +OYPd9m9lxFgo0rqyA3MC+c6O1qxuGSyxMtbRQqGI+xdOAlFsHhpFw3uhNRX39Hl3T MJdqe9SKTBsEtnj0dTx7rdiTj4jVz3GuQCfGP1v4=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id D861436004C; Mon, 30 Apr 2012 17:15:12 +0000 (UTC)
From: James Cloos 
To: 
In-Reply-To: <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> (Matt Miller's message of "Mon, 30 Apr 2012 08:36:22 -0600")
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com>  <201204300316.q3U3GFcF002018@new.toad.com>  <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com>
User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2012 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Mon, 30 Apr 2012 13:15:12 -0400
Message-ID: 
Lines: 33
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:120430:dane@ietf.org::59idNfa5W+yUYlmU:00090FCS
X-Hashcash: 1:30:120430:mamille2@cisco.com::Iw6p1yGhderflihh:0000000000000000000000000000000000000000004PyGe
X-Hashcash: 1:30:120430:stpeter@stpeter.im::FiX853q1723FdyGP:000000000000000000000000000000000000000000i+hh6
X-Hashcash: 1:30:120430:apps-discuss@ietf.org::k04pOjngJV2+/SRa:000000000000000000000000000000000000000bpk6d
X-Hashcash: 1:30:120430:gnu@toad.com::XiWO0BG8Z9qqYrd2:00003fq7p
X-Hashcash: 1:30:120430:paul.hoffman@vpnc.org::NNBgxQisdQgYm7SP:000000000000000000000000000000000000000aAAjd
X-Hashcash: 1:30:120430:iesg@ietf.org::kf7oTx//in5Goqlz:0003NJ8S
X-Hashcash: 1:30:120430:paul@nohats.ca::mWDgxs0QWwPqYuGH:00KNTNE
Cc: apps-discuss@ietf.org, John Gilmore , Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 17:33:57 -0000

Thanks to Peter and Matt for the references to rfc 6120.

My prior presumptions about how XMPP uses TLS were based solely on posts
here.  Having now read through 6210, though, I see nothing which
contraindicates doing TLSA lookups based on the serv*er* name.

The XMPP app receives a URI.  From that it extracts a name to use in a
SRV lookup.  From the SRV RRs it gets a set of hostname+port tuples.
It then does an A/AAAA lookup on each of the hostnames.

When it does echo A/AAAA lookup it also can do a TLSA lookup using the
hostname+port and the protocol name which it previously used to
construct the SRV lookup.

It doesn't matter that it will look in the cert for the name in the
original URI and not for the resulting hostname.  It still is reasonable
to expect the cert association to be found parallel to the ip address.

Each dns lookup needs to dnsec-verify, of course, but the association
is provable (to the extent that *anything* crypto can be /proven/).

Everything just works.

Some might argue that having to add TLSA RRs for each server is a
hassle, but they already have to add the certs to each server, and
automation to keep everything in sync is not hard.

XMPP doesn't even need its own rfc for DANE, TLSA and 6120 already
cover everything it needs.

-JimC
-- 
James Cloos          OpenPGP: 1024D/ED7DAEA6

From mrex@sap.com  Mon Apr 30 10:43: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 B70D321F86FC; Mon, 30 Apr 2012 10:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.128
X-Spam-Level: 
X-Spam-Status: No, score=-10.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2v8GSbBHJ46; Mon, 30 Apr 2012 10:43:17 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id BA3CD21F87BE; Mon, 30 Apr 2012 10:43:16 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3UHhE87026290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Apr 2012 19:43:14 +0200 (MEST)
From: Martin Rex 
Message-Id: <201204301743.q3UHhDUH020670@fs4113.wdf.sap.corp>
To: dot@dotat.at (Tony Finch)
Date: Mon, 30 Apr 2012 19:43:13 +0200 (MEST)
In-Reply-To:  from "Tony Finch" at Apr 30, 12 05:27:43 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: mrex@sap.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, gnu@toad.com, iesg@ietf.org, paul@nohats.ca
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Apr 2012 17:43:22 -0000

Tony Finch wrote:
> 
> Martin Rex  wrote:
> >
> > If you want to allow DNS-based indirection, and in particular on existing
> > DNS records, then you would have to enforce that *ALL* domains that
> > are traversed during all possible DNS indirections have DNSSEC active
> > and that all lookups are verified,
> 
> Right.
> 
> > and require that the SMTP-software aborts if DNSSEC verification of one
> > of the indirections fails or is not possible,
> 
> Yes if you get a "bogus" result; if it's just insecure then it should fall
> back to insecure SMTP (perhaps with unauthenticated TLS) as at present.


Current security with SMTP is completely fubar (.. beyond repair).

First, the SMTP server endpoint identification should be fixed so that
it can be used with both/either (1) PKIX names or (2) DANE.

I believe that it would be a very bad idea to continue ignoring
the lack of authentication in SMTP with STARTTLS or by embracing
a scheme that is much more complex than what is used for HTTPS
by adding all conceivable DNS transformations into the picture,
because neither users nor admins will understand it anymore.


When writing a program for Unix that needs to be setuid for a privileged
operation, then it is extremely sensible to limit the euid to that one
privileged operation only, and carefully check the inputs to that privileged
operation, rather than running with elevated privileges all the time and use
all sorts of fancy features from various complex application libraries.


> 
> > and it may be difficult to impossible for the DNS-Software (maintenance
> > tools and DNS-Server) to help you maintaining consistency across all
> > those possible indirections, and close to impossible for the DNS admins
> > to understand the implications.
> 
> That's an argument for putting the TLSA record alongside the server host
> name, so that a certificate update only needs to be reflected in the DNS
> in one place rather than at all the innumerable virtual domains hosted by
> that server.


DNSSEC seems to create a lot of confusion.  The existance of DNS signatures
does not make data any more trustworthy above plain DNS.  It is still the
_same_ data, and usually maintained with the _same_ admin procedures and
the same amount of errors in it.

A goole search result is _not_ any more trustworthy when done through
https:// instead of http://, just less susceptible to third parties
modifying the results when it is transfered between google and your
browser.  The links to which google is pointing are going to be
the exact same (I assume... :).


-Martin

From mamille2@cisco.com  Mon Apr 30 10:46: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 99AD221F8691; Mon, 30 Apr 2012 10:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.199
X-Spam-Level: 
X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKGt4e-0dOpT; Mon, 30 Apr 2012 10:46:22 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id AEAFF21F864C; Mon, 30 Apr 2012 10:46:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6413; q=dns/txt; s=iport; t=1335807982; x=1337017582; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=u1M7LPEdLbOb/UqhQk8luFjDa5tLkILx/8vurNfFhSY=; b=eQ05VLivdn/oHoiZNAvCGGFbXT+pO3Cu3PDvOzom1ITtyoB01Kr/243j 1yqk9DbY9T0U5WJk2jghCSNX98ph/RXNcEaJ1bT+qbPt+8e96DOzyJMt7 d1zhzRkU8bmrYe8ly9VuweevFUntXsvevsmWvZGkEiJTgUBm1wfCtWEnv A=;
X-Files: smime.p7s, PGP.sig : 2214, 535
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAHTPnk+rRDoG/2dsb2JhbABEr1CDAIEHggkBAQEDARIBZgULC0YCVQYTIodmBAGaQZ9+kD9jBIhkhhOHB45ZgWmDBw
X-IronPort-AV: E=Sophos;i="4.75,505,1330905600";  d="sig'?p7s'?scan'208";a="42827147"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 30 Apr 2012 17:46:22 +0000
Received: from dhcp-64-101-72-220.cisco.com (dhcp-64-101-72-220.cisco.com [64.101.72.220]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3UHjemi013550; Mon, 30 Apr 2012 17:46:21 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-77-1018504897"
From: Matt Miller 
In-Reply-To: 
Date: Mon, 30 Apr 2012 11:46:30 -0600
Message-Id: <7CBBA998-7681-4885-A5E9-387F32DCE990@cisco.com>
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com>  <201204300316.q3U3GFcF002018@new.toad.com>  <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> 
To: James Cloos 
Content-Transfer-Encoding: 7bit
X-Pgp-Agent: GPGMail 1.3.3
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss@ietf.org, dane@ietf.org, John Gilmore , Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 17:46:23 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-77-1018504897
Content-Type: multipart/signed; boundary=Apple-Mail-76-1018504894; protocol="application/pkcs7-signature"; micalg=sha1


--Apple-Mail-76-1018504894
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Apr 30, 2012, at 11:15, James Cloos wrote:

> Thanks to Peter and Matt for the references to rfc 6120.
>=20
> My prior presumptions about how XMPP uses TLS were based solely on =
posts
> here.  Having now read through 6210, though, I see nothing which
> contraindicates doing TLSA lookups based on the serv*er* name.
>=20
> The XMPP app receives a URI.  =46rom that it extracts a name to use in =
a
> SRV lookup.  =46rom the SRV RRs it gets a set of hostname+port tuples.
> It then does an A/AAAA lookup on each of the hostnames.
>=20
> When it does echo A/AAAA lookup it also can do a TLSA lookup using the
> hostname+port and the protocol name which it previously used to
> construct the SRV lookup.
>=20
> It doesn't matter that it will look in the cert for the name in the
> original URI and not for the resulting hostname.  It still is =
reasonable
> to expect the cert association to be found parallel to the ip address.
>=20
> Each dns lookup needs to dnsec-verify, of course, but the association
> is provable (to the extent that *anything* crypto can be /proven/).
>=20
> Everything just works.
>=20
> Some might argue that having to add TLSA RRs for each server is a
> hassle, but they already have to add the certs to each server, and
> automation to keep everything in sync is not hard.
>=20
> XMPP doesn't even need its own rfc for DANE, TLSA and 6120 already
> cover everything it needs.

I think there might still need to be some explicitness on what name to =
expect to match on regardless of where the certificate is found, =
especially with multi-domain XMPP servers (e.g. a server =
"im.shakespeare.lit" that services domains "capulet.shakespeare.lit" and =
"denmark.shakespeare.lit").

Maybe that doesn't need to be its own document.  I am working on a =
proposal for improving XMPP federation, and a section in that document =
might be sufficient...Probably (-:


- m&m

Matt Miller - 
Cisco Systems, Inc.


--Apple-Mail-76-1018504894
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw
ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x
MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt
YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd
/kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk
cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO
7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV
jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv
NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC
AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo
dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE
AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB
hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN
BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+
SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9
N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT
xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx
s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B
PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2
FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc
/6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg
b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph
p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD
VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo
b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg
ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQzMDE3NDYz
MFowIwYJKoZIhvcNAQkEMRYEFEraCZxbtX9t6Tpmv/2bYAPZZIowMIGRBgkrBgEEAYI3EAQxgYMw
gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw
IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0
QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD
QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p
bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq
hkiG9w0BAQEFAASCAQCNCH/HlMWuv4VjJFjmL1WLTVp2BzfEKgYk3JhLBRdGWvLqnZyoWA7/7TFr
m4sXoBeGvgfpz2LkcJDTfp5NaG1DAciLQwnyXmw+NCpoTC4eCI+ONV2F1Z3PHxiYd0dFxCmulOxg
HryUgelx9vbvV0xZrdba2zlUP7HKps0QsK+cFdggoOPeQMQOdYs7AzmMtl81IrPunc1INFZAQ9fg
FY4wYm7L4YrzFvcokKQOjXvYuxSYfl/n1RTVLsCXabsNgNKv747N7oTS8KvrggxCLMge8rm6V7D2
+UnRFVlFMuAeuSOIQuEMxFdHn6iJJA6szo3cY2EiQJDIcGt9C/KqscqBAAAAAAAA

--Apple-Mail-76-1018504894--

--Apple-Mail-77-1018504897
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJPns/2AAoJEJq6Ou0cgrSP6a4IAMNTcBeCmx+qpgDM84n48vxK
b2iXgwcxvkqXdXHyJC5kXgVXQcTtD4dszF2g+Ez03HpSKjb5os50KD4w5/pac29K
a9nNd9m1V56gDrptVnAQFjn7sTHWZlIGEy3ivVz54BFHxO23ln4VXXWP9mJUZzmC
qc/80uldlQwHs1G4XQhZw+CpS0yG6JmDkw2QNCoEbgI6nzC8BtHDpcc2JGk6CiZv
v9bN0jgIigJIv0mrCnssfesd7ygLz0Tf/l9GO9+2pHIfEDGpPD6zbuyjugu6n64f
eAGPGsbLYvFGBUjTgdMzow+GUySpzgp/KbEq6NIXLcCYlAyLD3etzh63TKRtb7s=
=BSfe
-----END PGP SIGNATURE-----

--Apple-Mail-77-1018504897--

From paul.hoffman@vpnc.org  Mon Apr 30 11:37: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 1263E21F891B; Mon, 30 Apr 2012 11:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.54
X-Spam-Level: 
X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6VzHJoMKmRz; Mon, 30 Apr 2012 11:37:22 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5BE21F8910; Mon, 30 Apr 2012 11:37:22 -0700 (PDT)
Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3UIbGcr015909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Apr 2012 11:37:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman 
In-Reply-To: <7CBBA998-7681-4885-A5E9-387F32DCE990@cisco.com>
Date: Mon, 30 Apr 2012 11:37:16 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7584CC56-4202-45B5-81CD-BF77872D61D1@vpnc.org>
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com>  <201204300316.q3U3GFcF002018@new.toad.com>  <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com>  <7CBBA998-7681-4885-A5E9-387F32DCE990@cisco.com>
To: Matt Miller 
X-Mailer: Apple Mail (2.1257)
Cc: "apps-discuss@ietf.org Discuss" , IETF DANE WG list 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 18:37:23 -0000

On Apr 30, 2012, at 10:46 AM, Matt Miller wrote:

> I think there might still need to be some explicitness on what name to =
expect to match on regardless of where the certificate is found, =
especially with multi-domain XMPP servers (e.g. a server =
"im.shakespeare.lit" that services domains "capulet.shakespeare.lit" and =
"denmark.shakespeare.lit").

Yes.

> Maybe that doesn't need to be its own document. =20

Are you serious!?!?! After the amount of confusing and disagreement we =
have seen in the past few months on this topic, a stand-alone document =
that can be referred to easily is exactly what we need.

> I am working on a proposal for improving XMPP federation, and a =
section in that document might be sufficient...Probably (-:

I'm skeptical, to say the least.

--Paul Hoffman


From mamille2@cisco.com  Mon Apr 30 11:52: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 0150921F88E5; Mon, 30 Apr 2012 11:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.479
X-Spam-Level: 
X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Enw+76H7Y2Tq; Mon, 30 Apr 2012 11:52:52 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE5D21F8476; Mon, 30 Apr 2012 11:52:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=5717; q=dns/txt; s=iport; t=1335811972; x=1337021572; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=BnspdV8hLc24MYyPNQQgMtTe4eVX3FUp1+aOWkmDExo=; b=YPEf0rTvFeyHmzpgX+R8a0cjuRk7f5vX/+nLcrZb6dnvMGdE5gmThW32 Pp8n3rtKyHJSl1MkAHyeU8yXlHsKgbLEiVtBHMpowf+/EVcGbrayxQSPk QElLiiA/z7VpUAzbCc88p0NaIoNGzHH+VxXAnR5XP0OGMHJcjwFM/0x/T Y=;
X-Files: smime.p7s, PGP.sig : 2214, 535
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAPXenk+rRDoI/2dsb2JhbABEr1ODAIEHggkBAQEDARIBZgULIyMLAlUGEyKHZgQBmkGgApA/YwSIZIYThweOWYFpgwc
X-IronPort-AV: E=Sophos;i="4.75,505,1330905600";  d="sig'?p7s'?scan'208";a="42745738"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 30 Apr 2012 18:52:52 +0000
Received: from dhcp-64-101-72-220.cisco.com (dhcp-64-101-72-220.cisco.com [64.101.72.220]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3UIqpDh029149; Mon, 30 Apr 2012 18:52:51 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-81-1022493794"
From: Matt Miller 
In-Reply-To: <7584CC56-4202-45B5-81CD-BF77872D61D1@vpnc.org>
Date: Mon, 30 Apr 2012 12:52:59 -0600
Message-Id: <708C6B7F-A6E7-4DF5-9A77-7718791B7CE6@cisco.com>
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com>  <201204300316.q3U3GFcF002018@new.toad.com>  <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com>  <7CBBA998-7681-4885-A5E9-387F32DCE990@cisco.com> <7584CC56-4202-45B5-81CD-BF77872D61D1@vpnc.org>
To: Paul Hoffman 
Content-Transfer-Encoding: 7bit
X-Pgp-Agent: GPGMail 1.3.3
X-Mailer: Apple Mail (2.1084)
Cc: XMPP Working Group , "apps-discuss@ietf.org Discuss" , IETF DANE WG list 
Subject: [apps-discuss] Documenting DANE for XMPP (WAS: [dane] AppsDir review of draft-ietf-dane-protocol-19)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 18:52:53 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-81-1022493794
Content-Type: multipart/signed; boundary=Apple-Mail-80-1022493784; protocol="application/pkcs7-signature"; micalg=sha1


--Apple-Mail-80-1022493784
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Apr 30, 2012, at 12:37, Paul Hoffman wrote:

> On Apr 30, 2012, at 10:46 AM, Matt Miller wrote:
>=20
>> I think there might still need to be some explicitness on what name =
to expect to match on regardless of where the certificate is found, =
especially with multi-domain XMPP servers (e.g. a server =
"im.shakespeare.lit" that services domains "capulet.shakespeare.lit" and =
"denmark.shakespeare.lit").
>=20
> Yes.
>=20
>> Maybe that doesn't need to be its own document. =20
>=20
> Are you serious!?!?! After the amount of confusing and disagreement we =
have seen in the past few months on this topic, a stand-alone document =
that can be referred to easily is exactly what we need.
>=20

The preference of having a single document came from the XMPP WG.  I =
personally am not sure it's the best idea, but I also don't have =
anything written up yet.  I'm more than willing to fight hard to =
separate, but I also need to see what it looks like with the rest of =
XMPP federation stuff.

>> I am working on a proposal for improving XMPP federation, and a =
section in that document might be sufficient...Probably (-:
>=20
> I'm skeptical, to say the least.

I did say "might" and "probably" (-:


- m&m

Matt Miller - 
Cisco Systems, Inc.


--Apple-Mail-80-1022493784
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw
ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x
MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt
YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd
/kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk
cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO
7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV
jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv
NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC
AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo
dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE
AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB
hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN
BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+
SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9
N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT
xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx
s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B
PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2
FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc
/6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg
b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph
p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD
VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo
b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg
ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQzMDE4NTI1
OVowIwYJKoZIhvcNAQkEMRYEFKYtQhbUbQq6VO9BjRW4o7U+td2dMIGRBgkrBgEEAYI3EAQxgYMw
gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw
IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0
QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD
QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p
bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq
hkiG9w0BAQEFAASCAQBZGZTwnJyeiCvy128Fhymh/a1dXYE0WsyKMgQDMbJJzOhqHPWT9fQDFNN9
uohWmQT+9SgKhgvlqcpT0siUmqjGd/uNGEk0b+wJLQXsI/uKLxqQBZn9E/rsPVNMdX36jcOley4m
bSOHhDby3Gf9nUWu5RqClnR392iLZbtfqS0dx6mekIW+1leNCjBhDsrJjH2PLMY4NxXj2Sh1E/Nr
Crpnn7OItQ6TsK5MBsk5IhbKXhaXye2Lh/QDJNHrLLeE8kdR7xli9MDDlje8V7GhyjOUqoh079ef
nZEBKJfGfd96TE7BV8K96aG1dkBNNFk9q5fJ2z7r7qhVII+lkiWqIoIhAAAAAAAA

--Apple-Mail-80-1022493784--

--Apple-Mail-81-1022493794
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJPnt+LAAoJEJq6Ou0cgrSP31gH/iDRqgPeVdEKhIPCTpMweHxF
XtNVctZbkegNAO0ZkXlcFvjIJF1BXkBrSAXFPpsMawAmoQ7cmwQlaJP/kWscN7m5
IU57kdFBa4EkGYvW1SMd4zdbsuR/BAu2NryxaQRXWkoLhdaTJGN2+DksID5LFG8Z
WJJvIAJ/GmIZI3s24/qBDYWtfAgT7REcogHzHcJbjdg86B/Cl08VOAIe5sNDfPWk
HV4QBxdCCBCLnl3q0aGIYcOLZ4nOPHO0AudykZfBhfg4YhGctlrRcgXR8C7AVlc/
DkvKaT49AJo3c6G6j+4JhzcX4XEtHJIEL4H+xQxdNzZzWsWZIStB0MRrTyhocBk=
=rOzu
-----END PGP SIGNATURE-----

--Apple-Mail-81-1022493794--

From dave@cridland.net  Mon Apr 30 12:56:29 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D5521F8702; Mon, 30 Apr 2012 12:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level: 
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBYIdwPkctme; Mon, 30 Apr 2012 12:56:29 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id D719C21F8691; Mon, 30 Apr 2012 12:56:28 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id B066B116808F; Mon, 30 Apr 2012 20:56:22 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuQUhqcIfGQV; Mon, 30 Apr 2012 20:56:19 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 1EB81116808D; Mon, 30 Apr 2012 20:56:19 +0100 (BST)
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com>  <201204300316.q3U3GFcF002018@new.toad.com>  <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> 
In-Reply-To: 
MIME-Version: 1.0
Message-Id: <327.1335815779.111245@puncture>
Date: Mon, 30 Apr 2012 20:56:19 +0100
From: Dave Cridland 
To: James Cloos , General discussion of application-layer protocols ,  The IESG , "dane@ietf.org" 
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 19:56:29 -0000

On Mon Apr 30 18:15:12 2012, James Cloos wrote:
> Each dns lookup needs to dnsec-verify, of course, but the  
> association
> is provable (to the extent that *anything* crypto can be /proven/).

One of the rather jolly things posited by those in the XMPP community  
looking at DANE and similar was that one might solve what's quite a  
tricky problem for larger XMPP services - that of maintaining a cert  
for every domain they host.

For some services (Google is oft-cited here) this is vast numbers,  
and I recall one XSF meeting (in San Diego) where the problems of TLS  
in such an environment where discussed at length.

DANE/TLSA currently makes this more complex by requiring secure name  
redirections throughout the chain; unfortunately, whilst this does  
indeed work in theory, it also provides limited benefit.

In particular, it adds little more than using a perfectly ordinary  
certificate with the server's hostname in does - plus you need to  
ensure that the certificate either contains the right domain/XMPP  
SANs, or else you've used Usage 2/3 TLSA (AKA "Please ignore your PKI  
policy").

Unfortunately, this only works to authenticate the called server -  
the caller cannot use DANE/TLSA to authenticate itself, instead it  
still must present a certificate which identifies itself as the  
domain.

Now one could, I suppose, present a certificate which matched a host,  
and then the callee could perform SRV on the asserted domain, and try  
each record in turn until it found a combination where the hostname  
of the SRV matched a hostname present in the certificate.

This is, as far as I can tell, secure, although exhaustively  
searching just fills me with horror, and this doesn't use TLSA yet -  
including *that* in the mix is even more fun, since it requires a  
TLSA record fetch per SRV record returned - and all the time we're  
effectively ignoring the port. I feel sure there's something nasty  
lurking there, although I can't think what.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From fanf2@hermes.cam.ac.uk  Mon Apr 30 13:28: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 4F27221E8090; Mon, 30 Apr 2012 13:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.472
X-Spam-Level: 
X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4h2UhLlX2SVn; Mon, 30 Apr 2012 13:28:06 -0700 (PDT)
Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2C41421E804E; Mon, 30 Apr 2012 13:28:05 -0700 (PDT)
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-2.csi.cam.ac.uk ([131.111.8.54]:60055) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1SOxCW-0007R8-pt (Exim 4.72) (return-path ); Mon, 30 Apr 2012 21:28:04 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SOxCW-0001fm-2O (Exim 4.67) (return-path ); Mon, 30 Apr 2012 21:28:04 +0100
Date: Mon, 30 Apr 2012 21:28:04 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Dave Cridland 
In-Reply-To: <327.1335815779.111245@puncture>
Message-ID: 
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com>  <201204300316.q3U3GFcF002018@new.toad.com>  <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com>  <327.1335815779.111245@puncture>
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 , "dane@ietf.org" 
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 20:28:07 -0000

Dave Cridland  wrote:
>
> DANE/TLSA currently makes this more complex by requiring secure name
> redirections throughout the chain; unfortunately, whilst this does indeed work
> in theory, it also provides limited benefit.
>
> In particular, it adds little more than using a perfectly ordinary certificate
> with the server's hostname in does - plus you need to ensure that the
> certificate either contains the right domain/XMPP SANs, or else you've used
> Usage 2/3 TLSA (AKA "Please ignore your PKI policy").

Would it make sense to define an alternative virtual-hosting-friendly
authentication scheme that relies on DNSSEC and matches the cert against
the hostname instead of the server domain?

I think something along those lines will be required for SMTP so that
clients know they can expect a valid server certificate.

> Unfortunately, this only works to authenticate the called server - the caller
> cannot use DANE/TLSA to authenticate itself, instead it still must present a
> certificate which identifies itself as the domain.
>
> Now one could, I suppose, present a certificate which matched a host, and then
> the callee could perform SRV on the asserted domain, and try each record in
> turn until it found a combination where the hostname of the SRV matched a
> hostname present in the certificate.
>
> This is, as far as I can tell, secure, although exhaustively searching just
> fills me with horror, and this doesn't use TLSA yet - including *that* in the
> mix is even more fun, since it requires a TLSA record fetch per SRV record
> returned - and all the time we're effectively ignoring the port. I feel sure
> there's something nasty lurking there, although I can't think what.

Surely it isn't that bad: client presents certificate and asserts a
domain; server concurrently looks up SRV of domain and TLSA of all the
host names in the certificate; server checks that at least one SRV target
host name appears in the certificate and has a TLSA that matches. The
"exhausive" search is not much of a search and is not at all taxing, and
you can recommend that deployments arrange that there is one name in the
certificate to minimize the TLSA lookup cost.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Viking, North Utsire, South Utsire: Variable 3 or 4, becoming northerly 5
later in North Utsire. Slight, occasionally moderate. Fog patches developing.
Moderate or good, occasionally very poor.

From ned.freed@mrochek.com  Mon Apr 30 13:43: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 A5AF521E809E; Mon, 30 Apr 2012 13:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Level: 
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTFb3VP3Ac2s; Mon, 30 Apr 2012 13:43:36 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 09A2621E8019; Mon, 30 Apr 2012 13:43:36 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEXJW7XW74000S3A@mauve.mrochek.com>; Mon, 30 Apr 2012 13:43:27 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Mon, 30 Apr 2012 13:43:21 -0700 (PDT)
Message-id: <01OEXJW3QF0G0006TF@mauve.mrochek.com>
Date: Mon, 30 Apr 2012 13:41:32 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 30 Apr 2012 13:02:13 -0400" 
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>  <01OEXB2GEMB20006TF@mauve.mrochek.com> 
To: James Cloos 
Cc: Ned Freed , Mark Andrews , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of	draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 20:43:36 -0000

> >>>>> "NF" == Ned Freed  writes:

> NF> That's incorrect. See my previous post on this topic for specifics.

> I don't see any previous post from you???

> To which list was it posted?

apps-discuss. Id:  <01OEWP11R5NK0006TF@mauve.mrochek.com>

				Ned

From stephen.farrell@cs.tcd.ie  Mon Apr 30 13:50: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 EA1D221F86E0; Mon, 30 Apr 2012 13:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.17
X-Spam-Level: 
X-Spam-Status: No, score=-102.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYGlCC0Qrldj; Mon, 30 Apr 2012 13:50:14 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7A121F86F0; Mon, 30 Apr 2012 13:50:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0B55D1714F1; Mon, 30 Apr 2012 21:50:08 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335819007; bh=VDF80Kei/vfe2A dVDhHczPUO8Y/bQaY2u7S+67hm5SI=; b=FR8vGtMbu3/U1sC94RKntLXKHM4X8X 6uywDXb1MwsLlRTTnZBm2rymxrnm/DJX90uifpUs5Lh5ON8ZQOSEsaWWYx1GPKsx 8W0j1vaT47UqDn2mlfBj6OtTE9omTTMeU7BJAZZLkM7AvNQfunCUSS+v9YP4zwBF EcktYNtB5CS68afRIix1+/LvGuaSFP48eW2f0sLtw2YC0XGnvWX21/c4tL6XieV2 e/ZeM69vk96QGlynJiqzArfUt3M37H3aHuZuMJdbZGaKktxzulT+dPbdi/KwMwOB bhEtLi6blrPBuGm3Tge99NnbLiLvYj4tT8xMH7JovuhY3PKKhLSdxMhA==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id cYROGUcHc9oJ; Mon, 30 Apr 2012 21:50:07 +0100 (IST)
Received: from [10.87.48.9] (unknown [86.46.25.92]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2AE49171476; Mon, 30 Apr 2012 21:50:03 +0100 (IST)
Message-ID: <4F9EFAFB.5050709@cs.tcd.ie>
Date: Mon, 30 Apr 2012 21:50:03 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: Ned Freed 
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>  <01OEXB2GEMB20006TF@mauve.mrochek.com>  <01OEXJW3QF0G0006TF@mauve.mrochek.com>
In-Reply-To: <01OEXJW3QF0G0006TF@mauve.mrochek.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of	draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 20:50:16 -0000

Folks,

I think we may be wandering from the appsdir review of the
DANE draft. If we are, please reduce the cc list to one list,
either apps-discuss (with a different subject probably), or
DANE, or if this is still relevant to the concluded IETF LC
for DANE, then DANE+IESG or ietf@ietf.org is in fact fine.

I intend checking -20 of the DANE draft vs. IETF LC comments
received now and putting it on an IESG telechat if all's well,
so if there remain substantive concerns about progressing
*that document*, you need to make those clear. (For example,
how XMPP uses DANE is not a substantive concern for the DANE
draft IMO, but if you want to, you can make that argument.)
If your mail is about some other thing then please reduce
the cc list and set the subject appropriately.

Thanks,
Stephen.

On 04/30/2012 09:41 PM, Ned Freed wrote:
>>>>>>> "NF" == Ned Freed  writes:
> 
>> NF> That's incorrect. See my previous post on this topic for specifics.
> 
>> I don't see any previous post from you???
> 
>> To which list was it posted?
> 
> apps-discuss. Id:  <01OEWP11R5NK0006TF@mauve.mrochek.com>
> 
> 				Ned
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane

From ned.freed@mrochek.com  Mon Apr 30 15:11: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 4E7D321E80AD; Mon, 30 Apr 2012 15:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level: 
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+5sI8VbUNda; Mon, 30 Apr 2012 15:11:35 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4C621E80A1; Mon, 30 Apr 2012 15:11:33 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEXMZ6W0B4000NG3@mauve.mrochek.com>; Mon, 30 Apr 2012 15:11:22 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Mon, 30 Apr 2012 15:11:16 -0700 (PDT)
Message-id: <01OEXMZ1FWDW0006TF@mauve.mrochek.com>
Date: Mon, 30 Apr 2012 15:07:16 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 30 Apr 2012 21:50:03 +0100" <4F9EFAFB.5050709@cs.tcd.ie>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>  <01OEXB2GEMB20006TF@mauve.mrochek.com>  <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie>
To: Stephen Farrell 
Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review	of	draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 22:11:35 -0000

> I think we may be wandering from the appsdir review of the
> DANE draft. If we are, please reduce the cc list to one list,
> either apps-discuss (with a different subject probably), or
> DANE, or if this is still relevant to the concluded IETF LC
> for DANE, then DANE+IESG or ietf@ietf.org is in fact fine.

I strongly disagree. This is all in response to the apps area review of a DANE
WG document and in that context it is entirely appropriate to be cc'ing both
the apps area list and the dane list. Indeed, if you fail to do so, your
comments will fail to be read by one constituency or another. It is not
reasonable to expect everyone on the apps area list to subscribe to the DANE
list for this or vice versa.

And yes, this means that some folks will get multiple copies. Life is hard
someitmes; deal with it.

				Ned

From stephen.farrell@cs.tcd.ie  Mon Apr 30 15:20: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 694D721E80CD; Mon, 30 Apr 2012 15:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.864
X-Spam-Level: 
X-Spam-Status: No, score=-101.864 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLrdYRi1b6db; Mon, 30 Apr 2012 15:20:46 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B1DD521E80A1; Mon, 30 Apr 2012 15:20:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D7FEB1714F1; Mon, 30 Apr 2012 23:20:43 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335824443; bh=S4ZIVIAUyc0xQ7 7bIS4PF+Qo0UjQMb06Iri85WFwMQc=; b=gySL946DsvxG7E/8E22UFPTXBvgAid Pdzk0THnFRiq4Nq00Ki2po49J0es16Gik2sedAzpuIe74rBWfH/UmpNj34lAEtra U4F3cBb5ppQmo4qIAeMZFuXqj/Nx2iK66sLZuBmodZXCXfTgZ82+U32mBOFy0p0E ZD3OYsG7Ahx/YkuIl3xKnyiA/GzqBtxBaLvfxb0hQMeadarIdYFxiHqRnAfKGkIl AikLT8+wWsgK3PdmQoWr8UytvrtlnBjB+tHDr6G1W4d9I/3px/p+OdGOQ2XeY73s pwG5o+Xi0OckU0fJNtjgCVDQzrk5sw7LgaR9n0SYgOl/v81VIOI0xAsg==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id hCTFJD3WJvbq; Mon, 30 Apr 2012 23:20:43 +0100 (IST)
Received: from [10.87.48.9] (unknown [86.46.25.92]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 630FB171476; Mon, 30 Apr 2012 23:20:41 +0100 (IST)
Message-ID: <4F9F1039.8000402@cs.tcd.ie>
Date: Mon, 30 Apr 2012 23:20:41 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: Ned Freed 
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>  <01OEXB2GEMB20006TF@mauve.mrochek.com>  <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com>
In-Reply-To: <01OEXMZ1FWDW0006TF@mauve.mrochek.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org, Paul Wouters , Paul Hoffman , "apps-discuss@ietf.org" , dane@ietf.org
Subject: Re: [apps-discuss] [dane] AppsDir review	of	draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 22:20:47 -0000

On 04/30/2012 11:07 PM, Ned Freed wrote:
> 
>> I think we may be wandering from the appsdir review of the
>> DANE draft. If we are, please reduce the cc list to one list,
>> either apps-discuss (with a different subject probably), or
>> DANE, or if this is still relevant to the concluded IETF LC
>> for DANE, then DANE+IESG or ietf@ietf.org is in fact fine.
> 
> I strongly disagree. This is all in response to the apps area review of a DANE
> WG document and in that context it is entirely appropriate to be cc'ing both
> the apps area list and the dane list. Indeed, if you fail to do so, your
> comments will fail to be read by one constituency or another. It is not
> reasonable to expect everyone on the apps area list to subscribe to the DANE
> list for this or vice versa.

Fair enough. However, I don't see what potential changes to the
DANE document are being discussed in a bunch of this mail. I do
see people talking about tricky issues with CNAMEs and XMPP
etc. (Changing the subject when appropriate would also be
good.) If people seriously want that kind of text in the DANE
document then they'd presumably start proposing something specific
or else be yelling that DANE needs to be held up for a bit, and
I'm not seeing any of that (in most of the thread).

> And yes, this means that some folks will get multiple copies. Life is hard
> someitmes; deal with it.

Dealing with lots of mail is fine - even I've gotten used to
it:-) Finding the relevant bits of the thread when its wandered
off into how to do XMPP's DNA thing better is harder, hence
my mail.

S.


> 
> 				Ned

From ned.freed@mrochek.com  Mon Apr 30 15:47: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 707AF21E80E4; Mon, 30 Apr 2012 15:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Z6+WNilC24b; Mon, 30 Apr 2012 15:47:10 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id EC82921E80E2; Mon, 30 Apr 2012 15:47:09 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEXO8GJRSG000T76@mauve.mrochek.com>; Mon, 30 Apr 2012 15:47:04 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Mon, 30 Apr 2012 15:46:59 -0700 (PDT)
Message-id: <01OEXO8DBSKY0006TF@mauve.mrochek.com>
Date: Mon, 30 Apr 2012 15:41:57 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 30 Apr 2012 23:20:41 +0100" <4F9F1039.8000402@cs.tcd.ie>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>  <01OEXB2GEMB20006TF@mauve.mrochek.com>  <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie>
To: Stephen Farrell 
Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review	of	draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 22:47:10 -0000

> On 04/30/2012 11:07 PM, Ned Freed wrote:
> >
> >> I think we may be wandering from the appsdir review of the
> >> DANE draft. If we are, please reduce the cc list to one list,
> >> either apps-discuss (with a different subject probably), or
> >> DANE, or if this is still relevant to the concluded IETF LC
> >> for DANE, then DANE+IESG or ietf@ietf.org is in fact fine.
> >
> > I strongly disagree. This is all in response to the apps area review of a DANE
> > WG document and in that context it is entirely appropriate to be cc'ing both
> > the apps area list and the dane list. Indeed, if you fail to do so, your
> > comments will fail to be read by one constituency or another. It is not
> > reasonable to expect everyone on the apps area list to subscribe to the DANE
> > list for this or vice versa.

> Fair enough. However, I don't see what potential changes to the
> DANE document are being discussed in a bunch of this mail. I do
> see people talking about tricky issues with CNAMEs and XMPP
> etc. (Changing the subject when appropriate would also be
> good.) If people seriously want that kind of text in the DANE
> document then they'd presumably start proposing something specific
> or else be yelling that DANE needs to be held up for a bit, and
> I'm not seeing any of that (in most of the thread).

Again, I'm not taking any position on the interaction of TLSA records and
services that use SRV or SRV-like mechanisms. That said, I think most of the
comments are essentially saying that not discussing how TLSA records would
interact with such services at all - even if that discussion is simply to say
that those services need to specify how they are going to use TLSA records - 
is a mistake. And I have to say that is a pretty compelling argument.

> > And yes, this means that some folks will get multiple copies. Life is hard
> > someitmes; deal with it.

> Dealing with lots of mail is fine - even I've gotten used to
> it:-) Finding the relevant bits of the thread when its wandered
> off into how to do XMPP's DNA thing better is harder, hence
> my mail.

Don't you think it might be appropriate to discuss how specific services
actually do this sort of stuff in reaching a decision as to how TLSA records
should work in these contexts?

				Ned

From cloos@jhcloos.com  Mon Apr 30 16:00: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 11E6A21E810C; Mon, 30 Apr 2012 16:00:36 -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.414,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F10R98pwapKX; Mon, 30 Apr 2012 16:00:35 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFF921E810B; Mon, 30 Apr 2012 16:00:35 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 0D0BD40019; Mon, 30 Apr 2012 23:00:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1335826834; bh=Nt41BhkKLmVno2o99PRoswmVJnFPplHRqXLexhGgbMo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=cvGAG44kJQk0xGm+SNB676IAKqvQVLabOKjXDFZzRiquKLGLrCthfMw42YbSKE9CF JHGLMtEPPt1WIAfw2A8DOWE7yvuYC3Owose2Xe1Pn5dT7UO5ju0uqO5oiBHc+JNtHe ZT9yCAXL4TAp1EyUi467IhFfxxVvgoqm2g2P1Pnk=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id C1E5D360048; Mon, 30 Apr 2012 22:36:01 +0000 (UTC)
From: James Cloos 
To: Ned Freed 
In-Reply-To: <01OEXJW3QF0G0006TF@mauve.mrochek.com> (Ned Freed's message of "Mon, 30 Apr 2012 13:41:32 -0700 (PDT)")
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>  <01OEXB2GEMB20006TF@mauve.mrochek.com>  <01OEXJW3QF0G0006TF@mauve.mrochek.com>
User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2012 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Mon, 30 Apr 2012 18:36:01 -0400
Message-ID: 
Lines: 24
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Hashcash: 1:30:120430:ned.freed@mrochek.com::wrAT0vhLRP2UURkk:000000000000000000000000000000000000000h9Bkv
X-Hashcash: 1:30:120430:dane@ietf.org::75n2YagWNEUF1SUe:0005gMAI
X-Hashcash: 1:30:120430:marka@isc.org::jqoUzg6QxVjQZ8SF:000T9DL8
X-Hashcash: 1:30:120430:"apps-discuss\@ietf.org"::CLkq6Ma/vk6TnMPf:000000000000000000000000000000000000Fm2Qy
X-Hashcash: 1:30:120430:apps-discuss@ietf.org::iTJbkBlAa5FfE4Im:000000000000000000000000000000000000000VXqJH
X-Hashcash: 1:30:120430:paul.hoffman@vpnc.org::u9yh2i88AgXOxV1q:000000000000000000000000000000000000000o17nr
X-Hashcash: 1:30:120430:iesg@ietf.org::cjfbOZsC9QjC3goZ:000KfHMB
X-Hashcash: 1:30:120430:paul@nohats.ca::nMEGmj5K/R92y2lW:003RURy
Cc: Mark Andrews , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review of	draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 23:00:36 -0000

>>>>> "NF" == Ned Freed  writes:

NF> apps-discuss. Id:  <01OEWP11R5NK0006TF@mauve.mrochek.com>

Thanks.  I found it in my backup and remember reading (most of) it.

You reference rfc 2181 §10.3 which explains that:

  [MX lookups cause] "additional section processing" in
  which address records associated with the value of the
  record sought are appended to the answer....

And that:

  Additional section processing does not include CNAME records,

That indeed makes pointing an MX RR at a CNAME RR a poor choice.

Thanks.  I'd forgotten to consider additional processing in my
earlier note.

-JimC
-- 
James Cloos          OpenPGP: 1024D/ED7DAEA6

From stephen.farrell@cs.tcd.ie  Mon Apr 30 16:11: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 D51E121E8048; Mon, 30 Apr 2012 16:11:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.806
X-Spam-Level: 
X-Spam-Status: No, score=-101.806 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3bmRm8eocXa; Mon, 30 Apr 2012 16:11:48 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E0F6C21F866D; Mon, 30 Apr 2012 16:11:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5659E1714F2; Tue,  1 May 2012 00:11:47 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335827506; bh=SpTvX22rre+gzp TETaZPtKEzLIsqXYJu98usO0yEqYM=; b=Q1fTp6rOrO0PVDEcjDc3+hA+tQtbZA NkekirDhn7MisHKkkba3eV+svxousmj4aXkNQqHUMtYaL2/dl/m1X+2iVv5oYVoi yPEEmO4jJRxypCXdn7w2orWDMHJ2gztI7s8/NCqfEF5ikoW7b7uTVeGF1313geZy 3CIlrR3P1xslvT/aw3KSb7QssOVex26xHbAwStIuQpoQefTuijg/FePtVTB68xvC URSNDYF1W4ZLK0w31S5Gq3nNtQRgh/B6EO06WirAa8As208SWGNKkgyf/lhU+DVN ggGsmACjZX/hJLpnVQXPVZubSawb3n/arJMS20ruSHwrCQv0cp6kk0MQ==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id i3vmsko36WQ5; Tue,  1 May 2012 00:11:46 +0100 (IST)
Received: from [10.87.48.9] (unknown [86.46.25.92]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1B39B1714F1; Tue,  1 May 2012 00:11:46 +0100 (IST)
Message-ID: <4F9F1C31.50602@cs.tcd.ie>
Date: Tue, 01 May 2012 00:11:45 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0
MIME-Version: 1.0
To: Ned Freed 
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>  <01OEXB2GEMB20006TF@mauve.mrochek.com>  <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com>
In-Reply-To: <01OEXO8DBSKY0006TF@mauve.mrochek.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org, Paul Wouters , Paul Hoffman , "apps-discuss@ietf.org" , dane@ietf.org
Subject: Re: [apps-discuss] [dane] AppsDir review	of	draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 23:11:49 -0000

On 04/30/2012 11:41 PM, Ned Freed wrote:
> 
> 
>> On 04/30/2012 11:07 PM, Ned Freed wrote:
>>>
>>>> I think we may be wandering from the appsdir review of the
>>>> DANE draft. If we are, please reduce the cc list to one list,
>>>> either apps-discuss (with a different subject probably), or
>>>> DANE, or if this is still relevant to the concluded IETF LC
>>>> for DANE, then DANE+IESG or ietf@ietf.org is in fact fine.
>>>
>>> I strongly disagree. This is all in response to the apps area review of a DANE
>>> WG document and in that context it is entirely appropriate to be cc'ing both
>>> the apps area list and the dane list. Indeed, if you fail to do so, your
>>> comments will fail to be read by one constituency or another. It is not
>>> reasonable to expect everyone on the apps area list to subscribe to the DANE
>>> list for this or vice versa.
> 
>> Fair enough. However, I don't see what potential changes to the
>> DANE document are being discussed in a bunch of this mail. I do
>> see people talking about tricky issues with CNAMEs and XMPP
>> etc. (Changing the subject when appropriate would also be
>> good.) If people seriously want that kind of text in the DANE
>> document then they'd presumably start proposing something specific
>> or else be yelling that DANE needs to be held up for a bit, and
>> I'm not seeing any of that (in most of the thread).
> 
> Again, I'm not taking any position on the interaction of TLSA records and
> services that use SRV or SRV-like mechanisms. That said, I think most of the
> comments are essentially saying that not discussing how TLSA records would
> interact with such services at all - even if that discussion is simply to say
> that those services need to specify how they are going to use TLSA records - 
> is a mistake. And I have to say that is a pretty compelling argument.

Could well be. What changes to the text in 1.3 of -20 do you think
are needed if any?

  "            Note that this document does not cover how to associate
   certificates with domain names for application protocols that depend
   on SRV, NAPTR, and similar DNS resource records; it is expected that
   later updates to this document might cover methods for making those
   associations."

The authors and a WG chair figure they've handled the IETF LC
comments already. I need to figure out if they have and this thread
is not helping me at least. (Given that I already know this is a
tricky area.)

>>> And yes, this means that some folks will get multiple copies. Life is hard
>>> someitmes; deal with it.
> 
>> Dealing with lots of mail is fine - even I've gotten used to
>> it:-) Finding the relevant bits of the thread when its wandered
>> off into how to do XMPP's DNA thing better is harder, hence
>> my mail.
> 
> Don't you think it might be appropriate to discuss how specific services
> actually do this sort of stuff in reaching a decision as to how TLSA records
> should work in these contexts?

I do. I'm suggesting that the discussion, while useful in
general, has perhaps wandered and is no longer necessarily
useful for figuring out what this draft needs to say.

S.


> 
> 				Ned

From fanf2@hermes.cam.ac.uk  Mon Apr 30 16:47: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 208CC21E80A8; Mon, 30 Apr 2012 16:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.479
X-Spam-Level: 
X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CBaw+QTyS2M; Mon, 30 Apr 2012 16:47:44 -0700 (PDT)
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 D56D821E8041; Mon, 30 Apr 2012 16:47:43 -0700 (PDT)
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-2.csi.cam.ac.uk ([131.111.8.54]:43404) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SP0JM-0001DV-RQ (Exim 4.72) (return-path ); Tue, 01 May 2012 00:47:20 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SP0JM-0002Qr-Es (Exim 4.67) (return-path ); Tue, 01 May 2012 00:47:20 +0100
Date: Tue, 1 May 2012 00:47:20 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: James Cloos 
In-Reply-To: 
Message-ID: 
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>  <01OEXB2GEMB20006TF@mauve.mrochek.com>  <01OEXJW3QF0G0006TF@mauve.mrochek.com> 
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1870870024-1082916895-1335829640=:17365"
Sender: Tony Finch 
Cc: Ned Freed , Mark Andrews , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir review	of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Apr 2012 23:47:45 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1870870024-1082916895-1335829640=:17365
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE

James Cloos  wrote:
>
> You reference rfc 2181 =A710.3 which explains that:
>
>   [MX lookups cause] "additional section processing" in
>   which address records associated with the value of the
>   record sought are appended to the answer....
>
> And that:
>
>   Additional section processing does not include CNAME records,
>
> That indeed makes pointing an MX RR at a CNAME RR a poor choice.

However an MTA cannot rely on additional section processing because
additional RRsets can be silently omitted - see RFC 1034 section 4.3.2
point 6 and RFC 2181 section 9. So an MTA has to look up any address
records that are missing from the MX answer, which means CNAMEs don't
cause problems unless the MTA makes a special effort to forbid them.

Tony.
--=20
f.anthony.n.finch    http://dotat.at/
Humber, Thames, Dover: Northeast 5 to 7, becoming variable 3 or 4. Moderate=
,
occasionally rough. Thundery rain or showers, fog patches. Moderate or good=
,
occasionally very poor.
--1870870024-1082916895-1335829640=:17365--

From ned.freed@mrochek.com  Mon Apr 30 19:11: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 1C26921F870A; Mon, 30 Apr 2012 19:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level: 
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIKAE21-UAV0; Mon, 30 Apr 2012 19:11:40 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD8521F8705; Mon, 30 Apr 2012 19:11:40 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEXVD10R1S000OJX@mauve.mrochek.com>; Mon, 30 Apr 2012 19:11:35 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Mon, 30 Apr 2012 19:11:30 -0700 (PDT)
Message-id: <01OEXVCY097U0006TF@mauve.mrochek.com>
Date: Mon, 30 Apr 2012 18:52:50 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 01 May 2012 00:11:45 +0100" <4F9F1C31.50602@cs.tcd.ie>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>  <01OEXB2GEMB20006TF@mauve.mrochek.com>  <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie>
To: Stephen Farrell 
Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir	review	of	draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 01 May 2012 02:11:41 -0000

> > Again, I'm not taking any position on the interaction of TLSA records and
> > services that use SRV or SRV-like mechanisms. That said, I think most of the
> > comments are essentially saying that not discussing how TLSA records would
> > interact with such services at all - even if that discussion is simply to say
> > that those services need to specify how they are going to use TLSA records -
> > is a mistake. And I have to say that is a pretty compelling argument.

> Could well be. What changes to the text in 1.3 of -20 do you think
> are needed if any?

>   "            Note that this document does not cover how to associate
>    certificates with domain names for application protocols that depend
>    on SRV, NAPTR, and similar DNS resource records; it is expected that
>    later updates to this document might cover methods for making those
>    associations."

Well, to be blunt, I think that by trying to avoid solving the problem now
while not giving up control over future solutions this ends up being
unacceptable to everyone. 

What if a service comes along that uses SRV records and wants to specify how
TLSA records are used to secure them? According to this text, it can't - the
clear implication here is that this has to be done by revising the DANE
specification itself.

And what about existing services like email where it is arguably the case that
simply using TLSA records to secure the A/AAAA targets MX records is
sufficient? A very short "secure email transport" specification could
be writte that refers to the DANE specification, but this would also seem
to forbid that.

I would much rather see a note that simply refers to future specification work
being needed, not specifically to a DANE revision being needed.

But even this may not be acceptable for all I know. It may turn out that using
DANE to secure the terminal A/AAAA records (modulo CNAMEs) is actually an
acceptable default for SRV/MX/NATPR-based services. I could easily be wrong,
but it seems to me that this is what all this additional discussion is about.

				Ned

From stpeter@stpeter.im  Mon Apr 30 19:17: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 EAF8821E80CD; Mon, 30 Apr 2012 19:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03X8RkeCnelA; Mon, 30 Apr 2012 19:17:00 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D9C5521E80C5; Mon, 30 Apr 2012 19:17:00 -0700 (PDT)
Received: from [107.16.139.250] (unknown [209.116.57.2]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 620BC40058; Mon, 30 Apr 2012 20:31:53 -0600 (MDT)
Message-ID: <4F9F479A.10501@stpeter.im>
Date: Mon, 30 Apr 2012 19:16:58 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Ned Freed 
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>  <01OEXB2GEMB20006TF@mauve.mrochek.com>  <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com>
In-Reply-To: <01OEXVCY097U0006TF@mauve.mrochek.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane] AppsDir	review	of	draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 01 May 2012 02:17:02 -0000

On 4/30/12 6:52 PM, Ned Freed wrote:
> 
>>> Again, I'm not taking any position on the interaction of TLSA records and
>>> services that use SRV or SRV-like mechanisms. That said, I think most of the
>>> comments are essentially saying that not discussing how TLSA records would
>>> interact with such services at all - even if that discussion is simply to say
>>> that those services need to specify how they are going to use TLSA records -
>>> is a mistake. And I have to say that is a pretty compelling argument.
> 
>> Could well be. What changes to the text in 1.3 of -20 do you think
>> are needed if any?
> 
>>   "            Note that this document does not cover how to associate
>>    certificates with domain names for application protocols that depend
>>    on SRV, NAPTR, and similar DNS resource records; it is expected that
>>    later updates to this document might cover methods for making those
>>    associations."
> 
> Well, to be blunt, I think that by trying to avoid solving the problem now
> while not giving up control over future solutions this ends up being
> unacceptable to everyone. 
> 
> What if a service comes along that uses SRV records and wants to specify how
> TLSA records are used to secure them? According to this text, it can't - the
> clear implication here is that this has to be done by revising the DANE
> specification itself.
> 
> And what about existing services like email where it is arguably the case that
> simply using TLSA records to secure the A/AAAA targets MX records is
> sufficient? A very short "secure email transport" specification could
> be writte that refers to the DANE specification, but this would also seem
> to forbid that.
> 
> I would much rather see a note that simply refers to future specification work
> being needed, not specifically to a DANE revision being needed.

I had the same concern but then I realized that "later updates to this
document might cover methods for making those associations" could be
construed as referring to add-on documents that would officially update
the DANE-RFC-to-be, not as saying that such changes would need to be
made in the single DANEbis document that would cover all possible uses
of the TLSA RR.

Peter

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



From James.H.Manger@team.telstra.com  Mon Apr 30 19: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 1B96B21E80F3 for ; Mon, 30 Apr 2012 19:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.532
X-Spam-Level: 
X-Spam-Status: No, score=0.532 tagged_above=-999 required=5 tests=[AWL=-1.167,  BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4yy7a1UVDh8 for ; Mon, 30 Apr 2012 19:17:42 -0700 (PDT)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9B52421E80C5 for ; Mon, 30 Apr 2012 19:17:41 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,508,1330866000"; d="scan'208";a="76968564"
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 01 May 2012 12:17:40 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6697"; a="9367219"
Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcani.tcif.telstra.com.au with ESMTP; 01 May 2012 12:17:40 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Tue, 1 May 2012 12:17:40 +1000
From: "Manger, James H" 
To: Stephen Farrell , Ari Keranen , Apps Discuss 
Date: Tue, 1 May 2012 12:17:37 +1000
Thread-Topic: CRC vs check digit in draft-farrell-decade-ni
Thread-Index: Ac0myevxKiYXzeWPQCafdSTEA9q9nQAcYu9A
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com> <4F9E8055.1080209@cs.tcd.ie>
In-Reply-To: <4F9E8055.1080209@cs.tcd.ie>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [apps-discuss] CRC vs check digit in draft-farrell-decade-ni
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 01 May 2012 02:17:44 -0000

A check digit would be more appropriate than an CRC for the human-readable =
format in "Naming Things with Hashes" . The draft =
currently has an optional 16-bit CRC, represented with 4 hex digits. CRCs a=
re really designed for detecting bit errors (or bursts of bit errors). Chec=
k digits, on the other hand, are designed to detect human errors (changing =
digits, transposing digits etc). 1 or 2 check digits are sufficient, instea=
d of 4 chars for a 16-bit CRC.

Most check digit algorithms work on decimal digits. This draft needs one fo=
r a string or at least for hex digits. Perhaps the Luhn mod N algorithm wou=
ld be suitable ? Using N=
=3D16 and calculating the checksum over just the hex digits of the hash sho=
uld work well. Such a checksum doesn't "protect" the algorithm name, but it=
 doesn't need to as there are only a handful of valid values anyway. Such a=
 checksum would also ignore the case of hex digits. It doesn't change if yo=
u switch from an alg name to id (eg "sha-256-120" to "3").

P.S. The examples in draft 05 all look correct now.

--
James Manger

From paul.hoffman@vpnc.org  Mon Apr 30 19:30: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 00D9921E80BE; Mon, 30 Apr 2012 19:30:53 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4yCNV9Hzx4J; Mon, 30 Apr 2012 19:30:52 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5A98421E80BA; Mon, 30 Apr 2012 19:30:52 -0700 (PDT)
Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q412UoU9029360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Apr 2012 19:30:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman 
In-Reply-To: <4F9F479A.10501@stpeter.im>
Date: Mon, 30 Apr 2012 19:30:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BD409C0-F932-4198-B98F-55295AA56B93@vpnc.org>
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>  <01OEXB2GEMB20006TF@mauve.mrochek.com>  <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> <4F9F479A.10501@stpeter.im>
To: Ned Freed 
X-Mailer: Apple Mail (2.1257)
Cc: "iesg@ietf.org IESG" , "apps-discuss@ietf.org Discuss" , IETF DANE WG list 
Subject: Re: [apps-discuss] [dane] AppsDir	review	of	draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 01 May 2012 02:30:53 -0000

On Apr 30, 2012, at 7:16 PM, Peter Saint-Andre wrote:

> On 4/30/12 6:52 PM, Ned Freed wrote:
>>=20
>>>> Again, I'm not taking any position on the interaction of TLSA =
records and
>>>> services that use SRV or SRV-like mechanisms. That said, I think =
most of the
>>>> comments are essentially saying that not discussing how TLSA =
records would
>>>> interact with such services at all - even if that discussion is =
simply to say
>>>> that those services need to specify how they are going to use TLSA =
records -
>>>> is a mistake. And I have to say that is a pretty compelling =
argument.
>>=20
>>> Could well be. What changes to the text in 1.3 of -20 do you think
>>> are needed if any?
>>=20
>>>  "            Note that this document does not cover how to =
associate
>>>   certificates with domain names for application protocols that =
depend
>>>   on SRV, NAPTR, and similar DNS resource records; it is expected =
that
>>>   later updates to this document might cover methods for making =
those
>>>   associations."
>>=20
>> Well, to be blunt, I think that by trying to avoid solving the =
problem now
>> while not giving up control over future solutions this ends up being
>> unacceptable to everyone.=20
>>=20
>> What if a service comes along that uses SRV records and wants to =
specify how
>> TLSA records are used to secure them? According to this text, it =
can't - the
>> clear implication here is that this has to be done by revising the =
DANE
>> specification itself.
>>=20
>> And what about existing services like email where it is arguably the =
case that
>> simply using TLSA records to secure the A/AAAA targets MX records is
>> sufficient? A very short "secure email transport" specification could
>> be writte that refers to the DANE specification, but this would also =
seem
>> to forbid that.
>>=20
>> I would much rather see a note that simply refers to future =
specification work
>> being needed, not specifically to a DANE revision being needed.
>=20
> I had the same concern but then I realized that "later updates to this
> document might cover methods for making those associations" could be
> construed as referring to add-on documents that would officially =
update
> the DANE-RFC-to-be, not as saying that such changes would need to be
> made in the single DANEbis document that would cover all possible uses
> of the TLSA RR.


Peter's interpretation is certainly the one we intended: that is why I =
used "updates" not "replacements" in the sentence quoted above.

Ned: if you have a better wording for the sentence, I strongly suspect =
the WG would be happy with such a clarification.

--Paul Hoffman


From stpeter@stpeter.im  Mon Apr 30 19:44: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 8101B21E8144; Mon, 30 Apr 2012 19:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NicXfsc6+TBG; Mon, 30 Apr 2012 19:44:01 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 372E021E80BA; Mon, 30 Apr 2012 19:44:01 -0700 (PDT)
Received: from [107.16.139.250] (unknown [209.116.57.2]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F2A8440058; Mon, 30 Apr 2012 20:58:53 -0600 (MDT)
Message-ID: <4F9F4DEE.1090309@stpeter.im>
Date: Mon, 30 Apr 2012 19:43:58 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "apps-discuss@ietf.org" , dane@ietf.org,  iesg@ietf.org
References: <4F95CA0B.8050202@stpeter.im>
In-Reply-To: <4F95CA0B.8050202@stpeter.im>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 01 May 2012 02:44:02 -0000

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

I've reviewed version -20. Herewith a bit of follow-up.

On 4/23/12 2:30 PM, Peter Saint-Andre wrote:
> This is a supplemental AppsDir review of draft-ietf-dane-protocol 
> (for background on AppsDir, please see 
> ).
>
>
> 
Although Murray Kucherawy has already reviewed this I-D on behalf of
> the AppsDir, folks in the Applications Area realize that wide 
> deployment of the TLSA Resource Record might have a significant 
> impact on applications, so we are performing additional reviews. 
> Please treat these comments just as you would any other Last Call 
> feedback.
> 
> Document: draft-ietf-dane-protocol Title: "The DNS-Based 
> Authentication of Named Entities (DANE) Protocol for Transport 
> Layer Security (TLS)" Reviewer: Peter Saint-Andre Review Date: 
> 2012-04-23 IETF Last Call Date: 2012-04-25 IESG Telechat: not yet 
> scheduled
> 
> Summary: This draft is almost ready for publication as an Standards
> Track RFC but has a few issues that should be fixed before
> publication.
> 
> Major Issue:
> 
> This document does not mention that TLSA records cannot be used 
> directly in application protocols that depend on SRV (or NAPTR or 
> similar technologies). Although I realize that the DANE WG decided,
> after much discussion, that the interaction between TLSA records
> and SRV records is out of scope for this specification (and I do
> not mean to reopen that discussion now), it would be very helpful
> for this specification to reflect the results of that discussion.
> Although I make specific suggestions regarding text under the Minor
> Issues below, in general I think this document needs to be clearer
> about the assumptions it has made in this regard; in fact, it seems
> to me that an explicit applicability statement is warranted to
> avoid confusion of the kind that Dave Cridland experienced (see his
> Last Call comments). Absent such an applicability statement, it
> would be good to state up front something that currently is not
> made explicit until the first sentence of the Security
> Considerations:
> 
> The security of the DNS RRtype described in this document relies on
> the security of DNSSEC as used by the client requesting A/AAAA and
> TLSA records.
> 
> The import of "and" in that sentence is significant, and needs to 
> be highlighted earlier in the specification.

The new text in Section 1.3 addresses my concern.

> Minor Issues:
> 
> 1. In Section 1.2, these sentences might involve a slight 
> oversimplication:
> 
> A TLS client begins a connection by exchanging messages with a TLS
>  server.  It looks up the server's name using the DNS to get an 
> Internet Protocol (IP) address associated with the name.  It then 
> begins a connection to a client-chosen port at that address, and 
> sends an initial message there.
> 
> 1a. The second sentence might be construed as requiring only one 
> step (look up the name, get an IP address), whereas we know that 
> sometimes multiple steps are involved (think SRV). I'd be more 
> comfortable if we added a clause at the end along the lines of 
> "sometimes via multiple steps".
> 
> 1b. The term "client-chosen port" makes it sound as if the client 
> can choose any port it pleases when connecting to the TLS server. 
> Yet typically the port is derived from a URI, "hardcoded" into the
>  application protocol (sometimes as a fallback), or discovered via 
> the DNS (again, think SRV). We needn't reflect those alternatives 
> in the text, but at the least "appropriate" is better than 
> "client-chosen".

The change from "client-chosen port" to "client-define port" is
mystifying to me. Even assuming that "client-defined" was meant, it's
not clear to me what a client-defined port is, and I see no effective
difference between the old text and the new text.

> 2. In Section 1.3, it is said that "This document only applies to 
> PKIX [RFC5280] certificates, not certificates of other formats." 
> Does this mean that a new RR type would need to be defined to 
> handle other formats (e.g., PGP as in RFC 6091), or only that 
> documents defining how to use TLSA records with those other
> formats would need to define new values for the Certificate Usage
> field? Please clarify.

The new text reads:

   This document only applies to PKIX [RFC5280] certificates, not
   certificates of other formats.  Later updates to this document might
   specify how to use certificates in other formats.

That doesn't make it clear what would be needed to specify how to use
certificates in other formats (new RR type or new values for the
Certificate Usage field?). I still think it would be better to make
that clear so folks who update this document in the future know what
to do.

> 3. In Section 1.3, the following paragraph is true only for 
> application protocols that do not make use of SRV or similar 
> technologies:
> 
> This document defines a secure method to associate the certificate
>  that is obtained from the TLS server with a domain name using DNS;
>  the DNS information needs to be be protected by DNSSEC.  Because 
> the certificate association was retrieved based on a DNS query, the
> domain name in the query is by definition associated with the 
> certificate.
> 
> For example, in the case of XMPP the application client might 
> discover through a DNS SRV lookup that the XMPP service for 
> example.com is actually provided at im.example.net. In this case, 
> the domain name in the certificate presented by the TLS server 
> (im.example.net) is not the same as the certificate discovered via 
> the DNS TLSA lookup (example.com), so we can't simply stipulate 
> that "the domain name in the query is by definition associated
> with the certificate". Here again that applicability statement
> would be helpful, because this document assumes that you're
> connecting to the IP address that you discover by means of DNS
> A/AAAA lookup on the domain name contained in the prefixed DNS
> domain name defined in Section 3. (As noted, this is made explicit
> in the first sentence of the Security Considerations.)

This is OK, per the new statement in Section 1.3.

> 4. In Section 2.2, the term "whitespace" is underspecified. Does 
> that include, say, any Unicode space separator (Unicode General 
> Category Zs) or also line separators (Unicode General Category Zl) 
> or only certain code points in the ASCII range? Further, is the 
> whitespace significant in the examples from Section 2.3?

I see no change in -20 to clarify this matter.

> 5. To those of us accustomed to SRV records, at first glance the 
> prefixed DNS domain name format defined in Section 3 looks strange:
> why not _http._tcp.www.example.com instead of 
> _443._tcp.www.example.com? But when we take off our SRV-colored 
> glasses and realize that DANE assumes a DNS A/AAAA lookup on the 
> domain name, it all makes sense. Perhaps it would be helpful to 
> mention the reasoning behind the port number (instead of 
> application name) here?

This is OK to me now.

> 6. In section 4, no mention is made of the application service that
> the TLS expects to encounter at the TLS server:
> 
> The TLS session that is to be set up MUST be for the specific port
>  number and transport name that was given in the TLSA query.
> 
> Yet surely the application protocol can matter here, no? In 
> particular, given that 443 is the one true port, we know that folks
> might run non-HTTP applications over that port (for evil reasons,
> of course). Does DANE elide over the application protocol because
> we simply assume that the "right" service is being served over any
> particular port? What about service providers that wish to restrict
> the usage of a certificate to a particular application service type
> (cf. RFC 6125)? Or do we assume that it is enough to differentiate
> among application services based on the underlying transport (as
> seems to be the case in the text on "Multiple Ports" in Section 5)?
> IMHO we have a bit of a muddle here.

Paul explained this in a previous message. I think it's OK.

> 7. The paragraph about SSL proxies in Section 8 says that "the TLS
>  client will get a certificate association from the DNS that will 
> not match the certificate that the SSL proxy uses with the client";
> however, if the SSL proxy is working in concert with an external
> DNS validator, is it possible to mimic the behavior of current SSL
> proxies?

As Paul pointed out, the behavior of SSL proxies is undefined in any
spec, and it's not the job of this spec to define them. OK with me.

> Nits:
> 
> 1. In Section 1.1, I suggest changing "using encryption" to "using
>  channel encryption" (since TLS uses connection-oriented encryption
>  methods, not object encryption).

Done, thanks.

> 2. Section 1.1, uses the term "subdomain" in the sentence "This 
> prevents an untrustworthy signer from compromising anyone's keys 
> except those in their own subdomains." The term "subdomain" is not
>  always well understood. I suggest explicitly citing Section 3.1
> of RFC 1034 here.

Unchanged, but it's probably OK as-is.

> 3. In Section 1.3, the phrase "the domain name where the data is 
> found" makes it sound as if DANE applies only to application 
> protocols that involve data retrieval, whereas we know it can be 
> used also for technologies that involve communication (email, IM, 
> etc.). I suggest "the domain name for the relevant application 
> service" or somesuch.

The modified text looks good to me ("the domain name where the server
application runs").

> 4. In Section 1.3, I suggest changing "server" (which might be 
> confused with the TLS server itself) to "service" or "application 
> service" in this sentence: "A DNS query can return multiple 
> certificate associations, such as in the case of a server is 
> changing from one certificate to another."

Unchanged, but I think that's OK.

In a follow-up email message, I also noted:

###

One more issue is nagging at me: there is no definition or citation
for "domain name" in Section 3. In particular, there is no indication
of whether internationalized domain names are allowed (and, if so, in
what format). I think it would good to make this clear by saying that
a domain name can be either a "traditional domain name" (RFC 1034) or
an "internationalized domain name" (RFC 5890); for the latter I think
it would be best to say that the IDN's internationalized labels are
represented only as A-labels. IMHO a short paragraph on this matter
would be appropriate in Section 3 or in a new section entitled
"Internationalization Considerations".

###

I still think that this document needs to say something about IDNs.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+fTe4ACgkQNL8k5A2w/vyJiACgpyfjFCeKpB2KWq9KN01MKl91
sYcAoJcpNcbenV3yvknbhi14vWNy1T49
=iPW1
-----END PGP SIGNATURE-----

From msk@cloudmark.com  Mon Apr 30 19:55: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 58B4F21E814D for ; Mon, 30 Apr 2012 19:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.628
X-Spam-Level: 
X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hO-6wP5Lz4Oy for ; Mon, 30 Apr 2012 19:55:44 -0700 (PDT)
Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id BDF9821E814B for ; Mon, 30 Apr 2012 19:55:44 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 4SvT1j0010as01C01SvTHj; Mon, 30 Apr 2012 19:55:33 -0700
X-CMAE-Match: 0
X-CMAE-Score: 0.00
X-CMAE-Analysis: v=2.0 cv=T7IOvo2Q c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=Pip2rxCYUeAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=gZYdKlMGs4HJI1Aa6poA:9 a=YStEGMaWOOYe8RdfCE0A:7 a=CjuIK1q_8ugA:10 a=_RhRFcbxBZMA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Mon, 30 Apr 2012 19:55:27 -0700
From: "Murray S. Kucherawy" 
To: Julian Reschke 
Thread-Topic: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec
Thread-Index: Ac0l10W9SlaETdSSRZWdVKRKL9SkswBVntWAAAXqgAA=
Date: Tue, 1 May 2012 02:55:27 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com>
References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de>
In-Reply-To: <4F9EC5BD.7000404@gmx.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [67.160.203.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335840933; bh=S6mz8zB+L5fF8JFr5cKqQHi3fE6efDPpk2WspI3Et7E=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=oEU1SIO0XhaUJ+SBofypfUFvFr8d5+tbyO6ZSIbXG1p9ie0zphde5s6yf/In5MTtB CWR+f5G+Es15hPm4j+oh2fhghijiHJTHmG69fzvxDCr/YUsrG9anxumpVUYTJuJOsm 0nLMiMmET9svLAQaXCIPYp1IInv8lNwK3mEDAGdA=
Cc: "draft-ietf-websec-strict-transport-sec@tools.ietf.org" , "websec@ietf.org" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] [websec] AppsDir review of draft-ietf-websec-strict-transport-sec
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 01 May 2012 02:55:45 -0000

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Monday, April 30, 2012 10:03 AM
> To: Murray S. Kucherawy
> Cc: apps-discuss@ietf.org; websec@ietf.org; draft-ietf-websec-strict-tran=
sport-sec@tools.ietf.org
> Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transpor=
t-sec
>=20
> On 2012-04-29 09:11, Murray S. Kucherawy wrote:
>  > ...
> > Section 6.1.1: I think the "delta-seconds" should be:
> >
> > delta-seconds =3D 1*DIGIT
> >
> > ; defined in Section 3.3.2 of [RFC2616] ...
>=20
> That would copy the rule from RFC 2616 "by value".

Why not just say "delta-seconds is defined in Section 3.3.2 of [RFC2616]" a=
nd leave out the restatement of the ABNF?  Then it's truly only specified i=
n one place.

> > The angle-bracket notation you have there doesn't seem to be normal.
> > ...
>=20
> It's a prose rule; see RFC 5234 prose-val. It's used here to define the
> ABNF rule "by reference".

RFC5234 also says it should be used as a "last resort".  This is such a sim=
ple definition that it doesn't seem to qualify.

-MSK


From ned.freed@mrochek.com  Mon Apr 30 23:34: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 0E48821F86B4; Mon, 30 Apr 2012 23:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.492
X-Spam-Level: 
X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwtc91ZqC13c; Mon, 30 Apr 2012 23:34:45 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C3BA521F85E1; Mon, 30 Apr 2012 23:34:45 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEY4K8KHJK000UX2@mauve.mrochek.com>; Mon, 30 Apr 2012 23:34:41 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Mon, 30 Apr 2012 23:34:38 -0700 (PDT)
Message-id: <01OEY4K69WQE0006TF@mauve.mrochek.com>
Date: Mon, 30 Apr 2012 23:30:42 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 30 Apr 2012 19:16:58 -0700" <4F9F479A.10501@stpeter.im>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org>  <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se>  <01OEXB2GEMB20006TF@mauve.mrochek.com>  <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> <4F9F479A.10501@stpeter.im>
To: Peter Saint-Andre 
Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters 
Subject: Re: [apps-discuss] [dane]	AppsDir	review	of	draft-ietf-dane-protocol-19
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 01 May 2012 06:34:47 -0000

> On 4/30/12 6:52 PM, Ned Freed wrote:
> >
> >>> Again, I'm not taking any position on the interaction of TLSA records and
> >>> services that use SRV or SRV-like mechanisms. That said, I think most of the
> >>> comments are essentially saying that not discussing how TLSA records would
> >>> interact with such services at all - even if that discussion is simply to say
> >>> that those services need to specify how they are going to use TLSA records -
> >>> is a mistake. And I have to say that is a pretty compelling argument.
> >
> >> Could well be. What changes to the text in 1.3 of -20 do you think
> >> are needed if any?
> >
> >>   "            Note that this document does not cover how to associate
> >>    certificates with domain names for application protocols that depend
> >>    on SRV, NAPTR, and similar DNS resource records; it is expected that
> >>    later updates to this document might cover methods for making those
> >>    associations."
> >
> > Well, to be blunt, I think that by trying to avoid solving the problem now
> > while not giving up control over future solutions this ends up being
> > unacceptable to everyone.
> >
> > What if a service comes along that uses SRV records and wants to specify how
> > TLSA records are used to secure them? According to this text, it can't - the
> > clear implication here is that this has to be done by revising the DANE
> > specification itself.
> >
> > And what about existing services like email where it is arguably the case that
> > simply using TLSA records to secure the A/AAAA targets MX records is
> > sufficient? A very short "secure email transport" specification could
> > be writte that refers to the DANE specification, but this would also seem
> > to forbid that.
> >
> > I would much rather see a note that simply refers to future specification work
> > being needed, not specifically to a DANE revision being needed.

> I had the same concern but then I realized that "later updates to this
> document might cover methods for making those associations" could be
> construed as referring to add-on documents that would officially update
> the DANE-RFC-to-be, not as saying that such changes would need to be
> made in the single DANEbis document that would cover all possible uses
> of the TLSA RR.

That doesn't fix the problem. Anything that says "updates RFC FOO" is
effectively the same as a DANEbis spec. What I want is for other specification
to be able define how to use TLSA records to secure protocols that use more
elaborate DNS record mechanisms *without* having to update DANE.

				Ned

On 2012-04-23, at 3:09 PM, Bob =
Wyman wrote:



On Mon, Apr 23, 2012 at 12:19 PM, John Bradley =
<ve7jtb@ve7jtb.com> wrote:


I understand that in some =
environments you may not have access to http rewrite rules. =
 
Others may preclude any scripts.

We =
do have to decide what environments we are going to support.



If we stick to static files only then we are just =
putting some lipstick on Yadis by adding a way to map a email like =
address to a file.

So yes there are those =
environments, but that needs to be balanced against the additional =
overhead on the clients to support that environment.



Yes, of course. We must seek a =
balance. What have I missed in the following attempt to balance the =
proposals?

If we adopt a solution that can't be =
implemented with static files, then:


  • Positive: Clients which seek only one or two bits of =
specific information may experience less "overhead."
  • Negative: =
Clients that seek all or many bits of available information would =
experience more overhead.
    • 

  • Negative: Many sites that could otherwise provide WebFinger support =
will not be able to. 
I guess the question is: =
"How should we weight the positive against the negatives?" Personally, I =
would suggest that the negatives outweigh (out-balances?) the positive. =
I believe that is why, for the many years that WebFinger has been under =
discussion, that the majority of discussions have assumed that static =
files would be sufficient.



bob wyman
 

John B.



On 2012-04-23, at 12:26 PM, Bob =
Wyman wrote:



On Mon, Apr 23, =
2012 at 11:08 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:




Mike,

I think =
there is less resistance to making resource parameter REQUIRED than =
there is to removing the initial host-meta lookup to get the =
template.





We should probably keep those issues =
separate.

I agree that supporting indirect =
discovery of the template via host-meta.jason should probably =
stay.

The question is if their can be an =
optimization that allows shortcutting that step if you know that all you =
want is web finger.




A possible option for that could be using a fixed =
template in /.well-known/.

That endpoint would =
return:



a The terminal JRD =
(like SWD)
b=
 a 3xx redirect to the real =
endpoint
Causing a 3xx redirect =
typically requires modification to the configuration files of a =
multi-host shared web server. Access to such configuration files is =
often restricted in such a way that those responsible from just one or a =
few of the sites sharing the common server are not permitted to make =
modifications to those files. In many cases, such modifications can be =
requested and will only be made after lengthy delays or the payment of =
support and maintenance fees. 




If we want this sort of discovery to become =
generally available, and not just be limited to the "large" sites, we =
should ensure that it is as simple as possible to =
deploy.
 



c a copy of the =
host-meta.jrd

We would probably only do =
one of b or c.

c has the advantage of being a =
static file and you being no worse off than having started with =
host-meta.json.



b is the simplest for the client and only requires common rewriting =
rules.

If the redirect is to the same host you =
could avoid the overhead of two connections by pipelining the requests =
over the same TCP connection.



SPDY in the future will make that even more =
efficient.

I will grant Blaine that most openID =
Connect discovery requests are Server to Server,  However there are =
Apps that are also clients that should not be ignored.



I personally like the fixed template with a 3xx redirect and =
 resource parameter returning a JRD due to the simplicity of client =
coding.

Things needing other sorts of =
information about the host would still use host-meta or =
host-meta.json.




John =
B.


On =
2012-04-23, at 1:11 AM, Mike Jones =
wrote:




I agree with your goal of simplicity for clients.  Paul=92s =
example seems about as simple as it can get for =
clients:





It shares the property with your earlier example (below) that clients =
have a no-branches code path to do discovery:



            =
;   curl -s http://example.com/.well-known/host-meta|<=
/u>



            =
;   awk "/lrdd/,/template/"|tr -d '\n'|sed -e =
"s/^.*template=3D'\([^']*\)'.*$/\1/"|



            =
;   sed -e "s/{uri}/user@example.com/"|xargs curl =
=96s



 



However, I challenge the assumption in your note below that servers =
using only static pages must be =
supported.  I just don=92t see the requirement to implement a query parameter as =
being an impediment in practice, even for hosted domains.  I know =
of no hosting company that doesn=92t provide a means of putting =
executable code behind web pages, be it PHP, Perl, Ruby, ASP, JSP, =
etc.  I know you=92re trying to make the case for static pages, but =
in practice, I believe that dynamic pages are always easily =
available.



 



Assuming that we=92re in an either-or situation with regard to either =
having single-GET discovery or supporting discovery using only static =
server pages (and I=92d love to have someone demonstrate to us that =
we=92re not), I=92d take single-GET discovery for sure, as in some =
cases, it makes an appreciable difference in user interface latency, and =
per the paragraph above, I believe that dynamic queries can be =
implemented on all hosting platforms.



 



Assuming the WebFinger authors agree, I=92d suggest that a logical =
next step would be for a -04 version of draft-jones-appsawg-webfinger to =
be published that changes support for the resource parameter from =
RECOMMENDED to REQUIRED, as that could provide a starting point for a =
common discovery spec.



 



            =
;            &=
nbsp;           &nb=
sp;            =
;           -- =
Mike



 



P.S.  As long as draft-jones-appsawg-webfinger is being revised, =
I=92d also suggest adding text making explicit what has been an implicit =
assumption in both WebFinger and SWD - that depending upon whether and =
how the client is authenticated, the set of resources returned may vary =
(as Blaine had pointed out earlier).  That could help deal with =
some of the privacy perceptions.



 



From: =
apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Blaine Cook


Sent: Sunday, April 22, 2012 2:15 =
PM
To: apps-discuss@ietf.org
Subject: =
[apps-discuss] Webfinger / SWD Issue #3: direct versus indirect =
discovery



 


This is the last issue that I've flagged as blocking a new Webfinger / =
SWD draft.


 
Mike suggested =
that being able to request a user's profile with a single request (i.e., =
that the /.well-known/ profile resource should be able to respond with =
full profile data immediately, rather than pointing at a second URL that =
will fulfil the request) is a requirement for this =
standard.



 


I'd like to challenge that requirement. The arguments for a direct =
discovery endpoint are:


 
1. Fewer =
requests against the server, since we save (in the worst-case) 50% of =
requests by bypassing the indirect lookup phase.



2. Lower =
latency for clients (e.g., mobile clients) owing to the reduced number =
of lookups.



 


The arguments for an indirect discovery endpoint =
are:


 
1. Trivial and =
web-standards friendly deployment for domains that won't host their own =
webfinger/swd profile servers, but want to enable accounts on their =
domains (e.g., statically hosted sites).



2. A loosening =
of the requirement that URLs at the bare domain must run dynamic scripts =
that respond to requests to the /.well-known/ path.



 


My opinion is that the approach that SWD has proposed for the redirect =
is problematic. First, the format is very similar in form to the HTML =
"meta refresh" tag that provided HTTP redirect support from within HTML. =
That format has been widely deprecated, and in these more enlightened =
times, we just use the 3xx response codes with Location headers, =
instead.



 


Secondly, the SWD request format means that for smaller sites, often =
those with the least resources, will end up serving static content in a =
way that's difficult to cache; certainly, more difficult to cache than =
just serving static content. This is due to the request parameters =
present in all SWD requests; those request parameters will bust =
caches.



 


As for the first argument *for* SWD's approach, I'd suggest we look to =
DNS, which uses the same indirection approach for NS records, relying on =
a (relatively) very small set of root servers to handle the traffic for =
the whole internet. Clearly, this approach works, and webfinger/swd =
servers are in a much better position to handle this additional traffic. =
Most of this traffic will be heavily cached, especially for the largest =
providers.



 


In fact, in terms of real deployments, hosting a script at, =
e.g., google.com/.well-known/simple-web-discovery&nb=
sp;is much harder than hosting a script atprofiles.google.com/profile.json f=
or all sorts of reasons, so it's my belief that the first argument is a =
red herring.



 


The second argument is legitimate, but only if mobile clients will =
actually be making requests to diverse webfinger/swd hosts. Instead, I =
strongly believe that we'll see the emergence of DNS-like servers that =
provide both profile hosting as well as proxy services. For a mobile =
client, the optimal approach will be to use SPDY to connect to a single =
host that performs webfinger/swd lookups on the mobile client's behalf, =
eliminating the latency concerns.



 


I offer that the two-step lookup can be implemented without conditionals =
on the client, whereas the direct-unless-not approach cannot be =
implemented that way (see my earlier curl example for proof). It's =
simpler, and easier to explain to the (hopefully many) small site owners =
who we'd like to implement this technology.



 


Thoughts? Am I missing something?
 



b.
_______________=
________________________________


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



=







On =
2012-04-23, at 12:26 PM, Bob Wyman wrote:



On Mon, Apr 23, =
2012 at 11:08 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:


Mike,

I think =
there is less resistance to making resource parameter REQUIRED than =
there is to removing the initial host-meta lookup to get the =
template.



We should probably keep those issues =
separate.

I agree that supporting indirect =
discovery of the template via host-meta.jason should probably =
stay.

The question is if their can be an =
optimization that allows shortcutting that step if you know that all you =
want is web finger.



A possible option for that could be using a fixed =
template in /.well-known/.

That endpoint would =
return:


a The terminal JRD =
(like SWD)
b=
 a 3xx redirect to the real =
endpoint
Causing a 3xx redirect =
typically requires modification to the configuration files of a =
multi-host shared web server. Access to such configuration files is =
often restricted in such a way that those responsible from just one or a =
few of the sites sharing the common server are not permitted to make =
modifications to those files. In many cases, such modifications can be =
requested and will only be made after lengthy delays or the payment of =
support and maintenance fees. 



If we want this sort of discovery to become =
generally available, and not just be limited to the "large" sites, we =
should ensure that it is as simple as possible to =
deploy.
 


c a copy of the =
host-meta.jrd

We would probably only do =
one of b or c.

c has the advantage of being a =
static file and you being no worse off than having started with =
host-meta.json.


b is the simplest for the client and only requires common rewriting =
rules.

If the redirect is to the same host you =
could avoid the overhead of two connections by pipelining the requests =
over the same TCP connection.


SPDY in the future will make that even more =
efficient.

I will grant Blaine that most openID =
Connect discovery requests are Server to Server,  However there are =
Apps that are also clients that should not be ignored.


I personally like the fixed template with a 3xx redirect and =
 resource parameter returning a JRD due to the simplicity of client =
coding.

Things needing other sorts of =
information about the host would still use host-meta or =
host-meta.json.



John =
B.


On 2012-04-23, at 1:11 AM, Mike Jones =
wrote:



I agree with your goal of simplicity for clients.  Paul=92s =
example seems about as simple as it can get for =
clients:



It shares the property with your earlier example (below) that clients =
have a no-branches code path to do discovery:


            =
;   curl -s http://example.com/.well-known/host-meta|<=
/u>


            =
;   awk "/lrdd/,/template/"|tr -d '\n'|sed -e =
"s/^.*template=3D'\([^']*\)'.*$/\1/"|


            =
;   sed -e "s/{uri}/user@example.com/"|xargs curl =
=96s


 


However, I challenge the assumption in your note below that servers =
using only static pages must be =
supported.  I just don=92t see the requirement to implement a query parameter as =
being an impediment in practice, even for hosted domains.  I know =
of no hosting company that doesn=92t provide a means of putting =
executable code behind web pages, be it PHP, Perl, Ruby, ASP, JSP, =
etc.  I know you=92re trying to make the case for static pages, but =
in practice, I believe that dynamic pages are always easily =
available.


 


Assuming that we=92re in an either-or situation with regard to either =
having single-GET discovery or supporting discovery using only static =
server pages (and I=92d love to have someone demonstrate to us that =
we=92re not), I=92d take single-GET discovery for sure, as in some =
cases, it makes an appreciable difference in user interface latency, and =
per the paragraph above, I believe that dynamic queries can be =
implemented on all hosting platforms.


 


Assuming the WebFinger authors agree, I=92d suggest that a logical =
next step would be for a -04 version of draft-jones-appsawg-webfinger to =
be published that changes support for the resource parameter from =
RECOMMENDED to REQUIRED, as that could provide a starting point for a =
common discovery spec.


 


            =
;            &=
nbsp;           &nb=
sp;            =
;           -- =
Mike


 


P.S.  As long as draft-jones-appsawg-webfinger is being revised, =
I=92d also suggest adding text making explicit what has been an implicit =
assumption in both WebFinger and SWD - that depending upon whether and =
how the client is authenticated, the set of resources returned may vary =
(as Blaine had pointed out earlier).  That could help deal with =
some of the privacy perceptions.


 


From: =
apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Blaine Cook

Sent: Sunday, April 22, 2012 2:15 =
PM
To: apps-discuss@ietf.org
Subject: =
[apps-discuss] Webfinger / SWD Issue #3: direct versus indirect =
discovery


 

This is the last issue that I've flagged as blocking a new Webfinger / =
SWD draft.

 
Mike suggested =
that being able to request a user's profile with a single request (i.e., =
that the /.well-known/ profile resource should be able to respond with =
full profile data immediately, rather than pointing at a second URL that =
will fulfil the request) is a requirement for this =
standard.


 

I'd like to challenge that requirement. The arguments for a direct =
discovery endpoint are:

 
1. Fewer =
requests against the server, since we save (in the worst-case) 50% of =
requests by bypassing the indirect lookup phase.


2. Lower =
latency for clients (e.g., mobile clients) owing to the reduced number =
of lookups.


 

The arguments for an indirect discovery endpoint =
are:

 
1. Trivial and =
web-standards friendly deployment for domains that won't host their own =
webfinger/swd profile servers, but want to enable accounts on their =
domains (e.g., statically hosted sites).


2. A loosening =
of the requirement that URLs at the bare domain must run dynamic scripts =
that respond to requests to the /.well-known/ path.


 

My opinion is that the approach that SWD has proposed for the redirect =
is problematic. First, the format is very similar in form to the HTML =
"meta refresh" tag that provided HTTP redirect support from within HTML. =
That format has been widely deprecated, and in these more enlightened =
times, we just use the 3xx response codes with Location headers, =
instead.


 

Secondly, the SWD request format means that for smaller sites, often =
those with the least resources, will end up serving static content in a =
way that's difficult to cache; certainly, more difficult to cache than =
just serving static content. This is due to the request parameters =
present in all SWD requests; those request parameters will bust =
caches.


 

As for the first argument *for* SWD's approach, I'd suggest we look to =
DNS, which uses the same indirection approach for NS records, relying on =
a (relatively) very small set of root servers to handle the traffic for =
the whole internet. Clearly, this approach works, and webfinger/swd =
servers are in a much better position to handle this additional traffic. =
Most of this traffic will be heavily cached, especially for the largest =
providers.


 

In fact, in terms of real deployments, hosting a script at, =
e.g., google.com/.well-known/simple-web-discovery&nb=
sp;is much harder than hosting a script atprofiles.google.com/profile.json f=
or all sorts of reasons, so it's my belief that the first argument is a =
red herring.


 

The second argument is legitimate, but only if mobile clients will =
actually be making requests to diverse webfinger/swd hosts. Instead, I =
strongly believe that we'll see the emergence of DNS-like servers that =
provide both profile hosting as well as proxy services. For a mobile =
client, the optimal approach will be to use SPDY to connect to a single =
host that performs webfinger/swd lookups on the mobile client's behalf, =
eliminating the latency concerns.


 

I offer that the two-step lookup can be implemented without conditionals =
on the client, whereas the direct-unless-not approach cannot be =
implemented that way (see my earlier curl example for proof). It's =
simpler, and easier to explain to the (hopefully many) small site owners =
who we'd like to implement this technology.


 

Thoughts? Am I missing something?
 


b.
_______________________________________________

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





Pelle,
 
My own implementation also accepts queries that to not include =
“acct:”.  See:
https://packetizer.com/.well-known/host-meta.json?reso=
urce=3Dpaulej@packetizer.com
 
I will return “acct:paulej@packetizer.com” as an =
alias.
 
The reason this was done was because Blaine (he’s quite =
influential) was arguing for a while that we did not need to use a =
URI.  After some time, I think there was convergence on use of =
“acct”.  In any case, I don’t think we should =
look to existing implementations as the way to do it.  We need to =
decide on one approach and put that into the =
spec.
 
The “mailto” URI may certainly return something, just as =
any other URI might.  However, if we’re making a reference to =
a user’s account, we should use “acct” and not =
“mailto”.  As noted on the list before, some services =
may not offer email, yet the user has an account (e.g., Twitter).  =
One’s email address (or set of addresses) can always be returned =
as data when querying a user account.
 
That said, you do present a very interesting use case. =
 I’m surprised a domain would allow two different users to =
have a name like pelle@flattr.com, where the meaning is truly =
differentiated only by the URI scheme.  That must be a source of =
confusion and it’s not clear how WebFinger could sort that =
out.  My personal opinion is that one should not tell the average =
user to use mailto: or acct:, as the average user will not understand =
it; they should not have to understand it.  I’m not sure what =
to suggest in this case.
 
Paul
 
From:=
 =
Pelle Wessman [mailto:pelle@kodfabrik.se] 
Sent: Thursday, =
April 19, 2012 2:53 AM
To: Paul E. Jones
Cc: 'Melvin =
Carvalho'; 'Apps Discuss'
Subject: Re: [apps-discuss] =
[OAUTH-WG] Web Finger vs. Simple Web Discovery =
(SWD)
 
While =
WebFinger officially requires an "acct" URI I believe almost =
all current implementers accept a "pelle@kodfabrik.se" URI as =
being the same as "acct:pelle@kodfabrik.se". Gmail.com does, StatusNet/Identi.ca does, =
we at Flattr does. So there is a discrepancy between the WebFinger =
specification and real life implementations.
 
Examples:
 
http:=
//www.google.com/s2/webfinger/?q=3Dvoxpelli@gmail.com
<=
/div>
=

 
Also, speaking from a Flattr-perspective, mail =
addresses and user accounts are _not_ the same thing in our system. I =
myself have the e-mail pelle@flattr.com but I have the web =
site account voxpelli@flattr.com and the web =
site account pelle@flattr.com =
doesn't belong to me but to one of our users. I believe most web sites, =
at least the smaller ones, works like this - that the e-mail system and =
the web system is completely separated from each other and that the user =
identifiers in one can conflict with the identifiers in the =
other.
 
I =
would say that a lookup for "mailto:pelle@flattr.com" =
should return info about the user behind that e-mail address (if it =
should return anything) but that a lookup for "pelle@flattr.com" or =
"acct:pelle@flattr.com" should always return data about the =
web site user and that clients should be encouraged to use =
"acct:" to make it clear that they want the web site's user, =
but that they shouldn't be required to do =
so.
 
/ =
Pelle
 
 
19 =
apr 2012 kl. 00:03 skrev Paul E. Jones:


Melvin,
 
WebFinger does discovery on any URI.  It might be =
“http”, “mailto”, “ftp”, or =
“acct”.  So, it’s not entirely correct to say =
that WebFinger does not do discovery using email addresses.  I =
could change my server code pretty easily to accommodate =
mailto.
 
Use of mailto was something discussed at length.  As others =
pointed out, it was not necessarily favored by all, but it was =
recognized to be insufficient for some situations.  Most =
importantly, nobody other than us geeks knows =
what the heck a “mailto” is.  But, we do recognize that =
social sites like Twitter have accounts.  Thus, after the lengthy =
debate that took place in several places, it was decided to go with =
“acct”.  It actually does have a useful purpose.  =
And its construction is made to look similar to “mailto” so =
that the a user would just enter what they consider to be an =
“email” address, including things we know are not like user@twitter.com.  Using =
“mailto” is technically incorrect, but users never have to =
know or care about that.  Behind the scenes, we use =
“acct”.  I would personally never show an end user =
“acct:paulej@packetizer.com”.  Rather, I would just =
tell people that their account ID is “paulej@packetizer.com”.&n=
bsp; That may or may not be their address.  Query a Twitter account =
and it might return an email address that differs (if Twitter were to =
share that info).
 
Paul
 
From:=
 Melvin =
Carvalho [mailto:melvincarvalho@=
gmail.com] 
Sent: Wednesday, April 18, 2012 =
6:05 AM
To: Paul E. =
Jones
Cc: Mike =
Jones; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] =
Web Finger vs. Simple Web Discovery =
(SWD)
 
 
On 18 April 2012 01:59, Paul E. Jones <paulej@packetizer.com> =
wrote:
Melvin,
 
On “acct:”…
 
Humans will usually interchange an acct URI and mailto URI, probably =
never using either scheme directly in practice.  That’s =
natural and expected, if not desired.  The intent is that we define =
something that looks like an email ID, but it’s not an email =
ID.  Some services, perhaps Twitter being most notable, do no use =
email addresses.  Yet, you might have an account there.  =
So, user@twitter.com might be used by humans and =
automated systems would convert that to acct:user@twitter.com.  It would not be =
appropriate to use mailto: since it’s not an email =
ID.
 
We did have a lot of debate about the use of =
“acct”.  If you query my WebFinger server, you’ll =
see that it will work without “acct:” prefixed, as that was =
a suggestion made a year or so ago.  It will inspect the input and =
if it looks like an acct URI, it will assume it is.  The =
“acct” URI will be returned as an alias.  However, we =
should always use some kind of URI scheme to remove the guesswork.  =
The client can often make a very good guess as to whether it’s =
looking for a user account or something else.  So, let it tell the =
server what it is looking for =
explicitly.
 
We need a URI scheme, because WebFinger can be used to discover all =
kinds of information related to a given domain, not only user =
information.  It can be used to query information about any URI, be =
that a web page, a user account, device on the network, etc.  If we =
got rid of “acct”, then we would have a system where we =
sometimes use a URI scheme and sometimes we do not.  Results might =
be inconsistent, as the server may not make the right guess, unless we =
agreed that absence of a scheme defaults to “acct:”.  =
However, I see no reason for the client to be so lazy to not include =
“acct:”.  The user might (and probably will) exclude =
it, but the client code can add it.
 
At this point, I’d argue the “train has left the =
station” on “acct”, too.  The current WebFinger =
spec exists (in part) to formally document that which has adopted; =
it’s not a new =
thing.


Paul, thank you for your explanation on lookup =
based on acct: (WebFinger) vs lookup based on mailto: (SWD).

I =
think this is a major difference.

The original WebFinger proposal =
was *supposed* to give extra information about an email =
address.

From wikipedia:

"WebFinger is an Internet protocol that =
aims to provide information about people by their E-mail =
addresses."

From webfinger.org:

"Put your email address into the box above, click the =
button"

From google code (the top hit on =
google):

"making email addresses readable =
again"

And perhaps most importantly from the spec, =
the first example:

"Assume you =
receive an email from =
Bob..."

However only SWD here is doing email based =
discovery (mailto:).  WebFinger *now* doing =
acct: based discovery, which is a departure from the original use =
case.  

Im =
glad that some people have voiced support for acct:, but I still believe =
that to be a minority.  I agree, that the new acct: scheme should =
for in another document, rather than shoe horned into an email based =
discovery system.  

IMHO, it's better to =
solve one problem (ie email based discovery) simply and well, than to =
half solve two problems (ie a new uri scheme for identity) in a single =
attempt.  
 
 
Paul
 
A couple of points:

1. =
JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the time webfinger was =
created in 2009, XML was the de facto serialization, used in AJAX, SOAP =
and many other systems.  Today I'm hearing more and more, that both =
developers and publishers, want to work with JSON, rather than, having =
to support both xml and json.  Content negotiation also confuses =
some publishers.  In my view, this is a great simplification that =
webfinger can learn from SWD.

2. acct: =
scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The acct: URI =
scheme has not proved popular, imho, and has added a layer of complexity =
and confusion.  How do we get from acct: to mailto:?  When =
should you use acct: and when mailto: (the spec says acct:user@host may =
be different from mailto:user@host).  What about the forms.  How =
about linked data ecosystems that want to cross link identifiers, do =
they now have to consider both cases?  

From the original =
post introducing acct:

"I don’t expect everyone to =
like this idea. I wish I could say I love it, but I am simply content =
with it."

I dont know of anyone in the community (and =
correct me if this has changed) that really loves acct:, or perhaps even =
likes the acct: idea.  SWD has shown you can do discovery without =
acct: and I think that's a big plus.




One final side =
note is that this almost becomes trivial when you can do SPARQL =
queries.  "void" is already registered by the W3C with =
IANA in .well-known in order to discover SPARQL endpoints.  It may =
be overkill in some people's eyes, but Linked Data (which predates =
webfinger), particularly newer things like JSON LD, are a lot bigger =
than they were in 2009.  In a few years it may become the =
definitive discovery mechanism =
anyway.
 
_______________________________________________
apps=
-discuss mailing list
apps-discuss@ietf.org
https://www.i=
etf.org/mailman/listinfo/apps-discuss
 

------=_NextPart_000_080E_01CD1E36.1BEA9C80--


From Michael.Jones@microsoft.com  Thu Apr 19 11:23: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 1ECEA21F8653; Thu, 19 Apr 2012 11:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Gx9DMhiO3H0; Thu, 19 Apr 2012 11:23:00 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id DC93A21F863F; Thu, 19 Apr 2012 11:22:59 -0700 (PDT)
Received: from mail125-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 18:22:59 +0000
Received: from mail125-ch1 (localhost [127.0.0.1])	by mail125-ch1-R.bigfish.com (Postfix) with ESMTP id 43A3F1E0202; Thu, 19 Apr 2012 18:22:59 +0000 (UTC)
X-SpamScore: -30
X-BigFish: VS-30(zzbb2dI9371I542Mc85dh98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail125-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=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail125-ch1 (localhost.localdomain [127.0.0.1]) by mail125-ch1 (MessageSwitch) id 1334859777484032_21123; Thu, 19 Apr 2012 18:22:57 +0000 (UTC)
Received: from CH1EHSMHS015.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252])	by mail125-ch1.bigfish.com (Postfix) with ESMTP id 66DAF6005B;	Thu, 19 Apr 2012 18:22:57 +0000 (UTC)
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 18:22:56 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Thu, 19 Apr 2012 18:22:46 +0000
From: Mike Jones 
To: John Panzer 
Thread-Topic: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
Thread-Index: AQHNHk5rJwvCScwa5U+4IAklxXbdk5aidjmP
Date: Thu, 19 Apr 2012 18:22:46 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366490C03@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366490C03TK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "oauth@ietf.org WG" , Apps Discuss 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Apr 2012 18:23:01 -0000

--_000_4E1F6AAD24975D4BA5B168042967394366490C03TK5EX14MBXC284r_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I agree that redirects need to be followed, when used.

-- Mike
________________________________
From: John Panzer
Sent: 4/19/2012 7:04 PM
To: Mike Jones
Cc: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery =
(SWD)

On Thu, Apr 19, 2012 at 9:48 AM, Mike Jones > wrote:
There are two criteria that I would consider to be essential requirements f=
or any resulting general-purpose discovery specification:

1.  Being able to always discover per-user information with a single GET (m=
inimizing user interface latency for mobile devices, etc.)

Clarification:  Does this requirement still allow HTTP redirects?  (Meaning=
 the server is in control of whether there is a single GET or not, basicall=
y, but can always ensure a single GET to minimize latency.)


2.  JSON should be required and it should be the only format required (simp=
licity and ease of deployment/adoption)


I think nobody would argue against JSON support (certainly not me), I think=
 few would argue against making it required.  I personally would be okay wi=
th actually standardizing on JSON as the only required format as it doesn't=
 preclude anyone from supporting other formats if they wish (for legacy/etc=
. reasons).

SWD already meets those requirements.  If the resulting spec meets those re=
quirements, it doesn't matter a lot whether we call it WebFinger or Simple =
Web Discovery, but I believe that the requirements discussion is probably t=
he most productive one to be having at this point - not the starting point =
document.

                               -- Mike

-----Original Message-----
From: apps-discuss-bounces@ietf.org [=
mailto:apps-discuss-bounces@ietf.org]=
 On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 19, 2012 9:32 AM
To: oauth@ietf.org WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery =
(SWD)

By all means people should correct me if they think I'm wrong about this, b=
ut so far from monitoring the discussion there seems to be general support =
for focusing on WebFinger and developing it to meet the needs of those who =
have deployed SWD, versus the opposite.

Does anyone want to argue the opposite?

-MSK, appsawg co-chair

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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--_000_4E1F6AAD24975D4BA5B168042967394366490C03TK5EX14MBXC284r_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









I agree that =
redirects need to be followed, when used.



-- Mike







From:
John P=
anzer

Sent:
4/19/2=
012 7:04 PM

To:
Mike J=
ones

Cc:
Murray=
 S. Kucherawy; oauth@ietf.org WG; Apps Discuss

Subject:
Re: [O=
AUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)





On Thu, Apr 19, 2012 at 9:48 AM, Mike Jones 
<Michael.Jones@microsoft.=
com> wrote:



There are two criteria that I would consider to be essential requirements f=
or any resulting general-purpose discovery specification:



1.  Being able to always discover per-user information with a single G=
ET (minimizing user interface latency for mobile devices, etc.)









Clarification:  Does this requirement still allow HTTP redirects?=
  (Meaning the server is in control of whether there is a single GET o=
r not, basically, but can always ensure a single GET to minimize latency.)<=
/div>

 





2.  JSON should be required and it should be the only format required =
(simplicity and ease of deployment/adoption)











I think nobody would argue against JSON support (certainly not me), I =
think few would argue against making it required.  I personally would =
be okay with actually standardizing on JSON as the only required format as =
it doesn't preclude anyone from supporting
 other formats if they wish (for legacy/etc. reasons).


 



SWD already meets those requirements.  If the resulting spec meets tho=
se requirements, it doesn't matter a lot whether we call it WebFinger or Si=
mple Web Discovery, but I believe that the requirements discussion is proba=
bly the most productive one to be having
 at this point - not the starting point document.



                     =
;          -- Mike





-----Original Message-----

From: apps-discuss-bounces=
@ietf.org [mailto:apps=
-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy

Sent: Thursday, April 19, 2012 9:32 AM




To: oauth@ietf.o=
rg WG; Apps Discuss

Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery =
(SWD)








By all means people should correct me if they think I'm w=
rong about this, but so far from monitoring the discussion there seems to b=
e general support for focusing on WebFinger and developing it to meet the n=
eeds of those who have deployed SWD,
 versus the opposite.



Does anyone want to argue the opposite?



-MSK, appsawg co-chair



_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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












_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth
















--_000_4E1F6AAD24975D4BA5B168042967394366490C03TK5EX14MBXC284r_--

From eran@hueniverse.com  Thu Apr 19 11:26: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 DE6DE11E8074; Thu, 19 Apr 2012 11:26:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level: 
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dws1sgesNX7B; Thu, 19 Apr 2012 11:26:36 -0700 (PDT)
Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1060811E8073; Thu, 19 Apr 2012 11:26:36 -0700 (PDT)
Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id zuSb1i00A0CJzpC01uSbCB; Thu, 19 Apr 2012 11:26:35 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Thu, 19 Apr 2012 11:26:35 -0700
From: Eran Hammer 
To: Mike Jones , "Murray S. Kucherawy" , "oauth@ietf.org WG" , Apps Discuss 
Thread-Topic: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple	Web	Discovery (SWD)
Thread-Index: AQHNHkxUamxtxNaeJEOwZxtbGF43j5aidV7Q
Date: Thu, 19 Apr 2012 18:26:34 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FF1C6A@P3PWEX2MB008.ex2.secureserver.net>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [161.163.44.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple	Web	Discovery	(SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Apr 2012 18:26:37 -0000

#1 as John Panzer identified, allowing the server to control its deployment=
 and supporting HTTP redirects is critical.
#2 JSON is better, which one is required is less of on issue but more of a =
best practices item.

I'll add:

* Highly cachable
* Optimize for large providers, reducing the need to make repeated requests=
 when the information is mostly following a template on the server side
* Ability to provide discovery on resources, not users or any other subset =
(emails, etc.)
* Security agnostic - leave it to HTTP, TLS, OAuth, etc.
* HTTP compliant - doesn't invent it's own rediretion menthods or custom he=
aders, etc.

EH

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Mike Jones
> Sent: Thursday, April 19, 2012 9:49 AM
> To: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss
> Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web
> Discovery (SWD)
>=20
> There are two criteria that I would consider to be essential requirements=
 for
> any resulting general-purpose discovery specification:
>=20
> 1.  Being able to always discover per-user information with a single GET
> (minimizing user interface latency for mobile devices, etc.)
>=20
> 2.  JSON should be required and it should be the only format required
> (simplicity and ease of deployment/adoption)
>=20
> SWD already meets those requirements.  If the resulting spec meets those
> requirements, it doesn't matter a lot whether we call it WebFinger or Sim=
ple
> Web Discovery, but I believe that the requirements discussion is probably
> the most productive one to be having at this point - not the starting poi=
nt
> document.
>=20
> 				-- Mike
>=20
> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of Murray S. Kucherawy
> Sent: Thursday, April 19, 2012 9:32 AM
> To: oauth@ietf.org WG; Apps Discuss
> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> Discovery (SWD)
>=20
> By all means people should correct me if they think I'm wrong about this,=
 but
> so far from monitoring the discussion there seems to be general support f=
or
> focusing on WebFinger and developing it to meet the needs of those who
> have deployed SWD, versus the opposite.
>=20
> Does anyone want to argue the opposite?
>=20
> -MSK, appsawg co-chair
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From torsten@lodderstedt.net  Thu Apr 19 11:40: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 EBF7E21F84F3; Thu, 19 Apr 2012 11:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtgXW4v+64LR; Thu, 19 Apr 2012 11:40:05 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6616E21F844C; Thu, 19 Apr 2012 11:40:05 -0700 (PDT)
Received: from [79.253.16.77] (helo=[192.168.71.36]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SKwGx-0000Y9-PP; Thu, 19 Apr 2012 20:40:03 +0200
Message-ID: <4F905C06.6070201@lodderstedt.net>
Date: Thu, 19 Apr 2012 20:40:06 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Mike Jones 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org WG" , Apps Discuss 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web	Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Apr 2012 18:40:06 -0000

Hi Mike,

Am 19.04.2012 18:48, schrieb Mike Jones:
> There are two criteria that I would consider to be essential requirements for any resulting general-purpose discovery specification:
>
> 1.  Being able to always discover per-user information with a single GET (minimizing user interface latency for mobile devices, etc.)

Is this a requirement from an OpenID Connect perspective? I'm asking 
because I think a user is not always the starting point of a discovery 
process in the more general OAuth case. In my opinion there is a need to 
discover
(1) the authorization server a particular resource server relies on 
("www.example.com/webdav" --> "as.example.com" and
(2) the properties of this authz server ("as.example.com" --> tokens, 
authz, revocation endpoints, grant types, ...).

How would this work with SWD or WebFinger?

regards,
Torsten.

From wmills@yahoo-inc.com  Thu Apr 19 11:55:58 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0056411E8085 for ; Thu, 19 Apr 2012 11:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.255
X-Spam-Level: 
X-Spam-Status: No, score=-17.255 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAdJOiylg18f for ; Thu, 19 Apr 2012 11:55:57 -0700 (PDT)
Received: from nm26-vm0.bullet.mail.ac4.yahoo.com (nm26-vm0.bullet.mail.ac4.yahoo.com [98.139.52.242]) by ietfa.amsl.com (Postfix) with SMTP id B9A1711E8072 for ; Thu, 19 Apr 2012 11:55:56 -0700 (PDT)
Received: from [98.139.52.188] by nm26.bullet.mail.ac4.yahoo.com with NNFMP; 19 Apr 2012 18:55:50 -0000
Received: from [98.139.52.161] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 19 Apr 2012 18:55:50 -0000
Received: from [127.0.0.1] by omp1044.mail.ac4.yahoo.com with NNFMP; 19 Apr 2012 18:55:50 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 278052.36031.bm@omp1044.mail.ac4.yahoo.com
Received: (qmail 24111 invoked by uid 60001); 19 Apr 2012 18:55:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334861749; bh=kM/6UgWds2eYKJobrfx+edRY02HFXgThUh9RTV5qZRE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nvXSQvCxH8j8y9anT/Xz5XdMYpqX7kIPOvZvtRl6TkRyDMpW8bDFM7Oy3ecZpVwhVRhz5cji0JrYcI0KBMxEOH+gOP4TdvLOTkHC1ochs/tn5vyxuniXJ7yrEY3Vvo0MRlpS/ec6d8CNCK/JIbFPtJwHfyG/RiBr8rsr9bV2MgM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aUH1DoHjDGIeZ2dMdk8P2MfZX0bF1gb3/S99Bf7v/PT0yRgVPKSceeYbNMe7XqgNvB6fqqjOWzCVDTjlkXTEceFOIdr5h1ysHsnT8PRkHguwQRMYYuSUmWJD7zQw9babGbqJin6FjsrXFmkYcS2ObCSUludQfKhZOnFP662vVIo=;
X-YMail-OSG: Dny0gxAVM1n0Q.9p9fHTpcwCoOLtYpGHoqA3bb2_CRQABjD CfRHstYNJ1XFBm6y30LHvVrgzkAy7a1xQyKNDfC9w0UDqLIzf9t2EJ3ptQWa SZ8Fg2x9cn9zpJiXnhbNY..c5xii7NKN3DZy6wF9LU.QUK0GQCPUzTnXg4vM DHnrGyeDpw0HS394fTWjK61wv2YiY3oeJPER5A5hFJ6kiG7FSoI5aEMLcntC RJ84jdNiQcZm.TP7g2sm8zBKo8lYhi_Dw5Krf1Yz2d22gdWc_33U33EYEu3i MeQKHDbEXSD5CcRKLue9t6ySkOBeKaMZDqxlgRC647JbQqSyGnK.YsF_xaaL 2wfcohi7W51AiQy_gXoVGuhr9DhtdOfaUH20_GJ9qXN6sA.DXC6JpibT56EJ nbeeGEUkBQEw9pbTK5.AgBPh6QpLgVeVFm.S4KoUzOUnLUPVeQXLcWoIe56m 895SBPTaZgByRrPoDwXnwcUqMN5KlJUDwDxMIZes.z7FBeEBBGghaZw--
Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Thu, 19 Apr 2012 11:55:49 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F905C06.6070201@lodderstedt.net>
Message-ID: <1334861749.10526.YahooMailNeo@web31812.mail.mud.yahoo.com>
Date: Thu, 19 Apr 2012 11:55:49 -0700 (PDT)
From: William Mills 
To: Torsten Lodderstedt , Mike Jones 
In-Reply-To: <4F905C06.6070201@lodderstedt.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1458549034-501957834-1334861749=:10526"
Cc: Apps Discuss 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Apr 2012 18:55:58 -0000

--1458549034-501957834-1334861749=:10526
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

My initial proposal for discovering things about endpoints is LINK/rel, and=
 I'll reiterate that I want to see something that can be communicated in-ba=
nd for other than HTTP/S protocols.=0A=0A=0A=0A=0A>________________________=
________=0A> From: Torsten Lodderstedt =0A>To: Mik=
e Jones  =0A>Cc: "oauth@ietf.org WG" ; Apps Discuss  =0A>Sent: Thursday, April 19,=
 2012 11:40 AM=0A>Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Sim=
ple Web Discovery (SWD)=0A> =0A>Hi Mike,=0A>=0A>Am 19.04.2012 18:48, schrie=
b Mike Jones:=0A>> There are two criteria that I would consider to be essen=
tial requirements for any resulting general-purpose discovery specification=
:=0A>> =0A>> 1.=A0 Being able to always discover per-user information with =
a single GET (minimizing user interface latency for mobile devices, etc.)=
=0A>=0A>Is this a requirement from an OpenID Connect perspective? I'm askin=
g because I think a user is not always the starting point of a discovery pr=
ocess in the more general OAuth case. In my opinion there is a need to disc=
over=0A>(1) the authorization server a particular resource server relies on=
 ("www.example.com/webdav" --> "as.example.com" and=0A>(2) the properties o=
f this authz server ("as.example.com" --> tokens, authz, revocation endpoin=
ts, grant types, ...).=0A>=0A>How would this work with SWD or WebFinger?=0A=
>=0A>regards,=0A>Torsten.=0A>______________________________________________=
_=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/l=
istinfo/oauth=0A>=0A>=0A>
--1458549034-501957834-1334861749=:10526
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


My initial proposal for discovering things about endpoints is LINK/rel, a=
nd I'll reiterate that I want to see something that can be communicated in-=
band for other than HTTP/S protocols.

  
 
 
  
  From: Torsten Lodderstedt <torsten@lod=
derstedt.net>
 To: M=
ike Jones <Michael.Jones@microsoft.com> 
Cc: "oauth@ietf.org WG" <oauth@ietf.org>; Apps Dis=
cuss <apps-discuss@ietf.org> 
 Sent: Thursday, April 19, 2012 11:40 AM
 Subject: Re: [OAUTH-WG] [apps-discuss] Web =
Finger vs. Simple Web Discovery (SWD)
  
 
=0AHi Mike,
Am 19.04.2012 18:48, schrieb Mike Jones:
> There are two criteri=
a that I would consider to be essential requirements for any resulting gene=
ral-purpose discovery specification:
> 
> 1.  Being able t=
o always discover per-user information with a single GET (minimizing user i=
nterface latency for mobile devices, etc.)

Is this a requirement fro=
m an OpenID Connect perspective? I'm asking because I think a user is not a=
lways the starting point of a discovery process in the more general OAuth c=
ase. In my opinion there is a need to discover
(1) the authorization ser=
ver a particular resource server relies on ("www.example.com/webdav" --> "as.example.com" and
(2) t=
he properties of this authz server ("as.example.com" --> tokens, authz, =
revocation endpoints, grant types, ...).

How would this
 work with SWD or WebFinger?

regards,
Torsten.
_______________=
________________________________
OAuth mailing list
OAuth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/oauth


 
 
 
   

--1458549034-501957834-1334861749=:10526--

From klensin@jck.com  Thu Apr 19 12:30: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 0DA0121F8667; Thu, 19 Apr 2012 12:30:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.700,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhkklbsDwLHK; Thu, 19 Apr 2012 12:30:02 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id E175221F8663; Thu, 19 Apr 2012 12:30:01 -0700 (PDT)
Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SKwyd-0002pt-BH; Thu, 19 Apr 2012 15:25:11 -0400
Date: Thu, 19 Apr 2012 15:29:56 -0400
From: John C Klensin 
To: ietf@ietf.org
Message-ID: <67E4D4377A5DE7379C951CD6@PST.JCK.COM>
In-Reply-To: <20120418205730.17453.64115.idtracker@ietfa.amsl.com>
References: <20120418205730.17453.64115.idtracker@ietfa.amsl.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Last Call:  (The "about"	URI Scheme) to Proposed Standard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Apr 2012 19:30:03 -0000

--On Wednesday, April 18, 2012 13:57 -0700 The IESG
 wrote:

> 
> The IESG has received a request from the Applications Area
> Working Group WG (appsawg) to consider the following document:
> - 'The "about" URI Scheme'
>    as a Proposed
> Standard
> 
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the ietf@ietf.org mailing lists by
> 2012-05-02. Exceptionally, comments may be sent to
> iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

Hi.

I've expressed more detailed concerns on the WG list or earlier,
but, since those seem to have been in the WG rough, two very
general comments:

(1) It is not clear that this document benefits from a
historical review but, if the authors choose to provide one, it
should be accurate.  For example, the second paragraph of the
Introduction says:

> The concept of "about" URIs formed when applications did not
> have a "friendly" user interface, to enable access to the
> aforementioned resources by typing URIs into an address bar or
> similar feature. 

There were applications with user-friendly interfaces to
configuration long before there were URIs, so certainly the
above statement cannot be true as written.  My recollection is
that "about:" came into being because the development team for a
particular early browser was unwilling or unable (given
resources and other constraints) to spend the time developing
what they would have considered an appropriate UI for options
they did not expect to be used extensively, but that is rather
different.  And, fwiw, that actual history puts the origins of
"about:" into a category that is often described with language
like "quick hack", although that doesn't prevent standardizing
just as other quick hacks of that period have been recognized in
standards when they were shown to have lasting value.

(2) This document is being proposed for Standards Track, but it
is not clear what is being standardized.  Certainly it registers
and reserves the scheme name "about", which I think it a good
idea (and agree with the authors that it is overdue).  But, as a
particularly interesting example, the IANA Template says "see
Section 2.2" for "URI scheme semantics", but Section 2.2 doesn't
actually specify anything.  That is clear from its first couple
of paragraphs which start "Generally speaking..." and "However,
it is impossible to specify a binding...".

Even the special token material is questionable.  Certainly we
recognize "about:blank", but it is not clear from the text that
we really have enough understanding of other things that might
be registered to have any idea whether the specifications for
the new registry and the registration template are adequate.
Perhaps that is the result of trying to generalize from one
case, perhaps it is more broadly symptomatic.  As an example,
the paragraph under the figure in Section 4.2 contains the
interesting phrasing "The registrant of the token ought to
provide...".   Is "ought to" a synonym for SHOULD and, if so,
shouldn't the specification contain guidance for IANA as to when
they are to make a registration entry even when that information
is not provided?  Or does it mean something else entirely and,
if so, what?  I also note that, in general, we ask that
information that is required (or even optional) for registration
go into the registry but this one expects that material to
appear in separate documentation with very little in the
registry itself.  I'm sure there are registries and
registrations out there that provides contact or authority
information only by indirection through other documents
(documents that are not required to be standards track RFCs or
otherwise meeting our requirements for normative references) but
they are rare and, IMO, undesirable.

Recommendation:

Before this specification is adopted as a Proposed Standard, it
should be absolutely clear what is standardized, what is general
advice, and what is just commentary.    Hand waving like "ought
to" should be removed in terms of 2119-style requirements
statements is requirements are intended or clarified
sufficiently to give IANA clear guidance on content and
operation of a registry.  That is especially important for an
FCFS registration spec where, in principle, only IANA evaluates
a request for conformance to the specification before modifying
the registry.

The setup for the token registry reflects the debates about
registration conventions that have waged since this document was
first proposed.  However, it seems to go both ways in that
debate.  On the one hand, it singles out a single keyword,
"blank", for registration.  It indicates that there can be more
but that they should/will be rare.  It does not encourage
registration of other keywords to lower the risk of different
applications using a given keyword for different purposes.  And
I can't find any actionable criteria for when something should
be registered and when doing so is assumed to be not worth the
effort.  Our old principle of conflict-reduction would argue for
trying to get all keywords registered even if they were used
only in a single implementation.  If the criterion is actually
"it is common knowledge that this is used by almost everyone and
used in the same way", then it is not clear what value is added
by creating a registry.  IMO, the document needs to be much more
clear about those issues and what it intends.  Once it is, we
can have a meaningful discussion about consensus on those
points.  As it stands today, a claim of consensus would need to
be based on the assumption that, somehow, everyone understands
what is expected to be done about registration of additional
tokens.  I just don't believe that is true.

Finally the historical descriptions should either be cleaned up
or removed.

best,
   john


From paulej@packetizer.com  Thu Apr 19 13:21: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 C79F721F8609 for ; Thu, 19 Apr 2012 13:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.304
X-Spam-Level: 
X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.294,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkyEMhXSHdbw for ; Thu, 19 Apr 2012 13:20:57 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2725A21F8608 for ; Thu, 19 Apr 2012 13:20:57 -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 q3JKKs55016485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Apr 2012 16:20:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334866855; bh=wb+a/Yb/5WcWoF94d7JArvZiHFS7TYt+viUKJKJIZGs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=RV1CbyOrHRxAPQR0a+xibr+qxWXVf3zHOkElT9pVlBJvHDuKt1PNL1CUNT0ppOaeM GKImEBZuB4vd+DLZ5aaT1XjGMfuAUvnCFhdom1fVtfdCICK1txCCcmxuFfVr7lmoEu WZMZvgf5fquck7O7HzF6btrpCBvrozlBgLQFlwl4=
From: "Paul E. Jones" 
To: "'Melvin Carvalho'" , "'Goix Laurent Walter'" 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net>	<4F8852D0.4020404@cs.tcd.ie>	<9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>	<4F8C5D22.7050309@stpeter.im>	<4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com>		<04fb01cd1cf6$23131c80$69395580$@packetizer.com>		<069501cd1daf$20087580$60196080$@packetizer.com>	<15AB1540-7555-4C02-A29A-AAE0ADA786B3@kodfabrik.se>	 
In-Reply-To: 
Date: Thu, 19 Apr 2012 16:21:14 -0400
Message-ID: <084401cd1e69$f8ff4250$eafdc6f0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0845_01CD1E48.71F0D6A0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0B/rNJdACTlkYtAqzWkh0CKCokFwIKVUEBASLQzuwCKHMIGAI9BikIAS4MPVmVoYfm8A==
Content-Language: en-us
Cc: 'Apps Discuss' 
Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Apr 2012 20:21:07 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0845_01CD1E48.71F0D6A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Melvin,

=20

We could use mailto, but mailto is for email.  That refers to one =
modality
of communication related to a person, but would not represent an =
=93account=94
at a domain.  Further, it would not be applicable to services like =
Twitter.

=20

I would make the same argument for XMPP.  It is another communication
modality for a user at a given domain.

=20

In general (though we=92ve seen evidence of at least one exception),
paulej@packetizer.com should be an identifier reserved for a specific
account.  I use that for my XMPP address, my email address, and I would =
use
that to discover my OpenID URI with WebFinger.  No matter what address
scheme one starts with, acct:paulej@packetizer.com should return =
information
about my account and likely pointers (directly or indirectly) to all of =
the
other URIs I use.

=20

The generic nature of =93user@domain=94 is perhaps why Blaine was =
arguing at one
point for no scheme at all.  However, we should use a properly formed =
URI
since WF returns information for a URI, which then leads us to ask =
=93what
scheme shall we use?=94  Thus, =93acct:=94 was born.  It would be legal =
to query
xmpp:paulej@packetizer.com.  However, that may or may not return a =
result.
Presently, it does not.  I most definitely would not expect any =
WebFinger
server to consider every possible scheme under the sun.  Use of mailto: =
is
popular, because so many people use email.  Funny thing is that the =
OpenID
folks at the start were against that, arguing that email was going to =
die.
They were pretty insistent that OpenID URIs should look like
https://openid.packetizer.com/paulej.  And, one could use WF to query =
that,
too.  But, you=92ll get a 404 on my server.  I do not want every =
possible
identifier to return a response.

=20

IMO, =93acct:=94 is a reasonable compromise.  It has a meaning (an =
account URI),
it=92s communication-protocol neutral (unlike xmpp:, sip:, h323:, =
mailto:,
http:, etc.), and we=92ve debated this at great length for at least 2 or =
3
years now.  People agree =93acct:=94 is not the most appreciated scheme, =
but
=93mailto:=94 is not an appropriate since that assumes a particular =
protocol.
Ditto for all other protocol-specific URI schemes.

=20

Paul

=20

From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]=20
Sent: Thursday, April 19, 2012 10:50 AM
To: Goix Laurent Walter
Cc: Pelle Wessman; Paul E.Jones; Apps Discuss
Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web
Discovery (SWD)

=20

=20

On 19 April 2012 15:59, Goix Laurent Walter
 wrote:

Possibly a standard discovery mechanism should rely on some sort of URI =
and
not a simple token string. URIs representing social network accounts are
missing so far and at least this type of URI should be discoverable.
Optionally I believe any type of other uri may, but with no guarantee. =
It
may be a matter of permissions, internal db lookups and/or associations =
or
else on the server to decide whether to provide a meaningful response to =
it.
This is somehow already clarified in section 5 of the wf draft.


Why do you say "URIs representing social accounts are missing so far"?  =
And
if so, from which systems? =20

For example, Facebook has a pretty good system for representing their
accounts as URIs (open graph protocol), as does SIOC, and people like
status.net (inventor of OStatus who have a pretty good FOAF impl.) etc.  =
All
of these use HTTP URIs as their machine representation, rather than any
proposed acct: scheme, for example. =20

I thought this use case is mainly relevant to the big webmail providers.

Email style discovery is missing (apart from the specific case of a =
public
key in GPG), so if you want a full Web sytle solution use void (already
registered with IANA).  If void is too complex, choose something =
simpler.
SWD seems a simpler solution, at this point, technically.  WF may have =
the
lead on adoption, I dont know.  Perhaps something can be learnt by each
system from each other ... e.g. the JSON vs XML discussion.  Merging the
best parts from both specs could be a great idea...

As for non mailto: URI schemes, that in itself is an interesting =
problem,
perhaps a big topic.  To me, xmpp: is a very interesting candidate.  =
Again
void can be used for this, but maybe WF/SWD is an interesting thing to
deploy.  Having a lookup for the tel: scheme would be kind of amazing =
...
but is a whole problem in itself, including finding the well known =
location.
HTTP discovery is really in advanced stages, with mature deployments, =
under
the W3C / Linked Data.  I would personally NOT encourage acct: lookup
because it's just too confusing for the average developer, fractures
identity, does not provide HTTP style 'follow your nose', and =
ultimately,
will probably not be a long lived identifier, given how quickly the web
identity space evolves (just my 2 cents).

I think sweet spot here is find the path of least resistance, for a =
really
good discovery system for email addresses.   Other schemes *could* be a =
plus
depending on the context, but the most compelling and useful lookup that =
is
filling a gap I think, is mailto: based.

=20

walter

=20

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
Per
conto di Pelle Wessman
Inviato: gioved=EC 19 aprile 2012 13.53
A: Paul E.Jones
Cc: 'Apps Discuss'
Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web =
Discovery
(SWD)

=20

While WebFinger officially requires an "acct" URI I believe almost all
current implementers accept a "pelle@kodfabrik.se" URI as being the same =
as
"acct:pelle@kodfabrik.se  ". Gmail.com
does, StatusNet/Identi.ca does, we at Flattr does. So there is a =
discrepancy
between the WebFinger specification and real life implementations.

=20

Examples:

=20

http://www.google.com/s2/webfinger/?q=3Dvoxpelli@gmail.com

http://identi.ca/main/xrd?uri=3Dvoxpelli@identi.ca

https://flattr.com/xrd/lrdd?uri=3Dvoxpelli@flattr.com

=20

Also, speaking from a Flattr-perspective, mail addresses and user =
accounts
are _not_ the same thing in our system. I myself have the e-mail
pelle@flattr.com but I have the web site account voxpelli@flattr.com and =
the
web site account pelle@flattr.com doesn't belong to me but to one of our
users. I believe most web sites, at least the smaller ones, works like =
this
- that the e-mail system and the web system is completely separated from
each other and that the user identifiers in one can conflict with the
identifiers in the other.

=20

I would say that a lookup for "mailto:pelle@flattr.com" should return =
info
about the user behind that e-mail address (if it should return anything) =
but
that a lookup for "pelle@flattr.com" or "acct:pelle@flattr.com
 " should always return data about the =
web
site user and that clients should be encouraged to use "acct:" to make =
it
clear that they want the web site's user, but that they shouldn't be
required to do so.

=20

/ Pelle

=20

=20

19 apr 2012 kl. 00:03 skrev Paul E. Jones:

=20

Melvin,

=20

WebFinger does discovery on any URI.  It might be =93http=94, =
=93mailto=94, =93ftp=94,
or =93acct=94.  So, it=92s not entirely correct to say that WebFinger =
does not do
discovery using email addresses.  I could change my server code pretty
easily to accommodate mailto.

=20

Use of mailto was something discussed at length.  As others pointed out, =
it
was not necessarily favored by all, but it was recognized to be =
insufficient
for some situations.  Most importantly, nobody other than us geeks knows
what the heck a =93mailto=94 is.  But, we do recognize that social sites =
like
Twitter have accounts.  Thus, after the lengthy debate that took place =
in
several places, it was decided to go with =93acct=94.  It actually does =
have a
useful purpose.  And its construction is made to look similar to =
=93mailto=94 so
that the a user would just enter what they consider to be an =93email=94
address, including things we know are not like user@twitter.com.  Using
=93mailto=94 is technically incorrect, but users never have to know or =
care
about that.  Behind the scenes, we use =93acct=94.  I would personally =
never
show an end user =93acct:paulej@packetizer.com
 =94.  Rather, I would just tell =
people
that their account ID is =93paulej@packetizer.com=94.  That may or may =
not be
their address.  Query a Twitter account and it might return an email =
address
that differs (if Twitter were to share that info).

=20

Paul

=20

From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]=20
Sent: Wednesday, April 18, 2012 6:05 AM
To: Paul E. Jones
Cc: Mike Jones; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web =
Discovery
(SWD)

=20

=20

On 18 April 2012 01:59, Paul E. Jones  wrote:

Melvin,

=20

On =93acct:=94=85

=20

Humans will usually interchange an acct URI and mailto URI, probably =
never
using either scheme directly in practice.  That=92s natural and =
expected, if
not desired.  The intent is that we define something that looks like an
email ID, but it=92s not an email ID.  Some services, perhaps Twitter =
being
most notable, do no use email addresses.  Yet, you might have an account
there.  So, user@twitter.com might be used by humans and automated =
systems
would convert that to acct:user@twitter.com =

.  It would not be appropriate to use mailto: since it=92s not an email =
ID.

=20

We did have a lot of debate about the use of =93acct=94.  If you query =
my
WebFinger server, you=92ll see that it will work without =93acct:=94 =
prefixed, as
that was a suggestion made a year or so ago.  It will inspect the input =
and
if it looks like an acct URI, it will assume it is.  The =93acct=94 URI =
will be
returned as an alias.  However, we should always use some kind of URI =
scheme
to remove the guesswork.  The client can often make a very good guess as =
to
whether it=92s looking for a user account or something else.  So, let it =
tell
the server what it is looking for explicitly.

=20

We need a URI scheme, because WebFinger can be used to discover all =
kinds of
information related to a given domain, not only user information.  It =
can be
used to query information about any URI, be that a web page, a user =
account,
device on the network, etc.  If we got rid of =93acct=94, then we would =
have a
system where we sometimes use a URI scheme and sometimes we do not.  =
Results
might be inconsistent, as the server may not make the right guess, =
unless we
agreed that absence of a scheme defaults to =93acct:=94.  However, I see =
no
reason for the client to be so lazy to not include =93acct:=94.  The =
user might
(and probably will) exclude it, but the client code can add it.

=20

At this point, I=92d argue the =93train has left the station=94 on =
=93acct=94, too.
The current WebFinger spec exists (in part) to formally document that =
which
has adopted; it=92s not a new thing.



Paul, thank you for your explanation on lookup based on acct: =
(WebFinger) vs
lookup based on mailto: (SWD).

I think this is a major difference.

The original WebFinger proposal was *supposed* to give extra information
about an email address.

>From wikipedia:

"WebFinger is an Internet protocol that aims to provide information =
about
people by their E-mail addresses."

>From webfinger.org:

"Put your email address into the box above, click the button"

>From google code (the top hit on google):

"making email addresses readable again"

And perhaps most importantly from the spec, the first example:

"Assume you receive an email from Bob..."

However only SWD here is doing email based discovery (mailto:).  =
WebFinger
*now* doing acct: based discovery, which is a departure from the =
original
use case. =20

Im glad that some people have voiced support for acct:, but I still =
believe
that to be a minority.  I agree, that the new acct: scheme should for in
another document, rather than shoe horned into an email based discovery
system. =20

IMHO, it's better to solve one problem (ie email based discovery) simply =
and
well, than to half solve two problems (ie a new uri scheme for identity) =
in
a single attempt. =20
=20

=20

Paul

=20

A couple of points:

1. JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the time webfinger was created in 2009, XML was the de facto
serialization, used in AJAX, SOAP and many other systems.  Today I'm =
hearing
more and more, that both developers and publishers, want to work with =
JSON,
rather than, having to support both xml and json.  Content negotiation =
also
confuses some publishers.  In my view, this is a great simplification =
that
webfinger can learn from SWD.

2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The acct: URI scheme has not proved popular, imho, and has added a layer =
of
complexity and confusion.  How do we get from acct: to mailto:?  When =
should
you use acct: and when mailto: (the spec says acct:user@host may be
different from mailto:user@host).  What about the forms.  How about =
linked
data ecosystems that want to cross link identifiers, do they now have to
consider both cases? =20

>From the original post introducing acct:

"I don=92t expect everyone to like this idea. I wish I could say I love =
it,
but I am simply content with it."

I dont know of anyone in the community (and correct me if this has =
changed)
that really loves acct:, or perhaps even likes the acct: idea.  SWD has
shown you can do discovery without acct: and I think that's a big plus.




One final side note is that this almost becomes trivial when you can do
SPARQL queries.  "void" is already registered by the W3C with IANA in
.well-known in order to discover SPARQL endpoints.  It may be overkill =
in
some people's eyes, but Linked Data (which predates webfinger), =
particularly
newer things like JSON LD, are a lot bigger than they were in 2009.  In =
a
few years it may become the definitive discovery mechanism anyway.

=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 =E8 necessario.=20


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

=20


------=_NextPart_000_0845_01CD1E48.71F0D6A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Melvin,
 
We could use mailto, but mailto is for email.=A0 That refers to one =
modality of communication related to a person, but would not represent =
an “account” at a domain. =A0Further, it would not be =
applicable to services like Twitter.
 
I would make the same argument for XMPP.=A0 It is another =
communication modality for a user at a given =
domain.
 
In general (though we’ve seen evidence of at least one =
exception), paulej@packetizer.com should =
be an identifier reserved for a specific account.=A0 I use that for my =
XMPP address, my email address, and I would use that to discover my =
OpenID URI with WebFinger.=A0 No matter what address scheme one starts =
with, acct:paulej@packetizer.com should return information about my =
account and likely pointers (directly or indirectly) to all of the other =
URIs I use.
 
The generic nature of “user@domain” is perhaps why Blaine =
was arguing at one point for no scheme at all.=A0 However, we should use =
a properly formed URI since WF returns information for a URI, which then =
leads us to ask “what scheme shall we use?”=A0 Thus, =
“acct:” was born.=A0 It would be legal to query =
xmpp:paulej@packetizer.com.=A0 However, that may or may not return a =
result.=A0 Presently, it does not.=A0 I most definitely would not expect =
any WebFinger server to consider every possible scheme under the sun.=A0 =
Use of mailto: is popular, because so many people use email.=A0 Funny =
thing is that the OpenID folks at the start were against that, arguing =
that email was going to die.=A0 They were pretty insistent that OpenID =
URIs should look like https://openid.packetizer.c=
om/paulej.=A0 And, one could use WF to query that, too.=A0 But, =
you’ll get a 404 on my server.=A0 I do not want every possible =
identifier to return a response.
 
IMO, “acct:” is a reasonable compromise.=A0 It has a =
meaning (an account URI), it’s communication-protocol neutral =
(unlike xmpp:, sip:, h323:, mailto:, http:, etc.), and we’ve =
debated this at great length for at least 2 or 3 years now.=A0 People =
agree “acct:” is not the most appreciated scheme, but =
“mailto:” is not an appropriate since that assumes a =
particular protocol.=A0 Ditto for all other protocol-specific URI =
schemes.
 
Paul
 
From:=
 =
Melvin Carvalho [mailto:melvincarvalho@gmail.com] 
Sent: =
Thursday, April 19, 2012 10:50 AM
To: Goix Laurent =
Walter
Cc: Pelle Wessman; Paul E.Jones; Apps =
Discuss
Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger =
vs. Simple Web Discovery (SWD)
 
 
On 19 April 2012 15:59, Goix Laurent Walter <laurentwalter.goix@te=
lecomitalia.it> wrote:
Possibly a standard discovery mechanism should rely on some sort of =
URI and not a simple token string. URIs representing social network =
accounts are missing so far and at least this type of URI should be =
discoverable. Optionally I believe any type of other uri may, but with =
no guarantee. It may be a matter of permissions, internal db lookups =
and/or associations or else on the server to decide whether to provide a =
meaningful response to it. This is somehow already clarified in section =
5 of the wf draft.

Why do you say "URIs =
representing social accounts are missing so far"?  And if so, =
from which systems?  

For example, Facebook has a pretty =
good system for representing their accounts as URIs (open graph =
protocol), as does SIOC, and people like status.net (inventor of OStatus who have =
a pretty good FOAF impl.) etc.  All of these use HTTP URIs as their =
machine representation, rather than any proposed acct: scheme, for =
example.  

I thought this use case is mainly relevant to the =
big webmail providers.

Email style discovery is missing (apart =
from the specific case of a public key in GPG), so if you want a full =
Web sytle solution use void (already registered with IANA).  If =
void is too complex, choose something simpler.  SWD seems a simpler =
solution, at this point, technically.  WF may have the lead on =
adoption, I dont know.  Perhaps something can be learnt by each =
system from each other ... e.g. the JSON vs XML discussion.  =
Merging the best parts from both specs could be a great =
idea...

As for non mailto: URI schemes, that in itself is an =
interesting problem, perhaps a big topic.  To me, xmpp: is a very =
interesting candidate.  Again void can be used for this, but maybe =
WF/SWD is an interesting thing to deploy.  Having a lookup for the =
tel: scheme would be kind of amazing ... but is a whole problem in =
itself, including finding the well known location.  HTTP discovery =
is really in advanced stages, with mature deployments, under the W3C / =
Linked Data.  I would personally NOT encourage acct: lookup because =
it's just too confusing for the average developer, fractures identity, =
does not provide HTTP style 'follow your nose', and ultimately, will =
probably not be a long lived identifier, given how quickly the web =
identity space evolves (just my 2 cents).

I think sweet spot here =
is find the path of least resistance, for a really good discovery system =
for email addresses.   Other schemes *could* be a plus depending on =
the context, but the most compelling and useful lookup that is filling a =
gap I think, is mailto: based.
 
walter
 
Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di =
Pelle Wessman
Inviato: gioved=EC 19 aprile 2012 =
13.53
A: Paul E.Jones
Cc: 'Apps =
Discuss'
Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. =
Simple Web Discovery (SWD)
 
While WebFinger officially requires an "acct" URI I =
believe almost all current implementers accept a "pelle@kodfabrik.se" URI as being the same as =
"acct:pelle@kodfabrik.se". Gmail.com does, =
StatusNet/Identi.ca does, we at Flattr does. So there is =
a discrepancy between the WebFinger specification and real life =
implementations.
 
Examples:
 
Also, speaking from a Flattr-perspective, mail addresses and =
user accounts are _not_ the same thing in our system. I myself have the =
e-mail pelle@flattr.com but I have the web site account =
voxpelli@flattr.com and the web site account pelle@flattr.com =
doesn't belong to me but to one of our users. I believe most web sites, =
at least the smaller ones, works like this - that the e-mail system and =
the web system is completely separated from each other and that the user =
identifiers in one can conflict with the identifiers in the =
other.
 
I would say that a lookup for "mailto:pelle@flattr.com" should return info =
about the user behind that e-mail address (if it should return anything) =
but that a lookup for "pelle@flattr.com" or "acct:pelle@flattr.com" should always return =
data about the web site user and that clients should be encouraged to =
use "acct:" to make it clear that they want the web site's =
user, but that they shouldn't be required to do =
so.
 
/ Pelle
 
 
19 apr 2012 kl. 00:03 skrev Paul E. =
Jones:
 
Melvin,
 
WebFinger does discovery on any URI.  It might =
be “http”, “mailto”, “ftp”, or =
“acct”.  So, it’s not entirely correct to say =
that WebFinger does not do discovery using email addresses.  I =
could change my server code pretty easily to accommodate =
mailto.
 
Use of mailto was something discussed at length.  As others =
pointed out, it was not necessarily favored by all, but it was =
recognized to be insufficient for some situations.  Most =
importantly, nobody other than us geeks knows what the =
heck a “mailto” is.  But, we do recognize that social =
sites like Twitter have accounts.  Thus, after the lengthy debate =
that took place in several places, it was decided to go with =
“acct”.  It actually does have a useful purpose.  =
And its construction is made to look similar to “mailto” so =
that the a user would just enter what they consider to be an =
“email” address, including things we know are not =
like user@twitter.com.  Using “mailto” =
is technically incorrect, but users never have to know or care about =
that.  Behind the scenes, we use “acct”.  I would =
personally never show an end user “acct:paulej@packetizer.com”.  Rather, I =
would just tell people that their account ID is “paulej@packetizer.com”.  That may or =
may not be their address.  Query a Twitter account and it might =
return an email address that differs (if Twitter were to share that =
info).
 
Paul
 
From:=
 Melvin=
 Carvalho [mailto:melvincarvalho@gmail.com] 
Sent:&nbs=
p;Wednesday, April 18, 2012 6:05 AM
To: Paul E. =
Jones
Cc: Mike Jones; Apps =
Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger =
vs. Simple Web Discovery (SWD)
 
 
On 18 April =
2012 01:59, Paul E. Jones <paulej@packetizer.com> wrote:
Melvin,
 
On “acct:”…
 
Humans will usually interchange an acct URI and mailto URI, probably =
never using either scheme directly in practice.  That’s =
natural and expected, if not desired.  The intent is that we define =
something that looks like an email ID, but it’s not an email =
ID.  Some services, perhaps Twitter being most notable, do no use =
email addresses.  Yet, you might have an account there.  =
So, user@twitter.com might be used by humans and =
automated systems would convert that to acct:user@twitter.com.  It would not be =
appropriate to use mailto: since it’s not an email ID.
 
We did have a lot of debate about the use of =
“acct”.  If you query my WebFinger server, you’ll =
see that it will work without “acct:” prefixed, as that was =
a suggestion made a year or so ago.  It will inspect the input and =
if it looks like an acct URI, it will assume it is.  The =
“acct” URI will be returned as an alias.  However, we =
should always use some kind of URI scheme to remove the guesswork.  =
The client can often make a very good guess as to whether it’s =
looking for a user account or something else.  So, let it tell the =
server what it is looking for explicitly.
 
We need a URI scheme, because WebFinger can be used to discover all =
kinds of information related to a given domain, not only user =
information.  It can be used to query information about any URI, be =
that a web page, a user account, device on the network, etc.  If we =
got rid of “acct”, then we would have a system where we =
sometimes use a URI scheme and sometimes we do not.  Results might =
be inconsistent, as the server may not make the right guess, unless we =
agreed that absence of a scheme defaults to “acct:”.  =
However, I see no reason for the client to be so lazy to not include =
“acct:”.  The user might (and probably will) exclude =
it, but the client code can add it.
 
At this point, I’d argue the “train has left the =
station” on “acct”, too.  The current WebFinger =
spec exists (in part) to formally document that which has adopted; =
it’s not a new thing.


Paul=
, thank you for your explanation on lookup based on acct: (WebFinger) vs =
lookup based on mailto: (SWD).

I think this is a major =
difference.

The original WebFinger proposal was *supposed* to =
give extra information about an email address.

From =
wikipedia:

"WebFinger is an =
Internet protocol that aims to provide information about people by =
their E-mail addresses."

From webfinger.org:

"Put your email =
address into the box above, click the =
button"

From google code (the top hit on =
google):

"making email =
addresses readable again"

And perhaps most =
importantly from the spec, the first example:

"Assume you receive =
an email from Bob..."

However only =
SWD here is doing email based discovery (mailto:).  WebFinger *now* doing acct: based =
discovery, which is a departure from the original use =
case.  

Im glad that some people have voiced support =
for acct:, but I still believe that to be a minority.  I agree, =
that the new acct: scheme should for in another document, rather than =
shoe horned into an email based discovery =
system.  

IMHO, it's better to solve one problem (ie =
email based discovery) simply and well, than to half solve two problems =
(ie a new uri scheme for identity) in a single =
attempt.  
 
 
Paul
 
A couple of =
points:

1. JSON
=3D=3D=3D=3D=3D=3D=3D

I think at the =
time webfinger was created in 2009, XML was the de facto serialization, =
used in AJAX, SOAP and many other systems.  Today I'm hearing more =
and more, that both developers and publishers, want to work with JSON, =
rather than, having to support both xml and json.  Content =
negotiation also confuses some publishers.  In my view, this is a =
great simplification that webfinger can learn from SWD.

2. acct: =
scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The acct: URI =
scheme has not proved popular, imho, and has added a layer of complexity =
and confusion.  How do we get from acct: to mailto:?  When =
should you use acct: and when mailto: (the spec says acct:user@host may =
be different from mailto:user@host).  What about the forms.  How =
about linked data ecosystems that want to cross link identifiers, do =
they now have to consider both cases?  

From the =
original post introducing acct:

"I don’t expect =
everyone to like this idea. I wish I could say I love it, but I am =
simply content with it."

I dont know of anyone in the =
community (and correct me if this has changed) that really loves acct:, =
or perhaps even likes the acct: idea.  SWD has shown you can do =
discovery without acct: and I think that's a big =
plus.




One final side note is that this almost becomes =
trivial when you can do SPARQL queries.  "void" is =
already registered by the W3C with IANA in .well-known in order to =
discover SPARQL endpoints.  It may be overkill in some people's =
eyes, but Linked Data (which predates webfinger), particularly newer =
things like JSON LD, are a lot bigger than they were in 2009.  In a =
few years it may become the definitive discovery mechanism anyway.
 
____________=
___________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<=
span lang=3DFR>
 
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>
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<=
o:p>
 

------=_NextPart_000_0845_01CD1E48.71F0D6A0--


From bobwyman@gmail.com  Thu Apr 19 13:36: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 1CB6921F862F for ; Thu, 19 Apr 2012 13:36:10 -0700 (PDT)
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.420,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0-8M2C8AdLH for ; Thu, 19 Apr 2012 13:36:07 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1F321F862A for ; Thu, 19 Apr 2012 13:36:07 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so6629159qcs.31 for ; Thu, 19 Apr 2012 13:36:06 -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=AWzOh+ES0mY80AKJkfu86e3JAQI8tzxVYxm6vSg4+ys=; b=IiXOm26pT2t7V6H5mvQCfRhbd+Vgu+dpD+P8UG4TqQvbMGRERpD4Y8ftrYTm5wogPb eKhWw0n5LQBZSXiEpxt3BLdtoyYp2QwjIjReJ0glmSAqkh2sCc9xAEeZKwldqZ5tW4/t C0XPFtTBYQ4JO5/zE+coQvMy6jKxKdQEnozqDtnrY9Y5w3WFQq3/kAEkJpm4OEyzdeZC CL/0aQFgRZMwGI9qOkU6uynm7agFW+prrURm1zPqzYPBxpMTN2pisi9b812sTXNQZNoc BB42QJdP/a0VqZfggNTJThfRVzskB8m5mPirQYuaHk+uoSpbpazo8wPKNxBx4oxX8caQ WazA==
MIME-Version: 1.0
Received: by 10.224.203.10 with SMTP id fg10mr5071521qab.66.1334867766463; Thu, 19 Apr 2012 13:36:06 -0700 (PDT)
Sender: bobwyman@gmail.com
Received: by 10.229.12.194 with HTTP; Thu, 19 Apr 2012 13:36:06 -0700 (PDT)
In-Reply-To: <084401cd1e69$f8ff4250$eafdc6f0$@packetizer.com>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4F8C5D22.7050309@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943664876AD@TK5EX14MBXC284.redmond.corp.microsoft.com>  <04fb01cd1cf6$23131c80$69395580$@packetizer.com>  <069501cd1daf$20087580$60196080$@packetizer.com> <15AB1540-7555-4C02-A29A-AAE0ADA786B3@kodfabrik.se>   <084401cd1e69$f8ff4250$eafdc6f0$@packetizer.com>
Date: Thu, 19 Apr 2012 16:36:06 -0400
X-Google-Sender-Auth: TPAEAMKPwxPF3u7b70D2lLTo9u0
Message-ID: 
From: Bob Wyman 
To: "Paul E. Jones" 
Content-Type: multipart/alternative; boundary=20cf300fb41d0acbae04be0e1fab
Cc: Apps Discuss 
Subject: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Apr 2012 20:36:10 -0000

--20cf300fb41d0acbae04be0e1fab
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 19, 2012 at 4:21 PM, Paul E. Jones wrote=
:

> Melvin,****
>
> ** **
>
> We could use mailto, but mailto is for email.  That refers to one modalit=
y
> of communication related to a person, but would not represent an =93accou=
nt=94
> at a domain.  Further, it would not be applicable to services like Twitte=
r.
> ****
>
> ** **
>
> I would make the same argument for XMPP.  It is another communication
> modality for a user at a given domain.****
>
> ** **
>
> In general (though we=92ve seen evidence of at least one exception),
> paulej@packetizer.com should be an identifier reserved for a specific
> account.  I use that for my XMPP address, my email address, and I would u=
se
> that to discover my OpenID URI with WebFinger.  No matter what address
> scheme one starts with, acct:paulej@packetizer.com should return
> information about my account and likely pointers (directly or indirectly)
> to all of the other URIs I use.****
>
> ** **
>
> The generic nature of =93user@domain=94 is perhaps why Blaine was arguing=
 at
> one point for no scheme at all.  However, we should use a properly formed
> URI since WF returns information for a URI, which then leads us to ask
> =93what scheme shall we use?=94  Thus, =93acct:=94 was born.  It would be=
 legal to
> query xmpp:paulej@packetizer.com.  However, that may or may not return a
> result.  Presently, it does not.  I most definitely would not expect any
> WebFinger server to consider every possible scheme under the sun.
>

It would, I think, be ideal if we could expect that any domain that
provides WebFinger support would allow queries for any protocols also
supported by that domain. Thus, if a domain supports mailto:, xmpp: or
foobar: services in addition to WebFinger, it should probably support
queries for identifiers used by those services, in addition to acct:, but
for no others. In general, I think it also would be good practice to ensure
that any query for a protocol other than acct: should return a link to an
acct: identifier.



>   Use of mailto: is popular, because so many people use email.  Funny
> thing is that the OpenID folks at the start were against that, arguing th=
at
> email was going to die.  They were pretty insistent that OpenID URIs shou=
ld
> look like https://openid.packetizer.com/paulej.  And, one could use WF to
> query that, too.  But, you=92ll get a 404 on my server.  I do not want ev=
ery
> possible identifier to return a response.****
>
> ** **
>
> IMO, =93acct:=94 is a reasonable compromise.  It has a meaning (an accoun=
t
> URI), it=92s communication-protocol neutral (unlike xmpp:, sip:, h323:,
> mailto:, http:, etc.), and we=92ve debated this at great length for at
> least 2 or 3 years now.  People agree =93acct:=94 is not the most appreci=
ated
> scheme, but =93mailto:=94 is not an appropriate since that assumes a
> particular protocol.  Ditto for all other protocol-specific URI schemes.*=
*
> **
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com]
> *Sent:* Thursday, April 19, 2012 10:50 AM
> *To:* Goix Laurent Walter
> *Cc:* Pelle Wessman; Paul E.Jones; Apps Discuss
> *Subject:* Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web
> Discovery (SWD)****
>
> ** **
>
> ** **
>
> On 19 April 2012 15:59, Goix Laurent Walter <
> laurentwalter.goix@telecomitalia.it> wrote:****
>
> Possibly a standard discovery mechanism should rely on some sort of URI
> and not a simple token string. URIs representing social network accounts
> are missing so far and at least this type of URI should be discoverable.
> Optionally I believe any type of other uri may, but with no guarantee. It
> may be a matter of permissions, internal db lookups and/or associations o=
r
> else on the server to decide whether to provide a meaningful response to
> it. This is somehow already clarified in section 5 of the wf draft.****
>
>
> Why do you say "URIs representing social accounts are missing so far"?
> And if so, from which systems?
>
> For example, Facebook has a pretty good system for representing their
> accounts as URIs (open graph protocol), as does SIOC, and people like
> status.net (inventor of OStatus who have a pretty good FOAF impl.) etc.
> All of these use HTTP URIs as their machine representation, rather than a=
ny
> proposed acct: scheme, for example.
>
> I thought this use case is mainly relevant to the big webmail providers.
>
> Email style discovery is missing (apart from the specific case of a publi=
c
> key in GPG), so if you want a full Web sytle solution use void (already
> registered with IANA).  If void is too complex, choose something simpler.
> SWD seems a simpler solution, at this point, technically.  WF may have th=
e
> lead on adoption, I dont know.  Perhaps something can be learnt by each
> system from each other ... e.g. the JSON vs XML discussion.  Merging the
> best parts from both specs could be a great idea...
>
> As for non mailto: URI schemes, that in itself is an interesting problem,
> perhaps a big topic.  To me, xmpp: is a very interesting candidate.  Agai=
n
> void can be used for this, but maybe WF/SWD is an interesting thing to
> deploy.  Having a lookup for the tel: scheme would be kind of amazing ...
> but is a whole problem in itself, including finding the well known
> location.  HTTP discovery is really in advanced stages, with mature
> deployments, under the W3C / Linked Data.  I would personally NOT encoura=
ge
> acct: lookup because it's just too confusing for the average developer,
> fractures identity, does not provide HTTP style 'follow your nose', and
> ultimately, will probably not be a long lived identifier, given how quick=
ly
> the web identity space evolves (just my 2 cents).
>
> I think sweet spot here is find the path of least resistance, for a reall=
y
> good discovery system for email addresses.   Other schemes *could* be a
> plus depending on the context, but the most compelling and useful lookup
> that is filling a gap I think, is mailto: based.****
>
>  ****
>
> walter****
>
>  ****
>
> *Da:* apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
]
> *Per conto di *Pelle Wessman
> *Inviato:* gioved=EC 19 aprile 2012 13.53
> *A:* Paul E.Jones
> *Cc:* 'Apps Discuss'
> *Oggetto:* Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> Discovery (SWD)****
>
>  ****
>
> While WebFinger officially requires an "acct" URI I believe almost all
> current implementers accept a "pelle@kodfabrik.se" URI as being the same
> as "acct:pelle@kodfabrik.se". Gmail.com does, StatusNet/Identi.ca does,
> we at Flattr does. So there is a discrepancy between the WebFinger
> specification and real life implementations.****
>
>  ****
>
> Examples:****
>
>  ****
>
> http://www.google.com/s2/webfinger/?q=3Dvoxpelli@gmail.com****
>
> http://identi.ca/main/xrd?uri=3Dvoxpelli@identi.ca****
>
> https://flattr.com/xrd/lrdd?uri=3Dvoxpelli@flattr.com****
>
>  ****
>
> Also, speaking from a Flattr-perspective, mail addresses and user account=
s
> are _not_ the same thing in our system. I myself have the e-mail
> pelle@flattr.com but I have the web site account voxpelli@flattr.com and
> the web site account pelle@flattr.com doesn't belong to me but to one of
> our users. I believe most web sites, at least the smaller ones, works lik=
e
> this - that the e-mail system and the web system is completely separated
> from each other and that the user identifiers in one can conflict with th=
e
> identifiers in the other.****
>
>  ****
>
> I would say that a lookup for "mailto:pelle@flattr.com =
"
> should return info about the user behind that e-mail address (if it shoul=
d
> return anything) but that a lookup for "pelle@flattr.com" or "
> acct:pelle@flattr.com" should always return data about the web site user
> and that clients should be encouraged to use "acct:" to make it clear tha=
t
> they want the web site's user, but that they shouldn't be required to do =
so.
> ****
>
>  ****
>
> / Pelle****
>
>  ****
>
>  ****
>
> 19 apr 2012 kl. 00:03 skrev Paul E. Jones:****
>
> ** **
>
> Melvin,****
>
>  ****
>
> WebFinger does discovery on *any* URI.  It might be =93http=94, =93mailto=
=94,
> =93ftp=94, or =93acct=94.  So, it=92s not entirely correct to say that We=
bFinger does
> not do discovery using email addresses.  I could change my server code
> pretty easily to accommodate mailto.****
>
>  ****
>
> Use of mailto was something discussed at length.  As others pointed out,
> it was not necessarily favored by all, but it was recognized to be
> insufficient for some situations.  Most importantly, *nobody* other than
> us geeks knows what the heck a =93mailto=94 is.  But, we do recognize tha=
t
> social sites like Twitter have accounts.  Thus, after the lengthy debate
> that took place in several places, it was decided to go with =93acct=94. =
 It
> actually does have a useful purpose.  And its construction is made to loo=
k
> similar to =93mailto=94 so that the a user would just enter what they con=
sider
> to be an =93email=94 address, including things we know are not like
> user@twitter.com.  Using =93mailto=94 is technically incorrect, but users
> never have to know or care about that.  Behind the scenes, we use =93acct=
=94.
> I would personally never show an end user =93acct:paulej@packetizer.com=
=94.
> Rather, I would just tell people that their account ID is =93
> paulej@packetizer.com=94.  That may or may not be their address.  Query a
> Twitter account and it might return an email address that differs (if
> Twitter were to share that info).****
>
>  ****
>
> Paul****
>
>  ****
>
> *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com]
> *Sent:* Wednesday, April 18, 2012 6:05 AM
> *To:* Paul E. Jones
> *Cc:* Mike Jones; Apps Discuss
> *Subject:* Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> Discovery (SWD)****
>
>  ****
>
>  ****
>
> On 18 April 2012 01:59, Paul E. Jones  wrote:****
>
> Melvin,****
>
>  ****
>
> On =93acct:=94=85****
>
>  ****
>
> Humans will usually interchange an acct URI and mailto URI, probably neve=
r
> using either scheme directly in practice.  That=92s natural and expected,=
 if
> not desired.  The intent is that we define something that looks like an
> email ID, but it=92s not an email ID.  Some services, perhaps Twitter bei=
ng
> most notable, do no use email addresses.  Yet, you might have an account
> there.  So, user@twitter.com might be used by humans and automated
> systems would convert that to acct:user@twitter.com.  It would not be
> appropriate to use mailto: since it=92s not an email ID.****
>
>  ****
>
> We did have a lot of debate about the use of =93acct=94.  If you query my
> WebFinger server, you=92ll see that it will work without =93acct:=94 pref=
ixed, as
> that was a suggestion made a year or so ago.  It will inspect the input a=
nd
> if it looks like an acct URI, it will assume it is.  The =93acct=94 URI w=
ill be
> returned as an alias.  However, we should always use some kind of URI
> scheme to remove the guesswork.  The client can often make a very good
> guess as to whether it=92s looking for a user account or something else. =
 So,
> let it tell the server what it is looking for explicitly.****
>
>  ****
>
> We need a URI scheme, because WebFinger can be used to discover all kinds
> of information related to a given domain, not only user information.  It
> can be used to query information about any URI, be that a web page, a use=
r
> account, device on the network, etc.  If we got rid of =93acct=94, then w=
e
> would have a system where we sometimes use a URI scheme and sometimes we =
do
> not.  Results might be inconsistent, as the server may not make the right
> guess, unless we agreed that absence of a scheme defaults to =93acct:=94.
> However, I see no reason for the client to be so lazy to not include
> =93acct:=94.  The user might (and probably will) exclude it, but the clie=
nt
> code can add it.****
>
>  ****
>
> At this point, I=92d argue the =93train has left the station=94 on =93acc=
t=94, too.
> The current WebFinger spec exists (in part) to formally document that whi=
ch
> has adopted; it=92s not a new thing.****
>
>
>
> Paul, thank you for your explanation on lookup based on acct: (WebFinger)
> vs lookup based on mailto: (SWD).
>
> I think this is a major difference.
>
> The original WebFinger proposal was *supposed* to give extra information
> about an email address.
>
> From wikipedia:
>
> "WebFinger is an Internet protocol that aims to provide information about
> people by their* E-mail addresses*."
>
> From webfinger.org:
>
> "Put your *email address* into the box above, click the button"
>
> From google code (the top hit on google):
>
> "making *email addresses* readable again"
>
> And perhaps most importantly from the spec, the first example:
>
> "Assume you receive an *email *from Bob..."
>
> However only SWD here is doing email based discovery (mailto:).
> WebFinger *now* doing acct: based discovery, which is a departure from th=
e
> original use case.
>
> Im glad that some people have voiced support for acct:, but I still
> believe that to be a minority.  I agree, that the new acct: scheme should
> for in another document, rather than shoe horned into an email based
> discovery system.
>
> IMHO, it's better to solve one problem (ie email based discovery) simply
> and well, than to half solve two problems (ie a new uri scheme for
> identity) in a single attempt.
>  ****
>
>  ****
>
> Paul****
>
>  ****
>
> A couple of points:
>
> 1. JSON
> =3D=3D=3D=3D=3D=3D=3D
>
> I think at the time webfinger was created in 2009, XML was the de facto
> serialization, used in AJAX, SOAP and many other systems.  Today I'm
> hearing more and more, that both developers and publishers, want to work
> with JSON, rather than, having to support both xml and json.  Content
> negotiation also confuses some publishers.  In my view, this is a great
> simplification that webfinger can learn from SWD.
>
> 2. acct: scheme
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The acct: URI scheme has not proved popular, imho, and has added a layer
> of complexity and confusion.  How do we get from acct: to mailto:?  When
> should you use acct: and when mailto: (the spec says acct:user@host may
> be different from mailto:user@host).  What about the forms.  How about
> linked data ecosystems that want to cross link identifiers, do they now
> have to consider both cases?
>
> From the original post introducing acct:
>
> "I don=92t expect everyone to like this idea. I wish I could say I love i=
t,
> but I am simply content with it."
>
> I dont know of anyone in the community (and correct me if this has
> changed) that really loves acct:, or perhaps even likes the acct: idea.
> SWD has shown you can do discovery without acct: and I think that's a big
> plus.
>
>
>
>
> One final side note is that this almost becomes trivial when you can do
> SPARQL queries.  "void" is already registered by the W3C with IANA in
> .well-known in order to discover SPARQL endpoints.  It may be overkill in
> some people's eyes, but Linked Data (which predates webfinger),
> particularly newer things like JSON LD, are a lot bigger than they were i=
n
> 2009.  In a few years it may become the definitive discovery mechanism
> anyway.****
>
>  ****
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
>  ****
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo=
ra
> abbiate ricevuto questo documento per errore siete cortesemente pregati d=
i
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie. ****
>
> *This e-mail and any attachments is confidential and may contain
> privileged information intended for the addressee(s) only. Dissemination,
> copying, printing or use by anybody else is unauthorised. If you are not
> the intended recipient, please delete this message and any attachments an=
d
> advise the sender by return e-mail, Thanks.* ****
>
> *Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.* **=
**
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
> ** **
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

--20cf300fb41d0acbae04be0e1fab
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On Thu, Apr 19, 2012 at 4:21 PM, Paul E.=
 Jones <paule=
j@packetizer.com> wrote:


Melvin,

=A0
We could use mailto, but mailto is for email.=
=A0 That refers to one modality of communication related to a person, but w=
ould not represent an =93account=94 at a domain. =A0Further, it would not b=
e applicable to services like Twitter.


=A0<=
/p>
I would make the same =
argument for XMPP.=A0 It is another communication modality for a user at a =
given domain.


=A0<=
/p>
In general (though we=
=92ve seen evidence of at least one exception), paulej@packetizer.com should be an iden=
tifier reserved for a specific account.=A0 I use that for my XMPP address, =
my email address, and I would use that to discover my OpenID URI with WebFi=
nger.=A0 No matter what address scheme one starts with, acct:paulej@packetizer.com should return information about my account and likely pointers (directly=
 or indirectly) to all of the other URIs I use.


=A0<=
/p>
The generic nature of =
=93user@domain=94 is perhaps why Blaine was arguing at one point for no sch=
eme at all.=A0 However, we should use a properly formed URI since WF return=
s information for a URI, which then leads us to ask =93what scheme shall we=
 use?=94=A0 Thus, =93acct:=94 was born.=A0 It would be legal to query xmpp:paulej@pa=
cketizer.com.=A0 However, that may or may not return a result.=A0 Prese=
ntly, it does not.=A0 I most definitely would not expect any WebFinger serv=
er to consider every possible scheme under the sun.



It would, I think, be ideal if=
 we could expect that any domain that provides WebFinger support would allo=
w queries for any protocols also supported by that domain. Thus, if a domai=
n supports mailto:, xmpp: or foobar: services in addition to WebFinger, it =
should probably support queries for identifiers used by those services, in =
addition to acct:, but for no others. In general, I think it also would be =
good practice to ensure that any query for a protocol other than acct: shou=
ld return a link to an acct: identifier.



=A0
=A0 Use of mailto: is popular, because so many people use e=
mail.=A0 Funny thing is that the OpenID folks at the start were against tha=
t, arguing that email was going to die.=A0 They were pretty insistent that =
OpenID URIs should look like https://openid.packetizer.com/paulej.=A0 And, one =
could use WF to query that, too.=A0 But, you=92ll get a 404 on my server.=
=A0 I do not want every possible identifier to return a response.=



=A0<=
/p>
IMO, =93acct:=94 is a =
reasonable compromise.=A0 It has a meaning (an account URI), it=92s communi=
cation-protocol neutral (unlike xmpp:, sip:, h323:, mailto:, http:, etc.), =
and we=92ve debated this at great length for at least 2 or 3 years now.=A0 =
People agree =93acct:=94 is not the most appreciated scheme, but =93mailto:=
=94 is not an appropriate since that assumes a particular protocol.=A0 Ditt=
o for all other protocol-specific URI schemes.


=A0<=
/p>
Paul


=A0<=
/p>


From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] 

Sent: Thursday, April 19, 2012 10:50 AM
To: Goix Laurent W=
alter
Cc: Pelle Wessman; Paul E.Jones; Apps Discuss
Subject=
: Re: [apps-discuss] R: [OAUTH-WG] Web Finger vs. Simple Web Discovery =
(SWD)


=A0
=A0
On 19 April 2012 15:59, Goix Laurent Walter=
 <laurentwalter.goix@telecomitalia.it> wrote:


Possibly a stan=
dard discovery mechanism should rely on some sort of URI and not a simple t=
oken string. URIs representing social network accounts are missing so far a=
nd at least this type of URI should be discoverable. Optionally I believe a=
ny type of other uri may, but with no guarantee. It may be a matter of perm=
issions, internal db lookups and/or associations or else on the server to d=
ecide whether to provide a meaningful response to it. This is somehow alrea=
dy clarified in section 5 of the wf draft.<=
u>



=
Why do you say "URIs representing social accounts are missing so far&q=
uot;?=A0 And if so, from which systems?=A0 

For example, Facebook ha=
s a pretty good system for representing their accounts as URIs (open graph =
protocol), as does SIOC, and people like status.net (inventor of OStatus who have a pretty good FO=
AF impl.) etc.=A0 All of these use HTTP URIs as their machine representatio=
n, rather than any proposed acct: scheme, for example.=A0 


I thought this use case is mainly relevant to the big webmail providers=
.

Email style discovery is missing (apart from the specific case of =
a public key in GPG), so if you want a full Web sytle solution use void (al=
ready registered with IANA).=A0 If void is too complex, choose something si=
mpler.=A0 SWD seems a simpler solution, at this point, technically.=A0 WF m=
ay have the lead on adoption, I dont know.=A0 Perhaps something can be lear=
nt by each system from each other ... e.g. the JSON vs XML discussion.=A0 M=
erging the best parts from both specs could be a great idea...


As for non mailto: URI schemes, that in itself is an interesting proble=
m, perhaps a big topic.=A0 To me, xmpp: is a very interesting candidate.=A0=
 Again void can be used for this, but maybe WF/SWD is an interesting thing =
to deploy.=A0 Having a lookup for the tel: scheme would be kind of amazing =
... but is a whole problem in itself, including finding the well known loca=
tion.=A0 HTTP discovery is really in advanced stages, with mature deploymen=
ts, under the W3C / Linked Data.=A0 I would personally NOT encourage acct: =
lookup because it's just too confusing for the average developer, fract=
ures identity, does not provide HTTP style 'follow your nose', and =
ultimately, will probably not be a long lived identifier, given how quickly=
 the web identity space evolves (just my 2 cents).


I think sweet spot here is find the path of least resistance, for a rea=
lly good discovery system for email addresses. =A0 Other schemes *could* be=
 a plus depending on the context, but the most compelling and useful lookup=
 that is filling a gap I think, is mailto: based.


=

=A0


walter
=A0


Da=
: apps-discuss-bounces@ietf.org [mailto:apps-discu=
ss-bounces@ietf.org] Per conto di Pelle Wessman

Inviato: gioved=EC 19 aprile 2012 13.53
A: Paul E.JonesCc: 'Apps Discuss'
Oggetto: Re: [apps-discuss] [O=
AUTH-WG] Web Finger vs. Simple Web Discovery (SWD)=



=A0
While WebFing=
er officially requires an "acct" URI I believe almost all current=
 implementers accept a "pelle@kodfabrik.se" URI as being the same as "acct:pelle@kodf=
abrik.se". Gmail.co=
m does, StatusNet/Identi.ca does, we at Flattr does. So there is a=A0di=
screpancy between the WebFinger specification and real life implementations=
.


=A0
Examples:
=A0<=
/u>




=A0


Also, speaking from a F=
lattr-perspective, mail addresses and user accounts are _not_ the same thin=
g in our system. I myself have the e-mail pelle@flattr.com but I have the web site account <=
a href=3D"mailto:voxpelli@flattr.com" target=3D"_blank">voxpelli@flattr.com=
 and the web site account pelle@flattr.com doesn't belong to me but to one of our us=
ers. I believe most web sites, at least the smaller ones, works like this -=
 that the e-mail system and the web system is completely separated from eac=
h other and that the user identifiers in one can conflict with the identifi=
ers in the other.


=A0
I would say that a=
 lookup for "mai=
lto:pelle@flattr.com" should return info about the user behind tha=
t e-mail address (if it should return anything) but that a lookup for "=
;pelle@flattr.com=
" or "acct:pelle@flattr.com" should always return data about the web s=
ite user and that clients should be encouraged to use "acct:" to =
make it clear that they want the web site's user, but that they shouldn=
't be required to do so.


=A0
/ Pelle<=
/u>
=A0


=A0
=

19 apr 2012 kl. 00:03 sk=
rev Paul E. Jones:

=A0
Melvin,


=A0
WebFinger does discovery on=A0any=A0URI.=A0=
 It might be =93http=94, =93mailto=94, =93ftp=94, or =93acct=94.=A0 So, it=
=92s not entirely correct to say that WebFinger does not do discovery using=
 email addresses.=A0 I could change my server code pretty easily to accommo=
date mailto.


=A0
Use of mailto was something discussed at length.=
=A0 As others pointed out, it was not necessarily favored by all, but it wa=
s recognized to be insufficient for some situations.=A0 Most importantly,=
=A0nobody=A0other than us geeks knows what the heck a =93mailto=94 i=
s.=A0 But, we do recognize that social sites like Twitter have accounts.=A0=
 Thus, after the lengthy debate that took place in several places, it was d=
ecided to go with =93acct=94.=A0 It actually does have a useful purpose.=A0=
 And its construction is made to look similar to =93mailto=94 so that the a=
 user would just enter what they consider to be an =93email=94 address, inc=
luding things we know are not like=A0user@twitter.com. =A0Using =93mailto=94 is technically =
incorrect, but users never have to know or care about that.=A0 Behind the s=
cenes, we use =93acct=94.=A0 I would personally never show an end user =93<=
a href=3D"mailto:acct%3Apaulej@packetizer.com" target=3D"_blank">acct:paule=
j@packetizer.com=94.=A0 Rather, I would just tell people that their acc=
ount ID is =93pa=
ulej@packetizer.com=94.=A0 That may or may not be their address.=A0 Que=
ry a Twitter account and it might return an email address that differs (if =
Twitter were to share that info).


=A0
Paul=



=A0


From:=A0Melvin Carvalho [mai=
lto:melvincar=
valho@gmail.com]=A0

Sent:=A0Wednesday, April 18, 2012 6:05 AM
To:=A0Paul E. Jo=
nes
Cc:=A0Mike Jones; Apps Discuss
Subject:=A0Re: [apps=
-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)


=A0<=
u>
=A0
On 18 April 2012 01:59, Paul E. Jones <paulej@packetizer.com> wrote:


Melv=
in,

=A0
On =93acc=
t:=94=85


=A0
Humans will usually interchange an acct URI and ma=
ilto URI, probably never using either scheme directly in practice.=A0 That=
=92s natural and expected, if not desired.=A0 The intent is that we define =
something that looks like an email ID, but it=92s not an email ID.=A0 Some =
services, perhaps Twitter being most notable, do no use email addresses.=A0=
 Yet, you might have an account there.=A0 So,=A0user@twitter.com=A0might be used by humans a=
nd automated systems would convert that to=A0acct:user@twitter.com.=A0 It would not b=
e appropriate to use mailto: since it=92s not an email ID.


=A0
We did have a lot of debate about the use of =93ac=
ct=94.=A0 If you query my WebFinger server, you=92ll see that it will work =
without =93acct:=94 prefixed, as that was a suggestion made a year or so ag=
o.=A0 It will inspect the input and if it looks like an acct URI, it will a=
ssume it is.=A0 The =93acct=94 URI will be returned as an alias.=A0 However=
, we should always use some kind of URI scheme to remove the guesswork.=A0 =
The client can often make a very good guess as to whether it=92s looking fo=
r a user account or something else.=A0 So, let it tell the server what it i=
s looking for explicitly.


=A0
We need a URI scheme, because WebFinger can be use=
d to discover all kinds of information related to a given domain, not only =
user information.=A0 It can be used to query information about any URI, be =
that a web page, a user account, device on the network, etc.=A0 If we got r=
id of =93acct=94, then we would have a system where we sometimes use a URI =
scheme and sometimes we do not.=A0 Results might be inconsistent, as the se=
rver may not make the right guess, unless we agreed that absence of a schem=
e defaults to =93acct:=94.=A0 However, I see no reason for the client to be=
 so lazy to not include =93acct:=94.=A0 The user might (and probably will) =
exclude it, but the client code can add it.=



=A0
At this point, I=92d argue the =93train has left t=
he station=94 on =93acct=94, too.=A0 The current WebFinger spec exists (in =
part) to formally document that which has adopted; it=92s not a new thing.<=
/span>




Paul, thank you =
for your explanation on lookup based on acct: (WebFinger) vs lookup based o=
n mailto: (SWD).

I think this is a major difference.

The orig=
inal WebFinger proposal was *supposed* to give extra information about an e=
mail address.


From wikipedia:

"WebFinger is=
 an Internet protocol that aims to provide information about people by thei=
r=A0E-mail addresses."

From=A0webfinger.org:


"Put your=A0email address=A0i=
nto the box above, click the button"

From google code (t=
he top hit on google):

"making=A0=
email addresses=A0readable again"


And perhaps most importantly from the spec, the first example:

<=
span style=3D"color:#000099">"Assume you receive an=A0email=A0f=
rom Bob..."

However only SWD here is doing email based d=
iscovery (mailto:).=A0 WebF=
inger *now* doing acct: based discovery, which is a departure from the orig=
inal use case.=A0=A0


Im glad that some people have voiced support for acct:, but I still bel=
ieve that to be a minority.=A0 I agree, that the new acct: scheme should fo=
r in another document, rather than shoe horned into an email based discover=
y system.=A0=A0


IMHO, it's better to solve one problem (ie email based discovery) s=
imply and well, than to half solve two problems (ie a new uri scheme for id=
entity) in a single attempt.=A0=A0
=A0




=A0
Paul<=
/p>

=A0


A couple of points:

1. JSON
=3D=3D=3D=
=3D=3D=3D=3D

I think at the time webfinger was created in 2009, XML =
was the de facto serialization, used in AJAX, SOAP and many other systems.=
=A0 Today I'm hearing more and more, that both developers and publisher=
s, want to work with JSON, rather than, having to support both xml and json=
.=A0 Content negotiation also confuses some publishers.=A0 In my view, this=
 is a great simplification that webfinger can learn from SWD.


2. acct: scheme
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The a=
cct: URI scheme has not proved popular, imho, and has added a layer of comp=
lexity and confusion.=A0 How do we get from acct: to mailto:?=A0 When shoul=
d you use acct: and when mailto: (the spec says acct:user@host may be diffe=
rent from mailto:user@host).=A0 What about the forms.=A0 How about linked data ecosystems that want=
 to cross link identifiers, do they now have to consider both cases?=A0=A0<=
br>

From the original post introducing acct:

"I don=92t expect =
everyone to like this idea. I wish I could say I love it, but I am simply c=
ontent with it."

I dont know of anyone in the community (and co=
rrect me if this has changed) that really loves acct:, or perhaps even like=
s the acct: idea.=A0 SWD has shown you can do discovery without acct: and I=
 think that's a big plus.





One final side note is that this almost becomes trivial whe=
n you can do SPARQL queries.=A0 "void" is already registered by t=
he W3C with IANA in .well-known in order to discover SPARQL endpoints.=A0 I=
t may be overkill in some people's eyes, but Linked Data (which predate=
s webfinger), particularly newer things like JSON LD, are a lot bigger than=
 they were in 2009.=A0 In a few years it may become the definitive discover=
y mechanism anyway.


_______________________________________________
apps-discuss mai=
ling list

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


=A0


Questo messaggio e i suoi allegati sono indirizzati =
esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altr=
a azione derivante dalla conoscenza di queste informazioni sono rigorosamen=
te vietate. Qualora abbiate ricevuto questo documento per errore siete cort=
esemente pregati di darne immediata comunicazione al mittente e di provvede=
re alla sua distruzione, Grazie. 


This e-mail and any attachments=A0is=
=A0confidential and may contain privileged information intended for the add=
ressee(s) only. Dissemination, copying, printing or use by anybody else is =
unauthorised. If you are not the intended recipient, please delete this mes=
sage and any attachments and advise the sender by return e-mail, Thanks. 


Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario=
. 



____________________________________=
___________
apps-discuss mailing list
apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss<=
/p>
=A0



_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--20cf300fb41d0acbae04be0e1fab--

From melvincarvalho@gmail.com  Thu Apr 19 14:12: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 C0DCF21F858B; Thu, 19 Apr 2012 14:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.498
X-Spam-Level: 
X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2R5X0DUdv5R; Thu, 19 Apr 2012 14:12:24 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47DD621F84C4; Thu, 19 Apr 2012 14:12:24 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so2432117vcb.31 for ; Thu, 19 Apr 2012 14:12:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tk1+OiwgYZwl+p4Q2V5c4YufcGFTH2syCwDftsiR2c0=; b=l9Z5VSaY/C+m9Oph/MV1AR4A4eP5s9LjxJXa/EsOLN1N0sbzevTcPLbIUkim8VBGPU pAIj8BJuhDJUzy2auwrHA75qAU+s9aNNwq46P3QiUE76hRXzYTmV4p5GuMQ9R4C5MjoB fCCEB02qarIyJFEFEXxcvEGPmqDM0x79a0lfRo2gpvrferU6COwFGe+JMBgcjtlVd20w JwLk6vc4OtOAzYnWwqU/59BQ5eX52qvgY7L2QPtiIRvjpyvSDxCmVDwvHuokYeLIQmQz 3wZYTGVgInEn/WomeC5OCzw5lWO4w9FtVaayD4gjpX14rL5lIGHW3X9fDV4EpFZUJZFu UQrw==
MIME-Version: 1.0
Received: by 10.220.150.134 with SMTP id y6mr1952997vcv.43.1334869943741; Thu, 19 Apr 2012 14:12:23 -0700 (PDT)
Received: by 10.52.70.98 with HTTP; Thu, 19 Apr 2012 14:12:23 -0700 (PDT)
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FF1C6A@P3PWEX2MB008.ex2.secureserver.net>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FF1C6A@P3PWEX2MB008.ex2.secureserver.net>
Date: Thu, 19 Apr 2012 23:12:23 +0200
Message-ID: 
From: Melvin Carvalho 
To: Eran Hammer 
Content-Type: multipart/alternative; boundary=f46d04389363d16d1604be0ea0a8
Cc: "oauth@ietf.org WG" , Apps Discuss 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Apr 2012 21:12:26 -0000

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

On 19 April 2012 20:26, Eran Hammer  wrote:

> #1 as John Panzer identified, allowing the server to control its
> deployment and supporting HTTP redirects is critical.
>

+1


> #2 JSON is better, which one is required is less of on issue but more of a
> best practices item.
>

Happy with this comment, and a +1 for JSON only


>
> I'll add:
>
> * Highly cachable
>

+1 tho I think most CSN dont cache a 303 redirect


> * Optimize for large providers, reducing the need to make repeated
> requests when the information is mostly following a template on the server
> side
>

+1


> * Ability to provide discovery on resources, not users or any other subset
> (emails, etc.)
>

There's a subtlety here and that's the difference in HTML between "rel" and
"rev".

A forward or reverse lookup.  Forward is a natural way to look things up,
eg you give a URL and you get a document.  But something like google search
is actually a reverse index, you give it words and you get back URLs for
documents.  Initially hard to get your head round, but in practice can be
incredibly practical and useful.

Given a triple such as (subject verb object)

  email  

Is your lookup based on the subject (WF) or the object (SWF)?

If subject then you need something there.  However, it need not be an acct:
URI

It could be a URN eg

urn:acct:user@host  (no new uri scheme needed)

it could be a relative URI such as

<#>  (which facebook do)

This indicates a pointer to the top of the document

It can even be blank

<>

The so-called 'blank node' in the linked data world, but then you're more
reliant on a query language, such as SPARQL.

I'm sure I havent covered every possibility.

OR you can key off the Object

  email 

then return all key values assoicated with  which would be in the
@subject position in the case of XRD/JRD or the @id position in the case of
something like JSON LD

It's quite confusing but essentially you are asking two very different
things:

1) Give me all information where the subject is acct:user@host

Which also means having to create a mapping, and educating every system
what the subject of their email (or xmpp/sip/tel/twitter account) should
be.  A potentially big task.  Im not saying it's wrong, but IMHO this is
potentially big enough to fill a whole other standards document in itself.

or

2) Give me all information for the user with email mailto:user@host

Non disruptive

I'm sorry If i have not explained this very well, but the difference
between rev and rel confuses a lot of confusion in HTML, and that's
essentially the subtlety here (forward vs reverse lookup)


> * Security agnostic - leave it to HTTP, TLS, OAuth, etc.
>

+1


> * HTTP compliant - doesn't invent it's own rediretion menthods or custom
> headers, etc.
>

+1


>
> EH
>
> > -----Original Message-----
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> > Of Mike Jones
> > Sent: Thursday, April 19, 2012 9:49 AM
> > To: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss
> > Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web
> > Discovery (SWD)
> >
> > There are two criteria that I would consider to be essential
> requirements for
> > any resulting general-purpose discovery specification:
> >
> > 1.  Being able to always discover per-user information with a single GET
> > (minimizing user interface latency for mobile devices, etc.)
> >
> > 2.  JSON should be required and it should be the only format required
> > (simplicity and ease of deployment/adoption)
> >
> > SWD already meets those requirements.  If the resulting spec meets those
> > requirements, it doesn't matter a lot whether we call it WebFinger or
> Simple
> > Web Discovery, but I believe that the requirements discussion is probably
> > the most productive one to be having at this point - not the starting
> point
> > document.
> >
> >                               -- Mike
> >
> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> > bounces@ietf.org] On Behalf Of Murray S. Kucherawy
> > Sent: Thursday, April 19, 2012 9:32 AM
> > To: oauth@ietf.org WG; Apps Discuss
> > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> > Discovery (SWD)
> >
> > By all means people should correct me if they think I'm wrong about
> this, but
> > so far from monitoring the discussion there seems to be general support
> for
> > focusing on WebFinger and developing it to meet the needs of those who
> > have deployed SWD, versus the opposite.
> >
> > Does anyone want to argue the opposite?
> >
> > -MSK, appsawg co-chair
> >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

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



On 19 April 2012 20:26, Eran Hammer <eran@hueniverse.co=
m> wrote:

#1 as John Panzer identified, allowing the server to control its deployment=
 and supporting HTTP redirects is critical.

+1
=
=A0


#2 JSON is better, which one is required is less of on issue but more of a =
best practices item.

Happy with this comment, and =
a +1 for JSON only
=A0




I'll add:



* Highly cachable

+1 tho I think most CSN dont cac=
he a 303 redirect
=A0


* Optimize for large providers, reducing the need to make repeated requests=
 when the information is mostly following a template on the server side
=


+1
=A0


* Ability to provide discovery on resources, not users or any other subset =
(emails, etc.)

There's a subtlety here and tha=
t's the difference in HTML between "rel" and "rev".=
=A0 


A forward or reverse lookup.=A0 Forward is a natural way to look things=
 up, eg you give a URL and you get a document.=A0 But something like google=
 search is actually a reverse index, you give it words and you get back URL=
s for documents.=A0 Initially hard to get your head round, but in practice =
can be incredibly practical and useful.


Given a triple such as (subject verb object)

<acct:user@host&=
gt;=A0 email=A0 <mailto:user@host>
Is your lookup based on the subject (WF) or the object (SWF)?=A0 
=


If subject then you need something there.=A0 However, it need not be an acc=
t: URI

It could be a URN eg

urn:acct:user@host=A0 (no new uri=
 scheme needed)

it could be a relative URI such as

<#>=
=A0 (which facebook do)


This indicates a pointer to the top of the document

It can even =
be blank

<>

The so-called 'blank node' in the l=
inked data world, but then you're more reliant on a query language, suc=
h as SPARQL.


I'm sure I havent covered every possibility.

OR you can key =
off the Object

<anything>=A0 email <mailto:user@host>

then return all key values assoicated=
 with <anything> which would be in the @subject position in the case =
of XRD/JRD or the @id position in the case of something like JSON LD


It's quite confusing but essentially you are asking two very differ=
ent things:

1) Give me all information where the subject is acct:use=
r@host

Which also means having to create a mapping, and educating ev=
ery system what the subject of their email (or xmpp/sip/tel/twitter account=
) should be.=A0 A potentially big task.=A0 Im not saying it's wrong, bu=
t IMHO this is potentially big enough to fill a whole other standards docum=
ent in itself.


or

2) Give me all information for the user with email mailto:user@host

Non disruptive

I'=
m sorry If i have not explained this very well, but the difference between =
rev and rel confuses a lot of confusion in HTML, and that's essentially=
 the subtlety here (forward vs reverse lookup)

=A0

* Security agnostic - leave it to HTTP, TLS, OAuth, etc.

+1
=A0

* HTTP compliant - doesn't invent it's own rediretion menthods or c=
ustom headers, etc.

+1
=A0




EH




> -----Original Message-----

> From: oauth-bounces@ietf.org=
 [mailto:oauth-bounces@ietf.o=
rg] On Behalf


> Of Mike Jones

> Sent: Thursday, April 19, 2012 9:49 AM

> To: Murray S. Kucherawy; oauth@ietf.=
org WG; Apps Discuss

> Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web

> Discovery (SWD)

>


> There are two criteria t=
hat I would consider to be essential requirements for

> any resulting general-purpose discovery specification:

>

> 1. =A0Being able to always discover per-user information with a single=
 GET

> (minimizing user interface latency for mobile devices, etc.)

>

> 2. =A0JSON should be required and it should be the only format require=
d

> (simplicity and ease of deployment/adoption)

>

> SWD already meets those requirements. =A0If the resulting spec meets t=
hose

> requirements, it doesn't matter a lot whether we call it WebFinger=
 or Simple

> Web Discovery, but I believe that the requirements discussion is proba=
bly

> the most productive one to be having at this point - not the starting =
point

> document.

>

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike
>

> -----Original Message-----

> From: apps-discuss-bo=
unces@ietf.org [mailto:apps-discuss-

> bounces@ietf.org] On Behalf Of=
 Murray S. Kucherawy

> Sent: Thursday, April 19, 2012 9:32 AM

> To: oauth@ietf.org WG; Apps Disc=
uss

> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web

> Discovery (SWD)

>

> By all means people should correct me if they think I'm wrong abou=
t this, but

> so far from monitoring the discussion there seems to be general suppor=
t for

> focusing on WebFinger and developing it to meet the needs of those who=


> have deployed SWD, versus the opposite.

>

> Does anyone want to argue the opposite?

>

> -MSK, appsawg co-chair

>

> _______________________________________________

> apps-discuss mailing list

> apps-discuss@ietf.org

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

>

>

> _______________________________________________


> OAuth mailing list

> OAuth@ietf.org

> https://www.ietf.org/mailman/listinfo/oauth


_____________________________=
__________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--f46d04389363d16d1604be0ea0a8--

From melvincarvalho@gmail.com  Thu Apr 19 14:13: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 EEC3721F84D5; Thu, 19 Apr 2012 14:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.508
X-Spam-Level: 
X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.090,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJPwgeUth906; Thu, 19 Apr 2012 14:13:19 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 653C621F84C4; Thu, 19 Apr 2012 14:13:19 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so2432711vcb.31 for ; Thu, 19 Apr 2012 14:13:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xSw4icn76uXzdSvGS28TtX/oUs9ohqRG0lMdEFQsqM0=; b=G85dqAmbRtEg6JlSQC6tJzYGLS0X++XniEQigbjJlOIr679nNwRMenaTXz66wcnmRD diH4ca218Aqvq5+e+QVIeNRRyiC9l6QLMNYwzQOxYYwWvpJqCUXDWXcT7ekTS4hOGAsS 1YQOvlI6PSENR6TKDmKNcsQtfsSS72heAG0Lo2yjDRqK4mXANFj0lkhnsOB8NFUN0mWv jZFkUm3wG45twBEUGd84/eBsEM9EM/b3xWL2xso/1Ju02mi3uGZmTiVkvkiANDXv8omx DCwjpXTz9z0V7efETCQI8uWzCyLXszFRN8vuX151zZSFmBVsftcWeeH6tirrPgI39R3/ SaSw==
MIME-Version: 1.0
Received: by 10.52.95.147 with SMTP id dk19mr1561835vdb.106.1334869998839; Thu, 19 Apr 2012 14:13:18 -0700 (PDT)
Received: by 10.52.70.98 with HTTP; Thu, 19 Apr 2012 14:13:18 -0700 (PDT)
In-Reply-To: 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FF1C6A@P3PWEX2MB008.ex2.secureserver.net> 
Date: Thu, 19 Apr 2012 23:13:18 +0200
Message-ID: 
From: Melvin Carvalho 
To: Eran Hammer 
Content-Type: multipart/alternative; boundary=20cf3071d0b61a281104be0ea4dd
Cc: "oauth@ietf.org WG" , Apps Discuss 
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Apr 2012 21:13:21 -0000

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

On 19 April 2012 23:12, Melvin Carvalho  wrote:

>
>
> On 19 April 2012 20:26, Eran Hammer  wrote:
>
>> #1 as John Panzer identified, allowing the server to control its
>> deployment and supporting HTTP redirects is critical.
>>
>
> +1
>
>
>> #2 JSON is better, which one is required is less of on issue but more of
>> a best practices item.
>>
>
> Happy with this comment, and a +1 for JSON only
>
>
>>
>> I'll add:
>>
>> * Highly cachable
>>
>
> +1 tho I think most CSN dont cache a 303 redirect
>

Apologies CSN should read CDN


>
>
>> * Optimize for large providers, reducing the need to make repeated
>> requests when the information is mostly following a template on the server
>> side
>>
>
> +1
>
>
>> * Ability to provide discovery on resources, not users or any other
>> subset (emails, etc.)
>>
>
> There's a subtlety here and that's the difference in HTML between "rel"
> and "rev".
>
> A forward or reverse lookup.  Forward is a natural way to look things up,
> eg you give a URL and you get a document.  But something like google search
> is actually a reverse index, you give it words and you get back URLs for
> documents.  Initially hard to get your head round, but in practice can be
> incredibly practical and useful.
>
> Given a triple such as (subject verb object)
>
>   email  
>
> Is your lookup based on the subject (WF) or the object (SWF)?
>
> If subject then you need something there.  However, it need not be an
> acct: URI
>
> It could be a URN eg
>
> urn:acct:user@host  (no new uri scheme needed)
>
> it could be a relative URI such as
>
> <#>  (which facebook do)
>
> This indicates a pointer to the top of the document
>
> It can even be blank
>
> <>
>
> The so-called 'blank node' in the linked data world, but then you're more
> reliant on a query language, such as SPARQL.
>
> I'm sure I havent covered every possibility.
>
> OR you can key off the Object
>
>   email 
>
> then return all key values assoicated with  which would be in
> the @subject position in the case of XRD/JRD or the @id position in the
> case of something like JSON LD
>
> It's quite confusing but essentially you are asking two very different
> things:
>
> 1) Give me all information where the subject is acct:user@host
>
> Which also means having to create a mapping, and educating every system
> what the subject of their email (or xmpp/sip/tel/twitter account) should
> be.  A potentially big task.  Im not saying it's wrong, but IMHO this is
> potentially big enough to fill a whole other standards document in itself.
>
> or
>
> 2) Give me all information for the user with email mailto:user@host
>
> Non disruptive
>
> I'm sorry If i have not explained this very well, but the difference
> between rev and rel confuses a lot of confusion in HTML, and that's
> essentially the subtlety here (forward vs reverse lookup)
>
>
>> * Security agnostic - leave it to HTTP, TLS, OAuth, etc.
>>
>
> +1
>
>
>> * HTTP compliant - doesn't invent it's own rediretion menthods or custom
>> headers, etc.
>>
>
> +1
>
>
>>
>> EH
>>
>> > -----Original Message-----
>> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> > Of Mike Jones
>> > Sent: Thursday, April 19, 2012 9:49 AM
>> > To: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss
>> > Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web
>> > Discovery (SWD)
>> >
>> > There are two criteria that I would consider to be essential
>> requirements for
>> > any resulting general-purpose discovery specification:
>> >
>> > 1.  Being able to always discover per-user information with a single GET
>> > (minimizing user interface latency for mobile devices, etc.)
>> >
>> > 2.  JSON should be required and it should be the only format required
>> > (simplicity and ease of deployment/adoption)
>> >
>> > SWD already meets those requirements.  If the resulting spec meets those
>> > requirements, it doesn't matter a lot whether we call it WebFinger or
>> Simple
>> > Web Discovery, but I believe that the requirements discussion is
>> probably
>> > the most productive one to be having at this point - not the starting
>> point
>> > document.
>> >
>> >                               -- Mike
>> >
>> > -----Original Message-----
>> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>> > bounces@ietf.org] On Behalf Of Murray S. Kucherawy
>> > Sent: Thursday, April 19, 2012 9:32 AM
>> > To: oauth@ietf.org WG; Apps Discuss
>> > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
>> > Discovery (SWD)
>> >
>> > By all means people should correct me if they think I'm wrong about
>> this, but
>> > so far from monitoring the discussion there seems to be general support
>> for
>> > focusing on WebFinger and developing it to meet the needs of those who
>> > have deployed SWD, versus the opposite.
>> >
>> > Does anyone want to argue the opposite?
>> >
>> > -MSK, appsawg co-chair
>> >
>> > _______________________________________________
>> > apps-discuss mailing list
>> > apps-discuss@ietf.org
>> > https://www.ietf.org/mailman/listinfo/apps-discuss
>> >
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>
>

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



On 19 April 2012 23:12, Melvin Carvalho =
<melvincar=
valho@gmail.com> wrote:



On 19 April 2012 20:26=
, Eran Hammer <eran@hueniverse.com> wrote:


#1 as John Panzer identified, allowing the server to control its deployment=
 and supporting HTTP redirects is critical.

=
+1
=A0



#2 JSON is better, which one is required is less of on issue but more of a =
best practices item.

Happy with this comment=
, and a +1 for JSON only
=A0





I'll add:



* Highly cachable

+1 tho I think most CSN do=
nt cache a 303 redirect

Apologies CSN =
should read CDN
=A0


=A0


* Optimize for large providers, reducing the need to make repeated requests=
 when the information is mostly following a template on the server side
=


+1
=A0



* Ability to provide discovery on resources, not users or any other subset =
(emails, etc.)

There's a subtlety here a=
nd that's the difference in HTML between "rel" and "rev&=
quot;.=A0 



A forward or reverse lookup.=A0 Forward is a natural way to look things=
 up, eg you give a URL and you get a document.=A0 But something like google=
 search is actually a reverse index, you give it words and you get back URL=
s for documents.=A0 Initially hard to get your head round, but in practice =
can be incredibly practical and useful.



Given a triple such as (subject verb object)

<acct:user@host&=
gt;=A0 email=A0 <mailto:u=
ser@host>

Is your lookup based on the subject (WF) or the obj=
ect (SWF)?=A0 



If subject then you need something there.=A0 However, it need not be an acc=
t: URI

It could be a URN eg

urn:acct:user@host=A0 (no new uri=
 scheme needed)

it could be a relative URI such as

<#>=
=A0 (which facebook do)



This indicates a pointer to the top of the document

It can even =
be blank

<>

The so-called 'blank node' in the l=
inked data world, but then you're more reliant on a query language, suc=
h as SPARQL.



I'm sure I havent covered every possibility.

OR you can key =
off the Object

<anything>=A0 email <mailto:user@host>

then return all key=
 values assoicated with <anything> which would be in the @subject pos=
ition in the case of XRD/JRD or the @id position in the case of something l=
ike JSON LD



It's quite confusing but essentially you are asking two very differ=
ent things:

1) Give me all information where the subject is acct:use=
r@host

Which also means having to create a mapping, and educating ev=
ery system what the subject of their email (or xmpp/sip/tel/twitter account=
) should be.=A0 A potentially big task.=A0 Im not saying it's wrong, bu=
t IMHO this is potentially big enough to fill a whole other standards docum=
ent in itself.



or

2) Give me all information for the user with email mailto:user@host

Non disrup=
tive

I'm sorry If i have not explained this very well, but the d=
ifference between rev and rel confuses a lot of confusion in HTML, and that=
's essentially the subtlety here (forward vs reverse lookup)


=A0


* HTTP compliant - doesn't invent it's own rediretion menthods or c=
ustom headers, etc.

+1
=A0





EH




> -----Original Message-----

> From: oaut=
h-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf


> Of Mike Jones

> Sent: Thursday, April 19, 2012 9:49 AM

> To: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss

> Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web

> Discovery (SWD)

>


> There are two criteria that I would consider to be ess=
ential requirements for

> any resulting general-purpose discovery specification:

>

> 1. =A0Being able to always discover per-user information with a single=
 GET

> (minimizing user interface latency for mobile devices, etc.)

>

> 2. =A0JSON should be required and it should be the only format require=
d

> (simplicity and ease of deployment/adoption)

>

> SWD already meets those requirements. =A0If the resulting spec meets t=
hose

> requirements, it doesn't matter a lot whether we call it WebFinger=
 or Simple

> Web Discovery, but I believe that the requirements discussion is proba=
bly

> the most productive one to be having at this point - not the starting =
point

> document.

>

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike
>

> -----Original Message-----

> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-

> bounces@ietf.org=
] On Behalf Of Murray S. Kucherawy

> Sent: Thursday, April 19, 2012 9:32 AM

> To: oauth@ietf.org=
 WG; Apps Discuss

> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web

> Discovery (SWD)

>

> By all means people should correct me if they think I'm wrong abou=
t this, but

> so far from monitoring the discussion there seems to be general suppor=
t for

> focusing on WebFinger and developing it to meet the needs of those who=


> have deployed SWD, versus the opposite.

>

> Does anyone want to argue the opposite?

>

> -MSK, appsawg co-chair

>

> _______________________________________________

> apps-discuss mailing list

> apps-discus=
s@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