From duerst@it.aoyama.ac.jp Mon Apr 1 19:00:12 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1E021F8EE1 for ; Mon, 1 Apr 2013 19:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, 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 sP0VraDkLRPR for ; Mon, 1 Apr 2013 19:00:11 -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 2F04721F8EC9 for ; Mon, 1 Apr 2013 19:00:08 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r321xsF8011100; Tue, 2 Apr 2013 10:59:55 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 50f2_97e2_036457f6_9b39_11e2_8979_001d096c5782; Tue, 02 Apr 2013 10:59:53 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 149E1BFF60; Tue, 2 Apr 2013 10:59:50 +0900 (JST) Message-ID: <515A3B99.50701@it.aoyama.ac.jp> Date: Tue, 02 Apr 2013 10:59:53 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Paul E. Jones" References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <056a01ce25df$8760b600$96222200$@packetizer.com> In-Reply-To: <056a01ce25df$8760b600$96222200$@packetizer.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: webfinger@ietf.org, 'Stephane Bortzmeyer' , ietf-languages@alvestrand.no Subject: Re: [webfinger] Default language (Was: Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 02:00:12 -0000 Hello Paul, others, ntohuntheonth On 2013/03/21 11:55, Paul E. Jones wrote: > Stephanie, > >>> The "titles" object comprises zero or more name/value pairs whose name >>> is a language tag or the string "default". [...] If the language is >>> unknown or unspecified, then the name is "default". >> >> Why inventing a special value when the language tag registry already has >> a specific value, "und"? To quote RFC 5646: >> >>> The 'und' (Undetermined) primary language subtag identifies linguistic >>> content whose language is not determined. This subtag SHOULD NOT be >>> used unless a language tag is required and language information is not >>> available or cannot be determined. > > This is historical. The JRD syntax was first defined in RFC 6415 and that > document said to use "default" when the corresponding XML document did not > specify the xml:lang attribute. It would be very good if the people involved could come up with a way to get rid of this historic oversight, the earlier, the better. Maybe this should actually be an erratum to RFC 6415? It should have been caught before that RFC was published, but unfortunately, such oversights happen. Regards, Martin. > We could change it, but it would break any existing implementations of RFC > 6415. > >> Editorial comment: the reference is wrong: >> >> [13] Phillips, A., Davis, M., "Tags for Identifying Languages", RFC >> 5646, January 2001. >> >> [It is 2009] > > That's an easy one. > > Thanks! > Paul > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > From bortzmeyer@nic.fr Tue Apr 2 03:39:22 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D3621F9804 for ; Tue, 2 Apr 2013 03:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 MRVd+ODn9mmf for ; Tue, 2 Apr 2013 03:39:21 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8207F21F9803 for ; Tue, 2 Apr 2013 03:39:18 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 3E71B280B7F; Tue, 2 Apr 2013 12:38:47 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 38FF1280B7D; Tue, 2 Apr 2013 12:38:47 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:113]) by relay2.nic.fr (Postfix) with ESMTP id 35B8AB38071; Tue, 2 Apr 2013 12:38:17 +0200 (CEST) Date: Tue, 2 Apr 2013 12:38:17 +0200 From: 'Stephane Bortzmeyer' To: Martin =?utf-8?B?Si4gRMO8cnN0?= Message-ID: <20130402103817.GA20944@nic.fr> References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <056a01ce25df$8760b600$96222200$@packetizer.com> <515A3B99.50701@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <515A3B99.50701@it.aoyama.ac.jp> X-Operating-System: Debian GNU/Linux 7.0 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Paul E. Jones" , ietf-languages@alvestrand.no, webfinger@ietf.org Subject: Re: [webfinger] Default language (Was: Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 10:39:22 -0000 On Tue, Apr 02, 2013 at 10:59:53AM +0900, Martin J. Dürst wrote a message of 57 lines which said: > Maybe this should actually be an erratum to RFC 6415? I'm not sure. Errata are not supposed to be used when you disagree with the working group, only when there is an involuntary slip. To quote draft-rfc-editor-errata-process: We note that allowing technical errata is a slippery slope: there may be a temptation to use errata to "fix" protocol design errors, rather than publishing new RFCs that update the erroneous documents. In general, an erratum is intended to report an error in a document, rather than an error in the design of the protocol [...] In this case, it seems the working group made a wrong choice, but deliberately. From duerst@it.aoyama.ac.jp Tue Apr 2 03:56:26 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA9221F984A for ; Tue, 2 Apr 2013 03:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.49 X-Spam-Level: X-Spam-Status: No, score=-103.49 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbW1SgGez1z7 for ; Tue, 2 Apr 2013 03:56:25 -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 5615F21F9800 for ; Tue, 2 Apr 2013 03:56:24 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r32AuGvR021660; Tue, 2 Apr 2013 19:56:16 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 50f2_b4bc_f11e0628_9b83_11e2_8979_001d096c5782; Tue, 02 Apr 2013 19:56:15 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 5251FC0003; Tue, 2 Apr 2013 19:56:11 +0900 (JST) Message-ID: <515AB94D.6030801@it.aoyama.ac.jp> Date: Tue, 02 Apr 2013 19:56:13 +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: "'Stephane Bortzmeyer'" References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <056a01ce25df$8760b600$96222200$@packetizer.com> <515A3B99.50701@it.aoyama.ac.jp> <20130402103817.GA20944@nic.fr> In-Reply-To: <20130402103817.GA20944@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "Paul E. Jones" , ietf-languages@alvestrand.no, webfinger@ietf.org Subject: Re: [webfinger] Default language (Was: Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 10:56:26 -0000 Hello Stephane, On 2013/04/02 19:38, 'Stephane Bortzmeyer' wrote: > On Tue, Apr 02, 2013 at 10:59:53AM +0900, > Martin J. D=C3=BCrst wrote > a message of 57 lines which said: > >> Maybe this should actually be an erratum to RFC 6415? > > I'm not sure. I'm also not sure. That's why I wrote "Maybe". > Errata are not supposed to be used when you disagree > with the working group, only when there is an involuntary slip. To > quote draft-rfc-editor-errata-process: > > We note that allowing technical errata is a slippery slope: there may > be a temptation to use errata to "fix" protocol design errors, rather > than publishing new RFCs that update the erroneous documents. In > general, an erratum is intended to report an error in a document, > rather than an error in the design of the protocol [...] > > In this case, it seems the working group made a wrong choice, but > deliberately. I think it's going a bit too far to say that there was a deliberate choic= e. I wasn't there, but it most probably just went like this: somebody got=20 the idea that having a default would be a good idea, somebody proposed=20 to use "default", and that was it. There was nobody who checked whether=20 somebody else already had similar ideas (not only is there "und", but=20 there's also "i-default"),... So there probably wasn't much deliberation. Also, as a draft, RFC 6415=20 was draft-hammer-hostmeta, so there wasn't a WG at all. Regards, Martin. From paulej@packetizer.com Tue Apr 2 10:20:25 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF44A21F8C45 for ; Tue, 2 Apr 2013 10:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNiJy1HMhDeb for ; Tue, 2 Apr 2013 10:20:24 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D44F521F8C1E for ; Tue, 2 Apr 2013 10:20:23 -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 r32HKJn6000481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Apr 2013 13:20:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1364923221; bh=mdc2cKZ0EmJV9x2lVgelRnV34G1UidgyL7dBOoFO4pk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=SAx0nB1SPqLaR7PDZHW1p1wZOX9QpwT9C6+K5fBCosQz+iz4gu3StKmx6JSlXcIIQ CQfqseFflTNBkbbJ9X2tsxGTg3+iHB6gJRaVQKVTuhYg9MKpjVM5gC+KtY2L/YKXOJ DikGa23BVkBXFriCv1vurJksmniS/pajJ5tDnhqY= From: "Paul E. Jones" To: "=?UTF-8?Q?'=22Martin_J._D=C3=BCrst=22'?=" , "'Stephane Bortzmeyer'" References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <056a01ce25df$8760b600$96222200$@packetizer.com> <515A3B99.50701@it.aoyama.ac.jp> <20130402103817.GA20944@nic.fr> <515AB94D.6030801@it.aoyama.ac.jp> In-Reply-To: <515AB94D.6030801@it.aoyama.ac.jp> Date: Tue, 2 Apr 2013 13:20:24 -0400 Message-ID: <03a401ce2fc6$5ddabf10$19903d30$@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: AQI0gy1+Rm1ye8tHtMgU8uLcqP1pXAIUtELjArbcRmICoD2PQAEsCfrtAlSyNcaXnxNEQA== Content-Language: en-us Cc: webfinger@ietf.org, ietf-languages@alvestrand.no Subject: Re: [webfinger] Default language (Was: Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 17:20:25 -0000 Martin, > > In this case, it seems the working group made a wrong choice, but > > deliberately. >=20 > I think it's going a bit too far to say that there was a deliberate > choice. >=20 > I wasn't there, but it most probably just went like this: somebody got > the idea that having a default would be a good idea, somebody proposed > to use "default", and that was it. There was nobody who checked = whether > somebody else already had similar ideas (not only is there "und", but > there's also "i-default"),... >=20 > So there probably wasn't much deliberation. Also, as a draft, RFC 6415 > was draft-hammer-hostmeta, so there wasn't a WG at all. You're probably right. I really do not care whether we use "und" or = "default", but I do like consistency. So, what can we do? We have a few options: 1) Leave "default" in place for consistency with RFC 6415 2) Change "default" to "und" and introduce inconsistency 3) Change "default" to "und" in both specs a) WebFinger would be easy b) We could revise RFC 6415 or file an errata (perhaps it is a = mistake) I'll consult with Eran about this, but what does the WG prefer?=20 Paul From Michael.Jones@microsoft.com Tue Apr 2 10:41:18 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31E721F8AD5 for ; Tue, 2 Apr 2013 10:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.150, 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 UK0b-9zd2V8i for ; Tue, 2 Apr 2013 10:41:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 1863221F8A8A for ; Tue, 2 Apr 2013 10:41:17 -0700 (PDT) Received: from BL2FFO11FD022.protection.gbl (10.173.161.201) by BL2FFO11HUB034.protection.gbl (10.173.161.114) with Microsoft SMTP Server (TLS) id 15.0.651.3; Tue, 2 Apr 2013 17:39:07 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD022.mail.protection.outlook.com (10.173.161.101) with Microsoft SMTP Server (TLS) id 15.0.664.0 via Frontend Transport; Tue, 2 Apr 2013 17:39:07 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 2 Apr 2013 17:39:01 +0000 From: Mike Jones To: "Paul E. Jones" , =?iso-8859-1?B?JyJNYXJ0aW4gSi4gRPxyc3QiJw==?= , 'Stephane Bortzmeyer' Thread-Topic: [webfinger] Default language (Was: Last Call: (WebFinger) to Proposed Standard Thread-Index: AQHOL8ZiavzEGWrB+EuqkZ4txOSoA5jDMFNQ Date: Tue, 2 Apr 2013 17:39:00 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675A7A63@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <056a01ce25df$8760b600$96222200$@packetizer.com> <515A3B99.50701@it.aoyama.ac.jp> <20130402103817.GA20944@nic.fr> <515AB94D.6030801@it.aoyama.ac.jp> <03a401ce2fc6$5ddabf10$19903d30$@packetizer.com> In-Reply-To: <03a401ce2fc6$5ddabf10$19903d30$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(189002)(377454001)(13464002)(199002)(53774001)(20776003)(47776003)(63696002)(51856001)(49866001)(55846006)(5343655001)(81342001)(69226001)(4396001)(53806001)(77982001)(47976001)(50466001)(65816001)(59766001)(50986001)(47446002)(23756002)(54356001)(46102001)(47736001)(79102001)(16406001)(31966008)(74662001)(33656001)(44976002)(74502001)(66066001)(56776001)(56816002)(80022001)(54316002)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB034; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08041D247D Cc: "webfinger@ietf.org" , "ietf-languages@alvestrand.no" Subject: Re: [webfinger] Default language (Was: Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 17:41:18 -0000 I'd switch to using "und". WebFinger has a normative dependency on RFC 564= 6 (Tags for Identifying Languages), which specifies the use of "und". We h= ave only an informative dependency upon RFC 6415 (Web Host Metadata) . And= I agree that the use of "default" in RFC 6415 is a spec defect that we sho= uld separately try to have corrected, either through the errata process or = by publishing an updated spec. We certainly shouldn't emulate the spec def= ect. But correcting 6415 shouldn't hold up WebFinger, which should just use the = convention in the spec that we normatively reference. -- Mike -----Original Message----- From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Paul E. Jones Sent: Tuesday, April 02, 2013 10:20 AM To: '"Martin J. D=FCrst"'; 'Stephane Bortzmeyer' Cc: webfinger@ietf.org; ietf-languages@alvestrand.no Subject: Re: [webfinger] Default language (Was: Last Call: (WebFinger) to Proposed Standard Martin, > > In this case, it seems the working group made a wrong choice, but=20 > > deliberately. >=20 > I think it's going a bit too far to say that there was a deliberate=20 > choice. >=20 > I wasn't there, but it most probably just went like this: somebody got=20 > the idea that having a default would be a good idea, somebody proposed=20 > to use "default", and that was it. There was nobody who checked=20 > whether somebody else already had similar ideas (not only is there=20 > "und", but there's also "i-default"),... >=20 > So there probably wasn't much deliberation. Also, as a draft, RFC 6415=20 > was draft-hammer-hostmeta, so there wasn't a WG at all. You're probably right. I really do not care whether we use "und" or "defau= lt", but I do like consistency. So, what can we do? We have a few options: 1) Leave "default" in place for consistency with RFC 6415 2) Change "default" to "und" and introduce inconsistency 3) Change "default" to "und" in both specs a) WebFinger would be easy b) We could revise RFC 6415 or file an errata (perhaps it is a mistake) I'll consult with Eran about this, but what does the WG prefer?=20 Paul _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger From gsalguei@cisco.com Tue Apr 2 11:50:04 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A30321F8D3A for ; Tue, 2 Apr 2013 11:50:04 -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=[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 vWh5ZtqNoSSk for ; Tue, 2 Apr 2013 11:50:03 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 5D17921F8D09 for ; Tue, 2 Apr 2013 11:50:02 -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 r32Io1LK026537 for ; Tue, 2 Apr 2013 14:50:01 -0400 (EDT) Received: from rtp-gsalguei-8918.cisco.com (rtp-gsalguei-8918.cisco.com [10.116.132.57]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r32Inw8Y004620; Tue, 2 Apr 2013 14:49:58 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Gonzalo Salgueiro In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675A7A63@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 2 Apr 2013 14:49:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <28F20A7A-4EDF-4F6D-A3C3-AD98E5CD9396@cisco.com> References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <056a01ce25df$8760b600$96222200$@packetizer.com> <515A3B99.50701@it.aoyama.ac.jp> <20130402103817.GA20944@nic.fr> <515AB94D.6030801@it.aoyama.ac.jp> <03a401ce2fc6$5ddabf10$19903d30$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943675A7A63@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) Cc: Paul Jones , =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , Stephane Bortzmeyer , ietf-languages@alvestrand.no, webfinger@ietf.org Subject: Re: [webfinger] Default language (Was: Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:50:04 -0000 I agree with this course. Gonzalo On Apr 2, 2013, at 1:39 PM, Mike Jones = wrote: > I'd switch to using "und". WebFinger has a normative dependency on = RFC 5646 (Tags for Identifying Languages), which specifies the use of = "und". We have only an informative dependency upon RFC 6415 (Web Host = Metadata) . And I agree that the use of "default" in RFC 6415 is a spec = defect that we should separately try to have corrected, either through = the errata process or by publishing an updated spec. We certainly = shouldn't emulate the spec defect. >=20 > But correcting 6415 shouldn't hold up WebFinger, which should just use = the convention in the spec that we normatively reference. >=20 > -- Mike >=20 > -----Original Message----- > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of Paul E. Jones > Sent: Tuesday, April 02, 2013 10:20 AM > To: '"Martin J. D=FCrst"'; 'Stephane Bortzmeyer' > Cc: webfinger@ietf.org; ietf-languages@alvestrand.no > Subject: Re: [webfinger] Default language (Was: Last Call: = (WebFinger) to Proposed Standard >=20 > Martin, >=20 >>> In this case, it seems the working group made a wrong choice, but=20 >>> deliberately. >>=20 >> I think it's going a bit too far to say that there was a deliberate=20= >> choice. >>=20 >> I wasn't there, but it most probably just went like this: somebody = got=20 >> the idea that having a default would be a good idea, somebody = proposed=20 >> to use "default", and that was it. There was nobody who checked=20 >> whether somebody else already had similar ideas (not only is there=20 >> "und", but there's also "i-default"),... >>=20 >> So there probably wasn't much deliberation. Also, as a draft, RFC = 6415=20 >> was draft-hammer-hostmeta, so there wasn't a WG at all. >=20 > You're probably right. I really do not care whether we use "und" or = "default", but I do like consistency. >=20 > So, what can we do? We have a few options: > 1) Leave "default" in place for consistency with RFC 6415 > 2) Change "default" to "und" and introduce inconsistency > 3) Change "default" to "und" in both specs > a) WebFinger would be easy > b) We could revise RFC 6415 or file an errata (perhaps it is a = mistake) >=20 > I'll consult with Eran about this, but what does the WG prefer?=20 >=20 > Paul >=20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 From duerst@it.aoyama.ac.jp Tue Apr 2 17:56:26 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E3111E80A3 for ; Tue, 2 Apr 2013 17:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.64 X-Spam-Level: X-Spam-Status: No, score=-103.64 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo+xSjcH9khU for ; Tue, 2 Apr 2013 17:56:24 -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 E1EC911E809C for ; Tue, 2 Apr 2013 17:56:23 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r330uCM3009319; Wed, 3 Apr 2013 09:56:14 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 0e4e_9d93_47a7d954_9bf9_11e2_8d62_001d096c5782; Wed, 03 Apr 2013 09:56:11 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 14706C00CF; Wed, 3 Apr 2013 09:56:07 +0900 (JST) Message-ID: <515B7E20.1060105@it.aoyama.ac.jp> Date: Wed, 03 Apr 2013 09:56:00 +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: Mike Jones References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> <20130315150058.GA28881@laperouse.bortzmeyer.org> <056a01ce25df$8760b600$96222200$@packetizer.com> <515A3B99.50701@it.aoyama.ac.jp> <20130402103817.GA20944@nic.fr> <515AB94D.6030801@it.aoyama.ac.jp> <03a401ce2fc6$5ddabf10$19903d30$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943675A7A63@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675A7A63@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "Paul E. Jones" , 'Stephane Bortzmeyer' , "ietf-languages@alvestrand.no" , "webfinger@ietf.org" Subject: Re: [webfinger] Default language (Was: Last Call: (WebFinger) to Proposed Standard X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 00:56:26 -0000 On 2013/04/03 2:39, Mike Jones wrote: > I'd switch to using "und". WebFinger has a normative dependency on RFC= 5646 (Tags for Identifying Languages), which specifies the use of "und".= We have only an informative dependency upon RFC 6415 (Web Host Metadata= ) . And I agree that the use of "default" in RFC 6415 is a spec defect t= hat we should separately try to have corrected, either through the errata= process or by publishing an updated spec. We certainly shouldn't emulat= e the spec defect. > > But correcting 6415 shouldn't hold up WebFinger, which should just use = the convention in the spec that we normatively reference. This makes a lot of sense indeed. Regards, Martin. > > -- Mike > > -----Original Message----- > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On= Behalf Of Paul E. Jones > Sent: Tuesday, April 02, 2013 10:20 AM > To: '"Martin J. D=C3=BCrst"'; 'Stephane Bortzmeyer' > Cc: webfinger@ietf.org; ietf-languages@alvestrand.no > Subject: Re: [webfinger] Default language (Was: Last Call: (WebFinger) to Proposed Standard > > Martin, > >>> In this case, it seems the working group made a wrong choice, but >>> deliberately. >> >> I think it's going a bit too far to say that there was a deliberate >> choice. >> >> I wasn't there, but it most probably just went like this: somebody got >> the idea that having a default would be a good idea, somebody proposed >> to use "default", and that was it. There was nobody who checked >> whether somebody else already had similar ideas (not only is there >> "und", but there's also "i-default"),... >> >> So there probably wasn't much deliberation. Also, as a draft, RFC 6415 >> was draft-hammer-hostmeta, so there wasn't a WG at all. > > You're probably right. I really do not care whether we use "und" or "d= efault", but I do like consistency. > > So, what can we do? We have a few options: > 1) Leave "default" in place for consistency with RFC 6415 > 2) Change "default" to "und" and introduce inconsistency > 3) Change "default" to "und" in both specs > a) WebFinger would be easy > b) We could revise RFC 6415 or file an errata (perhaps it is a mis= take) > > I'll consult with Eran about this, but what does the WG prefer? > > Paul > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > From presnick@qti.qualcomm.com Wed Apr 10 07:39:18 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760B521F93B4 for ; Wed, 10 Apr 2013 07:39:18 -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_23=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 a3EXbYGUBMX8 for ; Wed, 10 Apr 2013 07:39:17 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id AF4E121F93B2 for ; Wed, 10 Apr 2013 07:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1365604757; x=1397140757; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=xdPDYH5Mqnk2LXfeqYYs2q9BSrkQPNZOrR10zN7XwkM=; b=QCr3D71VDrt+Rq/j5xd3CdIfgTbUhW4LMrOYT4FCFZPJBOlF9FK/sxRl j3ZxfNsUAhA0DKDz6HuJV/5DiV+LghMTnWr1a+CAuSkkXktdCDLu+WtmV Z8hWK5C0/yIdT3cOmaKGP5EQMQBsfjSo+Ah6JYuW85WrKHFYLyBlyGPZ3 E=; X-IronPort-AV: E=Sophos;i="4.87,447,1363158000"; d="scan'208";a="34425533" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 10 Apr 2013 07:39:08 -0700 Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Apr 2013 07:39:08 -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.318.4; Wed, 10 Apr 2013 07:39:08 -0700 Message-ID: <5165798B.7030009@qti.qualcomm.com> Date: Wed, 10 Apr 2013 09:39:07 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] X-Mailman-Approved-At: Wed, 10 Apr 2013 07:41:52 -0700 Subject: [webfinger] Discussing DISCUSSing X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 14:39:18 -0000 Folks, Right now, draft-ietf-appsawg-webfinger is in the "IESG Evaluation" stage of review. For folks who don't know the details of what that means: The document is to be evaluated on the IESG telechat this Thursday and the Area Directors are now filling out their "ballots" on the document. The choices are "YES" (i.e., I think this is a good idea), "NO OBJECTION" (i.e., I think this is fine to go forward so long as someone else is supporting it), "ABSTAIN" (i.e., I don't think this is a good idea and I don't think this should go forward unless I am overruled by the rest of -- really, 2/3 of -- the IESG), and "DISCUSS" (i.e., I don't think this should go forward until we have some more discussion -- and perhaps changes -- on particular points). You can see the ballots for the webfinger document at https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ if you wish to follow along. DISCUSSes are the ones that take time, because of course they require discussion. However, normally those DISCUSSions take place only between the AD who has the issue and the author(s), the document shepherd, the chairs, and the rest of the IESG and are only brought back to the WG if the outcome would differ significantly from WG consensus. I have some serious points I wish to DISCUSS about webfinger, but after speaking with Barry, I agree that it's appropriate to have those discussions with the WG included directly. So I will be Cc'ing my ballot to this list. That said, I do want to ask for your patience and restraint: This is also being Cc'ed to all of the IESG. The IESG list has a *huge* volume of messages. You're also likely to see comments from ADs who have not been on this list from the get-go (myself included) that might seem downright ignorant. Wait for a bit. Let the chairs or the authors respond before you jump in and call me the idiot that I am. :-) Or use private email. If you see a point that you think you can clarify for everyone, please do respond publicly. I just want to avoid an email storm that is likely to make nobody happy. If, after DISCUSSing these points, I am still not satisfied, I can always move to ABSTAIN and let the rest of the IESG make the decision. But the point of the DISCUSS is to discuss, to see if we can't come to some sort of agreement on what needs to be in the document. To quote a famous US film: "Remain calm!" ;-) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From presnick@qti.qualcomm.com Wed Apr 10 08:13:42 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DCF21F989E; Wed, 10 Apr 2013 08:13:42 -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 MU-FJT-otZk1; Wed, 10 Apr 2013 08:13:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3798921F989B; Wed, 10 Apr 2013 08:13:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130410151341.19923.80191.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2013 08:13:41 -0700 Cc: webfinger@ietf.org, appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-webfinger@tools.ietf.org Subject: [webfinger] Pete Resnick's Discuss on draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 15:13:43 -0000 Pete Resnick has entered the following ballot position for draft-ietf-appsawg-webfinger-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [All: As I noted earlier to the Webfinger mailing list, I have Cc'ed this to the Webfinger list along with the document authors, the document shepherd, and the rest of the IESG. Also note that I intend to DISCUSS this until Thursday. If I get no further support from the IESG and/or the WG that this is a serious and showstopper problem, I will simply ABSTAIN on both this and on the -acct-uri document (on which I also currently have an open DISCUSS position). But it looks like Richard and I are in some agreement on this.] There appears to be a big giant semantic gap for the client side of this protocol. I can find nothing in the document that indicates to the client how it shall determine what sort of URI to use is the resource part of the query or what the semantics of any given URI are supposed to be. I suspect that the semantics are so underspecified that there could not possibly be interoperable implementations without lots of out-of-band information. The first example provides a mapping from an email address (or perhaps a mailto URI; that's not clear) to an acct URI, but neither the example nor anything in the rest of the document gives any clue why you would choose to query an "acct" URI based on the contents of an email message. I think the assumption is that if there is an email address, there must be some sort of "account" associated with it, and therefore querying the host on the RHS of the "@" for that account will get some interesting information. But I don't see any reason to choose an "acct" scheme over "mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the choice is semantics-free. Reading the above alongside 3.3 makes me all the more suspicious: In 3.3 (also mentioned in 4.5), a "mailto" URI gets you configuration information for all email configuration parameters. Does an "acct" URI get you configuration information for email *and* xmpp *and* sip *and* calendaring *and* all other configuration information (since you are no longer asking for a particular protocol, but rather the general account information), or do you only get "information" about the person and not their account? (I might also insert privacy and security worries here, but see Stephen's DISCUSS regarding that.) How can the client know what sort of information it can ask for and how to get it? And for that matter, how does the server tell what information to pass back? You'd think there would be a hint about this in 4.3, but "rel" only seems to provide for the client to request those things that the client already knows about it. In particular, there appears to be no way to say, "Give me user provided information, but not config information" or "Give me config information, but not blog entries". I find the semantics for "device" in 3.4 all-the-more mysterious. As far as I can tell, this URI scheme simply means, "Give me all of the information for the entire host." Again, the semantics of all of these interactions seem so underspecified that I don't understand how interoperation is supposed to happen. This also leaves me with the question about why the resource query part is a URI at all. It seems to me that the resource you are asking about is not a URI (or URN) at all; it's simply an identifier for an entity that the particular host knows about. Given that, why not pass a simple identifier? (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ for example.) If the scheme is not providing any particular semantics about the response, I see no reason to provide the scheme. If more semantics (beyond rel) are needed, another parameter indicating the type of identifier being used seems much more appropriate than using a URI scheme. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Stephen's concerns re: privacy. From bobwyman@gmail.com Wed Apr 10 08:42:26 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5764F21F93D6; Wed, 10 Apr 2013 08:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Gei--HGmZpJc; Wed, 10 Apr 2013 08:42:25 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D003C21F972C; Wed, 10 Apr 2013 08:42:23 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id c10so4959101wiw.14 for ; Wed, 10 Apr 2013 08:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IWb3nHUCzAYmmlHtV19ad/UCPK2WxFVwJypbpgWYNFM=; b=z01dE2VOdM/uXJr5m4Gkt2Uk7bZHSQESKEGJ7F3+pRkRCBDKgD05aVZoxx8eLN45c5 zOyUvwZqbCCKcDVxzJhXqBCpEQp3DuVaPC2ZhwsINXzSEIyUqvPuZEUGdYEHdFwVEF2o TLLH0Q4GFzl2PSKQrIlpeIhNicScNowDbsuljSzS730/RT5DLjDFX1T7cgUtgymgksSs 2T6rleIJjysjHgmhgXmorb8s4O/etSTiICeTGsAtbLzcNVUJQliK3SWEkA7vOJbO0UNN Nw49TNYlIQV2WfTjpQabSxPq7UNHeh8f7lDycb0gF7/8KEY2Ye3XPExOM+gbSRA6TEk3 +4rA== MIME-Version: 1.0 X-Received: by 10.194.222.3 with SMTP id qi3mr4487802wjc.28.1365608542874; Wed, 10 Apr 2013 08:42:22 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.194.15.137 with HTTP; Wed, 10 Apr 2013 08:42:22 -0700 (PDT) In-Reply-To: <20130410151341.19923.80191.idtracker@ietfa.amsl.com> References: <20130410151341.19923.80191.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2013 11:42:22 -0400 X-Google-Sender-Auth: iUt6apph01W-qFNIi8mFb3R2x2w Message-ID: From: Bob Wyman To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c27ee419c8e604da0384c7 Cc: webfinger@ietf.org, appsawg-chairs@tools.ietf.org, The IESG , draft-ietf-appsawg-webfinger@tools.ietf.org Subject: Re: [webfinger] Pete Resnick's Discuss on draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 15:42:26 -0000 --001a11c27ee419c8e604da0384c7 Content-Type: text/plain; charset=ISO-8859-1 WebFinger provides a mechanism with which one who discovers a URI can request metadata associated with that URI or what it represents. URI hosts are not required to support WebFinger nor are they constrained in the metadata that can be returned if they do support WebFinger. The metadata returned may or may not be useful to the requester. It is anticipated that with usage, hosts that support WebFinger will tend to report relatively consistent and useful metadata. However, it cannot be determined at this time what metadata will be most commonly reported or most commonly useful. bob wyman On Wed, Apr 10, 2013 at 11:13 AM, Pete Resnick wrote: > Pete Resnick has entered the following ballot position for > draft-ietf-appsawg-webfinger-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > [All: As I noted earlier to the Webfinger mailing list, I have Cc'ed this > to the Webfinger list along with the document authors, the document > shepherd, and the rest of the IESG. > > Also note that I intend to DISCUSS this until Thursday. If I get no > further support from the IESG and/or the WG that this is a serious and > showstopper problem, I will simply ABSTAIN on both this and on the > -acct-uri document (on which I also currently have an open DISCUSS > position). But it looks like Richard and I are in some agreement on > this.] > > There appears to be a big giant semantic gap for the client side of this > protocol. I can find nothing in the document that indicates to the client > how it shall determine what sort of URI to use is the resource part of > the query or what the semantics of any given URI are supposed to be. I > suspect that the semantics are so underspecified that there could not > possibly be interoperable implementations without lots of out-of-band > information. > > The first example provides a mapping from an email address (or perhaps a > mailto URI; that's not clear) to an acct URI, but neither the example nor > anything in the rest of the document gives any clue why you would choose > to query an "acct" URI based on the contents of an email message. I think > the assumption is that if there is an email address, there must be some > sort of "account" associated with it, and therefore querying the host on > the RHS of the "@" for that account will get some interesting > information. But I don't see any reason to choose an "acct" scheme over > "mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the > choice is semantics-free. > > Reading the above alongside 3.3 makes me all the more suspicious: In 3.3 > (also mentioned in 4.5), a "mailto" URI gets you configuration > information for all email configuration parameters. Does an "acct" URI > get you configuration information for email *and* xmpp *and* sip *and* > calendaring *and* all other configuration information (since you are no > longer asking for a particular protocol, but rather the general account > information), or do you only get "information" about the person and not > their account? (I might also insert privacy and security worries here, > but see Stephen's DISCUSS regarding that.) How can the client know what > sort of information it can ask for and how to get it? And for that > matter, how does the server tell what information to pass back? You'd > think there would be a hint about this in 4.3, but "rel" only seems to > provide for the client to request those things that the client already > knows about it. In particular, there appears to be no way to say, "Give > me user provided information, but not config information" or "Give me > config information, but not blog entries". > > I find the semantics for "device" in 3.4 all-the-more mysterious. As far > as I can tell, this URI scheme simply means, "Give me all of the > information for the entire host." > > Again, the semantics of all of these interactions seem so underspecified > that I don't understand how interoperation is supposed to happen. > > This also leaves me with the question about why the resource query part > is a URI at all. It seems to me that the resource you are asking about is > not a URI (or URN) at all; it's simply an identifier for an entity that > the particular host knows about. Given that, why not pass a simple > identifier? (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ > for example.) If the scheme is not providing any particular semantics > about the response, I see no reason to provide the scheme. If more > semantics (beyond rel) are needed, another parameter indicating the type > of identifier being used seems much more appropriate than using a URI > scheme. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Stephen's concerns re: privacy. > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > --001a11c27ee419c8e604da0384c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
WebFinger provides a mechanism with which one who discover= s a URI can request metadata associated with that URI or what it represents= .

URI hosts are not required to support WebF= inger nor are they constrained in the metadata that can be returned if they= do support WebFinger. The metadata returned may or may not be useful to th= e requester.=A0

It is anticipated that with usage, hosts th= at support WebFinger will tend to report relatively consistent and useful m= etadata. However, it cannot be determined at this time what metadata will b= e most commonly reported or most commonly useful.

bob wyman

<= div class=3D"gmail_extra">

On Wed, Apr 10= , 2013 at 11:13 AM, Pete Resnick <presnick@qti.qualcomm.com>= ; wrote:
Pete Resnick has entered the following ballo= t position for
draft-ietf-appsawg-webfinger-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.




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

[All: As I noted earlier to the Webfinger mailing list, I have Cc'ed th= is
to the Webfinger list along with the document authors, the document
shepherd, and the rest of the IESG.

Also note that I intend to DISCUSS this until Thursday. If I get no
further support from the IESG and/or the WG that this is a serious and
showstopper problem, I will simply ABSTAIN on both this and on the
-acct-uri document (on which I also currently have an open DISCUSS
position). But it looks like Richard and I are in some agreement on
this.]

There appears to be a big giant semantic gap for the client side of this protocol. I can find nothing in the document that indicates to the client how it shall determine what sort of URI to use is the resource part of
the query or what the semantics of any given URI are supposed to be. I
suspect that the semantics are so underspecified that there could not
possibly be interoperable implementations without lots of out-of-band
information.

The first example provides a mapping from an email address (or perhaps a mailto URI; that's not clear) to an acct URI, but neither the example n= or
anything in the rest of the document gives any clue why you would choose to query an "acct" URI based on the contents of an email message.= I think
the assumption is that if there is an email address, there must be some
sort of "account" associated with it, and therefore querying the = host on
the RHS of the "@" for that account will get some interesting
information. But I don't see any reason to choose an "acct" s= cheme over
"mailto" or "smtp" or "email" or "foobar= "; as far as I can tell, the
choice is semantics-free.

Reading the above alongside 3.3 makes me all the more suspicious: In 3.3 (also mentioned in 4.5), a "mailto" URI gets you configuration information for all email configuration parameters. Does an "acct"= ; URI
get you configuration information for email *and* xmpp *and* sip *and*
calendaring *and* all other configuration information (since you are no
longer asking for a particular protocol, but rather the general account
information), or do you only get "information" about the person a= nd not
their account? (I might also insert privacy and security worries here,
but see Stephen's DISCUSS regarding that.) How can the client know what=
sort of information it can ask for and how to get it? And for that
matter, how does the server tell what information to pass back? You'd think there would be a hint about this in 4.3, but "rel" only see= ms to
provide for the client to request those things that the client already
knows about it. In particular, there appears to be no way to say, "Giv= e
me user provided information, but not config information" or "Giv= e me
config information, but not blog entries".

I find the semantics for "device" in 3.4 all-the-more mysterious.= As far
as I can tell, this URI scheme simply means, "Give me all of the
information for the entire host."

Again, the semantics of all of these interactions seem so underspecified that I don't understand how interoperation is supposed to happen.

This also leaves me with the question about why the resource query part
is a URI at all. It seems to me that the resource you are asking about is not a URI (or URN) at all; it's simply an identifier for an entity that=
the particular host knows about. Given that, why not pass a simple
identifier? (See http://datatracker.ietf.org/doc/draft-ietf-radex= t-nai/
for example.) If the scheme is not providing any particular semantics
about the response, I see no reason to provide the scheme. If more
semantics (beyond rel) are needed, another parameter indicating the type of identifier being used seems much more appropriate than using a URI
scheme.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Stephen's concerns re: privacy.


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

--001a11c27ee419c8e604da0384c7-- From presnick@qti.qualcomm.com Wed Apr 10 12:31:09 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC25E21F90CE; Wed, 10 Apr 2013 12:31: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=[AWL=-0.001, 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 Pin3ywCT241j; Wed, 10 Apr 2013 12:31:08 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0E17621F9027; Wed, 10 Apr 2013 12:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1365622268; x=1397158268; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=yEy22RzXfwx6+8ZKoJMWl7b7tXypE/Rxo86BIvAFWmU=; b=opVSAGaLJ6vR9W2L9NxF69HZo+jiznAD5auTj7KYY8kdaGFphNysIGWy ZPqUhmefPY8r0AG9ovKg4YBa33gyQuO4/3hvON/27tYEYVvRhPjnb6h/o WYf2Gn2T88XOoQkp7Il8rc9aeuA2Bd21mMny82X3S6KHmu+skV7rsrM4G w=; X-IronPort-AV: E=Sophos;i="4.87,449,1363158000"; d="scan'208,217";a="34486509" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 10 Apr 2013 12:31:07 -0700 X-IronPort-AV: E=Sophos;i="4.87,449,1363158000"; d="scan'208,217";a="466628144" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Apr 2013 12:31:06 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 10 Apr 2013 12:31:06 -0700 Message-ID: <5165BDF7.2020100@qti.qualcomm.com> Date: Wed, 10 Apr 2013 14:31:03 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Bob Wyman References: <20130410151341.19923.80191.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070204080503090408010001" X-Originating-IP: [172.30.39.5] Cc: webfinger@ietf.org, appsawg-chairs@tools.ietf.org, The IESG , draft-ietf-appsawg-webfinger@tools.ietf.org Subject: Re: [webfinger] Pete Resnick's Discuss on draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 19:31:09 -0000 --------------070204080503090408010001 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi Bob, You'll note that my DISCUSS point was about the *client* behavior. You are talking about the *server* behavior, so this doesn't address my concerns. That said, as I explained in my earlier message, please give the document authors/shepherd a chance to formulate a response before jumping in. I don't want to run off on too many tangents. Thanks, pr On 4/10/13 10:42 AM, Bob Wyman wrote: > WebFinger provides a mechanism with which one who discovers a URI can > request metadata associated with that URI or what it represents. > > URI hosts are not required to support WebFinger nor are they > constrained in the metadata that can be returned if they do support > WebFinger. The metadata returned may or may not be useful to the > requester. > > It is anticipated that with usage, hosts that support WebFinger will > tend to report relatively consistent and useful metadata. However, it > cannot be determined at this time what metadata will be most commonly > reported or most commonly useful. > > bob wyman > > > > On Wed, Apr 10, 2013 at 11:13 AM, Pete Resnick > > wrote: > > Pete Resnick has entered the following ballot position for > draft-ietf-appsawg-webfinger-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > [All: As I noted earlier to the Webfinger mailing list, I have > Cc'ed this > to the Webfinger list along with the document authors, the document > shepherd, and the rest of the IESG. > > Also note that I intend to DISCUSS this until Thursday. If I get no > further support from the IESG and/or the WG that this is a serious and > showstopper problem, I will simply ABSTAIN on both this and on the > -acct-uri document (on which I also currently have an open DISCUSS > position). But it looks like Richard and I are in some agreement on > this.] > > There appears to be a big giant semantic gap for the client side > of this > protocol. I can find nothing in the document that indicates to the > client > how it shall determine what sort of URI to use is the resource part of > the query or what the semantics of any given URI are supposed to be. I > suspect that the semantics are so underspecified that there could not > possibly be interoperable implementations without lots of out-of-band > information. > > The first example provides a mapping from an email address (or > perhaps a > mailto URI; that's not clear) to an acct URI, but neither the > example nor > anything in the rest of the document gives any clue why you would > choose > to query an "acct" URI based on the contents of an email message. > I think > the assumption is that if there is an email address, there must be > some > sort of "account" associated with it, and therefore querying the > host on > the RHS of the "@" for that account will get some interesting > information. But I don't see any reason to choose an "acct" scheme > over > "mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the > choice is semantics-free. > > Reading the above alongside 3.3 makes me all the more suspicious: > In 3.3 > (also mentioned in 4.5), a "mailto" URI gets you configuration > information for all email configuration parameters. Does an "acct" URI > get you configuration information for email *and* xmpp *and* sip *and* > calendaring *and* all other configuration information (since you > are no > longer asking for a particular protocol, but rather the general > account > information), or do you only get "information" about the person > and not > their account? (I might also insert privacy and security worries here, > but see Stephen's DISCUSS regarding that.) How can the client know > what > sort of information it can ask for and how to get it? And for that > matter, how does the server tell what information to pass back? You'd > think there would be a hint about this in 4.3, but "rel" only seems to > provide for the client to request those things that the client already > knows about it. In particular, there appears to be no way to say, > "Give > me user provided information, but not config information" or "Give me > config information, but not blog entries". > > I find the semantics for "device" in 3.4 all-the-more mysterious. > As far > as I can tell, this URI scheme simply means, "Give me all of the > information for the entire host." > > Again, the semantics of all of these interactions seem so > underspecified > that I don't understand how interoperation is supposed to happen. > > This also leaves me with the question about why the resource query > part > is a URI at all. It seems to me that the resource you are asking > about is > not a URI (or URN) at all; it's simply an identifier for an entity > that > the particular host knows about. Given that, why not pass a simple > identifier? (See > http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ > for example.) If the scheme is not providing any particular semantics > about the response, I see no reason to provide the scheme. If more > semantics (beyond rel) are needed, another parameter indicating > the type > of identifier being used seems much more appropriate than using a URI > scheme. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Stephen's concerns re: privacy. > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------070204080503090408010001 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi Bob,

You'll note that my DISCUSS point was about the *client* behavior. You are talking about the *server* behavior, so this doesn't address my concerns.

That said, as I explained in my earlier message, please give the document authors/shepherd a chance to formulate a response before jumping in. I don't want to run off on too many tangents.

Thanks,

pr

On 4/10/13 10:42 AM, Bob Wyman wrote:
WebFinger provides a mechanism with which one who discovers a URI can request metadata associated with that URI or what it represents.

URI hosts are not required to support WebFinger nor are they constrained in the metadata that can be returned if they do support WebFinger. The metadata returned may or may not be useful to the requester. 

It is anticipated that with usage, hosts that support WebFinger will tend to report relatively consistent and useful metadata. However, it cannot be determined at this time what metadata will be most commonly reported or most commonly useful.

bob wyman



On Wed, Apr 10, 2013 at 11:13 AM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
Pete Resnick has entered the following ballot position for
draft-ietf-appsawg-webfinger-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.




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

[All: As I noted earlier to the Webfinger mailing list, I have Cc'ed this
to the Webfinger list along with the document authors, the document
shepherd, and the rest of the IESG.

Also note that I intend to DISCUSS this until Thursday. If I get no
further support from the IESG and/or the WG that this is a serious and
showstopper problem, I will simply ABSTAIN on both this and on the
-acct-uri document (on which I also currently have an open DISCUSS
position). But it looks like Richard and I are in some agreement on
this.]

There appears to be a big giant semantic gap for the client side of this
protocol. I can find nothing in the document that indicates to the client
how it shall determine what sort of URI to use is the resource part of
the query or what the semantics of any given URI are supposed to be. I
suspect that the semantics are so underspecified that there could not
possibly be interoperable implementations without lots of out-of-band
information.

The first example provides a mapping from an email address (or perhaps a
mailto URI; that's not clear) to an acct URI, but neither the example nor
anything in the rest of the document gives any clue why you would choose
to query an "acct" URI based on the contents of an email message. I think
the assumption is that if there is an email address, there must be some
sort of "account" associated with it, and therefore querying the host on
the RHS of the "@" for that account will get some interesting
information. But I don't see any reason to choose an "acct" scheme over
"mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the
choice is semantics-free.

Reading the above alongside 3.3 makes me all the more suspicious: In 3.3
(also mentioned in 4.5), a "mailto" URI gets you configuration
information for all email configuration parameters. Does an "acct" URI
get you configuration information for email *and* xmpp *and* sip *and*
calendaring *and* all other configuration information (since you are no
longer asking for a particular protocol, but rather the general account
information), or do you only get "information" about the person and not
their account? (I might also insert privacy and security worries here,
but see Stephen's DISCUSS regarding that.) How can the client know what
sort of information it can ask for and how to get it? And for that
matter, how does the server tell what information to pass back? You'd
think there would be a hint about this in 4.3, but "rel" only seems to
provide for the client to request those things that the client already
knows about it. In particular, there appears to be no way to say, "Give
me user provided information, but not config information" or "Give me
config information, but not blog entries".

I find the semantics for "device" in 3.4 all-the-more mysterious. As far
as I can tell, this URI scheme simply means, "Give me all of the
information for the entire host."

Again, the semantics of all of these interactions seem so underspecified
that I don't understand how interoperation is supposed to happen.

This also leaves me with the question about why the resource query part
is a URI at all. It seems to me that the resource you are asking about is
not a URI (or URN) at all; it's simply an identifier for an entity that
the particular host knows about. Given that, why not pass a simple
identifier? (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai/
for example.) If the scheme is not providing any particular semantics
about the response, I see no reason to provide the scheme. If more
semantics (beyond rel) are needed, another parameter indicating the type
of identifier being used seems much more appropriate than using a URI
scheme.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Stephen's concerns re: privacy.


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


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

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------070204080503090408010001-- From paulej@packetizer.com Wed Apr 10 20:39:49 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D8221F85BF; Wed, 10 Apr 2013 20:39:49 -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 YnI3UlH67V4p; Wed, 10 Apr 2013 20:39:48 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 19A2221F8C00; Wed, 10 Apr 2013 20:39:48 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r3B3dkji026769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Apr 2013 23:39:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1365651587; bh=suk5kJyDiZ2M/tFsv/luw4gxm4wNW4EBGIiJpV+NSUI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=DfntowA/59aoDHIewB9bovMAoV1KPCQOvCc7bATBrA5QcertzTvYBwTtdZwl40NYp /dWwuXADUW65AEyVto1fwS0aDiit2mCzdjg8fAdsxpKZrApN6LbYrjdo7PxDn3JPKX cy2jG6CyknLmsSj7F00wcXnAxR2gRA05coMORqBE= From: "Paul E. Jones" To: "'Pete Resnick'" , "'The IESG'" References: <20130410151341.19923.80191.idtracker@ietfa.amsl.com> In-Reply-To: <20130410151341.19923.80191.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2013 23:39:54 -0400 Message-ID: <0d3a01ce3666$3b7524a0$b25f6de0$@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: AQIFZ47RBvRxNougrt0H0X5S9MAW/Zhh8agQ Content-Language: en-us Cc: webfinger@ietf.org, appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-webfinger@tools.ietf.org Subject: Re: [webfinger] Pete Resnick's Discuss on draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 03:39:49 -0000 Pete, > [All: As I noted earlier to the Webfinger mailing list, I have Cc'ed > this > to the Webfinger list along with the document authors, the document > shepherd, and the rest of the IESG. >=20 > Also note that I intend to DISCUSS this until Thursday. If I get no > further support from the IESG and/or the WG that this is a serious and > showstopper problem, I will simply ABSTAIN on both this and on the > -acct-uri document (on which I also currently have an open DISCUSS > position). But it looks like Richard and I are in some agreement on > this.] >=20 > There appears to be a big giant semantic gap for the client side of = this > protocol. I can find nothing in the document that indicates to the > client > how it shall determine what sort of URI to use is the resource part of > the query or what the semantics of any given URI are supposed to be. I > suspect that the semantics are so underspecified that there could not > possibly be interoperable implementations without lots of out-of-band > information. If you are seeking information related to a user account, then the = specification recommends the use of the "acct" URI. Use of other URI = types is not fully specified and no recommendations are given. = Syntactically, the server behavior will be the same for any type of URI. = The only gap is knowing what set of link relations type to expect for a = given URI scheme. Do you use "mailto" or "acct"? We had a lot of = debate over that for years and settled on "acct". So what should one expect if one issued a query like this? $ curl = https://packetizer.com/.well-known/webfinger?resource=3Dhttp://www.packet= izer.com I would expect it to return information about that URL. The link = relation types returned might be "copyright" or "author" or other. It = would be types that are valid for a web page. > The first example provides a mapping from an email address (or perhaps = a > mailto URI; that's not clear) to an acct URI, but neither the example > nor > anything in the rest of the document gives any clue why you would = choose > to query an "acct" URI based on the contents of an email message. I > think > the assumption is that if there is an email address, there must be = some > sort of "account" associated with it, and therefore querying the host = on > the RHS of the "@" for that account will get some interesting > information. But I don't see any reason to choose an "acct" scheme = over > "mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the > choice is semantics-free. Again, this was a 3 year long discussion. You're right that it could be = anything. We even argued to use no URI at all and just use = "user@domain". However, it finally decided to use "acct". It = identifies an account at a domain. It does not identify an email = address. Using mailto URI didn't fit Twitter, for example, as there is = no email. The same can be said for other services, including photo = sharing services, blogs, and so forth. If you want to query information = about my account on a social networking site, it would not be an email = address that would be used. =20 > Reading the above alongside 3.3 makes me all the more suspicious: In = 3.3 > (also mentioned in 4.5), a "mailto" URI gets you configuration > information for all email configuration parameters. Does an "acct" URI > get you configuration information for email *and* xmpp *and* sip *and* > calendaring *and* all other configuration information (since you are = no > longer asking for a particular protocol, but rather the general = account > information), or do you only get "information" about the person and = not > their account? (I might also insert privacy and security worries here, > but see Stephen's DISCUSS regarding that.) How can the client know = what > sort of information it can ask for and how to get it? And for that > matter, how does the server tell what information to pass back? You'd > think there would be a hint about this in 4.3, but "rel" only seems to > provide for the client to request those things that the client already > knows about it. In particular, there appears to be no way to say, = "Give > me user provided information, but not config information" or "Give me > config information, but not blog entries". The "rel" parameter is just a filter to reduce the size of the JRD down = to only the particular link relation types of interest (e.g., "vcard", = "jcard", "blog", "profile"). If you wish to query for information about a person, you query the = person's acct URI. The other examples, such as use of "mailto" or = "device" are just examples of what is possible. As an example of how I = would expect to use "mailto", you can see this presentation: http://www.ietf.org/proceedings/86/slides/slides-86-aggsrv-3.pdf However, the aggsrv group could say (if they even elected to use WF) = that the "mailto" URI shall be used to query for configuration = information related to email. I don't know what they will recommend. = The WF draft shows an example of how one could use an email URI, but it = is a non-working example since none of the link relation types are = defined. The WF spec does not go into detail on what a client should expect to = receive for any URI scheme, but only recommends use of "acct" to get = user account information. The link relations returned from such a query = are in use today and some will be standardized (as that's next on the = "to-do" list). > I find the semantics for "device" in 3.4 all-the-more mysterious. As = far > as I can tell, this URI scheme simply means, "Give me all of the > information for the entire host." Well, "device" does not exist and that will likely never exist. The = only point with that was to demonstrate how any URI scheme could be = used, including one intended for device identification. And if we had = one for device identification, it might return that kind of information. = Again, this is just a non-normative example showing broadly what we can = do with WF. =20 > Again, the semantics of all of these interactions seem so = underspecified > that I don't understand how interoperation is supposed to happen. Yeah, this definitely was not intended to be defined. When or if we = decided to use WF for this purpose, it would be defined in another spec. = However, I would expect the syntax and procedures for making the = request to the server to be the same as querying for an account URI. =20 > This also leaves me with the question about why the resource query = part > is a URI at all. It seems to me that the resource you are asking about > is > not a URI (or URN) at all; it's simply an identifier for an entity = that > the particular host knows about. Given that, why not pass a simple > identifier? (See = http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ > for example.) If the scheme is not providing any particular semantics > about the response, I see no reason to provide the scheme. If more > semantics (beyond rel) are needed, another parameter indicating the = type > of identifier being used seems much more appropriate than using a URI > scheme. URI schemes allow for a natural separation. And, a WF server for a = domain could know all kinds of information about itself. It would know = who authored web pages on the domain. It would know information about = account holders on the domain. There was back and forth, as I noted = above, as to whether we needed "acct" or not. In the end, it was agreed = to identify information about users -- stuff users share or that are = shared within a company (e.g., employee pictures or contact info). Years of work on this topic resulted in RFC 6415. RFC 6415, in fact, is = what people had envisaged for "webfinger". It defined a well-known = location called "host-meta" and a different link relation called "LRDD" = for querying information about a particular URI. The challenge with RFC 6415 is that it too so long to move forward that = by the time it was done, JSON had become the favored syntax language, = people wanted to mandate use of TLS for a variety of security reasons, = people did not want two round trips to the server to return the JRD. = So, we set about fixing all of the gripes people had with RFC 6415. We = removed XML entirely, we fully documented JRD, the server does the = merging of host-meta and LRDD documents (though not described that way = for simplicity's sake), TLS was mandated, and we introduced the "rel" = parameter to allow for selecting one or a few types of links to reduce = the size of the document. RFC 6415 uses any type of URI. This is useful, since the URI scheme = does provide separation in namespace and since we do want to allow = retrieval of a set of link relations for those URIs -- web pages (http), = user accounts (acct), tel URIs (tel), etc. The only point of confusion, = I think, is "what do we do with mailto, sip, h323, telnet, etc.?" Well, = we're not prescribing that. That would be documented in a document that = wants to use those other URIs. They might be used to configure a device = or help route a call or whatever. We only have examples of possible = use, but we do not specify their use. Paul From laurentwalter.goix@telecomitalia.it Thu Apr 11 01:30:43 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E7B21F8EBE; Thu, 11 Apr 2013 01:30:43 -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 X7+0exNiyDUN; Thu, 11 Apr 2013 01:30:42 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3F321F8E94; Thu, 11 Apr 2013 01:30:41 -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.297.1; Thu, 11 Apr 2013 10:30:39 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Thu, 11 Apr 2013 10:30:38 +0200 From: Goix Laurent Walter To: "Paul E. Jones" , 'Pete Resnick' , 'The IESG' Date: Thu, 11 Apr 2013 10:30:35 +0200 Thread-Topic: [webfinger] Pete Resnick's Discuss on draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT) Thread-Index: AQIFZ47RBvRxNougrt0H0X5S9MAW/Zhh8agQgABaiVA= Message-ID: References: <20130410151341.19923.80191.idtracker@ietfa.amsl.com> <0d3a01ce3666$3b7524a0$b25f6de0$@packetizer.com> In-Reply-To: <0d3a01ce3666$3b7524a0$b25f6de0$@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 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "webfinger@ietf.org" , "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-webfinger@tools.ietf.org" Subject: [webfinger] R: Pete Resnick's Discuss on draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 08:30:43 -0000 Dear all, After reading this thread and the various ballots, I'd like to help the DIS= CUSSion and hopefully clarify (part of) the doubts by proposing an example = of usage of webfinger within federated social networks. This example is der= ived from the OMA Social Network Web specification, which references Webfin= ger for this specific purpose. I'd also like to recall (as Paul anticipated talking about rfc6415) that so= cial network federation was actually the first use case of the original web= finger community spec, and as such imo well deserves an example using this = new spec as it may become extremely relevant in the next years. Of course improvements are welcome if the generic idea is sound. Walter --- 3.x Federated Social Networks In the context of interoperable, federated, social networks, the Webfinger = discovery process is used by a SN Server when receiving a request from an S= N Client on behalf of a user asking to interact with a user identified by h= is SN account eg acct:joe@example.com. In particular the SN Server identifi= es whether it is authoritative for the recipient (i.e. the domain of his/he= r account is "locally" managed by this SN Server) or whether it pertains to= another remote SN domain/provider. If the recipient's address corresponds = to a "acct:" address, which domain-part corresponds to a remote domain, the= SN Server can locate the recipient's SN Server based on this domain-part a= nd trigger the Webfinger discovery process for that recipient (the "resourc= e"). This process can hence be triggered when receiving requests to follow remot= e users or when receiving reactions (e.g. comments, replies, mentions) that= relate to social activities of remote users, etc. Depending on the incomin= g request from the client, the SN Server may be interested in some specific= link rels that will be used to contact the remote SN Server on the related= endpoint(s). SN Servers can cache the information provided in the retrieve= d descriptor and/or issue conditional requests at a later stage to check fo= r updates of this information, subject to the mechanisms defined in [RFC 26= 16] section 13. The following JRD is an example of a user descriptor returned by an SN Serv= er for a Webfinger query to user account acct:joe@example.com. In this requ= est no specific rel is mentioned as it may be useful for the requesting SN = Server to cache to entire descriptor for future needs. { "subject" : "acct:joe@example.com", "properties" : { "http://salmon-protocol.org/ns/magic-key" : "RSA.mVgY8RN6URBTstn= dvmUUPb4UZTdwvwmddSKE5z_jvKUEK6yk1u3rrC9yN8k6FilGj9K0eeUPe2hf4Pj-5CmHww.AQA= B" }, "links" : [ { "rel" : "http://portablecontacts.net/spec/1.0", "href" : "http://example.com/api/people" }, { "rel" : "http://portablecontacts.net/spec/1.0#me", "href" : "http://example.com/api/people/joe" }, { "rel" : "http://ns.opensocial.org/2008/opensocial/people", "href" : "http://example.com/api/people" }, { "rel" : "http://webfinger.net/rel/profile-page", "type" : "text/html", "href" : "http://example.com/profiles/joe" }, { "rel" : "describedby", "type" : "text/html", "href" : "http://example.com/profiles/joe" }, { "rel" : "http://webfinger.net/rel/avatar", "href" : "http://example.com/profiles/joe/photo" }, { "rel" : "http://schemas.google.com/g/2010#updates-from", "type" : "application/atom+xml", "href" : "http://example.com/activities/joe" }, { "rel" : "salmon", "href" : "http://example.com/salmon/joe" } ] } Depending on the original request from the client the SN Server will typica= lly read a specific link rel and invoke the related endpoint. For example i= t can read the http://schemas.google.com/g/2010#updates-from relation link = of type "application/atom+xml" to access the user's activity stream feed or= the http://portablecontacts.net/spec/1.0 relation link to access personal = user information such as his profile or relationships. The actual access to= such endpoints and the retrieved data ,if any, will be subject to the remo= te SN policies and user settings. > -----Messaggio originale----- > Da: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] Per co= nto > di Paul E. Jones > Inviato: gioved=EC 11 aprile 2013 5.40 > A: 'Pete Resnick'; 'The IESG' > Cc: webfinger@ietf.org; appsawg-chairs@tools.ietf.org; draft-ietf-appsawg= - > webfinger@tools.ietf.org > Oggetto: Re: [webfinger] Pete Resnick's Discuss on draft-ietf-appsawg- > webfinger-12: (with DISCUSS and COMMENT) > > Pete, > > > [All: As I noted earlier to the Webfinger mailing list, I have Cc'ed > > this > > to the Webfinger list along with the document authors, the document > > shepherd, and the rest of the IESG. > > > > Also note that I intend to DISCUSS this until Thursday. If I get no > > further support from the IESG and/or the WG that this is a serious and > > showstopper problem, I will simply ABSTAIN on both this and on the > > -acct-uri document (on which I also currently have an open DISCUSS > > position). But it looks like Richard and I are in some agreement on > > this.] > > > > There appears to be a big giant semantic gap for the client side of thi= s > > protocol. I can find nothing in the document that indicates to the > > client > > how it shall determine what sort of URI to use is the resource part of > > the query or what the semantics of any given URI are supposed to be. I > > suspect that the semantics are so underspecified that there could not > > possibly be interoperable implementations without lots of out-of-band > > information. > > If you are seeking information related to a user account, then the > specification recommends the use of the "acct" URI. Use of other URI typ= es is > not fully specified and no recommendations are given. Syntactically, the > server behavior will be the same for any type of URI. The only gap is kn= owing > what set of link relations type to expect for a given URI scheme. Do you= use > "mailto" or "acct"? We had a lot of debate over that for years and settl= ed on > "acct". > > So what should one expect if one issued a query like this? > > $ curl https://packetizer.com/.well- > known/webfinger?resource=3Dhttp://www.packetizer.com > > I would expect it to return information about that URL. The link relatio= n > types returned might be "copyright" or "author" or other. It would be ty= pes > that are valid for a web page. > > > The first example provides a mapping from an email address (or perhaps = a > > mailto URI; that's not clear) to an acct URI, but neither the example > > nor > > anything in the rest of the document gives any clue why you would choos= e > > to query an "acct" URI based on the contents of an email message. I > > think > > the assumption is that if there is an email address, there must be some > > sort of "account" associated with it, and therefore querying the host o= n > > the RHS of the "@" for that account will get some interesting > > information. But I don't see any reason to choose an "acct" scheme over > > "mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the > > choice is semantics-free. > > Again, this was a 3 year long discussion. You're right that it could be > anything. We even argued to use no URI at all and just use "user@domain"= . > However, it finally decided to use "acct". It identifies an account at a > domain. It does not identify an email address. Using mailto URI didn't = fit > Twitter, for example, as there is no email. The same can be said for oth= er > services, including photo sharing services, blogs, and so forth. If you = want > to query information about my account on a social networking site, it wou= ld > not be an email address that would be used. > > > Reading the above alongside 3.3 makes me all the more suspicious: In 3.= 3 > > (also mentioned in 4.5), a "mailto" URI gets you configuration > > information for all email configuration parameters. Does an "acct" URI > > get you configuration information for email *and* xmpp *and* sip *and* > > calendaring *and* all other configuration information (since you are no > > longer asking for a particular protocol, but rather the general account > > information), or do you only get "information" about the person and not > > their account? (I might also insert privacy and security worries here, > > but see Stephen's DISCUSS regarding that.) How can the client know what > > sort of information it can ask for and how to get it? And for that > > matter, how does the server tell what information to pass back? You'd > > think there would be a hint about this in 4.3, but "rel" only seems to > > provide for the client to request those things that the client already > > knows about it. In particular, there appears to be no way to say, "Give > > me user provided information, but not config information" or "Give me > > config information, but not blog entries". > > The "rel" parameter is just a filter to reduce the size of the JRD down t= o > only the particular link relation types of interest (e.g., "vcard", "jcar= d", > "blog", "profile"). > > If you wish to query for information about a person, you query the person= 's > acct URI. The other examples, such as use of "mailto" or "device" are ju= st > examples of what is possible. As an example of how I would expect to us= e > "mailto", you can see this presentation: > http://www.ietf.org/proceedings/86/slides/slides-86-aggsrv-3.pdf > > However, the aggsrv group could say (if they even elected to use WF) that= the > "mailto" URI shall be used to query for configuration information related= to > email. I don't know what they will recommend. The WF draft shows an exa= mple > of how one could use an email URI, but it is a non-working example since = none > of the link relation types are defined. > > The WF spec does not go into detail on what a client should expect to rec= eive > for any URI scheme, but only recommends use of "acct" to get user account > information. The link relations returned from such a query are in use to= day > and some will be standardized (as that's next on the "to-do" list). > > > I find the semantics for "device" in 3.4 all-the-more mysterious. As fa= r > > as I can tell, this URI scheme simply means, "Give me all of the > > information for the entire host." > > Well, "device" does not exist and that will likely never exist. The only > point with that was to demonstrate how any URI scheme could be used, incl= uding > one intended for device identification. And if we had one for device > identification, it might return that kind of information. Again, this is= just > a non-normative example showing broadly what we can do with WF. > > > Again, the semantics of all of these interactions seem so underspecifie= d > > that I don't understand how interoperation is supposed to happen. > > Yeah, this definitely was not intended to be defined. When or if we deci= ded > to use WF for this purpose, it would be defined in another spec. However= , I > would expect the syntax and procedures for making the request to the serv= er to > be the same as querying for an account URI. > > > This also leaves me with the question about why the resource query part > > is a URI at all. It seems to me that the resource you are asking about > > is > > not a URI (or URN) at all; it's simply an identifier for an entity that > > the particular host knows about. Given that, why not pass a simple > > identifier? (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ > > for example.) If the scheme is not providing any particular semantics > > about the response, I see no reason to provide the scheme. If more > > semantics (beyond rel) are needed, another parameter indicating the typ= e > > of identifier being used seems much more appropriate than using a URI > > scheme. > > URI schemes allow for a natural separation. And, a WF server for a domai= n > could know all kinds of information about itself. It would know who auth= ored > web pages on the domain. It would know information about account holders= on > the domain. There was back and forth, as I noted above, as to whether we > needed "acct" or not. In the end, it was agreed to identify information = about > users -- stuff users share or that are shared within a company (e.g., emp= loyee > pictures or contact info). > > Years of work on this topic resulted in RFC 6415. RFC 6415, in fact, is = what > people had envisaged for "webfinger". It defined a well-known location c= alled > "host-meta" and a different link relation called "LRDD" for querying > information about a particular URI. > > The challenge with RFC 6415 is that it too so long to move forward that b= y the > time it was done, JSON had become the favored syntax language, people wan= ted > to mandate use of TLS for a variety of security reasons, people did not w= ant > two round trips to the server to return the JRD. So, we set about fixing= all > of the gripes people had with RFC 6415. We removed XML entirely, we full= y > documented JRD, the server does the merging of host-meta and LRDD documen= ts > (though not described that way for simplicity's sake), TLS was mandated, = and > we introduced the "rel" parameter to allow for selecting one or a few typ= es of > links to reduce the size of the document. > > RFC 6415 uses any type of URI. This is useful, since the URI scheme does > provide separation in namespace and since we do want to allow retrieval o= f a > set of link relations for those URIs -- web pages (http), user accounts > (acct), tel URIs (tel), etc. The only point of confusion, I think, is "w= hat > do we do with mailto, sip, h323, telnet, etc.?" Well, we're not prescrib= ing > that. That would be documented in a document that wants to use those oth= er > URIs. They might be used to configure a device or help route a call or > whatever. We only have examples of possible use, but we do not specify t= heir > use. > > Paul > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger 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 barryleiba@gmail.com Thu Apr 11 15:30:49 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15EC21F891D; Thu, 11 Apr 2013 15:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.689 X-Spam-Level: X-Spam-Status: No, score=-101.689 tagged_above=-999 required=5 tests=[AWL=-1.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_DIET=2.3, 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 jr8cbx8K2beX; Thu, 11 Apr 2013 15:30:48 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id AAC5321F8940; Thu, 11 Apr 2013 15:30:46 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id r10so2052029lbi.22 for ; Thu, 11 Apr 2013 15:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=XCbn1GGgHj4yZrX+F5sotDVGlUd1C+1rLCZEaq/ix5U=; b=BTkMvoJ12B6ecqqfrwgab5t/5n9GGRH5M5X1/SXmmtrb3CYZgOf3dJBWOT9cO/kXYI 1tOoD8xr8aO+K6EPCHvLm3h982rspD294BfvcXc848VJq9Hh3BKv1JbxroJx5j7T0KGP VqUEnHirLXwy2/5zh3GN8IkjTcPAwcQLjIpBUooOnd3k+tWmwCoswihUTip0xKAQbJN+ hfbGpz7gq/xEUJeEGbcqRQxh1IiQO7HhE+5ouc12luvCpj43xqCefu4/U8hjqqvqq02L oMNK3TBf4XOgJBvT9ID0y1EClK0df/jhmjtWgZ7bvUXo8FhiL1KT6IKgEVgYuc5BupeQ /u2A== MIME-Version: 1.0 X-Received: by 10.152.116.73 with SMTP id ju9mr3037823lab.54.1365719445915; Thu, 11 Apr 2013 15:30:45 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.117.225 with HTTP; Thu, 11 Apr 2013 15:30:45 -0700 (PDT) Date: Thu, 11 Apr 2013 18:30:45 -0400 X-Google-Sender-Auth: VsjhTkv1kfKn772f-CEdSJfmimM Message-ID: From: Barry Leiba To: draft-ietf-appsawg-webfinger.all@tools.ietf.org, "appsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: "webfinger@ietf.org" , The IESG Subject: [webfinger] All the DISCUSS positions on draft-ietf-appsawg-webfinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 22:30:50 -0000 > Some Aggressive AD has entered the following ballot position for > draft-ietf-appsawg-webfinger-12: Discuss OK, well, I know this is how it feels, and, as we have six DISCUSS positions on the document, some of them quite involved, with many sub-issues, I know it's quite frustrating. Let me try to manage the discussion and get us moving forward. I'd like to start breaking the discussion down and addressing one major issue at a time, avoiding 10-page, unreadable messages. When things get that involved and we're trying to deal with so many issues at once, we lose track of where we are in the different sub-threads, screw up the interactions among issues, and generally whirl like dervishes. After each major issue is settled (or we think it is), I'd like the editors to post another revised I-D with text changes for that issue. We'll then confirm that the issue has been put to bed, and start on the next. +++ ACTION: Appsawg Chairs +++ I think it would be useful for the appsawg chairs to start creating issues in the tracker for each main item that the ADs have identified. Please see the IESG Evaluation record here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ Please work with the ADs to concisely list their major issues, put in a form where they can be itemized in the tracker. DO NOT WORRY about getting everything on the first pass. If we can identify, say, half a dozen major issues, we can do another pass on it for the next set of lesser issues when these are sorted out. +++ ACTION: Document editors +++ While we sort out the issues, please post a revised I-D that includes any agreed-to changes that you've accumulated so far. This will give us a new starting point for discussion, making sure that we don't have to revisit the things we've already closed on. As a starting point for the issue discussion, let me set out two major issues that I want to go with first: 1. Privacy of the information returned by the WF server. I think the intent here is that WF servers will generally be used to get information that is already exposed through other means (for instance, getting someone's Facebook profile as a JRD through WF, as opposed to getting it by visiting the Facebook profile page through HTTP). The information returned could vary, depending upon whether and with what identity the client is authenticated. In other use cases (such as with the acct: URI), the intent is specified in Section 8.2, "WebFinger MUST NOT be used to provide any personal data to any party unless explicitly authorized by the person whose information is being shared. Publishing one's personal data within an access-controlled or otherwise limited environment on the Internet does not equate to providing implicit authorization of further publication of that data via WebFinger." Some ADs think that this is not sufficiently specified: there's insufficient discussion of the use cases, the access controls, the authentication, and so on. Let's start by sorting this out, and making sure that what's in the document makes the intent and responsibility clear. After that's done... 2. What information is actually returned, and how can the client understand it? The JRD includes, in the "links" array, items with "rel" values. For a client to understand what it gets in the JRD, it needs to understand the "rel" values. But there's no base set, and, so, with the base WF protocol as specified here, no client will understand anything it gets from any WF server. Want to know where my blog resides? The example in Section 3.1 isn't going to help, because there's no "rel" defined that will tell you that. Want my email address? My full name? My telephone number? My preferred IM system and identifier? Sorry, no "rel"s defined to tell you that. We need to have a discussion about the best way to set up (1) a starting set of reasonable "rel" values that will provide useful information for the initial use cases, and (2) a recommended mechanism for extending that interoperably. I think this should keep us busy for a bit. Editors, chairs... can you get started on your action items, above? Once we have a revised I-D, let's get the discussion going on issue 1 above. And let's please keep the distribution list that's on this message for the whole conversation (though you can remove me from explicit copy: I'll get the messages on the webfinger and iesg lists): To: draft-ietf-appsawg-webfinger.all@tools.ietf.org CC: iesg@ietf.org>, webfinger@ietf.org, appsawg-chairs@tools.ietf.org Thanks, all, and let's work on resolving these issues. Barry, Applications AD From paulej@packetizer.com Thu Apr 11 20:21:56 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9C521F86C5; Thu, 11 Apr 2013 20:21:55 -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 CDIW+WsApd+n; Thu, 11 Apr 2013 20:21:51 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC5421F86C3; Thu, 11 Apr 2013 20:21: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 r3C3Lho6011135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Apr 2013 23:21:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1365736904; bh=RHvO3+9xF3Wma5wQqM0xgOzumvZ3ITIZ8a8mYF0I0rw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Qr7c1XWjPu9s+afvykZSA/O/UQdyz1C7XJ8dxtCy5+XOYsi30p/xvisErulhVd6hv aEFaC4aOgXJ7+e10rbkchQ8LiTWlE3vNSAKRqVwbtbrn2HKjWe6KcOaOqutIqBs82D tLhbcpXGkF+Nuk2OrEJ/ZSIdhe9DAfctCL0BM1Yk= From: "Paul E. Jones" To: "'Barry Leiba'" , , References: In-Reply-To: Date: Thu, 11 Apr 2013 23:21:53 -0400 Message-ID: <0ee601ce372c$e1bdbcc0$a5393640$@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: AQKF+rJ19Sq3YwmLzkQPsCCUeEFrLpdiZADQ Content-Language: en-us Cc: webfinger@ietf.org, 'The IESG' Subject: Re: [webfinger] All the DISCUSS positions on draft-ietf-appsawg-webfinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 03:21:57 -0000 Barry, > +++ ACTION: Document editors +++ > While we sort out the issues, please post a revised I-D that includes > any agreed-to changes that you've accumulated so far. This will give > us a new starting point for discussion, making sure that we don't have > to revisit the things we've already closed on. I have quite a number of edits to the text already. I will give it to a few folks for review and try to post a revised document on Monday evening. Paul From paulej@packetizer.com Tue Apr 16 19:55:41 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CC821F972C for ; Tue, 16 Apr 2013 19:55:41 -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 chBZicBJvzf3 for ; Tue, 16 Apr 2013 19:55:41 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECE221F9725 for ; Tue, 16 Apr 2013 19:55:40 -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 r3H2tcWB025923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 16 Apr 2013 22:55:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1366167339; bh=28T+DSuzTpB7AHtsemwm6GIKY4PHc0ItMTrvFrbUy8M=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=cSllkJFNipDWZl4xzocAzUaPObvQClLy1n4pg2pQ6eHwJVeuP9rsjn3kAv9+oyXgz 5u283O+8/k8ietXWSy5qUrB95RF/CORdM7uP9E0OhG2+0Xpi/YFjmIlMYYxgHie3gn I3GRIAK+4OUFC5+Xvw7pFrLKcgH/AGhsDWQbXiXk= From: "Paul E. Jones" To: References: <20130417025405.14655.86603.idtracker@ietfa.amsl.com> In-Reply-To: <20130417025405.14655.86603.idtracker@ietfa.amsl.com> Date: Tue, 16 Apr 2013 22:55:43 -0400 Message-ID: <026801ce3b17$0e958690$2bc093b0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGHUJRrHTwH9MdWVq1dAaZCxMPA0JlnjOPw Content-Language: en-us Subject: [webfinger] FW: New Version Notification - draft-ietf-appsawg-webfinger-13.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 02:55:41 -0000 FYI > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, April 16, 2013 10:54 PM > To: appsawg-chairs@tools.ietf.org; draft-ietf-appsawg- > webfinger@tools.ietf.org; barryleiba@computer.org; > presnick@qti.qualcomm.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx; > bclaise@cisco.com; joelja@bogus.com > Subject: New Version Notification - draft-ietf-appsawg-webfinger-13.txt > > > A new version (-13) has been submitted for draft-ietf-appsawg-webfinger: > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.txt > > Sub state has been changed to AD Followup from Revised ID Needed > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-13 > > IETF Secretariat. From melvincarvalho@gmail.com Wed Apr 17 01:31:39 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E09221F8A80 for ; Wed, 17 Apr 2013 01:31: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, HTML_MESSAGE=0.001, 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 yD5U0GFaLoXx for ; Wed, 17 Apr 2013 01:31:38 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D379221F89A6 for ; Wed, 17 Apr 2013 01:31:37 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id fr10so1250104lab.17 for ; Wed, 17 Apr 2013 01:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ayb7XyX3aX1GebLCAgAGCV05iWgHIHhRP/0ZFgnY/yk=; b=EnysZ8I3mrTg0AVNiJQimov1YYKdGwBsZq7XB8A/1ajluU6lXub8nFS0OPHizH+c4g oqU2JfmihERQPJrGHX5zvMs+O+4U44iMA+7fiIInHbfYMnCnWochJ+3Sr5BqtHaLI+ZV GNeduCPI/czNy6Tm6sNpDZQaqXgEEDGjrPde4hs+8DuVJ/6USggCAKusyFlHp0ZzUryP cOkCBQ1jOY2V6LVRkdM8pUg++M3UFV4eouvFjYlcQ6GwFbHfS4RbxcwQ1ka0TUz9HyHL n883p3CKwHeJ47ioNH/cIywta0BIggNQcmcH/YJn+zcFXlbzTUNCvXvtJj1TI+R3Okkr kM5Q== MIME-Version: 1.0 X-Received: by 10.112.131.71 with SMTP id ok7mr3056435lbb.135.1366187496781; Wed, 17 Apr 2013 01:31:36 -0700 (PDT) Received: by 10.112.143.38 with HTTP; Wed, 17 Apr 2013 01:31:36 -0700 (PDT) In-Reply-To: <026801ce3b17$0e958690$2bc093b0$@packetizer.com> References: <20130417025405.14655.86603.idtracker@ietfa.amsl.com> <026801ce3b17$0e958690$2bc093b0$@packetizer.com> Date: Wed, 17 Apr 2013 10:31:36 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=047d7b3434047141ca04da8a50c4 Cc: webfinger Subject: Re: [webfinger] FW: New Version Notification - draft-ietf-appsawg-webfinger-13.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 08:31:39 -0000 --047d7b3434047141ca04da8a50c4 Content-Type: text/plain; charset=ISO-8859-1 On 17 April 2013 04:55, Paul E. Jones wrote: > FYI > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Tuesday, April 16, 2013 10:54 PM > > To: appsawg-chairs@tools.ietf.org; draft-ietf-appsawg- > > webfinger@tools.ietf.org; barryleiba@computer.org; > > presnick@qti.qualcomm.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx; > > bclaise@cisco.com; joelja@bogus.com > > Subject: New Version Notification - draft-ietf-appsawg-webfinger-13.txt > > > > > > A new version (-13) has been submitted for draft-ietf-appsawg-webfinger: > > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.txt > Hi Paul, I just noticed something odd. In most EAV description languages, the subject term is optional. The is true, for example, in XRD and RDF. I've noticed in section 4.4.1. The "subject" member MUST be present in the JRD. This would make JRD as a serialization inconsistent, and *perhaps*, in some cases not 100% interoperable with others. I was just wondering if there was a conscious decision in making this change when moving from XRD -> JRD or if it was unintended. > > > > Sub state has been changed to AD Followup from Revised ID Needed > > > > > > The IETF datatracker page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > > > > Diff from previous version: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-13 > > > > IETF Secretariat. > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > --047d7b3434047141ca04da8a50c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 17 April 2013 04:55, Paul E. Jones <paulej@packetizer.com> wrote:
FYI

> -----Original Message-----
> From: internet-drafts@ietf= .org [mailto:internet-draft= s@ietf.org]
> Sent: Tuesday, April 16, 2013 10:54 PM
> To: appsawg-chairs@to= ols.ietf.org; draft-ietf-appsawg-
> webfinger@tools.ietf.org; barryleiba@computer.org;=
> presnick@qti.qualcomm.com= ; stephen.farrell@cs.tcd.i= e; rlb@ipv.sx;
> bclaise@cisco.com; joelja@bogus.com
> Subject: New Version Notification - draft-ietf-appsawg-webfinger-13.tx= t
>
>
> A new version (-13) has been submitted for draft-ietf-appsawg-webfinge= r:
> http://www.ietf.org/internet-drafts/draft-i= etf-appsawg-webfinger-13.txt

Hi Pau= l, I just noticed something odd.

In most EAV description languages, the subject term is optio= nal.=A0 The is true, for example, in XRD and RDF.

I'v= e noticed in section 4.4.1.

   The "subject" member M=
UST be present in the JRD.

This would make JRD as a serialization inconsistent, and *pe= rhaps*, in some cases not 100% interoperable with others.

I was just wondering if there was a conscious decision in making this chan= ge when moving from XRD -> JRD or if it was unintended.

=A0
>
> Sub state has been changed to AD Followup from Revised ID Needed
>
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-= webfinger/
>
> Diff from previous version:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ap= psawg-webfinger-13
>
> IETF Secretariat.


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

--047d7b3434047141ca04da8a50c4-- From barryleiba@gmail.com Wed Apr 17 06:42:56 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA55B21F86CB; Wed, 17 Apr 2013 06:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 3gd6dGLjHjzD; Wed, 17 Apr 2013 06:42:56 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CFCC621F8480; Wed, 17 Apr 2013 06:42:55 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id fn20so1508363lab.15 for ; Wed, 17 Apr 2013 06:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VdwgWkTSDqzEDoARkie3GwFWBlkdwkBqn9p5gwaeugQ=; b=z5wk72YULejFKHYKeKprPfSLGqgY1xDkI/LmAkFJVc6YaqYDiDCTTxXuDR+glgPOi2 VHS3RbABBZ28KB7F9R5kk9E8wBXy/FJTRSLNNQuke9Yx9sEA8L/VuM81VGbH5ghtggOG cs+KvGcvqU3k+N6bfZSOBedSkLkCSbij/WsD/you/IUNWg9uv4blas3/i9jnaHQEHTrO 1OmdscrlN8LlI6c0ZfPcIpr/4cABI94SkazsG/2ZGaAF3b0AVi8+CHc2i+GckYkcbQWL CrOaWm/gu5uODu5tmt7QaC9lcn89aDcehGqgjOZhBAxQco+GOh0QQICuN/vmOTlvZiDh ejLg== MIME-Version: 1.0 X-Received: by 10.152.26.166 with SMTP id m6mr3556195lag.4.1366206174669; Wed, 17 Apr 2013 06:42:54 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.117.225 with HTTP; Wed, 17 Apr 2013 06:42:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Apr 2013 09:42:54 -0400 X-Google-Sender-Auth: 9_AqY8baA-eD3tLJozB1kopq744 Message-ID: From: Barry Leiba To: draft-ietf-appsawg-webfinger.all@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , joel jaeggli , Pete Resnick , Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 Cc: "webfinger@ietf.org" , The IESG Subject: Re: [webfinger] All the DISCUSS positions on draft-ietf-appsawg-webfinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 13:42:57 -0000 OK, everyone: Paul has released -13, and Stephen has updated his DISCUSS text to account for this version. Thanks, both of you, and I ask the other ADs with DISCUSS positions to do the same (I have explicitly put you in the "to" list here) -- and there's still an action item for the appsawg chairs to help them with this, and to record the issue list: > +++ ACTION: Appsawg Chairs +++ > I think it would be useful for the appsawg chairs to start creating > issues in the tracker for each main item that the ADs have identified. > Please see the IESG Evaluation record here: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ > > Please work with the ADs to concisely list their major issues, put in > a form where they can be itemized in the tracker. DO NOT WORRY about > getting everything on the first pass. If we can identify, say, half a > dozen major issues, we can do another pass on it for the next set of > lesser issues when these are sorted out. So, a reminder of how I'd like to run this discussion: > I'd like to start breaking the discussion down and addressing one > major issue at a time, avoiding 10-page, unreadable messages. When > things get that involved and we're trying to deal with so many issues > at once, we lose track of where we are in the different sub-threads, > screw up the interactions among issues, and generally whirl like > dervishes. > > After each major issue is settled (or we think it is), I'd like the > editors to post another revised I-D with text changes for that issue. > We'll then confirm that the issue has been put to bed, and start on > the next. My next message will kick us off into the first issue. Barry, Applications AD From barryleiba@gmail.com Wed Apr 17 06:49:42 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA2621F86FA; Wed, 17 Apr 2013 06:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 pEc24HGiKUeW; Wed, 17 Apr 2013 06:49:42 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE4F21F8709; Wed, 17 Apr 2013 06:49:41 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id fq13so409193lab.7 for ; Wed, 17 Apr 2013 06:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zaH950TdloRBCLWttNfBczh+Ftwsh0jb3Pk1eBkW6hU=; b=cnBwNnT7CVs1sLM5BeEuSAjLq/LTENJ+JVajKgw8WxJ0bK/OcVzbPAZrqXvMq9AfTl Xw8pO4nzWWgpqAZMHHUAXX1aF9SZ8vqKMqwFam0pbqSmTMr6dtHXnUwmz+m2oblAGhjM 6fzo3+kC9r5wJe1f5HING5m4bPzlOUwjduZvs94rl1fa4Tg4Fv/imZy5uGpnL8imjwQq 8TJIcNnEeY4P4qh6SNgwEKddCtoKuC3OPTdNPZudmZX2BSJSkrykj35xNlUrrvHi7xCY YGctA53LrYftLkzX5l3Yt17gyVoRA44xlBh7sXwribsnegGGmJcAgo5leyHg0tAhpvBj B0cA== MIME-Version: 1.0 X-Received: by 10.112.141.71 with SMTP id rm7mr3216746lbb.7.1366206580406; Wed, 17 Apr 2013 06:49:40 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.117.225 with HTTP; Wed, 17 Apr 2013 06:49:40 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Apr 2013 09:49:40 -0400 X-Google-Sender-Auth: vSGrLimMLaW9SCJi4Hg9TQ_96eI Message-ID: From: Barry Leiba To: draft-ietf-appsawg-webfinger.all@tools.ietf.org, "appsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: "webfinger@ietf.org" , The IESG Subject: Re: [webfinger] All the DISCUSS positions on draft-ietf-appsawg-webfinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 13:49:42 -0000 We're ready to wade into the first issue: > 1. Privacy of the information returned by the WF server. > > I think the intent here is that WF servers will generally be used to > get information that is already exposed through other means (for > instance, getting someone's Facebook profile as a JRD through WF, as > opposed to getting it by visiting the Facebook profile page through > HTTP). The information returned could vary, depending upon whether > and with what identity the client is authenticated. In other use > cases (such as with the acct: URI), the intent is specified in Section > 8.2, "WebFinger MUST NOT be used to provide any personal data to any > party unless explicitly authorized by the person whose information is > being shared. Publishing one's personal data within an > access-controlled or otherwise limited environment on the Internet > does not equate to providing implicit authorization of further > publication of that data via WebFinger." > > Some ADs think that this is not sufficiently specified: there's > insufficient discussion of the use cases, the access controls, the > authentication, and so on. Let's start by sorting this out, and > making sure that what's in the document makes the intent and > responsibility clear. Stephen, I note that your current DISCUSS has move this out of the major issue list and into the comments: > - 8.2, this is outstandingly glib: "If one does not wish to > share certain information with the world, do not allow that > information to be freely accessible on the Internet or > discoverable via WebFinger" - most users are never given a > choice as to whether or not much of their information is > freely accessible or not. I think the best that can be done > with that is to delete it. Is this general issue still of top importance to discuss? I think it's really Stephen and Richard who need to weigh in on that. And Joel isn't happy with the way 2119 language is used to express this: > 8.2 > > Further, WebFinger MUST NOT be used to provide any personal data to > any party unless explicitly authorized by the person whose > information is being shared. > > This is a usage guideline not a part of the protocol specification. At a > minimum it should use non-normative language. probably it should be replaced > with a description of the potential for exposure. At this point, I think we're not far from settling the general issue at hand. Stephen, Richard: where do you think we stand on it in version -13? (I realize, Stephen, that you have other concerns about privacy; I'm explicitly not getting to those yet. First I want to cover the general discussion about how webfinger provides access to information.) Barry From stephen.farrell@cs.tcd.ie Wed Apr 17 09:03:30 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C3D21E804D; Wed, 17 Apr 2013 09:03:30 -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 F5ZqhjB4X-dC; Wed, 17 Apr 2013 09:03:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id AF19921E8049; Wed, 17 Apr 2013 09:03:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4F260BE5B; Wed, 17 Apr 2013 17:03:07 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvyoI2jpTuso; Wed, 17 Apr 2013 17:03:07 +0100 (IST) Received: from [IPv6:2001:770:10:203:cc2e:c1ad:4c7b:1552] (unknown [IPv6:2001:770:10:203:cc2e:c1ad:4c7b:1552]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0F2CABE47; Wed, 17 Apr 2013 17:03:07 +0100 (IST) Message-ID: <516EC7BB.2050409@cs.tcd.ie> Date: Wed, 17 Apr 2013 17:03:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "webfinger@ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] All the DISCUSS positions on draft-ietf-appsawg-webfinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 16:03:31 -0000 Hiya, On 04/17/2013 02:49 PM, Barry Leiba wrote: > We're ready to wade into the first issue: Ok. > >> 1. Privacy of the information returned by the WF server. >> >> I think the intent here is that WF servers will generally be used to >> get information that is already exposed through other means (for >> instance, getting someone's Facebook profile as a JRD through WF, as >> opposed to getting it by visiting the Facebook profile page through >> HTTP). The information returned could vary, depending upon whether >> and with what identity the client is authenticated. In other use >> cases (such as with the acct: URI), the intent is specified in Section >> 8.2, I'll start here: >> "WebFinger MUST NOT be used to provide any personal data to any >> party unless explicitly authorized by the person whose information is >> being shared. I do think the above isn't well specified. And that does touch on my discuss point #1, even if that wasn't very clear (my fault;-) I agree that we're probably better off starting with fixing this bit though regardless of how discuss points are written up. The MUST NOT could be read to mean that Alice has to say who is and who is not allowed access to Alice's information when she decides to make that available via WF. Its not clear that the "explicitly authorized" means only "by Alice for whoever the WF service allows" and not e.g. "by Alice for Bob" or "by Alice for her friends" or "by Alice for people in .de" Now I know that the intent is not to require Alice to specify who can access her stuff, but it could be read to mean that, e.g. by some over-zealous regulator. (And that over-zealous regulator might then say that having the automated access in 3.1 succeed isn't ok, which is the link to my discuss point #1.) I think what was meant was more like: WebFinger MUST NOT be used to provide any personal data unless publishing that data via WebFinger by the relevant service was explicitly authorized by the person whose information is being shared. I think that (or an equivalent) were stated in 8.2 then that'd be better and would break the link with my discuss point#1. (It doesn't clear discuss point#1 though.) It might also imply that if the terms of service change then maybe the WF operator needs to ask Alice again, I don't know. (Not that they would or anything;-) >> Publishing one's personal data within an >> access-controlled or otherwise limited environment on the Internet >> does not equate to providing implicit authorization of further >> publication of that data via WebFinger." >> >> Some ADs think that this is not sufficiently specified: there's >> insufficient discussion of the use cases, the access controls, the >> authentication, and so on. Let's start by sorting this out, and >> making sure that what's in the document makes the intent and >> responsibility clear. > > Stephen, I note that your current DISCUSS has move this out of the > major issue list and into the comments: > >> - 8.2, this is outstandingly glib: "If one does not wish to >> share certain information with the world, do not allow that >> information to be freely accessible on the Internet or >> discoverable via WebFinger" - most users are never given a >> choice as to whether or not much of their information is >> freely accessible or not. I think the best that can be done >> with that is to delete it. Nah, that was always just a non-blocking comment. I do still think the statement is glib though, and would be better deleted. Most real users don't have a real choice here and pretending they do is bogus. They do have a choice to use or not use some service, but at a much higher level than we generally mean with that term. E.g. they might use or not use FB or G+ but after that most of the rest is just pretence that the user has a real choice as to what else happens with their data. > Is this general issue still of top importance to discuss? I think > it's really Stephen and Richard who need to weigh in on that. And > Joel isn't happy with the way 2119 language is used to express this: > >> 8.2 >> >> Further, WebFinger MUST NOT be used to provide any personal data to >> any party unless explicitly authorized by the person whose >> information is being shared. >> >> This is a usage guideline not a part of the protocol specification. At a >> minimum it should use non-normative language. probably it should be replaced >> with a description of the potential for exposure. I would argue that its a valid MUST NOT since it addresses a security/privacy issue even if not an interop issue, so I'd rather keep the 2119 term. I agree that might not be a winning argument. For security it would be valid I think to say you MUST NOT use a crap PRNG which is arguably similar enough. We don't have such a consensus for privacy related statements afaik, though perhaps we ought try to develop that. In any case, the MUST NOT doesn't hurt anyone and does help some folks, so I'd say keeping it is better. (I'd live with a non-normative statement, if need be.) > At this point, I think we're not far from settling the general issue > at hand. Stephen, Richard: where do you think we stand on it in > version -13? > > (I realize, Stephen, that you have other concerns about privacy; I'm > explicitly not getting to those yet. First I want to cover the > general discussion about how webfinger provides access to > information.) Tried to stick to that above. Let's see how it pans out, Cheers, S. > > Barry > From Michael.Jones@microsoft.com Wed Apr 17 10:30:04 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF01D21F861B for ; Wed, 17 Apr 2013 10:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.096, 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 OzdrS5Pzgv59 for ; Wed, 17 Apr 2013 10:30:02 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF8321F8693 for ; Wed, 17 Apr 2013 10:30:01 -0700 (PDT) Received: from BY2FFO11FD024.protection.gbl (10.1.15.202) by BY2FFO11HUB016.protection.gbl (10.1.14.89) with Microsoft SMTP Server (TLS) id 15.0.675.0; Wed, 17 Apr 2013 17:30:00 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD024.mail.protection.outlook.com (10.1.15.213) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Wed, 17 Apr 2013 17:29:59 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Wed, 17 Apr 2013 17:29:36 +0000 From: Mike Jones To: "Paul E. Jones" , "webfinger@ietf.org" Thread-Topic: New restriction added in WebFinger -13 needs to be relaxed or clarified Thread-Index: Ac47kSFynksU+fymSJu9J3hIf7ysmA== Date: Wed, 17 Apr 2013 17:29:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436764B4CA@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.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436764B4CATK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(69234004)(377454001)(51704004)(199002)(189002)(56776001)(80022001)(51856001)(18277545001)(53806001)(54316002)(46102001)(56816002)(66066001)(54356001)(55846006)(18276755001)(33656001)(77982001)(59766001)(16236675002)(15202345002)(512954001)(76482001)(16406001)(74502001)(5343635001)(4396001)(47736001)(49866001)(74662001)(47976001)(50986001)(65816001)(5343655001)(44976003)(81342001)(564824004)(20776003)(71186001)(69226001)(63696002)(6806003)(81542001)(47446002)(79102001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB016; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 081904387B Subject: [webfinger] New restriction added in WebFinger -13 needs to be relaxed or clarified X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 17:30:05 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436764B4CATK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This new paragraph was added in WebFinger -13: The host to which a WebFinger query is issued is significant. If the query= target contains a "host" portion (Section 3.2.2 of RFC 3986), then the hos= t to which the WebFinger query is issued MUST be the same as the "host" por= tion of the query target. If the query target does not contain a "host" por= tion, then the client MAY choose a host to which it directs the query based= on local policy. I'm concerned that this paragraph just ruled out using WebFinger to query f= or account identifiers at a host that contain another hostname in the accou= nt identifier. This is not a hypothetical situation. For instance, I have= a Google account whose identifier is mbj@microsoft.com. It appears that the new paragraph makes this well-formed and usefu= l query illegal: GET /.well-known/webfinger?resource=3Dacct%3Ambj%40microsoft.com HTTP/1.1 Host: google.com I believe that the new paragraph either needs to be removed or clarified in= some manner to make it clear that a WebFinger server may respond to resour= ces that it is authoritative for even if the resource being queried contain= s a different domain name. Another example of a situation where one domain is authoritative for others= is Microsoft's Internet mail service domains. At various times, the prefe= rred domain has been msn.com, hotmail.com, live.com, and outlook.com. It's= perfectly reasonable to query for an identifier containing msn.com at live= .com, for instance. I'd suggest replacing this paragraph with something like the following inst= ead: The host to which a WebFinger query is issued is significant. Different ho= sts hold authoritative information for different identifiers. WebFinger se= rvers MUST NOT supply information for identifiers that they are not authori= tative for. Note, however, that a WebFinger server at one domain may be au= thoritative for identifiers containing another domain. For instance the se= rver example.com may host an account whose identifier is acct:mary@example.= org, and queries may be sent to the WebFinger server at example.com about t= he account acct:mary@example.org that is hosted there. -- Mike -----Original Message----- From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Paul E. Jones Sent: Tuesday, April 16, 2013 7:56 PM To: webfinger@ietf.org Subject: [webfinger] FW: New Version Notification - draft-ietf-appsawg-webf= inger-13.txt FYI > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Tuesday, April 16, 2013 10:54 PM > To: appsawg-chairs@tools.ietf.org; = draft-ietf-appsawg- > webfinger@tools.ietf.org; barryleiba@com= puter.org; > presnick@qti.qualcomm.com; stephen.farr= ell@cs.tcd.ie; rlb@ipv.sx; > bclaise@cisco.com; joelja@bogus.com > Subject: New Version Notification - > draft-ietf-appsawg-webfinger-13.txt > > > A new version (-13) has been submitted for draft-ietf-appsawg-webfinger: > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.tx > t > > Sub state has been changed to AD Followup from Revised ID Needed > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-13 > > IETF Secretariat. _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger --_000_4E1F6AAD24975D4BA5B16804296739436764B4CATK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This new paragraph was added in WebFinger -13:

 

The host to which a We= bFinger query is issued is significant.  If the query target contains = a “host” portion (Section 3.2.2 of RFC 3986), then the host to = which the WebFinger query is issued MUST be the same as the “host” portion of the query target. If the query target= does not contain a “host” portion, then the client MAY choose = a host to which it directs the query based on local policy.

 

I’m concerned that this paragraph just rule= d out using WebFinger to query for account identifiers at a host that conta= in another hostname in the account identifier.  This is not a hypothet= ical situation.  For instance, I have a Google account whose identifier is mbj@micro= soft.com.  It appears that the new paragraph makes this well-forme= d and useful query illegal:

 

GET /.well-known/webfinge= r?resource=3Dacct%3Ambj%40microsoft.com HTTP/1.1
Host: google.com

 

I believe that the new paragraph either needs to = be removed or clarified in some manner to make it clear that a WebFinger se= rver may respond to resources that it is authoritative for even if the reso= urce being queried contains a different domain name.

 

Another example of a situation where one domain i= s authoritative for others is Microsoft’s Internet mail service domai= ns.  At various times, the preferred domain has been msn.com, hotmail.= com, live.com, and outlook.com.  It’s perfectly reasonable to query for an identifier containing msn.com at live.com, for = instance.

 

I’d suggest replacing this paragraph with s= omething like the following instead:

 

The host to which a We= bFinger query is issued is significant.  Different hosts hold authorit= ative information for different identifiers.  WebFinger servers MUST N= OT supply information for identifiers that they are not authoritative for.  Note, however, that a WebFinger server at= one domain may be authoritative for identifiers containing another domain.=   For instance the server example.com may host an account whose identi= fier is acct:mary@example.org, and queries may be sent to the WebFinger server at example.com about the account acct:= mary@example.org that is hosted there.

 

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

 

-----Original Message-----
From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Paul E. Jones
Sent: Tuesday, April 16, 2013 7:56 PM
To: webfinger@ietf.org
Subject: [webfinger] FW: New Version Notification - draft-ietf-appsawg-webf= inger-13.txt

 

FYI

 

> -----Original Message-----

> From: internet-drafts= @ietf.org [mailto:internet-drafts@ietf.or= g]

> Sent: Tuesday, April 16, 2013 10:54 PM<= /o:p>

> To: appsawg-chai= rs@tools.ietf.org; draft-ietf-appsawg-

> = webfinger@tools.ietf.= org; barryleiba@computer.org;

> presnick@qti.qualcom= m.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx;

> bclaise@cisco.com= ; joelja@bogus.com

> Subject: New Version Notification -

> draft-ietf-appsawg-webfinger-13.txt

>

>

> A new version (-13) has been submitted for d= raft-ietf-appsawg-webfinger:

> http://www.ietf.org/i= nternet-drafts/draft-ietf-appsawg-webfinger-13.tx

> t

>

> Sub state has been changed to AD Followup fr= om Revised ID Needed

>

>

> The IETF datatracker page for this Internet-= Draft is:

> https://datatracker.i= etf.org/doc/draft-ietf-appsawg-webfinger/

>

> Diff from previous version:

> http://www.ietf.org/r= fcdiff?url2=3Ddraft-ietf-appsawg-webfinger-13

>

> IETF Secretariat.

 

 

_______________________________________________

webfinger mailing list

webfinger@ietf.org

https://ww= w.ietf.org/mailman/listinfo/webfinger

--_000_4E1F6AAD24975D4BA5B16804296739436764B4CATK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Wed Apr 17 10:30:32 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EAA21F87B7 for ; Wed, 17 Apr 2013 10:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, 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 MbvRZs11o3tl for ; Wed, 17 Apr 2013 10:30:31 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 07C8721F8693 for ; Wed, 17 Apr 2013 10:30:30 -0700 (PDT) Received: from BL2FFO11FD024.protection.gbl (10.173.161.201) by BL2FFO11HUB016.protection.gbl (10.173.160.108) with Microsoft SMTP Server (TLS) id 15.0.675.0; Wed, 17 Apr 2013 17:30:29 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD024.mail.protection.outlook.com (10.173.161.103) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Wed, 17 Apr 2013 17:30:28 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Wed, 17 Apr 2013 17:30:08 +0000 From: Mike Jones To: "Paul E. Jones" , "webfinger@ietf.org" Thread-Topic: Why was the HEAD method added to WebFinger in -13? Thread-Index: Ac47kTH2sIrfGhB+Q2m7Obj8/QSN3Q== Date: Wed, 17 Apr 2013 17:30:07 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436764B4E0@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.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436764B4E0TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(164054002)(69234004)(51704004)(13464002)(377454001)(50986001)(51856001)(44976003)(71186001)(81342001)(54356001)(53806001)(16406001)(15202345002)(16236675002)(564824004)(18277545001)(18276755001)(512954001)(79102001)(47976001)(81542001)(33656001)(54316002)(56776001)(5343655001)(5343635001)(76482001)(59766001)(77982001)(69226001)(6806003)(80022001)(65816001)(20776003)(4396001)(47736001)(49866001)(74662001)(56816002)(63696002)(66066001)(31966008)(55846006)(46102001)(47446002)(74502001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB016; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 081904387B Subject: [webfinger] Why was the HEAD method added to WebFinger in -13? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 17:30:32 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436764B4E0TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WebFinger -13 added this paragraph: A WebFinger client MAY utilize the HEAD method when querying a WebFinger re= source. Consequently, a WebFinger resource MUST support the receipt of the= HEAD method. At least as I see it, this just increased the required implementation footp= rint of WebFinger servers for no particular apparent gain. I'm curious why= this was added and whether others think that it's actually necessary or us= eful. Thanks, -- Mike -----Original Message----- From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Paul E. Jones Sent: Tuesday, April 16, 2013 7:56 PM To: webfinger@ietf.org Subject: [webfinger] FW: New Version Notification - draft-ietf-appsawg-webf= inger-13.txt FYI > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Tuesday, April 16, 2013 10:54 PM > To: appsawg-chairs@tools.ietf.org; = draft-ietf-appsawg- > webfinger@tools.ietf.org; barryleiba@com= puter.org; > presnick@qti.qualcomm.com; stephen.farr= ell@cs.tcd.ie; rlb@ipv.sx; > bclaise@cisco.com; joelja@bogus.com > Subject: New Version Notification - > draft-ietf-appsawg-webfinger-13.txt > > > A new version (-13) has been submitted for draft-ietf-appsawg-webfinger: > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.tx > t > > Sub state has been changed to AD Followup from Revised ID Needed > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-13 > > IETF Secretariat. _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger --_000_4E1F6AAD24975D4BA5B16804296739436764B4E0TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WebFinger -13 added this paragraph:

 

A WebFinger client MAY= utilize the HEAD method when querying a WebFinger resource.  Conseque= ntly, a WebFinger resource MUST support the receipt of the HEAD method.

 

At least as I see it, this just increased the req= uired implementation footprint of WebFinger servers for no particular appar= ent gain.  I’m curious why this was added and whether others thi= nk that it’s actually necessary or useful.

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks,

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

 

-----Original Message-----
From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Paul E. Jones
Sent: Tuesday, April 16, 2013 7:56 PM
To: webfinger@ietf.org
Subject: [webfinger] FW: New Version Notification - draft-ietf-appsawg-webf= inger-13.txt

 

FYI

 

> -----Original Message-----

> From: internet-drafts= @ietf.org [mailto:internet-drafts@ietf.or= g]

> Sent: Tuesday, April 16, 2013 10:54 PM<= /o:p>

> To: appsawg-chai= rs@tools.ietf.org; draft-ietf-appsawg-

> = webfinger@tools.ietf.= org; barryleiba@computer.org;

> presnick@qti.qualcom= m.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx;

> bclaise@cisco.com= ; joelja@bogus.com

> Subject: New Version Notification -

> draft-ietf-appsawg-webfinger-13.txt

>

>

> A new version (-13) has been submitted for d= raft-ietf-appsawg-webfinger:

> http://www.ietf.org/i= nternet-drafts/draft-ietf-appsawg-webfinger-13.tx

> t

>

> Sub state has been changed to AD Followup fr= om Revised ID Needed

>

>

> The IETF datatracker page for this Internet-= Draft is:

> https://datatracker.i= etf.org/doc/draft-ietf-appsawg-webfinger/

>

> Diff from previous version:

> http://www.ietf.org/r= fcdiff?url2=3Ddraft-ietf-appsawg-webfinger-13

>

> IETF Secretariat.

 

 

_______________________________________________

webfinger mailing list

webfinger@ietf.org

https://ww= w.ietf.org/mailman/listinfo/webfinger

--_000_4E1F6AAD24975D4BA5B16804296739436764B4E0TK5EX14MBXC283r_-- From barryleiba.mailing.lists@gmail.com Wed Apr 17 11:08:39 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7152821F891D; Wed, 17 Apr 2013 11:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.938 X-Spam-Level: X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=0.039, 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 a10FZh1oIYae; Wed, 17 Apr 2013 11:08:38 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7836621F85C9; Wed, 17 Apr 2013 11:08:38 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id gd11so1610116vcb.3 for ; Wed, 17 Apr 2013 11:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qctjVdWqf8Kz8hFzVBq0820FdusZsDtYQShGEYVn8+E=; b=ypGWdZJKdejoqgzuH21r1Fp+jULYqb9WeXeoRsk7Pr8y+JrSnFPsf3KvjBwkpxWV5S W/n6pLSRKsJDGzbLu7Z9NTtsOJfEo+9YuBm4hXsfY2I+95Rku+VftWxXNax2ckuc97X0 b1/EXva68WC6ApwVsdWi7/QSfeeAKtBwOxQnEr2dn7mr5IHT9m9JcL3ko9Xb5tgUtlNh JqTVqcBdbIQQb7LCO/mfHvLlFjLI60cd0lDahWkNTjjEqywTFnOPB1k0Y3vUMKODqlsJ SeDyDemzg8dwG/Cj6c+jDAsoEN4AbYksbJoxBhHNhd5Zq8iKEn+QITYSe9GgwxC5tMol zmJg== MIME-Version: 1.0 X-Received: by 10.58.15.232 with SMTP id a8mr5801177ved.27.1366222117678; Wed, 17 Apr 2013 11:08:37 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Wed, 17 Apr 2013 11:08:37 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436764B4CA@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436764B4CA@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 17 Apr 2013 14:08:37 -0400 X-Google-Sender-Auth: SbhhmTWz_HLMtE_DNj-tIhOUI28 Message-ID: From: Barry Leiba To: Mike Jones , appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-webfinger.all@tools.ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "webfinger@ietf.org" , IESG Subject: Re: [webfinger] New restriction added in WebFinger -13 needs to be relaxed or clarified X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 18:08:39 -0000 Mike, you have not followed the discussion outline: this isn't sent to sufficient recipients to get to the right people. +++ ACTION: Appsawg Chairs +++ I've added more recipients here, and this is asking the appsawg chairs to add this to the issue list, to be brought up in its turn. Please see my messages about the DISCUSS positions to get the discussion parameters. Thanks, Barry On Wed, Apr 17, 2013 at 1:29 PM, Mike Jones w= rote: > This new paragraph was added in WebFinger -13: > > > > The host to which a WebFinger query is issued is significant. If the que= ry > target contains a =93host=94 portion (Section 3.2.2 of RFC 3986), then th= e host > to which the WebFinger query is issued MUST be the same as the =93host=94 > portion of the query target. If the query target does not contain a =93ho= st=94 > portion, then the client MAY choose a host to which it directs the query > based on local policy. > > > > I=92m concerned that this paragraph just ruled out using WebFinger to que= ry > for account identifiers at a host that contain another hostname in the > account identifier. This is not a hypothetical situation. For instance,= I > have a Google account whose identifier is mbj@microsoft.com. It appears > that the new paragraph makes this well-formed and useful query illegal: > > > > GET /.well-known/webfinger?resource=3Dacct%3Ambj%40microsoft.com HTTP/1.1 > Host: google.com > > > > I believe that the new paragraph either needs to be removed or clarified = in > some manner to make it clear that a WebFinger server may respond to > resources that it is authoritative for even if the resource being queried > contains a different domain name. > > > > Another example of a situation where one domain is authoritative for othe= rs > is Microsoft=92s Internet mail service domains. At various times, the > preferred domain has been msn.com, hotmail.com, live.com, and outlook.com= . > It=92s perfectly reasonable to query for an identifier containing msn.com= at > live.com, for instance. > > > > I=92d suggest replacing this paragraph with something like the following > instead: > > > > The host to which a WebFinger query is issued is significant. Different > hosts hold authoritative information for different identifiers. WebFinge= r > servers MUST NOT supply information for identifiers that they are not > authoritative for. Note, however, that a WebFinger server at one domain = may > be authoritative for identifiers containing another domain. For instance > the server example.com may host an account whose identifier is > acct:mary@example.org, and queries may be sent to the WebFinger server at > example.com about the account acct:mary@example.org that is hosted there. > > > > -- Mike > From barryleiba.mailing.lists@gmail.com Wed Apr 17 11:10:32 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE7F21F89E2; Wed, 17 Apr 2013 11:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.941 X-Spam-Level: X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=0.036, 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 keD8eyF-Dgpi; Wed, 17 Apr 2013 11:10:31 -0700 (PDT) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1531E21F89CF; Wed, 17 Apr 2013 11:10:30 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id db10so1702781veb.31 for ; Wed, 17 Apr 2013 11:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lZqzd3OUi+ivr8UWIKZ3N8nakKy7wDrmqXB0j2VFzto=; b=mnVUkXnuyhJLsFys4JOt8Q0KURfJIHoybPR8ZY7a1g7y+Ljg9TKLnsPFCnnAXezsuc EBXlx8x9k3WbrHjMxx5l4Np3rWeYdqyRMemsrwaJF8R4RWTgoQZnT/l1ji1ZL5qWEOEq 5mmkc5kqGhIZnSLT1KZZtJOjci1swlsBu4/Wushi7T6op6u4BHniR3cmJQAhHXTe7RDh rllTaW2Dtf1fZmd+PxEEPpDylAJWVc6aDgTXBm8/vE2k+pl5fnrgG9qR5izCpGHjZXkj SOIrSdjNRvCBQjh2rtXNC/FaQf2R8O3KnUq+TlvXwKj6awAmfwiTJx2M7Lldmc4/ydQ8 haZw== MIME-Version: 1.0 X-Received: by 10.52.89.229 with SMTP id br5mr4872517vdb.24.1366222227430; Wed, 17 Apr 2013 11:10:27 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Wed, 17 Apr 2013 11:10:27 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436764B4E0@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436764B4E0@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 17 Apr 2013 14:10:27 -0400 X-Google-Sender-Auth: mvl59WQ_VBDBFAv9obg3lK9UkFg Message-ID: From: Barry Leiba To: Mike Jones , appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-webfinger.all@tools.ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "webfinger@ietf.org" , IESG Subject: Re: [webfinger] Why was the HEAD method added to WebFinger in -13? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 18:10:32 -0000 Mike, you have not followed the discussion outline: this isn't sent to sufficient recipients to get to the right people. +++ ACTION: Appsawg Chairs +++ I've added more recipients here, and this is asking the appsawg chairs to add this to the issue list, to be brought up in its turn. Please see my messages about the DISCUSS positions to get the discussion parameters. Thanks, Barry On Wed, Apr 17, 2013 at 1:30 PM, Mike Jones w= rote: > WebFinger -13 added this paragraph: > > > > A WebFinger client MAY utilize the HEAD method when querying a WebFinger > resource. Consequently, a WebFinger resource MUST support the receipt of > the HEAD method. > > > > At least as I see it, this just increased the required implementation > footprint of WebFinger servers for no particular apparent gain. I=92m cu= rious > why this was added and whether others think that it=92s actually necessar= y or > useful. > > > > Thanks, > > -- Mike > > > > -----Original Message----- > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On > Behalf Of Paul E. Jones > Sent: Tuesday, April 16, 2013 7:56 PM > To: webfinger@ietf.org > Subject: [webfinger] FW: New Version Notification - > draft-ietf-appsawg-webfinger-13.txt > > > > FYI > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Tuesday, April 16, 2013 10:54 PM > >> To: appsawg-chairs@tools.ietf.org; draft-ietf-appsawg- > >> webfinger@tools.ietf.org; barryleiba@computer.org; > >> presnick@qti.qualcomm.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx; > >> bclaise@cisco.com; joelja@bogus.com > >> Subject: New Version Notification - > >> draft-ietf-appsawg-webfinger-13.txt > >> > >> > >> A new version (-13) has been submitted for draft-ietf-appsawg-webfinger: > >> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.tx > >> t > >> > >> Sub state has been changed to AD Followup from Revised ID Needed > >> > >> > >> The IETF datatracker page for this Internet-Draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > >> > >> Diff from previous version: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-13 > >> > >> IETF Secretariat. > > > > > > _______________________________________________ > > webfinger mailing list > > webfinger@ietf.org > > https://www.ietf.org/mailman/listinfo/webfinger > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > From barryleiba.mailing.lists@gmail.com Wed Apr 17 11:14:43 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692DB21E8050; Wed, 17 Apr 2013 11:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.943 X-Spam-Level: X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=0.034, 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 RSu86aj43wMx; Wed, 17 Apr 2013 11:14:43 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id BFA6D21E8048; Wed, 17 Apr 2013 11:14:42 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id kw10so1551767vcb.19 for ; Wed, 17 Apr 2013 11:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=ShvQj8Csf5ve5jYZQh8BiaAQCNPchOOzSq1NPS6G5xc=; b=azqtB/lWvtoVnhjgtbDtaYQPtbP3wcF2OLauoOvyUIU8tjY9pi+IfJFhdhW3AcO3zO Vl6yfH2jeEB771Kzv8PXRndc8mkeRcIFv+vZyunzPD7Kue1CWkTUjsq1iiDFKZyl0e+1 pV+jRruuBG2GVFl5VOl/BCNPbwTERqzuD2GFF9Z4KG/8bCZtVUaQ2NqWVprpgvtN/bfg DkALpkO94ARxtXLDKH5axHYMS3Z113LhDllfeajhc9qUQcjhn5mo5de9MWa/IrUrirPu CnNUqf9HAhGpbZ+oAyCuQockK4y4AIKgKuiFe2R0hNMEjuiTEMLMy65v5x3LZvbhfEBr 2aaQ== MIME-Version: 1.0 X-Received: by 10.220.103.7 with SMTP id i7mr5817164vco.7.1366222482225; Wed, 17 Apr 2013 11:14:42 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Wed, 17 Apr 2013 11:14:42 -0700 (PDT) Date: Wed, 17 Apr 2013 14:14:42 -0400 X-Google-Sender-Auth: d4D0cLbmUYifd-x8a64fhRDv2K8 Message-ID: From: Barry Leiba To: "appsawg-chairs@tools.ietf.org" , "webfinger@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: The IESG , draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: [webfinger] Issues with draft-ietf-appsawg-webfinger as a result of IESG Evaluation X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 18:14:43 -0000 Working group participants: If you have an issue to bring up with the changes that have been made in the webfinger spec during IESG Evaluation, please respond to this thread (do not change the subject line) and state what your issue is. Do not discuss the issue yet; it will be added to an issues list, and discussed in its turn. +++ ACTION: Appsawg Chairs +++ Please watch this thread and record issues that are raised. Barry, Applications AD From nils.diewald@gmail.com Tue Apr 16 05:51:14 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A0721F96B1 for ; Tue, 16 Apr 2013 05:51:14 -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 ql48cfWQiHXV for ; Tue, 16 Apr 2013 05:51:14 -0700 (PDT) Received: from mail-qa0-f63.google.com (mail-qa0-f63.google.com [209.85.216.63]) by ietfa.amsl.com (Postfix) with ESMTP id CBC5021F9652 for ; Tue, 16 Apr 2013 05:51:13 -0700 (PDT) Received: by mail-qa0-f63.google.com with SMTP id g10so209723qah.28 for ; Tue, 16 Apr 2013 05:51:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-google-doc-id:x-google-web-client:date:from:to:cc :message-id:in-reply-to:references:subject:mime-version:content-type :x-google-token:x-google-ip; bh=qZsKtc56+FSqVIDl7EtoS396zKnBYt3ujN09INlexkw=; b=VYKtxk4IjE/0OTkuF6H38Om9yPGQ0DSVG+sWwtCy1lEHXHs9olqPGncK+U1cxAEPUH 1xDr6tv0JsSd1CTashKIgDK6HxYJ+IuNpMSHlAKNOvONJiVdt95U7N3JUwdAyM1vAr66 6rLxNaVAsV52nHFGuEyLryGviMjiKS3sl6gEAAm39jQJUXE/htXzPQDHb4kpCKYlltbI vxA+UfsRx09jGDnI/y84d9DctugxPB2veaqsTRfgd3W55wQuwgsZztaS1zH88xPMO1yk Z+f5Yy/Ueon+RadcAeU1e7Wm/5wtnPMdC39RgBuFDu+dRP1rHo5dKQ5akKETjiG6Qrpr TJRA== X-Received: by 10.49.95.231 with SMTP id dn7mr104001qeb.39.1366116672941; Tue, 16 Apr 2013 05:51:12 -0700 (PDT) X-Google-Doc-Id: 9a20cf310e359773 X-Google-Web-Client: true Date: Tue, 16 Apr 2013 05:51:12 -0700 (PDT) From: Akron To: webfinger@googlegroups.com Message-Id: In-Reply-To: <00f101ce1515$60213a90$2063afb0$@packetizer.com> References: <00f101ce1515$60213a90$2063afb0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6498_17299805.1366116672582" X-Google-Token: EMCStYsFihoMJSk5eI80 X-Google-IP: 2001:638:504:f1fc:f2de:f1ff:fe71:8c40 X-Mailman-Approved-At: Wed, 17 Apr 2013 12:09:29 -0700 Cc: webfinger@ietf.org Subject: Re: [webfinger] List of client and server software X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 21:08:10 -0000 ------=_Part_6498_17299805.1366116672582 Content-Type: multipart/alternative; boundary="----=_Part_6499_8676318.1366116672582" ------=_Part_6499_8676318.1366116672582 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello Paul, I published a WebFinger plugin for Mojolicious (Perl), that supports new and old discovery, XRD as well as JRD, and the rel-parameter. It comes with a blocking and non-blocking interface. CPAN: http://search.cpan.org/dist/Mojolicious-Plugin-WebFinger/ GitHub: https://github.com/Akron/Mojolicious-Plugin-WebFinger Best, Nils ------=_Part_6499_8676318.1366116672582 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hello Paul,

I published a WebFinger plugin for Mojolicious (Perl), that supports new and old discovery, XRD as well as JRD, and the rel-parameter.
It comes with a blocking and non-blocking interface.

CPAN: http://search.cpan.org/dist/Mojolicious-Plugin-WebFinger/
GitHub: https://github.com/Akron/Mojolicious-Plugin-WebFinger

Best,
Nils
------=_Part_6499_8676318.1366116672582-- ------=_Part_6498_17299805.1366116672582-- From rlb@ipv.sx Wed Apr 17 11:49:51 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A575021E8063 for ; Wed, 17 Apr 2013 11:49:51 -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.672, 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 7HXHbmEm2KXR for ; Wed, 17 Apr 2013 11:49:50 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id B607F21E8047 for ; Wed, 17 Apr 2013 11:49:50 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id j6so1917655oag.22 for ; Wed, 17 Apr 2013 11:49:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ZeCjQjsma4hf9IdrsJLRYqxWblBsSJsBdEo64lr55SA=; b=oMvKcvidKSi6f4/aIWAC7qiTU3kXOmfpTNjui4Mtmk2dIxeFe2SWYlVBfpLPYnOr/D RWN++wbSpFtfkQpzhNxBiLBo2DulAO10BC/ror6YrN0BMylMbBZPK43gHJXPZ8FHBS1r eQ6jqwtF67p2iHjbfkYqN1ntdThCiJvJ71AOLJTS0ncJk2zwnuACC3hTnRGh9lAj4UtY I01C4nc/XHTxzm8XW9mzvQjnAUi7legQtD/7D/Oi4LAaC4TdaNTNdfjmXRnRfYenl6Mc OY9QGt7HcTA5rBpPxrDgGcGUPGpq+6390xTvw2nqPVBP6rHZoQ7sfq/ulZaIeOnGh0vG 3B8A== MIME-Version: 1.0 X-Received: by 10.182.96.1 with SMTP id do1mr3228649obb.17.1366224590168; Wed, 17 Apr 2013 11:49:50 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Wed, 17 Apr 2013 11:49:50 -0700 (PDT) X-Originating-IP: [192.1.255.184] In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739436764B4E0@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 17 Apr 2013 14:49:50 -0400 Message-ID: From: Richard Barnes To: Barry Leiba Content-Type: multipart/alternative; boundary=001a11c2fa02617afe04da92f376 X-Gm-Message-State: ALoCoQk7ndflvAxuvJdK1uYYgYngTOk8m6gR4fbISul1lT3Y91JSUfAxt3qH0ywffKNRNKKniiCZ X-Mailman-Approved-At: Wed, 17 Apr 2013 12:09:29 -0700 Cc: IESG , "webfinger@ietf.org" , Mike Jones , appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] Why was the HEAD method added to WebFinger in -13? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 18:49:51 -0000 --001a11c2fa02617afe04da92f376 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mike, The back story is this: -- My DISCUSS asked what methods should be allowed / required to a WebFinger URI -- Obviously GET is required -- Paul suggested that HEAD would also be useful Personally, I'm not sold on the utility of HEAD, especially as a MUST for servers. On the other hand, it occurs to me that servers will need to support OPTIONS for CORS pre-flight checks [1]. --Richard [1] On Wed, Apr 17, 2013 at 2:10 PM, Barry Leiba wrote= : > Mike, you have not followed the discussion outline: this isn't sent to > sufficient recipients to get to the right people. > > +++ ACTION: Appsawg Chairs +++ > I've added more recipients here, and this is asking the appsawg chairs > to add this to the issue list, to be brought up in its turn. Please > see my messages about the DISCUSS positions to get the discussion > parameters. > > Thanks, > Barry > > On Wed, Apr 17, 2013 at 1:30 PM, Mike Jones > wrote: > > WebFinger -13 added this paragraph: > > > > > > > > A WebFinger client MAY utilize the HEAD method when querying a WebFinge= r > > resource. Consequently, a WebFinger resource MUST support the receipt = of > > the HEAD method. > > > > > > > > At least as I see it, this just increased the required implementation > > footprint of WebFinger servers for no particular apparent gain. I=92m > curious > > why this was added and whether others think that it=92s actually necess= ary > or > > useful. > > > > > > > > Thanks, > > > > -- Mike > > > > > > > > -----Original Message----- > > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On > > Behalf Of Paul E. Jones > > Sent: Tuesday, April 16, 2013 7:56 PM > > To: webfinger@ietf.org > > Subject: [webfinger] FW: New Version Notification - > > draft-ietf-appsawg-webfinger-13.txt > > > > > > > > FYI > > > > > > > >> -----Original Message----- > > > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > >> Sent: Tuesday, April 16, 2013 10:54 PM > > > >> To: appsawg-chairs@tools.ietf.org; draft-ietf-appsawg- > > > >> webfinger@tools.ietf.org; barryleiba@computer.org; > > > >> presnick@qti.qualcomm.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx; > > > >> bclaise@cisco.com; joelja@bogus.com > > > >> Subject: New Version Notification - > > > >> draft-ietf-appsawg-webfinger-13.txt > > > >> > > > >> > > > >> A new version (-13) has been submitted for draft-ietf-appsawg-webfinge= r: > > > >> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.tx > > > >> t > > > >> > > > >> Sub state has been changed to AD Followup from Revised ID Needed > > > >> > > > >> > > > >> The IETF datatracker page for this Internet-Draft is: > > > >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > > > >> > > > >> Diff from previous version: > > > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-13 > > > >> > > > >> IETF Secretariat. > > > > > > > > > > > > _______________________________________________ > > > > webfinger mailing list > > > > webfinger@ietf.org > > > > https://www.ietf.org/mailman/listinfo/webfinger > > > > > > _______________________________________________ > > webfinger mailing list > > webfinger@ietf.org > > https://www.ietf.org/mailman/listinfo/webfinger > > > --001a11c2fa02617afe04da92f376 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mike,

The back story is this:
-- My DISCUSS as= ked what methods should be allowed / required to a WebFinger URI
= -- Obviously GET is required
-- Paul suggested that HEAD would al= so be useful

Personally, I'm not sold on the utility of HEAD, es= pecially as a MUST for servers.

On the other hand,= it occurs to me that servers will need to support OPTIONS for CORS pre-fli= ght checks [1].

--Richard






On Wed, Apr 17, 2013 at 2:10 PM, Barry Leiba <barryleiba@comput= er.org> wrote:
Mike, you have not followed the discussion o= utline: this isn't sent to
sufficient recipients to get to the right people.

+++ ACTION: Appsawg Chairs +++
I've added more recipients here, and this is asking the appsawg chairs<= br> to add this to the issue list, to be brought up in its turn. =A0Please
see my messages about the DISCUSS positions to get the discussion
parameters.

Thanks,
Barry

On Wed, Apr 17, 2013 at 1:30 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
> WebFinger -13 added this paragraph:
>
>
>
> A WebFinger client MAY utilize the HEAD method when querying a WebFing= er
> resource. =A0Consequently, a WebFinger resource MUST support the recei= pt of
> the HEAD method.
>
>
>
> At least as I see it, this just increased the required implementation<= br> > footprint of WebFinger servers for no particular apparent gain. =A0I= =92m curious
> why this was added and whether others think that it=92s actually neces= sary or
> useful.
>
>
>
> =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 Thanks,
>
> =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
>
>
>
> -----Original Message-----
> From: webfinger-bounces@= ietf.org [mailto:webfinge= r-bounces@ietf.org] On
> Behalf Of Paul E. Jones
> Sent: Tuesday, April 16, 2013 7:56 PM
> To: webfinger@ietf.org
> Subject: [webfinger] FW: New Version Notification -
> draft-ietf-appsawg-webfinger-13.txt
>
>
>
> FYI
>
>
>
>> -----Original Message-----
>
>> From: internet-drafts@= ietf.org [mailto:internet-d= rafts@ietf.org]
>
>> Sent: Tuesday, April 16, 2013 10:54 PM
>
>> To: appsawg-chair= s@tools.ietf.org; draft-ietf-appsawg-
>
>> webfinger@tools.ietf.o= rg; barryleiba@computer.org<= /a>;
>
>> presnick@qti.qualcomm= .com; stephen.farrell@cs.t= cd.ie; rlb@ipv.sx;
>
>> bclaise@cisco.com; joelja@bogus.com
>
>> Subject: New Version Notification -
>
>> draft-ietf-appsawg-webfinger-13.txt
>
>>
>
>>
>
>> A new version (-13) has been submitted for draft-ietf-appsawg-webf= inger:
>
>> http://www.ietf.org/internet-drafts/draf= t-ietf-appsawg-webfinger-13.tx
>
>> t
>
>>
>
>> Sub state has been changed to AD Followup from Revised ID Needed >
>>
>
>>
>
>> The IETF datatracker page for this Internet-Draft is:
>
>> https://datatracker.ietf.org/doc/draft-ietf-apps= awg-webfinger/
>
>>
>
>> Diff from previous version:
>
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-iet= f-appsawg-webfinger-13
>
>>
>
>> IETF Secretariat.
>
>
>
>
>
> _______________________________________________
>
> webfinger mailing list
>
> webfinger@ietf.org
>
> https://www.ietf.org/mailman/listinfo/webfinger
>
>
> _______________________________________________
> webfinger mailing list
> webfinger@ietf.org
> https://www.ietf.org/mailman/listinfo/webfinger
>

--001a11c2fa02617afe04da92f376-- From rlb@ipv.sx Wed Apr 17 11:59:29 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFEE21F896D for ; Wed, 17 Apr 2013 11:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 SxDbV07yMWgA for ; Wed, 17 Apr 2013 11:59:28 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id 271EC21F891D for ; Wed, 17 Apr 2013 11:59:28 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id k14so1966008oag.10 for ; Wed, 17 Apr 2013 11:59:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=9VZh1uiM9Fy+3N+YozK7rsedl+4G/6P7aoGu20d7zR0=; b=MuSmPNMVoFGeS8KWvEfnXcnrYa3BBQJyzQhuVkF/HfK7QkAZ/H8CMMSZN3Cy3iCBqN Bca4aquwd7wHbMx+qVJfKqRmRE2qZfapvPqefDeYkTyrV0qtWeKxjT8a3upkx1uVSD3F EJ0yS3AtEOtCLYC8Rrvqn9GBI29x+zZVcE8b1UfcOGY/bcs1Muay3OR15a338pWLe+eA SMcGKeT18yM/geMuT+xQqViZjhlya84Z1tAFHFLx8U4mrYEnGnhM2CA89cbaFCTTmFlx 8emQqgA+bank46Krc0XYctNSAEPXzDn9nCB7xxC4XhxleKrNWl3ppN5qvAuzmi0BLoMm UPkw== MIME-Version: 1.0 X-Received: by 10.60.34.98 with SMTP id y2mr3237019oei.74.1366225167632; Wed, 17 Apr 2013 11:59:27 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Wed, 17 Apr 2013 11:59:27 -0700 (PDT) X-Originating-IP: [192.1.255.184] In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739436764B4CA@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 17 Apr 2013 14:59:27 -0400 Message-ID: From: Richard Barnes To: Barry Leiba Content-Type: multipart/alternative; boundary=089e01175d07ccdc3d04da931548 X-Gm-Message-State: ALoCoQkaO0ZWY/SE6kX3cv+bdu9+tiiO/i+9sBCPvTnj0EjrUfVV/qcAM2G4ES1HwGPoeS21jPQU X-Mailman-Approved-At: Wed, 17 Apr 2013 12:09:29 -0700 Cc: IESG , "webfinger@ietf.org" , Mike Jones , appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] New restriction added in WebFinger -13 needs to be relaxed or clarified X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 18:59:29 -0000 --089e01175d07ccdc3d04da931548 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mike, Could you elaborate on the use case for such a URI? How would someone come across your "acct" URI and know to send the query to Google? The reason that text was added was to answer two questions: 1. How does a client know what server to send a WebFinger request to? and 2. How does a user know what WebFinger servers are giving out his information? If you want to relax the restriction, you'll need to provide answers to those questions. --Richard On Wed, Apr 17, 2013 at 2:08 PM, Barry Leiba wrote= : > Mike, you have not followed the discussion outline: this isn't sent to > sufficient recipients to get to the right people. > > +++ ACTION: Appsawg Chairs +++ > I've added more recipients here, and this is asking the appsawg chairs > to add this to the issue list, to be brought up in its turn. Please > see my messages about the DISCUSS positions to get the discussion > parameters. > > Thanks, > Barry > > On Wed, Apr 17, 2013 at 1:29 PM, Mike Jones > wrote: > > This new paragraph was added in WebFinger -13: > > > > > > > > The host to which a WebFinger query is issued is significant. If the > query > > target contains a =93host=94 portion (Section 3.2.2 of RFC 3986), then = the > host > > to which the WebFinger query is issued MUST be the same as the =93host= =94 > > portion of the query target. If the query target does not contain a > =93host=94 > > portion, then the client MAY choose a host to which it directs the quer= y > > based on local policy. > > > > > > > > I=92m concerned that this paragraph just ruled out using WebFinger to q= uery > > for account identifiers at a host that contain another hostname in the > > account identifier. This is not a hypothetical situation. For > instance, I > > have a Google account whose identifier is mbj@microsoft.com. It appear= s > > that the new paragraph makes this well-formed and useful query illegal: > > > > > > > > GET /.well-known/webfinger?resource=3Dacct%3Ambj%40microsoft.com HTTP/1= .1 > > Host: google.com > > > > > > > > I believe that the new paragraph either needs to be removed or clarifie= d > in > > some manner to make it clear that a WebFinger server may respond to > > resources that it is authoritative for even if the resource being queri= ed > > contains a different domain name. > > > > > > > > Another example of a situation where one domain is authoritative for > others > > is Microsoft=92s Internet mail service domains. At various times, the > > preferred domain has been msn.com, hotmail.com, live.com, and > outlook.com. > > It=92s perfectly reasonable to query for an identifier containing msn.c= omat > > live.com, for instance. > > > > > > > > I=92d suggest replacing this paragraph with something like the followin= g > > instead: > > > > > > > > The host to which a WebFinger query is issued is significant. Differen= t > > hosts hold authoritative information for different identifiers. > WebFinger > > servers MUST NOT supply information for identifiers that they are not > > authoritative for. Note, however, that a WebFinger server at one domai= n > may > > be authoritative for identifiers containing another domain. For instan= ce > > the server example.com may host an account whose identifier is > > acct:mary@example.org, and queries may be sent to the WebFinger server > at > > example.com about the account acct:mary@example.org that is hosted > there. > > > > > > > > -- Mike > > > --089e01175d07ccdc3d04da931548 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mike,

Could you elaborate on the use case for such a URI= ? =A0How would someone come across your "acct" URI and know to se= nd the query to Google?

The reason that text was a= dded was to answer two questions:=A0
1. How does a client know what server to send a WebFinger request to? = and
2. How does a user know what WebFinger servers are giving out= his information?

If you want to relax the restric= tion, you'll need to provide answers to those questions.

--Richard



<= br>
On Wed, Apr 17, 2013 at 2:08 PM, Barry Leiba = <barryleiba@computer.org> wrote:
Mike, you have not followed the discussion o= utline: this isn't sent to
sufficient recipients to get to the right people.

+++ ACTION: Appsawg Chairs +++
I've added more recipients here, and this is asking the appsawg chairs<= br> to add this to the issue list, to be brought up in its turn. =A0Please
see my messages about the DISCUSS positions to get the discussion
parameters.

Thanks,
Barry

On Wed, Apr 17, 2013 at 1:29 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
> This new paragraph was added in WebFinger -13:
>
>
>
> The host to which a WebFinger query is issued is significant. =A0If th= e query
> target contains a =93host=94 portion (Section 3.2.2 of RFC 3986), then= the host
> to which the WebFinger query is issued MUST be the same as the =93host= =94
> portion of the query target. If the query target does not contain a = =93host=94
> portion, then the client MAY choose a host to which it directs the que= ry
> based on local policy.
>
>
>
> I=92m concerned that this paragraph just ruled out using WebFinger to = query
> for account identifiers at a host that contain another hostname in the=
> account identifier. =A0This is not a hypothetical situation. =A0For in= stance, I
> have a Google account whose identifier is mbj@microsoft.com. =A0It appears
> that the new paragraph makes this well-formed and useful query illegal= :
>
>
>
> GET /.well-known/webfinger?resource=3Dacct%3Ambj%40microsoft.com HTTP/1.1
> Host: google.com >
>
>
> I believe that the new paragraph either needs to be removed or clarifi= ed in
> some manner to make it clear that a WebFinger server may respond to > resources that it is authoritative for even if the resource being quer= ied
> contains a different domain name.
>
>
>
> Another example of a situation where one domain is authoritative for o= thers
> is Microsoft=92s Internet mail service domains. =A0At various times, t= he
> preferred domain has been msn.com, hotmail.com<= /a>, live.com, and outlook.com.
> It=92s perfectly reasonable to query for an identifier containing msn.com at
> live.com, for instan= ce.
>
>
>
> I=92d suggest replacing this paragraph with something like the followi= ng
> instead:
>
>
>
> The host to which a WebFinger query is issued is significant. =A0Diffe= rent
> hosts hold authoritative information for different identifiers. =A0Web= Finger
> servers MUST NOT supply information for identifiers that they are not<= br> > authoritative for. =A0Note, however, that a WebFinger server at one do= main may
> be authoritative for identifiers containing another domain. =A0For ins= tance
> the server example.co= m may host an account whose identifier is
> acct:mary@example.org, = and queries may be sent to the WebFinger server at
> example.com about= the account acct:mary@example.o= rg that is hosted there.
>
>
>
> =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
>

--089e01175d07ccdc3d04da931548-- From matake@gmail.com Wed Apr 17 18:00:59 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D1B21E80E9 for ; Wed, 17 Apr 2013 18:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj7Wtr9r-0-X for ; Wed, 17 Apr 2013 18:00:57 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id C731721E80E1 for ; Wed, 17 Apr 2013 18:00:57 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id v14so1150468pde.4 for ; Wed, 17 Apr 2013 18:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=D4XVBL80+Zy0j1vVPeNwZqyo7GvHACNQfADRZveZsn0=; b=DT4oLBraJOL4+SJRIzeEEVze0uF6XJQ/DYDkJxuOBmH7/ugYUaYL948dL8yxdbn5+K j3lDuTfsPTdkaqJWuhmHU5WOvIqJxniN6no7W/qOMHOyhQZnyBSpE5W/hIgyY/QfoiEV KUFgOLvq1B/WpXgWzz+UZGc2/mzFq66rqExu15WY1Gxdk4tqdxjCZQ8mthtdPBtamc4T J8VfYxjsjRLC4l2apcZH1eajELLOW9y0BdF+7hiRghDlaaoRJ7tRZRckslBgzwasJnm+ Vo0KZI8v0yiEh93YonEiwZg7mRq3TyNsQtYB7od0Xw++8neL9dUQplZqxmQ76xCye6At 5kmg== X-Received: by 10.68.245.6 with SMTP id xk6mr11524089pbc.41.1366246857586; Wed, 17 Apr 2013 18:00:57 -0700 (PDT) Received: from [10.242.41.176] (KD182250064023.au-net.ne.jp. [182.250.64.23]) by mx.google.com with ESMTPS id mt13sm7850380pbc.15.2013.04.17.18.00.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Apr 2013 18:00:55 -0700 (PDT) References: <4E1F6AAD24975D4BA5B16804296739436764B4CA@TK5EX14MBXC283.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436764B4CA@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1EC9743C-6695-4879-A976-E4BD4A726A27 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: nov matake Date: Thu, 18 Apr 2013 09:55:46 +0900 To: Mike Jones Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] New restriction added in WebFinger -13 needs to be relaxed or clarified X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 01:00:59 -0000 --Apple-Mail-1EC9743C-6695-4879-A976-E4BD4A726A27 Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable Does this text allow HTTP redirects at the webfinger endpoints? Or when a webfinger endpoint want to redirect the user agent, does it have t= o omit "host" query? nov On Apr 18, 2013, at 2:29 AM, Mike Jones wrote:= > This new paragraph was added in WebFinger -13: > =20 > The host to which a WebFinger query is issued is significant. If the quer= y target contains a =81ghost=81h portion (Section 3.2.2 of RFC 3986), then t= he host to which the WebFinger query is issued MUST be the same as the =81gh= ost=81h portion of the query target. If the query target does not contain a =81= ghost=81h portion, then the client MAY choose a host to which it directs the= query based on local policy. > =20 > I=81fm concerned that this paragraph just ruled out using WebFinger to que= ry for account identifiers at a host that contain another hostname in the ac= count identifier. This is not a hypothetical situation. For instance, I ha= ve a Google account whose identifier is mbj@microsoft.com. It appears that t= he new paragraph makes this well-formed and useful query illegal: > =20 > GET /.well-known/webfinger?resource=3Dacct%3Ambj%40microsoft.com HTTP/1.1 > Host: google.com > =20 > I believe that the new paragraph either needs to be removed or clarified i= n some manner to make it clear that a WebFinger server may respond to resour= ces that it is authoritative for even if the resource being queried contains= a different domain name. > =20 > Another example of a situation where one domain is authoritative for other= s is Microsoft=81fs Internet mail service domains. At various times, the pr= eferred domain has been msn.com, hotmail.com, live.com, and outlook.com. It= =81fs perfectly reasonable to query for an identifier containing msn.com at l= ive.com, for instance. > =20 > I=81fd suggest replacing this paragraph with something like the following i= nstead: > =20 > The host to which a WebFinger query is issued is significant. Different h= osts hold authoritative information for different identifiers. WebFinger se= rvers MUST NOT supply information for identifiers that they are not authorit= ative for. Note, however, that a WebFinger server at one domain may be auth= oritative for identifiers containing another domain. For instance the serve= r example.com may host an account whose identifier is acct:mary@example.org,= and queries may be sent to the WebFinger server at example.com about the ac= count acct:mary@example.org that is hosted there. > =20 > -- Mike > =20 > -----Original Message----- > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Be= half Of Paul E. Jones > Sent: Tuesday, April 16, 2013 7:56 PM > To: webfinger@ietf.org > Subject: [webfinger] FW: New Version Notification - draft-ietf-appsawg-web= finger-13.txt > =20 > FYI > =20 > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Tuesday, April 16, 2013 10:54 PM > > To: appsawg-chairs@tools.ietf.org; draft-ietf-appsawg- > > webfinger@tools.ietf.org; barryleiba@computer.org; > > presnick@qti.qualcomm.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx; > > bclaise@cisco.com; joelja@bogus.com > > Subject: New Version Notification - > > draft-ietf-appsawg-webfinger-13.txt > > > > > > A new version (-13) has been submitted for draft-ietf-appsawg-webfinger:= > > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.tx > > t > > > > Sub state has been changed to AD Followup from Revised ID Needed > > > > > > The IETF datatracker page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > > > > Diff from previous version: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-13 > > > > IETF Secretariat. > =20 > =20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail-1EC9743C-6695-4879-A976-E4BD4A726A27 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Does this text allow HTTP redirects at= the webfinger endpoints?
Or when a webfinger endpoint want to red= irect the user agent, does it have to omit "host" query?

nov

On Apr 18, 2013, at 2:29 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
=

This new paragraph was added in WebFinger -13:

 

The host to which a Web= Finger query is issued is significant.  If the query target contains a =E2= =80=9Chost=E2=80=9D portion (Section 3.2.2 of RFC 3986), then the host to wh= ich the WebFinger query is issued MUST be the same as the =E2=80=9Chost=E2=80=9D portion of the query target. If the query tar= get does not contain a =E2=80=9Chost=E2=80=9D portion, then the client MAY c= hoose a host to which it directs the query based on local policy.=

 

I=E2=80=99m concerned that this paragraph just rul= ed out using WebFinger to query for account identifiers at a host that conta= in another hostname in the account identifier.  This is not a hypotheti= cal situation.  For instance, I have a Google account whose identifier is mbj@micros= oft.com.  It appears that the new paragraph makes this well-formed a= nd useful query illegal:

 

GET /.well-known/webfinger= ?resource=3Dacct%3Ambj%40microsoft.com HTTP/1.1
Host: google.com

 

I believe that the new paragraph either needs to b= e removed or clarified in some manner to make it clear that a WebFinger serv= er may respond to resources that it is authoritative for even if the resourc= e being queried contains a different domain name.

 

Another example of a situation where one domain is= authoritative for others is Microsoft=E2=80=99s Internet mail service domai= ns.  At various times, the preferred domain has been msn.com, hotmail.com, live.com, and outlo= ok.com.  It=E2=80=99s perfectly reasonable to query for an identifier containing msn.com at live.com, for instance.=

 

I=E2=80=99d suggest replacing this paragraph with s= omething like the following instead:

 

The host to which a Web= Finger query is issued is significant.  Different hosts hold authoritat= ive information for different identifiers.  WebFinger servers MUST NOT s= upply information for identifiers that they are not authoritative for.  Note, however, that a WebFinger server at o= ne domain may be authoritative for identifiers containing another domain.&nb= sp; For instance the server example.com m= ay host an account whose identifier is acct:mary@example.org, and queries may be sent to the WebFinger server at examp= le.com about the account acct:mary@exampl= e.org that is hosted there.

 

        &n= bsp;            =             &nbs= p;            &n= bsp;            =      -- Mike

 

-----Original Message-----
From: webfinger-bounces@ietf.o= rg [mailto:webfinger-bounc= es@ietf.org] On Behalf Of Paul E. Jones
Sent: Tuesday, April 16, 2013 7:56 PM
To: webfinger@ietf.org
Subject: [webfinger] FW: New Version Notification - draft-ietf-appsawg-webfi= nger-13.txt

 

FYI

 

> -----Original Message-----

> From: internet-drafts@i= etf.org [mailto:internet-drafts@ietf.org]

> Sent: Tuesday, April 16, 2013 10:54 PM

> To: appsawg-chairs= @tools.ietf.org; draft-ietf-appsawg-

> <= span style=3D"color:windowtext;text-decoration:none">webfinger@tools.ietf.or= g; barryleiba@computer.org;

> = presnick@qti.qualcomm.= com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx;

> bclaise@cisco.com; joelja@bogus.com

> Subject: New Version Notification -

> draft-ietf-appsawg-webfinger-13.txt

>

>

> A new version (-13) has been submitted for dr= aft-ietf-appsawg-webfinger:

> http://www.ietf.org/in= ternet-drafts/draft-ietf-appsawg-webfinger-13.tx

> t

>

> Sub state has been changed to AD Followup fro= m Revised ID Needed

>

>

> The IETF datatracker page for this Internet-D= raft is:

> https://datatracker.ie= tf.org/doc/draft-ietf-appsawg-webfinger/

>

> Diff from previous version:

> http://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-appsawg-webfinger-13

>

> IETF Secretariat.

 

 

_______________________________________________

webfinger mailing list

webfinger@ietf.org

https://www.= ietf.org/mailman/listinfo/webfinger

____________________= ___________________________
webfinger mailing listwebfinger@ietf.orghttps://= www.ietf.org/mailman/listinfo/webfinger
= --Apple-Mail-1EC9743C-6695-4879-A976-E4BD4A726A27-- From paulej@packetizer.com Wed Apr 17 18:51:11 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236F921E80D6 for ; Wed, 17 Apr 2013 18:51:11 -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.001, 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 FF+QFtF3ivAv for ; Wed, 17 Apr 2013 18:51:09 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E2C951F0CF7 for ; Wed, 17 Apr 2013 18:51: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 r3I1p5ND014039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Apr 2013 21:51:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1366249867; bh=6llkyOFboARIzondf1b6h0DLX+Ts4w+fCBIk0lfxmlc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Z/tmLn79tVS16R90GeSKI4ABKzQa2OVcwYiiOTaD9RyG9SRhS+QrcwG/NtjxSk4B0 gOQ35iNdv81lLv1xZQQVvvlJfgPq8t/msHjt4Q86lH6MMBBaFMxCa4iCxPSa3Ml75i LmAomFuICbCQ6QtXZmcUc5mOov0D1sh0kyl4fZ3k= From: "Paul E. Jones" To: "'Melvin Carvalho'" References: <20130417025405.14655.86603.idtracker@ietfa.amsl.com> <026801ce3b17$0e958690$2bc093b0$@packetizer.com> In-Reply-To: Date: Wed, 17 Apr 2013 21:51:13 -0400 Message-ID: <03e301ce3bd7$35e4fd50$a1aef7f0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03E4_01CE3BB5.AED495D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGHUJRrHTwH9MdWVq1dAaZCxMPA0AGLIKoTAejPLeSZTWrz4A== Content-Language: en-us Cc: 'webfinger' Subject: Re: [webfinger] FW: New Version Notification - draft-ietf-appsawg-webfinger-13.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 01:51:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03E4_01CE3BB5.AED495D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, That's an interesting observation. I was apparently mistaken that it was required for LRDD resources, but looking back at the older specifications, that does not seem to be the case. Given that every example I found related to LRDD included a "subject", I think the intent was that it should be required. The only explicit exception in the text I can find where "subject" "should not" be present is in RFC 6415 with respect to host host-meta resource itself. No comment is made with respect to LRDD. So, we have three options: 1) Mandate its presence (current text) 2) Say that it SHOULD be present in the JRD 3) Say it is OPTIONAL in the JRD What is the preference here? Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Wednesday, April 17, 2013 4:32 AM To: Paul E. Jones Cc: webfinger Subject: Re: [webfinger] FW: New Version Notification - draft-ietf-appsawg-webfinger-13.txt On 17 April 2013 04:55, Paul E. Jones wrote: FYI > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, April 16, 2013 10:54 PM > To: appsawg-chairs@tools.ietf.org; draft-ietf-appsawg- > webfinger@tools.ietf.org; barryleiba@computer.org; > presnick@qti.qualcomm.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx; > bclaise@cisco.com; joelja@bogus.com > Subject: New Version Notification - draft-ietf-appsawg-webfinger-13.txt > > > A new version (-13) has been submitted for draft-ietf-appsawg-webfinger: > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.txt Hi Paul, I just noticed something odd. In most EAV description languages, the subject term is optional. The is true, for example, in XRD and RDF. I've noticed in section 4.4.1. The "subject" member MUST be present in the JRD. This would make JRD as a serialization inconsistent, and *perhaps*, in some cases not 100% interoperable with others. I was just wondering if there was a conscious decision in making this change when moving from XRD -> JRD or if it was unintended. > > Sub state has been changed to AD Followup from Revised ID Needed > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-13 > > IETF Secretariat. _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_03E4_01CE3BB5.AED495D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

That’s an interesting observation.  I was apparently = mistaken that it was required for LRDD resources, but looking back at = the older specifications, that does not seem to be the = case.

 

Given that every example I found related to LRDD included a = “subject”, I think the intent was that it should be = required.  The only explicit exception in the text I can find where = “subject” “should not” be present is in RFC 6415 = with respect to host host-meta resource itself.  No comment is made = with respect to LRDD.

 

So, we have three options:

1)      = Mandate its presence (current text)

2)      = Say that it SHOULD be present in the JRD

3)      = Say it is OPTIONAL in the JRD

 

What is the preference here?

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Wednesday, April 17, 2013 4:32 AM
To: Paul E. = Jones
Cc: webfinger
Subject: Re: [webfinger] FW: New = Version Notification - = draft-ietf-appsawg-webfinger-13.txt

 

 

 

On 17 April 2013 04:55, Paul E. Jones <paulej@packetizer.com> wrote:

FYI

> -----Original Message-----
> = From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]> Sent: Tuesday, April 16, 2013 10:54 PM
> To: appsawg-chairs@tools.ietf.o= rg; draft-ietf-appsawg-
> webfinger@tools.ietf.org; = barryleiba@computer.org;
&= gt; presnick@qti.qualcomm.com; = stephen.farrell@cs.tcd.ie; = rlb@ipv.sx;
> bclaise@cisco.com; joelja@bogus.com
> Subject: = New Version Notification - = draft-ietf-appsawg-webfinger-13.txt
>
>
> A new = version (-13) has been submitted for = draft-ietf-appsawg-webfinger:
> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-= webfinger-13.txt

 

Hi Paul, I just noticed something = odd.

In most EAV description languages, the = subject term is optional.  The is true, for example, in XRD and = RDF.

I've noticed in section = 4.4.1.

   The "subject" member =
MUST be present in the JRD.

 

This would make JRD as a serialization = inconsistent, and *perhaps*, in some cases not 100% interoperable with = others.

I was just = wondering if there was a conscious decision in making this change when = moving from XRD -> JRD or if it was = unintended.

 

 

>
> Sub state has been changed to AD Followup = from Revised ID Needed
>
>
> The IETF datatracker page = for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-web= finger/
>
> Diff from previous version:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-w= ebfinger-13
>
> IETF = Secretariat.


_______________________________________________webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

------=_NextPart_000_03E4_01CE3BB5.AED495D0-- From paulej@packetizer.com Wed Apr 17 22:58:47 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FBD21F89E2 for ; Wed, 17 Apr 2013 22:58:47 -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 7gMX7SQzgjDY for ; Wed, 17 Apr 2013 22:58:44 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1728A21F89AF for ; Wed, 17 Apr 2013 22:58:44 -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 r3I5whlw029551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Apr 2013 01:58:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1366264723; bh=1Omzg55HVq6nhjMYZhMlb03BIONYb/75KY/gWVl2pW4=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=g2Fd7IaAuIbmIgXbdFiU5L1U4BPLc4BGdlfTRTu+9/5JS2/omRW+mVOlo3pd53b7Z t207DOv+EojNncKK5+e85chwGik+gjIJ/ZSO+GF7AHRM1i21T0AtYJ0VxvLFKZhjcJ YoTiQP49VQbpICTQfp8YETqHWQa0A3JkZF+ztx8I= From: "Paul E. Jones" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B16804296739436764B4CA@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436764B4CA@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 18 Apr 2013 01:58:51 -0400 Message-ID: <040a01ce3bf9$cd594c00$680be400$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_040B_01CE3BD8.46490B90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUKPlcfbjeiLjwoQYf4Z7gxYDKFJhPnHRQ Content-Language: en-us Subject: Re: [webfinger] New restriction added in WebFinger -13 needs to be relaxed or clarified X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 05:58:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_040B_01CE3BD8.46490B90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mike, This and other changes were made as a part of the DISCUSSion this past week. Your interpretation is correct. The problem trying to be solved was one of clarifying where a client would direct a request. I think it's obvious to me and you that if we were writing a client to query acct:paulej@packetizer.com, we'd direct the query to packetizer.com. However, this was not stated, nor was guidance given as to where one directs a request when there is no host portion in the URI (e.g., "tel"). If we introduce the text you propose, then the next question might be how one domain becomes authoritative for another domain. More importantly, your proposed wording removes the key statements the ADs were trying to make, and that is guidance on how to determine where a query should be directed. Perhaps you would like to just "soften" the wording, such as "query is normally issued" or something? Or, perhaps say "unless a client is explicitly configured to direct queries elsewhere, ."? Now, what this text does not intend to suggest is that 3xx redirection no longer works. If you have an msn.com account and the msn.com server wants that handled by the live.com server, it could redirect the HTTP request. So, what do we do here? Paul From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 17, 2013 1:30 PM To: Paul E. Jones; webfinger@ietf.org Subject: New restriction added in WebFinger -13 needs to be relaxed or clarified This new paragraph was added in WebFinger -13: The host to which a WebFinger query is issued is significant. If the query target contains a "host" portion (Section 3.2.2 of RFC 3986), then the host to which the WebFinger query is issued MUST be the same as the "host" portion of the query target. If the query target does not contain a "host" portion, then the client MAY choose a host to which it directs the query based on local policy. I'm concerned that this paragraph just ruled out using WebFinger to query for account identifiers at a host that contain another hostname in the account identifier. This is not a hypothetical situation. For instance, I have a Google account whose identifier is mbj@microsoft.com. It appears that the new paragraph makes this well-formed and useful query illegal: GET /.well-known/webfinger?resource=acct%3Ambj%40microsoft.com HTTP/1.1 Host: google.com I believe that the new paragraph either needs to be removed or clarified in some manner to make it clear that a WebFinger server may respond to resources that it is authoritative for even if the resource being queried contains a different domain name. Another example of a situation where one domain is authoritative for others is Microsoft's Internet mail service domains. At various times, the preferred domain has been msn.com, hotmail.com, live.com, and outlook.com. It's perfectly reasonable to query for an identifier containing msn.com at live.com, for instance. I'd suggest replacing this paragraph with something like the following instead: The host to which a WebFinger query is issued is significant. Different hosts hold authoritative information for different identifiers. WebFinger servers MUST NOT supply information for identifiers that they are not authoritative for. Note, however, that a WebFinger server at one domain may be authoritative for identifiers containing another domain. For instance the server example.com may host an account whose identifier is acct:mary@example.org, and queries may be sent to the WebFinger server at example.com about the account acct:mary@example.org that is hosted there. -- Mike -----Original Message----- From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Tuesday, April 16, 2013 7:56 PM To: webfinger@ietf.org Subject: [webfinger] FW: New Version Notification - draft-ietf-appsawg-webfinger-13.txt FYI > -----Original Message----- > From: internet-drafts@ietf.org [ mailto:internet-drafts@ietf.org] > Sent: Tuesday, April 16, 2013 10:54 PM > To: appsawg-chairs@tools.ietf.org; draft-ietf-appsawg- > webfinger@tools.ietf.org; barryleiba@computer.org; > presnick@qti.qualcomm.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx; > bclaise@cisco.com; joelja@bogus.com > Subject: New Version Notification - > draft-ietf-appsawg-webfinger-13.txt > > > A new version (-13) has been submitted for draft-ietf-appsawg-webfinger: > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.tx > t > > Sub state has been changed to AD Followup from Revised ID Needed > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-13 > > IETF Secretariat. _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_040B_01CE3BD8.46490B90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mike,

 

This and other changes = were made as a part of the DISCUSSion this past = week.

 

Your interpretation is = correct.  The problem trying to be solved was one of clarifying = where a client would direct a request.  I think it’s obvious = to me and you that if we were writing a client to query = acct:paulej@packetizer.com, we’d direct the query to = packetizer.com.  However, this was not stated, nor was guidance = given as to where one directs a request when there is no host portion in = the URI (e.g., “tel”).

 

If we introduce the text = you propose, then the next question might be how one domain becomes = authoritative for another domain.  More importantly, your proposed = wording removes the key statements the ADs were trying to make, and that = is guidance on how to determine where a query should be = directed.

 

Perhaps you would like = to just “soften” the wording, such as “query is = normally issued” or something?  Or, perhaps say “unless = a client is explicitly configured to direct queries elsewhere, = …”?

 

Now, what this text does = not intend to suggest is that 3xx redirection no longer works.  If = you have an msn.com account and the msn.com server wants that handled by = the live.com server, it could redirect the HTTP = request.

 

So, what do we do = here?

 

Paul

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: = Wednesday, April 17, 2013 1:30 PM
To: Paul E. Jones; = webfinger@ietf.org
Subject: New restriction added in WebFinger = -13 needs to be relaxed or clarified

 

This new = paragraph was added in WebFinger -13:

 

The host to which a WebFinger query is issued = is significant.  If the query target contains a “host” = portion (Section 3.2.2 of RFC 3986), then the host to which the = WebFinger query is issued MUST be the same as the “host” = portion of the query target. If the query target does not contain a = “host” portion, then the client MAY choose a host to which = it directs the query based on local policy.

 

I’m concerned that this paragraph just ruled = out using WebFinger to query for account identifiers at a host that = contain another hostname in the account identifier.  This is not a = hypothetical situation.  For instance, I have a Google account = whose identifier is mbj@microsoft.com.  It = appears that the new paragraph makes this well-formed and useful query = illegal:

 

GET = /.well-known/webfinger?resource=3Dacct%3Ambj%40microsoft.com = HTTP/1.1
Host: google.com

 

I = believe that the new paragraph either needs to be removed or clarified = in some manner to make it clear that a WebFinger server may respond to = resources that it is authoritative for even if the resource being = queried contains a different domain name.

 

Another example of a situation where one domain is = authoritative for others is Microsoft’s Internet mail service = domains.  At various times, the preferred domain has been msn.com, = hotmail.com, live.com, and outlook.com.  It’s perfectly = reasonable to query for an identifier containing msn.com at live.com, = for instance.

 

I’d suggest replacing this paragraph with = something like the following instead:

 

The host to which a WebFinger query is issued = is significant.  Different hosts hold authoritative information for = different identifiers.  WebFinger servers MUST NOT supply = information for identifiers that they are not authoritative for.  = Note, however, that a WebFinger server at one domain may be = authoritative for identifiers containing another domain.  For = instance the server example.com may host an account whose identifier is = acct:mary@example.org, and queries may be sent to the WebFinger server = at example.com about the account acct:mary@example.org that is hosted = there.

 

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

 

-----Original Message-----
From: webfinger-bounces@ietf.org= [mailto:webfinger-bounces@ietf.= org] On Behalf Of Paul E. Jones
Sent: Tuesday, April 16, 2013 = 7:56 PM
To: webfinger@ietf.org
Subject: = [webfinger] FW: New Version Notification - = draft-ietf-appsawg-webfinger-13.txt

 

FYI

 

> = -----Original Message-----

> = From: internet-drafts@ietf.org<= /span> [mailto:internet-drafts@ie= tf.org]

> Sent: = Tuesday, April 16, 2013 10:54 PM

> To: appsawg-chairs@tools.ietf= .org; draft-ietf-appsawg-

> webfinger@tools.ietf.org<= /span>; barryleiba@computer.org;

> presnick@qti.qualcomm.com= ; stephen.farrell@cs.tcd.ie= ; rlb@ipv.sx; =

> bclaise@cisco.com<= /a>; joelja@bogus.com

> Subject: New Version = Notification -

> = draft-ietf-appsawg-webfinger-13.txt

>

> =

> A new version (-13) has been = submitted for draft-ietf-appsawg-webfinger:

> http://www.ietf.org/inter= net-drafts/draft-ietf-appsawg-webfinger-13.tx

> t

> =

> Sub state has been changed = to AD Followup from Revised ID Needed

>

> =

> The IETF datatracker page = for this Internet-Draft is:

> = <= span = style=3D'color:windowtext;text-decoration:none'>https://datatracker.ietf.= org/doc/draft-ietf-appsawg-webfinger/

>

> = Diff from previous version:

> = http://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-appsawg-webfinger-13

>

> = IETF Secretariat.

 

 

_______________________________________________=

webfinger mailing = list

webfinger@ietf.org=

https://www.ietf.org/mail= man/listinfo/webfinger

------=_NextPart_000_040B_01CE3BD8.46490B90-- From paulej@packetizer.com Thu Apr 18 00:20:45 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8749F21F8E7A; Thu, 18 Apr 2013 00:20:45 -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 K7RUVdymQoN6; Thu, 18 Apr 2013 00:20:43 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3F24A21F8EE8; Thu, 18 Apr 2013 00:20: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 r3I7KPWL001749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Apr 2013 03:20:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1366269626; bh=bJiWNP+X6XOgnWG6H7/qUg9yi+8An+oJaoxcvYChYz8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Nl1iOVjAw5zc+FCpUM7UAzVmjuzoUhbdud8ZG4nHQOeFTbpz/QWX97DombK2xb99V P66tIaKI6EEtHTuSTP6I2HprKh3J/vzWBj7vfR43TbTisnVSl46lkB8bJiic5zuo9w lC5dBHmdHJI3iGyIM3E7lxYFlbChlBo/sJkTP8qI= From: "Paul E. Jones" To: "'Richard Barnes'" , "'Barry Leiba'" References: <4E1F6AAD24975D4BA5B16804296739436764B4E0@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Date: Thu, 18 Apr 2013 03:20:33 -0400 Message-ID: <042a01ce3c05$37d9b280$a78d1780$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_042B_01CE3BE3.B0C97210" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDsbQEnFYSxmqYUA1jkEkCklZZPLwFp1TuOAmA3VvKagNFeQA== Content-Language: en-us Cc: 'IESG' , webfinger@ietf.org, 'Mike Jones' , appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] Why was the HEAD method added to WebFinger in -13? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 07:20:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_042B_01CE3BE3.B0C97210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Richard, I would not go so far as to say I thought it was a good idea. I did say, in response to your proposal to expand on the methods allowed, that we probably ought not preclude HEAD. That said, I do agree with Mike on this. Personally, I'd rather say nothing about HEAD or other methods. The only reason I did say we ought not preclude it is that I can imagine some browsers trying to use it to see if the cache needs refreshing. So, I didn't want to forbid it, but I did feel mandating it was a bit much. The problem I faced when I inserted that text is that if we want to explicitly allow the client to send it, we have to have a statement about the server. I vote to strike the last paragraph in 4.2 relating to HEAD. If it's implemented, fine. If not, browsers should recover. For CORS, is a preflight request required when using a "simple method" (GET and HEAD both are). The text seems to suggest in the introduction that preflight checks are for non-simple methods (both in section 1 and section 6.2). Paul From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Wednesday, April 17, 2013 2:50 PM To: Barry Leiba Cc: Mike Jones; appsawg-chairs@tools.ietf.org; draft-ietf-appsawg-webfinger.all@tools.ietf.org; webfinger@ietf.org; IESG Subject: Re: [webfinger] Why was the HEAD method added to WebFinger in -13? Mike, The back story is this: -- My DISCUSS asked what methods should be allowed / required to a WebFinger URI -- Obviously GET is required -- Paul suggested that HEAD would also be useful Personally, I'm not sold on the utility of HEAD, especially as a MUST for servers. On the other hand, it occurs to me that servers will need to support OPTIONS for CORS pre-flight checks [1]. --Richard [1] On Wed, Apr 17, 2013 at 2:10 PM, Barry Leiba wrote: Mike, you have not followed the discussion outline: this isn't sent to sufficient recipients to get to the right people. +++ ACTION: Appsawg Chairs +++ I've added more recipients here, and this is asking the appsawg chairs to add this to the issue list, to be brought up in its turn. Please see my messages about the DISCUSS positions to get the discussion parameters. Thanks, Barry On Wed, Apr 17, 2013 at 1:30 PM, Mike Jones wrote: > WebFinger -13 added this paragraph: > > > > A WebFinger client MAY utilize the HEAD method when querying a WebFinger > resource. Consequently, a WebFinger resource MUST support the receipt of > the HEAD method. > > > > At least as I see it, this just increased the required implementation > footprint of WebFinger servers for no particular apparent gain. I'm curious > why this was added and whether others think that it's actually necessary or > useful. > > > > Thanks, > > -- Mike > > > > -----Original Message----- > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On > Behalf Of Paul E. Jones > Sent: Tuesday, April 16, 2013 7:56 PM > To: webfinger@ietf.org > Subject: [webfinger] FW: New Version Notification - > draft-ietf-appsawg-webfinger-13.txt > > > > FYI > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Tuesday, April 16, 2013 10:54 PM > >> To: appsawg-chairs@tools.ietf.org; draft-ietf-appsawg- > >> webfinger@tools.ietf.org; barryleiba@computer.org; > >> presnick@qti.qualcomm.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx; > >> bclaise@cisco.com; joelja@bogus.com > >> Subject: New Version Notification - > >> draft-ietf-appsawg-webfinger-13.txt > >> > >> > >> A new version (-13) has been submitted for draft-ietf-appsawg-webfinger: > >> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.tx > >> t > >> > >> Sub state has been changed to AD Followup from Revised ID Needed > >> > >> > >> The IETF datatracker page for this Internet-Draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > >> > >> Diff from previous version: > >> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-13 > >> > >> IETF Secretariat. > > > > > > _______________________________________________ > > webfinger mailing list > > webfinger@ietf.org > > https://www.ietf.org/mailman/listinfo/webfinger > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > ------=_NextPart_000_042B_01CE3BE3.B0C97210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Richard,

 

I would not go so far as to say I thought it was a good idea.  I = did say, in response to your proposal to expand on the methods allowed, = that we probably ought not preclude HEAD.  That said, I do agree = with Mike on this.  Personally, I’d rather say nothing about = HEAD or other methods.  The only reason I did say we ought not = preclude it is that I can imagine some browsers trying to use it to see = if the cache needs refreshing.  So, I didn’t want to forbid = it, but I did feel mandating it was a bit much.  The problem I = faced when I inserted that text is that if we want to explicitly allow = the client to send it, we have to have a statement about the = server.

 

I vote to strike the last paragraph in 4.2 relating to HEAD.  If = it’s implemented, fine.  If not, browsers should = recover.

 

For CORS, is a preflight request required when using a “simple = method” (GET and HEAD both are).  The text seems to suggest = in the introduction that preflight checks are for non-simple methods = (both in section 1 and section 6.2).

 

Paul

 

From:= = Richard Barnes [mailto:rlb@ipv.sx]
Sent: Wednesday, April 17, = 2013 2:50 PM
To: Barry Leiba
Cc: Mike Jones; = appsawg-chairs@tools.ietf.org; = draft-ietf-appsawg-webfinger.all@tools.ietf.org; webfinger@ietf.org; = IESG
Subject: Re: [webfinger] Why was the HEAD method added to = WebFinger in -13?

 

Mike,

 

The back story is this:

-- My DISCUSS asked what methods should be allowed / = required to a WebFinger URI

-- Obviously GET is = required

-- Paul suggested = that HEAD would also be useful

 

Personally, I'm not sold on the utility of HEAD, = especially as a MUST for servers.

 

On the other hand, it occurs to me that servers will = need to support OPTIONS for CORS pre-flight checks = [1].

 

--Richard

 

 

 

 

 

On Wed, Apr 17, 2013 at 2:10 PM, Barry Leiba <barryleiba@computer.org> = wrote:

Mike, you have not followed = the discussion outline: this isn't sent to
sufficient recipients to = get to the right people.

+++ ACTION: Appsawg Chairs +++
I've = added more recipients here, and this is asking the appsawg chairs
to = add this to the issue list, to be brought up in its turn. =  Please
see my messages about the DISCUSS positions to get the = discussion
parameters.

Thanks,
Barry

On Wed, Apr 17, = 2013 at 1:30 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
> WebFinger -13 added this = paragraph:
>
>
>
> A WebFinger client MAY = utilize the HEAD method when querying a WebFinger
> resource. =  Consequently, a WebFinger resource MUST support the receipt = of
> the HEAD method.
>
>
>
> At least as = I see it, this just increased the required implementation
> = footprint of WebFinger servers for no particular apparent gain. =  I’m curious
> why this was added and whether others = think that it’s actually necessary or
> = useful.
>
>
>
>         =                     =                     =                 = Thanks,
>
>               =                     =                     =           -- = Mike
>
>
>
> -----Original Message-----
> = From: webfinger-bounces@ietf.org= [mailto:webfinger-bounces@ietf.org= ] On
> Behalf Of Paul E. Jones
> Sent: Tuesday, April 16, = 2013 7:56 PM
> To: webfinger@ietf.org
> = Subject: [webfinger] FW: New Version Notification -
> = draft-ietf-appsawg-webfinger-13.txt
>
>
>
> = FYI
>
>
>
>> -----Original = Message-----
>
>> From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]>
>> Sent: Tuesday, April 16, 2013 10:54 = PM
>
>> To: appsawg-chairs@tools.ietf.o= rg; draft-ietf-appsawg-
>
>> webfinger@tools.ietf.org; = barryleiba@computer.org;
&= gt;
>> presnick@qti.qualcomm.com; = stephen.farrell@cs.tcd.ie; = rlb@ipv.sx;
>
>> bclaise@cisco.com; joelja@bogus.com
>
>>= Subject: New Version Notification -
>
>> = draft-ietf-appsawg-webfinger-13.txt
>
>>
>
>&g= t;
>
>> A new version (-13) has been submitted for = draft-ietf-appsawg-webfinger:
>
>> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-= webfinger-13.tx
>
>> = t
>
>>
>
>> Sub state has been changed to = AD Followup from Revised ID = Needed
>
>>
>
>>
>
>> The = IETF datatracker page for this Internet-Draft is:
>
>> https://datatracker.ietf.org/doc/draft-ietf-appsawg-web= finger/
>
>>
>
>> Diff from previous = version:
>
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-w= ebfinger-13
>
>>
>
>> IETF = Secretariat.
>
>
>
>
>
> = _______________________________________________
>
> = webfinger mailing list
>
> webfinger@ietf.org
>
>= https://www.ietf.org/mailman/listinfo/webfinger
= >
>
> = _______________________________________________
> webfinger = mailing list
> webfinger@ietf.org
> https://www.ietf.org/mailman/listinfo/webfinger
= >

 

------=_NextPart_000_042B_01CE3BE3.B0C97210-- From paulej@packetizer.com Thu Apr 18 00:36:53 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CA621F8E06 for ; Thu, 18 Apr 2013 00:36:53 -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 8qxvmCqINyUK for ; Thu, 18 Apr 2013 00:36:52 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5274D21F8E2C for ; Thu, 18 Apr 2013 00:36: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 r3I7al1x002664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Apr 2013 03:36:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1366270608; bh=PGaVk+Tq2cgUCZs+53tbDXEIWZi6RBNYATvcJITqz7Q=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=AmQsf8VYTuqmaoWV2T7FhE8b+YRdU0qtjVHB+7qTOuoqi5kDx7dI5nuxwOXrBD7QQ 9C2+bnGmerqPWRjjxooi7m6tp7NfOSCCZQrvKcuxTVEGzWPhDX2YsIZhe0qv4BzJjl EIyd7DADk4SJ6/ZiH4V6FXjJ6OGaoknPPl3bYWAs= From: "Paul E. Jones" To: "'nov matake'" , "'Mike Jones'" References: <4E1F6AAD24975D4BA5B16804296739436764B4CA@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Date: Thu, 18 Apr 2013 03:36:55 -0400 Message-ID: <043701ce3c07$80beab20$823c0160$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0438_01CE3BE5.F9AE91C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUKPlcfbjeiLjwoQYf4Z7gxYDKFAK/VNJEmDnBxIA= Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] New restriction added in WebFinger -13 needs to be relaxed or clarified X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 07:36:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0438_01CE3BE5.F9AE91C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The intent of the new text was to help the UA determine where to direct = the query. Redirection is still permitted and the Location: header = would dictate how the request is redirected, not the query target value. =20 Paul =20 From: nov matake [mailto:matake@gmail.com]=20 Sent: Wednesday, April 17, 2013 8:56 PM To: Mike Jones Cc: Paul E. Jones; webfinger@ietf.org Subject: Re: [webfinger] New restriction added in WebFinger -13 needs to = be relaxed or clarified =20 Does this text allow HTTP redirects at the webfinger endpoints? Or when a webfinger endpoint want to redirect the user agent, does it = have to omit "host" query? nov On Apr 18, 2013, at 2:29 AM, Mike Jones = wrote: This new paragraph was added in WebFinger -13: =20 The host to which a WebFinger query is issued is significant. If the = query target contains a =E2=80=9Chost=E2=80=9D portion (Section 3.2.2 of = RFC 3986), then the host to which the WebFinger query is issued MUST be = the same as the =E2=80=9Chost=E2=80=9D portion of the query target. If = the query target does not contain a =E2=80=9Chost=E2=80=9D portion, then = the client MAY choose a host to which it directs the query based on = local policy. =20 I=E2=80=99m concerned that this paragraph just ruled out using WebFinger = to query for account identifiers at a host that contain another hostname = in the account identifier. This is not a hypothetical situation. For = instance, I have a Google account whose identifier is mbj@microsoft.com. = It appears that the new paragraph makes this well-formed and useful = query illegal: =20 GET /.well-known/webfinger?resource=3Dacct%3Ambj%40microsoft.com = HTTP/1.1 Host: google.com =20 I believe that the new paragraph either needs to be removed or clarified = in some manner to make it clear that a WebFinger server may respond to = resources that it is authoritative for even if the resource being = queried contains a different domain name. =20 Another example of a situation where one domain is authoritative for = others is Microsoft=E2=80=99s Internet mail service domains. At various = times, the preferred domain has been msn.com, hotmail.com, live.com, and = outlook.com. It=E2=80=99s perfectly reasonable to query for an = identifier containing msn.com at live.com, for instance. =20 I=E2=80=99d suggest replacing this paragraph with something like the = following instead: =20 The host to which a WebFinger query is issued is significant. Different = hosts hold authoritative information for different identifiers. = WebFinger servers MUST NOT supply information for identifiers that they = are not authoritative for. Note, however, that a WebFinger server at = one domain may be authoritative for identifiers containing another = domain. For instance the server example.com may host an account whose = identifier is acct:mary@example.org, and queries may be sent to the = WebFinger server at example.com about the account acct:mary@example.org = that is hosted there. =20 -- Mike =20 -----Original Message----- From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Paul E. Jones Sent: Tuesday, April 16, 2013 7:56 PM To: webfinger@ietf.org Subject: [webfinger] FW: New Version Notification - = draft-ietf-appsawg-webfinger-13.txt =20 FYI =20 > -----Original Message----- > From: internet-drafts@ietf.org [ = mailto:internet-drafts@ietf.org] > Sent: Tuesday, April 16, 2013 10:54 PM > To: = appsawg-chairs@tools.ietf.org; draft-ietf-appsawg-=20 > webfinger@tools.ietf.org; = barryleiba@computer.org;=20 > presnick@qti.qualcomm.com; = stephen.farrell@cs.tcd.ie; = rlb@ipv.sx;=20 > bclaise@cisco.com; = joelja@bogus.com > Subject: New Version Notification -=20 > draft-ietf-appsawg-webfinger-13.txt >=20 >=20 > A new version (-13) has been submitted for = draft-ietf-appsawg-webfinger: > = = http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.tx > t >=20 > Sub state has been changed to AD Followup from Revised ID Needed >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > = https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ >=20 > Diff from previous version: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-13 >=20 > IETF Secretariat. =20 =20 _______________________________________________ webfinger mailing list webfinger@ietf.org = https://www.ietf.org/mailman/listinfo/webfinger _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_0438_01CE3BE5.F9AE91C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The intent of the new text was to help the UA = determine where to direct the query.=C2=A0 Redirection is still = permitted and the Location: header would dictate how the request is = redirected, not the query target value.

 

Paul

 

From:= = nov matake [mailto:matake@gmail.com]
Sent: Wednesday, April = 17, 2013 8:56 PM
To: Mike Jones
Cc: Paul E. Jones; = webfinger@ietf.org
Subject: Re: [webfinger] New restriction = added in WebFinger -13 needs to be relaxed or = clarified

 

Does = this text allow HTTP redirects at the webfinger = endpoints?

Or when a = webfinger endpoint want to redirect the user agent, does it have to omit = "host" query?


nov


On Apr 18, 2013, at 2:29 AM, Mike = Jones <Michael.Jones@microsoft.com> wrote:

This new paragraph was added in WebFinger = -13:

 

The host to which a = WebFinger query is issued is significant.  If the query target = contains a =E2=80=9Chost=E2=80=9D portion (Section 3.2.2 of RFC 3986), = then the host to which the WebFinger query is issued MUST be the same as = the =E2=80=9Chost=E2=80=9D portion of the query target. If the query = target does not contain a =E2=80=9Chost=E2=80=9D portion, then the = client MAY choose a host to which it directs the query based on local = policy.

 

I=E2=80=99m concerned that this paragraph just = ruled out using WebFinger to query for account identifiers at a host = that contain another hostname in the account identifier.  This is = not a hypothetical situation.  For instance, I have a Google = account whose identifier is mbj@microsoft.com.  It = appears that the new paragraph makes this well-formed and useful query = illegal:

 

GET = /.well-known/webfinger?resource=3Dacct%3Ambj%40microsoft.com HTTP/1.1
Host: google.com

 

I = believe that the new paragraph either needs to be removed or clarified = in some manner to make it clear that a WebFinger server may respond to = resources that it is authoritative for even if the resource being = queried contains a different domain name.

 

Another example of a situation where one domain is = authoritative for others is Microsoft=E2=80=99s Internet mail service = domains.  At various times, the preferred domain has been msn.com, hotmail.com, live.com, and outlook.com.  It=E2=80=99s = perfectly reasonable to query for an identifier containing msn.com at live.com, for instance.

 

I=E2=80=99d suggest replacing this paragraph with = something like the following instead:

 

The host to which a WebFinger query is issued = is significant.  Different hosts hold authoritative information for = different identifiers.  WebFinger servers MUST NOT supply = information for identifiers that they are not authoritative for.  = Note, however, that a WebFinger server at one domain may be = authoritative for identifiers containing another domain.  For = instance the server example.com may = host an account whose identifier is acct:mary@example.org, and queries may be sent to = the WebFinger server at example.com = about the account acct:mary@example.org that is hosted = there.

 

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

 

-----Original Message-----
From: webfinger-bounces@ietf.org= [mailto:webfinger-bounces@ietf.= org] On Behalf Of Paul E. Jones
Sent: Tuesday, April 16, 2013 = 7:56 PM
To: webfinger@ietf.org
Subject: = [webfinger] FW: New Version Notification - = draft-ietf-appsawg-webfinger-13.txt

 

FYI

 

> = -----Original Message-----

> = From: internet-drafts@ietf.org<= /span> [mailto:internet-drafts@ie= tf.org]

> Sent: = Tuesday, April 16, 2013 10:54 PM

> To: appsawg-chairs@tools.ietf= .org; draft-ietf-appsawg-

> webfinger@tools.ietf.org<= /span>; barryleiba@computer.org;

> presnick@qti.qualcomm.com= ; stephen.farrell@cs.tcd.ie= ; rlb@ipv.sx; =

> bclaise@cisco.com<= /a>; joelja@bogus.com

> Subject: New Version = Notification -

> = draft-ietf-appsawg-webfinger-13.txt

>

> =

> A new version (-13) has been = submitted for draft-ietf-appsawg-webfinger:

> http://www.ietf.org/inter= net-drafts/draft-ietf-appsawg-webfinger-13.tx

> t

> =

> Sub state has been changed = to AD Followup from Revised ID Needed

>

> =

> The IETF datatracker page = for this Internet-Draft is:

> = <= span = style=3D'color:windowtext;text-decoration:none'>https://datatracker.ietf.= org/doc/draft-ietf-appsawg-webfinger/

>

> = Diff from previous version:

> = http://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-appsawg-webfinger-13

>

> = IETF Secretariat.

 

 

_______________________________________________=

webfinger mailing = list

webfinger@ietf.org=

https://www.ietf.org/mail= man/listinfo/webfinger

_______________________________________________
webfin= ger mailing list
webfinger@ietf.org
https://www.ietf= .org/mailman/listinfo/webfinger

------=_NextPart_000_0438_01CE3BE5.F9AE91C0-- From paulej@packetizer.com Thu Apr 18 00:51:25 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806CD21F8F58 for ; Thu, 18 Apr 2013 00:51:25 -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 pIexsUm9Edo5 for ; Thu, 18 Apr 2013 00:51:24 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 80B5A21F8F62 for ; Thu, 18 Apr 2013 00:51: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 r3I7pGdf003523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Apr 2013 03:51:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1366271476; bh=B2ctOnY5ycLy7j00vBOthneaH3NCROlXGf4xuQgjddc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=RznkvRF0eKAMbWwEB//G1Rb5xzy99erZf/7IwMpPR6LB/vJSCY6h/RlX+vyUIklSk LptlwdQMALkqhAmGVE2h20rt+UY8+LFRuNaKzHE7tbhh4ad3pipPTi08fUF7euKidX eRf1f0SonCr3Sz/VATLypkxuDnRq7puwU7zMzq7I= From: "Paul E. Jones" To: "'Akron'" , References: <00f101ce1515$60213a90$2063afb0$@packetizer.com> In-Reply-To: Date: Thu, 18 Apr 2013 03:51:24 -0400 Message-ID: <045601ce3c09$86b69d10$9423d730$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0457_01CE3BE7.FFA57240" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIzn4Hhhy/cJFKUyle9gB4pbNL5uAFGb8OXmAafiTA= Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] List of client and server software X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 07:51:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0457_01CE3BE7.FFA57240 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cool. I=E2=80=99ve added it to the list here: http://www.packetizer.com/webfinger/software.html =20 Let me know if there is anything that should be changed. =20 Paul =20 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Akron Sent: Tuesday, April 16, 2013 8:51 AM To: webfinger@googlegroups.com Cc: webfinger@ietf.org Subject: Re: [webfinger] List of client and server software =20 Hello Paul, I published a WebFinger plugin for Mojolicious (Perl), that supports new = and old discovery, XRD as well as JRD, and the rel-parameter. It comes with a blocking and non-blocking interface. CPAN: http://search.cpan.org/dist/Mojolicious-Plugin-WebFinger/ GitHub: https://github.com/Akron/Mojolicious-Plugin-WebFinger Best, Nils ------=_NextPart_000_0457_01CE3BE7.FFA57240 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Cool.=C2=A0 I=E2=80=99ve added it to the list = here:

http://www.pac= ketizer.com/webfinger/software.html

 

Let me know if there is anything that should be = changed.

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Akron
Sent: Tuesday, April 16, 2013 8:51 = AM
To: webfinger@googlegroups.com
Cc: = webfinger@ietf.org
Subject: Re: [webfinger] List of client and = server software

 

Hello = Paul,

I published a WebFinger plugin for Mojolicious (Perl), that = supports new and old discovery, XRD as well as JRD, and the = rel-parameter.
It comes with a blocking and non-blocking = interface.

CPAN: http:/= /search.cpan.org/dist/Mojolicious-Plugin-WebFinger/
GitHub: https://gi= thub.com/Akron/Mojolicious-Plugin-WebFinger

Best,
Nils=

------=_NextPart_000_0457_01CE3BE7.FFA57240-- From melvincarvalho@gmail.com Thu Apr 18 00:56:57 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0090921F8F63 for ; Thu, 18 Apr 2013 00:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499, 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 jT88svlRfpwP for ; Thu, 18 Apr 2013 00:56:55 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5072521F8F4E for ; Thu, 18 Apr 2013 00:56:55 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id r11so2406722lbv.40 for ; Thu, 18 Apr 2013 00:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aNzKq2kf5Qo4vtSw3aalVchkz3w9rE5U13bGdAor4ZI=; b=x7+2gXkgEmDaPQ5Iv8K0iURxoyJTRna2rx5X/4V+JWYKuyyRO7yVyg50BfHNlAsSP9 F0tQ+GJnm206HeKjVE5WH0RsceHcIsG3isPzMzPztZMuvil5jqliTKwXl+ECV9cZaovE 4/4YIiQRRORhTvJCjUknqLTIogHpChzrGRMyz/RNJgGN4Zyu/T6+sveAydh0clLIn60q IeGzkhpic9qfegNc2zPQbwB+PL1SRm+BpPqrbpYH2fKVsy8lnHA1kjokvm4nub7YRixA BQWG5M9WU16FuhDzkk3SWCxttet7xd8qCjw9Pii8jPrp0ugTigPz8NTtFP91u9taPLnV 5Hgw== MIME-Version: 1.0 X-Received: by 10.152.6.229 with SMTP id e5mr5239151laa.6.1366271813966; Thu, 18 Apr 2013 00:56:53 -0700 (PDT) Received: by 10.112.143.38 with HTTP; Thu, 18 Apr 2013 00:56:53 -0700 (PDT) In-Reply-To: <03e301ce3bd7$35e4fd50$a1aef7f0$@packetizer.com> References: <20130417025405.14655.86603.idtracker@ietfa.amsl.com> <026801ce3b17$0e958690$2bc093b0$@packetizer.com> <03e301ce3bd7$35e4fd50$a1aef7f0$@packetizer.com> Date: Thu, 18 Apr 2013 09:56:53 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e01493f96240cf504da9df25e Cc: webfinger Subject: Re: [webfinger] FW: New Version Notification - draft-ietf-appsawg-webfinger-13.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 07:56:57 -0000 --089e01493f96240cf504da9df25e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 18 April 2013 03:51, Paul E. Jones wrote: > Melvin,**** > > ** ** > > That=92s an interesting observation. I was apparently mistaken that it w= as > required for LRDD resources, but looking back at the older specifications= , > that does not seem to be the case.**** > > ** ** > > Given that every example I found related to LRDD included a =93subject=94= , I > think the intent was that it should be required. The only explicit > exception in the text I can find where =93subject=94 =93should not=94 be = present is > in RFC 6415 with respect to host host-meta resource itself. No comment i= s > made with respect to LRDD.**** > > ** ** > > So, we have three options:**** > > **1) **Mandate its presence (current text)**** > > **2) **Say that it SHOULD be present in the JRD > +1 SHOULD. This is similar text to XRD > **** > > **3) **Say it is OPTIONAL in the JRD**** > > ** ** > > What is the preference here?**** > > ** ** > > Paul**** > > ** ** > > *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com] > *Sent:* Wednesday, April 17, 2013 4:32 AM > *To:* Paul E. Jones > *Cc:* webfinger > *Subject:* Re: [webfinger] FW: New Version Notification - > draft-ietf-appsawg-webfinger-13.txt**** > > ** ** > > ** ** > > ** ** > > On 17 April 2013 04:55, Paul E. Jones wrote:**** > > FYI > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Tuesday, April 16, 2013 10:54 PM > > To: appsawg-chairs@tools.ietf.org; draft-ietf-appsawg- > > webfinger@tools.ietf.org; barryleiba@computer.org; > > presnick@qti.qualcomm.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx; > > bclaise@cisco.com; joelja@bogus.com > > Subject: New Version Notification - draft-ietf-appsawg-webfinger-13.txt > > > > > > A new version (-13) has been submitted for draft-ietf-appsawg-webfinger= : > > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.txt= * > *** > > ** ** > > Hi Paul, I just noticed something odd.**** > > In most EAV description languages, the subject term is optional. The is > true, for example, in XRD and RDF.**** > > I've noticed in section 4.4.1.**** > > The "subject" member MUST be present in the JRD.**** > > ** ** > > This would make JRD as a serialization inconsistent, and *perhaps*, in > some cases not 100% interoperable with others.**** > > I was just wondering if there was a conscious decision in making this > change when moving from XRD -> JRD or if it was unintended.**** > > ** ** > > **** > > > > > Sub state has been changed to AD Followup from Revised ID Needed > > > > > > The IETF datatracker page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > > > > Diff from previous version: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-13 > > > > IETF Secretariat. > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger**** > > ** ** > --089e01493f96240cf504da9df25e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On 18 April 2013 03:51, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

=A0<= /p>

That=92s an interestin= g observation.=A0 I was apparently mistaken that it was required for LRDD r= esources, but looking back at the older specifications, that does not seem = to be the case.

=A0<= /p>

Given that every examp= le I found related to LRDD included a =93subject=94, I think the intent was= that it should be required.=A0 The only explicit exception in the text I c= an find where =93subject=94 =93should not=94 be present is in RFC 6415 with= respect to host host-meta resource itself.=A0 No comment is made with resp= ect to LRDD.

=A0<= /p>

So, we have three opti= ons:

1)=A0=A0=A0=A0=A0 Mandate its presence (current text)

2)=A0=A0=A0=A0=A0 Say that it SHOULD be present in the JRD

+1 SHOULD.=A0 This is similar text to XRD
=A0

3)=A0=A0=A0=A0=A0 Say it is OPTIONAL in the JRD

=A0<= /p>

What is the preference= here?

=A0<= /p>

Paul

=A0<= /p>

=A0=

=A0

=A0

On 17 April 2013 04:55, Paul E. Jones <paulej@packetizer.com> wrote:

FYI

> -----Original Message-----
> F= rom: internet= -drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Tuesday, April 16, 2013 10:54 PM
> To: appsawg-chairs@tools.ietf.o= rg; draft-ietf-appsawg-
> webfinger@tools.ietf.org; barryleiba@computer.org;
> presnic= k@qti.qualcomm.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx;
> bclaise@cisco.c= om; joelja@bogus.= com
> Subject: New Version Notification - draft-ietf-appsawg-webf= inger-13.txt
>
>
> A new version (-13) has been submitted for draft-ietf-= appsawg-webfinger:
> http://www.ietf.org/i= nternet-drafts/draft-ietf-appsawg-webfinger-13.txt

=A0

Hi Paul, I just noticed something od= d.

In most EAV description languages, the subject term is optional.=A0 The is = true, for example, in XRD and RDF.

I've noticed in section 4.4.1= .

=A0=A0 The "subject" member MUST be present in the JRD.

=A0

This would make JRD as a s= erialization inconsistent, and *perhaps*, in some cases not 100% interopera= ble with others.

I was just wondering if there was a consc= ious decision in making this change when moving from XRD -> JRD or if it= was unintended.

= =A0

=A0

>
> S= ub state has been changed to AD Followup from Revised ID Needed
>
>
> The IETF datatracker page for this Internet-Draft is:<= br>> https://datatracker.ietf.org/doc/draft-ietf-appsa= wg-webfinger/
>
> Diff from previous version:
> http= ://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-13
><= br>> IETF Secretariat.


_______________________________________________
webfinger mailin= g list
webfinger= @ietf.org
https://www.ietf.org/mailman/listinfo/webfinger<= /u>

=A0

=

--089e01493f96240cf504da9df25e-- From paulej@packetizer.com Thu Apr 18 01:19:38 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8C721F8F0D; Thu, 18 Apr 2013 01:19: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=[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 KkFt6JZFflC8; Thu, 18 Apr 2013 01:19:36 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0A27621F89AF; Thu, 18 Apr 2013 01:19: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 r3I8JKLJ005232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Apr 2013 04:19:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1366273161; bh=8UtzmjPnGynyqiLQmb6nJta0C4VIX4VnbofmmX0EmCo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WhfkvYNOeQZhbkeeEu5zcEteWIT79N9QkSANcRTYq/RKQBGubpuYToZvjvZIy2JgN kPqXcxxKoKCzIAGOIqfz7n03dsAsIVB7fuc3ATCcydPKu6Ai4j1Oi4J0OIoRh1BAb+ 20QZqLOqCALxd/wLGj/0aWTIVu/VUPHL7QZ8HSS0= From: "Paul E. Jones" To: "'Stephen Farrell'" , "'Barry Leiba'" References: <516EC7BB.2050409@cs.tcd.ie> In-Reply-To: <516EC7BB.2050409@cs.tcd.ie> Date: Thu, 18 Apr 2013 04:19:29 -0400 Message-ID: <048201ce3c0d$72f47d70$58dd7850$@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: AQKF+rJ19Sq3YwmLzkQPsCCUeEFrLgKJ4oOVAMxuZnOXUW6SsA== Content-Language: en-us Cc: webfinger@ietf.org, appsawg-chairs@tools.ietf.org, 'The IESG' , draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] All the DISCUSS positions on draft-ietf-appsawg-webfinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 08:19:38 -0000 Stephen, > >> "WebFinger MUST NOT be used to provide any personal data to any > >> party unless explicitly authorized by the person whose information is > >> being shared. > > I do think the above isn't well specified. And that does touch > on my discuss point #1, even if that wasn't very clear (my > fault;-) I agree that we're probably better off starting with > fixing this bit though regardless of how discuss points are > written up. > > The MUST NOT could be read to mean that Alice has to say who is > and who is not allowed access to Alice's information when she decides > to make that available via WF. Its not clear that the "explicitly > authorized" means only "by Alice for whoever the WF service allows" > and not e.g. "by Alice for Bob" or "by Alice for her friends" or > "by Alice for people in .de" > > Now I know that the intent is not to require Alice to specify > who can access her stuff, but it could be read to mean that, > e.g. by some over-zealous regulator. (And that over-zealous > regulator might then say that having the automated access in > 3.1 succeed isn't ok, which is the link to my discuss point #1.) > > I think what was meant was more like: > > WebFinger MUST NOT be used to provide any personal data unless > publishing that data via WebFinger by the relevant service > was explicitly authorized by the person whose information > is being shared. Yeah, that's the intent. Your wording sounds fine to me. > I think that (or an equivalent) were stated in 8.2 then that'd > be better and would break the link with my discuss point#1. > (It doesn't clear discuss point#1 though.) > > It might also imply that if the terms of service change then > maybe the WF operator needs to ask Alice again, I don't know. > (Not that they would or anything;-) Don't go boil an ocean. > >> - 8.2, this is outstandingly glib: "If one does not wish to > >> share certain information with the world, do not allow that > >> information to be freely accessible on the Internet or > >> discoverable via WebFinger" - most users are never given a > >> choice as to whether or not much of their information is > >> freely accessible or not. I think the best that can be done > >> with that is to delete it. > > Nah, that was always just a non-blocking comment. I do > still think the statement is glib though, and would be > better deleted. Most real users don't have a real choice > here and pretending they do is bogus. They do have a > choice to use or not use some service, but at a much > higher level than we generally mean with that term. > E.g. they might use or not use FB or G+ but after that > most of the rest is just pretence that the user has a > real choice as to what else happens with their data. Don't ask me to try to defend a statement in the privacy section. I already think it goes overboard and tries to scare people into not using WebFinger. Substitute WF with (whatever service) and it's true. So, I'm not sure what to do with it. I would not hesitate to remove it if asked. And while we're at it, can we remove WF being a tool that enables a person "to inflict harm" on someone? > > Is this general issue still of top importance to discuss? I think > > it's really Stephen and Richard who need to weigh in on that. And > > Joel isn't happy with the way 2119 language is used to express this: > > > >> 8.2 > >> > >> Further, WebFinger MUST NOT be used to provide any personal data > to > >> any party unless explicitly authorized by the person whose > >> information is being shared. > >> > >> This is a usage guideline not a part of the protocol specification. > At a > >> minimum it should use non-normative language. probably it should be > replaced > >> with a description of the potential for exposure. > > I would argue that its a valid MUST NOT since it addresses > a security/privacy issue even if not an interop issue, so > I'd rather keep the 2119 term. I agree that might not be a > winning argument. For security it would be valid I think > to say you MUST NOT use a crap PRNG which is arguably > similar enough. We don't have such a consensus for privacy > related statements afaik, though perhaps we ought try to > develop that. In any case, the MUST NOT doesn't hurt anyone > and does help some folks, so I'd say keeping it is better. > (I'd live with a non-normative statement, if need be.) So, do we make it lowercase or change it to REALLY SHOULD NOT? ;-) Paul From stephen.farrell@cs.tcd.ie Thu Apr 18 02:10:05 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C641821F859A; Thu, 18 Apr 2013 02:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=0.400, 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 u6v80VClKYrp; Thu, 18 Apr 2013 02:10:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A3B6E21F855A; Thu, 18 Apr 2013 02:10:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1D49EBE58; Thu, 18 Apr 2013 10:09:42 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSpmLeq+xst6; Thu, 18 Apr 2013 10:09:42 +0100 (IST) Received: from [IPv6:2001:770:10:203:cd09:7301:31dd:57e4] (unknown [IPv6:2001:770:10:203:cd09:7301:31dd:57e4]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EC506BE51; Thu, 18 Apr 2013 10:09:41 +0100 (IST) Message-ID: <516FB856.6050503@cs.tcd.ie> Date: Thu, 18 Apr 2013 10:09:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Paul E. Jones" References: <516EC7BB.2050409@cs.tcd.ie> <048201ce3c0d$72f47d70$58dd7850$@packetizer.com> In-Reply-To: <048201ce3c0d$72f47d70$58dd7850$@packetizer.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: webfinger@ietf.org, appsawg-chairs@tools.ietf.org, 'Barry Leiba' , 'The IESG' , draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] All the DISCUSS positions on draft-ietf-appsawg-webfinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 09:10:05 -0000 Hi Paul, On 04/18/2013 09:19 AM, Paul E. Jones wrote: > Stephen, > >>>> "WebFinger MUST NOT be used to provide any personal data to any >>>> party unless explicitly authorized by the person whose information is >>>> being shared. >> >> I do think the above isn't well specified. And that does touch >> on my discuss point #1, even if that wasn't very clear (my >> fault;-) I agree that we're probably better off starting with >> fixing this bit though regardless of how discuss points are >> written up. >> >> The MUST NOT could be read to mean that Alice has to say who is >> and who is not allowed access to Alice's information when she decides >> to make that available via WF. Its not clear that the "explicitly >> authorized" means only "by Alice for whoever the WF service allows" >> and not e.g. "by Alice for Bob" or "by Alice for her friends" or >> "by Alice for people in .de" >> >> Now I know that the intent is not to require Alice to specify >> who can access her stuff, but it could be read to mean that, >> e.g. by some over-zealous regulator. (And that over-zealous >> regulator might then say that having the automated access in >> 3.1 succeed isn't ok, which is the link to my discuss point #1.) >> >> I think what was meant was more like: >> >> WebFinger MUST NOT be used to provide any personal data unless >> publishing that data via WebFinger by the relevant service >> was explicitly authorized by the person whose information >> is being shared. > > Yeah, that's the intent. Your wording sounds fine to me. So I think on this point the remaining issue is for the folks who think the 2119 term above is bogus to speak up. (And just lower casing is not a fix, we don't have IETF consensus as to whether or not that makes any difference.) I think using MUST NOT there is good I guess its over to Joel who has the opposite opinion in his discuss. S. > >> I think that (or an equivalent) were stated in 8.2 then that'd >> be better and would break the link with my discuss point#1. >> (It doesn't clear discuss point#1 though.) >> >> It might also imply that if the terms of service change then >> maybe the WF operator needs to ask Alice again, I don't know. >> (Not that they would or anything;-) > > Don't go boil an ocean. > >>>> - 8.2, this is outstandingly glib: "If one does not wish to >>>> share certain information with the world, do not allow that >>>> information to be freely accessible on the Internet or >>>> discoverable via WebFinger" - most users are never given a >>>> choice as to whether or not much of their information is >>>> freely accessible or not. I think the best that can be done >>>> with that is to delete it. >> >> Nah, that was always just a non-blocking comment. I do >> still think the statement is glib though, and would be >> better deleted. Most real users don't have a real choice >> here and pretending they do is bogus. They do have a >> choice to use or not use some service, but at a much >> higher level than we generally mean with that term. >> E.g. they might use or not use FB or G+ but after that >> most of the rest is just pretence that the user has a >> real choice as to what else happens with their data. > > Don't ask me to try to defend a statement in the privacy section. I already > think it goes overboard and tries to scare people into not using WebFinger. > Substitute WF with (whatever service) and it's true. So, I'm not sure what > to do with it. I would not hesitate to remove it if asked. > > And while we're at it, can we remove WF being a tool that enables a person > "to inflict harm" on someone? > >>> Is this general issue still of top importance to discuss? I think >>> it's really Stephen and Richard who need to weigh in on that. And >>> Joel isn't happy with the way 2119 language is used to express this: >>> >>>> 8.2 >>>> >>>> Further, WebFinger MUST NOT be used to provide any personal data >> to >>>> any party unless explicitly authorized by the person whose >>>> information is being shared. >>>> >>>> This is a usage guideline not a part of the protocol specification. >> At a >>>> minimum it should use non-normative language. probably it should be >> replaced >>>> with a description of the potential for exposure. >> >> I would argue that its a valid MUST NOT since it addresses >> a security/privacy issue even if not an interop issue, so >> I'd rather keep the 2119 term. I agree that might not be a >> winning argument. For security it would be valid I think >> to say you MUST NOT use a crap PRNG which is arguably >> similar enough. We don't have such a consensus for privacy >> related statements afaik, though perhaps we ought try to >> develop that. In any case, the MUST NOT doesn't hurt anyone >> and does help some folks, so I'd say keeping it is better. >> (I'd live with a non-normative statement, if need be.) > > So, do we make it lowercase or change it to REALLY SHOULD NOT? ;-) > > Paul > > From barryleiba.mailing.lists@gmail.com Thu Apr 18 08:15:25 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E1021F8F4E for ; Thu, 18 Apr 2013 08:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.952 X-Spam-Level: X-Spam-Status: No, score=-101.952 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 90gr1g9vp4KW for ; Thu, 18 Apr 2013 08:15:24 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CCBDF21F8F0A for ; Thu, 18 Apr 2013 08:15:22 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 11so2481467vbe.5 for ; Thu, 18 Apr 2013 08:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rNB8mGq37h85RPMB8+uKkfJl/qNUfAGRLJouHcjRT6Q=; b=UU+ZM5H/3MDEHcsvubUw5r58HZo9NH67qwWUgKyKcKeOsXJfOxrr2MJHzx7KF6kgni jV3SlX/33BvnovuA3mKKBnja1VSyrhtUEymMyJjLRxkQvbEXrzWpyuPCuYYAxI5R10pz ZAygCy0VYBJK4UaU296fKHrqj4ohvnfLoQlQofm+wNTIdVi/NCVuiTKpdoSI5wjis/ZG AKU3QMaw0KfxU6DtzzzaOqXm3d7MWVUgnV+V1pmJym6bqFmYEKidj2z8mY7QP1TY4128 E1NDvXG/m+srBGjdxMFwfIt1C8FTpXsqtGQyGijbvCJw89FcKoO+yaEau6LJUYRGhyS1 SMUw== MIME-Version: 1.0 X-Received: by 10.52.72.40 with SMTP id a8mr7355729vdv.20.1366298122208; Thu, 18 Apr 2013 08:15:22 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Thu, 18 Apr 2013 08:15:22 -0700 (PDT) In-Reply-To: <040a01ce3bf9$cd594c00$680be400$@packetizer.com> References: <4E1F6AAD24975D4BA5B16804296739436764B4CA@TK5EX14MBXC283.redmond.corp.microsoft.com> <040a01ce3bf9$cd594c00$680be400$@packetizer.com> Date: Thu, 18 Apr 2013 11:15:22 -0400 X-Google-Sender-Auth: hvCUuGqsUXH8-jMUM6HYHxNbJ7o Message-ID: From: Barry Leiba To: "Paul E. Jones" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "webfinger@ietf.org" , Mike Jones Subject: Re: [webfinger] New restriction added in WebFinger -13 needs to be relaxed or clarified X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 15:15:25 -0000 > If we introduce the text you propose, then the next question might be how > one domain becomes authoritative for another domain. ... > Perhaps you would like to just =93soften=94 the wording, such as =93query= is > normally issued=94 or something? Or, perhaps say =93unless a client is > explicitly configured to direct queries elsewhere, =85=94? I think it's not as simple as this, because many domains are using the user's email address as an account name. That email address can be on any arbitrary domain, so authority doesn't enter into it. This needs some significant discussion to sort it out. Let's please not have that discussion now; let's follow the discussion management, and know that we've recorded this as an issue that will come up in its turn. Thanks. Barry, Applications AD On Thu, Apr 18, 2013 at 1:58 AM, Paul E. Jones wrot= e: > Mike, > > This and other changes were made as a part of the DISCUSSion this past we= ek. > > Your interpretation is correct. The problem trying to be solved was one = of > clarifying where a client would direct a request. I think it=92s obvious= to > me and you that if we were writing a client to query > acct:paulej@packetizer.com, we=92d direct the query to packetizer.com. > However, this was not stated, nor was guidance given as to where one dire= cts > a request when there is no host portion in the URI (e.g., =93tel=94). > > If we introduce the text you propose, then the next question might be how > one domain becomes authoritative for another domain. More importantly, y= our > proposed wording removes the key statements the ADs were trying to make, = and > that is guidance on how to determine where a query should be directed. > > Perhaps you would like to just =93soften=94 the wording, such as =93query= is > normally issued=94 or something? Or, perhaps say =93unless a client is > explicitly configured to direct queries elsewhere, =85=94? > > Now, what this text does not intend to suggest is that 3xx redirection no > longer works. If you have an msn.com account and the msn.com server want= s > that handled by the live.com server, it could redirect the HTTP request. > > So, what do we do here? > > Paul > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Wednesday, April 17, 2013 1:30 PM > To: Paul E. Jones; webfinger@ietf.org > Subject: New restriction added in WebFinger -13 needs to be relaxed or > clarified > > This new paragraph was added in WebFinger -13: > > The host to which a WebFinger query is issued is significant. If the que= ry > target contains a =93host=94 portion (Section 3.2.2 of RFC 3986), then th= e host > to which the WebFinger query is issued MUST be the same as the =93host=94 > portion of the query target. If the query target does not contain a =93ho= st=94 > portion, then the client MAY choose a host to which it directs the query > based on local policy. > > I=92m concerned that this paragraph just ruled out using WebFinger to que= ry > for account identifiers at a host that contain another hostname in the > account identifier. This is not a hypothetical situation. For instance,= I > have a Google account whose identifier is mbj@microsoft.com. It appears > that the new paragraph makes this well-formed and useful query illegal: > > GET /.well-known/webfinger?resource=3Dacct%3Ambj%40microsoft.com HTTP/1.1 > Host: google.com > > I believe that the new paragraph either needs to be removed or clarified = in > some manner to make it clear that a WebFinger server may respond to > resources that it is authoritative for even if the resource being queried > contains a different domain name. > > Another example of a situation where one domain is authoritative for othe= rs > is Microsoft=92s Internet mail service domains. At various times, the > preferred domain has been msn.com, hotmail.com, live.com, and outlook.com= . > It=92s perfectly reasonable to query for an identifier containing msn.com= at > live.com, for instance. > > I=92d suggest replacing this paragraph with something like the following > instead: > > The host to which a WebFinger query is issued is significant. Different > hosts hold authoritative information for different identifiers. WebFinge= r > servers MUST NOT supply information for identifiers that they are not > authoritative for. Note, however, that a WebFinger server at one domain = may > be authoritative for identifiers containing another domain. For instance > the server example.com may host an account whose identifier is > acct:mary@example.org, and queries may be sent to the WebFinger server at > example.com about the account acct:mary@example.org that is hosted there. > > -- Mike From paulej@packetizer.com Thu Apr 18 18:53:00 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E17621F8EC9; Thu, 18 Apr 2013 18:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6wt2-r99SdL; Thu, 18 Apr 2013 18:52:59 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 32ABA21F8EB1; Thu, 18 Apr 2013 18:52:56 -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 r3J1qilH012997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Apr 2013 21:52:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1366336367; bh=HR7Mw/1VggarbD2y22XDOoX1p6Fpp2rBC8Oy9OX6byE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=c7fg0GjlmfJ2idkl6xJLRYTiP3tojbB0P89//96Vqesd3OIhzJFyaAleQlHEc+uHy KjRqkyUcF0fjT6L1mOi9F2oDTUPImy9Dgf6IsGjIE84v5r6wL/E1B8f/1OeKPuJNki 9af6czXVJaIRPZjPx7wRbIBYx6HCnw+U5w8xoFVM= From: "Paul E. Jones" To: "'Stephen Farrell'" References: <516EC7BB.2050409@cs.tcd.ie> <048201ce3c0d$72f47d70$58dd7850$@packetizer.com> <516FB856.6050503@cs.tcd.ie> In-Reply-To: <516FB856.6050503@cs.tcd.ie> Date: Thu, 18 Apr 2013 21:52:53 -0400 Message-ID: <022c01ce3ca0$9d92a370$d8b7ea50$@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: AQKF+rJ19Sq3YwmLzkQPsCCUeEFrLgKJ4oOVAMxuZnMBqcRkZwBRuAGGl0K9GsA= Content-Language: en-us Cc: webfinger@ietf.org, appsawg-chairs@tools.ietf.org, 'Barry Leiba' , 'The IESG' , draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] All the DISCUSS positions on draft-ietf-appsawg-webfinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 01:53:00 -0000 What about the statement in the privacy section. Leave it or remove it? Paul > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, April 18, 2013 5:10 AM > To: Paul E. Jones > Cc: 'Barry Leiba'; webfinger@ietf.org; appsawg-chairs@tools.ietf.org; > 'The IESG'; draft-ietf-appsawg-webfinger.all@tools.ietf.org > Subject: Re: All the DISCUSS positions on draft-ietf-appsawg-webfinger > > > Hi Paul, > > On 04/18/2013 09:19 AM, Paul E. Jones wrote: > > Stephen, > > > >>>> "WebFinger MUST NOT be used to provide any personal data to any > >>>> party unless explicitly authorized by the person whose information > is > >>>> being shared. > >> > >> I do think the above isn't well specified. And that does touch > >> on my discuss point #1, even if that wasn't very clear (my > >> fault;-) I agree that we're probably better off starting with > >> fixing this bit though regardless of how discuss points are > >> written up. > >> > >> The MUST NOT could be read to mean that Alice has to say who is > >> and who is not allowed access to Alice's information when she decides > >> to make that available via WF. Its not clear that the "explicitly > >> authorized" means only "by Alice for whoever the WF service allows" > >> and not e.g. "by Alice for Bob" or "by Alice for her friends" or > >> "by Alice for people in .de" > >> > >> Now I know that the intent is not to require Alice to specify > >> who can access her stuff, but it could be read to mean that, > >> e.g. by some over-zealous regulator. (And that over-zealous > >> regulator might then say that having the automated access in > >> 3.1 succeed isn't ok, which is the link to my discuss point #1.) > >> > >> I think what was meant was more like: > >> > >> WebFinger MUST NOT be used to provide any personal data unless > >> publishing that data via WebFinger by the relevant service > >> was explicitly authorized by the person whose information > >> is being shared. > > > > Yeah, that's the intent. Your wording sounds fine to me. > > So I think on this point the remaining issue is for the folks > who think the 2119 term above is bogus to speak up. (And just > lower casing is not a fix, we don't have IETF consensus as to > whether or not that makes any difference.) > > I think using MUST NOT there is good I guess its over to Joel > who has the opposite opinion in his discuss. > > S. > > > > >> I think that (or an equivalent) were stated in 8.2 then that'd > >> be better and would break the link with my discuss point#1. > >> (It doesn't clear discuss point#1 though.) > >> > >> It might also imply that if the terms of service change then > >> maybe the WF operator needs to ask Alice again, I don't know. > >> (Not that they would or anything;-) > > > > Don't go boil an ocean. > > > >>>> - 8.2, this is outstandingly glib: "If one does not wish to > >>>> share certain information with the world, do not allow that > >>>> information to be freely accessible on the Internet or > >>>> discoverable via WebFinger" - most users are never given a > >>>> choice as to whether or not much of their information is > >>>> freely accessible or not. I think the best that can be done > >>>> with that is to delete it. > >> > >> Nah, that was always just a non-blocking comment. I do > >> still think the statement is glib though, and would be > >> better deleted. Most real users don't have a real choice > >> here and pretending they do is bogus. They do have a > >> choice to use or not use some service, but at a much > >> higher level than we generally mean with that term. > >> E.g. they might use or not use FB or G+ but after that > >> most of the rest is just pretence that the user has a > >> real choice as to what else happens with their data. > > > > Don't ask me to try to defend a statement in the privacy section. I > already > > think it goes overboard and tries to scare people into not using > WebFinger. > > Substitute WF with (whatever service) and it's true. So, I'm not sure > what > > to do with it. I would not hesitate to remove it if asked. > > > > And while we're at it, can we remove WF being a tool that enables a > person > > "to inflict harm" on someone? > > > >>> Is this general issue still of top importance to discuss? I think > >>> it's really Stephen and Richard who need to weigh in on that. And > >>> Joel isn't happy with the way 2119 language is used to express this: > >>> > >>>> 8.2 > >>>> > >>>> Further, WebFinger MUST NOT be used to provide any personal data > >> to > >>>> any party unless explicitly authorized by the person whose > >>>> information is being shared. > >>>> > >>>> This is a usage guideline not a part of the protocol specification. > >> At a > >>>> minimum it should use non-normative language. probably it should be > >> replaced > >>>> with a description of the potential for exposure. > >> > >> I would argue that its a valid MUST NOT since it addresses > >> a security/privacy issue even if not an interop issue, so > >> I'd rather keep the 2119 term. I agree that might not be a > >> winning argument. For security it would be valid I think > >> to say you MUST NOT use a crap PRNG which is arguably > >> similar enough. We don't have such a consensus for privacy > >> related statements afaik, though perhaps we ought try to > >> develop that. In any case, the MUST NOT doesn't hurt anyone > >> and does help some folks, so I'd say keeping it is better. > >> (I'd live with a non-normative statement, if need be.) > > > > So, do we make it lowercase or change it to REALLY SHOULD NOT? ;-) > > > > Paul > > > > From rlb@ipv.sx Thu Apr 18 09:45:42 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E0221F8F4E for ; Thu, 18 Apr 2013 09:45:42 -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.582, 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 1GMPBNcoBUH2 for ; Thu, 18 Apr 2013 09:45:41 -0700 (PDT) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 08F5A21F8F4D for ; Thu, 18 Apr 2013 09:45:40 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id n9so2925497oag.20 for ; Thu, 18 Apr 2013 09:45:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=S7EjB7AtoZH/jgnBVaEVj2EnU09XX0CSI7E7JommE30=; b=UPC8nC8ONsxFzCVOW6wWxyPH4tybvJwfyfE97RJJPwoKz1X6Fd1dBEbKtLTL3QCdbQ 2o0GuETdHPTj/5EmXQUtVBVUkUrk/lVKRwSZHWj435Lch0yyf+2G2Kz9nH6Sd5FMpI3e tuTumZayBvNL6AViIOzfV6xksK/pXE4sY1ltv2110Le25W5adQtk4wLzPlqhLDQXyHoz EAfzN/w1vaVjuJIk3DGZaDabPbQj/MJW8k8hL0Y6YEhH3WNIZM2mRouEK+sWRq4aeRcW wG5isMpvsoSMOW8EnBa/0bnFoGzuO5XRFZmPURkTzBRFzIUksmYEQg+zBRApCJtLPNel UoKw== MIME-Version: 1.0 X-Received: by 10.182.235.49 with SMTP id uj17mr1022496obc.18.1366303540384; Thu, 18 Apr 2013 09:45:40 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Thu, 18 Apr 2013 09:45:40 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <042a01ce3c05$37d9b280$a78d1780$@packetizer.com> References: <4E1F6AAD24975D4BA5B16804296739436764B4E0@TK5EX14MBXC283.redmond.corp.microsoft.com> <042a01ce3c05$37d9b280$a78d1780$@packetizer.com> Date: Thu, 18 Apr 2013 12:45:40 -0400 Message-ID: From: Richard Barnes To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=bcaec53969522e2b5904daa55581 X-Gm-Message-State: ALoCoQm51bro7vEwHQpZ2GUSAhASWj8qjEDWChgzn1aWhEZV4h2fTsT+DtwciPIF/C/R3gcvth0W X-Mailman-Approved-At: Thu, 18 Apr 2013 23:04:35 -0700 Cc: appsawg-chairs@tools.ietf.org, Mike Jones , IESG , draft-ietf-appsawg-webfinger.all@tools.ietf.org, webfinger@ietf.org, Barry Leiba Subject: Re: [webfinger] Why was the HEAD method added to WebFinger in -13? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 16:45:42 -0000 --bcaec53969522e2b5904daa55581 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry if I overstated your position. That's a good point that CORS pre-flight is not required for GET/HEAD. There might be some concern about non-simple headers. So it seems servers might still want to support it. How about the following change? OLD: """ A WebFinger client MAY utilize the HEAD method when querying a WebFinger resource. Consequently, a WebFinger resource MUST support the receipt of the HEAD method. """ NEW: """ WebFinger clients MAY perform HEAD requests to a WebFinger resource. For example, a HEAD request could be used to see if a cache needs refreshing. Clients MAY also send CORS pre-flight requests (if a request uses non-simple headers), which use the HTTP OPTIONS method. Servers SHOULD support the HEAD and OPTIONS methods for WebFinger resources. """ On Thu, Apr 18, 2013 at 3:20 AM, Paul E. Jones wrote= : > Richard,**** > > ** ** > > I would not go so far as to say I thought it was a good idea. I did say, > in response to your proposal to expand on the methods allowed, that we > probably ought not preclude HEAD. That said, I do agree with Mike on > this. Personally, I=92d rather say nothing about HEAD or other methods. = The > only reason I did say we ought not preclude it is that I can imagine some > browsers trying to use it to see if the cache needs refreshing. So, I > didn=92t want to forbid it, but I did feel mandating it was a bit much. = The > problem I faced when I inserted that text is that if we want to explicitl= y > allow the client to send it, we have to have a statement about the server= . > **** > > ** ** > > I vote to strike the last paragraph in 4.2 relating to HEAD. If it=92s > implemented, fine. If not, browsers should recover.**** > > ** ** > > For CORS, is a preflight request required when using a =93simple method= =94 > (GET and HEAD both are). The text seems to suggest in the introduction > that preflight checks are for non-simple methods (both in section 1 and > section 6.2).**** > > ** ** > > Paul**** > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Wednesday, April 17, 2013 2:50 PM > *To:* Barry Leiba > *Cc:* Mike Jones; appsawg-chairs@tools.ietf.org; > draft-ietf-appsawg-webfinger.all@tools.ietf.org; webfinger@ietf.org; IESG > *Subject:* Re: [webfinger] Why was the HEAD method added to WebFinger in > -13?**** > > ** ** > > Mike,**** > > ** ** > > The back story is this:**** > > -- My DISCUSS asked what methods should be allowed / required to a > WebFinger URI**** > > -- Obviously GET is required**** > > -- Paul suggested that HEAD would also be useful**** > > ** ** > > Personally, I'm not sold on the utility of HEAD, especially as a MUST for > servers.**** > > ** ** > > On the other hand, it occurs to me that servers will need to support > OPTIONS for CORS pre-flight checks [1].**** > > ** ** > > --Richard**** > > ** ** > > [1] ***= * > > ** ** > > ** ** > > ** ** > > ** ** > > On Wed, Apr 17, 2013 at 2:10 PM, Barry Leiba > wrote:**** > > Mike, you have not followed the discussion outline: this isn't sent to > sufficient recipients to get to the right people. > > +++ ACTION: Appsawg Chairs +++ > I've added more recipients here, and this is asking the appsawg chairs > to add this to the issue list, to be brought up in its turn. Please > see my messages about the DISCUSS positions to get the discussion > parameters. > > Thanks, > Barry > > On Wed, Apr 17, 2013 at 1:30 PM, Mike Jones > wrote: > > WebFinger -13 added this paragraph: > > > > > > > > A WebFinger client MAY utilize the HEAD method when querying a WebFinge= r > > resource. Consequently, a WebFinger resource MUST support the receipt = of > > the HEAD method. > > > > > > > > At least as I see it, this just increased the required implementation > > footprint of WebFinger servers for no particular apparent gain. I=92m > curious > > why this was added and whether others think that it=92s actually necess= ary > or > > useful. > > > > > > > > Thanks, > > > > -- Mike > > > > > > > > -----Original Message----- > > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On > > Behalf Of Paul E. Jones > > Sent: Tuesday, April 16, 2013 7:56 PM > > To: webfinger@ietf.org > > Subject: [webfinger] FW: New Version Notification - > > draft-ietf-appsawg-webfinger-13.txt > > > > > > > > FYI > > > > > > > >> -----Original Message----- > > > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > >> Sent: Tuesday, April 16, 2013 10:54 PM > > > >> To: appsawg-chairs@tools.ietf.org; draft-ietf-appsawg- > > > >> webfinger@tools.ietf.org; barryleiba@computer.org; > > > >> presnick@qti.qualcomm.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx; > > > >> bclaise@cisco.com; joelja@bogus.com > > > >> Subject: New Version Notification - > > > >> draft-ietf-appsawg-webfinger-13.txt > > > >> > > > >> > > > >> A new version (-13) has been submitted for draft-ietf-appsawg-webfinge= r: > > > >> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.tx > > > >> t > > > >> > > > >> Sub state has been changed to AD Followup from Revised ID Needed > > > >> > > > >> > > > >> The IETF datatracker page for this Internet-Draft is: > > > >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > > > >> > > > >> Diff from previous version: > > > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-13 > > > >> > > > >> IETF Secretariat. > > > > > > > > > > > > _______________________________________________ > > > > webfinger mailing list > > > > webfinger@ietf.org > > > > https://www.ietf.org/mailman/listinfo/webfinger > > > > > > _______________________________________________ > > webfinger mailing list > > webfinger@ietf.org > > https://www.ietf.org/mailman/listinfo/webfinger > >**** > > ** ** > --bcaec53969522e2b5904daa55581 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry if I overstated your position.

That's a good p= oint that CORS pre-flight is not required for GET/HEAD. =A0There might be s= ome concern about non-simple headers. =A0So it seems servers might still wa= nt to support it.

How about the following change?

OLD:
"""
A WebFinger client MAY u= tilize the HEAD method when querying a WebFinger resource. =A0Consequently,= a WebFinger resource MUST support the receipt of the HEAD method.
"""

NEW:
"= ;""
WebFinger clients MAY perform HEAD requests to a We= bFinger resource. =A0For example, a HEAD request could be used to see if a = cache needs refreshing. =A0Clients MAY also send CORS pre-flight requests (= if a request uses non-simple headers), which use the HTTP OPTIONS method. S= ervers SHOULD support the HEAD and OPTIONS methods for WebFinger resources.=
"""




On Thu, Apr 18, 2013 at 3:20 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Richard,

=A0<= /p>

I would not go so far = as to say I thought it was a good idea.=A0 I did say, in response to your p= roposal to expand on the methods allowed, that we probably ought not preclu= de HEAD.=A0 That said, I do agree with Mike on this.=A0 Personally, I=92d r= ather say nothing about HEAD or other methods.=A0 The only reason I did say= we ought not preclude it is that I can imagine some browsers trying to use= it to see if the cache needs refreshing.=A0 So, I didn=92t want to forbid = it, but I did feel mandating it was a bit much.=A0 The problem I faced when= I inserted that text is that if we want to explicitly allow the client to = send it, we have to have a statement about the server.=

=A0<= /p>

I vote to strike the l= ast paragraph in 4.2 relating to HEAD.=A0 If it=92s implemented, fine.=A0 I= f not, browsers should recover.

=A0<= /p>

For CORS, is a preflig= ht request required when using a =93simple method=94 (GET and HEAD both are= ).=A0 The text seems to suggest in the introduction that preflight checks a= re for non-simple methods (both in section 1 and section 6.2).

=A0<= /p>

Paul

=A0<= /p>

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Wednesday, April 17, 2013 2:50 PM
To: Barry LeibaCc: Mike Jones; appsawg-chairs@tools.ietf.org; draft-ietf-app= sawg-webfinger.all@tools.ietf.org; webfinger@ietf.org; IESG
Subject: Re: [webfinger] Why was the HEAD method added to WebFinger = in -13?

=A0

Mike,<= /u>

=A0

The back story is this:

-- My DISCUSS asked what methods should be allowed / required to a = WebFinger URI

-- Obviously GET is required

-- Paul suggested that HEAD would al= so be useful

=A0<= u>

Personally, I'm not sold on the utili= ty of HEAD, especially as a MUST for servers.

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

On the other hand, it occurs to me that servers will need to support OPTI= ONS for CORS pre-flight checks [1].

=A0

--Richard

=A0

=A0

On Wed, Apr 17, 2013 at 2:10 PM, Barry Leiba &l= t;barryleiba@c= omputer.org> wrote:

Mike, yo= u have not followed the discussion outline: this isn't sent to
sufficient recipients to get to the right people.

+++ ACTION: Appsaw= g Chairs +++
I've added more recipients here, and this is asking the= appsawg chairs
to add this to the issue list, to be brought up in its t= urn. =A0Please
see my messages about the DISCUSS positions to get the discussion
parame= ters.

Thanks,
Barry

On Wed, Apr 17, 2013 at 1:30 PM, Mike = Jones <= Michael.Jones@microsoft.com> wrote:
> WebFinger -13 added this paragraph:
>
>
>
> A = WebFinger client MAY utilize the HEAD method when querying a WebFinger
&= gt; resource. =A0Consequently, a WebFinger resource MUST support the receip= t of
> the HEAD method.
>
>
>
> At least as I see it,= this just increased the required implementation
> footprint of WebFi= nger servers for no particular apparent gain. =A0I=92m curious
> why = this was added and whether others think that it=92s actually necessary or > useful.
>
>
>
> =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 Thanks,
>
> =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
>
>
>
> -----Original Message-----
> From: webfinger-bounces@ietf.org [= mailto:webf= inger-bounces@ietf.org] On
> Behalf Of Paul E. Jones
> Sent: Tuesday, April 16, 2013 7:56 PM<= br>> To: webfing= er@ietf.org
> Subject: [webfinger] FW: New Version Notification -=
> draft-ietf-appsawg-webfinger-13.txt
>
>
>
> FY= I
>
>
>
>> -----Original Message-----
>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>
>> Sent: Tuesday, April 16, 2013 10:54 PM
>
>>= To: app= sawg-chairs@tools.ietf.org; draft-ietf-appsawg-
>
>> webfinger@tools.= ietf.org; = barryleiba@computer.org;
>
>> presnick@qti.qualcomm.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx;
>
>> bcl= aise@cisco.com; j= oelja@bogus.com
>
>> Subject: New Version Notification -=
>
>> draft-ietf-appsawg-webfinger-13.txt
>
>>>
>>
>
>> A new version (-13) has been submitte= d for draft-ietf-appsawg-webfinger:
>
>> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.= tx
>
>> t
>
>>
>
>> Sub state has be= en changed to AD Followup from Revised ID Needed
>
>>
>= ;
>>
>
>> The IETF datatracker page for this Intern= et-Draft is:
>
>> https://datatracker.ietf.org/doc/draft-i= etf-appsawg-webfinger/
>
>>
>
>> Diff fro= m previous version:
>
>> http://www.ietf.org/rfcdiff?url2=3Dd= raft-ietf-appsawg-webfinger-13
>
>>
>
>> = IETF Secretariat.
>
>
>
>
>
> ______________________________= _________________
>
> webfinger mailing list
>
> webfinger@ietf.org
>
> https://www.ietf.org/mailman/listinfo/webfinger
>=
>
> _______________________________________________
> we= bfinger mailing list
> webfinger@ietf= .org
> https://www.ietf.org/mailman/listinfo/webfinger
= >

=A0

<= /div>

--bcaec53969522e2b5904daa55581-- From ve7jtb@ve7jtb.com Fri Apr 19 07:16:10 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8D921F8FED for ; Fri, 19 Apr 2013 07:16:10 -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 J8cG7MisZCrT for ; Fri, 19 Apr 2013 07:16:09 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB3321F8FD5 for ; Fri, 19 Apr 2013 07:16:08 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id jy17so2674180qeb.11 for ; Fri, 19 Apr 2013 07:16:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=3+PkpaoNpNlV5aHYX4LKE4ydZGA/4lpHKlMgLFi/b7k=; b=csEASlQE0Nq/QTGMRDg0dl+OJ+RAoxhQjVK4tuKOVntCldxxOfDF55mBl/jaOnODbg v/OYu7P0I7L+U+/ygyjopDEmNuB1At7ZQA3K2adLqcm/FSdmgSBlic8K0QBkqfTDxnb4 iLxljxDkyfKeM1n7cAc0VWGET6Yso8DnL4k131pIk1azY+XT5ap1L0QzM6O3ShceXbFJ fgVdX5v7INW3zja0KWeztx3uI5yvRqVqR1Mlgjzw76SfAOqemE0vMnhxDqAhzYhfjEPb 8qua+j6HCOTY7Xt503uiGkX6M6P8waI1Zko3i/to42KTKDwJ6USW+kJCkCquMG1VX6xy Os2w== X-Received: by 10.224.73.7 with SMTP id o7mr14114555qaj.58.1366380968317; Fri, 19 Apr 2013 07:16:08 -0700 (PDT) Received: from [192.168.1.44] (190-20-56-217.baf.movistar.cl. [190.20.56.217]) by mx.google.com with ESMTPS id dl6sm17877149qab.12.2013.04.19.07.15.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Apr 2013 07:16:06 -0700 (PDT) References: <4E1F6AAD24975D4BA5B16804296739436764B4E0@TK5EX14MBXC283.redmond.corp.microsoft.com> <042a01ce3c05$37d9b280$a78d1780$@packetizer.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-DBD72D85-10F0-4829-8478-8C7AC5D4A154; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <42C31ECA-CC86-4786-9B18-92A17584AAD0@ve7jtb.com> X-Mailer: iPhone Mail (10B329) From: John Bradley Date: Fri, 19 Apr 2013 11:15:30 -0300 To: Richard Barnes X-Gm-Message-State: ALoCoQlyAvSSypXEYyxh2rl1hnuGkqgTKBO6+ZOBul9jC2wMJV9/Bh6pyGppbYa1j8BJIGtacQNZ Cc: Mike Jones , "Paul E. Jones" , "appsawg-chairs@tools.ietf.org" , IESG , "draft-ietf-appsawg-webfinger.all@tools.ietf.org" , "webfinger@ietf.org" , Barry Leiba Subject: Re: [webfinger] Why was the HEAD method added to WebFinger in -13? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:16:10 -0000 --Apple-Mail-DBD72D85-10F0-4829-8478-8C7AC5D4A154 Content-Type: multipart/alternative; boundary=Apple-Mail-3DB01AF8-9283-4865-A605-7D6B27BF29EC Content-Transfer-Encoding: 7bit --Apple-Mail-3DB01AF8-9283-4865-A605-7D6B27BF29EC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes that is reasonable.=20 Sent from my iPhone On 2013-04-18, at 1:45 PM, Richard Barnes wrote: > Sorry if I overstated your position. >=20 > That's a good point that CORS pre-flight is not required for GET/HEAD. Th= ere might be some concern about non-simple headers. So it seems servers mig= ht still want to support it. >=20 > How about the following change? >=20 > OLD: > """ > A WebFinger client MAY utilize the HEAD method when querying a WebFinger r= esource. Consequently, a WebFinger resource MUST support the receipt of the= HEAD method. > """ >=20 > NEW: > """ > WebFinger clients MAY perform HEAD requests to a WebFinger resource. For e= xample, a HEAD request could be used to see if a cache needs refreshing. Cl= ients MAY also send CORS pre-flight requests (if a request uses non-simple h= eaders), which use the HTTP OPTIONS method. Servers SHOULD support the HEAD a= nd OPTIONS methods for WebFinger resources. > """ >=20 >=20 >=20 >=20 > On Thu, Apr 18, 2013 at 3:20 AM, Paul E. Jones wro= te: >> Richard, >>=20 >> =20 >>=20 >> I would not go so far as to say I thought it was a good idea. I did say,= in response to your proposal to expand on the methods allowed, that we prob= ably ought not preclude HEAD. That said, I do agree with Mike on this. Per= sonally, I=E2=80=99d rather say nothing about HEAD or other methods. The on= ly reason I did say we ought not preclude it is that I can imagine some brow= sers trying to use it to see if the cache needs refreshing. So, I didn=E2=80= =99t want to forbid it, but I did feel mandating it was a bit much. The pro= blem I faced when I inserted that text is that if we want to explicitly allo= w the client to send it, we have to have a statement about the server. >>=20 >> =20 >>=20 >> I vote to strike the last paragraph in 4.2 relating to HEAD. If it=E2=80= =99s implemented, fine. If not, browsers should recover. >>=20 >> =20 >>=20 >> For CORS, is a preflight request required when using a =E2=80=9Csimple me= thod=E2=80=9D (GET and HEAD both are). The text seems to suggest in the int= roduction that preflight checks are for non-simple methods (both in section 1= and section 6.2). >>=20 >> =20 >>=20 >> Paul >>=20 >> =20 >>=20 >> From: Richard Barnes [mailto:rlb@ipv.sx]=20 >> Sent: Wednesday, April 17, 2013 2:50 PM >> To: Barry Leiba >> Cc: Mike Jones; appsawg-chairs@tools.ietf.org; draft-ietf-appsawg-webfing= er.all@tools.ietf.org; webfinger@ietf.org; IESG >> Subject: Re: [webfinger] Why was the HEAD method added to WebFinger in -1= 3? >>=20 >> =20 >>=20 >> Mike, >>=20 >> =20 >>=20 >> The back story is this: >>=20 >> -- My DISCUSS asked what methods should be allowed / required to a WebFin= ger URI >>=20 >> -- Obviously GET is required >>=20 >> -- Paul suggested that HEAD would also be useful >>=20 >> =20 >>=20 >> Personally, I'm not sold on the utility of HEAD, especially as a MUST for= servers. >>=20 >> =20 >>=20 >> On the other hand, it occurs to me that servers will need to support OPTI= ONS for CORS pre-flight checks [1]. >>=20 >> =20 >>=20 >> --Richard >>=20 >> =20 >>=20 >> [1] >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Wed, Apr 17, 2013 at 2:10 PM, Barry Leiba wr= ote: >>=20 >> Mike, you have not followed the discussion outline: this isn't sent to >> sufficient recipients to get to the right people. >>=20 >> +++ ACTION: Appsawg Chairs +++ >> I've added more recipients here, and this is asking the appsawg chairs >> to add this to the issue list, to be brought up in its turn. Please >> see my messages about the DISCUSS positions to get the discussion >> parameters. >>=20 >> Thanks, >> Barry >>=20 >> On Wed, Apr 17, 2013 at 1:30 PM, Mike Jones = wrote: >> > WebFinger -13 added this paragraph: >> > >> > >> > >> > A WebFinger client MAY utilize the HEAD method when querying a WebFinge= r >> > resource. Consequently, a WebFinger resource MUST support the receipt o= f >> > the HEAD method. >> > >> > >> > >> > At least as I see it, this just increased the required implementation >> > footprint of WebFinger servers for no particular apparent gain. I=E2=80= =99m curious >> > why this was added and whether others think that it=E2=80=99s actually n= ecessary or >> > useful. >> > >> > >> > >> > Thanks,= >> > >> > -- Mike= >> > >> > >> > >> > -----Original Message----- >> > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On= >> > Behalf Of Paul E. Jones >> > Sent: Tuesday, April 16, 2013 7:56 PM >> > To: webfinger@ietf.org >> > Subject: [webfinger] FW: New Version Notification - >> > draft-ietf-appsawg-webfinger-13.txt >> > >> > >> > >> > FYI >> > >> > >> > >> >> -----Original Message----- >> > >> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> > >> >> Sent: Tuesday, April 16, 2013 10:54 PM >> > >> >> To: appsawg-chairs@tools.ietf.org; draft-ietf-appsawg- >> > >> >> webfinger@tools.ietf.org; barryleiba@computer.org; >> > >> >> presnick@qti.qualcomm.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx; >> > >> >> bclaise@cisco.com; joelja@bogus.com >> > >> >> Subject: New Version Notification - >> > >> >> draft-ietf-appsawg-webfinger-13.txt >> > >> >> >> > >> >> >> > >> >> A new version (-13) has been submitted for draft-ietf-appsawg-webfinge= r: >> > >> >> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.tx= >> > >> >> t >> > >> >> >> > >> >> Sub state has been changed to AD Followup from Revised ID Needed >> > >> >> >> > >> >> >> > >> >> The IETF datatracker page for this Internet-Draft is: >> > >> >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ >> > >> >> >> > >> >> Diff from previous version: >> > >> >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-13 >> > >> >> >> > >> >> IETF Secretariat. >> > >> > >> > >> > >> > >> > _______________________________________________ >> > >> > webfinger mailing list >> > >> > webfinger@ietf.org >> > >> > https://www.ietf.org/mailman/listinfo/webfinger >> > >> > >> > _______________________________________________ >> > webfinger mailing list >> > webfinger@ietf.org >> > https://www.ietf.org/mailman/listinfo/webfinger >> > >>=20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail-3DB01AF8-9283-4865-A605-7D6B27BF29EC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes that is reasonable. 

S= ent from my iPhone

On 2013-04-18, at 1:45 PM, Richard Barnes &= lt;rlb@ipv.sx> wrote:

Sorry if I overstated your position.

That's a good point that CORS pre-flight is not required for GET/HEAD= .  There might be some concern about non-simple headers.  So it se= ems servers might still want to support it.

How about the following change?

OLD:
"""
A WebFinger client MAY utilize the HEAD m= ethod when querying a WebFinger resource.  Consequently, a WebFinger re= source MUST support the receipt of the HEAD method.
"""

NEW:
"""
WebFing= er clients MAY perform HEAD requests to a WebFinger resource.  For exam= ple, a HEAD request could be used to see if a cache needs refreshing.  = Clients MAY also send CORS pre-flight requests (if a request uses non-simple= headers), which use the HTTP OPTIONS method. Servers SHOULD support the HEA= D and OPTIONS methods for WebFinger resources.
"""




On Thu, Apr 18, 2013 at 3:20 AM, Paul E. Jones <= ;paulej@packetize= r.com> wrote:

Richard,

 =

I would not go so far a= s to say I thought it was a good idea.  I did say, in response to your p= roposal to expand on the methods allowed, that we probably ought not preclud= e HEAD.  That said, I do agree with Mike on this.  Personally, I=E2= =80=99d rather say nothing about HEAD or other methods.  The only reaso= n I did say we ought not preclude it is that I can imagine some browsers try= ing to use it to see if the cache needs refreshing.  So, I didn=E2=80=99= t want to forbid it, but I did feel mandating it was a bit much.  The p= roblem I faced when I inserted that text is that if we want to explicitly al= low the client to send it, we have to have a statement about the server.<= /u>

 =

I vote to strike the la= st paragraph in 4.2 relating to HEAD.  If it=E2=80=99s implemented, fin= e.  If not, browsers should recover.

 =

For CORS, is a prefligh= t request required when using a =E2=80=9Csimple method=E2=80=9D (GET and HEA= D both are).  The text seems to suggest in the introduction that prefli= ght checks are for non-simple methods (both in section 1 and section 6.2).

 =

Paul

 =

From:= Richard Barnes [mailto:rlb@= ipv.sx]
Sent: Wednesday, April 17, 2013 2:50 PM
To: Barry Leiba
= Cc: Mike Jones; appsawg-chairs@tools.ietf.org; draft-ietf-appsawg= -webfinger.all@tools.ietf.org; webfinger@ietf.org; IESG
Subject: Re: [webfinger] Why was the HEAD method added to WebFinger i= n -13?

 

Mike,

 

The back story is this:

-- My DISCUSS asked what methods should be allowed / required to a W= ebFinger URI

-- Obviously GET is required=

-- Paul suggested that HEAD would also= be useful

 <= u>

Personally, I'm not sold on the utility of= HEAD, especially as a MUST for servers.

 

On= the other hand, it occurs to me that servers will need to support OPTIONS f= or CORS pre-flight checks [1].

 

--Richard

 

 

On Wed, Apr 17, 2013 at 2:10 PM, Barry Leiba <= ;barryleiba@com= puter.org> wrote:

Mike, you h= ave not followed the discussion outline: this isn't sent to
sufficient recipients to get to the right people.

+++ ACTION: Appsawg= Chairs +++
I've added more recipients here, and this is asking the appsa= wg chairs
to add this to the issue list, to be brought up in its turn. &n= bsp;Please
see my messages about the DISCUSS positions to get the discussion
paramet= ers.

Thanks,
Barry

On Wed, Apr 17, 2013 at 1:30 PM, Mike Jo= nes <Mic= hael.Jones@microsoft.com> wrote:
> WebFinger -13 added this paragraph:
>
>
>
> A W= ebFinger client MAY utilize the HEAD method when querying a WebFinger
>= ; resource.  Consequently, a WebFinger resource MUST support the receip= t of
> the HEAD method.
>
>
>
> At least as I see it, t= his just increased the required implementation
> footprint of WebFinge= r servers for no particular apparent gain.  I=E2=80=99m curious
>= why this was added and whether others think that it=E2=80=99s actually nece= ssary or
> useful.
>
>
>
>         &nb= sp;                     &n= bsp;                     &= nbsp;           Thanks,
>
>   &nbs= p;                     &nb= sp;                     &n= bsp;                 -- Mike
>=
>
>
> -----Original Message-----
> From: webfinger-bounces@ietf.org [ma= ilto:webfing= er-bounces@ietf.org] On
> Behalf Of Paul E. Jones
> Sent: Tuesday, April 16, 2013 7:56 PM> To: webfinger= @ietf.org
> Subject: [webfinger] FW: New Version Notification - > draft-ietf-appsawg-webfinger-13.txt
>
>
>
> FYI=
>
>
>
>> -----Original Message-----
>
&= gt;> From: = internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>
>> Sent: Tuesday, April 16, 2013 10:54 PM
>
>> T= o: appsaw= g-chairs@tools.ietf.org; draft-ietf-appsawg-
>
>> webfinger@tools.ietf.= org; barryl= eiba@computer.org;
>
>> presnick@qti.qualcomm.com; stephen.farrell@cs.tcd.ie; rlb@ipv.sx;
>
>> bcla= ise@cisco.com; joe= lja@bogus.com
>
>> Subject: New Version Notification - >
>> draft-ietf-appsawg-webfinger-13.txt
>
>>
= >
>>
>
>> A new version (-13) has been submitted f= or draft-ietf-appsawg-webfinger:
>
>> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-13.tx=
>
>> t
>
>>
>
>> Sub state has bee= n changed to AD Followup from Revised ID Needed
>
>>
><= br>>>
>
>> The IETF datatracker page for this Internet-= Draft is:
>
>> https://datatracker.ietf.org/doc/draft-iet= f-appsawg-webfinger/
>
>>
>
>> Diff from p= revious version:
>
>> http://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-appsawg-webfinger-13
>
>>
>
>> IET= F Secretariat.
>
>
>
>
>
> _______________________________= ________________
>
> webfinger mailing list
>
> webfinger@ietf.org >
> https://www.ietf.org/mailman/listinfo/webfinger
>>
> _______________________________________________
> webfi= nger mailing list
> webfinger@ietf.= org
> https://www.ietf.org/mailman/listinfo/webfinger
>=

 


____________________= ___________________________
webfinger mailing listwebfinger@ietf.orghttps://= www.ietf.org/mailman/listinfo/webfinger
= --Apple-Mail-3DB01AF8-9283-4865-A605-7D6B27BF29EC-- --Apple-Mail-DBD72D85-10F0-4829-8478-8C7AC5D4A154 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw 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+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDQxOTE0MTU0N1owIwYJKoZIhvcNAQkEMRYEFCFS MA25r3408SulTdDMItnonmwBMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBAGEzuU+gxsltykIgyCnDu+Sn0Bokl4Yl2VsF hCWEzy/DKQls94PTeMclOLlTMSdNuRuQRpz7NNy7eOH93Do5qGLokMOaDcyPYqb1kefCCdNw7NmU tG79CoadznYGpdxRX+zN+JtlvXuKedVkY1K/lPku7EFpjE+PfdEeCpxdT7RUaFzI6dKatj9gdq8h sjpmHoO0MyngwVoKTTk52d89zQ7gsea1rkzkxg8ikGBR1b4vis5dqCUAL0PpddHx/j6gvkMK6Lt/ Vr5TstCihx5s4llYcGEAUwPJv9tTAlKOq5/ONAuEaJeEdVwYDYCLf0Ih9JYG4w2VtwBfJhQvVMxj TKwAAAAAAAA= --Apple-Mail-DBD72D85-10F0-4829-8478-8C7AC5D4A154-- From stephen.farrell@cs.tcd.ie Fri Apr 19 07:35:39 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A9921F9289; Fri, 19 Apr 2013 07:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJ5zpvDgxIfX; Fri, 19 Apr 2013 07:35:38 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5015821F8FC6; Fri, 19 Apr 2013 07:35:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A331FBE73; Fri, 19 Apr 2013 15:35:16 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSToFAVRq1qU; Fri, 19 Apr 2013 15:35:16 +0100 (IST) Received: from [IPv6:2001:770:10:203:745e:856:cc83:8d02] (unknown [IPv6:2001:770:10:203:745e:856:cc83:8d02]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5BBBDBE70; Fri, 19 Apr 2013 15:35:16 +0100 (IST) Message-ID: <51715624.7030901@cs.tcd.ie> Date: Fri, 19 Apr 2013 15:35:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Paul E. Jones" References: <516EC7BB.2050409@cs.tcd.ie> <048201ce3c0d$72f47d70$58dd7850$@packetizer.com> <516FB856.6050503@cs.tcd.ie> <022c01ce3ca0$9d92a370$d8b7ea50$@packetizer.com> In-Reply-To: <022c01ce3ca0$9d92a370$d8b7ea50$@packetizer.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: webfinger@ietf.org, appsawg-chairs@tools.ietf.org, 'Barry Leiba' , 'The IESG' , draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] All the DISCUSS positions on draft-ietf-appsawg-webfinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:35:39 -0000 On 04/19/2013 02:52 AM, Paul E. Jones wrote: > What about the statement in the privacy section. Leave it or remove it? Just to be sure, you mean this one: "If one does not wish to share certain information with the world, do not allow that information to be freely accessible on the Internet or discoverable via WebFinger" I'm for taking it out. The MUST NOT phrase does the job and this doesn't help IMO. But its a comment, so up to you and Barry as far as I'm concerned. S. > > Paul > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Thursday, April 18, 2013 5:10 AM >> To: Paul E. Jones >> Cc: 'Barry Leiba'; webfinger@ietf.org; appsawg-chairs@tools.ietf.org; >> 'The IESG'; draft-ietf-appsawg-webfinger.all@tools.ietf.org >> Subject: Re: All the DISCUSS positions on draft-ietf-appsawg-webfinger >> >> >> Hi Paul, >> >> On 04/18/2013 09:19 AM, Paul E. Jones wrote: >>> Stephen, >>> >>>>>> "WebFinger MUST NOT be used to provide any personal data to any >>>>>> party unless explicitly authorized by the person whose information >> is >>>>>> being shared. >>>> >>>> I do think the above isn't well specified. And that does touch >>>> on my discuss point #1, even if that wasn't very clear (my >>>> fault;-) I agree that we're probably better off starting with >>>> fixing this bit though regardless of how discuss points are >>>> written up. >>>> >>>> The MUST NOT could be read to mean that Alice has to say who is >>>> and who is not allowed access to Alice's information when she decides >>>> to make that available via WF. Its not clear that the "explicitly >>>> authorized" means only "by Alice for whoever the WF service allows" >>>> and not e.g. "by Alice for Bob" or "by Alice for her friends" or >>>> "by Alice for people in .de" >>>> >>>> Now I know that the intent is not to require Alice to specify >>>> who can access her stuff, but it could be read to mean that, >>>> e.g. by some over-zealous regulator. (And that over-zealous >>>> regulator might then say that having the automated access in >>>> 3.1 succeed isn't ok, which is the link to my discuss point #1.) >>>> >>>> I think what was meant was more like: >>>> >>>> WebFinger MUST NOT be used to provide any personal data unless >>>> publishing that data via WebFinger by the relevant service >>>> was explicitly authorized by the person whose information >>>> is being shared. >>> >>> Yeah, that's the intent. Your wording sounds fine to me. >> >> So I think on this point the remaining issue is for the folks >> who think the 2119 term above is bogus to speak up. (And just >> lower casing is not a fix, we don't have IETF consensus as to >> whether or not that makes any difference.) >> >> I think using MUST NOT there is good I guess its over to Joel >> who has the opposite opinion in his discuss. >> >> S. >> >>> >>>> I think that (or an equivalent) were stated in 8.2 then that'd >>>> be better and would break the link with my discuss point#1. >>>> (It doesn't clear discuss point#1 though.) >>>> >>>> It might also imply that if the terms of service change then >>>> maybe the WF operator needs to ask Alice again, I don't know. >>>> (Not that they would or anything;-) >>> >>> Don't go boil an ocean. >>> >>>>>> - 8.2, this is outstandingly glib: "If one does not wish to >>>>>> share certain information with the world, do not allow that >>>>>> information to be freely accessible on the Internet or >>>>>> discoverable via WebFinger" - most users are never given a >>>>>> choice as to whether or not much of their information is >>>>>> freely accessible or not. I think the best that can be done >>>>>> with that is to delete it. >>>> >>>> Nah, that was always just a non-blocking comment. I do >>>> still think the statement is glib though, and would be >>>> better deleted. Most real users don't have a real choice >>>> here and pretending they do is bogus. They do have a >>>> choice to use or not use some service, but at a much >>>> higher level than we generally mean with that term. >>>> E.g. they might use or not use FB or G+ but after that >>>> most of the rest is just pretence that the user has a >>>> real choice as to what else happens with their data. >>> >>> Don't ask me to try to defend a statement in the privacy section. I >> already >>> think it goes overboard and tries to scare people into not using >> WebFinger. >>> Substitute WF with (whatever service) and it's true. So, I'm not sure >> what >>> to do with it. I would not hesitate to remove it if asked. >>> >>> And while we're at it, can we remove WF being a tool that enables a >> person >>> "to inflict harm" on someone? >>> >>>>> Is this general issue still of top importance to discuss? I think >>>>> it's really Stephen and Richard who need to weigh in on that. And >>>>> Joel isn't happy with the way 2119 language is used to express this: >>>>> >>>>>> 8.2 >>>>>> >>>>>> Further, WebFinger MUST NOT be used to provide any personal data >>>> to >>>>>> any party unless explicitly authorized by the person whose >>>>>> information is being shared. >>>>>> >>>>>> This is a usage guideline not a part of the protocol specification. >>>> At a >>>>>> minimum it should use non-normative language. probably it should be >>>> replaced >>>>>> with a description of the potential for exposure. >>>> >>>> I would argue that its a valid MUST NOT since it addresses >>>> a security/privacy issue even if not an interop issue, so >>>> I'd rather keep the 2119 term. I agree that might not be a >>>> winning argument. For security it would be valid I think >>>> to say you MUST NOT use a crap PRNG which is arguably >>>> similar enough. We don't have such a consensus for privacy >>>> related statements afaik, though perhaps we ought try to >>>> develop that. In any case, the MUST NOT doesn't hurt anyone >>>> and does help some folks, so I'd say keeping it is better. >>>> (I'd live with a non-normative statement, if need be.) >>> >>> So, do we make it lowercase or change it to REALLY SHOULD NOT? ;-) >>> >>> Paul >>> >>> > From paulej@packetizer.com Fri Apr 19 15:42:33 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543E021F8FDD; Fri, 19 Apr 2013 15:42:33 -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 wjaBcQpvbThA; Fri, 19 Apr 2013 15:42:32 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4870D21F8F9D; Fri, 19 Apr 2013 15:42:32 -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 r3JMgMev022358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Apr 2013 18:42:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1366411344; bh=iVYxBSjVPoS5J1AuUgVBBCX75vUMUbAEIV+KMk2ZoQA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Hn4H0hFKICdxXLVZ+vz9qAQ/okV3Fa77VknetPtL0zFG438lTJDPFhg1sLNfYIt6e eqVUpjJUumFIQxRVVB6U++pLScJHbsIUT3HenhAiRIXyADaXqgq6v2BTLBTlVt3LTe KadL1jqOCboNLGRnqA4ku7bIgMxCVa5uQwybRRv4= From: "Paul E. Jones" To: "'Stephen Farrell'" References: <516EC7BB.2050409@cs.tcd.ie> <048201ce3c0d$72f47d70$58dd7850$@packetizer.com> <516FB856.6050503@cs.tcd.ie> <022c01ce3ca0$9d92a370$d8b7ea50$@packetizer.com> <51715624.7030901@cs.tcd.ie> In-Reply-To: <51715624.7030901@cs.tcd.ie> Date: Fri, 19 Apr 2013 18:42:33 -0400 Message-ID: <037101ce3d4f$305c5030$9114f090$@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: AQKF+rJ19Sq3YwmLzkQPsCCUeEFrLgKJ4oOVAMxuZnMBqcRkZwBRuAGGAxbATVQBF+GlaZcipUkQ Content-Language: en-us Cc: webfinger@ietf.org, appsawg-chairs@tools.ietf.org, 'Barry Leiba' , 'The IESG' , draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [webfinger] All the DISCUSS positions on draft-ietf-appsawg-webfinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 22:42:33 -0000 I'm OK with deleting that. I'll delete it from my text unless someone objects. Waiting on direction for the MUST NOT part. Paul > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Friday, April 19, 2013 10:35 AM > To: Paul E. Jones > Cc: webfinger@ietf.org; appsawg-chairs@tools.ietf.org; 'Barry Leiba'; > 'The IESG'; draft-ietf-appsawg-webfinger.all@tools.ietf.org > Subject: Re: All the DISCUSS positions on draft-ietf-appsawg-webfinger > > > > On 04/19/2013 02:52 AM, Paul E. Jones wrote: > > What about the statement in the privacy section. Leave it or remove > it? > > Just to be sure, you mean this one: > > "If one does not wish to > share certain information with the world, do not allow that > information to be freely accessible on the Internet or > discoverable via WebFinger" > > I'm for taking it out. The MUST NOT phrase does the job and this > doesn't help IMO. But its a comment, so up to you and Barry as > far as I'm concerned. > > S. > > > > > Paul > > > >> -----Original Message----- > >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > >> Sent: Thursday, April 18, 2013 5:10 AM > >> To: Paul E. Jones > >> Cc: 'Barry Leiba'; webfinger@ietf.org; appsawg-chairs@tools.ietf.org; > >> 'The IESG'; draft-ietf-appsawg-webfinger.all@tools.ietf.org > >> Subject: Re: All the DISCUSS positions on draft-ietf-appsawg- > webfinger > >> > >> > >> Hi Paul, > >> > >> On 04/18/2013 09:19 AM, Paul E. Jones wrote: > >>> Stephen, > >>> > >>>>>> "WebFinger MUST NOT be used to provide any personal data to any > >>>>>> party unless explicitly authorized by the person whose > information > >> is > >>>>>> being shared. > >>>> > >>>> I do think the above isn't well specified. And that does touch > >>>> on my discuss point #1, even if that wasn't very clear (my > >>>> fault;-) I agree that we're probably better off starting with > >>>> fixing this bit though regardless of how discuss points are > >>>> written up. > >>>> > >>>> The MUST NOT could be read to mean that Alice has to say who is > >>>> and who is not allowed access to Alice's information when she > decides > >>>> to make that available via WF. Its not clear that the "explicitly > >>>> authorized" means only "by Alice for whoever the WF service allows" > >>>> and not e.g. "by Alice for Bob" or "by Alice for her friends" or > >>>> "by Alice for people in .de" > >>>> > >>>> Now I know that the intent is not to require Alice to specify > >>>> who can access her stuff, but it could be read to mean that, > >>>> e.g. by some over-zealous regulator. (And that over-zealous > >>>> regulator might then say that having the automated access in > >>>> 3.1 succeed isn't ok, which is the link to my discuss point #1.) > >>>> > >>>> I think what was meant was more like: > >>>> > >>>> WebFinger MUST NOT be used to provide any personal data unless > >>>> publishing that data via WebFinger by the relevant service > >>>> was explicitly authorized by the person whose information > >>>> is being shared. > >>> > >>> Yeah, that's the intent. Your wording sounds fine to me. > >> > >> So I think on this point the remaining issue is for the folks > >> who think the 2119 term above is bogus to speak up. (And just > >> lower casing is not a fix, we don't have IETF consensus as to > >> whether or not that makes any difference.) > >> > >> I think using MUST NOT there is good I guess its over to Joel > >> who has the opposite opinion in his discuss. > >> > >> S. > >> > >>> > >>>> I think that (or an equivalent) were stated in 8.2 then that'd > >>>> be better and would break the link with my discuss point#1. > >>>> (It doesn't clear discuss point#1 though.) > >>>> > >>>> It might also imply that if the terms of service change then > >>>> maybe the WF operator needs to ask Alice again, I don't know. > >>>> (Not that they would or anything;-) > >>> > >>> Don't go boil an ocean. > >>> > >>>>>> - 8.2, this is outstandingly glib: "If one does not wish to > >>>>>> share certain information with the world, do not allow that > >>>>>> information to be freely accessible on the Internet or > >>>>>> discoverable via WebFinger" - most users are never given a > >>>>>> choice as to whether or not much of their information is > >>>>>> freely accessible or not. I think the best that can be done > >>>>>> with that is to delete it. > >>>> > >>>> Nah, that was always just a non-blocking comment. I do > >>>> still think the statement is glib though, and would be > >>>> better deleted. Most real users don't have a real choice > >>>> here and pretending they do is bogus. They do have a > >>>> choice to use or not use some service, but at a much > >>>> higher level than we generally mean with that term. > >>>> E.g. they might use or not use FB or G+ but after that > >>>> most of the rest is just pretence that the user has a > >>>> real choice as to what else happens with their data. > >>> > >>> Don't ask me to try to defend a statement in the privacy section. I > >> already > >>> think it goes overboard and tries to scare people into not using > >> WebFinger. > >>> Substitute WF with (whatever service) and it's true. So, I'm not > sure > >> what > >>> to do with it. I would not hesitate to remove it if asked. > >>> > >>> And while we're at it, can we remove WF being a tool that enables a > >> person > >>> "to inflict harm" on someone? > >>> > >>>>> Is this general issue still of top importance to discuss? I think > >>>>> it's really Stephen and Richard who need to weigh in on that. And > >>>>> Joel isn't happy with the way 2119 language is used to express > this: > >>>>> > >>>>>> 8.2 > >>>>>> > >>>>>> Further, WebFinger MUST NOT be used to provide any personal > data > >>>> to > >>>>>> any party unless explicitly authorized by the person whose > >>>>>> information is being shared. > >>>>>> > >>>>>> This is a usage guideline not a part of the protocol > specification. > >>>> At a > >>>>>> minimum it should use non-normative language. probably it should > be > >>>> replaced > >>>>>> with a description of the potential for exposure. > >>>> > >>>> I would argue that its a valid MUST NOT since it addresses > >>>> a security/privacy issue even if not an interop issue, so > >>>> I'd rather keep the 2119 term. I agree that might not be a > >>>> winning argument. For security it would be valid I think > >>>> to say you MUST NOT use a crap PRNG which is arguably > >>>> similar enough. We don't have such a consensus for privacy > >>>> related statements afaik, though perhaps we ought try to > >>>> develop that. In any case, the MUST NOT doesn't hurt anyone > >>>> and does help some folks, so I'd say keeping it is better. > >>>> (I'd live with a non-normative statement, if need be.) > >>> > >>> So, do we make it lowercase or change it to REALLY SHOULD NOT? ;-) > >>> > >>> Paul > >>> > >>> > > From barryleiba@gmail.com Sat Apr 20 02:47:38 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F1121F8DD4; Sat, 20 Apr 2013 02:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 bSxiM+PY6aYx; Sat, 20 Apr 2013 02:47:38 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 572EE21F8D8E; Sat, 20 Apr 2013 02:47:37 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id el20so4249664lab.9 for ; Sat, 20 Apr 2013 02:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OzSR8t1G0+1d9ByGl9j/tyA/Hub32ORTekTJbvbP1Jw=; b=C36NoeFlW7osGovwEz5NBR79fY+kz7am9UeI2ZVXOnb3JRP2OlgHoYwVu/oa3P0CBC b/br7lttGWns7arQA/y8JuGnEKa5dUhxGIiPimTYSbHJ6qPEtz+hlAbP1Vtg9XN6DAIx mAKYqYFDngsMSjJeCiEmSpCXPtwlMFyh5SDbj6HFh8+HacAFhYlp8U2yy1n+XhtpevZr 9BpvEzOy3C1Vjl3cv1LiAUlnbxtCg2JUgpQ/aJzOunT3jCq63Bl388Lm9wL1BdxjSAp6 6OGBi91ibS1AvWUKer/FnYT0VnnAOHr5GB3xOPbntike8+oa+gjfWffjJ3xWxC4xypUl eEcw== MIME-Version: 1.0 X-Received: by 10.112.134.135 with SMTP id pk7mr9644570lbb.54.1366451256231; Sat, 20 Apr 2013 02:47:36 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.117.225 with HTTP; Sat, 20 Apr 2013 02:47:36 -0700 (PDT) In-Reply-To: <037101ce3d4f$305c5030$9114f090$@packetizer.com> References: <516EC7BB.2050409@cs.tcd.ie> <048201ce3c0d$72f47d70$58dd7850$@packetizer.com> <516FB856.6050503@cs.tcd.ie> <022c01ce3ca0$9d92a370$d8b7ea50$@packetizer.com> <51715624.7030901@cs.tcd.ie> <037101ce3d4f$305c5030$9114f090$@packetizer.com> Date: Sat, 20 Apr 2013 05:47:36 -0400 X-Google-Sender-Auth: kHCCVHbtAfIFap0-CJpo0w6fcHQ Message-ID: From: Barry Leiba To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e011841d6bb0e5a04dac7b940 Cc: "webfinger@ietf.org" , "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-webfinger.all@tools.ietf.org" , The IESG , Stephen Farrell Subject: Re: [webfinger] All the DISCUSS positions on draft-ietf-appsawg-webfinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 09:47:38 -0000 --089e011841d6bb0e5a04dac7b940 Content-Type: text/plain; charset=ISO-8859-1 > Waiting on direction for the MUST NOT part. Go ahead and take that out, and post. Then we can start discussion on the second issue for which Pete is the lead AD. Barry On Friday, April 19, 2013, Paul E. Jones wrote: > I'm OK with deleting that. I'll delete it from my text unless someone > objects. > > Waiting on direction for the MUST NOT part. > > Paul > > > -----Original Message----- > > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie ] > > Sent: Friday, April 19, 2013 10:35 AM > > To: Paul E. Jones > > Cc: webfinger@ietf.org; appsawg-chairs@tools.ietf.org; 'Barry Leiba'; > > 'The IESG'; draft-ietf-appsawg-webfinger.all@tools.ietf.org > > Subject: Re: All the DISCUSS positions on draft-ietf-appsawg-webfinger > > > > > > > > On 04/19/2013 02:52 AM, Paul E. Jones wrote: > > > What about the statement in the privacy section. Leave it or remove > > it? > > > > Just to be sure, you mean this one: > > > > "If one does not wish to > > share certain information with the world, do not allow that > > information to be freely accessible on the Internet or > > discoverable via WebFinger" > > > > I'm for taking it out. The MUST NOT phrase does the job and this > > doesn't help IMO. But its a comment, so up to you and Barry as > > far as I'm concerned. > > > > S. > > > > > > > > Paul > > > > > >> -----Original Message----- > > >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > > >> Sent: Thursday, April 18, 2013 5:10 AM > > >> To: Paul E. Jones > > >> Cc: 'Barry Leiba'; webfinger@ietf.org; appsawg-chairs@tools.ietf.org; > > >> 'The IESG'; draft-ietf-appsawg-webfinger.all@tools.ietf.org > > >> Subject: Re: All the DISCUSS positions on draft-ietf-appsawg- > > webfinger > > >> > > >> > > >> Hi Paul, > > >> > > >> On 04/18/2013 09:19 AM, Paul E. Jones wrote: > > >>> Stephen, > > >>> > > >>>>>> "WebFinger MUST NOT be used to provide any personal data to any > > >>>>>> party unless explicitly authorized by the person whose > > information > > >> is > > >>>>>> being shared. > > >>>> > > >>>> I do think the above isn't well specified. And that does touch > > >>>> on my discuss point #1, even if that wasn't very clear (my > > >>>> fault;-) I agree that we're probably better off starting with > > >>>> fixing this bit though regardless of how discuss points are > > >>>> written up. > > >>>> > > >>>> The MUST NOT could be read to mean that Alice has to say who is > > >>>> and who is not allowed access to Alice's information when she > > decides > > >>>> to make that available via WF. Its not clear that the "explicitly > > >>>> authorized" means only "by Alice for whoever the WF service allows" > > >>>> and not e.g. "by Alice for Bob" or "by Alice for her friends" or > > >>>> "by Alice for people in .de" > > >>>> > > >>>> Now I know that the intent is not to require Alice to specify > > >>>> who can access her stuff, but it could be read to mean that, > > >>>> e.g. by some over-zealous regulator. (And that over-zealous > > >>>> regulator might then say that having the automated access in > > >>>> 3.1 succeed isn't ok, which is the link to my discuss point #1.) > > >>>> > > >>>> I think what was meant was more like: > > >>>> > > >>>> WebFinger MUST NOT be used to provide any personal data unless > > >>>> publishing that data via WebFinger by the relevant service > > >>>> was explicitly authorized by the person whose information > > >>>> is being shared. > > >>> > > >>> Yeah, that's the intent. Your wording sounds fine to me. > > >> > > >> So I think on this point the remaining issue is for the folks > > >> who think the 2119 term above is bogus to speak up. (And just > > >> lower casing is not a fix, we don't have IETF consensus as to > > >> whether or not that makes any difference.) > > --089e011841d6bb0e5a04dac7b940 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >=A0Waiting on direction for the MUST NOT part.

Go ahead and take that out, and post. =A0T= hen we can start discussion on the second issue for which Pete is the lead = AD.

= Barry

On Friday, April 19, 2013, Paul E. Jones wrote:
I'm OK with deleting that. =A0I'll delete it from my text unless so= meone
objects.

Waiting on direction for the MUST NOT part.

Paul

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell= @cs.tcd.ie]
> Sent: Friday, April 19, 2013 10:35 AM
> To: Paul E. Jones
> Cc: webfinger@ietf.org; appsawg-chairs@tools.ietf.org; &= #39;Barry Leiba';
> 'The IESG'; draft-ietf-appsawg-webfinger.all@tools.ietf.org=
> Subject: Re: All the DISCUSS positions on draft-ietf-appsawg-webfinger=
>
>
>
> On 04/19/2013 02:52 AM, Paul E. Jones wrote:
> > What about the statement in the privacy section. =A0Leave it or r= emove
> it?
>
> Just to be sure, you mean this one:
>
> =A0 "If one does not wish to
> =A0 =A0share certain information with the world, do not allow that
> =A0 =A0information to be freely accessible on the Internet or
> =A0 =A0discoverable via WebFinger"
>
> I'm for taking it out. The MUST NOT phrase does the job and this > doesn't help IMO. But its a comment, so up to you and Barry as
> far as I'm concerned.
>
> S.
>
> >
> > Paul
> >
> >> -----Original Message-----
> >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> >> Sent: Thursday, April 18, 2013 5:10 AM
> >> To: Paul E. Jones
> >> Cc: 'Barry Leiba'; webfinger@ietf.org; apps= awg-chairs@tools.ietf.org;
> >> 'The IESG'; draft-ietf-appsawg-webfinger.all@tools= .ietf.org
> >> Subject: Re: All the DISCUSS positions on draft-ietf-appsawg-=
> webfinger
> >>
> >>
> >> Hi Paul,
> >>
> >> On 04/18/2013 09:19 AM, Paul E. Jones wrote:
> >>> Stephen,
> >>>
> >>>>>> "WebFinger MUST NOT be used to provide a= ny personal data to any
> >>>>>> party unless explicitly authorized by the per= son whose
> information
> >> is
> >>>>>> being shared.
> >>>>
> >>>> I do think the above isn't well specified. And th= at does touch
> >>>> on my discuss point #1, even if that wasn't very = clear (my
> >>>> fault;-) I agree that we're probably better off s= tarting with
> >>>> fixing this bit though regardless of how discuss poin= ts are
> >>>> written up.
> >>>>
> >>>> The MUST NOT could be read to mean that Alice has to = say who is
> >>>> and who is not allowed access to Alice's informat= ion when she
> decides
> >>>> to make that available via WF. Its not clear that the= "explicitly
> >>>> authorized" means only "by Alice for whoeve= r the WF service allows"
> >>>> and not e.g. "by Alice for Bob" or "by= Alice for her friends" or
> >>>> "by Alice for people in .de"
> >>>>
> >>>> Now I know that the intent is not to require Alice to= specify
> >>>> who can access her stuff, but it could be read to mea= n that,
> >>>> e.g. by some over-zealous regulator. (And that over-z= ealous
> >>>> regulator might then say that having the automated ac= cess in
> >>>> 3.1 succeed isn't ok, which is the link to my dis= cuss point #1.)
> >>>>
> >>>> I think what was meant was more like:
> >>>>
> >>>> =A0 =A0WebFinger MUST NOT be used to provide any pers= onal data unless
> >>>> =A0 =A0publishing that data via WebFinger by the rele= vant service
> >>>> =A0 =A0was explicitly authorized by the person whose = information
> >>>> =A0 =A0is being shared.
> >>>
> >>> Yeah, that's the intent. =A0Your wording sounds fine = to me.
> >>
> >> So I think on this point the remaining issue is for the folks=
> >> who think the 2119 term above is bogus to speak up. (And just=
> >> lower casing is not a fix, we don't have IETF consensus a= s to
> >> whether or not that makes any difference.)
>
--089e011841d6bb0e5a04dac7b940-- From hammondjohnson@hushmail.com Sat Apr 27 15:47:30 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7FD21F991C for ; Sat, 27 Apr 2013 15:47: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=[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 mQI6VwqaXrlQ for ; Sat, 27 Apr 2013 15:47:28 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE9921F9910 for ; Sat, 27 Apr 2013 15:47:28 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id A3973580B9 for ; Sat, 27 Apr 2013 17:55:08 +0000 (UTC) X-hush-relay-time: 215 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:55:08 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 747FCE6736; Sat, 27 Apr 2013 17:55:08 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:55:08 -0400 To: webfinger@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427175508.747FCE6736@smtp.hushmail.com> Subject: [webfinger] Biggest Fake Conference in Computer Science X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 22:47:31 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.